Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

GCC 5.1 released

gcc.gnu.org

Post reply on HN
Print view View original

41–50 of 54 posts

Re: GCC 5.1 released

#41

Post by TheLoneWolfling »

JoachimSchipper wrote: post #40
JoeAltmaier wrote: post #39

I'm troubled that 'write-only variables are ... optimized out'. That means, no more embedded trace buffers in memory dumps? I've used that for decades to debug intermittent problems. Maybe there's some way to tag necessary write-only variables...

volatile works, asm works, and it's usually not hard to trick the optimizer.

It's becoming harder to trick the optimizer all the time.

I mean, the goal of an optimizer is literally not to be able to be tricked into doing work it doesn't have to.

Re: GCC 5.1 released

#42

Post by JoeAltmaier »

JoachimSchipper wrote: post #40
JoeAltmaier wrote: post #39

I'm troubled that 'write-only variables are ... optimized out'. That means, no more embedded trace buffers in memory dumps? I've used that for decades to debug intermittent problems. Maybe there's some way to tag necessary write-only variables...

volatile works, asm works, and it's usually not hard to trick the optimizer.

I wondered about 'volatile'. Its not really meant for that - but maybe its enough to trigger 'hands off'.

Re: GCC 5.1 released

#43

Post by JoachimSchipper »

TheLoneWolfling wrote: post #41
JoachimSchipper wrote: post #40

Earlier quoted context omitted.

volatile works, asm works, and it's usually not hard to trick the optimizer.

It's becoming harder to trick the optimizer all the time. I mean, the goal of an optimizer is literally not to be able to be tricked into doing work it doesn't have to.

Yes; e.g. http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string... demonstrates that rather well. Still, it is and will remain possible - and for the intended use, that's probably good enough. (It's not write - and - forget code where tricking the optimizer is security-critical.)

Re: GCC 5.1 released

#44

Post by fragmede »

JoeAltmaier wrote: post #42
JoachimSchipper wrote: post #40

Earlier quoted context omitted.

volatile works, asm works, and it's usually not hard to trick the optimizer.

I wondered about 'volatile'. Its not really meant for that - but maybe its enough to trigger 'hands off'.

Practically speaking, 'volatile' has used for that pretty much since its inception.

Re: GCC 5.1 released

#45

Post by Devid2014 »

huu wrote: post #34
bstamour wrote: post #29

Earlier quoted context omitted.

I haven't really heard much buzz about C11 since its release. I don't mean to sound snarky (I'm really curious): does anyone really use C11 at all?

I use C++11 and it's awesome. It's expressive like python but still maintains strict type safety. I built a (still young) curl wrapper using C++11: https://github.com/whoshuu/cpr Edit: Misread the parent posts and thought they were referring to C++11. Today I learned C11 is a separate standard.

Nice looking project but unfortunately it is GPL. Unlike Curl it self because it uses MIT like license.

Re: GCC 5.1 released

#46

Post by jbrandmeyer »

bstamour wrote: post #29
ehmmm wrote: post #19

It is so close to full C11 support. I think just threads.h are missing now.

I haven't really heard much buzz about C11 since its release. I don't mean to sound snarky (I'm really curious): does anyone really use C11 at all?

As an embedded programmer, I have to say that C11 atomics are a much better fit for device register access than volatile. Unfortunately, since many commercial C compilers don't even support C99 fully, I don't expect to see C11 in common use anytime soon.

Re: GCC 5.1 released

#47

Post by huu »

Devid2014 wrote: post #45
huu wrote: post #34

Earlier quoted context omitted.

I use C++11 and it's awesome. It's expressive like python but still maintains strict type safety. I built a (still young) curl wrapper using C++11: https://github.com/whoshuu/cpr Edit: Misread the parent posts and thought they were referring to C++11. Today I learned C11 is a separate standard.

Nice looking project but unfortunately it is GPL. Unlike Curl it self because it uses MIT like license.

Excellent point, I just changed the license to MIT to be consistent with curl. Thanks for catching that.

Re: GCC 5.1 released

#48

Post by loup-vaillant »

Devid2014 wrote: post #45
huu wrote: post #34

Earlier quoted context omitted.

I use C++11 and it's awesome. It's expressive like python but still maintains strict type safety. I built a (still young) curl wrapper using C++11: https://github.com/whoshuu/cpr Edit: Misread the parent posts and thought they were referring to C++11. Today I learned C11 is a separate standard.

Nice looking project but unfortunately it is GPL. Unlike Curl it self because it uses MIT like license.

Too bad proprietary projects can't link against it. A loss for us all.

Seriously? GPL stuff can be used with any internal stuff, and almost any Free stuff. Isn't that enough? Where is the loss exactly?

Edit: okay, that wasn't the author's intention, and the consistency argument is a good one (least astonishment and all that). Still, the general argument holds.

Re: GCC 5.1 released

#49

Post by rurban »

ploxiln wrote: post #9

I won't be able to use them in portable code anytime soon, but the new feature here that most interests me is __builtin_add_overflow, __builtin_sub_overflow and __builtin_mul_overflow "These builtins have two integral arguments (which don't need to have the same type), the arguments are extended to infinite precision signed type, +, - or * is performed on those, and the result is stored in an integer variable pointed…

I use them for some time now with

    +#if (defined(__clang__) && ((__clang_major__ > 3) \
    +                         || (__clang_major__ == 3 &&     __clang_minor__ >= 4))) \
    + || (defined(__GNUC__) && __GNUC__ >= 5)

Re: GCC 5.1 released

#50

Post by TheLoneWolfling »

JoachimSchipper wrote: post #43
TheLoneWolfling wrote: post #41

Earlier quoted context omitted.

It's becoming harder to trick the optimizer all the time. I mean, the goal of an optimizer is literally not to be able to be tricked into doing work it doesn't have to.

Yes; e.g. http://cvsweb.openbsd.org/cgi-bin/cvsweb/src/lib/libc/string... demonstrates that rather well. Still, it is and will remain possible - and for the intended use, that's probably good enough. (It's not write - and - forget code where tricking the optimizer is security-critical.)

If you're having to trick the optimizer, you're doing something wrong.

If the language is such that there are things in the language that inherently require tricking the optimizer, the language is doing it wrong.

Post reply on HN