Re: Re: Why does gcc generate const local array on stack?
I agree with you on this example.
But in my original code, as Jonathan pointed out, is not recursive and
the address of "a" does not escape the function in any way. I believe
it is valid transformation.
BTW, LLVM compiles your example still by moving const array to rodata,
which I think is wrong and will fail the test.
Cheers,
Bingfeng
On Thu, Apr 21, 2016 at 3:41 AM, lh_mouse wrote:
> See this example: http://coliru.stacked-crooked.com/a/048b4aa5046da11b
>
> In this example the function is called recursively.
> During each call a pointer to that local areay is appended to a static array
> of pointers.
> Should a new instance of that local array of const int be created every time,
> abort() will never be called.
> Since calling a library function is observable behavior, clang's optimization
> has effectively changed that program's behavior. Hence I think it is wrong.
>
> [code]
> #include
>
> static const int *ptrs[2];
> static unsigned recur;
>
> void foo(){
> const int a[] = {0,1,2,3,4,5,6,7,8,9};
> ptrs[recur] = a;
> if(recur == 0){
> ++recur;
> foo();
> }
> if(ptrs[0] == ptrs[1]){
> abort();
> }
> }
>
> int main(){
> foo();
> }
> [/code]
>
> --
> Best regards,
> lh_mouse
> 2016-04-21
>
> -
> 发件人：Jonathan Wakely
> 发送日期：2016-04-21 01:51
> 收件人：lh_mouse
> 抄送：Bingfeng Mei,gcc
> 主题：Re: Why does gcc generate const local array on stack?
>
> On 20 April 2016 at 18:31, lh_mouse wrote:
>> I tend to say clang is wrong here.
>
> If you can't detect the difference then it is a valid transformation.
>
>> Your identifier 'a' has no linkage. Your object designated by 'a' does not
>> have a storage-class specifier.
>> So it has automatic storage duration and 6.2.4/7 applies: 'If the scope is
>> entered recursively, a new instance of the object is created each time.'
>
> How do you tell the difference between a const array that is recreated
> each time and one that isn't?
>
>> Interesting enough, ISO C doesn't say whether distinct objects should have
>> distinct addresses.
>> It is worth noting that this is explicitly forbidden in ISO C++ because
>> distinct complete objects shall have distinct addresses:
>
> If the object's address doesn't escape from the function then I can't
> think of a way to tell the difference.
>
>
Re: Re: Why does gcc generate const local array on stack?
On 21 April 2016 at 03:41, lh_mouse wrote: > See this example: http://coliru.stacked-crooked.com/a/048b4aa5046da11b > > In this example the function is called recursively. See the original email you replied to: "I understand if this function is recursive and pointer of the array is involved, GCC would have to maintain the array on stack and hence the initialization." The question is about cases where that doesn't happen.
Re: Looking for some help with GCC 6 and bad code generation
This is the wrong mailing list for such questions, the gcc-help list would be appropriate. On 21 April 2016 at 02:11, Zan Lynx wrote: > I would like someone to look at this and tell me this is an already > fixed bug. Or that recent GCC patches may have fixed it. :-) > > Or it would also be great to get some advice on building a reproducer > without needing to include many megabytes of proprietary code plus Boost. > > I've been using Fedora 24 Alpha and of course I've somehow managed to > write some C++ code even more confusing for GCC than Firefox. Heh. > > The problem is a crash when std::string tries to free memory from a > temporary std::string that was bound to a const reference. This usually means you have a reference to a local or a reference to a temporary that has gone out of scope. With the COW std::string you could usually get away with that, because the actual string representation wasn't always destroyed when objects went out of scope. With the new std::string you have to be more careful, invalid uses of destroyed objects result in accesses to deleted or clobbered memory.
Re: Re: Why does gcc generate const local array on stack?
On Thu, Apr 21, 2016 at 11:39 AM, Jonathan Wakely wrote: > On 21 April 2016 at 03:41, lh_mouse wrote: >> See this example: http://coliru.stacked-crooked.com/a/048b4aa5046da11b >> >> In this example the function is called recursively. > > See the original email you replied to: > > "I understand if this function is recursive and pointer of the array > is involved, GCC would have to maintain the array on stack and hence > the initialization." > > The question is about cases where that doesn't happen. The decision on whether to localize the array and inline the init is done at gimplification time. The plan is to delay this until SRA which could then also apply the desired optimization of removing the local in case it is never written to. Richard.
GCC 6 symbol poisoning and c++ header usage is fragile
building gcc6 using musl based gcc6 fails with symbol poisoning error (details at the end of the mail). the root cause is c++: c++ headers include random libc headers with _GNU_SOURCE ftm so all sorts of unexpected symbols are defined/declared. since it's unlikely the c++ standard gets fixed (to properly specify the namespace rules) it is not acceptable to include std headers after system.h, where the poisoning happens, because trivial libc header change will break the build. c++ header use in gcc seems inconsistent, e.g. there are cases where - is included before system.h (go-system.h) - is included after system.h (indirectly through ) - is included in system.h because INCLUDE_STRING is defined. - is included in system.h and in source files using it.. sometimes i think it should be consistently before system.h (i'm not sure what's going on with the INCLUDE_STRING macro), fortunately not many files are affected in gcc/: auto-profile.c diagnostic.c graphite-isl-ast-to-gimple.c ipa-icf.c ipa-icf-gimple.c pretty-print.c toplev.c i can prepare a patch moving the c++ includes up and i'm open to other suggestions. (including libc headers is also problematic because of _GNU_SOURCE, but still safer than what is happening in c++ land where #include makes all locale.h, pthread.h, time.h, sched.h, etc symbols visible). x86_64-linux-musl-g++ -fno-PIE -c -g -O2 -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H -I. -I. -I/src/gcc/gcc -I/src/gcc/gcc/. -I/src/gcc/gcc/../include -I/src/gcc/gcc/../libcpp/include -I/build/host-tools/include -I/build/host-tools/include -I/build/host-tools/include -I/src/gcc/gcc/../libdecnumber -I/src/gcc/gcc/../libdecnumber/dpd -I../libdecnumber -I/src/gcc/gcc/../libbacktrace -o auto-profile.o -MT auto-profile.o -MMD -MP -MF ./.deps/auto-profile.TPo /src/gcc/gcc/auto-profile.c In file included from /tool/x86_64-linux-musl/include/pthread.h:30:0, from /tool/x86_64-linux-musl/include/c++/6.0.1/x86_64-linux-musl/bits/gthr-default.h:35, from /tool/x86_64-linux-musl/include/c++/6.0.1/x86_64-linux-musl/bits/gthr.h:148, from /tool/x86_64-linux-musl/include/c++/6.0.1/ext/atomicity.h:35, from /tool/x86_64-linux-musl/include/c++/6.0.1/bits/basic_string.h:39, from /tool/x86_64-linux-musl/include/c++/6.0.1/string:52, from /tool/x86_64-linux-musl/include/c++/6.0.1/stdexcept:39, from /tool/x86_64-linux-musl/include/c++/6.0.1/array:39, from /tool/x86_64-linux-musl/include/c++/6.0.1/tuple:39, from /tool/x86_64-linux-musl/include/c++/6.0.1/bits/stl_map.h:63, from /tool/x86_64-linux-musl/include/c++/6.0.1/map:61, from /src/gcc/gcc/auto-profile.c:36: /tool/x86_64-linux-musl/include/sched.h:74:7: error: attempt to use poisoned "calloc" void *calloc(size_t, size_t); ^ /tool/x86_64-linux-musl/include/sched.h:114:36: error: attempt to use poisoned "calloc" #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n))) ^
Re: GCC 6 symbol poisoning and c++ header usage is fragile
On Thu, Apr 21, 2016 at 1:11 PM, Szabolcs Nagy wrote: > building gcc6 using musl based gcc6 fails with symbol poisoning error > (details at the end of the mail). > > the root cause is c++: c++ headers include random libc headers with > _GNU_SOURCE ftm so all sorts of unexpected symbols are defined/declared. > > since it's unlikely the c++ standard gets fixed (to properly specify > the namespace rules) it is not acceptable to include std headers after > system.h, where the poisoning happens, because trivial libc header > change will break the build. > > c++ header use in gcc seems inconsistent, e.g. there are cases where > - is included before system.h (go-system.h) > - is included after system.h (indirectly through ) > - is included in system.h because INCLUDE_STRING is defined. > - is included in system.h and in source files using it.. sometimes > > i think it should be consistently before system.h (i'm not sure what's > going on with the INCLUDE_STRING macro), fortunately not many files are > affected in gcc/: system headers should be included from _within_ system.h. To avoid including them everywhere we use sth like /* Include before "safe-ctype.h" to avoid GCC poisoning the ctype macros through safe-ctype.h */ #ifdef __cplusplus #ifdef INCLUDE_STRING # include #endif #endif so sources do #define INCLUDE_STRING #include "config.h" #include "system.h" So the cases can be simplified with INCLUDE_STRING and the case should be added similarly (unless we decide is cheap enough to be always included). Richard. > auto-profile.c > diagnostic.c > graphite-isl-ast-to-gimple.c > ipa-icf.c > ipa-icf-gimple.c > pretty-print.c > toplev.c > > i can prepare a patch moving the c++ includes up and i'm open to > other suggestions. (including libc headers is also problematic because > of _GNU_SOURCE, but still safer than what is happening in c++ land > where #include makes all locale.h, pthread.h, time.h, sched.h, > etc symbols visible). > > > x86_64-linux-musl-g++ -fno-PIE -c -g -O2 -DIN_GCC -fno-exceptions > -fno-rtti -fasynchronous-unwind-tables > -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual > -Wmissing-format-attribute -Woverloaded-virtual -pedantic > -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -DHAVE_CONFIG_H > -I. -I. -I/src/gcc/gcc > -I/src/gcc/gcc/. -I/src/gcc/gcc/../include -I/src/gcc/gcc/../libcpp/include > -I/build/host-tools/include > -I/build/host-tools/include -I/build/host-tools/include > -I/src/gcc/gcc/../libdecnumber > -I/src/gcc/gcc/../libdecnumber/dpd -I../libdecnumber > -I/src/gcc/gcc/../libbacktrace -o auto-profile.o -MT > auto-profile.o -MMD -MP -MF ./.deps/auto-profile.TPo > /src/gcc/gcc/auto-profile.c > In file included from /tool/x86_64-linux-musl/include/pthread.h:30:0, > from > /tool/x86_64-linux-musl/include/c++/6.0.1/x86_64-linux-musl/bits/gthr-default.h:35, > from > /tool/x86_64-linux-musl/include/c++/6.0.1/x86_64-linux-musl/bits/gthr.h:148, > from > /tool/x86_64-linux-musl/include/c++/6.0.1/ext/atomicity.h:35, > from > /tool/x86_64-linux-musl/include/c++/6.0.1/bits/basic_string.h:39, > from /tool/x86_64-linux-musl/include/c++/6.0.1/string:52, > from /tool/x86_64-linux-musl/include/c++/6.0.1/stdexcept:39, > from /tool/x86_64-linux-musl/include/c++/6.0.1/array:39, > from /tool/x86_64-linux-musl/include/c++/6.0.1/tuple:39, > from > /tool/x86_64-linux-musl/include/c++/6.0.1/bits/stl_map.h:63, > from /tool/x86_64-linux-musl/include/c++/6.0.1/map:61, > from /src/gcc/gcc/auto-profile.c:36: > /tool/x86_64-linux-musl/include/sched.h:74:7: error: attempt to use poisoned > "calloc" > void *calloc(size_t, size_t); >^ > /tool/x86_64-linux-musl/include/sched.h:114:36: error: attempt to use > poisoned "calloc" > #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n))) > ^ >
Re: GCC 6 symbol poisoning and c++ header usage is fragile
On 21/04/16 12:36, Richard Biener wrote:
> On Thu, Apr 21, 2016 at 1:11 PM, Szabolcs Nagy wrote:
>> building gcc6 using musl based gcc6 fails with symbol poisoning error
>> (details at the end of the mail).
>>
>> the root cause is c++: c++ headers include random libc headers with
>> _GNU_SOURCE ftm so all sorts of unexpected symbols are defined/declared.
>>
>> since it's unlikely the c++ standard gets fixed (to properly specify
>> the namespace rules) it is not acceptable to include std headers after
>> system.h, where the poisoning happens, because trivial libc header
>> change will break the build.
>>
>> c++ header use in gcc seems inconsistent, e.g. there are cases where
>> - is included before system.h (go-system.h)
>> - is included after system.h (indirectly through )
>> - is included in system.h because INCLUDE_STRING is defined.
>> - is included in system.h and in source files using it.. sometimes
>>
>> i think it should be consistently before system.h (i'm not sure what's
>> going on with the INCLUDE_STRING macro), fortunately not many files are
>> affected in gcc/:
>
> system headers should be included from _within_ system.h. To avoid including
> them everywhere we use sth like
>
> /* Include before "safe-ctype.h" to avoid GCC poisoning
>the ctype macros through safe-ctype.h */
>
> #ifdef __cplusplus
> #ifdef INCLUDE_STRING
> # include
> #endif
> #endif
>
> so sources do
>
> #define INCLUDE_STRING
> #include "config.h"
> #include "system.h"
>
> So the cases can be simplified with INCLUDE_STRING and the
> case should be added similarly (unless we decide is cheap
> enough to be always included).
>
is always included already.
there is also , , usage and go-system.h is special.
(and gmp.h includes when built with c++)
so i can prepare a patch with INCLUDE_{MAP,SET,LIST} and remove
the explicit libc/libstdc++ includes.
> Richard.
>
>> auto-profile.c
>> diagnostic.c
>> graphite-isl-ast-to-gimple.c
>> ipa-icf.c
>> ipa-icf-gimple.c
>> pretty-print.c
>> toplev.c
>>
>> i can prepare a patch moving the c++ includes up and i'm open to
>> other suggestions. (including libc headers is also problematic because
>> of _GNU_SOURCE, but still safer than what is happening in c++ land
>> where #include makes all locale.h, pthread.h, time.h, sched.h,
>> etc symbols visible).
>>
>>
>> x86_64-linux-musl-g++ -fno-PIE -c -g -O2 -DIN_GCC -fno-exceptions
>> -fno-rtti -fasynchronous-unwind-tables
>> -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual
>> -Wmissing-format-attribute -Woverloaded-virtual -pedantic
>> -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
>> -DHAVE_CONFIG_H -I. -I. -I/src/gcc/gcc
>> -I/src/gcc/gcc/. -I/src/gcc/gcc/../include -I/src/gcc/gcc/../libcpp/include
>> -I/build/host-tools/include
>> -I/build/host-tools/include -I/build/host-tools/include
>> -I/src/gcc/gcc/../libdecnumber
>> -I/src/gcc/gcc/../libdecnumber/dpd -I../libdecnumber
>> -I/src/gcc/gcc/../libbacktrace -o auto-profile.o -MT
>> auto-profile.o -MMD -MP -MF ./.deps/auto-profile.TPo
>> /src/gcc/gcc/auto-profile.c
>> In file included from /tool/x86_64-linux-musl/include/pthread.h:30:0,
>> from
>> /tool/x86_64-linux-musl/include/c++/6.0.1/x86_64-linux-musl/bits/gthr-default.h:35,
>> from
>> /tool/x86_64-linux-musl/include/c++/6.0.1/x86_64-linux-musl/bits/gthr.h:148,
>> from
>> /tool/x86_64-linux-musl/include/c++/6.0.1/ext/atomicity.h:35,
>> from
>> /tool/x86_64-linux-musl/include/c++/6.0.1/bits/basic_string.h:39,
>> from /tool/x86_64-linux-musl/include/c++/6.0.1/string:52,
>> from /tool/x86_64-linux-musl/include/c++/6.0.1/stdexcept:39,
>> from /tool/x86_64-linux-musl/include/c++/6.0.1/array:39,
>> from /tool/x86_64-linux-musl/include/c++/6.0.1/tuple:39,
>> from
>> /tool/x86_64-linux-musl/include/c++/6.0.1/bits/stl_map.h:63,
>> from /tool/x86_64-linux-musl/include/c++/6.0.1/map:61,
>> from /src/gcc/gcc/auto-profile.c:36:
>> /tool/x86_64-linux-musl/include/sched.h:74:7: error: attempt to use poisoned
>> "calloc"
>> void *calloc(size_t, size_t);
>>^
>> /tool/x86_64-linux-musl/include/sched.h:114:36: error: attempt to use
>> poisoned "calloc"
>> #define CPU_ALLOC(n) ((cpu_set_t *)calloc(1,CPU_ALLOC_SIZE(n)))
>> ^
>>
>
Re: GCC 6 symbol poisoning and c++ header usage is fragile
On 21 April 2016 at 12:11, Szabolcs Nagy wrote: > the root cause is c++: c++ headers include random libc headers with > _GNU_SOURCE ftm so all sorts of unexpected symbols are defined/declared. Yes, I'd really like to be able to stop defining _GNU_SOURCE unconditionally. It needs some libstdc++ and glibc changes for that to happen, I'll be looking at it for gcc 7. > since it's unlikely the c++ standard gets fixed (to properly specify > the namespace rules) Fixed how? What's wrong with the rules? (I'd like to understand what's wrong here before I try to change anything, and I don't understand the comment above).
Re: GCC 6 symbol poisoning and c++ header usage is fragile
On 21/04/16 12:52, Jonathan Wakely wrote: > On 21 April 2016 at 12:11, Szabolcs Nagy wrote: >> the root cause is c++: c++ headers include random libc headers with >> _GNU_SOURCE ftm so all sorts of unexpected symbols are defined/declared. > > Yes, I'd really like to be able to stop defining _GNU_SOURCE > unconditionally. It needs some libstdc++ and glibc changes for that to > happen, I'll be looking at it for gcc 7. > > >> since it's unlikely the c++ standard gets fixed (to properly specify >> the namespace rules) > > Fixed how? What's wrong with the rules? (I'd like to understand what's > wrong here before I try to change anything, and I don't understand the > comment above). > posix has "namespace rules" specifying what symbols are reserved for the implementation when certain headers are included. (it's not entirely trivial, i have a collected list http://port70.net/~nsz/c/posix/reserved.txt http://port70.net/~nsz/c/posix/README.txt i use for testing musl headers, glibc also does such namespace checks.) e.g. the declared function names in a header are reserved to be defined as macros. c++ does not specify how its headers interact with posix headers except for a few c standard headers where it requires no macro definition for functions (and imposes some other requirements on the libc like being valid c++ syntax, using extern "C" where appropriate etc). so from a libc implementor's point of view, including libc headers into c++ code is undefined behaivour (neither posix nor c++ specifies what should happen). without a specification libc headers just piling #ifdef __cplusplus hacks when ppl run into problems. e.g. c++ code uses ::pthread_equal(a,b), but musl used a macro for pthread_equal (the only sensible implementation is (a)==(b), this has to be suppressed for c++, which now uses an extern call to do the same), i'm also pretty sure a large number of c++ code would break if unistd.h defined "read", "write", "link" etc as macros, since these are often used as method names in c++, but this would be a conforming libc implementation.
Re: GCC 6 symbol poisoning and c++ header usage is fragile
Hi,
On Thu, 21 Apr 2016, Szabolcs Nagy wrote:
> there is also , , usage and go-system.h is special.
> (and gmp.h includes when built with c++)
>
> so i can prepare a patch with INCLUDE_{MAP,SET,LIST} and remove the
> explicit libc/libstdc++ includes.
This.
> >> auto-profile.c
> >> diagnostic.c
> >> graphite-isl-ast-to-gimple.c
> >> ipa-icf.c
> >> ipa-icf-gimple.c
> >> pretty-print.c
> >> toplev.c
But check if they really are required at all in the sources. E.g.
is useless in ipa-icf-gimple.c.
Ciao,
Michael.
Re: GCC 6 symbol poisoning and c++ header usage is fragile
On Thu, Apr 21, 2016 at 8:33 AM, Szabolcs Nagy wrote: > On 21/04/16 12:52, Jonathan Wakely wrote: >> On 21 April 2016 at 12:11, Szabolcs Nagy wrote: >>> the root cause is c++: c++ headers include random libc headers with >>> _GNU_SOURCE ftm so all sorts of unexpected symbols are defined/declared. >> >> Yes, I'd really like to be able to stop defining _GNU_SOURCE >> unconditionally. It needs some libstdc++ and glibc changes for that to >> happen, I'll be looking at it for gcc 7. >> >> >>> since it's unlikely the c++ standard gets fixed (to properly specify >>> the namespace rules) >> >> Fixed how? What's wrong with the rules? (I'd like to understand what's >> wrong here before I try to change anything, and I don't understand the >> comment above). >> > > posix has "namespace rules" specifying what symbols > are reserved for the implementation when certain > headers are included. > (it's not entirely trivial, i have a collected list > http://port70.net/~nsz/c/posix/reserved.txt > http://port70.net/~nsz/c/posix/README.txt > i use for testing musl headers, glibc also does > such namespace checks.) > > e.g. the declared function names in a header are > reserved to be defined as macros. > > c++ does not specify how its headers interact with > posix headers except for a few c standard headers > where it requires no macro definition for functions > (and imposes some other requirements on the libc > like being valid c++ syntax, using extern "C" where > appropriate etc). > > so from a libc implementor's point of view, including > libc headers into c++ code is undefined behaivour > (neither posix nor c++ specifies what should happen). > without a specification libc headers just piling > #ifdef __cplusplus hacks when ppl run into problems. > > e.g. c++ code uses ::pthread_equal(a,b), but musl used > a macro for pthread_equal (the only sensible > implementation is (a)==(b), this has to be suppressed > for c++, which now uses an extern call to do the > same), i'm also pretty sure a large number of c++ > code would break if unistd.h defined "read", "write", > "link" etc as macros, since these are often used as > method names in c++, but this would be a conforming > libc implementation. C++ headers cannot be included before GCC headers because some systems, such as AIX, depend on macros defined in GCC system.h -- the behavior of the system headers depend on definitions set by GCC. The C++ headers would pull in system headers prior to the GCC headers and cause build failures. Thanks, David
Re: Re: Why does gcc generate const local array on stack?
Richard, thanks for explanation. I found an option -fmerge-all-constants, which can help me work around for now. BIngfeng On Thu, Apr 21, 2016 at 11:15 AM, Richard Biener wrote: > On Thu, Apr 21, 2016 at 11:39 AM, Jonathan Wakely > wrote: >> On 21 April 2016 at 03:41, lh_mouse wrote: >>> See this example: http://coliru.stacked-crooked.com/a/048b4aa5046da11b >>> >>> In this example the function is called recursively. >> >> See the original email you replied to: >> >> "I understand if this function is recursive and pointer of the array >> is involved, GCC would have to maintain the array on stack and hence >> the initialization." >> >> The question is about cases where that doesn't happen. > > The decision on whether to localize the array and inline the init is > done at gimplification time. > The plan is to delay this until SRA which could then also apply the > desired optimization > of removing the local in case it is never written to. > > Richard.
Re: GCC 6 symbol poisoning and c++ header usage is fragile
On 21 April 2016 at 13:33, Szabolcs Nagy wrote: > On 21/04/16 12:52, Jonathan Wakely wrote: >> On 21 April 2016 at 12:11, Szabolcs Nagy wrote: >>> the root cause is c++: c++ headers include random libc headers with >>> _GNU_SOURCE ftm so all sorts of unexpected symbols are defined/declared. >> >> Yes, I'd really like to be able to stop defining _GNU_SOURCE >> unconditionally. It needs some libstdc++ and glibc changes for that to >> happen, I'll be looking at it for gcc 7. >> >> >>> since it's unlikely the c++ standard gets fixed (to properly specify >>> the namespace rules) >> >> Fixed how? What's wrong with the rules? (I'd like to understand what's >> wrong here before I try to change anything, and I don't understand the >> comment above). >> > > posix has "namespace rules" specifying what symbols > are reserved for the implementation when certain > headers are included. > (it's not entirely trivial, i have a collected list > http://port70.net/~nsz/c/posix/reserved.txt > http://port70.net/~nsz/c/posix/README.txt > i use for testing musl headers, glibc also does > such namespace checks.) > > e.g. the declared function names in a header are > reserved to be defined as macros. > > c++ does not specify how its headers interact with > posix headers except for a few c standard headers > where it requires no macro definition for functions > (and imposes some other requirements on the libc > like being valid c++ syntax, using extern "C" where > appropriate etc). > > so from a libc implementor's point of view, including > libc headers into c++ code is undefined behaivour > (neither posix nor c++ specifies what should happen). > without a specification libc headers just piling > #ifdef __cplusplus hacks when ppl run into problems. > > e.g. c++ code uses ::pthread_equal(a,b), but musl used > a macro for pthread_equal (the only sensible > implementation is (a)==(b), this has to be suppressed > for c++, which now uses an extern call to do the > same), i'm also pretty sure a large number of c++ > code would break if unistd.h defined "read", "write", > "link" etc as macros, since these are often used as > method names in c++, but this would be a conforming > libc implementation. Gotcha, I understand what you mean now, thanks. Those rules belong in a POSIX binding for C++, not in the C++ standard, but unfortunately the group working on that has been inactive for some time. (In the absence of an official binding, I think a reasonable rule that would work for most sane C++ programs would be to say any name in ALL_CAPS and any name using the ^_[_[:upper:]].* reserved namespace can be a macro, but other names such as "read", "write", and "link" must not be defined as macros by libc headers. Maybe it would be good to come up with a set of rules for glibc and musl to agree on, if no official POSIX C++ binding is going to happen.) Even if I fix libstdc++ to not require _GNU_SOURCE that won't make the problem go away, because a user could still do: #define _POSIX_SOURCE #include and if "read" is a macro that will break the declaration of std::istream::read.
Re: GCC 6 symbol poisoning and c++ header usage is fragile
On 4/21/2016 8:20 AM, Jonathan Wakely wrote: On 21 April 2016 at 13:33, Szabolcs Nagy wrote: On 21/04/16 12:52, Jonathan Wakely wrote: On 21 April 2016 at 12:11, Szabolcs Nagy wrote: the root cause is c++: c++ headers include random libc headers with _GNU_SOURCE ftm so all sorts of unexpected symbols are defined/declared. Yes, I'd really like to be able to stop defining _GNU_SOURCE unconditionally. It needs some libstdc++ and glibc changes for that to happen, I'll be looking at it for gcc 7. since it's unlikely the c++ standard gets fixed (to properly specify the namespace rules) Fixed how? What's wrong with the rules? (I'd like to understand what's wrong here before I try to change anything, and I don't understand the comment above). posix has "namespace rules" specifying what symbols are reserved for the implementation when certain headers are included. (it's not entirely trivial, i have a collected list http://port70.net/~nsz/c/posix/reserved.txt http://port70.net/~nsz/c/posix/README.txt i use for testing musl headers, glibc also does such namespace checks.) e.g. the declared function names in a header are reserved to be defined as macros. c++ does not specify how its headers interact with posix headers except for a few c standard headers where it requires no macro definition for functions (and imposes some other requirements on the libc like being valid c++ syntax, using extern "C" where appropriate etc). so from a libc implementor's point of view, including libc headers into c++ code is undefined behaivour (neither posix nor c++ specifies what should happen). without a specification libc headers just piling #ifdef __cplusplus hacks when ppl run into problems. e.g. c++ code uses ::pthread_equal(a,b), but musl used a macro for pthread_equal (the only sensible implementation is (a)==(b), this has to be suppressed for c++, which now uses an extern call to do the same), i'm also pretty sure a large number of c++ code would break if unistd.h defined "read", "write", "link" etc as macros, since these are often used as method names in c++, but this would be a conforming libc implementation. Gotcha, I understand what you mean now, thanks. Those rules belong in a POSIX binding for C++, not in the C++ standard, but unfortunately the group working on that has been inactive for some time. (In the absence of an official binding, I think a reasonable rule that would work for most sane C++ programs would be to say any name in ALL_CAPS and any name using the ^_[_[:upper:]].* reserved namespace can be a macro, but other names such as "read", "write", and "link" must not be defined as macros by libc headers. Maybe it would be good to come up with a set of rules for glibc and musl to agree on, if no official POSIX C++ binding is going to happen.) newlib should also be on this list. I know the RTEMS community cares about being proper per POSIX and I would expect the Cygwin community to feel the same way. Other than inspection, what can be done to find violations? --joel RTEMS Even if I fix libstdc++ to not require _GNU_SOURCE that won't make the problem go away, because a user could still do: #define _POSIX_SOURCE #include and if "read" is a macro that will break the declaration of std::istream::read. -- Joel Sherrill, Ph.D. Director of Research & Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35806 Support Available(256) 722-9985
Re: GCC 6 symbol poisoning and c++ header usage is fragile
On 21 April 2016 at 15:32, Joel Sherrill wrote: >> Those rules belong in a POSIX binding for C++, not in the C++ >> standard, but unfortunately the group working on that has been >> inactive for some time. >> >> (In the absence of an official binding, I think a reasonable rule that >> would work for most sane C++ programs would be to say any name in >> ALL_CAPS and any name using the ^_[_[:upper:]].* reserved namespace >> can be a macro, but other names such as "read", "write", and "link" >> must not be defined as macros by libc headers. Maybe it would be good >> to come up with a set of rules for glibc and musl to agree on, if no >> official POSIX C++ binding is going to happen.) > > > newlib should also be on this list. I know the RTEMS community > cares about being proper per POSIX and I would expect the Cygwin > community to feel the same way. Yes, newlib should on the list too - I thought of newlib but then thought of something else and forgot to add it! > Other than inspection, what can be done to find violations? I once tried to write a gcc plugin that would check all names defined by libstdc++ and ensure they were either in the reserved namespace, or were in a whitelist of allowed names defined by the standard (such as "istream" and "read"). It didn't work because gcc plugins don't run early enough, so macros and uninstantiated templates are never seen by the plugin. I think it would be possible to write something using libclang that would check for violations of that kind of rule, but I don't know how to do that.
Re: GCC 6 symbol poisoning and c++ header usage is fragile
On Thu, Apr 21, 2016 at 12:47 PM, Jason Merrill wrote: > On Thu, Apr 21, 2016 at 11:57 AM, Jonathan Wakely > wrote: >> >> I once tried to write a gcc plugin that would check all names defined >> by libstdc++ and ensure they were either in the reserved namespace, or >> were in a whitelist of allowed names defined by the standard (such as >> "istream" and "read"). It didn't work because gcc plugins don't run >> early enough, so macros and uninstantiated templates are never seen by >> the plugin. > > > Then let's add plugin callbacks to make that possible. Jason
Re: GCC 6 symbol poisoning and c++ header usage is fragile
On 21 April 2016 at 17:47, Jason Merrill wrote: > On Thu, Apr 21, 2016 at 11:57 AM, Jonathan Wakely > wrote: >> >> I once tried to write a gcc plugin that would check all names defined >> by libstdc++ and ensure they were either in the reserved namespace, or >> were in a whitelist of allowed names defined by the standard (such as >> "istream" and "read"). It didn't work because gcc plugins don't run >> early enough, so macros and uninstantiated templates are never seen by >> the plugin. > > > Then let's add plugin callbacks to make that possible. I've created https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70757
Re: Does gcc cilk plus support include offloading to graphics hardware?
2016-04-21 7:09 GMT+03:00 Hal Ashburner : > Another cilk plus question: > Is op_ostream also considered to be outside of cilk plus? > https://www.cilkplus.org/docs/doxygen/include-dir/group___reducers_ostream.html > I am trying to compile the basic "Cilk Plus Tutorial Sources" code as > supplied at http://cilkplus.org/download > reducer-ostream-demo.cpp, reducer-string-demo.cpp and > reducer-wstring-demo.cpp I am unable to get to compile. The tutorial samples require the latest Cilk runtime (not in GCC yet). The new runtime will be merged into mainline soon. -- Ilya
Is MODES_TIEABLE_P transitive?
As I start to allow integer modes into vector registers, I need to revisit MODES_TIEABLE_P. I'm wondering if MODES_TIEABLE_P is transitive? For example, with the current Power8 system 1) Anything can go in GPRs 2) Currently, SFmode/DFmode/KFmode, and vectors can go in VSX registers (the first 32 are overlaid on top of the traditional floating point registers, and the remaining 32 are overload on top of the traditional Altivec registers). 3) At the moment, DImode can only go in the traditional floating point registers, but I have patches to allow it in the traditional Altivec registers as well. 4) The decimal types and the IBM extended double (SDmode, DDmode, TDmode, and IFmode/TFmode) can only go in the traditional floating point registers, and not the Altivec registers. In addition, for the 128-bit types (TDmode, IFmode, TFmode) take two registers and not one, even though the VSX registers are now 128-bits. 5) The current machines have the ability to load SImode into VSX registers and store them. However, GCC has never allowed SImode in the floating point or vector registers. Where we use it in the context of conversion to/from floating point, we wrap in UNSPECs to hide the usage. 6) The next machine will have the ability to load and store 8/16-bit values (QImode/HImode) to/from VSX registers. What I'd like to do, in a Power8 context, is to allow these to return true (after allowing SImode to go in VSX registers): MODES_TIEABLE_P (SImode, DFmode) MODES_TIEABLE_P (SImode, QImode) but, the following would return false for power8: MODES_TIEABLE_P (QImode, DFmode) In a power9 context, since there are loads/stores of 8/16-bit items it would return true. If it matters, we would be switching to LRA in the GCC 7.0 time frame once PR 69847 is fixed (this is the spec 2006 403.gcc benchmark that slows down because LRA is generating unnecessary address reloads because it doesn't use LEGITIMIZE_RELOAD_ADDRESS. So the question is whether we might need to support MODES_TIEABLE_P being transitive (i.e. it would return true a lot less of the time). I would prefer to not have to worry about odd corner cases where another type is tieable with one of the arguments, but not tieable with the other. And does it matter whether we are using RELOAD or IRA? Thanks in advance. -- Michael Meissner, IBM IBM, M/S 2506R, 550 King Street, Littleton, MA 01460-6245, USA email: meiss...@linux.vnet.ibm.com, phone: +1 (978) 899-4797
Re: Does gcc cilk plus support include offloading to graphics hardware?
That basic tutorial code was last updated 3 years ago. I think we've established pretty clearly that gcc does _not_ have full support of what intel calls cilk plus. Offload not supported, and the 3 year old basic introductory tutorial code from the cilkplus.org website doesn't compile. I'm likely to be suspicious of gcc's claims of support of cilk plus in the future. Thank you very much for your help, Ilya I appreciate it. It's good to find these things out as early as possible. On 22 April 2016 at 05:31, Ilya Verbin wrote: > 2016-04-21 7:09 GMT+03:00 Hal Ashburner : >> Another cilk plus question: >> Is op_ostream also considered to be outside of cilk plus? >> https://www.cilkplus.org/docs/doxygen/include-dir/group___reducers_ostream.html >> I am trying to compile the basic "Cilk Plus Tutorial Sources" code as >> supplied at http://cilkplus.org/download >> reducer-ostream-demo.cpp, reducer-string-demo.cpp and >> reducer-wstring-demo.cpp I am unable to get to compile. > > The tutorial samples require the latest Cilk runtime (not in GCC yet). > The new runtime will be merged into mainline soon. > > -- Ilya
gcc-6-20160421 is now available
Snapshot gcc-6-20160421 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160421/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 235353 You'll find: gcc-6-20160421.tar.bz2 Complete GCC MD5=80d0ebf7851708b80210b61a0cb27878 SHA1=f605072960486536b2159f4d691a6687b102705f Diffs from 6-20160410 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: Looking for some help with GCC 6 and bad code generation
This is kind of stream-of-conciousness but I swear there's an
interesting new bit about 8 paragraphs down. :)
On 04/20/2016 07:18 PM, Andrew Pinski wrote:
> On Thu, Apr 21, 2016 at 9:11 AM, Zan Lynx wrote:
>> > I would like someone to look at this and tell me this is an already
>> > fixed bug. Or that recent GCC patches may have fixed it. :-)
>> >
>> > Or it would also be great to get some advice on building a reproducer
>> > without needing to include many megabytes of proprietary code plus Boost.
>> >
>> > I've been using Fedora 24 Alpha and of course I've somehow managed to
>> > write some C++ code even more confusing for GCC than Firefox. Heh.
>> >
>> > The problem is a crash when std::string tries to free memory from a
>> > temporary std::string that was bound to a const reference.
>> >
>> > And it only crashes when I pass -O2 or -O3 and the -fprofile-generate
>> > flags.
>
> What is the return type of URLDatabaseReader_1::identifier() ?
> Also does -fsanitize=undefined say anything about your code?
The -fsanitize=undefined run is pretty interesting.
The debug build test runs fine, with only some expected unaligned access
messages (due to reading 8 byte values from a memory map, where they
were put on 4 byte boundaries a long time ago by 32-bit code and can't
be moved)
However, when I skip the profile guided build step (which is the part
that crashes) and go to release, I get a sanitize runtime failure at
that same Delete1 test function that crashes in profiling. It is an
unreachable code error. Which it seems to jump to in a virtual function
dispatch to the "lookup" function of URLDatabaseLookup.
So sanitize is somehow jumping through the virtual table to an
unreachable code marker.
It is a fairly complicated virtual function override with multiple
virtual inheritance and templated parent classes to assemble it. I
believe this is sometimes called a "mixin" pattern. Which is part of why
making a nice test case is being so difficult.
But it has always worked in the past. This isn't new code, it has been
in use since 2008.
And an interesting, possibly the same problem, is that when I skip
profile-generate and go straight to my release build WITHOUT ubsan GCC
is simply removing all the code from the time I call url_lookup to the
end of the test function. And then crashing in the exception unwinder.
It's WEIRD though. If I add a std::cout << "Test output" to the
url_lookup function then it WORKS.
It almost has to be some interaction of inlining, virtual functions and
devirtualization.
And YES if I change -O3 to -O3 -fno-devirtualize then it WORKS again.
So somehow when it devirtualizes the call to an inlined virtual
function, that function disappears. Somehow.
Maybe I can build a simplified reproducer with this hint...
Here's a snip of the implementation class
> class
> URLDatabaseReader_1 :
> protected virtual URLDatabaseStorage,
> public URLDatabaseReaderCommon,
> public URLDatabaseLookup IPLookupTableNull, IPLookupTableNull>,
> public virtual URLDatabaseReader
> {
And a snip of the interface class:
> class
> DLLEXPORT
> URLDatabaseReader
> {
> public:
> virtual uint32_t lookup(const char *url) const = 0;
> virtual uint32_t lookup(const char *url, url_options &url_flags) const =
> 0;
> virtual uint32_t lookup(
> const comp_list_type &domain_parts,
> const comp_list_type &path_parts,
> const comp_list_type &query_parts,
> url_options &url_flags
> ) const = 0;
And a snip of the class that does the lookups:
> template class IPv6LookupTable>
> class URLDatabaseLookup :
> protected virtual URLDatabaseStorage,
> public virtual URLDatabaseReader
> {
> public:
> uint32_t lookup(const char *url) const
> {
> url_options url_flags = URL_NONE;
> return lookup(url, url_flags);
> }
> uint32_t lookup(
> const char *url,
> url_options &url_flags
> ) const;
And then there's the whole Writer side which goes into a ReaderWriter
> class
> DLLEXPORT
> URLDatabaseReaderWriter
> : public virtual URLDatabaseWriter,
> public virtual URLDatabaseReader
> {
signature.asc
Description: OpenPGP digital signature
