[Bug tree-optimization/42719] "-fcompare-debug failure" with "-O2 -ftracer"
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||01/msg00999.html Status|NEW |ASSIGNED Last reconfirmed|2010-01-18 14:53:08 |2010-01-19 08:18:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42719
[Bug debug/42728] "-fcompare-debug failure (length)" at -O1
-- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jakub at gcc dot gnu dot org |dot org | URL||http://gcc.gnu.org/ml/gcc- ||patches/2010- ||01/msg01000.html Status|NEW |ASSIGNED Last reconfirmed|2010-01-18 13:03:43 |2010-01-19 08:18:42 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42728
[Bug debug/42782] [4.5 Regression] VTA missed location: parameter via stack
--- Comment #4 from aoliva at gcc dot gnu dot org 2010-01-19 08:44 --- Mine (testing a patch) -- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42782
[Bug other/42715] [4.5 Regression] output_operand: invalid expression as operand
--- Comment #6 from aoliva at gcc dot gnu dot org 2010-01-19 08:44 --- Mine (testing a patch) -- aoliva at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |aoliva at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42715
[Bug debug/41371] [4.5 Regression] var-tracking is slow and memory hungry
--- Comment #15 from jakub at gcc dot gnu dot org 2010-01-19 09:03 --- This patch seems to fix issues with (most of) KDE testcases, but there are still some testcases where gcc spends very long time in var-tracking (usually generated huge routines where simply too many VALUEs are tracked through). E.g. https://bugzilla.redhat.com/show_bug.cgi?id=548826 and https://bugzilla.redhat.com/show_bug.cgi?id=531218 These can be worked around by the #c9 patch, even with much bigger default (50mil). Not sure if we should track this all in this bug, or just split into separate bugs. -- jakub at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|jakub at gcc dot gnu dot org|unassigned at gcc dot gnu ||dot org Status|ASSIGNED|NEW http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41371
[Bug regression/42282] regression: ICE when bootstrapping trunk with -O2 -funswitch-loops
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-19 09:14 --- Please retry with current trunk, there have been many fixes recently. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42282
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #9 from FBergemann at web dot de 2010-01-19 09:25 --- change "Reported against" to 3.4.6. Because 3.4.6 is the last version of the 3.4.x series. I tested with that as well, but it fails, too. And i would have withdrawn this issue, if it would have worked for 3.4.6. This means, that gcc-3.4.x has a deficit for hp-ux B11.31 ia64 and should not be used for that architecture - unless some fellows at HP will make negative confirmation and proof that's it's e.g. due to the set-up of my machine. I'll ask HP for verification - and likely switch to a newer gcc :-) rgds, Frank -- FBergemann at web dot de changed: What|Removed |Added Version|3.4.4 |3.4.6 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug bootstrap/42798] New: --enable-build-with-cxx bootstrap fails on i686-pc-linux-gnu (Fedora12)
I am trying to build mainline GCC (revision 156033) configured with -enable-build-with-cxx . I get the following error during bootstrap: make[3]: Entering directory `/user/inria/fsf/bld-gcc-cxx2/libcpp' g++ -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include -g -W -Wall -Wwrite-strings -Wmissing-format-attribute -pedantic -Wno-long-long -I../../gcc/libcpp -I. -I../../gcc/libcpp/../include -I../../gcc/libcpp/include -c -o charset.o -MT charset.o -MMD -MP -MF .deps/charset.Tpo ../../gcc/libcpp/charset.c In file included from ../../gcc/libcpp/system.h:341, from ../../gcc/libcpp/charset.c:22: ../../gcc/libcpp/../include/libiberty.h:106: error: new declaration char* basename(const char*) /usr/include/string.h:601: error: ambiguates old declaration const char* basename(const char*) make[3]: *** [charset.o] Error 1 make[3]: Leaving directory `/user/inria/fsf/bld-gcc-cxx2/libcpp' make[2]: *** [all-stage1-libcpp] Error 2 make[2]: Leaving directory `/user/inria/fsf/bld-gcc-cxx2' make[1]: *** [stage1-bubble] Error 2 make[1]: Leaving directory `/user/inria/fsf/bld-gcc-cxx2' make: *** [bootstrap] Error 2 -- Summary: --enable-build-with-cxx bootstrap fails on i686-pc- linux-gnu (Fedora12) Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org GCC host triplet: i686-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42798
[Bug c/42799] New: Variable unexpectedly set to 0 because a scanf()
I'm learning C, so it's possible there's a reason for this, but I've made a lot
of tests to find out that in my source code a variable (called "q_num") changes
from 3 to 0 just because of a scanf().
I tested the code with these lines:
...
printf("1. %d\n",q_num);
p=scanf("%d",&idade);
printf("2. %d\n",q_num);
...
And results in:
1. 3 // Value dynamicly set before by a function
15// Just the value entered to the scanf()
2. 0 // Value after the scanf(), expected a 3 again
I'll attach complete source code.
--
Summary: Variable unexpectedly set to 0 because a scanf()
Product: gcc
Version: 4.4.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: adriyetichaves at gmail dot com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42799
[Bug c/42799] Variable unexpectedly set to 0 because a scanf()
--- Comment #1 from adriyetichaves at gmail dot com 2010-01-19 09:59
---
I've simplified the code, step by step (though that removing functions would
change the result), but this simple code still gets the same error:
#include
int main(void)
{
unsigned short int q_num, idade, p, dimension;
q_num=3;
// dimension=q_num; This would fix the bug
printf("1. %d\n",q_num);
p=scanf("%d",&idade);
printf("2. %d\n",q_num);
return -1;
}
About the output of gcc ($ gcc -v -save-temps -o temp bugcode.c ):
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../configure --prefix=/usr --enable-shared
--enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-threads=posix
--mandir=/usr/share/man --infodir=/usr/share/info --enable-__cxa_atexit
--disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu
--disable-libstdcxx-pch --with-tune=generic
Thread model: posix
gcc version 4.4.2 20091208 (prerelease) (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'temp' '-mtune=generic'
/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/cc1 -E -quiet -v bugcode.c -mtune=generic
-fpch-preprocess -o bugcode.i
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/include
/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'temp' '-mtune=generic'
/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/cc1 -fpreprocessed bugcode.i -quiet
-dumpbase bugcode.c -mtune=generic -auxbase bugcode -version -o bugcode.s
GNU C (GCC) version 4.4.2 20091208 (prerelease) (i686-pc-linux-gnu)
compiled by GNU C version 4.4.2 20091208 (prerelease), GMP version
4.3.1, MPFR version 2.4.1.
GGC heuristics: --param ggc-min-expand=98 --param ggc-min-heapsize=128032
Compiler executable checksum: caa9064c9b58d9d704202d766b06d9de
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'temp' '-mtune=generic'
as -V -Qy -o bugcode.o bugcode.s
GNU assembler version 2.20.0 (i686-pc-linux-gnu) using BFD version (GNU
Binutils) 2.20.0.20091101
COMPILER_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/:/usr/lib/gcc/i686-pc-linux-gnu/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/:/usr/lib/gcc/i686-pc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/:/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-o' 'temp' '-mtune=generic'
/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/collect2 --eh-frame-hdr -m elf_i386
--hash-style=both -dynamic-linker /lib/ld-linux.so.2 -o temp
/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/../../../crt1.o
/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/../../../crti.o
/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/crtbegin.o
-L/usr/lib/gcc/i686-pc-linux-gnu/4.4.2 -L/usr/lib/gcc/i686-pc-linux-gnu/4.4.2
-L/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/../../.. bugcode.o -lgcc --as-needed
-lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed
/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/crtend.o
/usr/lib/gcc/i686-pc-linux-gnu/4.4.2/../../../crtn.o
--
adriyetichaves at gmail dot com changed:
What|Removed |Added
CC||adriyetichaves at gmail dot
||com
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42799
[Bug c/42799] Variable unexpectedly set to 0 because a scanf()
--- Comment #2 from adriyetichaves at gmail dot com 2010-01-19 10:04 --- Same code compiled in other compiler (Turbo C++) works. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42799
[Bug debug/42800] New: VLA DW_AT_upper_bound is no longer emitted
FAIL: gcc (GCC) 4.5.0 20100119 (experimental)
PASS: gcc (GCC) 4.4.3 20100119 (prerelease)
PASS: gcc-4.4.2-20.fc12.x86_64 (Fedora 12)
---
gcc -c -o vla.o vla.c -Wall -g
---
This is a 4.4 -> 4.5 debug regression.
---
int
f (int i)
{
char a[i];
return a[0];
}
---
FAIL:
< c> DW_AT_producer: (indirect string, offset: 0x11): GNU C 4.5.0
20100119 (experimental)
<2><5c>: Abbrev Number: 4 (DW_TAG_variable)
<5d> DW_AT_name: a
<61> DW_AT_type: <0x71>
<65> DW_AT_location: 3 byte block: 91 60 6(DW_OP_fbreg: -32;
DW_OP_deref)
<1><71>: Abbrev Number: 6 (DW_TAG_array_type)
<72> DW_AT_type: <0x83>
<2><7a>: Abbrev Number: 7 (DW_TAG_subrange_type)
<7b> DW_AT_type: <0x80>
---
PASS:
< c> DW_AT_producer: (indirect string, offset: 0x17): GNU C 4.4.3
20100119 (prerelease)
<2><5c>: Abbrev Number: 4 (DW_TAG_variable)
<5d> DW_AT_name: a
<61> DW_AT_type: <0x71>
<65> DW_AT_location: 3 byte block: 91 68 6(DW_OP_fbreg: -24;
DW_OP_deref)
<1><71>: Abbrev Number: 6 (DW_TAG_array_type)
<72> DW_AT_type: <0x87>
<2><7a>: Abbrev Number: 7 (DW_TAG_subrange_type)
<7b> DW_AT_type: <0x84>
<7f> DW_AT_upper_bound : 3 byte block: 91 60 6(DW_OP_fbreg: -32;
DW_OP_deref)
--
Summary: VLA DW_AT_upper_bound is no longer emitted
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42800
[Bug c++/42791] boost[1.33.1]::spirit depends on optimization level
--- Comment #10 from FBergemann at web dot de 2010-01-19 10:06 --- if i compile the sample on hp-ux ia64 for 32 bits, it's generating a coredump: (gdb) r Starting program: /nfs/uh01/frank/TESTX/sample test is '' Program received signal SIGBUS, Bus error si_code: 1 - BUS_ADRALN - Invalid address alignment. Please refer to the following link that helps in handling unaligned data: http://docs.hp.com/en/7730/newhelp0610/pragmas.htm#pragma-pack-ex3. boost::spirit::grammar,boost::spirit::parser_context >::grammar (this=0x40025cf0) at sp_counted_base_gcc_ia64.hpp:38 38 "r"(pw)); seems to be related to alignment(?!) rgds, Frank -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42791
[Bug debug/42801] New: C VLAs should use DW_AT_allocated
FAIL: gcc (GCC) 4.4.3 20100119 (prerelease)
FAIL: gcc-4.4.2-20.fc12.x86_64 (Fedora 12)
SKIP: gcc (GCC) 4.5.0 20100119 (experimental) - N/A - blocked by PR debug/42800
--
Currently the type of a VLA (Variable Length Array) contains incorrect bounds
before the specific variable is allocated. Fortran uses DW_AT_allocated in
such case and GDB with archer-jankratochvil-vla patch properly avoids
evaluating the invalid bounds printing:
(gdb) ptype varx
type =
Currently with -O0 its DW_AT_location is defined even before it is allocated.
With -O2 its DW_AT_location is never defined (suboptimal VTA?). Offtopic here.
Still IMO the type should have DW_AT_allocated indicator and not depend on
never being evaluated when its variable has DW_AT_location undefined
(=).
This is not a regression bug.
--
static long
f (void)
{
long l = 0x7ffe; /* Pre-fill DW_AT_upper_bound of `a'. */
long unused = l;
return l | unused;
}
static int
g (long l)
{
char a[l];/* gdb -ex 'b 13' -ex r -ex 'ptype a' */
return a[0];
}
int
main (void)
{
f ();
return g (5);
}
--
(gcc -o 1 1.c -m64 -Wall -g; ulimit -v 50; gdb -nx -ex 'b 13' -ex r -ex
'ptype a' ./1)
--
Breakpoint 1, g (l=5) at 1.c:13
13char a[l];/* gdb -ex 'b 13' -ex r -ex 'ptype a' */
../../gdb/utils.c:1205: internal-error: virtual memory exhausted: can't
allocate 2147483647 bytes.
The problem is GDB internally allocates the type being printed (which is
suboptimal). Still it shows the type is valid but with incorrect bounds there.
Reducing the size will print the incorrect bound:
type = char [134217727]
--
Summary: C VLAs should use DW_AT_allocated
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: debug
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jan dot kratochvil at redhat dot com
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42801
[Bug c/42799] Variable unexpectedly set to 0 because a scanf()
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-19 10:21 --- This is undefined behavior, scanf is writing int value into an unsigned short variable, so it of course can overwrite whatever happens to be adjacent to that var on the stack. Use %hd instead of %d to write to short/unsigned short vars in scanf format string, or write to int variable instead. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42799
[Bug debug/42800] [4.5 Regression] VLA DW_AT_upper_bound is no longer emitted
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added Summary|VLA DW_AT_upper_bound is no |[4.5 Regression] VLA |longer emitted |DW_AT_upper_bound is no ||longer emitted Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42800
[Bug c++/42336] [4.5 Regression] ICE with pointer-to-member-function argument in template function
--- Comment #19 from rguenth at gcc dot gnu dot org 2010-01-19 10:26 --- I wonder why the C++ frontend emits overload resolution errors from emitting debug information like seen in the duplicate PR42797. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42336
[Bug c++/42797] call of overloaded 'allocator()' is ambiguous
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-19 10:27 --- *** This bug has been marked as a duplicate of 42336 *** -- 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=42797
[Bug c++/42336] [4.5 Regression] ICE with pointer-to-member-function argument in template function with -fipa-sra
--- Comment #20 from rguenth at gcc dot gnu dot org 2010-01-19 10:27 --- *** Bug 42797 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||foom at fuhm dot net http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42336
[Bug target/42796] ICE on building libstdc++-v3
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-19 10:29 --- Without preprocessed source of the testcase nobody is going to look at this. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |WAITING http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42796
[Bug tree-optimization/42614] [4.4 Regression] FRE optimizes away valid code after IPA inlining
--- Comment #16 from rguenth at gcc dot gnu dot org 2010-01-19 10:39 --- *** Bug 42794 has been marked as a duplicate of this bug. *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added CC||sergei_lus at yahoo dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42614
[Bug middle-end/42794] PRE produces illegal PHI node
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-19 10:39 --- The issue is (verified with 4.4.0): # VUSE D.1626_14 = Decode_1(D)->ActualSize; ... # complete_24 = VDEF # SMT.13_25 = VDEF *BufLen_3 = D.1619_8; thus the alias information is wrong. This has been fixed for 4.4.3. *** This bug has been marked as a duplicate of 42614 *** -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42794
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility with static common vars.
--- Comment #27 from hubicka at ucw dot cz 2010-01-19 10:48 --- Subject: Re: [4.5 regression] ICE in function_and_variable_visibility with static common vars. > 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). Does it happen also with the reduced version of the patch I comitted to mainline? I can't imagine how this one can trigger ICE, but it might be independent change in meantime as I was slow on fixing this bug :( Does the reduced testcase also trigger it? (I will try it on cross, since without useful backtrace I can't do much). I proofread the other part of patch but don't see anything obviously wrong here. Honza -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug debug/42801] C VLAs should use DW_AT_allocated
--- Comment #1 from jan dot kratochvil at redhat dot com 2010-01-19 10:57 --- Maybe properly limiting DW_AT_location even in -O0 -g mode would be the same. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42801
[Bug libstdc++/42712] search_n/iterator.cc times out in parallel-mode
--- Comment #5 from singler at gcc dot gnu dot org 2010-01-19 11:18 --- Subject: Bug 42712 Author: singler Date: Tue Jan 19 11:18:03 2010 New Revision: 156036 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156036 Log: 2010-01-19 Johannes Singler PR libstdc++/42712 * include/parallel/settings.h (_Settings): Add search_minimal_n. * include/parallel/algo.h (__search_switch): Add serial fallback for too small inputs. (__search_n_switch): Likewise. Call serial fallback on higher level to gain special treatment for __count 0 or 1. * testsuite/25_algorithms/search_n/iterator.cc: Reenable full test depth for parallel mode. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/parallel/algo.h trunk/libstdc++-v3/include/parallel/settings.h trunk/libstdc++-v3/testsuite/25_algorithms/search_n/iterator.cc -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42712
[Bug rtl-optimization/42802] New: FMAs not exploited
double bar(double x, double y)
{
double tmp = 0.1234 * y;
return ((x + tmp) * (x - tmp));
}
GCC should use multiply-add and multiply-sub when that is cheaper than
one multiplication and two additions.
With -mfma4 on x86_64 instead of
vmulsd .LC0(%rip), %xmm1, %xmm1
vaddsd %xmm1, %xmm0, %xmm2
vsubsd %xmm1, %xmm0, %xmm0
vmulsd %xmm0, %xmm2, %xmm0
it should generate
vmovsd .LC0(%rip), %xmm3
vfmaddsd%xmm0, %xmm3, %xmm1, %xmm2
vfnmaddsd %xmm0, %xmm3, %xmm1, %xmm0
vmulsd %xmm0, %xmm2, %xmm0
See also PR19988.
FMA opportunities of this kind should probably be detected during RTL
expansion, similar to widening multiplications.
--
Summary: FMAs not exploited
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: rtl-optimization
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: rguenth at gcc dot gnu dot org
GCC target triplet: powerpc64-*-*, x86_64-*-*
OtherBugsDependingO 19988
nThis:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42802
[Bug middle-end/19988] [4.3/4.4/4.5 Regression] pessimizes fp multiply-add/subtract combo
-- rguenth at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn|42802 | AssignedTo|unassigned at gcc dot gnu |rguenth at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-08-17 12:43:49 |2010-01-19 11:38:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19988
[Bug libstdc++/42712] search_n/iterator.cc times out in parallel-mode
--- Comment #6 from paolo dot carlini at oracle dot com 2010-01-19 12:08 --- Confirmed fixed, thanks! -- paolo dot carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42712
[Bug middle-end/42068] [4.5 regression] ICE in function_and_variable_visibility with static common vars.
--- Comment #28 from simon at pushface dot org 2010-01-19 12:36 --- (In reply to comment #27) I am sorry for spreading confusion & wasting time, I had a different PR-resolution process in mind. Now that the reduced patch is committed to mainline, there is no longer an ICE during build of i86_64-apple-darwin10.2, powerpc-wrs-vxworks. So Richard is right in comment #23. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42068
[Bug debug/42728] "-fcompare-debug failure (length)" at -O1
--- Comment #3 from jakub at gcc dot gnu dot org 2010-01-19 12:38 --- Subject: Bug 42728 Author: jakub Date: Tue Jan 19 12:38:25 2010 New Revision: 156037 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156037 Log: PR debug/42728 * fwprop.c (all_uses_available_at): Return false if def_set dest is a REG that is used in def_insn. * gcc.dg/pr42728.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr42728.c Modified: trunk/gcc/ChangeLog trunk/gcc/fwprop.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42728
[Bug tree-optimization/42719] "-fcompare-debug failure" with "-O2 -ftracer"
--- Comment #7 from jakub at gcc dot gnu dot org 2010-01-19 12:39 --- Subject: Bug 42719 Author: jakub Date: Tue Jan 19 12:39:42 2010 New Revision: 156038 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156038 Log: PR tree-optimization/42719 * tree-outof-ssa.c (trivially_conflicts_p): Don't consider debug stmt uses. * gcc.dg/pr42719.c: New test. Added: trunk/gcc/testsuite/gcc.dg/pr42719.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-outof-ssa.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42719
[Bug tree-optimization/42719] "-fcompare-debug failure" with "-O2 -ftracer"
--- Comment #8 from jakub at gcc dot gnu dot org 2010-01-19 12:41 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42719
[Bug debug/42728] "-fcompare-debug failure (length)" at -O1
--- Comment #4 from jakub at gcc dot gnu dot org 2010-01-19 12:42 --- Fixed. -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42728
[Bug rtl-optimization/42802] FMAs not exploited
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-19 13:08 ---
Playing with patterns like
(define_insn "*fma4_fmadd4_1"
[(set (match_operand:SSEMODEF4 0 "register_operand" "=x,x")
(plus:SSEMODEF4
(mult:SSEMODEF4
(match_operand:SSEMODEF4 2 "nonimmediate_operand" "%x,x")
(match_operand:SSEMODEF4 3 "nonimmediate_operand" "x,m"))
(match_operand:SSEMODEF4 4 "nonimmediate_operand" "xm,x")))
(set (match_operand:SSEMODEF4 1 "register_operand" "=x,x")
(mult:SSEMODEF4
(match_dup 2)
(match_dup 3)))]
"TARGET_FMA4 && TARGET_FUSED_MADD"
"vmul\t{%3, %2, %1|%1, %2, %3}\n
vadd\t{%4, %1, %0|%0, %1, %4}"
[(set_attr "type" "ssemuladd")
(set_attr "mode" "")])
and trying to exploit combine doesn't work as while it combines the
multiplication and the addition into the above the subtraction
isn't combined into (of course - the separate multiplication is already
gone).
Another idea would be to use fwprop for this, instead of propagating
single-uses only propagate also if propagation into all uses is possible.
--
rguenth 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-19 13:08:16
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42802
[Bug fortran/42545] type extension: parent component has wrong accessibility
--- Comment #8 from janus at gcc dot gnu dot org 2010-01-19 13:20 --- Patch posted at: http://gcc.gnu.org/ml/fortran/2010-01/msg00101.html -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-19 13:20:04 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42545
[Bug c++/42803] New: [(probably) regression gcc 4.4 on 32bit] c++ compilation hang
Compilation hangs at the following file for several hours (then I stopped it). According to http://www.rawtherapee.com/forum/viewtopic.php?t=1719 this seems to be a regression in gcc 4.4 which is present on multiple GNU/Linux distributions, all 32bit. 64bit doesn't seem to be affected. Another discussion about this topic is hold in http://aur.archlinux.org/packages.php?ID=11186 gcc 4.3 is said to work (I didn't tested it myself because compilation of gcc takes several hours on my 32bit machine). OS -- Archlinux current Tested gcc versions Using built-in specs. Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr --enable-shared --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-threads=posix --mandir=/usr/share/man --infodir=/usr/share/info --enable-__cxa_atexit --disable-multilib --libdir=/usr/lib --libexecdir=/usr/lib --enable-clocale=gnu --disable-libstdcxx-pch --with-tune=generic Thread model: posix gcc version 4.4.2 20091208 (prerelease) (GCC) Using built-in specs. COLLECT_GCC=gcc-4.5 COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-linux-gnu/4.5.0/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/usr --enable-languages=c,c++ --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-lto --enable-gnu-unique-object --disable-multilib --disable-libstdcxx-pch --with-tune=generic --with-system-zlib --with-ppl --with-cloog --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --disable-werror --enable-checking=release --program-suffix=-4.5 --enable-version-specific-runtime-libs Thread model: posix gcc version 4.5.0 20100114 (experimental) (GCC) -- Summary: [(probably) regression gcc 4.4 on 32bit] c++ compilation hang Product: gcc Version: 4.4.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: l dot jirkovsky at gmail dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42803
[Bug fortran/42545] type extension: parent component has wrong accessibility
--- Comment #9 from janus at gcc dot gnu dot org 2010-01-19 13:45 --- Subject: Bug 42545 Author: janus Date: Tue Jan 19 13:45:07 2010 New Revision: 156040 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156040 Log: gcc/fortran/ 2010-01-19 Janus Weil PR fortran/42545 * resolve.c (resolve_fl_derived): Set the accessibility of the parent component for extended types. * symbol.c (gfc_find_component): Remove a wrongly-worded error message and take care of parent component accessibility. gcc/testsuite/ 2010-01-19 Janus Weil PR fortran/42545 * gfortran.dg/extends_6.f03: Modified an error message. * gfortran.dg/extends_10.f03: New test. * gfortran.dg/private_type_6.f03: Modified an error message. * gfortran.dg/structure_constructor_8.f03: Ditto. Added: trunk/gcc/testsuite/gfortran.dg/extends_10.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/extends_6.f03 trunk/gcc/testsuite/gfortran.dg/private_type_6.f90 trunk/gcc/testsuite/gfortran.dg/structure_constructor_8.f03 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42545
[Bug c++/42803] [(probably) regression gcc 4.4 on 32bit] c++ compilation hang
--- Comment #1 from l dot jirkovsky at gmail dot com 2010-01-19 13:45 --- Created an attachment (id=19654) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19654&action=view) Compilation hangs on this file -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42803
[Bug c++/42803] [4.4/4.5 Regression] c++ compilation hang
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-19 14:00 --- Confirmed. Backtrace: #0 0x00e50900 in tree_operand_length (node=0x72201d58) at /space/rguenther/src/svn/trunk/gcc/tree.h:5340 #1 0x00e5c983 in initializer_constant_valid_p (value=0x72201d58, endtype=0x77ee7540) at /space/rguenther/src/svn/trunk/gcc/varasm.c:4336 #2 0x00e5c90d in initializer_constant_valid_p (value=0x72201e38, endtype=0x77ee7540) at /space/rguenther/src/svn/trunk/gcc/varasm.c:4335 #3 0x00e5b328 in narrowing_initializer_constant_valid_p ( value=0x72201f18, endtype=0x77ee7540) at /space/rguenther/src/svn/trunk/gcc/varasm.c:4144 #4 0x00e5ca2e in initializer_constant_valid_p (value=0x72201f18, endtype=0x77ee7540) at /space/rguenther/src/svn/trunk/gcc/varasm.c:4346 #5 0x00e5b328 in narrowing_initializer_constant_valid_p ( value=0x72202000, endtype=0x77ee7540) at /space/rguenther/src/svn/trunk/gcc/varasm.c:4144 #6 0x00e5ca2e in initializer_constant_valid_p (value=0x72202000, endtype=0x77ee7540) at /space/rguenther/src/svn/trunk/gcc/varasm.c:4346 #7 0x00e5b328 in narrowing_initializer_constant_valid_p ( value=0x72202150, endtype=0x77ee7540) at /space/rguenther/src/svn/trunk/gcc/varasm.c:4144 ... #45 0x00e5c272 in initializer_constant_valid_p (value=0x72200ae0, endtype=0x77ee7540) at /space/rguenther/src/svn/trunk/gcc/varasm.c:4285 4285 return initializer_constant_valid_p (src, endtype); #46 0x005ba410 in store_init_value (decl=0x72177320, init=0x72203850, flags=0) at /space/rguenther/src/svn/trunk/gcc/cp/typeck2.c:734 734 if (value != error_mark_node (gdb) call debug_generic_expr (value) (unsigned int) int) *(*(src + ((unsigned int) i + 4) * 4) + ((unsigned int) j + 1) * 2) * *(ec + ((unsigned int) ((int) *(*(src + ((unsigned int) i + 4) * 4) + ((unsigned int) j + 1) * 2) - (int) *(*(src + (unsigned int) ((unsigned int) i * 4)) + (unsigned int) ((unsigned int) j * 2))) + 65536) * 4) + (int) *(*(src + ((unsigned int) i + 4) * 4) + (unsigned int) ((unsigned int) j * 2)) * *(ec + ((unsigned int) ((int) *(*(src + ((unsigned int) i + 4) * 4) + (unsigned int) ((unsigned int) j * 2)) - (int) *(*(src + (unsigned int) ((unsigned int) i * 4)) + (unsigned int) ((unsigned int) j * 2))) + 65536) * 4)) + ((int) *(*(src + ((unsigned int) i + 3) * 4) + ((unsigned int) j + 3) * 2) * *(ec + ((unsigned int) ((int) *(*(src + ((unsigned int) i + 3) * 4) + ((unsigned int) j + 3) * 2) - (int) *(*(src + (unsigned int) ((unsigned int) i * 4)) + (unsigned int) ((unsigned int) j * 2))) + 65536) * 4) + (int) *(*(src + ((unsigned int) i + 4) * 4) + ((unsigned int) j + -1) * 2) * *(ec + ((unsigned int) ((int) *(*(src + ((unsigned int) i + 4) * 4) + ((unsigned int) j + -1) * 2) - (int) *(*(src + (unsigned int) ((unsigned int) i * 4)) + (unsigned int) ((unsigned int) j * 2))) + 65536) * 4))) + (((int) *(*(src + ((unsigned int) i + 3) * 4) + ((unsigned int) j + 1) * 2) * *(ec + ((unsigned int) ((int) *(*(src + ((unsigned int) i + 3) * 4) + ((unsigned int) j + 1) * 2) - (int) *(*(src + (unsigned int) ((unsigned int) i * 4)) + (unsigned int) ((unsigned int) j * 2))) + 65536) * 4)) * 3 + ((int) *(*(src + ((unsigned int) i + 3) * 4) + ((unsigned int) j + 2) * 2) * *(ec + ((unsigned int) ((int) *(*(src + ((unsigned int) i + 3) * 4) + ((unsigned int) j + 2) * 2) - (int) *(*(src + (unsigned int) ((unsigned int) i * 4)) + (unsigned int) ((unsigned int) j * 2))) + 65536) * 4)) * 2)) + (((int) *(*(src + ((unsigned int) i + 3) * 4) + ((unsigned int) j + -1) * 2) * *(ec + ((unsigned int) ((int) *(*(src + ((unsigned int) i + 3) * 4) + ((unsigned int) j + -1) * 2) - (int) *(*(src + (unsigned int) ((unsigned int) i * 4)) + (unsigned int) ((unsigned int) j * 2))) + 65536) * 4)) * 3 + ((int) *(*(src + ((unsigned int) i + 3) * 4) + (unsigned int) ((unsigned int) j * 2)) * *(ec + ((unsigned int) ((int) *(*(src + ((unsigned int) i + 3) * 4) + (unsigned int) ((unsigned int) j * 2)) - (int) *(*(src + (unsigned int) ((unsigned int) i * 4)) + (unsigned int) ((unsigned int) j * 2))) + 65536) * 4)) * 4)) + ((int) *(*(src + ((unsigned int) i + 3) * 4) + ((unsigned int) j + -3) * 2) * *(ec + ((unsigned int) ((int) *(*(src + ((unsigned int) i + 3) * 4) + ((unsigned int) j + -3) * 2) - (int) *(*(src + (unsigned int) ((unsigned int) i * 4)) + (unsigned int) ((unsigned int) j * 2))) + 65536) * 4) + ((int) *(*(src + ((unsigned int) i + 3) * 4) + ((unsigned int) j + -2) * 2) * *(ec + ((unsigned int) ((int) *(*(src + ((unsigned int) i + 3) * 4) + ((unsigned int) j + -2) * 2) - (int) *(*(src + (unsigned int) ((unsigned int) i * 4)) + (unsigned int) ((unsigned int) j * 2))) + 65536) * 4)) * 2)) + (((int) *(*(src + ((unsigned int) i + 2) * 4) + ((unsigned int) j + 2) * 2) * *(ec + ((unsigned int) ((int) *(*(sr
[Bug fortran/42545] type extension: parent component has wrong accessibility
--- Comment #10 from janus at gcc dot gnu dot org 2010-01-19 14:00 --- Fixed with r156040. Closing. -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42545
[Bug fortran/42804] New: ICE with -fcheck=bounds and type bound procedure call on array element
A segmentation violation occurs in gfc_trans_runtime_error_vararg (trans.c:393) when compiling with -fcheck=bounds and an expression like the following is encountered: call array_of_derived_type(index)%type_bound_proc(args...) (With svn revision 156036) -- Summary: ICE with -fcheck=bounds and type bound procedure call on array element Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: ian_harvey at bigpond dot com GCC build triplet: i686-pc-mingw32 GCC host triplet: i686-pc-mingw32 GCC target triplet: i686-pc-mingw32 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #1 from ian_harvey at bigpond dot com 2010-01-19 14:06 --- Created an attachment (id=19655) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19655&action=view) Source code that demonstrates the ICE -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug c++/42803] [4.4/4.5 Regression] c++ compilation hang
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-19 14:07 --- I have a patch. -- 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|2010-01-19 14:00:13 |2010-01-19 14:07:19 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42803
[Bug target/38697] gcc.target/arm/neon/neon.exp tests for vmov fail on arm-linux-eabi
--- Comment #8 from ramana at gcc dot gnu dot org 2010-01-19 14:21 --- Subject: Bug 38697 Author: ramana Date: Tue Jan 19 14:21:14 2010 New Revision: 156042 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156042 Log: Fix target/38697 2010-01-19 Ramana Radhakrishnan PR target/38697 * config/arm/neon-testgen.m (emit_automatics): New parameter features. Adjust for Fixed_return_reg feature. (test_intrinsic): Call emit_automatics with new feature. * config/arm/neon.ml: Update copyright years. (features): New Fixed_return_reg feature. (ops): Update feature for Vget_low. 2010-01-19 Ramana Radhakrishnan PR target/38697. * gcc.target/arm/neon/vget_lowf32.c: Regenerate. * gcc.target/arm/neon/vget_lowp16.c: Likewise. * gcc.target/arm/neon/vget_lowp8.c: Likewise. * gcc.target/arm/neon/vget_lows16.c: Likewise. * gcc.target/arm/neon/vget_lows32.c: Likewise. * gcc.target/arm/neon/vget_lows64.c: Likewise. * gcc.target/arm/neon/vget_lows8.c: Likewise. * gcc.target/arm/neon/vget_lowu16.c: Likewise. * gcc.target/arm/neon/vget_lowu32.c: Likewise. * gcc.target/arm/neon/vget_lowu64.c: Likewise. * gcc.target/arm/neon/vget_lowu8.c: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/neon-testgen.ml trunk/gcc/config/arm/neon.ml trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/arm/neon/vget_lowf32.c trunk/gcc/testsuite/gcc.target/arm/neon/vget_lowp16.c trunk/gcc/testsuite/gcc.target/arm/neon/vget_lowp8.c trunk/gcc/testsuite/gcc.target/arm/neon/vget_lows16.c trunk/gcc/testsuite/gcc.target/arm/neon/vget_lows32.c trunk/gcc/testsuite/gcc.target/arm/neon/vget_lows64.c trunk/gcc/testsuite/gcc.target/arm/neon/vget_lows8.c trunk/gcc/testsuite/gcc.target/arm/neon/vget_lowu16.c trunk/gcc/testsuite/gcc.target/arm/neon/vget_lowu32.c trunk/gcc/testsuite/gcc.target/arm/neon/vget_lowu64.c trunk/gcc/testsuite/gcc.target/arm/neon/vget_lowu8.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38697
[Bug middle-end/42803] [4.4/4.5 Regression] c++ compilation hang
--- Comment #4 from rguenth at gcc dot gnu dot org 2010-01-19 14:24 --- Caused by r144394 2009-02-23 Jason Merrill PR c++/38880 * varasm.c (initializer_constant_valid_p) [PLUS_EXPR]: Check narrowing_initializer_constant_valid_p. (narrowing_initializer_constant_valid_p): Don't return null_pointer_node for adding a pointer to itself. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42803
[Bug middle-end/42805] New: FAIL: gcc.c-torture/execute/pr42248.c compilation at -O1 and above
Executing on host: /home/dave/gnu/gcc/objdir/gcc/xgcc -B/home/dave/gnu/gcc/objdi r/gcc/ /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr42248.c -w -O1 -lm -o /home/dave/gnu/gcc/objdir/gcc/testsuite/gcc/pr42248.x1 (timeo ut = 300) /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr42248.c: In functio n 'check': /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr42248.c:9:1: intern al compiler error: in make_decl_rtl, at varasm.c:1316 Breakpoint 2, make_decl_rtl (decl=0x4008f7e0) at ../../gcc/gcc/varasm.c:1312 1312 gcc_assert (TREE_CODE (decl) != VAR_DECL (gdb) p debug_tree (decl) unit size align 64 symtab 0 alias set -1 canonical type 0x40077f60 fields DC file /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr42248.c line 2 col 19 size unit size align 64 offset_align 64 offset bit offset context chain > context pointer_to_this chain > used BLK file /home/dave/gnu/gcc/gcc/gcc/testsuite/gcc.c-torture/execute/pr42248.c line 9 col 1 size unit size align 64 context chain > (gdb) bt #0 make_decl_rtl (decl=0x4008f7e0) at ../../gcc/gcc/varasm.c:1312 #1 0x00892cf8 in expand_expr_real_1 (exp=0x4008f7e0, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc/gcc/expr.c:8438 #2 0x0088a0ac in expand_expr_real (exp=0x4008f7e0, target=0x0, tmode=VOIDmode, modifier=EXPAND_NORMAL, alt_rtl=0x0) at ../../gcc/gcc/expr.c:7188 ... -- Summary: FAIL: gcc.c-torture/execute/pr42248.c compilation at -O1 and above Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: danglin at gcc dot gnu dot org GCC build triplet: hppa-unknown-linux-gnu GCC host triplet: hppa-unknown-linux-gnu GCC target triplet: hppa-unknown-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42805
[Bug middle-end/42805] FAIL: gcc.c-torture/execute/pr42248.c compilation at -O1 and above
--- Comment #1 from rguenth at gcc dot gnu dot org 2010-01-19 15:18 --- Can you check if the patch that introduced the testcase is responsible for the failure? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42805
[Bug bootstrap/42798] --enable-build-with-cxx bootstrap fails on i686-pc-linux-gnu (Fedora12)
--- Comment #1 from amylaar at gcc dot gnu dot org 2010-01-19 15:31 --- This patch: http://gcc.gnu.org/ml/gcc-patches/2010-01/msg01019.html gets past this failure, and has also been successfully bootstrapped & regtested without --enable-build-with-cxx bootstrap on i686-pc-linux-gnu -- amylaar at gcc dot gnu dot org changed: What|Removed |Added Keywords||patch http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42798
[Bug middle-end/42805] FAIL: gcc.c-torture/execute/pr42248.c compilation at -O1 and above
--- Comment #2 from dave at hiauly1 dot hia dot nrc dot ca 2010-01-19 15:38 --- Subject: Re: FAIL: gcc.c-torture/execute/pr42248.c compilation at -O1 and above > Can you check if the patch that introduced the testcase is responsible for the > failure? Will do. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42805
[Bug c++/42634] ICE with -g -O2 -std=c++0x in copy_fn_p, at cp/decl.c:9973
--- Comment #14 from dodji at gcc dot gnu dot org 2010-01-19 15:39 --- Created an attachment (id=19656) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19656&action=view) candidate fix I am testing this fix. I think one residual issue that was left to fix in the revert patch was that count_non_default_template_args is triggering some class type instantiation on the new std::bind related code, but it shouldn't. This patch tries to avoid that. But I'll sleep on it a bit. I have been bitten by it enough :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42634
[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #2 from burnus at gcc dot gnu dot org 2010-01-19 15:41 --- Confirm. Backtrace: Program received signal SIGSEGV, Segmentation fault. 0x0053e011 in gfc_trans_runtime_error_vararg (error=, where=0x13ea980, msgid=0x13ea3f0 "Index '%ld' of dimension 1 of array 'arr' below lower bound of %ld", ap=0x7fffcf10) at fortran/trans.c:393 393 line = LOCATION_LINE (where->lb->location); (gdb) bt #0 0x0053e011 in gfc_trans_runtime_error_vararg (error=, where=0x13ea980, msgid=0x13ea3f0 "Index '%ld' of dimension 1 of array 'arr' below lower bound of %ld", ap=0x7fffcf10) at fortran/trans.c:393 #1 0x0053e7a8 in gfc_trans_runtime_check (error=1 '\001', once=0 '\000', cond=0x2b94f3f0, pblock=0x7fffd310, where=0x13ea980, msgid=0x2cbb7960 "") at /projects/tob/gcc-trunk-checkout/gcc/fortran/trans.c:466 #2 0x00543f03 in gfc_conv_array_ref (se=0x7fffd310, ar=0x13eaa08, sym=, where=) at fortran/trans-array.c:2576 #3 0x0055f491 in gfc_conv_variable (se=0x7fffd310, expr=0x13ea930) at fortran/trans-expr.c:694 #4 0x0055ed3e in gfc_conv_expr_reference (se=0x7fffd310, expr=) at fortran/trans-expr.c:4520 -- burnus at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 GCC build triplet|i686-pc-mingw32 | GCC host triplet|i686-pc-mingw32 | GCC target triplet|i686-pc-mingw32 | Keywords||ice-on-valid-code Known to fail||4.5.0 Last reconfirmed|-00-00 00:00:00 |2010-01-19 15:41:22 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug debug/42800] [4.5 Regression] VLA DW_AT_upper_bound is no longer emitted
--- Comment #1 from hjl dot tools at gmail dot com 2010-01-19 15:43 --- It is caused by Expand from SSA: http://gcc.gnu.org/ml/gcc-cvs/2009-04/msg01459.html -- hjl dot tools at gmail dot com changed: What|Removed |Added CC||matz at gcc dot gnu dot org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-19 15:43:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42800
[Bug debug/42800] [4.5 Regression] VLA DW_AT_upper_bound is no longer emitted
--- Comment #2 from matz at gcc dot gnu dot org 2010-01-19 15:49 --- What's the brokenness? The missing upper bound in the subrange type? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42800
[Bug debug/42800] [4.5 Regression] VLA DW_AT_upper_bound is no longer emitted
--- Comment #3 from hjl dot tools at gmail dot com 2010-01-19 15:52 --- (In reply to comment #2) > What's the brokenness? The missing upper bound in the subrange type? > It blocks PR 42801. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42800
[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #3 from burnus at gcc dot gnu dot org 2010-01-19 15:56 --- The problem is that e(xpr)->where->lb == NULL. The flow is: gfc_conv_procedure_call -> gfc_conv_derived_to_class -> gfc_conv_expr_reference -> gfc_conv_variable etc. I wonder whether the problem is that the CLASS struct has no line number information associated with - but that is just a blind shot. -- burnus at gcc dot gnu dot org changed: What|Removed |Added CC||janus at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug tree-optimization/41783] r151561 (PRE fix) regresses zeusmp
--- Comment #16 from matz at gcc dot gnu dot org 2010-01-19 16:06 --- Subject: Bug 41783 Author: matz Date: Tue Jan 19 16:05:57 2010 New Revision: 156043 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156043 Log: PR tree-optimization/41783 * tree-data-ref.c (toplevel): Include flags.h. (dump_data_dependence_relation): Also dump the inputs if the result will be unknown. (split_constant_offset_1): Look through some conversions. * tree-predcom.c (determine_roots_comp): Restart a new chain if the offset from last element is too large. (ref_at_iteration): Deal also with MISALIGNED_INDIRECT_REF. (reassociate_to_the_same_stmt): Handle vector registers. * tree-vect-data-refs.c (vect_equal_offsets): Handle unary operations (e.g. conversions). * tree-vect-loop-manip.c (vect_gen_niters_for_prolog_loop): Add wide_prolog_niters argument, emit widening instructions. (vect_do_peeling_for_alignment): Adjust caller, use widened variant of the iteration cound. * Makefile.in (tree-data-ref.o): Add $(FLAGS_H). testsuite/ * gfortran.dg/vect/fast-math-mgrid-resid.f: New. Added: trunk/gcc/testsuite/gfortran.dg/vect/fast-math-mgrid-resid.f Modified: trunk/gcc/ChangeLog trunk/gcc/Makefile.in trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-data-ref.c trunk/gcc/tree-predcom.c trunk/gcc/tree-vect-data-refs.c trunk/gcc/tree-vect-loop-manip.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41783
[Bug target/27855] [4.3/4.4/4.5 regression] reassociation causes the RA to be confused
--- Comment #34 from rguenth at gcc dot gnu dot org 2010-01-19 16:17 --- Re-confirmed. -fsched-pressure -fschedule-insns helps recover some of the performance, ivopts adds its share as well as re-association. Scheduling is probably limited by ivopts producing TMRs and w/o ivopts by plain INDIRECT_REFs. None of which are handled by the alias-export to RTL. -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Last reconfirmed|2007-12-11 05:57:28 |2010-01-19 16:17:28 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27855
[Bug tree-optimization/41879] [4.5 Regression] 172.mgrid regression, vectorizer prevents predictive commoning
--- Comment #7 from rguenth at gcc dot gnu dot org 2010-01-19 16:20 --- Fixed by Author: matz Date: Tue Jan 19 16:05:57 2010 New Revision: 156043 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156043 -- rguenth at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41879
[Bug rtl-optimization/42617] TARGET_MEM_REF and plain INDIRECT_REFs are not handled by the RTL oracle
--- Comment #2 from rguenth at gcc dot gnu dot org 2010-01-19 16:29 --- Mine anyway. -- 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|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-19 16:29:50 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42617
[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #4 from janus at gcc dot gnu dot org 2010-01-19 16:35 --- If one replaces the TBP call by a direct call to the subroutine, like this: call a_proc(arr(i),ierr) then the ICE goes away (of course a_proc must be public for this to work). This means it is not a problem of the CLASS argument, but really connected to the type-bound call. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #5 from janus at gcc dot gnu dot org 2010-01-19 16:39 --- Another observation: If I remove the CLASS argument, give the procedure the NOPASS attribute and call it like this, the ICE also goes away. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug middle-end/42803] [4.4/4.5 Regression] c++ compilation hang
--- Comment #5 from jakub at gcc dot gnu dot org 2010-01-19 16:57 --- Created an attachment (id=19657) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19657&action=view) gcc45-pr42803.patch Alternative patch, which should avoid exponential behavior in all cases (even when there are casts that narrowing_initializer_constant_valid_p skips). POINTER_PLUS_EXPR/PLUS_EXPR/MINUS_EXPR/CONSTRUCTOR seem to be the only ones where initializer_constant_valid_p recurses more than once, so I think it is enough to cache those. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42803
[Bug rtl-optimization/42617] TARGET_MEM_REF and plain INDIRECT_REFs are not handled by the RTL oracle
--- Comment #3 from rguenth at gcc dot gnu dot org 2010-01-19 17:02 --- Created an attachment (id=19658) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19658&action=view) tentative fix Patch for testing, should work for all cases (fingers crossing). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42617
[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #6 from janus at gcc dot gnu dot org 2010-01-19 17:11 --- (In reply to comment #3) > The problem is that e(xpr)->where->lb == NULL. Exactly. What's important is that the expression "e" here is the passed-object argument. Now the problem really is that when we construct this passed-object argument, we do not set a locus for it. But this is easily fixed: Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (revision 156040) +++ gcc/fortran/resolve.c (working copy) @@ -4777,6 +4777,7 @@ extract_compcall_passed_object (gfc_expr* e) po->expr_type = EXPR_VARIABLE; po->symtree = e->symtree; po->ref = gfc_copy_ref (e->ref); + po->where = e->where; } if (gfc_resolve_expr (po) == FAILURE) -- janus at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |janus at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED Last reconfirmed|2010-01-19 15:41:22 |2010-01-19 17:11:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug debug/42800] [4.5 Regression] VLA DW_AT_upper_bound is no longer emitted
--- Comment #4 from jakub at gcc dot gnu dot org 2010-01-19 17:19 --- Yes. This is -O0, so we definitely should ensure that the debug info has the correct upper bound. Look at gimplify_type_sizes which for -O0 clears DECL_IGNORED_P on the temporaries to make sure they are not optimized out. That worked well in 4.4, but probably doesn't work any longer. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42800
[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #7 from janus at gcc dot gnu dot org 2010-01-19 17:24 --- We probably have the same trouble with procedure pointer components, which can also have passed-object arguments. However, when trying to construct an analogous PPC test case, I came across another bug. Here is the test case with a PPC instead of a TBP: MODULE ModA IMPLICIT NONE TYPE, PUBLIC :: A PROCEDURE(a_proc),pointer :: Proc END TYPE A CONTAINS SUBROUTINE a_proc(this, stat) CLASS(A), INTENT(INOUT) :: this INTEGER, INTENT(OUT) :: stat WRITE (*, *) 'a_proc' stat = 0 END SUBROUTINE a_proc END MODULE ModA PROGRAM ProgA USE ModA IMPLICIT NONE INTEGER :: ierr INTEGER :: i TYPE(A), ALLOCATABLE :: arr(:) ALLOCATE(arr(2)) DO i = 1, 2 arr(i)%proc => a_proc CALL arr(i)%Proc(ierr) END DO END PROGRAM ProgA Compiling this gives: CALL arr(i)%Proc(ierr) 1 Error: Passed-object at (1) must be scalar Now, the passed-object is obviously scalar (it's an element of an array), so this surely is a bug. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug bootstrap/42786] Athlon SSE3 and Fx processors not supported by configure
--- Comment #3 from ubizjak at gmail dot com 2010-01-19 17:30 --- (In reply to comment #2) > Can't edit original post. Email client added line breaks where they shouldn't > be. Please use patch attached to issue, and not one orginally submitted in > description. Please post the patch (with appropriate ChangeLog) to gcc-patc...@gcc.gnu.org mailing list, as described in great detail in [1]. The patch is OK as far as x86 is concerned, but you will need an approval from build maintainer for these changes. Please also note, that it is a bit late in the release process for these kind of changes, so unless you convince the maintainer of a great benefit from your patch, it will have to wait for 4.6 release. [1] http://gcc.gnu.org/contribute.html -- ubizjak at gmail dot com changed: What|Removed |Added Severity|normal |enhancement Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2010-01-19 17:30:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42786
[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #8 from janus at gcc dot gnu dot org 2010-01-19 17:46 --- Here is the fix for PPCs, curing both the "must be scalar" error from the last comment as well as the missing-locus ICE (which, as expected, did appear also for PPCs after the other thing was fixed): Index: gcc/fortran/resolve.c === --- gcc/fortran/resolve.c (revision 156040) +++ gcc/fortran/resolve.c (working copy) @@ -4831,11 +4832,12 @@ extract_ppc_passed_object (gfc_expr *e) po->expr_type = EXPR_VARIABLE; po->symtree = e->symtree; po->ref = gfc_copy_ref (e->ref); + po->where = e->where; /* Remove PPC reference. */ ref = &po->ref; while ((*ref)->next) -(*ref) = (*ref)->next; +ref = &(*ref)->next; gfc_free_ref_list (*ref); *ref = NULL; -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug tree-optimization/42806] New: "-fcompare-debug failure (length)" at -O1 in recent builds
Command line: g++ -O1 -fcompare-debug -c testcase.cpp Tested revisions: r156038 - crash r155966 - crash r155945 - crash (x86) r155938 - crash r155902 - OK r155844 - OK (x86) r155833 - OK r155363 - OK r153685 - OK Behaviour is the same for unreduced testcase (at -O1) Output: $ /mnt/svn/gcc-trunk/binary-156038-lto/bin/g++ -O1 -fcompare-debug -c testcase.cpp g++: testcase.cpp: -fcompare-debug failure (length) -- Summary: "-fcompare-debug failure (length)" at -O1 in recent builds Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: zsojka at seznam dot cz GCC host triplet: x86(_64)-pc-linux-gnu GCC target triplet: x86(_64)-pc-linux-gnu http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42806
[Bug tree-optimization/42806] "-fcompare-debug failure (length)" at -O1 in recent builds
--- Comment #1 from zsojka at seznam dot cz 2010-01-19 17:53 --- Created an attachment (id=19659) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19659&action=view) reduced testcase Command line: g++ -O1 -fcompare-debug -c pr42806.cpp -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42806
[Bug c/42807] New: constant folding at compile time limited to integers.
Gnu compiler (latest microchip version with full optimizations) makes the following error. unsigned long value; value=2501*1600; the result should be 0x3D0F40 instead it is 0x0F40. The problem is this. The compiler computed the constant 2501*1600 as an integer, even though it had sufficient information to know that value is a long, and thus should have automatically promoted the constants in the multiplication. It assigned the integer value to the long properly, but since the compiler did the multiply in integer form first, it only got the last half. postpending 'l' to each constant fixes it, but that should not be necessary, as the compiler has all the information it needs to properly do the multiply. -- Summary: constant folding at compile time limited to integers. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: tossit1 at mail15 dot com http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42807
[Bug c/42807] constant folding at compile time limited to integers.
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-01-19 18:13 --- This is correct for C/C++. 2501*1600 is an integer. If you want an unsigned long, use ((unsigned long)2501)*1600 or 2501ul*1600ul. -- 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=42807
[Bug fortran/42783] [4.5 Regression] Bogus Array bounds violation with optional array argument
--- Comment #3 from pault at gcc dot gnu dot org 2010-01-19 19:47 --- Subject: Bug 42783 Author: pault Date: Tue Jan 19 19:46:59 2010 New Revision: 156046 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156046 Log: 2010-01-19 Paul Thomas PR fortran/42783 * trans-decl.c (add_argument_checking): Do not use the backend decl directly to test for the presence of an optional dummy argument. Use gfc_conv_expr_present, remembering to set the symbol referenced. PR fortran/42772 * trans-decl.c (gfc_generate_function_code): Small white space changes. If 'recurcheckvar' is NULL do not try to reset it. 2010-01-19 Paul Thomas PR fortran/42783 * gfortran.dg/bounds_check_15.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/bounds_check_15.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42783
[Bug fortran/42772] [4.5 Regression] ICE at fold-const.c:10033
--- Comment #7 from pault at gcc dot gnu dot org 2010-01-19 19:47 --- Subject: Bug 42772 Author: pault Date: Tue Jan 19 19:46:59 2010 New Revision: 156046 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156046 Log: 2010-01-19 Paul Thomas PR fortran/42783 * trans-decl.c (add_argument_checking): Do not use the backend decl directly to test for the presence of an optional dummy argument. Use gfc_conv_expr_present, remembering to set the symbol referenced. PR fortran/42772 * trans-decl.c (gfc_generate_function_code): Small white space changes. If 'recurcheckvar' is NULL do not try to reset it. 2010-01-19 Paul Thomas PR fortran/42783 * gfortran.dg/bounds_check_15.f90 : New test. Added: trunk/gcc/testsuite/gfortran.dg/bounds_check_15.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-decl.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42772
[Bug fortran/42783] [4.5 Regression] Bogus Array bounds violation with optional array argument
--- Comment #4 from pault at gcc dot gnu dot org 2010-01-19 19:48 --- Fixed on trunk. Thanks for the report. Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42783
[Bug fortran/42772] [4.5 Regression] ICE at fold-const.c:10033
--- Comment #8 from pault at gcc dot gnu dot org 2010-01-19 19:49 --- I believe that the commit in comment #7 fixes it. If not, please get in touch. Thanks for the report Paul -- pault at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42772
[Bug middle-end/42803] [4.4/4.5 Regression] c++ compilation hang
--- Comment #6 from l dot jirkovsky at gmail dot com 2010-01-19 19:56 --- I've recompiled gcc 4.5 snapshot with the patch included. The file bilateral2.ii compiles perfectly. Thank you, you're doing a great job. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42803
[Bug c++/42336] [4.5 Regression] ICE with pointer-to-member-function argument in template function with -fipa-sra
--- Comment #21 from jason at gcc dot gnu dot org 2010-01-19 20:10 --- 42797 doesn't seem like a duplicate; it's another issue with count_non_default_template_args, but the issue there is that we are triggering instantiation when we shouldn't. But I'm not sure yet why -fno-ipa-sra makes a difference for that test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42336
[Bug middle-end/42805] FAIL: gcc.c-torture/execute/pr42248.c compilation at -O1 and above
--- Comment #3 from dave at hiauly1 dot hia dot nrc dot ca 2010-01-19 20:51 --- Subject: Re: FAIL: gcc.c-torture/execute/pr42248.c compilation at -O1 and above > Can you check if the patch that introduced the testcase is responsible for the > failure? It's not. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42805
[Bug middle-end/42805] FAIL: gcc.c-torture/execute/pr42248.c compilation at -O1 and above
--- Comment #4 from dave at hiauly1 dot hia dot nrc dot ca 2010-01-19 21:00 --- Subject: Re: FAIL: gcc.c-torture/execute/pr42248.c compilation at -O1 and above > > Can you check if the patch that introduced the testcase is responsible for > > the > > failure? > > It's not. Testcase doesn't fail with Debian 4.3.4-6 and Debian 4.4.2-8. Dave -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42805
[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #9 from janus at gcc dot gnu dot org 2010-01-19 22:21 --- Subject: Bug 42804 Author: janus Date: Tue Jan 19 22:21:35 2010 New Revision: 156049 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=156049 Log: gcc/fortran/ 2010-01-19 Janus Weil PR fortran/42804 * resolve.c (extract_compcall_passed_object): Set locus for passed-object argument. (extract_ppc_passed_object): Set locus and correctly remove PPC reference. gcc/testsuite/ 2010-01-19 Janus Weil PR fortran/42804 * gfortran.dg/proc_ptr_comp_pass_6.f90: New test. * gfortran.dg/typebound_call_12.f03: New test. Added: trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_pass_6.f90 trunk/gcc/testsuite/gfortran.dg/typebound_call_12.f03 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug fortran/42804] ICE with -fcheck=bounds and type bound procedure call on array element
--- Comment #10 from janus at gcc dot gnu dot org 2010-01-19 22:23 --- Fixed with r156049. Closing. Thanks for the report! -- janus at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42804
[Bug fortran/42809] New: Too much noise with -Wconversion
There is a lot of noise generated with -Wconversion: program gfcbug100 implicit none integer, parameter :: sp = kind (1.0) integer, parameter :: dp = kind (1.d0) real(sp) :: s real(dp) :: d complex(dp) :: z s = 0 ! Warn if you are very picky d = s ! No reason for a warning z = (0, 1)! Many warnings for this one! end program gfcbug100 Which gives: gfcbug100.f90:11.8: z = (0, 1)! Many warnings for this one! 1 Warning: Conversion from INTEGER(4) to REAL(4) at (1) gfcbug100.f90:11.11: z = (0, 1)! Many warnings for this one! 1 Warning: Conversion from INTEGER(4) to REAL(4) at (1) gfcbug100.f90:9.6: s = 0 ! Warn if you are very picky 1 Warning: Conversion from INTEGER(4) to REAL(4) at (1) gfcbug100.f90:10.6: d = s ! No reason for a warning 1 Warning: Conversion from REAL(4) to REAL(8) at (1) gfcbug100.f90:11.6: z = (0, 1)! Many warnings for this one! 1 Warning: Conversion from COMPLEX(4) to COMPLEX(8) at (1) It would be nice if the promotion kind=4 to kind=8 would never produce a warning in cases like the above as it is always exact. Also, promoting integers to reals is often possible without any loss of accuracy, this is certainly the case for 0 and 1 ;-) The complex literal is particularly funny, generating 3 warnings. This is at least one too much. (0,1) gets promoted by default to (0.0,1.0) as required by the standard, and the complex conversion is exact. Any attempt at reducing the above noise is greatly appreciated. -- Summary: Too much noise with -Wconversion Product: gcc Version: 4.5.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: anlauf at gmx dot de http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42809
[Bug fortran/42809] Too much noise with -Wconversion
--- Comment #1 from pinskia at gcc dot gnu dot org 2010-01-19 22:42 --- Well constants don't really need to be warned about if it does fit. But really an generic integer(4) to real(4) should be warned about really as not all integer(4) fit into real(4). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42809
[Bug c++/42810] New: Enumeration with sequential values has its for-loop exit condition optimized out.
An enumeration with sequentially-assigned values is used as an index of a for
loop. The loop operates properly at optimization levels -O0 and -O1. At level
-O2 the optimizer "optimizes out" the test for the exit condition and the loop
never exits.
I'll be attaching the *.i file, but below is the test source file which shows
the situation. At -O2, the loop itself never exits and a separate counter
which is part of the test triggers a break itself--after printing that the test
has failed.
/*
Sample program to demonstrate comparison failure involving sequential
enumeration when optimized. To reproduce the failure:
g++ -O2 test.cpp && ./a.out
Any one of the following changes correct the problem:
- Change optimization (omit or use -O0 or -O1).
- Set ENUM_VALUE_FIRST to 0.
- Delete one of the enum values between first and last (one less
value).
- Insert an addition enum value between first and last (one more
value).
agarland at fluke dot com
*/
// Compile at -O1 or uncomment any one of the following to "fix" the problem.
//#define FIX1 // Omit an enum value.
//#define FIX2 // Add an extra enum value.
//#define FIX3 // Start first value at zero rather than 1.
#include
enum ENUM_VALUE
{
#ifdef FIX3
ENUM_VALUE_FIRST = 0,
#else
ENUM_VALUE_FIRST = 1,
#endif
ENUM_VALUE_A,
#ifndef FIX1
ENUM_VALUE_B,
#endif
ENUM_VALUE_C,
ENUM_VALUE_D,
ENUM_VALUE_E,
#ifdef FIX2
ENUM_VALUE_F,
#endif
ENUM_VALUE_LAST
};
main()
{
printf("Compiled on %s %s\n", __DATE__, __TIME__);
unsigned int count = 0;
for (
ENUM_VALUE id = ENUM_VALUE_FIRST;
id <= ENUM_VALUE_LAST;
id = static_cast(id+1)
)
{
printf("id=%d\n", id);
if (100 == count++)
{
// Should never get here.
printf("ENUMERATION COMPARISON FAILED!\n");
break;
}
}
}
--
Summary: Enumeration with sequential values has its for-loop exit
condition optimized out.
Product: gcc
Version: 4.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: tony3 at GarlandConsulting dot us
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
[Bug c++/42810] Enumeration with sequential values has its for-loop exit condition optimized out.
--- Comment #1 from tony3 at GarlandConsulting dot us 2010-01-19 22:53 --- Created an attachment (id=19661) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19661&action=view) Preprocessed version of the test.cpp file. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
[Bug c++/42810] Enumeration with sequential values has its for-loop exit condition optimized out.
--- Comment #2 from tony3 at GarlandConsulting dot us 2010-01-19 22:53 --- Created an attachment (id=19662) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19662&action=view) Compiler output ready to feed to assembler--the problem can be seen here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
[Bug c++/42810] Enumeration with sequential values has its for-loop exit condition optimized out.
--- Comment #3 from tony3 at GarlandConsulting dot us 2010-01-19 22:54 --- Here is the compiler information: g++ -v Using built-in specs. Target: i586-suse-linux Configured with: ../configure --prefix=/usr --with-local-prefix=/usr/local --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib --libexecdir=/usr/lib --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.3 --enable-ssp --disable-libssp --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --with-slibdir=/lib --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --program-suffix=-4.3 --enable-version-specific-runtime-libs --enable-linux-futex --without-system-libunwind --with-cpu=generic --build=i586-suse-linux Thread model: posix gcc version 4.3.1 20080507 (prerelease) [gcc-4_3-branch revision 135036] (SUSE Linux) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
[Bug c++/42810] Enumeration with sequential values has its for-loop exit condition optimized out.
--- Comment #4 from tony3 at GarlandConsulting dot us 2010-01-19 22:56 --- Created an attachment (id=19663) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19663&action=view) ARM gcc 4.4.1 output at assembler input level. This shows the same problem in gcc for the ARM. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
[Bug c++/42810] Enumeration with sequential values has its for-loop exit condition optimized out.
--- Comment #5 from tony3 at GarlandConsulting dot us 2010-01-19 22:58 --- Created an attachment (id=19664) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19664&action=view) Assembler input which works correctly compiled at -O1 In this sample, the exit condition is properly tested as can be seen in the assembly listing. The difference between this file and test.s shows how the exit condition gets optimized out. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
[Bug fortran/42809] Too much noise with -Wconversion
--- Comment #2 from anlauf at gmx dot de 2010-01-19 22:59 --- (In reply to comment #1) > Well constants don't really need to be warned about if it does fit. But > really > an generic integer(4) to real(4) should be warned about really as not all > integer(4) fit into real(4). > That's right. For the conversion of a non-trivial integer(4) expression to real(4) warnings are desired. But for a known integer(4), one could use the knowledge of the Fortran model of reals a check whether the modulus of the integer is smaller than 2/epsilon(0._4). (I hope that I got the factor of two correctly). -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42809
[Bug c++/42810] Enumeration with sequential values has its for-loop exit condition optimized out.
--- Comment #6 from tony3 at GarlandConsulting dot us 2010-01-19 23:05 --- There is a related bug here: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36170 But unlike that bug which uses an out-of-range enum value, this case does not. We are testing 'value <= max_valid_enum_value'. So I've entered this as a different bug for reconsideration about how the compiler is handling valid enumeration values in -O2. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
[Bug java/42811] New: [4.5 regression] java.lang.ExceptionInInitializerError in ecj1
configuration
./configure --prefix=/usr --disable-win32-registry --enable-threads=posix
--enable-languages=c,c++,java --with-win32-nlsapi=unicode --enable-tls
--disable-bootstrap --enable-shared --enable-interpreter
--disable-sjlj-exceptions --enable-load-library
testcase
public class java
{
public static void main(String arg[])
{
System.out.println("Hello World!");
}
}
debug session
Reading symbols from /usr/libexec/gcc/i686-pc-cygwin/4.5.0/ecj1.exe...done.
(gdb) set args java.java -g1 -fbootclasspath=./:/usr/share/java/libgcj-4.5.0.j
ar -g1 -fsource=1.5 -ftarget=1.5 -fzip-dependency java.zip -fzip-target java.j
ar
(gdb) directory /tmp/gcc/t/t/t/t
Warning: /tmp/gcc/t/t/t/t: No such file or directory.
Source directories searched: /tmp/gcc/t/t/t/t:$cdir:$cwd
(gdb) start
Temporary breakpoint 1 at 0x40112e: file /cygdrive/d/Temp/cache/ccnRjjtS.i,
line
11.
Starting program: /usr/libexec/gcc/i686-pc-cygwin/4.5.0/ecj1.exe java.java -g1
-
fbootclasspath=./:/usr/share/java/libgcj-4.5.0.jar -g1 -fsource=1.5
-ftarget=1.5
-fzip-dependency java.zip -fzip-target java.jar
[New Thread 2040.0x1020]
warning: section .gnu_debuglink not found in /usr/bin/cygwin1.dbg
[New Thread 2040.0x1338]
Temporary breakpoint 1, main (argc=,
argv=) at /cygdrive/d/Temp/cache/ccnRjjtS.i:11
11 /cygdrive/d/Temp/cache/ccnRjjtS.i: No such file or directory.
in /cygdrive/d/Temp/cache/ccnRjjtS.i
(gdb) disp /i $eip
1: x/i $eip
=> 0x40112e : mov0xc(%ebp),%eax
(gdb) b Calendar.java:500
Breakpoint 2 at 0x6c1b0ed6: file
../../../.././libjava/classpath/java/util/Calen
dar.java, line 500.
(gdb) c
Continuing.
[New Thread 2040.0x119c]
[New Thread 2040.0x1704]
Breakpoint 2, java.util.Calendar.()void ()
at ../../../.././libjava/classpath/java/util/Calendar.java:500
500 properties = new Properties();
1: x/i $eip
=> 0x6c1b0ed6 ()void+6>:
movl $0x6c5d0fe0,(%esp)
(gdb) n
503
properties.load(Calendar.class.getResourceAsStream("weeks.proper
ties"));
1: x/i $eip
=> 0x6c1b0eec ()void+28>: mov0x6c5d5350,%eax
(gdb) n
500 properties = new Properties();
1: x/i $eip
=> 0x6c1b0ef1 ()void+33>: mov%ebx,0x6cabc75c
(gdb) n
503
properties.load(Calendar.class.getResourceAsStream("weeks.proper
ties"));
1: x/i $eip
=> 0x6c1b0ef7 ()void+39>:
movl $0x6c5c84e0,(%esp)
(gdb) n
Exception in thread "main" java.lang.ExceptionInInitializerError
at java.lang.Class.initializeClass(Unknown Source)
at java.util.Calendar.getInstance(Unknown Source)
at java.util.zip.ZipEntry.getDOSTime(Unknown Source)
at java.util.zip.ZipOutputStream.putNextEntry(Unknown Source)
at
org.eclipse.jdt.internal.compiler.batch.GCCMain.getZipOutput(GCCMain.java:
110)
at
org.eclipse.jdt.internal.compiler.batch.GCCMain.configure(GCCMain.java:459
)
at org.eclipse.jdt.internal.compiler.batch.Main.compile(Main.java:1628)
at org.eclipse.jdt.internal.compiler.batch.GCCMain.compile(GCCMain.java:481)
at org.eclipse.jdt.internal.compiler.batch.GCCMain.main(GCCMain.java:498)
Caused by: java.lang.NullPointerException
at java.io.InputStreamReader.read(Unknown Source)
at java.io.BufferedReader.fill(Unknown Source)
at java.io.BufferedReader.readLine(Unknown Source)
at java.util.Properties.load(Unknown Source)
at java.util.Properties.load(Unknown Source)
at java.util.Calendar.(Unknown Source)
at java.lang.Class.initializeClass(Unknown Source)
...8 more
Program exited with code 01.
(gdb)
it seems that libgcj-bc is disabled except linux (libjava/configure.host)
but SUPPRESS_LIBGCJ_BC_TRUE is enabled because it is default. and problematic
switches "-fzip-dependency java.zip -fzip-target java.jar" try to load
weeks.properties resource. then it invokes url classloader and find resource in
libgcj-.jar so results exception.
i tried to compile with --disable-libgcj-bc, but it has undefined symbol with
namespace org.xml (showing that there is no choice but to use libgcj-bc)
--
Summary: [4.5 regression] java.lang.ExceptionInInitializerError
in ecj1
Product: gcc
Version: 4.5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: java
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: jojelino at gmail dot com
GCC build triplet: i686-pc-cygwin
GCC host triplet: i686-pc-cygwin
GCC target triplet: i686-pc-cygwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811
[Bug c++/36625] bogus error on __attribute__((aligned(N))) in template code
--- Comment #7 from jason at gcc dot gnu dot org 2010-01-19 23:30 --- The problem here is that the attribute parsing code sees that the argument is an identifier and treats it as a plain name rather than an expression; this is to support attributes like mode which take an identifier as an argument. I guess we should handle this case specially. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36625
[Bug c++/42810] Enumeration with sequential values has its for-loop exit condition optimized out.
--- Comment #7 from jakub at gcc dot gnu dot org 2010-01-19 23:56 --- This testcase also uses out of range enum value, so has undefined behavior as well. For ENUM_VALUE_LAST which is a power of 2 minus 1 the for loop condition still lets the body to be executed, then id = static_cast(id+1) i.e. id = static_cast(ENUM_VALUE_LAST+1) is the out of range value. The compiler can assume that no enum value is larger than ENUM_VALUE_LAST if it is a power of 2 minus 1 (i.e. the largest value of the underlying type). -- jakub at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
[Bug c++/42810] Enumeration with sequential values has its for-loop exit condition optimized out.
--- Comment #8 from tony3 at GarlandConsulting dot us 2010-01-20 00:18 --- I see what you mean. I was looking at the "wrong side" of the "<=" and not thinking about the reality that it would have to exceed the last valid value. Pretty obvious once you point it out. So now my question is why doesn't the compiler issue any warning about this? The result is a silent "forever loop" and the program hangs. Surely this is not what the programmer intended? I can appreciate that the compiler can make certain assumptions, but what I'm really trying to say here is that to truly be helpful in programming a compiler should either accept the code as valid (and try to do what is intended) or issue a warning or error saying it won't or might not. This is compounded by the fact that the code runs fine at lesser optimization levels--and compiles silently at all levels. So it is worse than silent, it is misleading in that it allows this poor programming practice during development only to turn it into a permanent hang in optimized production builds. :-) -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42810
[Bug libstdc++/21769] per-file control over PCH inclusion
--- Comment #3 from paolo dot carlini at oracle dot com 2010-01-20 01:36 --- For now at least I'll simply add what Janis suggested and then use it to clean-up the long standing XPASS of c99_classification_macros_c.cc (few people complained about 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|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21769
[Bug java/42811] [4.5 regression] java.lang.ExceptionInInitializerError in ecj1
--- Comment #1 from jojelino at gmail dot com 2010-01-20 05:02 --- linking executables with -Wl,--whole-archive libgcj-noncore.la libgcj.la -Wl,--no-whole-archive solves this problem. excepts that it creates fatty import symbol table approx. (28 megabyte). is there any workaround instead of this naive method? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42811
[Bug c++/36625] bogus error on __attribute__((aligned(N))) in template code
--- Comment #8 from jason at gcc dot gnu dot org 2010-01-20 05:51 --- Created an attachment (id=19665) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=19665&action=view) patch -- jason at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |jason at gcc dot gnu dot org |dot org | Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36625
[Bug bootstrap/42812] New: --enable-build-with-cxx bootstrap fails on fortran/resolve.c:gfc_resolve
I see this error during bootstrap: /user/inria/fsf/bld-gcc-cxx8/./prev-gcc/g++ -B/user/inria/fsf/bld-gcc-cxx8/./prev-gcc/ -B/user/inria/cxx/i686-pc-linux-gnu/bin/ -nostdinc++ -I/user/inria/fsf/bld-gcc-cxx8/prev-i686-pc-linux-gnu/libstdc++-v3/include/i686-pc-linux-gnu -I/user/inria/fsf/bld-gcc-cxx8/prev-i686-pc-linux-gnu/libstdc++-v3/include -I/user/inria/fsf/gcc/libstdc++-v3/libsupc++ -L/user/inria/fsf/bld-gcc-cxx8/prev-i686-pc-linux-gnu/libstdc++-v3/src/.libs -c -g -O2 -fomit-frame-pointer -gtoggle -DIN_GCC -W -Wall -Wwrite-strings -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -fno-common -DHAVE_CONFIG_H -I. -Ifortran -I../../gcc/gcc -I../../gcc/gcc/fortran -I../../gcc/gcc/../include -I../../gcc/gcc/../libcpp/include -I../../gcc/gcc/../libdecnumber -I../../gcc/gcc/../libdecnumber/bid -I../libdecnumber -DCLOOG_PPL_BACKEND -I/usr/include/libelf ../../gcc/gcc/fortran/resolve.c -o fortran/resolve.o cc1plus: warnings being treated as errors ../../gcc/gcc/fortran/resolve.c: In function void gfc_resolve(gfc_namespace*): ../../gcc/gcc/fortran/resolve.c:12359:19: error: large integer implicitly truncated to unsigned type The value -1 is assigned to the unsigned bitfield "resolve" in a struct gfc_namespace. -- Summary: --enable-build-with-cxx bootstrap fails on fortran/resolve.c:gfc_resolve Product: gcc Version: 4.5.0 Status: UNCONFIRMED Keywords: build Severity: normal Priority: P3 Component: bootstrap AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: amylaar at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42812
