[Bug target/54121] ICE at extract_insn, at recog.c:2123 sparc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54121 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson 2012-07-30 07:28:19 UTC --- I can reproduce the ICE with gcc 4.8-20120729 and 4.7-20120728, but not with 4.6-20120727, on sparc64-linux.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #70 from rguenther at suse dot de 2012-07-30 08:43:09 UTC --- On Sat, 28 Jul 2012, mikael at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 > > --- Comment #69 from Mikael Morin 2012-07-28 > 09:46:00 UTC --- > (In reply to comment #63) > > With a (seemingly) unrelated patch (attached to PR52097) I'm back on ICEing > > for the gfortran.dg/lto/pr45586*.f90 testcases ... > > > > Even before the adjusted type merging we have (at compile-time) > > > [...] > > > > _BUT_(!) its main-variant is > > > [...] > > > > thus has a restrict-qualified data field. That's bogus as TYPE_FIELDS > > is supposed to be shared amongst variant types. > > So, is this a fortran front-end bug, a middle-end bug, or a lto bug ? > (Hint: PR 51765 is a marked as a lto bug ;-) ) It's a frontend bug.
[Bug tree-optimization/53773] Vectorizer generates non-canonical multiplies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53773 --- Comment #6 from rguenther at suse dot de 2012-07-30 08:47:35 UTC --- On Sun, 29 Jul 2012, wschmidt at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53773 > > William J. Schmidt changed: > >What|Removed |Added > > AssignedTo|unassigned at gcc dot |wschmidt at gcc dot gnu.org >|gnu.org | >Target Milestone|--- |4.8.0 > > --- Comment #5 from William J. Schmidt > 2012-07-29 16:54:45 UTC --- > I'll take this one. > > I think the assumption of operand placement is too embedded to tease out > easily, so I'm going to approach this by re-canonicalizing PLUS_EXPR, > POINTER_PLUS_EXPR, and MULT_EXPR when operand swapping has occurred. Are > there > other tree codes that could be broken? I don't think so
[Bug middle-end/54123] inline functions not optimized as well as static inline
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54123 Richard Guenther changed: What|Removed |Added Keywords||missed-optimization Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-30 CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #3 from Richard Guenther 2012-07-30 09:05:25 UTC --- Confirmed. inline and static inline should be the same with C99. Honza - I suppose inlining static functions called once may be the reason this doesn't work with plain 'inline'. I guess we need a better predicate here? inline functions called once whose bodies can be removed?
[Bug pch/54117] [4.8 Regression] FAIL: ./decl-3.h -O0 -g (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54117 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug middle-end/54114] [4.8 Regression] variable-tracking performance regression from 4.8-20120610 to 4.8-20120701
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54114 Richard Guenther changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-07-30 Version|unknown |4.8.0 Target Milestone|--- |4.8.0 Summary|variable-tracking |[4.8 Regression] |performance regression from |variable-tracking |4.8-20120610 to |performance regression from |4.8-20120701|4.8-20120610 to ||4.8-20120701 Ever Confirmed|0 |1 --- Comment #2 from Richard Guenther 2012-07-30 09:11:00 UTC --- Please attach preprocessed source.
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 Steven Bosscher changed: What|Removed |Added Status|NEW |WAITING --- Comment #21 from Steven Bosscher 2012-07-30 09:11:27 UTC --- Markus, I think that r189951 should have fixed this problem (xf. http://gcc.gnu.org/viewcvs?view=revision&revision=189951), although I suspect there will still be a compile time increase from GCC 4.7 to GCC 4.8 because of the macro expansion tracking stuff. Could you please try a recent trunk GCC 4.8 and report back how compile times look for you now?
[Bug middle-end/47353] superfluous alignment after dynamic stack allocation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47353 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Eric Botcazou 2012-07-30 09:33:36 UTC --- . *** This bug has been marked as a duplicate of bug 34548 ***
[Bug middle-end/34548] GCC generates too many alignment adds for alloca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34548 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #3 from Eric Botcazou 2012-07-30 09:33:36 UTC --- *** Bug 47353 has been marked as a duplicate of this bug. ***
[Bug middle-end/34548] GCC generates too many alignment adds for alloca
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34548 Eric Botcazou changed: What|Removed |Added CC||ebotcazou at gcc dot ||gnu.org --- Comment #3 from Eric Botcazou 2012-07-30 09:33:36 UTC --- *** Bug 47353 has been marked as a duplicate of this bug. *** --- Comment #4 from Eric Botcazou 2012-07-30 09:35:16 UTC --- Possibly useful link: http://gcc.gnu.org/ml/gcc-patches/2011-01/msg00842.html
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #71 from Mikael Morin 2012-07-30 10:35:48 UTC --- (In reply to comment #70) > On Sat, 28 Jul 2012, mikael at gcc dot gnu.org wrote: > > So, is this a fortran front-end bug, a middle-end bug, or a lto bug ? > > (Hint: PR 51765 is a marked as a lto bug ;-) ) > > It's a frontend bug. great :-(. (In reply to comment #63) > That's bogus as TYPE_FIELDS > is supposed to be shared amongst variant types. Then we'll have to revert Micha's recursive restrict work. Is it possible for the front-end to specify alias sets by hand (I mean without relying on the middle-end computing them based on types etc)?
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 --- Comment #22 from Markus Trippelsdorf 2012-07-30 10:54:35 UTC --- (In reply to comment #21) > Markus, I think that r189951 should have fixed this problem (xf. > http://gcc.gnu.org/viewcvs?view=revision&revision=189951), although I suspect > there will still be a compile time increase from GCC 4.7 to GCC 4.8 because of > the macro expansion tracking stuff. Could you please try a recent trunk GCC > 4.8 > and report back how compile times look for you now? gcc version 4.8.0 20120730 (experimental) (GCC) markus@x4 tmp % time c++ -c -o pch.hpp.gch /usr/include/boost/math/special_functions.hpp c++ -c -o pch.hpp.gch /usr/include/boost/math/special_functions.hpp 138.60s user 0.38s system 99% cpu 2:19.87 total Still a 98% compile time regression on todays trunk.
[Bug target/53975] [ia64] Target register of a speculative load moved to a branch register prior to the chk.s instruction
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53975 Andrey Belevantsev changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #17 from Andrey Belevantsev 2012-07-30 11:01:35 UTC --- I'm testing the revert of the below patch with a clarified comment.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #72 from rguenther at suse dot de 2012-07-30 11:04:39 UTC --- On Mon, 30 Jul 2012, mikael at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 > > --- Comment #71 from Mikael Morin 2012-07-30 > 10:35:48 UTC --- > (In reply to comment #70) > > On Sat, 28 Jul 2012, mikael at gcc dot gnu.org wrote: > > > So, is this a fortran front-end bug, a middle-end bug, or a lto bug ? > > > (Hint: PR 51765 is a marked as a lto bug ;-) ) > > > > It's a frontend bug. > > great :-(. > > > (In reply to comment #63) > > That's bogus as TYPE_FIELDS > > is supposed to be shared amongst variant types. > > Then we'll have to revert Micha's recursive restrict work. I don't think so, it merely has to be fixed. > Is it possible for the front-end to specify alias sets by hand (I mean without > relying on the middle-end computing them based on types etc)? Yes. But that does not work with LTO, nor does it address the original issue of supporting INTENT IN/OUT properly.
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 --- Comment #23 from Steven Bosscher 2012-07-30 11:08:01 UTC --- (In reply to comment #22) > Still a 98% compile time regression on todays trunk. What revision number is this? If it includes r189951, could you please see if you can get an updated profile (similar to the one in comment #3)?
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
--- Comment #24 from Markus Trippelsdorf
2012-07-30 11:21:54 UTC ---
(In reply to comment #23)
> (In reply to comment #22)
> > Still a 98% compile time regression on todays trunk.
>
> What revision number is this? If it includes r189951, could you please see if
> you can get an updated profile (similar to the one in comment #3)?
I'm running revision 189954.
# Samples: 557K of event 'cycles'
# Event count (approx.): 448107030198
#
# Overhead Command Shared Object Symbol
97.54% cc1plus cc1plus[.] gt_pch_p_9line_maps
0.12% cc1plus cc1plus[.] htab_find_slot_with_hash
0.10% cc1plus libc-2.16.90.so[.] memcpy@@GLIBC_2.14
0.10% cc1plus cc1plus[.] htab_expand
0.09% cc1plus libc-2.16.90.so[.] malloc_consolidate
0.08% cc1plus cc1plus[.] htab_find_with_hash
0.08% cc1plus libc-2.16.90.so[.] msort_with_tmp.part.0
Zoom into gt_pch_p_9line_maps:
│ if ((*x).info_macro.maps != NULL) {
│ size_t i2;
│ for (i2 = 0; i2 != (size_t)(l2); i2++) {
4.10 │109: cmp%rcx,%rbx
3.86 │ nop
3.22 │ ↓ je 188
3.26 │112: mov0x18(%rbp),%rax
3.21 │ add$0x1,%rbx
│ break;
│ }
│ }
│
│ void
│ gt_pch_p_9line_maps (ATTRIBUTE_UNUSED void *this_obj,
2.94 │11a: lea(%rbx,%rbx,4),%r15
3.69 │ shl$0x3,%r15
│ {
│ size_t l2 = (size_t)(((*x).info_macro).used);
│ if ((*x).info_macro.maps != NULL) {
│ size_t i2;
│ for (i2 = 0; i2 != (size_t)(l2); i2++) {
│ switch (((*x).info_macro.maps[i2]).reason ==
LC_ENTER_MACRO)
3.58 │ lea(%rax,%r15,1),%rdi
3.59 │ cmpb $0x4,0x4(%rdi)
4.26 │ ↑ jne100
│ op (&((*x).info_macro.maps[i2].d.ordinary.to_file),
cookie);
│ break;
│ case 1:
│ {
│ union tree_node * x3 =
│ ((*x).info_macro.maps[i2].d.macro.macro) ?
HT_IDENT_TO_GCC_IDENT (HT_NODE (((*x).info_macro.maps[i2].d.macro.macro))) :
4.18 │ mov0x8(%rdi),%rsi
4.07 │ xor%edx,%edx
2.28 │ lea-0x18(%rsi),%r8
2.28 │ test %rsi,%rsi
2.70 │ cmovne %r8,%rdx
│ if ((void *)((*x).info_macro.maps) == this_obj)
2.69 │ cmp%rax,%r14
│ if ((void *)((*x).info_macro.maps) == this_obj)
│ op (&((*x).info_macro.maps[i2].d.ordinary.to_file),
cookie);
│ break;
│ case 1:
│ {
│ union tree_node * x3 =
2.55 │ mov%rdx,0x18(%rsp)
│ ((*x).info_macro.maps[i2].d.macro.macro) ?
HT_IDENT_TO_GCC_IDENT (HT_NODE (((*x).info_macro.maps[i2].d.macro.macro))) :
│ if ((void *)((*x).info_macro.maps) == this_obj)
2.82 │ ↓ je 1a0
│ op (&(x3), cookie);
│ (*x).info_macro.maps[i2].d.macro.macro = (x3) ?
CPP_HASHNODE (GCC_IDENT_TO_HT_IDENT ((x3))) : NULL;
2.80 │147: lea0x18(%rdx),%rsi
3.00 │ xor%eax,%eax
3.28 │ test %rdx,%rdx
3.11 │ cmovne %rsi,%rax
3.15 │ mov%rax,0x8(%rdi)
│ }
│ if ((*x).info_macro.maps[i2].d.macro.macro_locations
!= NULL) {
4.51 │ mov0x18(%rbp),%rax
4.45 │ add%rax,%r15
4.94 │ cmpq $0x0,0x18(%r15)
3.74 │ ↑ je 109
│ if ((void *)((*x).info_macro.maps) == this_obj)
3.16 │ cmp%rax,%r14
3.03 │ ↑ jne109
│ op
(&((*x).info_macro.maps[i2].d.macro.macro_locations), cookie);
│ mov%rcx,0x8(%rsp)
0.00 │ lea0x18(%r15),%rdi
│ mov%r13,%rsi
│ → callq *%r12
0.00 │ mov0x8(%rsp),%rcx
│ }
[Bug target/29776] result of ffs/clz/ctz/popcount/parity are already sign-extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
--- Comment #4 from Uros Bizjak 2012-07-30 11:36:23
UTC ---
> Perhaps REE can be taught about ctz giving a non-negative result.
Maybe we need some VRP pass to remove these extensions. Please note an example
from (duplicate) PR54115, where we generate:
#include
uint64_t foo(long x){
return __builtin_ctzl(x);
}
foo:
bsfq %rdi, %rax
cltq
this is DImode -> DImode operation, followed by sign-extend from SImode partial
reg.
Your examples in comment #3:
bsfl %esi, %esi
movslq %esi, %rsi
can be "fixed" by slapping any_extend:DI to CTZ pattern, to consume either
ZERO_EXTEND or SIGN_EXTEND of the value (it doesn't matter for ranges [0..(some
small number)]).
The DImode example above can be "fixed" by adding SUBREG to all patterns. But,
I think that there is more optimal implementation than exploding the number of
bit manipulating patterns.
[Bug web/54124] Web-based GCC 4.7.1 manual: -dM and similar options hard to find
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54124 --- Comment #5 from Jonathan Wakely 2012-07-30 11:37:18 UTC --- That section is formatted the same in HTML and the info pages. If you go to the options summary at http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Option-Summary.html you can search for -dM (or "preprocessor") and find it in the relevant section, which takes you to http://gcc.gnu.org/onlinedocs/gcc-4.7.1/gcc/Preprocessor-Options.html
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 Steven Bosscher changed: What|Removed |Added Status|WAITING |NEW Known to work||4.7.1 Known to fail||4.8.0 --- Comment #25 from Steven Bosscher 2012-07-30 12:03:25 UTC --- AFAICT, the only way that gt_pch_p_9line_maps can be called, is from ggc-common.c:gt_pch_save (via note_ptr_fn). The "op" argument will be relocate_ptrs, so all calls are for pointer-rewriting and there are so many of them simply because the linemaps structure is so big if we're tracking macro expansions on a library as big as Boost. It looks like this is the only note_ptr_fn callback left (if there were any others to begin with) so a first simple speed-up could be to rip out this callback stuff and just call relocate_ptrs directly. That would eliminate millions of costly indirect calls. Even better would be to reduce the size of line_maps, but I don't see how.
[Bug middle-end/54114] [4.8 Regression] variable-tracking performance regression from 4.8-20120610 to 4.8-20120701
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54114 --- Comment #3 from jimis 2012-07-30 12:18:49 UTC --- Created attachment 27894 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27894 XPatch.cpp preprocessed source from xalanc Hi thanks for your patience, I resurrected my PC so now I have access to my files, and the webinterface is up for anyone caring to see the function breakdown (just check footnote [6] in front page). Attached is the preprocessed source, I compile with $CC1PLUS -quiet -D_GNU_SOURCE -D LINUX -D _REENTRANT -D XALAN_INMEM_MSG_LOADER XPath.ii -g -O2 -fno-elide-constructors -fPIC -o /dev/null
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #73 from Mikael Morin 2012-07-30 12:29:33 UTC --- (In reply to comment #72) > > (In reply to comment #63) > > > That's bogus as TYPE_FIELDS > > > is supposed to be shared amongst variant types. > > > > Then we'll have to revert Micha's recursive restrict work. > > I don't think so, it merely has to be fixed. How so? by making it non-recursive? For variable to be type compatible for assignment, they shall be variants of the same type, and thus have the same TYPE_FIELDS. If they shall have the same TYPE_FIELDS, they shall have the same components, the same components have the same types, so that one cannot be restrict qualified. > > > Is it possible for the front-end to specify alias sets by hand (I mean > > without > > relying on the middle-end computing them based on types etc)? > > Yes. But that does not work with LTO, You mean calling the front-end's code does not work at LTO time or the alias sets are not saved/restored for LTO? > nor does it address the original > issue of supporting INTENT IN/OUT properly. Ah? Isn't a restricted type variable (resp. component, etc) merely one that has its own alias set? So if it works with restrict, it works with alias sets?
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #74 from rguenther at suse dot de 2012-07-30 12:33:01 UTC --- On Mon, 30 Jul 2012, mikael at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 > > --- Comment #73 from Mikael Morin 2012-07-30 > 12:29:33 UTC --- > (In reply to comment #72) > > > (In reply to comment #63) > > > > That's bogus as TYPE_FIELDS > > > > is supposed to be shared amongst variant types. > > > > > > Then we'll have to revert Micha's recursive restrict work. > > > > I don't think so, it merely has to be fixed. > How so? by making it non-recursive? > For variable to be type compatible for assignment, they shall be variants of > the same type, and thus have the same TYPE_FIELDS. > If they shall have the same TYPE_FIELDS, they shall have the same components, > the same components have the same types, so that one cannot be restrict > qualified. The types should not be variant types ;) (see my hack patch in this or another bug) > > > Is it possible for the front-end to specify alias sets by hand (I mean > > > without > > > relying on the middle-end computing them based on types etc)? > > > > Yes. But that does not work with LTO, > You mean calling the front-end's code does not work at LTO time or the alias > sets are not saved/restored for LTO? LTO re-computes alias-sets based on types. > > nor does it address the original > > issue of supporting INTENT IN/OUT properly. > Ah? Isn't a restricted type variable (resp. component, etc) merely one that > has > its own alias set? So if it works with restrict, it works with alias sets? No, alias-sets and restrict are different beasts. It's important to have the data member restrict qualified for INTENT IN/OUT.
[Bug target/29776] result of ffs/clz/ctz/popcount/parity are already sign-extended
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29776
--- Comment #5 from Uros Bizjak 2012-07-30 12:48:19
UTC ---
Created attachment 27895
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27895
Target patch that handles ctz extensions
x86 target patch that teaches gcc about extensions for ctz.
Patched gcc generates no extension for:
long long foo (int x) { return __builtin_ctz (x); }
and
int foo (long long x) { return __builtin_ctzll (x); }
(and their unsigned variants) on x86.
[Bug ada/54125] New: [4.8 regression] s-atopri.adb:40:10: "Support_Atomic_Primitives" is undefined broke Ada on sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54125 Bug #: 54125 Summary: [4.8 regression] s-atopri.adb:40:10: "Support_Atomic_Primitives" is undefined broke Ada on sparc64-linux Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassig...@gcc.gnu.org ReportedBy: mi...@it.uu.se Attempting to bootstrap gcc-4.8-20120729 on sparc64-linux with Ada enabled fails with: /mnt/scratch/objdir48/./gcc/xgcc -B/mnt/scratch/objdir48/./gcc/ -B/mnt/scratch/install48/sparc64-unknown-linux-gnu/bin/ -B/mnt/scratch/install48/sparc64-unknown-linux-gnu/lib/ -isystem /mnt/scratch/install48/sparc64-unknown-linux-gnu/include -isystem /mnt/scratch/install48/sparc64-unknown-linux-gnu/sys-include-c -g -O2 -m64 -fPIC -W -Wall -gnatpg -nostdinc -m64 s-atopri.adb -o s-atopri.o s-atopri.adb:40:10: "Support_Atomic_Primitives" is undefined (more references follow) make[9]: *** [s-atopri.o] Error 1 make[9]: *** Waiting for unfinished jobs make[9]: Leaving directory `/mnt/scratch/objdir48/gcc/ada/rts_64' make[8]: *** [gnatlib] Error 2 make[8]: Leaving directory `/mnt/scratch/objdir48/gcc/ada' make[7]: *** [gnatlib-shared-default] Error 2 make[7]: Leaving directory `/mnt/scratch/objdir48/gcc/ada' make[6]: *** [gnatlib-shared-dual] Error 2 make[6]: Leaving directory `/mnt/scratch/objdir48/gcc/ada' make[5]: *** [gnatlib-shared] Error 2 make[5]: Leaving directory `/mnt/scratch/objdir48/gcc/ada' make[4]: *** [gnatlib-shared] Error 2 make[4]: Leaving directory `/mnt/scratch/objdir48/sparc64-unknown-linux-gnu/64/libada' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/mnt/scratch/objdir48/sparc64-unknown-linux-gnu/libada' make[2]: *** [all] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir48/sparc64-unknown-linux-gnu/libada' make[1]: *** [all-target-libada] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir48' make: *** [bootstrap] Error 2 The previous weekly snapshot, 4.8-20120722, bootstrapped fine on this machine with the same configuration options.
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 --- Comment #26 from Steven Bosscher 2012-07-30 13:17:25 UTC --- FWIW, the resulting PCH for GCC 4.8 is more than twice as large as the PCH for GCC 4.7.
[Bug middle-end/53823] [4.8 Regression] FAIL: gcc.c-torture/execute/930921-1.c execution at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53823 Richard Henderson changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-30 Ever Confirmed|0 |1 --- Comment #5 from Richard Henderson 2012-07-30 13:31:15 UTC --- That patch is obviously correct.
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880
--- Comment #27 from Steven Bosscher 2012-07-30
13:51:58 UTC ---
The problem is the quadratic behavior invoked by the loop in
gt_pch_nx_line_maps:
{
size_t l2 = (size_t)(((*x).info_macro).used);
if ((*x).info_macro.maps != NULL) {
size_t i2;
for (i2 = 0; i2 != (size_t)(l2); i2++) {
switch (((*x).info_macro.maps[i2]).reason == LC_ENTER_MACRO)
{
case 0:
gt_pch_n_S ((*x).info_macro.maps[i2].d.ordinary.to_file);
break;
case 1:
{
union tree_node * const x3 =
((*x).info_macro.maps[i2].d.macro.macro) ?
HT_IDENT_TO_GCC_IDENT (HT_NODE (((*x).info_macro.maps[i2].d.macro.macro))) :
NULL;
gt_pch_n_9tree_node (x3);
}
if ((*x).info_macro.maps[i2].d.macro.macro_locations != NULL) {
gt_pch_note_object
((*x).info_macro.maps[i2].d.macro.macro_locations, x, gt_pch_p_9line_maps,
gt_types_enum_last);
}
break;
default:
break;
}
}
and the loop in gt_pch_p_9line_maps:
size_t l2 = (size_t)(((*x).info_macro).used);
if ((*x).info_macro.maps != NULL) {
size_t i2;
for (i2 = 0; i2 != (size_t)(l2); i2++) {
switch (((*x).info_macro.maps[i2]).reason == LC_ENTER_MACRO)
{
case 0:
if ((void *)((*x).info_macro.maps) == this_obj)
op (&((*x).info_macro.maps[i2].d.ordinary.to_file), cookie);
break;
case 1:
{
union tree_node * x3 =
((*x).info_macro.maps[i2].d.macro.macro) ?
HT_IDENT_TO_GCC_IDENT (HT_NODE (((*x).info_macro.maps[i2].d.macro.macro))) :
NULL;
if ((void *)((*x).info_macro.maps) == this_obj)
op (&(x3), cookie);
(*x).info_macro.maps[i2].d.macro.macro = (x3) ? CPP_HASHNODE
(GCC_IDENT_TO_HT_IDENT ((x3))) : NULL;
}
if ((*x).info_macro.maps[i2].d.macro.macro_locations != NULL) {
if ((void *)((*x).info_macro.maps) == this_obj)
op (&((*x).info_macro.maps[i2].d.macro.macro_locations),
cookie);
}
break;
default:
break;
}
}
The first loop registers every line map entry to be visited for pointer
rewriting later by gt_pch_p_9line_maps:
gt_pch_note_object ((*x).info_macro.maps[i2].d.macro.macro_locations, x,
gt_pch_p_9line_maps, gt_types_enum_last);
where x==input.c:line_table, and
(*x).info_macro.maps[i2].d.macro.macro_locations is the "i2"'th entry.
The second loop is called from the loop in gt_pch_save via note_ptr_fn, which
is gt_pch_p_9line_maps:
state.ptrs[i]->note_ptr_fn (state.ptrs[i]->obj,
state.ptrs[i]->note_ptr_cookie,
relocate_ptrs, &state);
==
gt_pch_p_9line_maps((*x).info_macro.maps[i2].d.macro.macro_locations,
&line_table, relocate_ptrs, &state);
and gt_pch_p_9line_maps loops over all map elements until:
(void *)((*x).info_macro.maps) == this_obj
This causes (((*x).info_macro).used)**2 visits.
[Bug middle-end/53823] [4.8 Regression] FAIL: gcc.c-torture/execute/930921-1.c execution at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53823 Steven Bosscher changed: What|Removed |Added CC||uros at gcc dot gnu.org --- Comment #6 from Steven Bosscher 2012-07-30 14:13:04 UTC --- And this is why "uninitialized" warnings shouldn't be silenced like this... * expmed.c (expand_mult): Initialize coeff and is_neg. http://gcc.gnu.org/viewcvs?view=revision&revision=189281
[Bug ada/54125] [4.8 regression] s-atopri.adb:40:10: "Support_Atomic_Primitives" is undefined broke Ada on sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54125 Richard Guenther changed: What|Removed |Added Target Milestone|--- |4.8.0
[Bug c++/54126] New: ICE on constexpr move ctor with const ref type instead of error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54126 Bug #: 54126 Summary: ICE on constexpr move ctor with const ref type instead of error Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: minor Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: morph...@gmail.com Compiling attached source fails with ICE: $ gcc -std=c++11 gcc-bug.cpp --save-temps gcc-bug.cpp: In instantiation of 'constexpr ClassA::ClassA(U1&&) [with U1 = int; T1 = const ClassB&]': gcc-bug.cpp:34:3: required from here gcc-bug.cpp:22:12: internal compiler error: in build_data_member_initialization, at cp/semantics.c:5790 GCC version dump: $ gcc -v Using built-in specs. COLLECT_GCC=C:\MinGW\bin\gcc.exe COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/i686-w64-mingw32/4.7.2/lto-wrapp er.exe Target: i686-w64-mingw32 Configured with: ../..//mingw-src/gcc-4_7-branch/configure --host=i686-w64-mingw 32 --build=i686-w64-mingw32 --target=i686-w64-mingw32 --prefix=/mingw-gcc-4_7-br anch-x32 --with-sysroot=/mingw-gcc-4_7-branch-x32 --enable-shared --enable-stati c --enable-targets=all --enable-multilib --enable-languages=c,c++,fortran,lto -- enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-lto - -enable-graphite --enable-cloog-backend=isl --enable-checking=release --enable-f ully-dynamic-string --enable-version-specific-runtime-libs --enable-sjlj-excepti ons --disable-ppl-version-check --disable-cloog-version-check --disable-libstdcx x-pch --disable-libstdcxx-debug --disable-bootstrap --disable-rpath --disable-wi n32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-ld --wi th-tune=generic --with-host-libstdcxx='-static -lstdc++' --with-libiconv --with- gmp=/mingw-gcc-4_7-branch-libs-x32 --with-mpfr=/mingw-gcc-4_7-branch-libs-x32 -- with-mpc=/mingw-gcc-4_7-branch-libs-x32 --with-ppl=/mingw-gcc-4_7-branch-libs-x3 2 --with-cloog=/mingw-gcc-4_7-branch-libs-x32 --with-pkgversion='MinGW-builds: h ttp://sourceforge.net/projects/mingwbuilds/' --with-bugurl=http://sourceforge.ne t/projects/mingwbuilds/ CFLAGS='-O2 -pipe -fomit-frame-pointer -momit-leaf-frame -pointer -I/mingw-gcc-4_7-branch-libs-x32/include' CXXFLAGS='-O2 -pipe -fomit-fr ame-pointer -momit-leaf-frame-pointer' CPPFLAGS= LDFLAGS='-pipe -s -L/mingw-gcc- 4_7-branch-libs-x32/lib -L/mingw-gcc-4_7-branch-x32/bin' Thread model: posix gcc version 4.7.2 20120727 (prerelease) (MinGW-builds: http://sourceforge.net/pr ojects/mingwbuilds/)
[Bug c++/54126] ICE on constexpr move ctor with const ref type instead of error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54126 --- Comment #1 from Jonathan Wakely 2012-07-30 14:22:18 UTC --- The attachment is missing
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 --- Comment #28 from Steven Bosscher 2012-07-30 14:22:37 UTC --- With -ftrack-macro-expansion=2 (the default): (gdb) call dump_line_table_statistics() Number of expanded macros: 237994 Average number of tokens per macro expansion: 12 Line Table allocations during the compilation process Number of ordinary maps used: 2732 Ordinary map used size:106k Number of ordinary maps allocated:6553 Ordinary maps allocated size: 255k Number of macro maps used: 183k Macro maps used size: 7339k Macro maps locations size: 24M Macro maps size:31M Duplicated maps locations size: 5598k Total allocated maps size: 40M Total used maps size: 31M With -ftrack-macro-expansion=0: (gdb) call dump_line_table_statistics() Number of expanded macros: 233678 Average number of tokens per macro expansion: 13 Line Table allocations during the compilation process Number of ordinary maps used: 2732 Ordinary map used size:106k Number of ordinary maps allocated:6553 Ordinary maps allocated size: 255k Number of macro maps used: 0 Macro maps used size:0 Macro maps locations size: 0 Macro maps size: 0 Duplicated maps locations size: 0 Total allocated maps size: 255k Total used maps size: 106k (The count for number of tokens per macro expansion should be the same, looks like a bug...).
[Bug middle-end/53823] [4.8 Regression] FAIL: gcc.c-torture/execute/930921-1.c execution at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53823 --- Comment #7 from Uros Bizjak 2012-07-30 14:25:32 UTC --- (In reply to comment #6) > And this is why "uninitialized" warnings shouldn't be silenced like this... > > * expmed.c (expand_mult): Initialize coeff and is_neg. > > http://gcc.gnu.org/viewcvs?view=revision&revision=189281 Sure, considering that following is way better: # These files are to have specific diagnostics suppressed, or are not to # be subject to -Werror: # flex output may yield harmless "no previous prototype" warnings build/gengtype-lex.o-warn = -Wno-error gengtype-lex.o-warn = -Wno-error expmed.o-warn = -Wno-error
[Bug ada/54125] [4.8 regression] s-atopri.adb:40:10: "Support_Atomic_Primitives" is undefined broke Ada on sparc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54125 Arnaud Charlet changed: What|Removed |Added CC||charlet at gcc dot gnu.org AssignedTo|unassigned at gcc dot |charlet at gcc dot gnu.org |gnu.org | --- Comment #1 from Arnaud Charlet 2012-07-30 14:31:54 UTC --- Will take care of it
[Bug c++/54126] ICE on constexpr move ctor with const ref type instead of error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54126 --- Comment #2 from Ilya Mikhaltsou 2012-07-30 14:33:41 UTC --- Created attachment 27896 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27896 Preprocessed source
[Bug rtl-optimization/54127] New: [4.7] ICE in maybe_record_trace_start with asm goto, --target=powerpc-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54127 Bug #: 54127 Summary: [4.7] ICE in maybe_record_trace_start with asm goto, --target=powerpc-unknown-linux-gnu Classification: Unclassified Product: gcc Version: 4.7.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: sim...@google.com gcc.dg/torture/pr53589.c fails in gcc-4_7-branch at r189949 with --target=powerpc-unknown-linux-gnu. I haven't yet checked 4.8. Repro, using a cross-gcc hosted on x86_64: configure \ --enable-languages=c \ --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu \ --target=powerpc-unknown-linux-gnu make -j6 all-gcc make RUNTESTFLAGS='dg-torture.exp=pr53589.c' check-gcc ... FAIL: gcc.dg/torture/pr53589.c -O3 -g (internal compiler error) ... .../gcc/testsuite/gcc.dg/torture/pr53589.c: In function 'bar': .../gcc/testsuite/gcc.dg/torture/pr53589.c:15:1: internal compiler error: in maybe_record_trace_start, at dwarf2cfi.c:2197
[Bug c++/54126] ICE on constexpr move ctor with const ref type instead of error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54126 Jonathan Wakely changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-30 Ever Confirmed|0 |1
[Bug c++/54126] ICE on constexpr move ctor with const ref type instead of error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54126
--- Comment #3 from Ilya Mikhaltsou 2012-07-30
14:56:31 UTC ---
Reduced source:
namespace std {
template class initializer_list {
};
}
using namespace std;
class ClassB {
public:
constexpr ClassB(int x) {}
};
template struct ClassA {
template constexpr ClassA(U1 &&a)
: a_(a) {}
T1 a_;
};
void f(std::initializer_list> l) {
f({
{1}
});
}
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 --- Comment #29 from Steven Bosscher 2012-07-30 15:04:18 UTC --- Created attachment 27897 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27897 Unswitched gtype-desc.c at r189965 Manually "unswitching" gt_pch_p_9line_maps gives me acceptable compile times.
[Bug middle-end/53823] [4.8 Regression] FAIL: gcc.c-torture/execute/930921-1.c execution at -O0 and -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53823 --- Comment #8 from John David Anglin 2012-07-30 15:46:13 UTC --- Author: danglin Date: Mon Jul 30 15:46:08 2012 New Revision: 189980 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189980 Log: PR middle-end/53823 * expmed.c (expand_mult): Skip synth_mult for constant double op1 except for special cases. Don't initialize coeff and is_neg. Modified: trunk/gcc/ChangeLog trunk/gcc/expmed.c
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 --- Comment #30 from Steven Bosscher 2012-07-30 16:15:35 UTC --- Created attachment 27898 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27898 Hack to avoid quadratic loops This makes use of the assumption that this_obj and its comparison companion are loop invariant (they have to be for pointer rewriting). Drops compile time to worse-than-gcc47-but-acceptable levels. Markus, could you give this a try, please?
[Bug bootstrap/54128] New: GCC does not bootstrap on little endian mips due to mis-compare on tree-data-ref.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54128 Bug #: 54128 Summary: GCC does not bootstrap on little endian mips due to mis-compare on tree-data-ref.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassig...@gcc.gnu.org ReportedBy: s...@gcc.gnu.org A bootstrap using the latest GCC fails on a little endian MIPS system due to a compare failure. make[3]: Leaving directory `/home2/sje/gcc_native/obj-native/gcc' Comparing stages 2 and 3 warning: gcc/cc1plus-checksum.o differs warning: gcc/cc1-checksum.o differs Bootstrap comparison failure! gcc/tree-data-ref.o differs make[2]: *** [compare] Error 1 It looks like someone else saw this on a debian box and submitted a debian bug, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=634881, but their fix was to workaround it by using -gtoggle for both the stage 2 and stage 3 builds. It is -gtoggle that is causing the difference. Comparing the two objects I see a small code gen difference in "analyze_subscript_affine". I have attached the preprocessed version of that source file to this bug report. Compiling it with C++ and "-g -O2 -fno-exceptions -fno-rtti -fno-common" in one case and adding -gtoggle in the second case should show the codegen difference. You may need -EL if using a mips GCC that does not generated little-endian by default.
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 --- Comment #31 from Markus Trippelsdorf 2012-07-30 16:26:23 UTC --- (In reply to comment #30) > Created attachment 27898 [details] > Hack to avoid quadratic loops > > This makes use of the assumption that this_obj and its comparison companion > are > loop invariant (they have to be for pointer rewriting). Drops compile time to > worse-than-gcc47-but-acceptable levels. > > Markus, could you give this a try, please? Looks very good: % time c++ -c -o pch.hpp.gch /usr/include/boost/math/special_functions.hpp c++ -c -o pch.hpp.gch /usr/include/boost/math/special_functions.hpp 2.67s user 0.20s system 99% cpu 2.888 total Thanks a lot, Steven.
[Bug testsuite/53664] neon-testgen.ml generates duplicate scan-assembler directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664 --- Comment #4 from Ramana Radhakrishnan 2012-07-30 18:30:40 UTC --- (In reply to comment #0) > Tests gcc/testsuite/gcc.target/arm/neon/v*.c are generated by the script > gcc/config/arm/neon-testgen.ml. 54 of these tests have duplicate > scan-assembler test directives, leading to duplicate lines in the test summary > file. The test generator is an O'Caml program. > > I'm hoping that someone who knows that language will kindly take a look at > this > bug, fix it, and regenerate the tests. I took a quick peek , it's a bit of work to get this done - the problem really is in the way in which we are generating with emit_epilogue - would be nice if one could get a hold of VecArray at this point of time and generate scan-assembler-times the arity I don't do enough ML to deal with it right now. Ramana
[Bug testsuite/53664] neon-testgen.ml generates duplicate scan-assembler directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664 --- Comment #5 from Janis Johnson 2012-07-30 18:34:50 UTC --- Thanks for looking, Ramana. I noticed in my investigation that the search string needs to be different for scan-assembler-times than for scan-assembler, since the regular expression handling seems to be different.
[Bug c/54129] New: __thread variables and pthread_*specific data destroyed in different order on Darwin than Linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54129 Bug #: 54129 Summary: __thread variables and pthread_*specific data destroyed in different order on Darwin than Linux Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: blu...@gmail.com Created attachment 27899 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27899 A test program that shows the behavior. I have written a short program that works on Linux but does not work on Mac OSX. The program uses __thread variables, which I understand are emulated on Darwin. The program also uses pthread_key_create(..., thread_destructor) to register the function thread_destructor() to run when threads end. I have attached a test program that works on Linux and does not work on OS X. thread_destructor() accesses the __thread variables. It looks like what is happening is the __thread variables are being zeroed before thread_destructor() is running. Some of those __thread variables are pointers, leading to segfaults when thread_destructor dereferences them. This may not be a bug. I have not read the relevant parts of the language specification. It may be undefined to mix pthread_setspecific and __thread. I may be using some library functions wrong. However, it is definitely the case that the behavior on Darwin is different from the behavior on Linux. Note that this simple program is not the only place I've seen this. I am building a debugging/monitoring runtime system that makes heavy use of these facilities and it first experienced the problem. The attached program is (pretty much) minimal to manifest the problem. Program compiled with: gcc -std=c99 ./TLSBug.c -o TLSBug Output of test program on Mac OS X 10.6: redoldfence:MacTLSBugTest blucia0a$ ./TLSBug Thread says foo == 0x100200130 Thread says *foo == 17 0123456789 Thread Destructor Called Thread says foo == 0x0 Segmentation fault Output of test program on Linux: blucia@pango:~$ ./TLSBug Thread says foo == 0x2564160 Thread says *foo == 17 0123456789 Thread Destructor Called Thread says foo == 0x2564160 Thread says *foo == 17
[Bug fortran/51081] [F03] Proc-pointer assignment: Rejects valid internal proc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51081 --- Comment #11 from janus at gcc dot gnu.org 2012-07-30 19:55:45 UTC --- Author: janus Date: Mon Jul 30 19:55:41 2012 New Revision: 189985 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=189985 Log: 2012-07-30 Janus Weil PR fortran/51081 * gfortran.h (gfc_resolve_intrinsic): Add prototype. * expr.c (gfc_check_pointer_assign): Set INTRINSIC attribute if needed. Check for invalid intrinsics. * primary.c (gfc_match_rvalue): Check for intrinsics came too early. Set procedure flavor if appropriate. * resolve.c (resolve_intrinsic): Renamed to gfc_resolve_intrinsic. (resolve_procedure_interface,resolve_procedure_expression, resolve_function,resolve_fl_derived0,resolve_symbol): Ditto. 2012-07-30 Janus Weil PR fortran/51081 * gfortran.dg/proc_ptr_37.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_37.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/primary.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug middle-end/54129] emulated __thread variables and pthread_*specific data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54129 Andrew Pinski changed: What|Removed |Added Component|c |middle-end Summary|__thread variables and |emulated __thread variables |pthread_*specific data |and pthread_*specific data |destroyed in different | |order on Darwin than Linux | --- Comment #1 from Andrew Pinski 2012-07-30 19:56:19 UTC --- I don't think this is even defined behavior. Is the order which pthread_*specific data destroyed defined? This is the biggest issue I think.
[Bug fortran/51081] [F03] Proc-pointer assignment: Rejects valid internal proc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51081 janus at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from janus at gcc dot gnu.org 2012-07-30 19:59:51 UTC --- r189985 fixes the test cases in comment 1 and 8, so that we can close this PR.
[Bug middle-end/54129] emulated __thread variables and pthread_*specific data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54129 --- Comment #2 from blucia at gmail dot com 2012-07-30 20:25:52 UTC --- The man page for pthread_key_create says: "An optional destructor function may be associated with each key value. ... The order of destructor calls is unspecified if more than one destructor exists for a thread when it exits." That's fine, but I did not register any destructor function for the __thread variables that are getting zeroed! In my program, only one destructor function exists. It seems a little weird that those __thread variables are being zeroed at all. Again, I'm not sure what the spec says, but it seems like a better default behavior would be to let them retain their values until termination, unless explicitly altered elsewhere. Doubly so, because it already does that on Linux, and copying that behavior makes code more portable.
[Bug middle-end/54129] emulated __thread variables and pthread_*specific data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54129 --- Comment #3 from Andrew Pinski 2012-07-30 20:29:05 UTC --- > In my program, only one destructor function exists. Yes in your source only has one but the code really there is two. One for the __thread implementation and one you have in your source. So I think we might declare this as being unspecified behavior. The same way the order of the destructor is unspecified.
[Bug middle-end/54129] emulated __thread variables and pthread_*specific data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54129 --- Comment #4 from blucia at gmail dot com 2012-07-30 20:40:31 UTC --- I don't really see your point. Where is the code in the destructor for the __thread variables? For the pthread_key_create vars, I wrote down what I want to do to the data, and the destructor does it (in thread_destructor). I could write a destructor that doesn't do anything, and just keeps getting called on my non-NULL thread specific data. The man page suggests I can handle the arbitrary order problem by cycling through my destructors up to PTHREAD_DESTRUCTOR_ITERATIONS times without NULLing any of my data. >From the man page: "If, after all the destructors have been called for all non-NULL values with associated destructors, there are still some non-NULL values with associated destructors, then the process is repeated. If, after at least [PTHREAD_DESTRUCTOR_ITERATIONS] iterations of destructor calls for outstanding non-NULL values, there are still some non-NULL values with associated destructors, the implementation stops calling destructors." The problem is that the current behavior always NULLs out the __thread data on the first whack. I want to be able to let the __thread destructor run (in any order) and NOT zero the data on its first time through (regardless of the order). Then, eventually, my pthread_key_create-registered destructor runs, and accesses the non-zero data. Later, like the manpage says, my destructors get called again, and eventually the __thread destructor NULLs out the __thread data (perhaps based on some global state that indicates things are safe to delete).
[Bug c++/54130] New: Recognize builtins with bool return type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54130
Bug #: 54130
Summary: Recognize builtins with bool return type
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
Hello,
extern "C" int isnan(double);
int f(){return isnan(3);}
is optimized to "return 0;" because isnan is recognized as a builtin. However,
if I change the program to:
extern "C" bool isnan(double);
int f(){return isnan(3);}
the optimization is not done. I haven't seen any example in gcc sources of a
builtin that may be declared with several different prototypes.
[Bug middle-end/54129] emulated __thread variables and pthread_*specific data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54129
--- Comment #5 from Andrew Pinski 2012-07-30
20:50:21 UTC ---
>Where is the code in the destructor for the __thread variables?
in libgcc/emutls.c .
The code is:
static void
emutls_destroy (void *ptr)
{
struct __emutls_array *arr = ptr;
pointer size = arr->size;
pointer i;
for (i = 0; i < size; ++i)
{
if (arr->data[i])
free (arr->data[i][-1]);
}
free (ptr);
}
static void
emutls_init (void)
{
#ifndef __GTHREAD_MUTEX_INIT
__GTHREAD_MUTEX_INIT_FUNCTION (&emutls_mutex);
#endif
if (__gthread_key_create (&emutls_key, emutls_destroy) != 0)
abort ();
}
--- CUT
So it does is free the current thread memory.
__gthread_key_create is a simple wrapper around pthread_key_create.
[Bug fortran/54120] [4.8 Regression] FAIL: gfortran.fortran-torture/execute/random_2.f90 execution
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54120 John David Anglin changed: What|Removed |Added CC||steven at gcc dot gnu.org --- Comment #1 from John David Anglin 2012-07-30 20:55:42 UTC --- Introduced in 189366. Does this change affect recog_memoized?
[Bug middle-end/54129] emulated __thread variables and pthread_*specific data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54129 --- Comment #6 from blucia at gmail dot com 2012-07-30 21:00:56 UTC --- Thanks for pointing out where that code is. I still think this is weird (i.e., possibly a bug) for two reasons: 1)Differs from Linux behavior. I'm sure lots of things differ though, so I understand pushing it off. 2)Inflexibility in how __thread vars are cleaned up. Is it possible to virtualize the emutls cleanup function? I understand that might be crazy and complex, so I understand pushing that off too. Thanks again for discussing this. I suspect you'll close it as not-a-bug, but it is disappointing that this portability problem exists.
[Bug rtl-optimization/54131] New: ICE building 416.gamess, reload_cse_simplify_operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54131
Bug #: 54131
Summary: ICE building 416.gamess, reload_cse_simplify_operands
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: pthau...@gcc.gnu.org
Created attachment 27900
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27900
Reduced testcase
Seeing the following ICE building gamess with trunk on PowerPC.
[pthaugen@igoo gamess]$ /home/pthaugen/install/gcc/trunk/bin/gfortran -c -m32
-O2 -funroll-loops efgrd2.f
efgrd2.f: In function ‘efpgrd’:
efgrd2.f:20:0: error: insn does not satisfy its constraints:
END
^
(insn 474 161 163 7 (set (mem/c:DF (lo_sum:SI (reg/f:SI 5 5 [243])
(const:SI (plus:SI (symbol_ref:SI ("fgrad_") [flags 0x80]
)
(const_int 12 [0x1d4c0] [4 MEM[base: D.982_96,
offset: 0B]+0 S8 A64])
(reg:DF 23 23)) efgrd2.f:15 385 {*movdf_hardfloat32}
(nil))
efgrd2.f:20:0: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:402
Configured with: /home/pthaugen/src/gcc/trunk/gcc/configure
--prefix=/home/pthaugen/install/gcc/trunk --target=powerpc64-linux
--host=powerpc64-linux --build=powerpc64-linux --enable-secureplt
--enable-threads=posix --enable-shared --enable-__cxa_atexit
--with-long-double-128 --enable-decimal-float --disable-alsa --enable-checking
--with-lto --with-as=/home/pthaugen/install/binutils/binutils-2.21.1/bin/as
--with-ld=/home/pthaugen/install/binutils/binutils-2.21.1/bin/ld
--with-gmp=/home/pthaugen/install/gcc-host-libs
--with-mpfr=/home/pthaugen/install/gcc-host-libs
--with-mpc=/home/pthaugen/install/gcc-host-libs
--with-ppl=/home/pthaugen/install/gcc-host-libs
--with-cloog=/home/pthaugen/install/gcc-host-libs
--with-host-libstdcxx=-Wl,-Bstatic,-L/home/pthaugen/install/gcc-host-libs/lib,-lstdc++,-Bdynamic,-lm
--enable-languages=c,fortran,c++ --disable-bootstrap
[Bug target/54131] [4.8 Regression] ICE building 416.gamess, reload_cse_simplify_operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54131 Andrew Pinski changed: What|Removed |Added Keywords||ice-on-valid-code Component|rtl-optimization|target Target Milestone|--- |4.8.0 Summary|ICE building 416.gamess,|[4.8 Regression] ICE |reload_cse_simplify_operand |building 416.gamess, |s |reload_cse_simplify_operand ||s
[Bug tree-optimization/54132] New: Incorrect loop transformation with -ftree-loop-distribute-patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54132
Bug #: 54132
Summary: Incorrect loop transformation with
-ftree-loop-distribute-patterns
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m...@mansr.com
The following function is incorrectly optimised when
-ftree-loop-distribute-patterns is used (enabled by -O3):
void foo(char *p, int n)
{
int i;
for (i = 0; i < n; i++)
p[i] = p[i - 1];
}
The loop is replaced by a call to memmove(), whereas the correct operation is
equivalent to memset(p, p[-1], n).
[Bug pch/53880] [4.8 Regression] compile time regression when generating precompiled headers for boost
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53880 Steven Bosscher changed: What|Removed |Added Keywords||compile-time-hog Status|NEW |ASSIGNED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-07/msg01524.htm ||l AssignedTo|unassigned at gcc dot |steven at gcc dot gnu.org |gnu.org |
[Bug rtl-optimization/52983] [4.8 Regression] internal compiler error: in df_uses_record, at df-scan.c:3243
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52983 Gary Funck changed: What|Removed |Added CC||gary at intrepid dot com --- Comment #11 from Gary Funck 2012-07-30 23:15:13 UTC --- We are also seeing this build failure on: SUSE Linux Enterprise Server 11.1 (ia64) against trunk revision 189777.
[Bug middle-end/25266] SJLJ exception handling fails in function using alloca()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25266 Steven Bosscher changed: What|Removed |Added Status|NEW |RESOLVED CC||steven at gcc dot gnu.org Resolution||FIXED --- Comment #2 from Steven Bosscher 2012-07-30 23:16:37 UTC --- Fixed by tree-ssa's EH lowering and builtin_alloca handling.
[Bug other/51662] Temporary objects gets garbage collected in cc1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51662 Steven Bosscher changed: What|Removed |Added CC||jason at gcc dot gnu.org --- Comment #4 from Steven Bosscher 2012-07-30 23:25:09 UTC --- >From the backtrace, this looks like a real bug. A test case would still be much appreciated, but someone familiar with G++ can probably construct something and trigger the bug with a GCAC-enabled compiler. Adding Jason to CC: for that.
[Bug target/54131] [4.8 Regression] ICE building 416.gamess, reload_cse_simplify_operands
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54131 Alan Modra changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-07-30 CC||amodra at gmail dot com AssignedTo|unassigned at gcc dot |amodra at gmail dot com |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Alan Modra 2012-07-30 23:25:28 UTC --- Mine. The Y constraint is too restrictive. lo_sums are allowed any offset, it seems.
[Bug target/14563] new/delete much slower than malloc/free because of sjlj exceptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14563 Steven Bosscher changed: What|Removed |Added Status|NEW |RESOLVED CC||steven at gcc dot gnu.org Resolution||FIXED Target Milestone|--- |4.3.0 Known to fail|| --- Comment #51 from Steven Bosscher 2012-07-30 23:29:36 UTC --- As per Danny's suggestion in comment #50 (impressive...)
[Bug c++/27100] ICE with multiple friend declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27100 Steven Bosscher changed: What|Removed |Added Status|REOPENED|NEW Last reconfirmed|2006-09-03 21:39:42 |2012-07-31 1:35 Known to fail||4.7.0, 4.7.1, 4.8.0 --- Comment #5 from Steven Bosscher 2012-07-30 23:35:50 UTC --- Still happens.
[Bug c++/27100] ICE with multiple friend declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27100 --- Comment #6 from Steven Bosscher 2012-07-30 23:48:39 UTC --- It's not clear to me how instantiate_pending_templates protects its instantiations from GGC.
[Bug testsuite/53664] neon-testgen.ml generates duplicate scan-assembler directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664 --- Comment #6 from Ramana Radhakrishnan 2012-07-31 00:00:36 UTC --- Created attachment 27901 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27901 Tentative patch. Tentative patch - has a few unneeded whitespace changes but probably fixes the issue. I need to see how this does also with my current changes to the neon testsuite here but this really should be orthogonal to the other patch. http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01472.html Ramana
[Bug testsuite/53664] neon-testgen.ml generates duplicate scan-assembler directives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53664 --- Comment #7 from Ramana Radhakrishnan 2012-07-31 00:04:58 UTC --- (In reply to comment #5) > Thanks for looking, Ramana. I noticed in my investigation that the search > string needs to be different for scan-assembler-times than for scan-assembler, > since the regular expression handling seems to be different. Could you take a look at the output of the tentative-patch I've attached here ? I'll clean it up and submit it properly sometime tomorrow. Ramana
[Bug rtl-optimization/51631] Trunk ICE for case vst1_lanes64.c with -Os
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51631 Ramana Radhakrishnan changed: What|Removed |Added Keywords||ice-on-invalid-code Status|UNCONFIRMED |NEW Last reconfirmed||2012-07-31 CC||ramana at gcc dot gnu.org Ever Confirmed|0 |1 Known to fail||4.7.0, 4.7.1, 4.8.0 --- Comment #2 from Ramana Radhakrishnan 2012-07-31 00:54:41 UTC --- Aha - probably fixed by http://gcc.gnu.org/ml/gcc-patches/2012-07/msg01474.html Ramana
[Bug target/48803] arm: Bad assembler produced by bit extract/shift
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48803 Ramana Radhakrishnan changed: What|Removed |Added Known to work||4.6.2, 4.7.0 Known to fail||4.5.2 --- Comment #4 from Ramana Radhakrishnan 2012-07-31 00:57:03 UTC --- This is a 4.5 only bug and should probably be closed as 4.5 is now kind of dead. Ramana
[Bug c++/51662] Temporary objects gets garbage collected in cc1plus
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51662 --- Comment #5 from Jason Merrill 2012-07-31 00:58:50 UTC --- Created attachment 27902 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27902 Fix? Does this fix the bug? The call to instantiate_decl was removed for 4.7, so this issue should only affect 4.6.
[Bug rtl-optimization/49169] ARM: optimisations strip the Thumb/ARM mode bit off function pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49169 Ramana Radhakrishnan changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.7.0 --- Comment #7 from Ramana Radhakrishnan 2012-07-31 01:00:46 UTC --- This should be marked FIXED as of 4.7.0 . Ramana
[Bug target/49437] interrupt return pop sometimes corrupts sp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49437 --- Comment #5 from Ramana Radhakrishnan 2012-07-31 01:05:18 UTC --- Fixed only in 4.7.0 Ramana
[Bug rtl-optimization/54133] New: regrename introduces additional dependencies
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54133
Bug #: 54133
Summary: regrename introduces additional dependencies
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: amker.ch...@gmail.com
With test program below:
typedef struct
{
double X, Y;
} Point;
typedef struct
{
Point p1;
Point c1;
Point c2;
Point p2;
} Curve;
double bar(double t, double p0, double p1, double p2, double p3);
void foo( Curve *curve, int count )
{
int n;
int step;
Point point;
Curve c0;
double t;
for ( n = 0; n < count; ++n )
{
c0 = curve[n];
for ( step = 0; step < (10); ++step )
{
t = ((double)(step)) / (double)(10);
point.X = bar( t, c0.p1.X, c0.c1.X, c0.c2.X, c0.p2.X );
point.Y = bar( t, c0.p1.Y, c0.c1.Y, c0.c2.Y, c0.p2.Y );
}
}
}
Compiled with command line:
arm-none-eabi-gcc -mthumb -mcpu=cortex-m0 -Os -frename-registers -S
The dump before and after regrenaming are like:
1. before regrename:
(insn 157 80 158 4 (set (reg:SI 4 r4 [180])
(reg:SI 0 r0)) ../office_pointio.E:29 187 {*thumb1_movsi_insn}
(expr_list:REG_DEAD (reg:SI 0 r0)
(nil)))
(insn 158 157 147 4 (set (reg:SI 5 r5 [+4 ])
(reg:SI 1 r1 [+4 ])) ../office_pointio.E:29 187 {*thumb1_movsi_insn}
(expr_list:REG_DEAD (reg:SI 1 r1 [+4 ])
(nil)))
(insn 147 158 83 4 (set (reg:DF 2 r2)
(mem/c:DF (plus:SI (reg/f:SI 13 sp)
(const_int 40 [0x28])) [6 %sfp+-56 S8 A64]))
../office_pointio.E:30 205 {*thumb_movdf_insn}
(nil))
(insn 83 147 148 4 (set (mem:DF (reg/f:SI 13 sp) [0 S8 A64])
(reg:DF 2 r2)) ../office_pointio.E:30 205 {*thumb_movdf_insn}
(expr_list:REG_DEAD (reg:DF 2 r2)
(nil)))
(insn 148 83 84 4 (set (reg:DF 2 r2)
(mem/c:DF (plus:SI (reg/f:SI 13 sp)
(const_int 56 [0x38])) [6 %sfp+-40 S8 A64]))
../office_pointio.E:30 205 {*thumb_movdf_insn}
(nil))
(insn 84 148 149 4 (set (mem:DF (plus:SI (reg/f:SI 13 sp)
(const_int 8 [0x8])) [0 S8 A64])
(reg:DF 2 r2)) ../office_pointio.E:30 205 {*thumb_movdf_insn}
(expr_list:REG_DEAD (reg:DF 2 r2)
(nil)))
(insn 149 84 85 4 (set (reg:DF 2 r2)
(mem/c:DF (plus:SI (reg/f:SI 13 sp)
(const_int 72 [0x48])) [6 %sfp+-24 S8 A64]))
../office_pointio.E:30 205 {*thumb_movdf_insn}
(nil))
(insn 85 149 159 4 (set (mem:DF (plus:SI (reg/f:SI 13 sp)
(const_int 16 [0x10])) [0 S8 A64])
(reg:DF 2 r2)) ../office_pointio.E:30 205 {*thumb_movdf_insn}
(expr_list:REG_DEAD (reg:DF 2 r2)
(nil)))
(insn 159 85 160 4 (set (reg:SI 0 r0)
(reg:SI 4 r4 [180])) ../office_pointio.E:30 187 {*thumb1_movsi_insn}
(nil))
(insn 160 159 87 4 (set (reg:SI 1 r1 [+4 ])
(reg:SI 5 r5 [+4 ])) ../office_pointio.E:30 187 {*thumb1_movsi_insn}
(nil))
2. after regrename:
(insn 157 80 158 4 (set (reg:SI 4 r4 [180])
(reg:SI 0 r0)) ../office_pointio.E:29 187 {*thumb1_movsi_insn}
(expr_list:REG_DEAD (reg:SI 0 r0)
(nil)))
(insn 158 157 147 4 (set (reg:SI 5 r5 [+4 ])
(reg:SI 1 r1 [+4 ])) ../office_pointio.E:29 187 {*thumb1_movsi_insn}
(expr_list:REG_DEAD (reg:SI 1 r1 [+4 ])
(nil)))
(insn 147 158 83 4 (set (reg:DF 0 r0)
(mem/c:DF (plus:SI (reg/f:SI 13 sp)
(const_int 40 [0x28])) [6 %sfp+-56 S8 A64]))
../office_pointio.E:30 205 {*thumb_movdf_insn}
(nil))
(insn 83 147 148 4 (set (mem:DF (reg/f:SI 13 sp) [0 S8 A64])
(reg:DF 0 r0)) ../office_pointio.E:30 205 {*thumb_movdf_insn}
(expr_list:REG_DEAD (reg:DF 2 r2)
(nil)))
(insn 148 83 84 4 (set (reg:DF 2 r2)
(mem/c:DF (plus:SI (reg/f:SI 13 sp)
(const_int 56 [0x38])) [6 %sfp+-40 S8 A64]))
../office_pointio.E:30 205 {*thumb_movdf_insn}
(nil))
(insn 84 148 149 4 (set (mem:DF (plus:SI (reg/f:SI 13 sp)
(const_int 8 [0x8])) [0 S8 A64])
(reg:DF 2 r2)) ../office_pointio.E:30 205 {*thumb_movdf_insn}
(expr_list:REG_DEAD (reg:DF 2 r2)
(nil)))
(insn 149 84 85 4 (set (reg:DF 1 r1)
(mem/c:DF (plus:SI (reg/f:SI 13 sp)
(const_int 72 [0x48])) [6 %sfp+-24 S8 A64]))
../office_pointio.E:30 205 {*thumb_movdf_insn}
(nil))
(insn 85 149 159 4 (set (mem:DF (plus:SI (reg/f:SI 13 sp)
(const_int 16 [0x10])) [0 S8 A64])
(reg:DF 1 r1)) ../office_pointio.E:30 205 {*thumb_movdf_insn}
(expr_list:REG_DEAD (reg:DF 2 r2)
(nil)))
(insn 159 85 160 4 (set (reg:SI 0 r0)
(reg:SI 4 r4 [180])) ../office_pointio.E:30 187 {*thumb1_movsi_insn}
(nil))
(insn 160 159 87 4 (set (reg:SI 1 r1 [+4 ])
(reg:SI 5 r5 [+4 ])) ../office_pointio.E:30 187 {*
