[Bug c++/42797] call of overloaded 'allocator()' is ambiguous
--- Comment #1 from foom at fuhm dot net 2010-01-19 06:15 --- Error also occurs with: g++ -O1 -fipa-sra -g -std=c++0x -c test.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42797
[Bug fortran/42772] [4.5 Regression] ICE at fold-const.c:10033
--- Comment #6 from pault at gcc dot gnu dot org 2010-01-19 06:04 --- Ah, I was being stupid; now I see what test case 2 actually is. duuh, I did not think to go to comment #10! My patch that was just posted does indeed fix this, so I'll take it on. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-01-16 22:16:01 |2010-01-19 06:04:44 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42772
[Bug c++/42797] New: call of overloaded 'allocator()' is ambiguous
On Linux x86_64
g++ --version:
g++ (Debian 20100117-1) 4.5.0 20100117 (experimental) [trunk revision 155979]
Compiling with:
g++ -O2 -g -std=c++0x -c test.cpp
The following program:
#include
#include
struct Foo {
Foo() {}
template
Foo(Tp *p) {}
};
void foo() {
std::map > the_map;
the_map[1] = std::vector();
}
Produces the below error. However, it *doesn't* produce an error if compiled
without the -g switch (nor with -O1 instead of -O2).
In file included from /usr/include/c++/4.5.0/bits/move.h:38:0,
from /usr/include/c++/4.5.0/bits/stl_pair.h:60,
from /usr/include/c++/4.5.0/bits/stl_algobase.h:66,
from /usr/include/c++/4.5.0/vector:61,
from test.cpp:1:
/usr/include/c++/4.5.0/type_traits: In constructor 'std::vector<_Tp,
_Alloc>::vector(std::vector::size_type, const value_type&, const
allocator_type&) [with _Tp = Foo, _Alloc = std::allocator,
std::vector::size_type = long unsigned int, value_type = Foo, allocator_type =
std::allocator]':
/usr/include/c++/4.5.0/type_traits:224:67: instantiated from 'const bool
std::__is_constructible_helper, const int&&>::__value'
/usr/include/c++/4.5.0/type_traits:235:5: instantiated from
'std::is_constructible, const int&&>'
/usr/include/c++/4.5.0/bits/stl_map.h:451:11: instantiated from here
/usr/include/c++/4.5.0/type_traits:224:67: error: call of overloaded
'allocator()' is ambiguous
/usr/include/c++/4.5.0/bits/allocator.h:103:7: note: candidates are:
std::allocator<_Tp>::allocator(const std::allocator<_Tp>&) [with _Tp = Foo,
std::allocator<_Tp> = std::allocator]
/usr/include/c++/4.5.0/bits/allocator.h:101:7: note:
std::allocator<_Tp>::allocator() [with _Tp = Foo]
/usr/include/c++/4.5.0/type_traits:224:67: error: call of overloaded
'allocator()' is ambiguous
/usr/include/c++/4.5.0/bits/allocator.h:103:7: note: candidates are:
std::allocator<_Tp>::allocator(const std::allocator<_Tp>&) [with _Tp = Foo,
std::allocator<_Tp> = std::allocator]
/usr/include/c++/4.5.0/bits/allocator.h:101:7: note:
std::allocator<_Tp>::allocator() [with _Tp = Foo]
/usr/include/c++/4.5.0/type_traits:218:2: error: call of overloaded
'allocator()' is ambiguous
/usr/include/c++/4.5.0/bits/allocator.h:103:7: note: candidates are:
std::allocator<_Tp>::allocator(const std::allocator<_Tp>&) [with _Tp = Foo,
std::allocator<_Tp> = std::allocator]
/usr/include/c++/4.5.0/bits/allocator.h:101:7: note:
std::allocator<_Tp>::allocator() [with _Tp = Foo]
--
Summary: call of overloaded 'allocator()' is ambiguous
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: foom at fuhm dot net
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42797
[Bug lto/42762] ICE in get_resolution() when compiling a C++ program with -flto -fuse-linker-plugin
--- Comment #1 from espindola at gcc dot gnu dot org 2010-01-19 04:45 --- The problem is coming from DECL_FUNCTION_PERSONALITY (expr) = lto_input_tree (ib, data_in); This reads in __gxx_personality_v0 as an external function and we try to add it to the symbol table. If using the linker plugin this fails because there is no reference to __gxx_personality_v0 in the symbol table. Two options: * There should be an undefined reference and we are missing it in produce_symtab * There should not be an undefined reference. In this case maybe DECL_FUNCTION_PERSONALY should not be set or we should be ignoring it in this case for some reason I don't think there should be an undefined reference to the personality in this test. The produced assembly never mentions a personality function... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42762
[Bug c/42796] New: ICE on building libstdc++-v3
libstdc++-v3/config.log is: configure: In function 'void foo()': configure:14896:1: error: in basic block 2: configure:14896:1: error: flow control insn inside a basic block (jump_insn 36 35 37 2 (parallel [ (set (pc) (if_then_else (ne:HI (reg:HI 2 r2) (const_int 0 [0x0])) (label_ref 40) (pc))) (clobber (reg:BI 16 carry)) ]) -1 (nil) -> 40) configure:14896:1: internal compiler error: in rtl_verify_flow_info_1, at cfgrtl.c:2013 Please submit a full bug report, with preprocessed source if appropriate. -- Summary: ICE on building libstdc++-v3 Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: monaka at monami-software dot com GCC build triplet: i386-apple-darwin10.2.0 GCC host triplet: i386-apple-darwin10.2.0 GCC target triplet: xstormy16-elf http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42796
[Bug c/42795] false "statement has no effect" message
--- Comment #5 from jrt at worldlinc dot net 2010-01-19 03:15 --- Ahhh, i see. It appears that i is not assigned at the start of the loop. I assigned it just before the loop, so the loop starts at the correct value. I tried doing the assignment with an otherwise useless variable, don't recall what messages resulted in that try. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42795
[Bug c/42795] false "statement has no effect" message
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-01-19 03:01 ---
(In reply to comment #3)
> So setting a variable as the coder desires is no effect? Some would disagree.
>
> A statement that really would not have an effect would be:
>
> if (theworldis > notenough);
No that is not is being warned about. The statement that is being warned about
is just "i;" which is the same inside a for statement as it is outside one.
Both are statements have no effect as it does nothing.
Take:
void f(int i)
{
i;
}
Do you think that should be warned about? That is the exact same thing which
is being warned about when you have:
void f(int i)
{
for(i; ; )
}
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42795
[Bug c/42795] false "statement has no effect" message
--- Comment #3 from jrt at worldlinc dot net 2010-01-19 02:58 --- So setting a variable as the coder desires is no effect? Some would disagree. A statement that really would not have an effect would be: if (theworldis > notenough); The comparison indicated here perhaps is performed, but there is no result to subsequently use, no variable changed. What I reported is not the genuine "no effect" condition I just described here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42795
[Bug bootstrap/42785] error: impossible constraint in 'asm'
--- Comment #6 from pinskia at gcc dot gnu dot org 2010-01-19 02:45 --- >They are inconsistent, right? No because i386-driver.c is only supposed to be compiled with a x86 or x86_64 compiler. Really the file could have #if !defined(__i386__) && !defined(__x86_64__) #error "This should only be compiled with an x86 compiler" #endif And still be correct. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42785
[Bug bootstrap/42785] error: impossible constraint in 'asm'
--- Comment #5 from monaka at monami-software dot com 2010-01-19 02:42 --- (In reply to comment #3) > driver-i386.c should not be included if you are compiling for a PPC host/build > really. So it is a problem of you misconfiguring GCC really and nothing else. I see what you want to say, but. The another viewpoint: In i386-driver.c, there is decided by "#ifdef __GNUC__" which host_detect_local_cpu (dummy or not) is used In i386.h, there is decided by "#if defined(__i386__) || defined(__x86_64__) if it defines EXTRA_SPEC_FUNCTIONS . They are inconsistent, right? P.S. Thanks for your information about lipo. I know about it and I've already released binary distributions. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42785
[Bug fortran/42353] [fortran-dev] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...
--- Comment #23 from jvdelisle at gcc dot gnu dot org 2010-01-19 02:37 --- Janus, reassigning to myself. I think I see a problem in the error checking logic and I have a tentative patch that has regression tested fine. I want to think a bit about whether I an fixing this correctly. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|janus at gcc dot gnu dot org|jvdelisle at gcc dot gnu dot ||org Status|REOPENED|ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42353
[Bug c/42795] false "statement has no effect" message
--- Comment #2 from pinskia at gcc dot gnu dot org 2010-01-19 02:14 --- >gnuchess.c:1021: warning: statement with no effect This warning is correct as: i; has no effect. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42795
[Bug c/42795] false "statement has no effect" message
--- Comment #1 from jrt at worldlinc dot net 2010-01-19 01:22 --- I used inaccurate phrasing. I should have said that The compiler flags used in compiling THE FOLLOWING were -O3 -funroll-loops. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42795
[Bug c/42795] New: false "statement has no effect" message
I apologize for not knowing much about GCC bug filing, like the triplet info
requested above. I am using a GCC 4.3.4 with the following configuration:
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.3.4/./configure --prefix=/usr
Thread model: posix
gcc version 4.3.4 (GCC)
It's compiled on a Mandriva 2007.0 Linux system with glibc-2.4-7 from Mandriva.
The compiler flags used in compiling this were -O3 -funroll-loops.
The following statement has the purpose of scanning some array elements until
the condition isn't met, and then the variable i has the info I want. So this
is not a statement with no effect because it's found something. Below the
statement are two console lines showing GCC's error message.
if ((i > prunecap) && (deep > 1)) /* Trim lemons early */
{ /* remove with slope test, saving at least prunecap */
for (i; (((max - Tree[i].score) > i) && (i >= margin)); i--);
}
gnuchess.c: In function âBackPruneâ:
gnuchess.c:1021: warning: statement with no effect
Thought you'd like to know.
--
Summary: false "statement has no effect" message
Product: gcc
Version: 4.3.4
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jrt at worldlinc dot net
GCC build triplet: i686-pc-linux-gnu
GCC host triplet: I586-Mandriva-Linux?
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42795
[Bug middle-end/42169] [4.4/4.5 Regression] gfortran.dg/pr41928.f90:47: internal compiler error: in store_can_be_removed_p, at ira-emit.c:371
--- Comment #2 from danglin at gcc dot gnu dot org 2010-01-19 01:01 --- Still present in revision 155956. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42169
[Bug fortran/42353] [fortran-dev] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...
--- Comment #22 from jvdelisle at gcc dot gnu dot org 2010-01-19 00:25 --- Obviously we do not have the original test case added to the testsuite so we can catch these things. I added gfcbug96d.f90 to the testsuite, thinking it was the same issue as gfcbug96.f90. Lets just reopen this PR, noting that the various cases listed have differing issues and that we need to add test cases for each in the test suite. -- jvdelisle at gcc dot gnu dot org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42353
[Bug bootstrap/42785] error: impossible constraint in 'asm'
--- Comment #4 from pinskia at gcc dot gnu dot org 2010-01-19 00:13 --- More to the point, use lipo to combine the gcc drivers after the fact to get a dual arch executable. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42785
[Bug c/42787] Failed to "make all-target"
--- Comment #5 from monaka at monami-software dot com 2010-01-19 00:11 --- There are no GTY tags in t-h8300.h and t-m32r.h. Is this an indirect cause? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42787
[Bug bootstrap/42785] error: impossible constraint in 'asm'
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-01-19 00:10 --- driver-i386.c should not be included if you are compiling for a PPC host/build really. So it is a problem of you misconfiguring GCC really and nothing else. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42785
[Bug middle-end/42794] PRE produces illegal PHI node
--- Comment #3 from paolo dot carlini at oracle dot com 2010-01-18 23:57 --- But really, test up to date 4.4 branch or mainline. Thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42794
[Bug middle-end/42794] PRE produces illegal PHI node
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-18 23:57 --- I'm sorry, maybe you didn't mean the compiler loops, you mean the code is miscompiled to an infinite loop?!? -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|WORKSFORME | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42794
[Bug middle-end/42794] PRE produces illegal PHI node
--- Comment #1 from paolo dot carlini at oracle dot com 2010-01-18 23:52 --- Works fine for me with current mainline and 4_4-branch. Please, fetch the current sources and try again, if you can still see something wrong re-open, or file a different issue if the problem is different. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.4.1 4.4.3 4.5.0 Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42794
[Bug middle-end/42794] New: PRE produces illegal PHI node
The following (reduced) code:
typedef enum {
TYPE_NON_IDR,
TYPE_IDR,
} NAL_UNIT_TYPE;
typedef struct recordTag
{
} Record;
typedef struct {
unsigned int ActualSize;
unsigned short *Slice;
}Info;
typedef struct {
} Params;
typedef struct {
NAL_UNIT_TYPE unit_type;
} NAL_UNIT;
unsigned int foo( Info *Decode, unsigned int nal_len)
{
NAL_UNIT nal_unit;
unsigned short *Backend;
unsigned char complete;
int *BufLen = (int *)&Decode->ActualSize;
do{
*BufLen = *BufLen - nal_len;
if (((nal_unit.unit_type) == TYPE_NON_IDR))
{
Decode->Slice = Backend;
}
}while (*BufLen >0);
Finish( &complete);
}
Produces infinite loop with this options: -O2
>gcc -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --enable-threads=posix
--prefix=/x/x86_gcc_4.4/bin --enable-languages=c,c++ --disable-checking
Thread model: posix
gcc version 4.4.0 (GCC)
The issue first appears in tree PRE (from reduced2.c.084t.pre):
...
:
D.1896_2 = &Decode_1(D)->ActualSize;
BufLen_3 = (int *) D.1896_2;
pretmp.16_34 = Decode_1(D)->ActualSize;
:
# prephitmp.17_35 = PHI
D.1907_14 = prephitmp.17_35;
D.1899_7 = D.1907_14 - nal_len_6(D);
D.1900_8 = (int) D.1899_7;
*BufLen_3 = D.1900_8;
if (nal_unit$unit_type_16(D) == 0)
goto ;
else
goto ;
:
goto ;
:
Decode_1(D)->Slice = Backend_10(D);
pretmp.16_36 = Decode_1(D)->ActualSize;
:
# prephitmp.17_37 = PHI
D.1905_12 = prephitmp.17_37;
D.1906_13 = (int) D.1905_12;
if (D.1906_13 > 0)
goto ;
else
goto ;
The first "argument" of this PHI: # prephitmp.17_37 = PHI is wrong - instead of decremented value it uses original one.
PRE only makes an earlier DF analysis issue evident. The problem is elsewhere.
Any suggestions are highly appreciated.
--
Summary: PRE produces illegal PHI node
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: middle-end
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: sergei_lus at yahoo dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42794
[Bug bootstrap/42785] error: impossible constraint in 'asm'
--- Comment #2 from monaka at monami-software dot com 2010-01-18 23:29 --- (In reply to comment #1) > If you use -arch ppc, then the host/build is really powerpc-apple-darwin so > obviously you are configuring GCC incorrectly and the error message is correct > as that is x86 inline-asm that is being compiled in that source. There is no need to use -arch option if we use powerpc-apple-darwin host/build. I think it can be resolved by a patch follows. diff --git a/gcc/config/i386/driver-i386.c b/gcc/config/i386/driver-i386.c index 17694ef..dc69a80 100644 --- a/gcc/config/i386/driver-i386.c +++ b/gcc/config/i386/driver-i386.c @@ -25,7 +25,7 @@ along with GCC; see the file COPYING3. If not see const char *host_detect_local_cpu (int argc, const char **argv); -#ifdef __GNUC__ +#if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__)) #include "cpuid.h" struct cache_desc -- monaka at monami-software dot com changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID | Summary|error: impossible constraint|error: impossible constraint |in �easm�f |in 'asm' http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42785
[Bug c/42787] Failed to "make all-target"
--- Comment #4 from monaka at monami-software dot com 2010-01-18 23:21 --- (In reply to comment #3) > It rather seems you do not have proper target headers. What's "proper target headers"? If it's t-m32r.h, I have it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42787
[Bug c++/42634] ICE with -g -O2 -std=c++0x in copy_fn_p, at cp/decl.c:9973
--- Comment #13 from dodji at gcc dot gnu dot org 2010-01-18 23:14 --- Subject: Bug 42634 Author: dodji Date: Mon Jan 18 23:14:01 2010 New Revision: 156026 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156026 Log: Revert fix of PR c++/ gcc/cp/ChangeLog: * error.c (dump_template_parms, count_non_default_template_args): Revert fix of PR c++/42634. gcc/testsuite/ChangeLog: * g++.dg/template/error45.C: reverted as part of reverting the fix of PR c++/42634. Removed: trunk/gcc/testsuite/g++.dg/template/error45.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42634
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #24 from gcc at coreland dot ath dot cx 2010-01-18 22:53 --- Created an attachment (id=19653) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19653&action=view) A smaller repro for the "_master conflicts with declaration" error $ gnatmake arc_dir_003.adb gcc -c arc_dir_003.adb arc_dir_003.adb:29:26: "_master" conflicts with declaration at line 30 gnatmake: "arc_dir_003.adb" compilation error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42150] GNAT (really) appears to misbehave with limited types/finalization/extended return
--- Comment #23 from gcc at coreland dot ath dot cx 2010-01-18 22:51 --- Created an attachment (id=19652) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19652&action=view) Another repro A smaller, simpler piece of code that triggers this: $ gnatmake p.adb p.adb:8:70: wrong type for return_subtype_indication gnatmake: "p.adb" compilation error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42150
[Bug ada/42793] Bug box when using generic package
--- Comment #3 from gcc at coreland dot ath dot cx 2010-01-18 22:46 --- Created an attachment (id=19651) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19651&action=view) Another repro This appears to be the same bug but giving a slightly more interesting crash message: $ gnatchop proto1.adb $ gnatmake proto1.adb +===GNAT BUG DETECTED==+ | 4.4.0 (x86_64-unknown-freebsd8.0) GCC error: | | in simplify_subreg, at simplify-rtx.c:4954 | | Error detected around protocol.adb:4 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. list may be incomplete raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:424 gnatmake: "protocol.adb" compilation error -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42793
[Bug tree-optimization/42773] [4.4 Regression] ICE with g++ from 4.4.3 20100112 (prerelease)
--- Comment #7 from chris2553 at googlemail dot com 2010-01-18 22:24 --- I can confirm that the patch at comment 4 has fixed the ICE. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42773
[Bug fortran/42353] [fortran-dev] Bogus Error: Name 'vtype$...' at (1) is an ambiguous reference ...
--- Comment #21 from anlauf at gmx dot de 2010-01-18 22:18 --- (In reply to comment #19) > > Regressions on fortran-dev branch fixed. > > Due to the patch in > > http://gcc.gnu.org/ml/fortran/2009-12/msg00232.html Jerry, is this patch supposed to be complete for fortran-dev? I still get this failure with the latest fortran-dev on the original testcase: gfcbug96.f90:43.23: use concrete_gradient 1 Error: The element in the derived type constructor at (1), for pointer component '$extends', is DERIVED but should be DERIVED Should I open a new PR for this one? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42353
[Bug c/42790] ICE on building libgcc.c __muldi3.
--- Comment #1 from monaka at monami-software dot com 2010-01-18 22:07 --- Created an attachment (id=19650) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19650&action=view) Preprocessed source. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42790
[Bug target/42774] [4.4/4.5 Regression] ICE in get_aligned_mem, at config/alpha/alpha.c:1484
--- Comment #14 from ubizjak at gmail dot com 2010-01-18 21:48 --- Fixed. -- ubizjak at gmail dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.4.3 4.5.0 |4.3.4 4.4.3 4.5.0 Known to work|4.3.4 | Resolution||FIXED Target Milestone|4.4.3 |4.3.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42774
[Bug target/42774] [4.4/4.5 Regression] ICE in get_aligned_mem, at config/alpha/alpha.c:1484
--- Comment #13 from uros at gcc dot gnu dot org 2010-01-18 21:44 --- Subject: Bug 42774 Author: uros Date: Mon Jan 18 21:44:32 2010 New Revision: 156024 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156024 Log: PR target/42774 * config/alpha/predicates.md (aligned_memory_operand): Return 0 for memory references with unaligned offsets. Remove CQImode handling. (unaligned_memory_operand): Return 1 for memory references with unaligned offsets. Remove CQImode handling. testsuite/ChangeLog: PR target/42774 * gcc.target/alpha/pr42774.c: New test. Added: branches/gcc-4_3-branch/gcc/testsuite/gcc.target/alpha/pr42774.c Modified: branches/gcc-4_3-branch/gcc/ChangeLog branches/gcc-4_3-branch/gcc/config/alpha/predicates.md branches/gcc-4_3-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42774
[Bug c++/42634] ICE with -g -O2 -std=c++0x in copy_fn_p, at cp/decl.c:9973
--- Comment #12 from dodji at gcc dot gnu dot org 2010-01-18 21:19 --- Subject: Bug 42634 Author: dodji Date: Mon Jan 18 21:18:49 2010 New Revision: 156022 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156022 Log: Fix PR c++/42634 gcc/cp/ChangeLog: PR c++/42634 * error.c (dump_template_parms): Use innermost template arguments before calling count_non_default_template_args. (count_non_default_template_args): We are being called with template innermost arguments now. There is no need to ensure that again. gcc/testsuite/ChangeLog: PR c++/42634 * g++.dg/template/error45.C: New test. Added: trunk/gcc/testsuite/g++.dg/template/error45.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/error.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42634
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility with static common vars.
--- Comment #26 from simon at pushface dot org 2010-01-18 20:54 --- (In reply to comment #22) > No longer bootstrap issue, but still ICE on valid. The problem is that the ICE-on-valid occurs while building the Ada RTS, and that is a bootstrap issue for Ada (what I mean is, a build configured with "--enable-languages=foo,ada" will fail). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility with static common vars.
--- Comment #25 from simon at pushface dot org 2010-01-18 20:41 --- OK on i86_64-apple-darwin10.2, powerpc-wrs-vxworks (hosted on i366-apple-darwin10.2). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug fortran/42772] [4.5 Regression] ICE at fold-const.c:10033
--- Comment #5 from pault at gcc dot gnu dot org 2010-01-18 19:55 ---
Index: gcc/fortran/trans-decl.c
===
*** gcc/fortran/trans-decl.c(revision 155875)
--- gcc/fortran/trans-decl.c(working copy)
*** gfc_generate_function_code (gfc_namespac
*** 4256,4262
stmtblock_t block;
stmtblock_t body;
tree result;
! tree recurcheckvar = NULL;
gfc_symbol *sym;
int rank;
bool is_recursive;
--- 4257,4263
stmtblock_t block;
stmtblock_t body;
tree result;
! tree recurcheckvar = NULL_TREE;
gfc_symbol *sym;
int rank;
bool is_recursive;
*** gfc_generate_function_code (gfc_namespac
*** 4446,4456
gfc_add_expr_to_block (&block, tmp);
/* Reset recursion-check variable. */
if ((gfc_option.rtcheck & GFC_RTCHECK_RECURSION) && !is_recursive
! && !gfc_option.flag_openmp)
! {
! gfc_add_modify (&block, recurcheckvar, boolean_false_node);
! recurcheckvar = NULL;
! }
}
--- 4447,4457
gfc_add_expr_to_block (&block, tmp);
/* Reset recursion-check variable. */
if ((gfc_option.rtcheck & GFC_RTCHECK_RECURSION) && !is_recursive
! && !gfc_option.flag_openmp && recurcheckvar != NULL_TREE)
! {
! gfc_add_modify (&block, recurcheckvar, boolean_false_node);
! recurcheckvar = NULL_TREE;
! }
}
Gets rid of the trivial problem reported by Richard.
Cheers
Paul
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42772
[Bug tree-optimization/42642] "-fcompare-debug failure" with "-O1 -fpeel-loops"
--- Comment #6 from steven at gcc dot gnu dot org 2010-01-18 19:19 --- Same issue: web renaming a single-USE "web". *** This bug has been marked as a duplicate of 42685 *** -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42642
[Bug tree-optimization/42685] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops" (2)
--- Comment #6 from steven at gcc dot gnu dot org 2010-01-18 19:19 --- *** Bug 42642 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42685
[Bug c++/42766] [4.5 Regression] tree check fail in build_expr_type_conversion
--- Comment #9 from dodji at gcc dot gnu dot org 2010-01-18 19:17 --- Fixed in 4.5 -- dodji at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42766
[Bug tree-optimization/42685] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops" (2)
--- Comment #5 from steven at gcc dot gnu dot org 2010-01-18 19:16 ---
Register number differences appear - again - because a USE operand of a
DEBUG_INSN ends up in a web of its own:
--- R1web/pr42685-2.c.167r.web 2010-01-18 11:11:38.0 -0800
+++ R2web/pr42685-2.c.167r.web 2010-01-18 11:11:38.0 -0800
@@ -7,275 +7,323 @@
df_worklist_dataflow_doublequeue:n_basic_blocks 55 n_edges 83 count 108 (
2)
df_worklist_dataflow_doublequeue:n_basic_blocks 55 n_edges 83 count 109 (
2)
Web oldreg=386 newreg=401
-Updating insn 82 (386->401)
-deferring rescan insn with uid = 82.
-Web oldreg=371 newreg=402
-Updating insn 63 (371->402)
-deferring rescan insn with uid = 63.
-Web oldreg=375 newreg=403
-Updating insn 394 (375->403)
-deferring rescan insn with uid = 394.
+Updating insn 96 (386->401)
+deferring rescan insn with uid = 96.
+Web oldreg=375 newreg=402
+Updating insn 72 (375->402)
+deferring rescan insn with uid = 72.
+Web oldreg=371 newreg=403
+Updating insn 75 (371->403)
+deferring rescan insn with uid = 75.
+Updating insn 468 (375->402)
+deferring rescan insn with uid = 468.
...
@@ -413,12 +474,19 @@
(label_ref #)
(pc)))# {*br_true} (expr_list:REG_BR_PROB (const_int 7100
[0x1bbc])
(nil))
- -> 65)
+ -> 77)
(note# # # 10 [bb 10] NOTE_INSN_BASIC_BLOCK)
+(debug_insn# # # 10 pr42685-2.c:19 (var_location:DI D#2 (zero_extend:DI
(reg/v:SI 402 [ i ])))# (nil))
+
+(debug_insn# # # 10 pr42685-2.c:19 (var_location:DI D#1 (mult:DI
(debug_expr:DI D#2)
+(const_int 4 [0x4])))# (nil))
+
+(debug_insn# # # 10 pr42685-2.c:19 (var_location:DI s (clobber (const_int 0
[0x0])))# (nil))
+
(insn# # # 10 pr42685-2.c:10 (set (reg:SI 120 out0)
-(mem/s/j:SI (reg:DI 402 [ ivtmp.5 ]) [0 D.1998->i+0 S4 A32]))#
{movsi_internal} (nil))
+(mem/s/j:SI (reg:DI 403 [ ivtmp.5 ]) [0 D.1998->i+0 S4 A32]))#
{movsi_internal} (nil))
(call_insn# # # 10 pr42685-2.c:10 (parallel [
(call (mem:DI (symbol_ref:DI ("baz") [flags 0x41] ) [0 S8 A64])
This whole compare-debug stuff makes no sense to me, so I'm not even going to
try to come up with a fix. IMHO the proper fix would be to never even try to
rename a web that consists of just a single USE. I don't see how that is any
more "right" than no debug info at all since no DEF reaches the USE (i.e.
uninitialized) so any value represented in the debug info is fair and
reasonable.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|steven at gcc dot gnu dot |unassigned at gcc dot gnu
|org |dot org
Status|ASSIGNED|NEW
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42685
[Bug c++/42766] [4.5 Regression] tree check fail in build_expr_type_conversion
--- Comment #8 from dodji at gcc dot gnu dot org 2010-01-18 19:11 --- Subject: Bug 42766 Author: dodji Date: Mon Jan 18 19:11:24 2010 New Revision: 156020 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156020 Log: Fix PR c++/42766 gcc/cp/ChangeLog: PR c++/42766 * cvt.c (build_expr_type_conversion): Look through OVERLOAD. gcc/testsuite/ChangeLog: PR c++/42766 * g++.dg/conversion/op6.C: New test. Added: trunk/gcc/testsuite/g++.dg/conversion/op6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/cvt.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42766
[Bug target/42789] undefined reference to `__sync_fetch_and_add_4'
--- Comment #3 from pinskia at gcc dot gnu dot org 2010-01-18 18:48 --- This is a bug in boost and not GCC. Not all targets define the __sync_* functions. There is a define for each one saying which one is available. -- pinskia at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42789
[Bug driver/42690] Undefined reference errors with -flto -fuse-linker-plugin
--- Comment #15 from d dot g dot gorbachev at gmail dot com 2010-01-18 18:48 --- Created an attachment (id=19649) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19649&action=view) Simple patch It leaves -plugin-opt in LINK_COMMAND_SPEC, but I think it is not quite right, as LIBGCC_SPEC and LIB_SPEC are redefined by many targets (and, for example, choose libc or libc_p depending on -p / -pg / -profile). GCC r155915 bootstrapped with this patch on i686-pc-linux-gnu with and without --disable-shared option. It seems to work. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42690
[Bug tree-optimization/42642] "-fcompare-debug failure" with "-O1 -fpeel-loops"
-- steven at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |NEW Last reconfirmed|2010-01-07 07:17:23 |2010-01-18 18:31:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42642
[Bug ada/42793] Bug box when using generic package
--- Comment #2 from gcc at coreland dot ath dot cx 2010-01-18 18:14 --- Created an attachment (id=19648) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19648&action=view) Repro case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42793
[Bug ada/42793] Bug box when using generic package
--- Comment #1 from gcc at coreland dot ath dot cx 2010-01-18 18:13 --- I'm attempting to submit the repro case as an attachment but bugzilla keeps suffering internal errors. Admin contacted... -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42793
[Bug ada/42793] New: Bug box when using generic package
$ gnatchop unchopped.adb $ gnatmake protocol.adb +===GNAT BUG DETECTED==+ | 4.4.0 (x86_64-unknown-freebsd8.0) Storage_Error stack overflow or erroneous memory access| | Error detected at serial_io.adb:560:3 [protocol.ads:32:3]| | Please submit a bug report; see http://gcc.gnu.org/bugs.html.| | Use a subject line meaningful to you and us to track the bug.| | Include the entire contents of this bug box in the report. | | Include the exact gcc or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. protocol.adb protocol.ads serial_io.ads serial_io.adb compilation abandoned gnatmake: "protocol.adb" compilation error It crashes every version of GNAT that I can find on any platform. Unfortunately, I struggled to even write a summary line as I'm not sure what's wrong with the 'Serializable_Enumeration' package. -- Summary: Bug box when using generic package Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: gcc at coreland dot ath dot cx GCC host triplet: x86_64-unknown-freebsd8.0, i486-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42793
[Bug target/42774] [4.4/4.5 Regression] ICE in get_aligned_mem, at config/alpha/alpha.c:1484
--- Comment #12 from uros at gcc dot gnu dot org 2010-01-18 17:46 --- Subject: Bug 42774 Author: uros Date: Mon Jan 18 17:46:17 2010 New Revision: 156017 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156017 Log: PR target/42774 * config/alpha/predicates.md (aligned_memory_operand): Return 0 for memory references with unaligned offsets. Remove CQImode handling. (unaligned_memory_operand): Return 1 for memory references with unaligned offsets. Remove CQImode handling. testsuite/ChangeLog: PR target/42774 * gcc.target/alpha/pr42774.c: New test. Added: trunk/gcc/testsuite/gcc.target/alpha/pr42774.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/alpha/predicates.md trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42774
[Bug tree-optimization/42642] "-fcompare-debug failure" with "-O1 -fpeel-loops"
--- Comment #5 from zsojka at seznam dot cz 2010-01-18 17:45 --- $ /mnt/svn/gcc-trunk/binary-155984-lto/bin/g++ -O1 -fpeel-loops -fcompare-debug pr42642.cpp -c g++: pr42642.cpp: -fcompare-debug failure r155984 still fails for me -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42642
[Bug fortran/42736] [4.3/4.4/4.5 Regression] Wrong-code with allocatable or pointer components in elemental functions
--- Comment #9 from pault at gcc dot gnu dot org 2010-01-18 17:32 --- Have posted a fix on the list today. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-18 17:32:21 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42736
[Bug fortran/42783] [4.5 Regression] Bogus Array bounds violation with optional array argument
--- Comment #2 from pault at gcc dot gnu dot org 2010-01-18 17:31 --- Confirmed. A weird and wonderful feature of this bug is that it disappears for -O2 and higher :-) The problem comes about because fsym->backend_decl is being used, which is incorrect if the argument is missing because this does not correspond to the declaration for the string. Instead, the function gfc_conv_expr_present should be used. A patch is regtesting right now. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |pault at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-18 17:31:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42783
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility with static common vars.
--- Comment #24 from hubicka at gcc dot gnu dot org 2010-01-18 17:19 --- Subject: Bug 42068 Author: hubicka Date: Mon Jan 18 17:19:13 2010 New Revision: 156016 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156016 Log: PR middle-end/42068 * gcc-interface/utils.c (create_var_decl_1): Do not set COMMON flag for unit local variables. Modified: trunk/gcc/ada/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug target/42774] [4.4/4.5 Regression] ICE in get_aligned_mem, at config/alpha/alpha.c:1484
--- Comment #11 from uros at gcc dot gnu dot org 2010-01-18 17:04 --- Subject: Bug 42774 Author: uros Date: Mon Jan 18 17:04:29 2010 New Revision: 156014 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156014 Log: PR target/42774 * config/alpha/predicates.md (aligned_memory_operand): Return 0 for memory references with unaligned offsets. Remove CQImode handling. (unaligned_memory_operand): Return 1 for memory references with unaligned offsets. Remove CQImode handling. testsuite/ChangeLog: PR target/42774 * gcc.target/alpha/pr42774.c: New test. Added: branches/gcc-4_4-branch/gcc/testsuite/gcc.target/alpha/pr42774.c Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/alpha/predicates.md branches/gcc-4_4-branch/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42774
[Bug tree-optimization/42685] [4.5 Regression] "-fcompare-debug failure" with "-O1 -funroll-loops" (2)
--- Comment #4 from steven at gcc dot gnu dot org 2010-01-18 17:00 --- This still fails, even with Alexandre's patch for bug 42631. With -fno-web the failure disappears. So this is probably another issue in the webizer. Investigating -> mine for now. -- steven at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |steven at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-18 17:00:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42685
[Bug tree-optimization/42642] "-fcompare-debug failure" with "-O1 -fpeel-loops"
--- Comment #4 from steven at gcc dot gnu dot org 2010-01-18 16:57 --- I think this is fixed now, with Alexandre's patch. Could the OP confirm that please? On to the next -fcompare-debug failure :-) -- steven at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42642
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #8 from davek at gcc dot gnu dot org 2010-01-18 16:35 --- (In reply to comment #7) > Should we perhaps rename all the lto_elf_ stuff to something else, if all of > this also Just Works with COFF? As I said, WIP; I was certainly thinking of renaming it all to lto_objfile_xxx or some similar prefix in time for the final version. > Can we use a similar approach for Mach-O? I don't speak Mach-O, but yes, the approach should work. You'd start by saying lto_binary_reader=lto-mach-o in config.gcc and adding a new lto/lto-mach-o.c with the same handful of toplevel functions: open and close file, build section hash, and create section and append binary data to section. > Big kudos for Dave, btw, for working on this. Ah, it's nothing - a simple COFF file reader is no BFD... (pun intended) ;-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug tree-optimization/42585] [4.5 Regression] SRA is not good for structure copies with one replacement any more
--- Comment #2 from jamborm at gcc dot gnu dot org 2010-01-18 16:29 --- Patch restoring the 4.4 behavior posted to the mailing list: http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00976.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42585
[Bug other/42792] cc1-dummy link fails with missing tree_ and rtl_ functions
--- Comment #1 from David dot Biesack at sas dot com 2010-01-18 16:21 --- Created an attachment (id=19647) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19647&action=view) build log for gcc 4.4.2 build log showing environment, configure, make, and make errors linking cc1-dummy -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42792
[Bug other/42792] New: cc1-dummy link fails with missing tree_ and rtl_ functions
I downloaded a fresh 4.4.2 source distribution and configured and build for x86_64-redhat-linux I'll attach a full build log, but basically the GCC build fails trying to link cc1-dummy with many, many undefined symbols. I've built local copies of GMP, MPFR, MPC in /usr/local (using -fPIC) and did # export LD_LIBRARY_PATH=/usr/local/lib # export LIBRARY_PATH=/usr/local/lib # ./configure --with-gmp=/usr/local --with-mpfr=/usr/local --with-mpc=/usr/local # make and got this error: gcc -g -fkeep-inline-functions -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -Wcast-qual -Wold-style-definition -Wc++-compat -Wmissing-format-attribute -fno-common -DHAVE_CONFIG_H -o cc1-dummy c-lang.o stub-objc.o attribs.o c-errors.o c-lex.o c-pragma.o c-decl.o c-typeck.o c-convert.o c-aux-info.o c-common.o c-opts.o c-format.o c-semantics.o c-ppoutput.o c-cppbuiltin.o c-objc-common.o c-dump.o c-pch.o c-parser.o i386-c.o c-gimplify.o tree-mudflap.o c-pretty-print.o c-omp.o dummy-checksum.o \ main.o tree-browser.o libbackend.a ../libcpp/libcpp.a ../libdecnumber/libdecnumber.a ../libcpp/libcpp.a ../libiberty/libiberty.a ../libdecnumber/libdecnumber.a -L/usr/local/lib -L/usr/local/lib -lmpfr -lgmp i386-c.o: In function `ix86_pragma_target_parse': /usr/local/src/gcc-4.4.2/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/config/i386/i386-c.c:259: undefined reference to `tree_check_failed' /usr/local/src/gcc-4.4.2/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/config/i386/i386-c.c:271: undefined reference to `tree_check_failed' /usr/local/src/gcc-4.4.2/host-x86_64-unknown-linux-gnu/gcc/../.././gcc/config/i386/i386-c.c:272: undefined reference to `tree_check_failed' libbackend.a(gtype-desc.o): In function `gt_ggc_mx_rtx_def': /usr/local/src/gcc-4.4.2/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:1477: undefined reference to `rtl_check_failed_flag' libbackend.a(gtype-desc.o): In function `gt_pch_nx_rtx_def': /usr/local/src/gcc-4.4.2/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:3588: undefined reference to `rtl_check_failed_flag' libbackend.a(gtype-desc.o): In function `gt_pch_p_7rtx_def': /usr/local/src/gcc-4.4.2/host-x86_64-unknown-linux-gnu/gcc/gtype-desc.c:6016: undefined reference to `rtl_check_failed_flag' with many more in the log My gcc is # gcc -v Using built-in specs. Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-libgcj-multifile --enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk --disable-dssi --enable-plugin --with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic --host=x86_64-redhat-linux Thread model: posix gcc version 4.1.2 20080704 (Red Hat 4.1.2-44) I'll attach a full gcc.log -- Summary: cc1-dummy link fails with missing tree_ and rtl_ functions Product: gcc Version: 4.4.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: David dot Biesack at sas dot com GCC build triplet: x86_64-redhat-linux GCC host triplet: x86_64-redhat-linux GCC target triplet: x86_64-redhat-linux http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42792
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #7 from steven at gcc dot gnu dot org 2010-01-18 16:18 --- Should we perhaps rename all the lto_elf_ stuff to something else, if all of this also Just Works with COFF? Can we use a similar approach for Mach-O? Big kudos for Dave, btw, for working on this. -- steven 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-01-18 16:18:01 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug c++/42758] [4.5 Regression] ICE on assert() in function with complex(?) template argument
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-01-15 18:57:48 |2010-01-18 16:11:15 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42758
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility with static common vars.
--- Comment #23 from rguenth at gcc dot gnu dot org 2010-01-18 15:48 --- If it's now middle-end then we need to adjust the priority. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords|build |ice-on-valid-code Priority|P4 |P1 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility with static common vars.
--- Comment #22 from hubicka at gcc dot gnu dot org 2010-01-18 15:47 --- No longer bootstrap issue, but still ICE on valid. -- hubicka at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |hubicka at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-01-06 22:48:22 |2010-01-18 15:47:12 date|| Summary|[4.5 regression] ICE in |[4.5 regression] ICE in |function_and_variable_visibi|function_and_variable_visibi |lity breaks Ada bootstrap |lity with static common ||vars. http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap
--- Comment #21 from hubicka at gcc dot gnu dot org 2010-01-18 15:42 --- Subject: Bug 42068 Author: hubicka Date: Mon Jan 18 15:42:05 2010 New Revision: 156010 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156010 Log: PR middle-end/42068 (create_var_decl_1): Do not set COMMON flag for unit local variables. Modified: trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/utils.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug middle-end/19988] [4.3/4.4/4.5 Regression] pessimizes fp multiply-add/subtract combo
--- Comment #23 from rguenth at gcc dot gnu dot org 2010-01-18 15:16 --- And a fix along comment #14 would be (untested, but of course fixes the testcase): Index: gcc/fold-const.c === --- gcc/fold-const.c(revision 156009) +++ gcc/fold-const.c(working copy) @@ -1129,10 +1129,14 @@ negate_expr_p (tree t) && TYPE_OVERFLOW_WRAPS (type)); case FIXED_CST: -case REAL_CST: case NEGATE_EXPR: return true; +case REAL_CST: + /* We want to canonicalize to positive real constants. Pretend + that only negative ones can be easily negated. */ + return REAL_VALUE_NEGATIVE (TREE_REAL_CST (t)); + case COMPLEX_CST: return negate_expr_p (TREE_REALPART (t)) && negate_expr_p (TREE_IMAGPART (t)); looks appealing, but let's check for fallout. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19988
[Bug c++/42766] [4.5 Regression] tree check fail in build_expr_type_conversion
--- Comment #7 from dodji at gcc dot gnu dot org 2010-01-18 14:55 --- A candidate patch was posted to http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00974.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42766
[Bug tree-optimization/42719] "-fcompare-debug failure" with "-O2 -ftracer"
-- jakub 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-01-18 14:53:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42719
[Bug target/40332] [4.5 Regression] (.eh_frame); no .eh_frame_hdr table will be created.
--- Comment #11 from jv244 at cam dot ac dot uk 2010-01-18 14:41 --- after the previous comment, marking this as a regression, confirm it, and set P1 as suggest by Ian on the list. -- jv244 at cam dot ac dot uk changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Priority|P3 |P1 Last reconfirmed|-00-00 00:00:00 |2010-01-18 14:41:59 date|| Summary|(.eh_frame); no |[4.5 Regression] |.eh_frame_hdr table will be |(.eh_frame); no |created.|.eh_frame_hdr table will be ||created. Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40332
[Bug fortran/42545] type extension: parent component has wrong accessibility
--- Comment #7 from burnus at gcc dot gnu dot org 2010-01-18 14:39 --- (In reply to comment #6) > > It sets the accessibility at resolution time and makes the following > > variant > > of comment #2 work: > > That variant works for me already with the trunk, i.e. it is not rejected > which is (for me) the expected result. Actually, I misread "makes ... work": It is seemingly rejected with the patch and - after (re)reading the standard (see quote in comment 6), I think rejecting is indeed correct. Sorry for not checking that part of my comment before hitting "Commit". -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42545
[Bug fortran/42545] type extension: parent component has wrong accessibility
--- Comment #6 from burnus at gcc dot gnu dot org 2010-01-18 14:36 --- (In reply to comment #5) > It sets the accessibility at resolution time and makes the following variant > of comment #2 work: That variant works for me already with the trunk, i.e. it is not rejected which is (for me) the expected result. * * * As it took me a while to see whether the various examples are valid or not. (Comment 0 is quite unrelated as it about TBP vs. component accessibility while the rest is about accessibility of inherited components.) Fortran 2003 has in "4.5.6.1 Inheritance": "An extended type includes all of the type parameters, all of the components, and the nonoverridden (4.5.6.2) nonfinal procedure bindings of its parent type. These are said to be inherited by the extended type from the parent type. They retain all of the attributes that they had in the parent type. Additional type parameters, components, and procedure bindings may be declared in the derived-type definition of the extended type." "An extended type has a scalar, nonpointer, nonallocatable, parent component with the type and type parameters of the parent type. The name of this component is the parent type name. It has the accessibility of the parent type." "Note 4.51: Inaccessible components and bindings of the parent type are also inherited, but they remain inaccessible in the extended type. Inaccessible entities occur if the type being extended is accessed via use association and has a private entity." Thus the crucial part is: a) For components "they retain all of the attributes that they had in the parent type" -- thus the PRIVATE statement which only changes the default has no influence. b) For the parent type: If it is PRIVATE then also extended%parent%par_comp is only accessible in the module per "It has the accessibility of the parent type" in the second paragraph. But what about: extended%par_comp ? par_comp is PUBLIC while its TYPE is PRIVATE. Just from reading the standard, it looks valid. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42545
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #8 from paolo dot carlini at oracle dot com 2010-01-18 14:25 --- Whatever you prefer. As a matter of fact, now, a PR vs 3.4.4 should be invalid, essentially. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #7 from FBergemann at web dot de 2010-01-18 14:16 --- Hi Paolo, shouldn't it be WONTFIX then? (as it is against 3.4.4) best rgds, Frank -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug fortran/42545] type extension: parent component has wrong accessibility
--- Comment #5 from janus at gcc dot gnu dot org 2010-01-18 13:46 --- (In reply to comment #3) > Here is a simple patch for setting the parent component accessibility: > [...] > This is probably not enough, since the access. specification of the parent > type > may come after the daughter type definition. But this already fixes the exmple > in comment #2. This version should be better: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (revision 155994) +++ gcc/fortran/resolve.c (working copy) @@ -10494,6 +10494,12 @@ resolve_fl_derived (gfc_symbol *sym) && resolve_typespec_used (&c->ts, &c->loc, c->name) == FAILURE) return FAILURE; + /* If this type is an extension, set the accessibility of the parent +component. */ + if (super_type && c == sym->components + && strcmp (super_type->name, c->name) == 0) + c->attr.access = super_type->attr.access; + /* If this type is an extension, see if this component has the same name as an inherited type-bound procedure. */ if (super_type It sets the accessibility at resolution time and makes the following variant of comment #2 work: module mo implicit none type :: tt integer :: i = 1 end type type, extends(tt) :: ttt real :: x = 2.0 end type private :: tt end module program pr use mo implicit none type(ttt) :: obj print *,obj%tt%i end program -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42545
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #6 from paolo dot carlini at oracle dot com 2010-01-18 13:38 --- Very hard to answer all those questions and for an architecture which I don't know well, and for an application which I don't know (of course). For sure here, in the FSF GCC community, 3.4.x is considered a very, very, old release branch, completely unmaintained by now. Thus, my general advice: the sooner you update your tools the better. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #5 from FBergemann at web dot de 2010-01-18 13:31 --- Hi Paolo, well switching to more recent version might be a solution - but unfortunately not that easy to implement for me. It's a big project i am working in. Switching the compiler means invoking our release management to re-create the application release. For this they need to re-create all binary components it depends on, before. Then we have to re-start entire system tests, rollout to customers, etc, ... Before i consider this i need to know where the problem is actually. Is it possible to get a confirmation, that gcc-3.4.4 has some deficit(s) on hp-ux ia64 B11.31? Because it might affect some or all our products on HP-UX. Is there a deficit list for gcc-3.4.4 for HP-UX ia64 B11.31? I tried to look it up on this bug system - but couldn't find such kind of summary. We are also involving HP for this now. And a request to boost.org is also pending. One important thing: The reason, why we are stuck to 3.4.4 here is, that in the past this was a well-optimized compiler (performance). We have been told that newer versions are "slower". Now for gcc.4.3.x i am not sure, if this argument is still valid?! Can you gimme some help in that - about performance impacts from switching from 3.4.4 to 4.3.x? - many thanks! best rgds, Frank -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug rtl-optimization/42621] [4.4 Regression] Computed gotos on AMD 800% slower
--- Comment #10 from carlr at freemail dot gr 2010-01-18 13:14 --- Please note that computed gotos are factored out because "they are a hell to deal with" in tree-cfg.c:build_gimple_cfg(). This means that they MUST be unfactored out as promised in the comment without leaving this to another optimization step that may or may not be enabled. Also, for our product there are 97 "extra jumps" and 95 of them are long jumps, i.e: 12be0: ff e1 jmp *%ecx ... 12dda: e9 01 fe ff ff jmp 12be0 ... so this is a serious both speed and size pessimisation :( -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42621
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-18 13:05 --- Excellent that it works fine with current GCCs. Frankly, I'm thinking that as far as GCC is concerned the issue can be closed here, maybe you should consider pointing out to the spirit project the little tweak you needed: you know recent GCCs implements the C++ Standard much better, for sure that tweak is needed for any good modern compiler. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|WAITING |RESOLVED Known to work||4.3.3 Resolution||WORKSFORME http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug tree-optimization/42728] "-fcompare-debug failure (length)" at -O1
--- Comment #2 from jakub at gcc dot gnu dot org 2010-01-18 13:03 ---
This is a fwprop.c bug. In particular, that the
797 /* If target_insn comes right after def_insn, which is very common
798 for addresses, we can use a quicker test. */
799 if (NEXT_INSN (def_insn) == target_insn
800 && REG_P (SET_DEST (def_set)))
shortcut in all_uses_available_at has different behavior depending from the
following code. We have def_insn:
(insn 15 14 18 4 pr42728.c:6 (parallel [
(set (reg/v/f:DI 60 [ b ])
(plus:DI (reg/v/f:DI 60 [ b ])
(const_int 1 [0x1])))
(clobber (reg:CC 17 flags))
]) 252 {*adddi_1} (expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))
(as b is uninitialized, this is the only definition of b) and target_insn is
(insn 21 19 22 4 pr42728.c:5 (set (reg:CCZ 17 flags)
(compare:CCZ (mem:QI (reg/v/f:DI 60 [ b ]) [0 S1 A8])
(const_int 0 [0x0]))) 0 {*cmpqi_ccno_1} (nil))
(the only use of it besides debug_insns with -g).
If def_insn and target_insn are adjacent (-g0), then this returns false, as
one of the uses (the only one actually) in def_insn is the target of that insn.
If there are any debug insns in between (or any other), it returns true, as
/* Check if the reg in USE has only one definition. We already
know that this definition reaches use, or we wouldn't be here.
However, this is invalid for hard registers because if they are
live at the beginning of the function it does not mean that we
have an uninitialized access. */
regno = DF_REF_REGNO (use);
def = DF_REG_DEF_CHAIN (regno);
if (def
&& DF_REF_NEXT_REG (def) == NULL
&& regno >= FIRST_PSEUDO_REGISTER)
return false;
shortcut applies and thus local_ref_killed_between_p is not allowed to return
true (because of the def in def_insn).
To fix this, we could either ensure the shortcut is run regardless of any debug
insns in between (next_nondebug_insn isn't probably usable, as target_insn may
be a debug_insn):
--- fwprop.c.jj 2009-12-10 19:19:08.0 +0100
+++ fwprop.c 2010-01-18 13:55:57.0 +0100
@@ -791,13 +791,16 @@ all_uses_available_at (rtx def_insn, rtx
df_ref *use_rec;
struct df_insn_info *insn_info = DF_INSN_INFO_GET (def_insn);
rtx def_set = single_set (def_insn);
+ rtx next;
gcc_assert (def_set);
/* If target_insn comes right after def_insn, which is very common
for addresses, we can use a quicker test. */
- if (NEXT_INSN (def_insn) == target_insn
- && REG_P (SET_DEST (def_set)))
+ next = NEXT_INSN (def_insn);
+ while (next && next != target_insn && DEBUG_INSN_P (next))
+next = NEXT_INSN (next);
+ if (next == target_insn && REG_P (SET_DEST (def_set)))
{
rtx def_reg = SET_DEST (def_set);
or we could do something like:
--- fwprop.c.xx2009-12-10 19:19:08.0 +0100
+++ fwprop.c2010-01-18 14:02:32.0 +0100
@@ -818,17 +818,23 @@ all_uses_available_at (rtx def_insn, rtx
}
else
{
+ rtx def_reg = REG_P (SET_DEST (def_set)) ? SET_DEST (def_set) :
NULL_RTX;
+
/* Look at all the uses of DEF_INSN, and see if they are not
killed between DEF_INSN and TARGET_INSN. */
for (use_rec = DF_INSN_INFO_USES (insn_info); *use_rec; use_rec++)
{
df_ref use = *use_rec;
+ if (def_reg && rtx_equal_p (DF_REF_REG (use), def_reg))
+return false;
if (use_killed_between (use, def_insn, target_insn))
return false;
}
for (use_rec = DF_INSN_INFO_EQ_USES (insn_info); *use_rec; use_rec++)
{
df_ref use = *use_rec;
+ if (def_reg && rtx_equal_p (DF_REF_REG (use), def_reg))
+return false;
if (use_killed_between (use, def_insn, target_insn))
return false;
}
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
CC||bonzini at gnu dot org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2010-01-18 13:03:43
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42728
[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c
--- Comment #31 from rguenth at gcc dot gnu dot org 2010-01-18 13:00 --- Subject: Bug 39954 Author: rguenth Date: Mon Jan 18 12:59:50 2010 New Revision: 156008 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156008 Log: 2010-01-18 Richard Guenther PR middle-end/39954 * cfgexpand.c (expand_call_stmt): TER pointer arguments in builtin calls. Modified: trunk/gcc/ChangeLog trunk/gcc/cfgexpand.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c
--- Comment #30 from rguenth at gcc dot gnu dot org 2010-01-18 12:59 --- Fixed. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap
--- Comment #20 from hubicka at ucw dot cz 2010-01-18 12:57 --- Subject: Re: [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap > This is really messy: maybe I'll have some more luck with a cross > compiler. Indeed it is. I will try, but I had problem building the cross because of missing a.out headers. Can you, please, try the change to ada directory itself? That alone should be enough to cure the bootstrap failure (not the C version of testcase). So I am testing it now and intend to commit it ahead of rest of changes. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #3 from FBergemann at web dot de 2010-01-18 12:55 --- Hi Paolo, i tested again with 1) gcc-4.1.2 package delivered from HP (installed at /opt/hp-gcc-4.1.2/) -> it works (no such problem) But there were some warning for compilation /var/tmp//ccgkYSFL.s: Assembler messages: /var/tmp//ccgkYSFL.s:1057: Warning: Use of 'add' may violate WAW dependency 'GR%, % in 1 - 127' (impliedf), specific resource number is 44 /var/tmp//ccgkYSFL.s:1057: Warning: Only the first path encountering the conflict is reported /var/tmp//ccgkYSFL.s:1056: Warning: This is the location of the conflicting usage 2) gcc-4.3.1 package delivered from HP (installed at /opt/hp-gcc-4.3.1/) -> it works (no such problem, also no warnings during compilation) 3) self-compiled /usr/local/gcc-4.3.3/ -> it works (no such problem) To make it compile for gcc versions > 3.4.4, i just needed to fix the fbe_xml_grammar.hpp to drop "extra qualification 'basic_xml_grammar::' on member 'parse_start_tag'" respectively 'parse_end_tag' and 'parse_string'. shall i attach again the modified source.tar.gz for this? - thanks! rgds, Frank -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #6 from davek at gcc dot gnu dot org 2010-01-18 12:54 --- (In reply to comment #5) > > did you run autoconf? > > Forgot to run it, to my disgrace. :) Sorry, false alarm. > No need to apologise, thanks for testing on linux for me! -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug tree-optimization/42585] [4.5 Regression] SRA is not good for structure copies with one replacement any more
-- jamborm at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jamborm at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2010-01-03 06:41:47 |2010-01-18 12:39:10 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42585
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #2 from paolo dot carlini at oracle dot com 2010-01-18 12:27 --- Please, try to reproduce the problem for a currently maintained GCC, thuse either 4.3.x or, better, 4.4.x. In case, please provide a self-contained reproducer in the form of a pre-processed file. For details see: http://gcc.gnu.org/bugs/ Thanks. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap
--- Comment #19 from ro at CeBiTec dot Uni-Bielefeld dot DE 2010-01-18 12:20 --- Subject: Re: [4.5 regression] ICE in function_and_variable_visibility breaks Ada bootstrap > --- Comment #16 from hubicka at gcc dot gnu dot org 2010-01-16 14:54 > --- > Created an attachment (id=19623) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19623&action=view) > --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19623&action=view) > patch I am testing Unfortunately, this (together with Eric's addition) fails in alpha-dec-osf testing: % /vol/gcc/obj/gcc-4.5.0-20100111/4.0f-gcc/./prev-gcc/xgcc -B/vol/gcc/obj/gcc-4.5.0-20100111/4.0f-gcc/./prev-gcc/ -B/vol/gcc/alpha-dec-osf4.0f/bin/ -B/vol/gcc/alpha-dec-osf4.0f/bin/ -B/vol/gcc/alpha-dec-osf4.0f/lib/ -isystem /vol/gcc/alpha-dec-osf4.0f/include -isystem /vol/gcc/alpha-dec-osf4.0f/sys-include-c -g -O2 -gnatpg -gnata -g -O1 -fno-inline \ -nostdinc -I- -I. -Iada -I/vol/gcc/src/hg/trunk/osf/gcc/ada -I/vol/gcc/src/hg/trunk/osf/gcc/ada/gcc-interface /vol/gcc/src/hg/trunk/osf/gcc/ada/a-except.adb -o ada/a-except.o raised CONSTRAINT_ERROR : SIGSEGV Both gdb 6.6 and 7.0 segv when loading gnat1 on Tru64 UNIX V4.0F, so it's hard to debug from here. On V5.1B, gdb doesn't work properly either: Reading symbols from /vol/gcc/obj/gcc-4.5.0-20100111/5.1b-gcc/gcc/gnat1...Error reading symbol table: Memory exhausted No symbol table is loaded. Use the "file" command. If I use ladebug instead, I miss the symbolic debug information (ladebug cannot deal with stabs-in-ecoff), but at least I get a stack trace: Thread received signal SEGV stopped at [void _GLOBAL__FD_gnat1(void) 0x121847f58] (ladebug) where >0 0x121847f58 in _GLOBAL__FD_gnat1() in ./gnat1 #1 0x121848b20 in _GLOBAL__FD_gnat1() in ./gnat1 #2 0x12184adfc in _GLOBAL__FD_gnat1() in ./gnat1 #3 0x12184ba6c in _GLOBAL__FD_gnat1() in ./gnat1 #4 0x120cf8a30 in _GLOBAL__FD_gnat1() in ./gnat1 #5 0x12184be88 in _GLOBAL__FD_gnat1() in ./gnat1 #6 0x120cf8a30 in _GLOBAL__FD_gnat1() in ./gnat1 #7 0x120daed08 in _GLOBAL__FD_gnat1() in ./gnat1 #8 0x120dafa98 in _GLOBAL__FD_gnat1() in ./gnat1 #9 0x120dae470 in _GLOBAL__FD_gnat1() in ./gnat1 #10 0x120dafbc4 in _GLOBAL__FD_gnat1() in ./gnat1 #11 0x120dae470 in _GLOBAL__FD_gnat1() in ./gnat1 #12 0x120dafb10 in _GLOBAL__FD_gnat1() in ./gnat1 #13 0x120dae470 in _GLOBAL__FD_gnat1() in ./gnat1 #14 0x120dafb10 in _GLOBAL__FD_gnat1() in ./gnat1 #15 0x120dae470 in _GLOBAL__FD_gnat1() in ./gnat1 #16 0x12184a090 in _GLOBAL__FD_gnat1() in ./gnat1 #17 0x12184a104 in _GLOBAL__FD_gnat1() in ./gnat1 #18 0x12184a6d8 in _GLOBAL__FD_gnat1() in ./gnat1 #19 0x1218556c0 in _GLOBAL__FD_gnat1() in ./gnat1 #20 0x12144f8a0 in _GLOBAL__FD_gnat1() in ./gnat1 #21 0x121450dc0 in _GLOBAL__FD_gnat1() in ./gnat1 #22 0x121451510 in _GLOBAL__FD_gnat1() in ./gnat1 More (n if no)? n #23 0x121451b34 in _GLOBAL__FD_gnat1() in ./gnat1 #24 0x1204e5e68 in _GLOBAL__FD_gnat1() in ./gnat1 #25 0x120f52a74 in _GLOBAL__FD_gnat1() in ./gnat1 #26 0x120f55fe8 in _GLOBAL__FD_gnat1() in ./gnat1 #27 0x120f56138 in _GLOBAL__FD_gnat1() in ./gnat1 #28 0x120c156c4 in _GLOBAL__FD_gnat1() in ./gnat1 #29 0x120382b98 in __start(...) in ./gnat1 This is really messy: maybe I'll have some more luck with a cross compiler. Rainer -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #1 from FBergemann at web dot de 2010-01-18 12:18 --- Created an attachment (id=19646) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19646&action=view) tar file with mini program sources & Makefile Pls change the optimization level in Makefile to see the differences. To successfully compile it requires -I for the boost include files. Remember i uses boost 1.33.1 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug tree-optimization/42652] vectorizer created unaligned vector insns
--- Comment #13 from irar at il dot ibm dot com 2010-01-18 12:17 ---
Does something like this make sense? (With this patch we will never use peeling
for function parameters, unless the builtin returns OK to peel for packed
types).
Index: tree-vect-data-refs.c
===
--- tree-vect-data-refs.c (revision 155880)
+++ tree-vect-data-refs.c (working copy)
@@ -1010,10 +1010,29 @@ vector_alignment_reachable_p (struct dat
tree type = (TREE_TYPE (DR_REF (dr)));
tree ba = DR_BASE_OBJECT (dr);
bool is_packed = false;
+ tree tmp = TREE_TYPE (DR_BASE_ADDRESS (dr));
if (ba)
is_packed = contains_packed_reference (ba);
+ is_packed = is_packed || contains_packed_reference (DR_BASE_ADDRESS
(dr));
+
+ if (!is_packed)
+{
+ while (tmp)
+{
+ is_packed = TYPE_PACKED (tmp);
+ if (is_packed)
+break;
+
+ tmp = TREE_TYPE (tmp);
+}
+}
+
+ if (TREE_CODE (DR_BASE_ADDRESS (dr)) == SSA_NAME
+ && TREE_CODE (SSA_NAME_VAR (DR_BASE_ADDRESS (dr))) == PARM_DECL)
+is_packed = true;
+
if (vect_print_dump_info (REPORT_DETAILS))
fprintf (vect_dump, "Unknown misalignment, is_packed = %d",is_packed);
if (targetm.vectorize.vector_alignment_reachable (type, is_packed))
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42652
[Bug c++/42791] New: boost[1.33.1]::spirit depends on optimization level
Hello,
i posted a problem against boost::serialization.
(http://article.gmane.org/gmane.comp.lib.boost.user/54935).
But now i could track it down to boost::spirit.
I have extracted boost::serialization stuff , which is dealing with boost
spirit, in a mini demo program
(will attach tar file next).
It accepts XML input if compiled with -O0 or -O1 and returns #1 ("hit") for it:
|hpux03 407> make sample
/usr/local/gcc-3.4.4/bin/g++ -g -mlp64 -Wall -mtune=itanium2 -O1
-I/nfs/uh01/frank/userspace/OPSC_DIAXHBS_dev_R2.2_hpport/include -c sample.cc
/usr/local/gcc-3.4.4/bin/g++ -g -mlp64 -Wall -mtune=itanium2 -O1
-I/nfs/uh01/frank/userspace/OPSC_DIAXHBS_dev_R2.2_hpport/include -c
fbe_basic_xml_grammar.cc
./sample
/usr/local/gcc-3.4.4/bin/g++ -g -mlp64 -Wall -mtune=itanium2 -O1
-I/nfs/uh01/frank/userspace/OPSC_DIAXHBS_dev_R2.2_hpport/include -lunwind -o
sample sample.o fbe_basic_xml_grammar.o
|hpux03 408> ./sample
test is ''
parse_start_tag('') returned 1
But it fails (return #0 "no hit"), if i use -O2 or -O3:
|hpux03 411> make sample
/usr/local/gcc-3.4.4/bin/g++ -g -mlp64 -Wall -mtune=itanium2 -O2
-I/nfs/uh01/frank/userspace/OPSC_DIAXHBS_dev_R2.2_hpport/include -c sample.cc
./sample
/usr/local/gcc-3.4.4/bin/g++ -g -mlp64 -Wall -mtune=itanium2 -O2
-I/nfs/uh01/frank/userspace/OPSC_DIAXHBS_dev_R2.2_hpport/include -c
fbe_basic_xml_grammar.cc
/usr/local/gcc-3.4.4/bin/g++ -g -mlp64 -Wall -mtune=itanium2 -O2
-I/nfs/uh01/frank/userspace/OPSC_DIAXHBS_dev_R2.2_hpport/include -lunwind -o
sample sample.o fbe_basic_xml_grammar.o
|hpux03 412> ./sample
test is ''
parse_start_tag('') returned 0
Is it a bug of gcc-3.4.4? (for HP-UX B11.31 ia64?)
Or boost::spirit using experimental C++ feature (for level of gcc-3.4.4)?
- many thanks!
Frank Bergemann
--
Summary: boost[1.33.1]::spirit depends on optimization level
Product: gcc
Version: 3.4.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: FBergemann at web dot de
GCC build triplet: ia64 hp-ux B11.31
GCC host triplet: ia64 hp-ux B11.31
GCC target triplet: ia64 hp-ux B11.31
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug lto/42776] LTO doesn't work on non-ELF platforms.
--- Comment #5 from d dot g dot gorbachev at gmail dot com 2010-01-18 11:51 --- > did you run autoconf? Forgot to run it, to my disgrace. :) Sorry, false alarm. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42776
[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c
--- Comment #29 from rguenth at gcc dot gnu dot org 2010-01-18 11:43
---
(In reply to comment #28)
> Btw, get_pointer_alignment should get passed an access type to put it into
> context. For alignment of say INDIRECT_REFs it would be the pointed-to type
> but for function arguments in general it needs to be 'char' if you don't know
> anything about the kind of the accesses the function does. That would be
> the default/fallback align get_pointer_alignment has to assume.
Which, if you look at all current callers, boils down to effectively
Index: gcc/builtins.c
===
--- gcc/builtins.c (revision 156006)
+++ gcc/builtins.c (working copy)
@@ -369,8 +369,7 @@ get_pointer_alignment (tree exp, unsigne
if (!POINTER_TYPE_P (TREE_TYPE (exp)))
return 0;
- align = TYPE_ALIGN (TREE_TYPE (TREE_TYPE (exp)));
- align = MIN (align, max_align);
+ align = BITS_PER_UNIT;
while (1)
{
@@ -380,9 +379,6 @@ get_pointer_alignment (tree exp, unsigne
exp = TREE_OPERAND (exp, 0);
if (! POINTER_TYPE_P (TREE_TYPE (exp)))
return align;
-
- inner = TYPE_ALIGN (TREE_TYPE (TREE_TYPE (exp)));
- align = MIN (inner, max_align);
break;
case POINTER_PLUS_EXPR:
which of course will regress generated code quite a bit (even though it's
correct). We might be able to recover some bits by walking SSA defs
here but we'll still lose when reaching function arguments.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
[Bug c++/42766] [4.5 Regression] tree check fail in build_expr_type_conversion
-- dodji at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |dodji at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-01-16 12:57:39 |2010-01-18 11:31:41 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42766
[Bug c++/42697] ice-on-legal-code: template class template function local objects
--- Comment #13 from dodji at gcc dot gnu dot org 2010-01-18 11:25 --- Subject: Re: ice-on-legal-code: template class template function local objects > Ah, I see. So the reason it is not fixed in 4.5 is that it may cause new > regressions? Yes. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42697
[Bug c++/42634] ICE with -g -O2 -std=c++0x in copy_fn_p, at cp/decl.c:9973
--- Comment #11 from dodji at gcc dot gnu dot org 2010-01-18 11:24 --- It looks like the fix for PR42761 made the previous fix for this one (the one I reverted) acceptable now. I am waiting for Jason's comment at http://gcc.gnu.org/ml/gcc-patches/2010-01/msg00964.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42634
[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c
--- Comment #28 from rguenth at gcc dot gnu dot org 2010-01-18 11:24 --- Btw, get_pointer_alignment should get passed an access type to put it into context. For alignment of say INDIRECT_REFs it would be the pointed-to type but for function arguments in general it needs to be 'char' if you don't know anything about the kind of the accesses the function does. That would be the default/fallback align get_pointer_alignment has to assume. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
[Bug c++/42780] Incorrect warning message
--- Comment #2 from jwakely dot gcc at gmail dot com 2010-01-18 11:23 --- N.B. the Host/Target/Target fields are meant for the "host triplet" such as i686-pc-cygwin Feel free to include the snapshot date and OS details in the main report, but putting them in the Host field just makes it harder to search bug reports. As it says at http://gcc.gnu.org/bugs/ the system type is output by 'gcc -v' -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42780
[Bug libstdc++/42712] search_n/iterator.cc times out in parallel-mode
--- Comment #4 from paolo dot carlini at oracle dot com 2010-01-18 11:21 --- Excellent. If possible, I would suggest removing my temporary hack from the testcase together with the parallel-mode patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42712
[Bug middle-end/39954] [4.5 Regression] Revision 146817 caused unaligned access in gcc.dg/torture/pr26565.c
--- Comment #27 from rguenth at gcc dot gnu dot org 2010-01-18 11:12 --- Testing a patch to do minimal surgery to restore previous behavior (thus, fix this regression but not the fundamental frontend / middle-end problem). -- rguenth at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2009-06-17 20:37:33 |2010-01-18 11:12:33 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39954
