[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #25 from dominiq at lps dot ens dot fr 2010-02-18 08:00 ---
> Would you mind testing the attached patch?
Apparently the patch in comment #23 does not fix the problem (incremental
update of gcc and partial test):
make -k check-gfortran RUNTESTFLAGS="dg.exp=complex*.f90
--target_board=unix'{-m32,-m64}'"
Running target unix/-m32
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using /opt/gcc/gcc-4.5-work/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/dg.exp ...
=== gfortran Summary for unix/-m32 ===
# of expected passes104
Running target unix/-m64
Using /sw/share/dejagnu/baseboards/unix.exp as board description file for
target.
Using /sw/share/dejagnu/config/unix.exp as generic interface file for target.
Using /opt/gcc/gcc-4.5-work/gcc/testsuite/config/default.exp as
tool-and-target-specific interface file.
Running /opt/gcc/gcc-4.5-work/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -fomit-frame-pointer
-funroll-loops execution test
FAIL: gfortran.dg/complex_intrinsic_5.f90 -O3 -fomit-frame-pointer
-funroll-all-loops -finline-functions execution test
=== gfortran Summary for unix/-m64 ===
# of expected passes102
# of unexpected failures2
=== gfortran Summary ===
# of expected passes206
# of unexpected failures2
/opt/gcc/darwin_buildw/gcc/testsuite/gfortran/../../gfortran version 4.5.0
20100215 (experimental) [trunk revision 156774p2] (GCC)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug inline-asm/43112] 'A' constraint's behavior not compliant with doc under x86-64
--- Comment #1 from jakub at gcc dot gnu dot org 2010-02-18 08:56 --- You just misunderstand it. You'd need a 128-bit int __attribute__((mode (TI))) value if you want it to mean a pair, because for -m64 registers are 64-bit. If you use smaller precision type, "A" constraint acts just as a constraint allowing both ax and dx registers and it is up to the compiler which one it chooses. rdtsc returns result in %eax and %edx, even for 64-bit code, so you need to use unsigned int low, high; "=a" (low), "=d" (high) and then combine that into a 64-bit value. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43112
[Bug fortran/43111] [4.5 Regression] No temporary produced for array pointer actual arguments
--- Comment #1 from burnus at gcc dot gnu dot org 2010-02-18 09:25 --- Why is this marked as 4.4 regression? According to my regression hunt it fails since the patch http://gcc.gnu.org/viewcvs?view=revision&revision=156749 which has only be committed to the trunk. I just checked and the test case of comment #0 still works with a 6h old gcc-4_4-branch. -> Thus I mark this as 4.5 only. * * * By the way, the Fortran 2008 standard lists in 5.3.7 CONTIGUOUS attribute 6.5.4 Simply contiguous array designators some things which are/aren't contiguous in Fortran; maybe one should browse that list just to get some more ideas (both for optimization and for avoiding over-optimization). See: ftp://ftp.nag.co.uk/sc22wg5/N1751-N1800/N1791.pdf -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P4 Last reconfirmed|-00-00 00:00:00 |2010-02-18 09:25:19 date|| Summary|[4.4, 4.5 regression] No|[4.5 Regression] No |temporary produced for array|temporary produced for array |pointer actual arguments|pointer actual arguments Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43111
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #17 from paolo dot carlini at oracle dot com 2010-02-18 09:36 --- (In reply to comment #16) > I don't understand why all libstdc++ headers should not have #pragma GCC > system_header in them. Would you please explain that? Hi Mark. For sure all the *library proper* headers should have (and afaik, have already) the pragma. If I understand correctly, the doubt is about the libsupc++ headers: at some point in the past we discussed that briefly and we came to the conclusion that if we could avoid decorating those too it would be cleaner (Gaby agreed, I'm 100% sure). But indeed, nothing set in stone, at least for 4.5.x, if we want to decorate the few user visibile headers in libsupc++, I do not object. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug target/43107] [4.5 Regression] ICE: SIGSEGV with -O3 -mavx
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Component|tree-optimization |target Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-18 09:40:59 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43107
[Bug c++/43108] mixed complex multiplication horribly inefficient
--- Comment #28 from paolo dot carlini at oracle dot com 2010-02-18 09:42 --- Thanks Gaby, eventually I learned something ;) Hopefully the remaining correctness issues can be fixed quickly in the C++ front-end, honestly before this PR I wasn't aware of any correctness regression in this area, that is treatment of signed zeros. Performance, that could be also a problem for some users, I think we should anyway add a note to the 4.5 changes explaining the use of -fno-signed-zeros, both for C and C++, in that case. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
[Bug tree-optimization/43074] [4.4/4.5 Regression] ICE in vectorizable_reduction, at tree-vect-loop.c:3491
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-02-18 09:43 --- Yep. Fixed. Thanks Ira. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail||4.4.3 Known to work||4.4.4 4.5.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43074
[Bug c++/43108] mixed complex multiplication horribly inefficient
--- Comment #29 from rguenth at gcc dot gnu dot org 2010-02-18 09:46 --- (In reply to comment #28) > Thanks Gaby, eventually I learned something ;) > > Hopefully the remaining correctness issues can be fixed quickly in the C++ > front-end, honestly before this PR I wasn't aware of any correctness > regression > in this area, that is treatment of signed zeros. Performance, that could be > also a problem for some users, I think we should anyway add a note to the 4.5 > changes explaining the use of -fno-signed-zeros, both for C and C++, in that > case. C performance is fine. Joseph fixed it for the C frontend and the fallout is that it regressed for the C++ frontend. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
[Bug target/43107] [4.5 Regression] ICE: SIGSEGV with -O3 -mavx
--- Comment #4 from jakub at gcc dot gnu dot org 2010-02-18 09:48 --- Created an attachment (id=19904) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19904&action=view) gcc45-pr43107.patch Fix, tested so far just on this testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43107
[Bug c++/43108] mixed complex multiplication horribly inefficient
--- Comment #30 from paolo dot carlini at oracle dot com 2010-02-18 09:53 --- Argh, so the C front-end manages to be both correct and fast. We should definitely do something about C++... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
[Bug ada/43096] [4.5 Regression] ACATS c37105a wrong-code on arm-linux
--- Comment #3 from ebotcazou at gcc dot gnu dot org 2010-02-18 09:56 --- Looking into it. -- ebotcazou at gcc dot gnu dot org changed: What|Removed |Added CC|ebotcazou at gcc dot gnu dot| |org | AssignedTo|unassigned at gcc dot gnu |ebotcazou at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-18 09:56:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43096
[Bug libstdc++/40278] -std=c++0x is error, but -std=gnu++0x is OK!
--- Comment #9 from paolo dot carlini at oracle dot com 2010-02-18 10:00 --- Dave, what do you recommend about this issue? Does it affect cygwin too? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC|loaden at gmail dot com |dave dot korn dot cygwin at ||gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278
[Bug libstdc++/40278] -std=c++0x is error, but -std=gnu++0x is OK!
--- Comment #10 from paolo dot carlini at oracle dot com 2010-02-18 10:12 --- In short, I see two conceptually separate issues: 1- We run the configure tests for those functions in GNU mode, thus if on a target an header doesn't declare some functions in ISO strict mode, the user experiences puzzling errors, like in Comment #1; 2- Specific to MingW (and Cygwin too?!?), those C99 names do not correspond to functions implementing the actual C99 semantics, arguably should indeed not be exposed in strict ISO mode. Thus, my doubt is: should we actually run those configure tests in strict ISO mode, instead of GNU mode? For Linux would not make a difference, and would avoid puzzling errors like those experienced by MingW users. However, I'm afraid some users, on other systems, could be disappointed in finding fewer functions declared in the C++ headers (in namespace std) in GNU mode (which is the default!) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278
[Bug fortran/43111] [4.5 Regression] No temporary produced for array pointer actual arguments
--- Comment #2 from pault at gcc dot gnu dot org 2010-02-18 10:26 --- (In reply to comment #1) > Why is this marked as 4.4 regression? According to my regression hunt it fails > since the patch http://gcc.gnu.org/viewcvs?view=revision&revision=156749 which > has only be committed to the trunk. I just checked and the test case of > comment > #0 still works with a 6h old gcc-4_4-branch. -> Thus I mark this as 4.5 only. My mistake - OK! Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |ASSIGNED Last reconfirmed|2010-02-18 09:25:19 |2010-02-18 10:26:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43111
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #26 from bernds_cb1 at t-online dot de 2010-02-18 11:51 --- Created an attachment (id=19905) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19905&action=view) A patch to help debug the problem I'll need some help since on my system a compiler targetting powerpc-apple-darwin9 produces rather different output in the dumps than what is attached to this bug. The powerpc-linux failures look unrelated as they appear even at -O0. If the problem really is in regrename, the attached patch should help debug it. If you wish to help, please follow these instructions. You'll need to use a kind of binary search using the -fdbg-cnt=rnreg:N option, where N is an integer. Start with something small, maybe even 1, then double it until the failure appears. Then do a binary search between the last number that produced a working binary, and the one that did not. You should end up with a value of N such that -fdbg-cnt=rnreg:N produces a working executable, and -fdbg-cnt=rnreg:N+1 does not. Please attach the .rnreg dumps and assembly files for both. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #27 from dominiq at lps dot ens dot fr 2010-02-18 12:17 --- > You'll need to use a kind of binary search using the -fdbg-cnt=rnreg:N option, > where N is an integer. Start with something small, maybe even 1, then double > it until the failure appears. Then do a binary search between the last number > that produced a working binary, and the one that did not. Should I use '-fdbg-cnt=rnreg:N' to build gcc or only when testing complex_intrinsic_5.f90? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #28 from bernds_cb1 at t-online dot de 2010-02-18 12:21 --- Only when building the testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42233] [4.3/4.4/4.5 regression] c++ builtin_expect code generation regression
--- Comment #7 from jakub at gcc dot gnu dot org 2010-02-18 12:30 --- On the 4.4 branch actually cc1 behaves differently from cc1plus. In any case, I believe the two setne's plus testb code is actually the worst of the options, and e.g. with -Os it is even much larger. Just compile the testcase on 4.5 with -Os and -Os -D'__builtin_expect(a,b)=(a)' In the former case (i.e. with __builtin_expect) if generates: cmpq%rcx, %rdx sete%dl xorl%eax, %eax cmpq%rsi, %rdi movzbl %dl, %edx sete%al testl %eax, %edx je .L2 xorl%eax, %eax jmp likely .L2: xorl%eax, %eax jmp unlikely while in the latter case generates: cmpq%rcx, %rdx jne .L2 cmpq%rsi, %rdi jne .L2 xorl%eax, %eax jmp likely .L2: xorl%eax, %eax jmp unlikely (what would be actually the best code for -O2 when __builtin_expect is used and tells that likely () is likely). -- jakub at gcc dot gnu dot org changed: What|Removed |Added CC||bonzini at gnu dot org Known to work|4.1.2 4.5.0 |4.1.2 Summary|[4.3/4.4 regression] c++|[4.3/4.4/4.5 regression] c++ |builtin_expect code |builtin_expect code |generation regression |generation regression http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42233
[Bug middle-end/42233] [4.3/4.4/4.5 regression] c++ builtin_expect code generation regression
--- Comment #8 from jakub at gcc dot gnu dot org 2010-02-18 12:47 --- Created an attachment (id=19906) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19906&action=view) gcc45-pr42233.patch The reason why it behaves differently with __builtin_expect from normal condition is that in the latter case gimple_boolify changes the types of the comparisons etc. to _Bool, while for __builtin_expect it doesn't recurse into its first argument. The attached patch fixes that. Then we are back to the 4.3 generated code, i.e. the same as is generated without __builtin_expect. At this point the problem is described in a comment above add_reg_br_prob_note: /* Verify that there is exactly single jump instruction since last and attach REG_BR_PROB note specifying probability. ??? We really ought to pass the probability down to RTL expanders and let it re-distribute it when the conditional expands into multiple conditionals. This is however difficult to do. */ Since here there are two jumps, not one, no REG_BR_PROB note is added. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42233
[Bug libstdc++/40278] -std=c++0x is error, but -std=gnu++0x is OK!
--- Comment #11 from davek at gcc dot gnu dot org 2010-02-18 12:54 --- (In reply to comment #9) > Dave, what do you recommend about this issue? Does it affect cygwin too? > This particular problem doesn't occur on cygwin, but we've had similar issues in the past with pre-c99 headers on cygwin (arising from newlib), although it was easier there, since we did actually have the functionality available, so just had to change the headers to make sure it was declared in __STRICT_ANSI__ mode. I don't know how the MinGW guys would best like to go about tackling this, but I'd certainly not suggest changing the configury for /all/ hosts. Adding a host-specific CFLAGs entry during the configure tests would be one way of handling it at the compiler end. Adding the required support in the mingw library will be the ultimate way of handling it. A third option would be for mingw to alias their current _(v)swprintf implementations to the required names as a stop-gap measure, on the grounds that since the resulting compiler/toolchain is going to be not fully conformant anyway until the functions are added, a slightly sub-spec implementation is preferable to an entirely missing one. Danny, it's your call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40278
[Bug target/40887] GCC generates suboptimal code for indirect function calls on ARM
--- Comment #12 from ramana at gcc dot gnu dot org 2010-02-18 13:13 --- Subject: Bug 40887 Author: ramana Date: Thu Feb 18 13:13:03 2010 New Revision: 156862 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156862 Log: PR target/40887 Backport from trunk. 2009-12-24 Julian Brown Ramana Radhakrishnan * config/arm/arm.c (output_call_mem): Remove armv5 support. * config/arm/arm.md (*call_mem): Disable for armv5. Add note. (*call_value_mem): Likewise. PR target/40887 Backport from trunk. 2009-12-24 Julian Brown Ramana Radhakrishnan * gcc.target/arm/pr40887.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.target/arm/pr40887.c - copied unchanged from r155453, trunk/gcc/testsuite/gcc.target/arm/pr40887.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/arm/arm.c branches/gcc-4_4-branch/gcc/config/arm/arm.md branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
[Bug middle-end/42233] [4.3/4.4/4.5 regression] c++ builtin_expect code generation regression
--- Comment #9 from bonzini at gnu dot org 2010-02-18 13:17 --- I'm relieved that cond-optab is in no way related to this. :-) I'm not expert of the gimplifier but the patch makes sense and looks good. -- bonzini at gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-18 13:17:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42233
[Bug target/29560] [avr] Poor optimization for byte shifts
--- Comment #5 from Rudolf dot Leitgeb at gmx dot at 2010-02-18 13:28 --- Right away: I am NOT an expert in compiler or optimizer design, so please bear with me. I understand, that (((unsigned char)1) << ((unsigned char)something)) may need more than 8 bits for representation and that gcc's default int size on the ATmega platform is 16 bits. But the result is assigned to an 8 bit value. I take it that there is no way to back propagate this potential optimization from the assignment to the shifting step. If you look in my assembly code, r25 is computed with great effort yet never transferred anywhere. The trick with &7 is nice but introduces another unnecessary AND operation. And it is only correct if the input numebr is guaranteed to be between 0 and 7. Am I correct that this whole optimization issue comes from the fact that ATmega is an 8 bit architecture yet gcc's int on that platform is 16 bit? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29560
[Bug c++/43113] New: too long diagnostics in some cases of recursive template instantiation
testcase.cpp
template < typename >
struct A {
struct S;
A < S > ht;
};
struct B : A < B > {};
--
without -ftemplate-depth, it instantiates templates up do default depth, giving
760KiB of diagnostics for this simple testcase (for 4.5.0)
this is output with -ftemplate-depth-5:
$ g++ testcase.cpp -ftemplate-depth-5
testcase.cpp:4: error: template instantiation depth exceeds maximum of 5 (use
-ftemplate-depth-NN to increase the maximum) instantiating 'struct
A::S>::S>::S>::S>::S>'
testcase.cpp:4: instantiated from 'A::S>::S>::S>::S>'
testcase.cpp:4: instantiated from 'A::S>::S>::S>'
testcase.cpp:4: instantiated from 'A::S>::S>'
testcase.cpp:4: instantiated from 'A::S>'
testcase.cpp:4: instantiated from 'A'
testcase.cpp:7: instantiated from here
testcase.cpp:4: error: 'A< >::ht' has incomplete type
testcase.cpp:2: error: declaration of 'struct
A::S>::S>::S>::S>::S>'
--
all tested gcc versions behave the same - 2.95, 3.2.3, 3.3.6, 3.4.6, 4.0.4,
4.1.2, 4.2.4, 4.3.4, 4.4.3, 4.5.0 (with the exception that 2.95 bails out at
the end, and 3.2.3 and 2.95 need quite long time for even template depth 20)
--
Summary: too long diagnostics in some cases of recursive template
instantiation
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: zsojka at seznam dot cz
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43113
[Bug target/40887] GCC generates suboptimal code for indirect function calls on ARM
--- Comment #13 from ramana at gcc dot gnu dot org 2010-02-18 13:34 --- Fixed. -- ramana at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.4.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40887
[Bug c++/43114] New: GCC 4.4.1 problems with include
Overview Description: GCC version: 4.4.1 System info: 2.6.31-14-generic #48-Ubuntu SMP Fri Oct 16 14:04:26 UTC 2009 i686 GNU/Linux, Ubuntu 9.10 GCC I used was the Ubuntu 9.10 native c++ compiler, installed using Synaptic package manager. The case is the following: There are two files to be compiled: cpp and hpp. x.hpp contains only the f() function prototype. x.cpp contains the f() function implementation and main(). x.cpp file includes the x.hpp. g++ -c x.hpp - this command generates x.hpp.gch file. After this the command g++ x.cpp gives the following error: x.cpp: In function int f(): x.cpp:3: error: redefinition of int f() x.hpp:2: error: int f() previously defined here. In some cases it is not reproducible. -- Summary: GCC 4.4.1 problems with include Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: major Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: nar dot martirosyan at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43114
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #29 from dominiq at lps dot ens dot fr 2010-02-18 13:42 --- In order to compile gcc/regrename.c, I had to add + enum debug_counter rnreg; Is this right? Then compiling the test with gfc -fdbg-cnt=rnreg:1 -m64 -O1 -frename-registers /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/complex_intrinsic_5.f90 I get the following error f951: error: Can not find a valid counter:value pair: f951: error: -fdbg-cnt=rnreg:1 f951: error: ^ What is missing? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #30 from steven at gcc dot gnu dot org 2010-02-18 13:53 --- It looks like there should be a patch to dbgcnt.def. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #31 from dominiq at lps dot ens dot fr 2010-02-18 14:06 --- > It looks like there should be a patch to dbgcnt.def. Does this mean that I should remove the line + enum debug_counter rnreg; I have added, and add a line DEBUG_COUNTER (rnreg) in dbgcnt.def? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug libstdc++/40856] numeric_limits not specialized for __int128_t or __uint128_t
--- Comment #4 from paolo dot carlini at oracle dot com 2010-02-18 14:10 --- Created an attachment (id=19907) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19907&action=view) Draft patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40856
[Bug libstdc++/40856] numeric_limits not specialized for __int128_t or __uint128_t
--- Comment #5 from paolo dot carlini at oracle dot com 2010-02-18 14:11 --- Gaby, I just attached a draft patch which essentially does what submitter requested, adds the two specializations. Shall we do this? -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||gdr at integrable-solutions ||dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40856
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #32 from bernds_cb1 at t-online dot de 2010-02-18 14:17 --- Created an attachment (id=19908) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19908&action=view) Additional patch on top of the previous one Sorry about that. Yes, you'll need to add that in dbgcnt.def, or just apply this additional patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug c++/43113] too long diagnostics in some cases of recursive template instantiation
--- Comment #1 from paolo dot carlini at oracle dot com 2010-02-18 14:18 --- *** This bug has been marked as a duplicate of 9335 *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43113
[Bug c++/9335] Inordinately long output when maximum template depth is exceeded
--- Comment #5 from paolo dot carlini at oracle dot com 2010-02-18 14:18 --- *** Bug 43113 has been marked as a duplicate of this bug. *** -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||zsojka at seznam dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9335
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #33 from dominiq at lps dot ens dot fr 2010-02-18 14:22 --- > Sorry about that. Yes, you'll need to add that in dbgcnt.def, or just apply > this additional patch. This recompiles most of gcc!-(it will take a couple hours on my poor G5!-). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug tree-optimization/43066] [4.5 Regression] ICE: SIGFPE with empty struct and va_arg
--- Comment #6 from jamborm at gcc dot gnu dot org 2010-02-18 14:53 --- Subject: Bug 43066 Author: jamborm Date: Thu Feb 18 14:53:05 2010 New Revision: 156863 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156863 Log: 2010-02-18 Martin Jambor PR tree-optimization/43066 * tree-sra.c (build_ref_for_offset_1): Return false on encountering an array with zero-sized element type. * testsuite/gcc.c-torture/compile/pr43066.c: New test. Added: trunk/gcc/testsuite/gcc.c-torture/compile/pr43066.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-sra.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43066
[Bug middle-end/42233] [4.3/4.4/4.5 regression] c++ builtin_expect code generation regression
--- Comment #10 from jakub at gcc dot gnu dot org 2010-02-18 15:04 --- Created an attachment (id=19909) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19909&action=view) gcc45-pr42233-2.patch Trunk patch that seems to fix this together with the previous patch. Going to bootstrap/regtest both now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42233
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #34 from dominiq at lps dot ens dot fr 2010-02-18 15:08 --- And the winner is N=137! [karma] f90/bug% gfc -fdbg-cnt=rnreg:137 -m64 -O1 -frename-registers /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/complex_intrinsic_5.f90 dbg_cnt 'rnreg' set to 137 [karma] f90/bug% a.out [karma] f90/bug% gfc -fdbg-cnt=rnreg:138 -m64 -O1 -frename-registers /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/complex_intrinsic_5.f90 dbg_cnt 'rnreg' set to 138 [karma] f90/bug% a.out check4: z=.000 + I .000 zref=1.000 + I .000 Diff: -1.000 + I*.000 eps=.23841858E-06 Abort -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug debug/43077] VTA issues caused by SSA expand
--- Comment #1 from matz at gcc dot gnu dot org 2010-02-18 15:13 --- Created an attachment (id=19910) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19910&action=view) candidate fix Try this. I don't know how to write guality tests, but I think it has the effects you look for, at least the debug_insn now refer to existing things. -- matz at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |matz at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43077
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #18 from mmitchel at gcc dot gnu dot org 2010-02-18 15:13 --- Paolo -- I think libsupc++ is just as much a "system library" as libstdc++. It doesn't have an ISO-standard API, of course, but that's not the point; it's just as much a part of the system/implementation as libstdc++. To the extent a program is going to use a header that we ship from libsupc++, that program certainly doesn't want to get random warnings about those headers. However, Julian Brown warns me that he's been playing with this and that it doesn't entirely solve the problem. It may be that my earlier patch to arm.c is insufficient in some cases. So, I'd like the libstdc++ maintainers to make the change to the libsupc++ headers -- unless someone can articulate a good reason not to do so of course -- but there may still be more work to do. We will continue to investigate the possible non-workingness of the patch. Thanks, -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #19 from paolo dot carlini at oracle dot com 2010-02-18 15:24 --- Ok, it's just an handful of files, after all. If Julian wants to add the pragmas, the change is pre-approved, otherwise, just let me know when you have the other issues under control, and I'll do it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #35 from bernds_cb1 at t-online dot de 2010-02-18 15:32 --- Okay, great. Could you attach the .rnreg dumps and assembly output for both values? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #36 from dominiq at lps dot ens dot fr 2010-02-18 15:38 --- > Could you attach the .rnreg dumps How do I get them? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug c++/43087] [4.5 Regression] ICE in tsubst, at cp/pt.c:9923
--- Comment #5 from hjl dot tools at gmail dot com 2010-02-18 15:40 --- Revision 156792: http://gcc.gnu.org/ml/gcc-cvs/2010-02/msg00375.html made ICE disappear. I don't know if it really fixes the bug or just hides it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43087
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #37 from dominiq at lps dot ens dot fr 2010-02-18 15:40 --- Created an attachment (id=19911) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19911&action=view) Assembly for -fdbg-cnt=rnreg:137 Command used gfc -S -fdbg-cnt=rnreg:137 -m64 -O1 -frename-registers /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/complex_intrinsic_5.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #38 from dominiq at lps dot ens dot fr 2010-02-18 15:41 --- Created an attachment (id=19912) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19912&action=view) Assembly for -fdbg-cnt=rnreg:138 Command line gfc -S -fdbg-cnt=rnreg:138 -m64 -O1 -frename-registers /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/complex_intrinsic_5.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug debug/43077] VTA issues caused by SSA expand
--- Comment #2 from jakub at gcc dot gnu dot org 2010-02-18 15:46 --- Created an attachment (id=19913) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19913&action=view) gcc45-pr43077-test.patch Here is a guality testcase for it. Before the patch there is just lots of FAILs, with the patch most of them are gone on both x86_64-linux -m64 and -m32, though not all. Will look at those later, I have Alex have some pending patches so will also try with them. So the patch looks good, at least on this testcase. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43077
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #39 from bernds_cb1 at t-online dot de 2010-02-18 15:52 --- (In reply to comment #36) > > Could you attach the .rnreg dumps > > How do I get them? > -fdump-rtl-rnreg-details -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #40 from dominiq at lps dot ens dot fr 2010-02-18 15:58 --- Created an attachment (id=19914) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19914&action=view) .rnreg for -fdbg-cnt=rnreg:137 Command used fc -fdump-rtl-rnreg-details -fdbg-cnt=rnreg:137 -m64 -O1 -frename-registers /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/complex_intrinsic_5.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #41 from dominiq at lps dot ens dot fr 2010-02-18 15:59 --- Created an attachment (id=19915) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19915&action=view) .rnreg for -fdbg-cnt=rnreg:138 Command line gfc -fdump-rtl-rnreg-details -fdbg-cnt=rnreg:138 -m64 -O1 -frename-registers /opt/gcc/_gcc_clean/gcc/testsuite/gfortran.dg/complex_intrinsic_5.f90 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug debug/43077] VTA issues caused by SSA expand
--- Comment #3 from matz at gcc dot gnu dot org 2010-02-18 16:12 --- At least varb isn't printed in fn3, because dse2 (after prologue_epilogue) makes the expressions in the debug_insn be (clobber 0). Presumably because frame elimination rewrites the address-takings, but not the debug instructions, hence it thinks they are uninited stores, as they still refer to the frame pointer, not the stack pointer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43077
[Bug fortran/41209] Add full ATTRIBUTE support to gfortran (ALIGN, (WEAK)ALIAS, ...)
--- Comment #4 from burnus at gcc dot gnu dot org 2010-02-18 16:19 --- Another request for this feature: http://gcc.gnu.org/ml/fortran/2010-02/msg00144.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41209
[Bug c++/43109] [4.5 Regression] ICE: SIGSEGV with unnamed namespace inside named
--- Comment #1 from jason at gcc dot gnu dot org 2010-02-18 16:27 --- Subject: Bug 43109 Author: jason Date: Thu Feb 18 16:27:07 2010 New Revision: 156864 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156864 Log: PR c++/43109 * semantics.c (begin_class_definition): Don't crash on unnamed ns. Added: trunk/gcc/testsuite/g++.dg/parse/namespace12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43109
[Bug c++/43101] [4.4/4.5 regression] Rejects template with const static data member used in return type
--- Comment #2 from jason at gcc dot gnu dot org 2010-02-18 16:27 --- Subject: Bug 43101 Author: jason Date: Thu Feb 18 16:27:18 2010 New Revision: 156865 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156865 Log: PR c++/26261 PR c++/43101 * pt.c (tsubst_qualified_id): Do normal lookup in non-dependent scope. (maybe_update_decl_type): New fn. * parser.c (cp_parser_init_declarator): Use it. Added: trunk/gcc/testsuite/g++.dg/template/dependent-name6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43101
[Bug c++/26261] Rejects template with const static data member used in return type
--- Comment #13 from jason at gcc dot gnu dot org 2010-02-18 16:27 --- Subject: Bug 26261 Author: jason Date: Thu Feb 18 16:27:18 2010 New Revision: 156865 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156865 Log: PR c++/26261 PR c++/43101 * pt.c (tsubst_qualified_id): Do normal lookup in non-dependent scope. (maybe_update_decl_type): New fn. * parser.c (cp_parser_init_declarator): Use it. Added: trunk/gcc/testsuite/g++.dg/template/dependent-name6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/parser.c trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26261
[Bug c++/43101] [4.4/4.5 regression] Rejects template with const static data member used in return type
--- Comment #3 from jason at gcc dot gnu dot org 2010-02-18 16:28 --- *** This bug has been marked as a duplicate of 26261 *** -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43101
[Bug c++/26261] Rejects template with const static data member used in return type
--- Comment #14 from jason at gcc dot gnu dot org 2010-02-18 16:28 --- *** Bug 43101 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26261
[Bug c++/26261] Rejects template with const static data member used in return type
--- Comment #15 from jason at gcc dot gnu dot org 2010-02-18 16:28 --- Fixed for 4.5. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26261
[Bug debug/43077] VTA issues caused by SSA expand
--- Comment #4 from matz at gcc dot gnu dot org 2010-02-18 16:40 --- Created an attachment (id=19916) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19916&action=view) do reg elimination This will fix some more of the var[bc] references by eliminating all registers in DEBUG_INSN_P. As I'm ignoring DEBUG_INSNs for effects that might change elimination results, this should not result in code changes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43077
[Bug debug/43077] VTA issues caused by SSA expand
--- Comment #5 from matz at gcc dot gnu dot org 2010-02-18 16:50 --- That leaves 'c' which isn't printed, because the setup of c (a stackslot) is schedules to be part of the function call setup, the breakpoint is before that setup, and hence the location of 'c' does point to the correct one (namely its stackslot), but that one isn't initialized yet. One problem might be that there's no DEBUG_BIND insn generated for c at all. Or alternatively, once the stack slot initialization is moved down that no debug_insn is generated at it's original place to refer to the value 0. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43077
[Bug c++/43108] [4.5 regression] mixed complex multiplication horribly inefficient
--- Comment #31 from jason at gcc dot gnu dot org 2010-02-18 16:52 --- Performance regression. -- jason at gcc dot gnu dot org changed: What|Removed |Added Keywords||missed-optimization Summary|mixed complex|[4.5 regression] mixed |multiplication horribly |complex multiplication |inefficient |horribly inefficient Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
[Bug c++/9990] locale_facets.h contains invalid typedef
--- Comment #8 from paolo dot carlini at oracle dot com 2010-02-18 16:56 --- For the record, all the compilers I have at hand, EDG based too, accept this in the most strict mode. I seriously doubt there is really something to fix here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9990
[Bug c++/43070] [4.5 Regression] g++.dg/ext/label2.C fails to compile at -O1
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-18 17:07:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43070
[Bug target/43070] [4.5 Regression] g++.dg/ext/label2.C fails to compile at -O1
--- Comment #2 from jason at gcc dot gnu dot org 2010-02-18 17:42 --- The problem turns out to be that the patch for PR 6196 was wrong; ext/label[12].C are ill-formed, as both are trying to goto the address of an array rather than an element. -- jason at gcc dot gnu dot org changed: What|Removed |Added Component|c++ |target http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43070
[Bug c++/43108] [4.5 regression] mixed complex multiplication horribly inefficient
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-18 17:54:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
[Bug fortran/43115] New: bug with gfortran on Windows vista, correct on Linux
listing of the gfortran program whith the bug use iso_fortran_env implicit none integer,parameter:: mligne = 1,n2 = 10 character(len = n2 + 2):: ligne ! the bug is here : 2 is not necessary for reading essai.f95 : 10 max character per line ! character(len = n2):: ligne ! the bug is here did not work : only 8 max character per line ! character(len = n2 + 1):: ligne ! the bug is here did not work : only 9 max character per line character(len = 260):: string integer:: i,j,iosta,nligne write(output_unit,*) ' name of he file to read' read(input_unit,*) string open(unit = 7,action = 'read',file = string) do i = 1,mligne read(unit = 7,fmt = '(a)',iostat = iosta) ligne if(iosta .eq. iostat_end) go to 100 if(iosta .eq. iostat_eor) go to 200 200continue end do 100 continue close(unit = 7) nligne = i - 1 write(6,*) "number of read lines = ",nligne end listing of the file not correctly read : essai.f95 : 12345 123456 1234567 12345678 123456789 1234567890 123456789 12345678 1234567 123456 12345 Because no bug on Linux : end of line : Carriage return + form feed ? -- Summary: bug with gfortran on Windows vista, correct on Linux Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: cgerdy at wanadoo dot fr http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43115
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #42 from bernds_cb1 at t-online dot de 2010-02-18 18:13 --- Created an attachment (id=19917) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19917&action=view) Another test patch that attempts to fix the problem. Could you test whether this fixes it? -- bernds_cb1 at t-online dot de changed: What|Removed |Added Attachment #19900|0 |1 is obsolete|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug fortran/43115] bug with gfortran on Windows vista, correct on Linux
--- Comment #1 from kargl at gcc dot gnu dot org 2010-02-18 18:15 --- Please attach the files to the PR. Cut and paste from bugzilla will mangle the files; particularly, if it is a CRLF problem. Also, try removing your iostat usage and see if the the operating system generates an error, or use iomsg. Something like str = 'OK' open(unit = 7, action = 'read', file = string) do i = 1,mligne read(unit = 7, fmt = '(a)', iostat = iosta, iomsg=str) ligne print *, trim(str) On FreeBSD, I get troutmask:sgk[223] ./z name of he file to read abc OK OK OK OK OK OK OK OK OK OK OK End of file number of read lines = 11 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43115
[Bug debug/43084] [4.5 Regression] ICE -fipa-struct-reorg -g (VTA)
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-02-18 18:31 --- (gdb) p debug_gimple_stmt (new_stmt) # DEBUG p => &s This was caused by the introduction of debug statements. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added CC||aoliva at gcc dot gnu dot ||org Component|tree-optimization |debug GCC host triplet|x86_64-pc-linux-gnu | GCC target triplet|x86_64-pc-linux-gnu | Keywords||ice-on-valid-code Summary|[4.5 Regression] ICE: in|[4.5 Regression] ICE -fipa- |find_new_var_of_type, at|struct-reorg -g (VTA) |ipa-struct-reorg.c:604 with | |-fipa-struct-reorg -g | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43084
[Bug tree-optimization/43097] [4.5 Regression] ICE in rename_map_elt_info for Graphite, vect in 173.applu
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-18 18:36 --- Happens on x86_64-linux-gnu also even without -ftree-vectorize. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC target triplet|powerpc64-linux | Last reconfirmed|-00-00 00:00:00 |2010-02-18 18:36:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43097
[Bug tree-optimization/43083] [4.5 Regression] ICE: SIGSEGV with -fgraphite-identity
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-02-18 18:38 --- Confirmed backtrace: #0 0x00801625 in link_block (b=0x7f9f943dcaf8, after=0x7f9f943dc138) at /home/apinski/src/gcc-fsf/local//gcc/gcc/cfg.c:153 #1 0x012b8fb6 in create_bb (h=0x0, e=0x0, after=0x7f9f943dc138) at /home/apinski/src/gcc-fsf/local//gcc/gcc/tree-cfg.c:444 #2 0x00863a60 in create_basic_block (head=0x0, end=0x0, after=0x7f9f943dc138) at /home/apinski/src/gcc-fsf/local//gcc/gcc/cfghooks.c:621 #3 0x00863ac1 in create_empty_bb (after=0x7f9f943dc138) at /home/apinski/src/gcc-fsf/local//gcc/gcc/cfghooks.c:636 #4 0x012c7d00 in gimple_split_block (bb=0x7f9f943dc138, stmt=0x0) at /home/apinski/src/gcc-fsf/local//gcc/gcc/tree-cfg.c:4812 #5 0x008633d7 in split_block (bb=0x7f9f943dc138, i=0x0) at /home/apinski/src/gcc-fsf/local//gcc/gcc/cfghooks.c:433 #6 0x00863510 in split_block_after_labels (bb=0x7f9f943dc138) at /home/apinski/src/gcc-fsf/local//gcc/gcc/cfghooks.c:471 #7 0x00863e00 in make_forwarder_block (bb=0x7f9f943dc138, redirect_edge_p=0x2532697 , new_bb_cbk=0) at /home/apinski/src/gcc-fsf/local//gcc/gcc/cfghooks.c:737 #8 0x0253271e in create_single_exit_edge (region=0x47afff8) at /home/apinski/src/gcc-fsf/local//gcc/gcc/graphite-scop-detection.c:965 #9 0x025329f1 in create_sese_edges (regions=0x47affd0) at /home/apinski/src/gcc-fsf/local//gcc/gcc/graphite-scop-detection.c:1034 #10 0x0253338c in build_scops (scops=0x7fff14b44e20) at /home/apinski/src/gcc-fsf/local//gcc/gcc/graphite-scop-detection.c:1327 #11 0x0245f015 in graphite_transform_loops () at /home/apinski/src/gcc-fsf/local//gcc/gcc/graphite.c:260 #12 0x01906459 in graphite_transforms () at /home/apinski/src/gcc-fsf/local//gcc/gcc/tree-ssa-loop.c:300 -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-02-18 18:38:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43083
[Bug tree-optimization/43083] [4.5 Regression] ICE: SIGSEGV with -fgraphite-identity
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-02-18 18:39 --- #8 0x0253271e in create_single_exit_edge (region=0x47afff8) at /home/apinski/src/gcc-fsf/local//gcc/gcc/graphite-scop-detection.c:965 965 forwarder = make_forwarder_block (exit, &sd_region_without_exit, NULL); (gdb) p debug_bb(exit) ;; basic block 1, loop depth 0, count 0 ;; prev block 7, next block 9 ;; pred: 7 [100.0%] 6 [100.0%] ;; succ: : -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43083
[Bug tree-optimization/43083] [4.5 Regression] ICE: SIGSEGV with -fgraphite-identity
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-02-18 18:42 --- (In reply to comment #3) > #8 0x0253271e in create_single_exit_edge (region=0x47afff8) at > /home/apinski/src/gcc-fsf/local//gcc/gcc/graphite-scop-detection.c:965 > 965 forwarder = make_forwarder_block (exit, &sd_region_without_exit, > NULL); > (gdb) p debug_bb(exit) > ;; basic block 1, loop depth 0, count 0 > ;; prev block 7, next block 9 > ;; pred: 7 [100.0%] 6 [100.0%] > ;; succ: > : > Well BB 1 is not supposed to have any succ anyways as it is the exit block. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43083
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #43 from dominiq at lps dot ens dot fr 2010-02-18 18:44 --- The compilation of gcc/regrename.c fails with ... cc1: warnings being treated as errors ../../gcc-4.5-work/gcc/regrename.c: In function 'build_def_use': ../../gcc-4.5-work/gcc/regrename.c:1113:6: error: array subscript has type 'char' The line is has_dup[recog_data.dup_num[i]] = true; trying has_dup[(int) recog_data.dup_num[i]] = true; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug tree-optimization/43083] [4.5 Regression] ICE: SIGSEGV with -fgraphite-identity
--- Comment #5 from pinskia at gcc dot gnu dot org 2010-02-18 18:46 --- Hmm, this code is undefined first but that does not matter. The issue comes down to return statements not being combined into just one return statement. I don't know if this is supposed to happen this way or not. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43083
[Bug libstdc++/42460] man page errors for generated libstdc++ man pages
--- Comment #23 from bkoz at redhat dot com 2010-02-18 19:09 --- Subject: Re: man page errors for generated libstdc++ man pages > 2010-02-17 09:36 --- So... shall we close this as fixed? Remaining item is doxygen function markup is not working for man pages. But this is an upstream (doxygen) doxygen, and this closed. I do not see any other thing to do from a libstdc++ POV. Original reporter calls? -benjamin -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42460
[Bug middle-end/42220] [4.5 Regression] FAIL: gfortran.dg/complex_intrinsic_5.f90 -m64 -O -frename-registers
--- Comment #44 from dominiq at lps dot ens dot fr 2010-02-18 19:10 --- The patch in comment #43 with the fix in comment #44 works for the limited tests I am able to do right now. I can do a "full" test with a fresh bootstrap of gcc and fortran, but it will take a full day, so I'ld prefer to do it during the week-end. Thanks for the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42220
[Bug target/43070] [4.5 Regression] g++.dg/ext/label2.C fails to compile at -O1
--- Comment #3 from jason at gcc dot gnu dot org 2010-02-18 19:20 --- Subject: Bug 43070 Author: jason Date: Thu Feb 18 19:20:21 2010 New Revision: 156872 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156872 Log: PR c++/43070 * semantics.c (finish_goto_stmt): Don't call decay_conversion. Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/ext/label1.C trunk/gcc/testsuite/g++.dg/ext/label2.C -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43070
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #20 from manu at gcc dot gnu dot org 2010-02-18 19:44 --- (In reply to comment #15) > Subject: Re: warnings about 'mangling of 'va_list' has changed > in GCC 4.4' not suppressed in sytem headers > > manu at gcc dot gnu dot org wrote: > > > Why is this a note and not simply a warning? > > Because, as noted earlier, it's not reflective of any likely problem in > the user's code. I think a warning is appropriate if the compiler > detects something which might indicate a bug in the application, but > this is just the compiler telling you about that something might go > wrong if you linked with code form a different version of G++. Which is > unlikely, and might go wrong for other reasons too. So it is the compiler telling you that something might go wrong and you can silence it with -Wno-psabi, which is a warning option. Moreover, as it stands now, if someone has -Werror=psabi, the compilation will not stop and they might get bitten by this. Moreover2, -w will not silence the note. I still completely fail to see why it is a note and not a warning. In any case, using diagnostic_report_warnings_p (location) should fix it. -- manu at gcc dot gnu dot org changed: What|Removed |Added CC|manu at gcc dot gnu dot org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug c/41843] segfault using '-O -fipa-struct-reorg -fwhole-program'
--- Comment #8 from steven at gcc dot gnu dot org 2010-02-18 19:46 --- Olga, is this fixed? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41843
[Bug tree-optimization/41843] segfault using '-O -fipa-struct-reorg -fwhole-program'
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41843
[Bug c++/42748] warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers
--- Comment #21 from mark at codesourcery dot com 2010-02-18 19:47 --- Subject: Re: warnings about 'mangling of 'va_list' has changed in GCC 4.4' not suppressed in sytem headers manu at gcc dot gnu dot org wrote: > In any case, using diagnostic_report_warnings_p (location) should fix it. AFAICT, this is not the case; at the point of mangling, input_location does not necessarily reflect the location at which the function was declared. Julian Brown and I are looking into this. Thanks, -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42748
[Bug tree-optimization/39806] incorrect pointer hashing in ipa-struct-reorg.c
--- Comment #5 from steven at gcc dot gnu dot org 2010-02-18 19:48 --- Olga, is this fixed? -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39806
[Bug debug/43077] VTA issues caused by SSA expand
--- Comment #6 from jakub at gcc dot gnu dot org 2010-02-18 19:49 --- I doubt http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43077#c4 applies cleanly to the current tree, as http://gcc.gnu.org/viewcvs?view=revision&revision=156693 changed the same spot as the second hunk. Will need to see why eliminate_regs_in_insn doesn't eliminate those. Regarding a/b/c on the a = foo (&b, &c) line, it is true that the breakpoint on that line might be on some insn that is scheduled earlier than b = 0 resp. c = 0 store. Perhaps we could have a DEBUG_INSN very early at the spot where the variable appear in the scope that would tell the value is 0, but I guess that should be handled separately from that, so I'll nuke that from the testcase for now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43077
[Bug c++/43108] [4.5 regression] mixed complex multiplication horribly inefficient
--- Comment #32 from jason at gcc dot gnu dot org 2010-02-18 19:58 --- Subject: Bug 43108 Author: jason Date: Thu Feb 18 19:58:41 2010 New Revision: 156874 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156874 Log: PR c++/43108 * typeck.c (cp_build_binary_op): Adapt mixed complex/non handling from C build_binary_op. * cp-tree.h (WANT_VECTOR_OR_COMPLEX): Rename from WANT_VECTOR. * cvt.c (build_expr_type_conversion): Allow COMPLEX_TYPE. Added: trunk/gcc/testsuite/c-c++-common/complex-alias-1.c - copied, changed from r156873, trunk/gcc/testsuite/gcc.dg/torture/complex-alias-1.c trunk/gcc/testsuite/c-c++-common/complex-sign-add.c - copied, changed from r156873, trunk/gcc/testsuite/gcc.dg/torture/complex-sign-add.c trunk/gcc/testsuite/c-c++-common/complex-sign-mixed-add.c - copied, changed from r156873, trunk/gcc/testsuite/gcc.dg/torture/complex-sign-mixed-add.c trunk/gcc/testsuite/c-c++-common/complex-sign-mixed-div.c - copied, changed from r156873, trunk/gcc/testsuite/gcc.dg/torture/complex-sign-mixed-div.c trunk/gcc/testsuite/c-c++-common/complex-sign-mixed-mul.c - copied, changed from r156873, trunk/gcc/testsuite/gcc.dg/torture/complex-sign-mixed-mul.c trunk/gcc/testsuite/c-c++-common/complex-sign-mixed-sub.c - copied, changed from r156873, trunk/gcc/testsuite/gcc.dg/torture/complex-sign-mixed-sub.c trunk/gcc/testsuite/c-c++-common/complex-sign-mul-minus-one.c - copied, changed from r156873, trunk/gcc/testsuite/gcc.dg/torture/complex-sign-mul-minus-one.c trunk/gcc/testsuite/c-c++-common/complex-sign-mul-one.c - copied, changed from r156873, trunk/gcc/testsuite/gcc.dg/torture/complex-sign-mul-one.c trunk/gcc/testsuite/c-c++-common/complex-sign-mul.c - copied, changed from r156873, trunk/gcc/testsuite/gcc.dg/torture/complex-sign-mul.c trunk/gcc/testsuite/c-c++-common/complex-sign-sub.c - copied, changed from r156873, trunk/gcc/testsuite/gcc.dg/torture/complex-sign-sub.c trunk/gcc/testsuite/c-c++-common/complex-sign.h - copied, changed from r156873, trunk/gcc/testsuite/gcc.dg/torture/complex-sign.h Removed: trunk/gcc/testsuite/gcc.dg/torture/complex-alias-1.c trunk/gcc/testsuite/gcc.dg/torture/complex-sign-add.c trunk/gcc/testsuite/gcc.dg/torture/complex-sign-mixed-add.c trunk/gcc/testsuite/gcc.dg/torture/complex-sign-mixed-div.c trunk/gcc/testsuite/gcc.dg/torture/complex-sign-mixed-mul.c trunk/gcc/testsuite/gcc.dg/torture/complex-sign-mixed-sub.c trunk/gcc/testsuite/gcc.dg/torture/complex-sign-mul-minus-one.c trunk/gcc/testsuite/gcc.dg/torture/complex-sign-mul-one.c trunk/gcc/testsuite/gcc.dg/torture/complex-sign-mul.c trunk/gcc/testsuite/gcc.dg/torture/complex-sign-sub.c trunk/gcc/testsuite/gcc.dg/torture/complex-sign.h Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cp-tree.h trunk/gcc/cp/cvt.c trunk/gcc/cp/typeck.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
[Bug c++/43108] [4.5 regression] mixed complex multiplication horribly inefficient
--- Comment #33 from jason at gcc dot gnu dot org 2010-02-18 19:59 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
[Bug c++/43109] [4.5 Regression] ICE: SIGSEGV with unnamed namespace inside named
--- Comment #2 from jason at gcc dot gnu dot org 2010-02-18 20:01 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43109
[Bug c++/43108] [4.5 regression] mixed complex multiplication horribly inefficient
--- Comment #34 from paolo dot carlini at oracle dot com 2010-02-18 20:18 --- Thanks Jason! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43108
[Bug c++/9990] locale_facets.h contains invalid typedef
--- Comment #9 from bangerth at gmail dot com 2010-02-18 20:29 --- (In reply to comment #8) > For the record, all the compilers I have at hand, EDG based too, accept this > in > the most strict mode. I seriously doubt there is really something to fix here. That said: if it is unclear to people well versed in the language standard whether the code is correct or not (and does what it is supposed to do or not) then one could argue that the code is also hard to read. In other words: there may not be a need to change the code for *correctness reasons*, but the *is* a need to change the code to make it more maintainable. I believe that's a valid argument in software design to change things. W. -- bangerth at gmail dot com changed: What|Removed |Added CC||bangerth at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9990
[Bug c++/9990] locale_facets.h contains invalid typedef
--- Comment #10 from paolo dot carlini at oracle dot com 2010-02-18 20:36 --- I'm not sure to fully understand, Wolfgang: you mean, we should change that line in the library instead of dealing with a possible C++ issue here? That would be easy to do, just tell me the exact form you would like to see, whose correctness you are 101% sure about, and let's close this PR! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9990
[Bug middle-end/42837] [4.5 Regression] FAIL: g++.dg/abi/packed1.C execution test
-- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-02-16 18:48:29 |2010-02-18 20:46:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42837
[Bug target/43070] [4.5 Regression] g++.dg/ext/label2.C fails to compile at -O1
--- Comment #4 from jason at gcc dot gnu dot org 2010-02-18 20:47 --- Fixed. -- jason at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43070
[Bug c/39170] cannot silence -Wconversion warnings for bit-fields
--- Comment #8 from Zachary_Deretsky at mentor dot com 2010-02-18 20:50 --- With -Wconversion for the assignment to bitfields gcc 4.4.2 gives a warning, which is impossible to fix. This BUG (I hope everybody agrees it is a BUG) gives us a lot of trouble while porting our code (45 developers, 7 year history) from 4.2.4 to 4.4.2 We spent a lot of effort to make our code clean with -Wshadow -Wconversion -Wall -Werror flags and now our only choice is to remove -Wconversion. Please assign and fix this ASAP. Thank you, Zach. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39170
[Bug c++/9990] locale_facets.h contains invalid typedef
--- Comment #11 from bangerth at gmail dot com 2010-02-18 20:53 --- (In reply to comment #10) > I'm not sure to fully understand, Wolfgang: you mean, we should change that > line in the library instead of dealing with a possible C++ issue here? That > would be easy to do, just tell me the exact form you would like to see, whose > correctness you are 101% sure about, and let's close this PR! I think there are two issues: 1/ A possible bug in the C++ front end, though from what I read Nathan felt unsure about it. 2/ A poorly written typedef that, depending on the outcome of 1/ may or may not be invalid, but in any case isn't easy to understand to the human reader. Ideally, there would be separate PRs about these two issues. I was just addressing the second point, which could be solved by replacing typedef typename ctype::mask mask; by typedef typename __ctype_abstract_base<_CharT>::mask mask; which makes it abundantly clear that ctype::mask is not meant to be a reference to the typedef we are currently declaring. Best W. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9990
[Bug c++/9990] locale_facets.h contains invalid typedef
--- Comment #12 from paolo dot carlini at oracle dot com 2010-02-18 20:55 --- Bah, I can do the change, sure, but if we are not resolving this issue, we are not making progress on the number of open, long-standing, Bugzilla entries, and that is *bad*. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9990
[Bug c++/9990] locale_facets.h contains invalid typedef
--- Comment #13 from paolo dot carlini at oracle dot com 2010-02-18 20:57 --- The library issue doesn't exist anymore ;) Thus, let's not be distracted by the trivial library case, ok? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9990
[Bug tree-optimization/41843] segfault using '-O -fipa-struct-reorg -fwhole-program'
--- Comment #9 from olga at il dot ibm dot com 2010-02-18 21:07 --- (In reply to comment #8) > Olga, is this fixed? I think so. Olga. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41843
[Bug libstdc++/22200] numeric_limits::is_modulo is inconsistent with gcc
--- Comment #24 from paolo dot carlini at oracle dot com 2010-02-18 22:03 --- Richard, can you comment on this issue? Do you think it's currently correct to have numeric_limits<>:is_modulo == true for all our signed integral types? We are not making any progress on this issue :( -- paolo dot carlini at oracle dot com changed: What|Removed |Added CC||rguenth at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22200
[Bug objc/43061] 47 new GCC h...@156527 regressions
--- Comment #36 from mikestump at comcast dot net 2010-02-18 22:06 --- I've checked in a slightly updated fix in r156877. Let us know if all the regressions are fixed now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43061
[Bug target/43047] internal compiler error: in extract_insn, at recog.c:2048
--- Comment #6 from rearnsha at gcc dot gnu dot org 2010-02-18 23:09 --- Please supply pre-processed source that will allow a developer to reproduce the problem. -- rearnsha at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43047
