[Bug middle-end/32964] [4.3/4.4 Regression] union cause inefficient code inside loops
--- Comment #11 from bonzini at gnu dot org 2009-02-01 08:07 --- still present. -- bonzini at gnu dot org changed: What|Removed |Added Last reconfirmed|2008-03-25 03:46:33 |2009-02-01 08:07:23 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32964
[Bug target/33604] [4.3/4.4 Regression] Revision 119502 causes significantly slower results with 4.3/4.4 compared to 4.2
--- Comment #48 from bonzini at gnu dot org 2009-02-01 08:14 --- Fixed on the trunk with the original testcase: 4.2 -O2 0m13.897s 4.2 -O3 miscompiled 4.4 -O2/-O3 0m8.714s -- bonzini at gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
[Bug c++/39045] No warning for uninitialized reference
--- Comment #2 from alexey dot veselovsky at gmail dot com 2009-02-01 09:17 --- I think it should be error, not warning. (comeau and ms vc claims it as error) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39045
[Bug c++/39055] [4.2/4.3/4.4 regression] ICE with questionable default parameter of a member function
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.2.5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39055
[Bug tree-optimization/38968] Complex matrix product is not vectorized
--- Comment #7 from dominiq at lps dot ens dot fr 2009-02-01 10:37 --- Created an attachment (id=17220) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17220action=view) testin complex matrix multiplication Comment #0 is not fully accurate. With some more testsing with the attached code, I get: - gcc 4.3.3: no vectorization, - gcc 4.4.0 (trunk) : vectorization for odd n, - gcc 4.4.0 + patch from http://gcc.gnu.org/ml/gcc-patches/2009-01/msg01271.html: vectorization for all values of n (in the tested range). The attached code also checked the result of the matrix product which is OK. Now as shown below (in flops/clock cycle), the timings are quite disapointing (-m64 -O3 -ffast-math -funroll-loops): for odd n, the vectorized code is slower than the nonvectorized one, for even n, the code is faster with vectorization, but still significantly slower than with ifort. n 4.3.3 trunk trunk ifort +patch 11.0 124 1.331.361.812.61 125 1.371.321.322.20 126 1.361.371.792.55 127 1.371.311.312.22 128 1.381.391.862.64 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38968
[Bug c++/39057] New: ICE with default argument in friend declaration
The following invalid code snippet triggers an ICE since at least GCC 2.95.3
(with the exception of 3.3.[2-6] where the code is wrongly accepted):
struct A
{
templateint void foo();
};
templateint struct B
{
friend void A::foo0(int = 0);
};
bug.cc:9: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
Btw, the bug is related to PR13166, but not quite identical:
If I remove the class around foo, the code is rejected correctly.
--
Summary: ICE with default argument in friend declaration
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39057
[Bug target/33604] [4.3/4.4 Regression] Revision 119502 causes significantly slower results with 4.3/4.4 compared to 4.2
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|4.3.4 |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33604
[Bug c++/39053] [4.4 regression] ICE with broken function declaration
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-01 10:57 --- Better split this. P2 for the trunk non-error recovery one. For the rest WONTFIX. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to fail||4.4.0 Known to work||4.1.0 4.3.3 Priority|P3 |P2 Summary|[4.2/4.3/4.4 regression] ICE|[4.4 regression] ICE with |with broken function|broken function declaration |declaration | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39053
[Bug inline-asm/39058] New: [4.3/4.4 regression] ICE with double in inline-asm
The following (IMHO valid) code snippet triggers an ICE since GCC 4.3.0
when compiled with -O:
double foo()
{
double x;
asm( : =r,r(x) : 0,0(x));
return x;
}
bug.c: In function 'foo':
bug.c:5: internal compiler error: in reg_overlap_mentioned_p, at rtlanal.c:1393
Please submit a full bug report, [etc.]
The same code compiles fine if I use float instead of double.
--
Summary: [4.3/4.4 regression] ICE with double in inline-asm
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39058
[Bug tree-optimization/38968] Complex matrix product is not vectorized
--- Comment #9 from dominiq at lps dot ens dot fr 2009-02-01 10:58 --- Did you try enabling SSE3 btw? No. How do I get the enabled SSE* by default? Can you post the ifort assembly of the loop? L_B1.14:# Preds L_B1.14 L_B1.13 lea (%rsi,%r9,8), %r11# lea mymatmul_$A.0.1(%rip), %r10 #27.33 movaps(%r10,%r11), %xmm2#27.33 movaps16(%r10,%r11), %xmm4 #27.33 movaps%xmm0, %xmm3 #27.40 mulps %xmm2, %xmm3 #27.40 shufps$177, %xmm2, %xmm2#27.40 lea (%rdx,%r9,8), %r15# lea mymatmul_$C.0.1(%rip), %r14 #27.24 movaps%xmm0, %xmm5 #27.40 addq $4, %r9 #26.12 mulps %xmm1, %xmm2 #27.40 cmpq $128, %r9 #26.12 addsubps %xmm2, %xmm3 #27.40 addps (%r14,%r15), %xmm3#27.15 movaps%xmm3, (%r14,%r15)#27.15 mulps %xmm4, %xmm5 #27.40 shufps$177, %xmm4, %xmm4#27.40 mulps %xmm1, %xmm4 #27.40 addsubps %xmm4, %xmm5 #27.40 addps 16(%r14,%r15), %xmm5 #27.15 movaps%xmm5, 16(%r14,%r15) #27.15 jlL_B1.14 # Prob 99% #26.12 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38968
[Bug c++/39055] [4.2/4.3/4.4 regression] ICE with questionable default parameter of a member function
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Known to work||3.2.3 Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39055
[Bug inline-asm/39059] New: [4.3/4.4 regression] ICE with fixed-point type in inline-asm
The following (IMHO valid) testcase triggers an ICE since GCC 4.3.0
(when fixed-point types were introduced):
void foo()
{
asm( : : r(0r));
}
bug.c: In function 'foo':
bug.c:4: internal compiler error: in init_move_cost, at reginfo.c:270
Please submit a full bug report, [etc.]
Technically, this is a regression since the code did not crash the
compiler before (because it was rejected earlier).
--
Summary: [4.3/4.4 regression] ICE with fixed-point type in
inline-asm
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: inline-asm
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39059
[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - /dev/null'
--- Comment #11 from patriciak784-gccmainling at yahoo dot de 2009-02-01 11:44 --- I am sorry that I was a bit unclear - 4.0.0 @ 95634 works for PR20239 but doesn't for this problem. But the patch from PR20239 fixed both problems on 3.4.4, so both bugs are no duplicates, sorry. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37215
[Bug ada/39061] New: [4.4 Regression] SIGFPE on ACATS c456001 c45624a c45624b c4a013a cxa5a03 cxg2002 cxg2017 cxg2020 on alpha-linux
This used to work in 4.3, but doesn't on trunk: $ gnatchop /opt/cfarm/src/trunk/gcc/testsuite/ada/acats/support/repbody.ada $ gnatchop /opt/cfarm/src/trunk/gcc/testsuite/ada/acats/support/repspec.ada $ gnatchop /opt/cfarm/src/trunk/gcc/testsuite/ada/acats/tests/c4/c4a013a.ada $ gnatmake -f -g ./c4a013a $ ./c4a013a ,.,. C4A013A ACATS 2.5 09-02-01 11:40:55 C4A013A CHECK NONSTATIC UNIVERSAL_REAL EXPRESSIONS WHOSE RESULTS OVERFLOW. Floating point exception $ gdb ./c4a013a GNU gdb 6.8-debian Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type show copying and show warranty for details. This GDB was configured as alpha-linux-gnu... (gdb) r Starting program: /home/guerby/tmp/c4a013a ,.,. C4A013A ACATS 2.5 09-02-01 11:41:01 C4A013A CHECK NONSTATIC UNIVERSAL_REAL EXPRESSIONS WHOSE RESULTS OVERFLOW. Program received signal SIGFPE, Arithmetic exception. 0x0001200081ac in c4a013a () at c4a013a.adb:57 57B := 1.0 1.0 / (1.0 * INTEGER'POS (IDENT_INT (0))); This problem also cause FAIL in the same way for: c456001 c45624a c45624b c4a013a cxa5a03 cxg2002 cxg2017 cxg2020 That is to say all alpha-linux FAIL but cxf3a02 which is a SEGV probably unrelated. -- Summary: [4.4 Regression] SIGFPE on ACATS c456001 c45624a c45624b c4a013a cxa5a03 cxg2002 cxg2017 cxg2020 on alpha-linux Product: gcc Version: unknown Status: UNCONFIRMED Keywords: wrong-code Severity: normal Priority: P3 Component: ada AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net GCC host triplet: alpha-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39061
[Bug ada/39061] [4.4 Regression] SIGFPE on ACATS c456001 c45624a c45624b c4a013a cxa5a03 cxg2002 cxg2017 cxg2020 on alpha-linux
--- Comment #4 from laurent at guerby dot net 2009-02-01 13:47 --- With -mieee they indeed pass. Was the default changed for 4.4? -- laurent at guerby dot net changed: What|Removed |Added Priority|P4 |P3 Target Milestone|4.4.0 |--- Version|4.4.0 |unknown http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39061
[Bug ada/39061] [4.4 Regression] SIGFPE on ACATS c456001 c45624a c45624b c4a013a cxa5a03 cxg2002 cxg2017 cxg2020 on alpha-linux
--- Comment #3 from ubizjak at gmail dot com 2009-02-01 12:22 --- (In reply to comment #0) This problem also cause FAIL in the same way for: c456001 c45624a c45624b c4a013a cxa5a03 cxg2002 cxg2017 cxg2020 These should probably be compiled with -mieee. Can you try to compile using this flag? Uros. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39061
[Bug ada/39061] [4.4 Regression] SIGFPE on ACATS c456001 c45624a c45624b c4a013a cxa5a03 cxg2002 cxg2017 cxg2020 on alpha-linux
--- Comment #1 from laurent at guerby dot net 2009-02-01 11:59 --- Forgot to add version: $ gcc -v Using built-in specs. Target: alphaev56-unknown-linux-gnu Configured with: /opt/cfarm/src/trunk/configure --prefix=/n/30/guerby/install-trunk-143742 --enable-languages=c,ada --disable-libmudflap --disable-nls --enable-threads=posix --enable-__cxa_atexit --with-mpfr=/opt/cfarm/mpfr-2.3.2 Thread model: posix gcc version 4.4.0 20090128 (experimental) [trunk revision 143742] (GCC) -- laurent at guerby dot net changed: What|Removed |Added CC||laurent at guerby dot net, ||uros at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39061
[Bug c++/38986] comparing lengths of 2 strings reads through both strings completely
--- Comment #3 from falk at debian dot org 2009-02-01 10:50 --- The main problem is that just replacing the code by the below loop won't necessarily give a speedup. strlen is usually implemented in highly efficient and platform-specific assembly that treats several bytes at a time. I don't think the vectorizer will give equally efficient code for the loop. Also, in normal applications almost all strings are pretty short (and not of very unequal length). Probably the best way to motivate somebody to look into this is if you gave benchmark results that show a noticeable improvement for some real-world application. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38986
[Bug c++/39056] New: [4.4 regression] [c++0x] ICE with invalid initializer list for complex variable
The following invalid code snippet triggers an ICE on the trunk:
==
__complex__ int i({0});
==
bug.cc:1: internal compiler error: in process_init_constructor, at
cp/typeck2.c:1192
Please submit a full bug report, [etc.]
The bug appeared with the introduction of initializer lists:
2008-07-02 Jason Merrill ja...@redhat.com
* Make-lang.in (cp/typeck2.o): Add $(REAL_H) dependency.
Implement WG21 N2672, Initializer List proposed wording
* cp-tree.h (enum cp_tree_index): Add CPTI_INIT_LIST_TYPE.
(struct lang_type_class): Add has_list_ctor bitfield.
(TYPE_HAS_LIST_CTOR): New macro.
(BRACE_ENCLOSED_INITIALIZER_P): Expect init_list_type_node.
...
It's a regression since the same code snippet didn't cause a crash before.
--
Summary: [4.4 regression] [c++0x] ICE with invalid initializer
list for complex variable
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39056
[Bug tree-optimization/38968] Complex matrix product is not vectorized
--- Comment #10 from rguenther at suse dot de 2009-02-01 11:11 --- Subject: Re: Complex matrix product is not vectorized On Sun, 1 Feb 2009, dominiq at lps dot ens dot fr wrote: --- Comment #9 from dominiq at lps dot ens dot fr 2009-02-01 10:58 --- Did you try enabling SSE3 btw? No. How do I get the enabled SSE* by default? You can enable SSE3 manually with -msse3, or automatically enable what your local CPU can do with -march=native. Richard. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38968
[Bug c++/39054] [4.3/4.4 regression] ICE with invalid pseudo-dtor in template
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39054
[Bug middle-end/32964] [4.3/4.4 Regression] union cause inefficient code inside loops
--- Comment #12 from rguenth at gcc dot gnu dot org 2009-02-01 10:40 --- New SRA should fix this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||mjambor at suse dot cz http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32964
[Bug ada/39061] [4.4 Regression] SIGFPE on ACATS c456001 c45624a c45624b c4a013a cxa5a03 cxg2002 cxg2017 cxg2020 on alpha-linux
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39061
[Bug ada/39061] [4.4 Regression] SIGFPE on ACATS c456001 c45624a c45624b c4a013a cxa5a03 cxg2002 cxg2017 cxg2020 on alpha-linux
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added GCC host triplet|alpha-unknown-linux-gnu | GCC target triplet||alpha-unknown-linux-gnu Priority|P3 |P4 Version|unknown |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39061
[Bug c++/39060] [4.4 regression] ICE with lots of invalid member functions
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39060
[Bug ada/39061] [4.4 Regression] SIGFPE on ACATS c456001 c45624a c45624b c4a013a cxa5a03 cxg2002 cxg2017 cxg2020 on alpha-linux
--- Comment #2 from laurent at guerby dot net 2009-02-01 12:00 --- Testresults: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00058.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39061
[Bug c++/39054] New: [4.3/4.4 regression] ICE with invalid pseudo-dtor in template
The following invalid code snippet triggers an ICE since GCC 4.3.4
(so we have a regression on the 4.3 branch):
==
struct A {};
templatetypename void foo()
{
A().~int();
}
==
bug.cc: In function 'void foo()':
bug.cc:5: error: expected identifier before 'int'
bug.cc:5: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
Jason, this is fallout from your patch:
2009-01-19 Jason Merrill ja...@redhat.com
PR c++/23287
* parser.c (cp_parser_unqualified_id): In a template,
accept ~identifier.
* typeck.c (lookup_destructor): Handle IDENTIFIER_NODE.
Would you mind having a look?
--
Summary: [4.3/4.4 regression] ICE with invalid pseudo-dtor in
template
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39054
[Bug c++/39054] [4.3/4.4 regression] ICE with invalid pseudo-dtor in template
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39054
[Bug testsuite/38946] [4.4 Regression] gcc trunk 143562 - Testsuite - gfortran failing tests that worked previously
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38946
[Bug c++/39053] [4.2/4.3/4.4 regression] ICE with broken function declaration
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39053
[Bug tree-optimization/18687] [4.2/4.3/4.4 Regression] ~50% compile time regression
--- Comment #41 from rguenth at gcc dot gnu dot org 2009-02-01 11:08 --- Ok, let's say then comparing -O[23s] compile-times is unfair as we never stated they are optimized for compile-time but they explicitly contain passes that may usually _not_ help. -O1 may be a different story, but I do not remember when we last tried to find a reasonable set of optimizations for it ;) (I guess we could do with early optimizations only, no IPA, maybe one memory CSE and cleanups after it, no tree loop opts, no repeating everything). Oh, and you are welcome to try to remove redundant passes. I tried for 4.4 with mixed success (our testsuite shows that we have many corner-cases that are only optimized if you run the correct passes in the right order). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18687
[Bug inline-asm/39059] [4.3/4.4 regression] ICE with fixed-point type in inline-asm
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39059
[Bug preprocessor/37215] ICE on 'gcc -E -dM -fpreprocessed - /dev/null'
--- Comment #10 from patriciak784-gccmainling at yahoo dot de 2009-02-01
11:22 ---
(In reply to comment #6)
read_original_filename lexes a token, which hits EOF, which
causes the buffer to be popped.
This is sort of an odd scenario.
Perhaps working around it in preprocess_file is best.
Tom, I did investigate that problem a bit more with the compilers (see end of
comment for versioninfo).
All 4.x branches + trunk @ rev 143756 fail in preprocess_file but 3.4.6
doesn't.
The reason 3.4.6 does not fail is the patch applied to 3.4 branch by Richard
Guenther because of PR20239(perhaps we should even mark this bug as a duplicate
and reopen 20239).
The patch didn't make it into 4.0 because the code there had already been
changed from
if (CPP_OPTION (pfile, preprocessed))
{
read_original_filename (pfile);
+ if (!pfile-map)
+ return NULL;
fname = pfile-map-to_file;
}
to
if (CPP_OPTION (pfile, preprocessed))
{
read_original_filename (pfile);
fname = pfile-line_table-maps[pfile-line_table-used-1].to_file;
}
(see function cpp_read_main_file in gcc/cppinit.c libcpp/init.c respectively)
The two lines beginning with + are Richard's fix.
pfile-map seems to get NULL if there is only whitespace in the file or nothing
at all. Therefore 3.4.4 segfaulted on pfile-map-to_file.
By returning NULL, the function calling cpp_read_main_file,
c_common_post_options will increment errorcount
(=global_dc-diagnostic_count[DK_ERROR])
which leads to the code calling preprocess_file to be skipped and therefore
there is no segfault on 3.4.6.
On the 4.x branches cpp_read_main_file will not return NULL in that case and
preprocess_file will be executed and segfault.
I just wonder why in PR20239, 4.0.0 is said to work. I don't know which
revision Andrew Pinski used but rev 95634 fails for me and I fail to build the
3.3.3 release which is supposed to succeed either.
Perhaps the code leading to the error was introduced around that time and 4.0
branch and trunk but I don't actually think so. If 3.3.3 worked, I assume the
bug was introduced in the 3.4 development cycle.
After all it is now up to you Tom or another maintainer to decide if to apply
my piece of code or create something else (perhaps something in
cpp_read_main_file like Richard did about 4 years ago). I have no objections
against either possibility.
Perhaps someone could verify what I did and update known to fail and known to
work to 3.4.6 | 4.0.4 4.1.3 4.2.5 4.3.4 4.4.0.
And one last thing: this is a regression from 3.4.6.
==gcc versioninfo =
I compiled gcc 3.4,4.0,4.1,4.2,4.3 and 4.4 from svn rev 143756
-v outputs:
Reading specs from
/media/OSS/final/gcc-3.4/bin/../lib/gcc/x86_64-unknown-linux-gnu/3.4.6/specs
Configured with: ../../gcc3.4/configure --prefix=/gcc/final/gcc-3.4
--disable-multilib --enable-languages=c,c++ --with-gnu-ld --with-gnu-as
--disable-nls --with-system-zlib
Thread model: posix
gcc version 3.4.6
===
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc4.0/configure --prefix=/gcc/final/gcc-4.0
--disable-multilib --enable-languages=c,c++ --with-gnu-ld --with-gnu-as
--disable-nls --with-system-zlib
Thread model: posix
gcc version 4.0.4
===
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc4.1/configure --prefix=/gcc/final/gcc-4.1
--disable-multilib --enable-languages=c,c++ --with-gnu-ld --with-gnu-as
--disable-nls --with-system-zlib
Thread model: posix
gcc version 4.1.3 20080704 (prerelease)
===
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc4.2/configure --prefix=/gcc/final/gcc-4.2-143756
--disable-multilib --enable-languages=c,c++ --with-gnu-ld --with-gnu-as
--disable-nls --with-system-zlib --disable-bootstrap
Thread model: posix
gcc version 4.2.5 20090129 (prerelease)
===
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc4.3/configure --prefix=/gcc/final/gcc-4.3-143756
--disable-multilib --enable-languages=c,c++ --with-gnu-ld --with-gnu-as
--disable-nls --with-system-zlib --disable-bootstrap
Thread model: posix
gcc version 4.3.4 20090129 (prerelease) (GCC)
===
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../../gcc4.4/configure --prefix=/gcc/final/gcc-4.4-143756
--disable-multilib --enable-languages=c,c++ --with-gnu-ld --with-gnu-as
--disable-nls --with-system-zlib --disable-bootstrap
Thread model: posix
gcc version 4.4.0 20090129 (experimental) (GCC)
[Bug c++/39060] [4.4 regression] ICE with lots of invalid member functions
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P5 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39060
[Bug c++/39053] New: [4.2/4.3/4.4 regression] ICE with broken function declaration
The following invalid code snippet triggers an ICE since GCC 4.1.1: === void foo() = === On the trunk I get: bug.cc:1: internal compiler error: in cp_lexer_consume_token, at cp/parser.c:637 Please submit a full bug report, [etc.] Before this was only an error-recovery bug: bug.cc:1: error: function 'void foo()' is initialized like a variable bug.cc:1: internal compiler error: in cp_lexer_consume_token, at cp/parser.c:638 Please submit a full bug report, [etc.] So it's a regression of a regression ;-) -- Summary: [4.2/4.3/4.4 regression] ICE with broken function declaration Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code, monitored Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: reichelt at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39053
[Bug tree-optimization/39052] writing arrays twice not optimized
--- Comment #2 from tkoenig at gcc dot gnu dot org 2009-02-01 15:53 --- (In reply to comment #1) I don't think trying to solve this particular case is useful. In order to extend the -finit- - options for gfortran to allocatable arrays, I was thinking of adding an assignment statement after the ALLOCATE for such cases. There, it would be useful (but probably not decisive :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39052
[Bug tree-optimization/39052] writing arrays twice not optimized
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-01 11:02 --- Loop fusion by GRAPHITE may be able to do this in the future (as a side-effect). I don't think trying to solve this particular case is useful. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||spop at gcc dot gnu dot org Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-01 11:02:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39052
[Bug c++/39053] [4.4 regression] ICE with broken function declaration
--- Comment #2 from paolo dot carlini at oracle dot com 2009-02-01 16:22 --- On it. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2009-02-01 16:22:24 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39053
[Bug inline-asm/39059] [4.3/4.4 regression] ICE with fixed-point type in inline-asm
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39059
[Bug c++/38950] [4.3/4.4 regression] ICE: deducing function template arguments for array type.
--- Comment #3 from rguenth at gcc dot gnu dot org 2009-02-01 13:25 --- 3.3.6 and 3.4.1 accept it, starting with 3.4.2 we reject it and since 4.2.0 we ICE. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Keywords||ice-on-valid-code, rejects- ||valid Known to fail||3.4.2 4.2.0 Known to work||3.3.6 3.4.1 Priority|P3 |P2 Target Milestone|--- |4.3.4 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38950
[Bug c++/39060] New: [4.4 regression] ICE with lots of invalid member functions
The following invalid testcase triggers an ICE on the trunk:
struct A
{
A(void* i=);
A(void* i=);
A(void* i=);
void operator+ (void* i=);
virtual void foo1(=);
void foo2(=);
void foo3(=);
void foo4(=);
void foo5(=);
};
A::A (void* i=) {}
bug.cc:4: error: 'A::A(void*)' cannot be overloaded
bug.cc:3: error: with 'A::A(void*)'
[...lots of errors removed...]
bug.cc:16: error: default argument given for parameter 1 of 'A::A(void*)'
bug.cc:3: error: after previous specification in 'A::A(void*)'
bug.cc:16: internal compiler error: canonical types differ for identical types
void (A::)(void*) and void (A::)(void*)
Please submit a full bug report, [etc.]
The testcase is a little fragile, it looks like some memory access is not OK.
--
Summary: [4.4 regression] ICE with lots of invalid member
functions
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-invalid-code, error-recovery, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39060
[Bug c++/39056] [4.4 regression] [c++0x] ICE with invalid initializer list for complex variable
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39056
[Bug c++/39055] New: [4.2/4.3/4.4 regression] ICE with questionable default parameter of a member function
The following valid code snippet triggers an ICE since GCC 3.4.0:
==
templateint struct A
{
int i;
A() { void foo(int=i); }
};
A0 a;
==
bug.cc: In function 'void foo(int) [with int anonymous = 0]':
bug.cc:4: instantiated from 'Aanonymous ::A() [with int anonymous = 0]'
bug.cc:7: instantiated from here
bug.cc:4: internal compiler error: Segmentation fault
Please submit a full bug report, [etc.]
GCC 3.3.x wrongly rejected the code ('i' as default parameter is not OK,
but this should only be diagnosed if the default parameter is actually used).
GCC 3.[012].x correctly accepted the code.
Btw, the code compiles fine if A is not a template class.
--
Summary: [4.2/4.3/4.4 regression] ICE with questionable default
parameter of a member function
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Keywords: ice-on-valid-code, monitored
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: reichelt at gcc dot gnu dot org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39055
[Bug inline-asm/39058] [4.3/4.4 regression] ICE with double in inline-asm
--- Comment #1 from reichelt at gcc dot gnu dot org 2009-02-01 11:03
---
A slightly more complex testcase crashes in a different place:
double foo()
{
double x, y;
asm( : =r,r(x), =r,r(y) : %0,0(x), r,r(0));
return x;
}
bug.c: In function 'foo':
bug.c:6: error: Failure trying to reload:
(nil)
bug.c:6: internal compiler error: in gen_reload, at reload1.c:8327
Please submit a full bug report, [etc.]
Again, no ICE without optimization or with float instead of double.
--
reichelt at gcc dot gnu dot org changed:
What|Removed |Added
Target Milestone|--- |4.3.4
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39058
[Bug tree-optimization/38968] Complex matrix product is not vectorized
--- Comment #8 from rguenth at gcc dot gnu dot org 2009-02-01 10:49 --- This is somewhat expected. We vectorize the complex product using vectors of real parts and vectors of complex parts of two complex numbers (so we are not using the fancy haddsub SSE codes). Did you try enabling SSE3 btw? Can you post the ifort assembly of the loop? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38968
[Bug c++/39056] [4.4 regression] [c++0x] ICE with invalid initializer list for complex variable
-- reichelt at gcc dot gnu dot org changed: What|Removed |Added Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39056
[Bug other/39062] New: libssp/ssp.c needs malloc.h for mingw
libssp only checks for alloca.h header for alloca(), but mingw headers define it in malloc.h. this results in the following warning: ../../../gcc-svn/libssp/ssp.c: In function 'fail': ../../../gcc-svn/libssp/ssp.c:109: warning: implicit declaration of function 'alloca' ../../../gcc-svn/libssp/ssp.c:109: warning: incompatible implicit declaration of built-in function 'alloca' Atached patch fixes it. -- Summary: libssp/ssp.c needs malloc.h for mingw Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: other AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sezeroz at gmail dot com GCC target triplet: x86_64-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39062
[Bug other/39062] libssp/ssp.c needs malloc.h for mingw
--- Comment #1 from sezeroz at gmail dot com 2009-02-01 16:47 --- Created an attachment (id=17221) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17221action=view) libssp alloca patch for mingw -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39062
[Bug target/39063] New: libgcc2.c:mprotect() for mingw, incompatible pointer type warning
in windows replacement of mprotect() in libgcc2.c uses VirtualProtect which requires an unsigned, not a signed ptr as its last argument. the attached patch fixes a 'may be used uninitialized' warning, too. here are the warnings: ../../../gcc-svn/libgcc/../gcc/libgcc2.c: In function 'mprotect': ../../../gcc-svn/libgcc/../gcc/libgcc2.c:2079: warning: passing argument 4 of 'VirtualProtect' from incompatible pointer type /opt/buildroot/gcc-svn/winsup/mingw/include/winbase.h:1126: note: expected 'PDWORD' but argument is of type 'int *' ../../../gcc-svn/libgcc/../gcc/libgcc2.c:2064: warning: 'np' may be used uninitialized in this function -- Summary: libgcc2.c:mprotect() for mingw, incompatible pointer type warning Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sezeroz at gmail dot com GCC target triplet: x86_64-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39063
[Bug target/39064] New: libiberty md5.h needs uintptr_t
md5.h of libiberty assumes unsigned long to be of equal size to the size of a pointer, but that isn't true for all sys tems (ie. win64). this patch is a workaround for that, probably ugly, but md5.h should include stdint.h not for _LIBC only.. here is the generated warning: ../../../gcc-svn/libiberty/md5.c: In function 'md5_process_bytes': ../../../gcc-svn/libiberty/md5.c:234: warning: cast from pointer to integer of different size (the patch should also be applied to binutils and gdb, or whoever else uses libiberty) -- Summary: libiberty md5.h needs uintptr_t Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sezeroz at gmail dot com GCC target triplet: x86_64-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39064
[Bug target/39064] libiberty md5.h needs uintptr_t
--- Comment #1 from sezeroz at gmail dot com 2009-02-01 16:57 --- Created an attachment (id=17223) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17223action=view) libiberty md5.h win64 patch -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39064
[Bug target/39065] New: libiberty hashtab.c:hash_pointer() needs intptr_t
in function hash_pointer(), libiberty/hashtab.c casts its pointer argument to long, probably with the assumption that long is 64 bits on all 64 bit systems, which isn't true for win64. it must cast to intptr_t, instead. here is the warning: ../../../gcc-svn/libiberty/hashtab.c: In function 'hash_pointer': ../../../gcc-svn/libiberty/hashtab.c:199: warning: cast from pointer to integer of different size (the patch should also be applied to binutils and gdb, or whoever else uses libiberty) -- Summary: libiberty hashtab.c:hash_pointer() needs intptr_t Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sezeroz at gmail dot com GCC target triplet: x86_64-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39065
[Bug target/39065] libiberty hashtab.c:hash_pointer() needs intptr_t
--- Comment #1 from sezeroz at gmail dot com 2009-02-01 17:00 --- Created an attachment (id=17224) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17224action=view) libiberty hashtab.c intptr_t fix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39065
[Bug target/39066] New: DO_GLOBAL_CTORS_BODY needs uintptr_t
DO_GLOBAL_CTORS_BODY casts __CTOR_LIST__[0] to unsigned long, probably with the assumption that long is 64 bits on all 64 bit systems, which isn't true for win64. it must cast to uintptr_t, instead. here is the warning: ../../../gcc-svn/libgcc/../gcc/libgcc2.c: In function '__do_global_ctors': ../../../gcc-svn/libgcc/../gcc/libgcc2.c:2161: warning: cast from pointer to integer of different size -- Summary: DO_GLOBAL_CTORS_BODY needs uintptr_t Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: target AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: sezeroz at gmail dot com GCC target triplet: x86_64-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39066
[Bug target/39066] DO_GLOBAL_CTORS_BODY needs uintptr_t
--- Comment #1 from sezeroz at gmail dot com 2009-02-01 17:03 --- Created an attachment (id=17225) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17225action=view) DO_GLOBAL_CTORS_BODY win64 uintptr_t fix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39066
[Bug target/39063] libgcc2.c:mprotect() for mingw, incompatible pointer type warning
--- Comment #1 from sezeroz at gmail dot com 2009-02-01 16:53 --- Created an attachment (id=17222) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17222action=view) mprotect warnings fix -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39063
[Bug c++/39067] New: [PPC64] un-needed copy generated for small structs kept on stack
Consider this simple class:
class TV
{
private:
float truth;
float confidence;
public:
TV(float, float);
float getT(void);
};
extern TV my_tv_maker(float tr);
float my_subr(float tr)
{
TV tv = my_tv_maker(434.23);
return tv.getT();
}
On powerPC, when compiled with gcc -O2 -S -c generates the annotated assembly,
below. Noticable is a copy of the entire structure, which is 8 bytes long, to
and from the stack, which is completely un-needed. When the structure is
*larger*, then no copy is performed, *even when no optimization is done (i.e.
even when -O2 is not specified.)*. So basically, large structures work great;
but small structures cause some extra, un-neccesary cycles to be wasted.
Problem is still there for -O3.
.L._Z7my_subrf:
.LFB3:
mflr 0r0 = link reg value
.LCFI4:
lfs 1,@toc(2) fpr1 = 434.23
std 0,16(1) save link reg value
.LCFI5:
stdu 1,-144(1) incr stack ptr
.LCFI6:
addi 3,1,128 alloc TV on stack. Note sizeof(TV) is 8 bytes.
bl _Z11my_tv_makerf call
ld 0,128(1) r0 = 8 bytes = copy of entire instance of class TV
addi 3,1,112 r3 = ptr to new location
std 0,112(1) store 8-byte copy of the instance to new location
on stack ... this is really not needed.
The old copy, at offset 128, could have been
used .. there was no point to making this copy.
bl _ZN2TV4getTEv call
nop
addi 1,1,144 decr stack
ld 0,16(1) get link reg val
mtlr 0 move to link reg
blr branch to link reg.
gcc -v
Using built-in specs.
Target: powerpc64-unknown-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.1.2/work/gcc-4.1.2/configure
--prefix=/usr --bindir=/usr/powerpc64-unknown-linux-gnu/gcc-bin/4.1.2
--includedir=/usr/lib/gcc/powerpc64-unknown-linux-gnu/4.1.2/include
--datadir=/usr/share/gcc-data/powerpc64-unknown-linux-gnu/4.1.2
--mandir=/usr/share/gcc-data/powerpc64-unknown-linux-gnu/4.1.2/man
--infodir=/usr/share/gcc-data/powerpc64-unknown-linux-gnu/4.1.2/info
--with-gxx-include-dir=/usr/lib/gcc/powerpc64-unknown-linux-gnu/4.1.2/include/g++-v4
--host=powerpc64-unknown-linux-gnu --build=powerpc64-unknown-linux-gnu
--enable-altivec --enable-nls --without-included-gettext --with-system-zlib
--disable-checking --disable-werror --enable-secureplt
--disable-libunwind-exceptions --disable-multilib --enable-libmudflap
--disable-libssp --enable-objc-gc
--enable-languages=c,c++,java,objc,obj-c++,fortran --enable-shared
--enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu
Thread model: posix
gcc version 4.1.2 (Gentoo 4.1.2 p1.0.2)
Bug is reproducible on:
Welcome to hazelnut.osuosl.org
Server Address : 140.211.167.137
Hardware : 8 x POWER5+ (gs),
CHRP IBM,9133-55A, 7794 MB RAM
Operating System : Gentoo Linux
(default-linux/ppc/ppc64/2007.0/64bit-userland/power5)
Support : supp...@osuosl.org
Website : http://powerdev.osuosl.org
Mailing List : http://lists.osuosl.org/mailman/listinfo/powerdev
--
Summary: [PPC64] un-needed copy generated for small structs kept
on stack
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: linasvepstas at gmail dot com
GCC build triplet: powerpc64-unknown-linux-gnu
GCC host triplet: powerpc64-unknown-linux-gnu
GCC target triplet: powerpc64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39067
[Bug tree-optimization/39069] New: signed short plus and signed char plus not vectorized
gcc -march=core2 -O3 -ftree-vectorizer-verbose=6
for this code:
#define SIZE 1
signed short a[SIZE];
signed short b[SIZE];
signed short c[SIZE];
void add()
{
int i;
for (i = 0; i SIZE; ++i)
a[i] = b[i] + c[i];
}
cannot vectorize the loop:
add_sshort.c:9: note: vect_model_load_cost: aligned.
add_sshort.c:9: note: vect_model_load_cost: inside_cost = 1, outside_cost = 0 .
add_sshort.c:9: note: not vectorized: relevant stmt not supported: D.1580_6 =
(short unsigned int) D.1579_5
add_sshort.c:7: note: vectorized 0 loops in function.
The same happens if the type for a,b and c is signed char.
But if the type is unsigned short or unsigned char the loop is vectorized.
--
Summary: signed short plus and signed char plus not vectorized
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39069
[Bug tree-optimization/39068] New: signed short plus and signed char plus not vectorized
gcc -march=core2 -O3 -ftree-vectorizer-verbose=6
for this code:
#define SIZE 1
signed short a[SIZE];
signed short b[SIZE];
signed short c[SIZE];
void add()
{
int i;
for (i = 0; i SIZE; ++i)
a[i] = b[i] + c[i];
}
cannot vectorize the loop:
add_sshort.c:9: note: vect_model_load_cost: aligned.
add_sshort.c:9: note: vect_model_load_cost: inside_cost = 1, outside_cost = 0 .
add_sshort.c:9: note: not vectorized: relevant stmt not supported: D.1580_6 =
(short unsigned int) D.1579_5
add_sshort.c:7: note: vectorized 0 loops in function.
The same happens if the type for a,b and c is signed char.
But if the type is unsigned short or unsigned char the loop is vectorized.
--
Summary: signed short plus and signed char plus not vectorized
Product: gcc
Version: 4.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: dann at godzilla dot ics dot uci dot edu
GCC host triplet: i686-pc-linux-gnu
GCC target triplet: i686-pc-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39068
[Bug tree-optimization/39069] signed short plus and signed char plus not vectorized
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-01 20:50 --- *** This bug has been marked as a duplicate of 39068 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39069
[Bug tree-optimization/39068] signed short plus and signed char plus not vectorized
--- Comment #1 from rguenth at gcc dot gnu dot org 2009-02-01 20:50 --- *** Bug 39069 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39068
[Bug tree-optimization/39068] signed short plus and signed char plus not vectorized
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Severity|normal |enhancement Keywords||missed-optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39068
[Bug tree-optimization/39068] signed short plus and signed char plus not vectorized
--- Comment #2 from dorit at gcc dot gnu dot org 2009-02-01 21:06 --- (reminds me of a couple missed-optimization PRs where vectorization is also failing due to casts - PR31873 , PR26128 - don't know if this is related) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39068
[Bug c++/39070] New: Segmentation fault
$ cat test.cpp
templatetypename X struct junk {
templatetypename Y static Y y();
templatetypename Y char test(typeof(yY().foo())*);
static int const value=sizeof(testX(0));
};
int function() { int const v=junkint::value; };
$ g++ -c -v test.cpp
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: /home/rk/xdisw/base/gnutools/gcc-4.3.3/configure
--enable-shared --enable-threads=posix --disable-checking --with-system-zlib
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-languages=c,c++
--enable-werror
Thread model: posix
gcc version 4.3.3 (GCC)
COLLECT_GCC_OPTIONS='-c' '-v' '-shared-libgcc' '-mtune=generic'
/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.3.3/cc1plus -quiet -v
-D_GNU_SOURCE test.cpp -quiet -dumpbase test.cpp -mtune=generic -auxbase test
-version -o /tmp/ccn9FvNk.s
ignoring nonexistent directory
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.3/../../../../x86_64-unknown-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.3/../../../../include/c++/4.3.3
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.3/../../../../include/c++/4.3.3/x86_64-unknown-linux-gnu
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.3/../../../../include/c++/4.3.3/backward
/usr/local/include
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.3/include
/usr/local/lib/gcc/x86_64-unknown-linux-gnu/4.3.3/include-fixed
/usr/include
End of search list.
GNU C++ (GCC) version 4.3.3 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.3.3, GMP version 4.2.4, MPFR version 2.3.2.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: f44867537d1291d59450732603599474
test.cpp: In instantiation of 'const int junkint::value':
test.cpp:7: instantiated from here
test.cpp:4: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
$ uname -a
Linux wata 2.6.18-92.1.22.el5 #1 SMP Tue Dec 16 11:57:43 EST 2008 x86_64 x86_64
x86_64 GNU/Linux
--
Summary: Segmentation fault
Product: gcc
Version: 4.3.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: kononov at ftml dot net
GCC build triplet: x86_64-unknown-linux-gnu
GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39070
[Bug tree-optimization/38984] [4.2/4.3 Regression] NULL pointers always considered distinct by PTA, even with -fno-delete-null-pointer-checks
--- Comment #14 from rguenth at gcc dot gnu dot org 2009-02-01 21:34 --- Hm, on the alias-improvements branch I now XPASS the not return 1 check, but - why do you think we should have two dereferences to *p? Hm, because: # VUSE .MEM_6(D) a = *p; # .MEM_7 = VDEF .MEM_6(D) *0B = 5; return *p == a; in optimized. # VUSE .MEM_6(D) a_2 = *p_1(D); # .MEM_7 = VDEF .MEM_6(D) *0B = 5; # VUSE .MEM_7 D.1236_4 = *p_1(D); -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38984
[Bug pch/39071] New: [4.4 regression] All gcc.dg/pch tests FAIL on mipsel-linux
From: http://gcc.gnu.org/ml/gcc-testresults/2009-02/msg00069.html FAIL: gcc.dg/pch/common-1.c -O0 -g -I. (test for excess errors) FAIL: gcc.dg/pch/common-1.c -O0 -g assembly comparison FAIL: gcc.dg/pch/common-1.c -O0 -I. (test for excess errors) ... Executing on host: /n/pc2/guerby/build-143818/gcc/xgcc -B/n/pc2/guerby/build-143818/gcc/ ./common-1.h -O0 -g -o common-1.h.gch (timeout = 300) PASS: ./common-1.h -O0 -g (test for excess errors) Executing on host: /n/pc2/guerby/build-143818/gcc/xgcc -B/n/pc2/guerby/build-143818/gcc/ /home/guerby/work/trunk/gcc/testsuite/gcc.dg/pch/common-1.c -O0 -g -I. -S -o common-1.s(timeout = 300) xgcc: Internal error: Segmentation fault (program cc1) Please submit a full bug report. Pasting the command is not enough so I'm unable to provide a backtrace. Matthias Klose is also seeing those failures on 4.4 at least since 20080523 http://people.debian.org/~doko/tmp/gcc-mips/gcc-snapshot_20080523-1_mipsel.bz2 http://people.debian.org/~doko/tmp/gcc-mips/gcc-snapshot_20090107-1_mipsel.bz2 FAIL: ./common-1.h -O0 -g (test for excess errors) FAIL: gcc.dg/pch/common-1.c -O0 -g FAIL: gcc.dg/pch/common-1.c -O0 -g assembly comparison FAIL: ./common-1.h -O0 (test for excess errors) FAIL: gcc.dg/pch/common-1.c -O0 FAIL: gcc.dg/pch/common-1.c -O0 assembly comparison ... -- Summary: [4.4 regression] All gcc.dg/pch tests FAIL on mipsel- linux Product: gcc Version: 4.4.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: pch AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: laurent at guerby dot net GCC target triplet: mipsel-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39071
[Bug tree-optimization/38984] [4.2/4.3 Regression] NULL pointers always considered distinct by PTA, even with -fno-delete-null-pointer-checks
--- Comment #15 from rguenth at gcc dot gnu dot org 2009-02-01 22:02 --- Err, that last comment probably didn't make much sense. I wanted to say I see # VUSE .MEM_6(D) a = *p; # .MEM_7 = VDEF .MEM_6(D) *0B = 5; return *p == a; so the pattern for two = *p does not match. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38984
[Bug pch/39071] [4.4 regression] All gcc.dg/pch tests FAIL on mipsel-linux
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Priority|P3 |P4 Target Milestone|--- |4.4.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39071
[Bug fortran/39072] New: I/O READing logical value beyond end of string
This might end up at won't fix. I don't know whether the program is invalid (I wouldn't wonder if it were). Using ifort 11.1, openf95, sunf95, pathf95 and pgif95 the attached program shows as last logical value F. Using NAG f95, g95 and gfortran, it aborts while reading the last logical. (g77 also fails, but it also fails for the valid (commented out) test case.) -- Summary: I/O READing logical value beyond end of string Product: gcc Version: 4.4.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: burnus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39072
[Bug fortran/39072] I/O READing logical value beyond end of string
--- Comment #1 from burnus at gcc dot gnu dot org 2009-02-01 23:09 --- Created an attachment (id=17226) -- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17226action=view) Test case -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39072
[Bug fortran/39072] I/O READing logical value beyond end of string
--- Comment #2 from burnus at gcc dot gnu dot org 2009-02-01 23:18 --- If one reads an integer (i1) instead of a logical variable (l1), gfortran/g95/f95 read a 0. * * * 10.6.2 Logical editing makes it quite explicit that it is invalid: The input field consists of optional blanks, optionally followed by a period, followed by a T for true or F for false. The T or F may be followed by additional characters in the field, which are ignored. A lower-case letter is equivalent to the corresponding upper-case letter in a logical input field. Regarding i1: 10.6.1 Numeric editing: On input, [...] A field containing only blanks is considered to be zero. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39072
[Bug c++/39053] [4.4 regression] ICE with broken function declaration
--- Comment #3 from paolo at gcc dot gnu dot org 2009-02-02 00:42 --- Subject: Bug 39053 Author: paolo Date: Mon Feb 2 00:41:52 2009 New Revision: 143861 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=143861 Log: /cp 2009-02-01 Paolo Carlini paolo.carl...@oracle.com PR c++/39053 * parser.c (cp_parser_pure_specifier): If there are no tokens left do not call cp_lexer_consume_token. /testsuite 2009-02-01 Paolo Carlini paolo.carl...@oracle.com PR c++/39053 * g++.dg/parse/crash52.C: New. Added: trunk/gcc/testsuite/g++.dg/parse/crash52.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39053
[Bug c++/39053] [4.4 regression] ICE with broken function declaration
--- Comment #4 from paolo dot carlini at oracle dot com 2009-02-02 00:43 --- Fixed for 4.4.0. -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39053
[Bug c++/35075] [4.2/4.3/4.4 regression] ICE with references in templates
--- Comment #3 from paolo dot carlini at oracle dot com 2009-02-02 01:58 --- Mine. -- paolo dot carlini at oracle dot com changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |paolo dot carlini at oracle |dot org |dot com Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35075
[Bug c/39034] Decimal floating-point math done wrong
--- Comment #3 from bje at gcc dot gnu dot org 2009-02-02 02:35 --- Thanks for expanding the test case, Janis. I think this is worthy of a test case in the regression testsuite, which I will submit now. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39034
[Bug testsuite/38263] gcc.dg/ipa/ipacost-2.c fails with -fpic/-fPIC
--- Comment #3 from ghazi at gcc dot gnu dot org 2009-02-02 03:49 --- Patch posted here: http://gcc.gnu.org/ml/gcc-patches/2009-02/msg00050.html -- ghazi at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2009-01-17 03:36:56 |2009-02-02 03:49:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38263
[Bug c++/38928] infinite loop on error message in C++ only
--- Comment #6 from mmitchel at gcc dot gnu dot org 2009-02-02 06:41 --- Yes, designated initializers are of course a GNU extension to C++. I'm surprised that icc accepts them in its strict mode. In GNU C++, it makes sense for us to accept the same extensions that are accepted in GNU C. So, if GCC accepts this, I think G++ should too. (I don't know what the initialization of id_struct with 0 means, though; does it only initialize the first element of id_struct::is_ip_addrs?) However, the GCC and G++ code that processes initializers is, I think, mostly if not totally distinct. So, it's likely that some significant work would need to be done to handle this case. -- Mark -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38928
[Bug c++/38908] [4.4 regression] Unexplained 'anonymous' is used uninitialized in this function warning in cc1plus -m64
--- Comment #16 from mark at codesourcery dot com 2009-02-02 07:15 ---
Subject: Re: [4.4 regression] Unexplained 'anonymous' is
used uninitialized in this function warning in cc1plus -m64
rguenther at suse dot de wrote:
Ok. But, as opposed to inheritance, inserting empty members seems to
make a class non-empty:
struct A {};
struct B { A x; };
I'm surprised by that too, but the ABI definition is:
empty class
A class with no non-static data members other than zero-width
bitfields, no virtual functions, no virtual base classes, and no
non-empty non-virtual proper base classes.
Here, we do have a non-static data member that is not a zero-width
bitfield, so I guess this isn't an empty class.
So, CLASSTYPE_EMPTY_P would be a conservative approximation at present,
but we need a new bit to capture the broader thing that is desired here.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38908
