[Bug bootstrap/56644] --disable-nls requires symbols from libintl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56644 Kai Tietz ktietz at gcc dot gnu.org changed: What|Removed |Added CC||ktietz at gcc dot gnu.org --- Comment #3 from Kai Tietz ktietz at gcc dot gnu.org 2013-03-20 06:59:33 UTC --- This looks like a duplicate of PR/54659. Which snapshort-date you are using of 4.8 gcc?
[Bug c++/56658] New: Silent conversion between 'char' and 'int' even though there are 'signed char' and 'unsigned char' alternatives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56658
Bug #: 56658
Summary: Silent conversion between 'char' and 'int' even though
there are 'signed char' and 'unsigned char'
alternatives
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: greenscape...@gmail.com
Consider code snippet:
#include stdio.h
typedef signed char int8_t;
typedef unsigned char uint8_t;
void foo(int8_t x)
{
printf(Cartman);
}
void foo(uint8_t x)
{
printf(Stan);
}
void foo(int x)
{
printf(Kenny);
}
int main(int argc, char ** argv)
{
charperson = '?';
printf(Oh my God they killed );
foo(person);
printf(! You bastards!\n);
}
It does compile and generate 0 warnings. Yes, we all know how 'wise' was former
creators of the standard when it came to char. But in this case, if compiler
can't figure out 'char' is 'signed char' there is still an ambiguity. And
silent conversion of 'char' to 'int' is just wrong. As far as I can judge,
clang guys just pathetically copy-pasted GCC's behavior. What I ask for is at
least warning message there.
[Bug fortran/56659] New: Segfault due to missing libcpp error handler for gfortran -cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659 Bug #: 56659 Summary: Segfault due to missing libcpp error handler for gfortran -cpp Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: kapi...@rz.rwth-aachen.de Reported by Paul Kapinos at fortran@gcc, http://thread.gmane.org/gmane.comp.gcc.fortran/40495 http://gcc.gnu.org/ml/fortran/2013-03/msg00083.html The problem is that libcpp calls an error handler, which is not set in f951. Namely, pfile-cb.error == NULL but should be point to a function; it has the the prototype: bool (*)(cpp_reader *, int, int, source_location, unsigned int, const char *, va_list *) C/C++ use: in c-opts.c: cb-error = c_cpp_error; the function is declared in c-family/c-common.c. Test case: * mkdir -p foo/bar * chmod 000 foo * gfortran -cpp some_file.F90
[Bug fortran/56660] New: Fails to read NAMELIST with certain form array syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56660
Bug #: 56660
Summary: Fails to read NAMELIST with certain form array syntax
Classification: Unclassified
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Keywords: wrong-code
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bur...@gcc.gnu.org
CC: jvdeli...@gcc.gnu.org, t...@tilo-schwarz.de
Depends on: 51825
Another namelist failure, found by Jerry.
See also PR 49791, PR 51825, PR 55117, PR 52512.
When reading the file, gfortran fails with:
At line 17 of file pr51825-3.f90 (unit = 99, file = 'nml.dat')
Fortran runtime error: Cannot match namelist object name 'bb'
Using NAG, one gets the output:
NAML1 TRACER = XX F XX F XX F/
NAML1 TRACER = aa T bb T XX F/
(There are plenty ways of outputting this data - as long as the data is there.)
type ptracer
character(len = 2) :: sname
logical :: lini
end type ptracer
type(ptracer) , dimension(3) :: tracer
namelist/naml1/ tracer
tracer(:) = ptracer('XXX', .false.)
write (*, nml=naml1)
open (99, file='nml.dat', status=replace)
write(99,*) naml1
write(99,*)tracer(:) = 'aa' , .true.
write(99,*)tracer(2) = 'bb' , .true.
write(99,*) /
rewind(99)
read (99, nml=naml1)
write (*, nml=naml1)
close (99, status=delete)
end
[Bug libgcc/56656] Suffix or operands invalid for 'movq'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56656 --- Comment #5 from Uros Bizjak ubizjak at gmail dot com 2013-03-20 07:45:22 UTC --- This is probably fallout from move pattern unification. Can you please attach preprocessed source and assembly? Please use -dp when compiling, it will generate corresponding insn pattern names in the assembly.
[Bug target/53325] arm-rtems switch default target to EABI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53325 --- Comment #7 from Sebastian Huber sebastian.hu...@embedded-brains.de 2013-03-20 08:09:50 UTC --- It is also fixed in the GCC 4.6 and 4.7 branches.
[Bug libfortran/48618] Negative unit number in OPEN(...) is sometimes allowed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48618 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-20 08:13:59 UTC --- Author: burnus Date: Wed Mar 20 07:45:49 2013 New Revision: 196805 URL: http://gcc.gnu.org/viewcvs?rev=196805root=gccview=rev Log: 2013-03-20 Tilo Schwarz t...@tilo-schwarz.de PR libfortran/48618 * io/open.c (st_open): Raise error for unit number 0 only if unit number does not exist already. 2013-03-20 Tilo Schwarz t...@tilo-schwarz.de PR libfortran/48618 * gfortran.dg/open_negative_unit_1.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/open_negative_unit_1.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/open.c
[Bug libfortran/48618] Negative unit number in OPEN(...) is sometimes allowed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48618 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-20 08:14:25 UTC --- FIXED on the 4.9 trunk. Thanks for the report Janne. Thanks for the patch Tilo.
[Bug libgcc/56656] Suffix or operands invalid for 'movq'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56656 --- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-03-20 08:14:55 UTC --- Created attachment 29696 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29696 preprocessed file
[Bug fortran/51825] Fortran runtime error: Cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51825 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-20 08:15:17 UTC --- Author: burnus Date: Wed Mar 20 07:56:02 2013 New Revision: 196806 URL: http://gcc.gnu.org/viewcvs?rev=196806root=gccview=rev Log: 2013-03-20 Tilo Schwarz t...@tilo-schwarz.de PR libfortran/51825 * io/list_read.c (nml_read_obj): Don't end the component loop on a nested derived type, but continue with the next loop iteration. (nml_get_obj_data): Don't move the first_nl pointer further in the list if a qualifier was found. 2013-03-20 Tilo Schwarz t...@tilo-schwarz.de PR libfortran/51825 * gcc/testsuite/gfortran.dg/namelist_77.f90: New. * gcc/testsuite/gfortran.dg/namelist_78.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/namelist_77.f90 trunk/gcc/testsuite/gfortran.dg/namelist_78.f90 Modified: trunk/gcc/testsuite/ChangeLog trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c
[Bug libgcc/56656] Suffix or operands invalid for 'movq'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56656 --- Comment #7 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-03-20 08:15:32 UTC --- Created attachment 29697 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29697 assembly with -dp
[Bug libgcc/56656] Suffix or operands invalid for 'movq'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56656 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-20 Ever Confirmed|0 |1 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2013-03-20 08:19:32 UTC --- I see the same failure on x86_64-apple-darwin10 for 4.9. This is due to revision 196784 (r196783 bootstraps). As asked by Uros I have attached the preprocessed source and generated assembly obtained with /opt/gcc/p_build/./gcc/xgcc -B/opt/gcc/p_build/./gcc/ -g -O2 -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fno-common -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -fno-common -I. -I. -I../.././gcc -I../../../p_work/libgcc -I../../../p_work/libgcc/. -I../../../p_work/gcc -I../../../p_work/include -DHAVE_CC_TLS -DUSE_EMUTLS -o extenddftf2_s.o -MT extenddftf2_s.o -MD -MP -MF extenddftf2_s.dep -DSHARED -c -dp ../../../p_work/libgcc/soft-fp/extenddftf2.c -save-temps The bootstrap is done in a directory different from the source one.
[Bug c++/56636] strange interaction of dynamic_cast and unique_ptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56636 Daniel Krügler daniel.kruegler at googlemail dot com changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #2 from Daniel Krügler daniel.kruegler at googlemail dot com 2013-03-20 08:38:22 UTC --- It also works for gcc 4.8.0 trunk using mingw 64.
[Bug tree-optimization/56635] [4.8/4.9 regression] internal compiler error: in find_lattice_value, at tree-complex.c:15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56635 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-20 08:42:52 UTC --- Author: jakub Date: Wed Mar 20 08:40:08 2013 New Revision: 196808 URL: http://gcc.gnu.org/viewcvs?rev=196808root=gccview=rev Log: PR tree-optimization/56635 * tree-ssa-phiopt.c (cond_if_else_store_replacement_1): Give up if lhs of then_assign and else_assign don't have compatible types. * g++.dg/torture/pr56635.C: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/g++.dg/torture/pr56635.C Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-ssa-phiopt.c
[Bug middle-end/56657] [GCC 4.6/4.7] ICE - error: unrecognizable insn.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56657 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #4 from Mikael Pettersson mikpe at it dot uu.se 2013-03-20 08:43:05 UTC --- The non-preprocessed test case doesn't ICE for me with gcc-4.7.2 targeting x86_64-w64-mingw32 (so not the same mingw as the reporter is using), with either -m64 or -m32. The preprocessed test case does ICE that compiler with -m32, but not with -m64.
[Bug tree-optimization/56635] [4.8/4.9 regression] internal compiler error: in find_lattice_value, at tree-complex.c:15
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56635 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-20 08:43:18 UTC --- Fixed.
[Bug libgcc/56656] Suffix or operands invalid for 'movq'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56656 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-20 08:57:32 UTC --- So I guess an important question is if the svn-fetched 4.8.0 wasn't actually svn-fetched trunk instead, Uros' changes have been committed only for 4.9 and not on the 4.8 branch.
[Bug tree-optimization/56661] New: [4.8 regression] Incorrect code with -O1 -ftree-pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56661
Bug #: 56661
Summary: [4.8 regression] Incorrect code with -O1 -ftree-pre
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: manisan...@gmail.com
Using gcc version 4.8.0 20130316 (Red Hat 4.8.0-0.17)
- main.c -
typedef long unsigned int size_t;
extern int printf (const char *__restrict __format, ...);
extern void *malloc (size_t __size) __attribute__ ((__nothrow__ , __leaf__))
__attribute__ ((__malloc__));
void setb(int* b);
void foo(int x){
if(x == 0){
int* b = malloc(3*sizeof(int));
while(b[0]);
}else if(x == 1){
int i, j;
int* b = malloc(3*sizeof(int));
for(i = 0; i 2; i++){
setb(b);
for(j = 0; j 3; ++j){
printf(%d , b[j]);
}
printf(\nb[0] = %d\n, b[0]);
}
}
}
extern int g_x;
int main(){
foo(g_x);
return 0;
}
- stuff.c -
void setb(int* b){
b[0] = b[1] = b[2] = 1;
}
int g_x = 1;
---
$ gcc -O1 -ftree-pre -o test main.c stuff.c
$ ./test
1 1 1
b[0] = 0
1 1 1
b[0] = 0
Works with gcc version 4.7.2 20121109 (Red Hat 4.7.2-8)
[Bug middle-end/56657] [GCC 4.6/4.7] ICE - error: unrecognizable insn.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56657 --- Comment #5 from Mikael Pettersson mikpe at it dot uu.se 2013-03-20 09:07:28 UTC --- Created attachment 29698 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29698 reduced test case
[Bug testsuite/55994] multiple definition or memset or strlen for builtins tests with LTO options
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55994 Sebastian Huber sebastian.hu...@embedded-brains.de changed: What|Removed |Added CC||sebastian.huber@embedded-br ||ains.de --- Comment #7 from Sebastian Huber sebastian.hu...@embedded-brains.de 2013-03-20 09:20:24 UTC --- The crucial thing is also that all these functions are recognized as builtins and GCC knows what they are expected to do. The failure also vanishes if -fno-builtin is used. Lets have a look at this example: gcc 1.c 2.c 3.c -l4 I expect that the modules 1.o 2.o 3.o end up in the executable and unresolved symbols inside this module set are resolved with definitions provided by the library 4. In particular if I have a global function f() in 2.c then I expect to have this function in my executable even in case a global function f() is also defined in the library 4. This is wrong for builtins. Here GCC seems to assume that implementations are interchangeable. It would be quite interesting to know what happens if we compile libc with -flto. In one failed GCC test f() is memcpy(), 2.c is 20010124-1-lib.c and lib4 is libc.
[Bug libgcc/56656] Suffix or operands invalid for 'movq'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56656 --- Comment #10 from Uros Bizjak ubizjak at gmail dot com 2013-03-20 09:29:13 UTC --- Author: uros Date: Wed Mar 20 09:23:39 2013 New Revision: 196813 URL: http://gcc.gnu.org/viewcvs?rev=196813root=gccview=rev Log: PR bootstrap/56656 * config/i386/i386.md (*movdi_internal): Handle broken assemblers that require movd instead of movq. Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.md
[Bug bootstrap/56656] Suffix or operands invalid for 'movq'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56656 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|NEW |RESOLVED Component|libgcc |bootstrap Resolution||FIXED --- Comment #11 from Uros Bizjak ubizjak at gmail dot com 2013-03-20 09:30:30 UTC --- Fixed. BTW: The change was applied to trunk only. 4.8 branch is not affected.
[Bug bootstrap/56656] Suffix or operands invalid for 'movq'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56656 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Version|4.8.0 |4.9.0 Target Milestone|--- |4.9.0
[Bug ada/53323] assertion failure on indefinite array of controlled objects and storage pools
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53323 --- Comment #2 from simon at pushface dot org 2013-03-20 09:36:44 UTC --- Still fails on 4.8. However: package Indefinite_Dynamic begins generic type Item () is private; type Item_Ptr is access Item; Storage : in out System.Storage_Pools.Root_Storage_Pool'Class; Initial_Size : Positive := 10; package Indefinite_Dynamic is and I find that the problem goes away if I move the formal parameters around so that Storage is the last parameter.
[Bug tree-optimization/56661] [4.8/4.9 regression] Incorrect code with -O1 -ftree-pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56661 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-03-20 AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | Target Milestone|--- |4.8.0 Summary|[4.8 regression] Incorrect |[4.8/4.9 regression] |code with -O1 -ftree-pre|Incorrect code with -O1 ||-ftree-pre Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-03-20 09:43:06 UTC --- Investigating.
[Bug ada/53323] assertion failure on indefinite array of controlled objects and storage pools
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53323 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-20 Ever Confirmed|0 |1 --- Comment #3 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-20 09:43:27 UTC --- Confirmed on mainline, but this will compile with the 4.8.0 release.
[Bug c++/56636] strange interaction of dynamic_cast and unique_ptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56636 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-20 09:43:46 UTC --- (friendly note to Daniel: gcc 4.8.0 trunk doesn't make much sense ;) Either you mean trunk (future 4.9) or the recently created gcc-4_8-branch branch, from which 4.8.0 will be released. Or maybe both, I don't know)
[Bug fortran/56655] Associate construct with OpenMP triggers ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56655 janus at gcc dot gnu.org changed: What|Removed |Added CC||janus at gcc dot gnu.org --- Comment #1 from janus at gcc dot gnu.org 2013-03-20 09:47:22 UTC --- (In reply to comment #0) Created attachment 29692 [details] Test source file to reproduce the error Attempting to compile the attached file with gfortran -fopenmp -c openmp_ice.f90 The file in the attachment is called 'test_h5_attr.f90' and I don't find any ASSOCIATE construct in there. Wrong file attached?
[Bug c++/56658] Silent conversion between 'char' and 'int' even though there are 'signed char' and 'unsigned char' alternatives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56658 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-03-20 09:48:46 UTC --- Actualy I think the clang guys tried to implement the standard, like the gcc guys.
[Bug tree-optimization/56662] New: ICE in gcc.dg/vect/vect-outer-5.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56662 Bug #: 56662 Summary: ICE in gcc.dg/vect/vect-outer-5.c Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization AssignedTo: rguent...@suse.de ReportedBy: ktkac...@gcc.gnu.org Target: arm-none-eabi $SOURCE/gcc/gcc/testsuite/gcc.dg/vect/vect-outer-5.c:13:5: internal compiler error: in vect_do_peeling_for_loop_bound, at tree-vect-loop-manip.c:1798 0xaa4439 vect_do_peeling_for_loop_bound(_loop_vec_info*, tree_node**, unsigned int, bool) $SOURCE/gcc/gcc/tree-vect-loop-manip.c:1798 0xaadea1 vectorize_loops() $SOURCE/gcc/gcc/tree-vectorizer.c:123 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. FAIL: gcc.dg/vect/vect-outer-5.c (internal compiler error) Compiler configured with: Configured with: $SOURCE/gcc/configure --target=arm-none-eabi --prefix=$SOURCE/build/install --with-gmp=$SOURCE/build/host-tools --with-mpfr=$SOURCE/build/host-tools --with-mpc=$SOURCE/build/host-tools --with-pkgversion=unknown --disable-shared --disable-nls --disable-threads --disable-tls --enable-checking=yes --enable-languages=c,c++,fortran --with-newlib --with-fpu=neon-fp16 --with-float=hard --with-arch=armv7-a ICE triggered for me with the command: arm-none-eabi-gcc -fno-diagnostics-show-caret -ffast-math -ftree-vectorize -fno-vect-cost-model -fno-common -O2 -fdump-tree-vect-details -S vect-outer-5.i caused by r196770. I believe Richard already has a patch queued to fix this
[Bug tree-optimization/56661] [4.8/4.9 regression] Incorrect code with -O1 -ftree-pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56661 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||vries at gcc dot gnu.org --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-03-20 10:12:35 UTC --- It's the tail-merging value-numbering doing Value numbering .MEM_8 stmt = b_9 = malloc (12); Setting value number of .MEM_8 to .MEM_8 (changed) Setting value number of b_9 to b_9 (changed) SCC consists of: .MEM_11 Value numbering .MEM_11 stmt = b_12 = malloc (12); Setting value number of .MEM_11 to .MEM_8 (changed) Setting value number of b_12 to b_9 (changed) SCC consists of: b_12 which is of course bogus. The pointers do not share the same alias properties and thus when disambiguating *b_12 against setb (b_12) which uses the call-clobbered vars set of the gimple call it doesn't work if you instead ask it to disambiguate *b_9. I know that I was nervous about this change ... it basically value-numbers the result of non-const/pure calls using the same VUSE the same. That's broken if the IL contains bits that rely on the results being distinct (which is alias information when it comes to malloc-like results). In theory alias info of value-equivalent SSA names can be _intersected_ to get the alias info of the value. Now in this case alias info computation relies on the fact that the calls are different - which means alias info for those equivalent SSA names has to be _unioned_. All of this alias-info adjusting doesn't work during the value-numbering process though, so it's not an option to do it as a post-processing step. We rely on the intersection property with all the value-numbering to not need to do any alias-info adjusting - but getting the unioning requirement in via value-numbering those calls the same breaks this. Which means the most obvious fix is to not value-number those calls the same.
[Bug tree-optimization/56661] [4.8/4.9 regression] Incorrect code with -O1 -ftree-pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56661
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-20
10:19:12 UTC ---
Single file simplified testcase:
__attribute__((noinline, noclone)) void
bar (int *b)
{
b[0] = b[1] = b[2] = 1;
}
__attribute__((noinline, noclone)) int
baz (int x)
{
if (x != 1)
__builtin_abort ();
}
void
foo (int x)
{
if (x == 0)
{
int *b = __builtin_malloc (3 * sizeof (int));
while (b[0])
;
}
else if (x == 1)
{
int i, j;
int *b = __builtin_malloc (3 * sizeof (int));
for (i = 0; i 2; i++)
{
bar (b);
for (j = 0; j 3; ++j)
baz (b[j]);
baz (b[0]);
}
}
}
int
main ()
{
int x = 1;
asm volatile ( : +r (x));
foo (x);
return 0;
}
[Bug c++/56636] strange interaction of dynamic_cast and unique_ptr
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56636 --- Comment #4 from Daniel Krügler daniel.kruegler at googlemail dot com 2013-03-20 10:19:47 UTC --- (In reply to comment #3) I tested gcc 4.8.0 20130310 (experimental)
[Bug bootstrap/56644] --disable-nls requires symbols from libintl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56644 --- Comment #4 from Rolf Ebert rolf.ebert.gcc at gmx dot de 2013-03-20 10:23:43 UTC --- I used the release candidate 4.8.0 from 2013-03-16 (see initial problem description)
[Bug other/56663] New: [PATCH] docs can't be built with texinfo 5.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56663 Bug #: 56663 Summary: [PATCH] docs can't be built with texinfo 5.x Classification: Unclassified Product: gcc Version: 4.7.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: bernhard.rosenkran...@linaro.org Created attachment 29699 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29699 Patch gcc fails to build while generating its documentation if texinfo 5.x is installed. Attaching a fix.
[Bug fortran/56659] Segfault due to missing libcpp error handler for gfortran -cpp
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56659 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-20 Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-03-20 10:49:24 UTC --- Confirmed.
[Bug c++/56658] Silent conversion between 'char' and 'int' even though there are 'signed char' and 'unsigned char' alternatives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56658 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-03-20 10:58:22 UTC --- char is simply subject to integral promotions if there is no exact match, those come before conversions are considered. char is _not_ equal to either unsigned char or signed char!
[Bug target/56657] [4.6/4.7 Regression] ICE - error: unrecognizable insn.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56657 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-20 Component|middle-end |target Target Milestone|--- |4.6.4 Summary|[GCC 4.6/4.7] ICE - error: |[4.6/4.7 Regression] ICE - |unrecognizable insn.|error: unrecognizable insn. Ever Confirmed|0 |1 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org 2013-03-20 11:00:41 UTC --- Confirmed partly as of comment #4. State of 4.8/4.9 unknown.
[Bug tree-optimization/56662] ICE in gcc.dg/vect/vect-outer-5.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56662 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-03-20 11:01:29 UTC --- Fixed by 2013-03-20 Richard Biener rguent...@suse.de * tree-vect-loop-manip.c (slpeel_can_duplicate_loop_p): Do not check whether an SSA update is needed.
[Bug other/56663] [PATCH] docs can't be built with texinfo 5.x
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56663 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-03-20 11:02:42 UTC --- Duplicate. *** This bug has been marked as a duplicate of bug 56258 ***
[Bug bootstrap/56258] Please upgrade doc/*.texi to the latest texinfo package(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56258 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||Bernhard.Rosenkranzer at ||linaro dot org --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org 2013-03-20 11:02:42 UTC --- *** Bug 56663 has been marked as a duplicate of this bug. ***
[Bug ada/48835] porting GNAT to m68k-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #54 from Mikael Pettersson mikpe at it dot uu.se 2013-03-20 11:05:58 UTC --- Status update: Although gnat is solid enough to rebuild itself with (patched) gcc-4.6 on m68k, there is a regression with (similarly patched) 4.7 that breaks bootstrap: /mnt/scratch/objdir47/./gcc/xgcc -B/mnt/scratch/objdir47/./gcc/ -B/usr/m68k-brewer-linux/bin/ -B/usr/m68k-brewer-linux/lib/ -isystem /usr/m68k-brewer-linux/include -isystem /usr/m68k-brewer-linux/sys-include -c -g -O2 -mcpu=68060 -fpic -W -Wall -gnatpg -nostdinc -mcpu=68060 a-calfor.adb -o a-calfor.o xgcc: internal compiler error: Segmentation fault (program gnat1) Please submit a full bug report, with preprocessed source if appropriate. make[9]: *** [a-calfor.o] Error 4 make[9]: Leaving directory `/mnt/scratch/objdir47/gcc/ada/rts_m68060' make[8]: *** [gnatlib] Error 2 make[8]: Leaving directory `/mnt/scratch/objdir47/gcc/ada' make[7]: *** [gnatlib-shared-default] Error 2 make[7]: Leaving directory `/mnt/scratch/objdir47/gcc/ada' make[6]: *** [gnatlib-shared-dual] Error 2 make[6]: Leaving directory `/mnt/scratch/objdir47/gcc/ada' make[5]: *** [gnatlib-shared] Error 2 make[5]: Leaving directory `/mnt/scratch/objdir47/gcc/ada' make[4]: *** [gnatlib-shared] Error 2 make[4]: Leaving directory `/mnt/scratch/objdir47/m68k-brewer-linux/m68060/libada' make[3]: *** [multi-do] Error 1 make[3]: Leaving directory `/mnt/scratch/objdir47/m68k-brewer-linux/libada' make[2]: *** [all] Error 2 make[2]: Leaving directory `/mnt/scratch/objdir47/m68k-brewer-linux/libada' make[1]: *** [all-target-libada] Error 2 make[1]: Leaving directory `/mnt/scratch/objdir47' make: *** [bootstrap] Error 2 This only occurs when compiling the 68060 variant of the libraries. With multilibs disabled 4.7.3 bootstraps fine w/ Ada. This ICE started with r180192, an ICE fix (PR50780). I don't see anything in that patch that seems m68k or cc0 related, so I suspect it just exposed some latent issue.
[Bug bootstrap/56258] Please upgrade doc/*.texi to the latest texinfo package(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56258 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org 2013-03-20 11:09:04 UTC --- I have applied the patch for the 4.7/4.6 branches now. Thus this is fixed (hopefully).
[Bug other/56664] New: internal compiler error: in estimate_function_body_sizes, at ipa-inline.c:1940
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56664
Bug #: 56664
Summary: internal compiler error: in
estimate_function_body_sizes, at ipa-inline.c:1940
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.sm...@alcatel-lucent.com
perl -e print 'void test(void) { __asm__ volatile ('; print '\.byte
,,,,,,,,,,,,,,,;\n\'x150;
print ');}'; /tmp/test.c
[Bug bootstrap/56258] Please upgrade doc/*.texi to the latest texinfo package(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56258
--- Comment #14 from Richard Biener rguenth at gcc dot gnu.org 2013-03-20
11:16:14 UTC ---
Author: rguenth
Date: Wed Mar 20 11:06:35 2013
New Revision: 196819
URL: http://gcc.gnu.org/viewcvs?rev=196819root=gccview=rev
Log:
2013-03-20 Jack Howarth howa...@bromo.med.uc.edu
PR bootstrap/56258
* doc/generic.texi (POINTER_PLUS_EXPR): Use @item instead of @itemx.
(PLUS_EXPR): Likewise.
* doc/cppopts.texi (--help): Likewise.
* doc/invoke.texi (-fenable-@var{kind}-@var{pass}): Likewise.
(-fdump-rtl-cprop_hardreg): Likewise.
(-fdump-rtl-csa): Likewise.
(-fdump-rtl-dce): Likewise.
(-fdump-rtl-dbr): Likewise.
(-fdump-rtl-into_cfglayout): Likewise.
(-fdump-rtl-outof_cfglayout): Likewise.
Modified:
branches/gcc-4_7-branch/gcc/ChangeLog
branches/gcc-4_7-branch/gcc/doc/cppopts.texi
branches/gcc-4_7-branch/gcc/doc/generic.texi
branches/gcc-4_7-branch/gcc/doc/invoke.texi
[Bug bootstrap/56258] Please upgrade doc/*.texi to the latest texinfo package(s)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56258
--- Comment #15 from Richard Biener rguenth at gcc dot gnu.org 2013-03-20
11:16:42 UTC ---
Author: rguenth
Date: Wed Mar 20 11:08:52 2013
New Revision: 196820
URL: http://gcc.gnu.org/viewcvs?rev=196820root=gccview=rev
Log:
2013-03-20 Jack Howarth howa...@bromo.med.uc.edu
PR bootstrap/56258
* doc/generic.texi (POINTER_PLUS_EXPR): Use @item instead of @itemx.
(PLUS_EXPR): Likewise.
* doc/cppopts.texi (--help): Likewise.
* doc/invoke.texi (-fenable-@var{kind}-@var{pass}): Likewise
(-fdump-rtl-cprop_hardreg): Likewise.
(-fdump-rtl-csa): Likewise.
(-fdump-rtl-dce): Likewise.
(-fdump-rtl-dbr): Likewise.
(-fdump-rtl-into_cfglayout): Likewise.
(-fdump-rtl-outof_cfglayout): Likewise.
(@gccoptlist): Move misplaced bracket.
Modified:
branches/gcc-4_6-branch/gcc/ChangeLog
branches/gcc-4_6-branch/gcc/doc/cppopts.texi
branches/gcc-4_6-branch/gcc/doc/generic.texi
branches/gcc-4_6-branch/gcc/doc/invoke.texi
[Bug tree-optimization/56522] [4.8/4.9 Regression] Bytemark ASSIGNMENT 9% / 11% slower
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56522 wbrana wbrana at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||WORKSFORME --- Comment #17 from wbrana wbrana at gmail dot com 2013-03-20 11:37:05 UTC --- I can switch to gold linker since 4.8
[Bug fortran/54932] Invalid loop code generated by Fortran FE for loops with bounds in HIGH(type)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54932 --- Comment #17 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-20 11:39:31 UTC --- Author: ro Date: Wed Mar 20 11:34:56 2013 New Revision: 196821 URL: http://gcc.gnu.org/viewcvs?rev=196821root=gccview=rev Log: Don't XFAIL gfortran.dg/do_1.f90 (PR fortran/54932) PR fortran/54932 * gfortran.dg/do_1.f90: Don't xfail. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/do_1.f90
[Bug c++/56665] New: -O2 with -fno-strict-aliasing makes boost::spirit::classic::assign_a not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56665
Bug #: 56665
Summary: -O2 with -fno-strict-aliasing makes
boost::spirit::classic::assign_a not working
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: bodzio...@op.pl
Hi,
I have problem using gcc4.7.2 with -fno-strict-aliasing switch along with -O2.
This combination makes boost::spirit::classic::assign_a (boost1.48) not working
properly. In undermentioned example value 101101 is not assigned to 'variable'.
It worked fine with gcc3.4.3, and it works ok with gcc4.7.2 -O2 without
-fno-strict-aliasing.
//-- start
#include boost/spirit/include/classic.hpp
#include boost/spirit/include/phoenix1.hpp
#include stdio.h
int main()
{
int variable = 123;
using namespace boost::spirit::classic;
using namespace phoenix;
rule testRule
// = eps_p [ var( variable ) = 101101 ] //that one works fine with -O2
-fno-strict-aliasing
= eps_p [ assign_a( variable, 101101 ) ] //this one gives rubbish with
-O2 -fno-strict-aliasing
;
parse_info result = parse( bla bla, testRule );
if ( result.hit )
printf( %d\n, variable );
return 0;
}
//-- end
gcc details:
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/build/storage/toolchain/gcc-4.7.2/bin/../libexec/gcc/i686-pc-linux-gnu/4.7.2/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.7.2/configure --prefix=/usr/local/gcc-4.7.2
--enable-languages=c,c++ --with-gmp=/usr/local/gcc-4.7.2
--with-ppl=/usr/local/gcc-4.7.2 --with-cloog=/usr/local/gcc-4.7.2
Thread model: posix
gcc version 4.7.2 (GCC)
Whole comilation log (g++ -v -save-temps -O2 -fno-strict-aliasing -pthread
-I/usr/local/gcc-4.7.2/STLport-5.2.1/boost-1.48/include
-L/usr/local/gcc-4.7.2/STLport-5.2.1/lib main.cpp -o test):
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/home/build/storage/toolchain/gcc-4.7.2/bin/../libexec/gcc/i686-pc-linux-gnu/4.7.2/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.7.2/configure --prefix=/usr/local/gcc-4.7.2
--enable-languages=c,c++ --with-gmp=/usr/local/gcc-4.7.2
--with-ppl=/usr/local/gcc-4.7.2 --with-cloog=/usr/local/gcc-4.7.2
Thread model: posix
gcc version 4.7.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O2' '-fno-strict-aliasing' '-pthread'
'-I' '/usr/local/gcc-4.7.2/STLport-5.2.1/boost-1.48/include'
'-L/usr/local/gcc-4.7.2/STLport-5.2.1/lib' '-o' 'test' '-shared-libgcc'
'-mtune=generic' '-march=pentiumpro'
/home/build/storage/toolchain/gcc-4.7.2/bin/../libexec/gcc/i686-pc-linux-gnu/4.7.2/cc1plus
-E -quiet -v -I /usr/local/gcc-4.7.2/STLport-5.2.1/boost-1.48/include -iprefix
/home/build/storage/toolchain/gcc-4.7.2/bin/../lib/gcc/i686-pc-linux-gnu/4.7.2/
-D_GNU_SOURCE -D_REENTRANT main.cpp -mtune=generic -march=pentiumpro
-fno-strict-aliasing -O2 -fpch-preprocess -o main.ii
ignoring nonexistent directory
/home/build/storage/toolchain/gcc-4.7.2/bin/../lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../i686-pc-linux-gnu/include
ignoring duplicate directory
/home/build/storage/toolchain/gcc-4.7.2/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../include/c++/4.7.2
ignoring duplicate directory
/home/build/storage/toolchain/gcc-4.7.2/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../include/c++/4.7.2/i686-pc-linux-gnu
ignoring duplicate directory
/home/build/storage/toolchain/gcc-4.7.2/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../include/c++/4.7.2/backward
ignoring duplicate directory
/home/build/storage/toolchain/gcc-4.7.2/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.7.2/include
ignoring duplicate directory
/home/build/storage/toolchain/gcc-4.7.2/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.7.2/include-fixed
ignoring nonexistent directory
/home/build/storage/toolchain/gcc-4.7.2/bin/../lib/gcc/../../lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../i686-pc-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/local/gcc-4.7.2/STLport-5.2.1/boost-1.48/include
/home/build/storage/toolchain/gcc-4.7.2/bin/../lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../include/c++/4.7.2
/home/build/storage/toolchain/gcc-4.7.2/bin/../lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../include/c++/4.7.2/i686-pc-linux-gnu
/home/build/storage/toolchain/gcc-4.7.2/bin/../lib/gcc/i686-pc-linux-gnu/4.7.2/../../../../include/c++/4.7.2/backward
/home/build/storage/toolchain/gcc-4.7.2/bin/../lib/gcc/i686-pc-linux-gnu/4.7.2/include
/home/build/storage/toolchain/gcc-4.7.2/bin/../lib/gcc/i686-pc-linux-gnu/4.7.2/include-fixed
/usr/local/include
[Bug c++/56665] -O2 with -fno-strict-aliasing makes boost::spirit::classic::assign_a not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56665 --- Comment #1 from Bogdan bodzio131 at op dot pl 2013-03-20 11:50:32 UTC --- Created attachment 29700 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29700 preprocessor output + log + test case
[Bug c++/56665] -O2 with -fno-strict-aliasing makes boost::spirit::classic::assign_a not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56665 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-03-20 Ever Confirmed|0 |1 Known to fail||4.7.2, 4.8.0, 4.9.0 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-03-20 11:58:46 UTC --- Also broken on trunk with plain -O2. Thus very likely triggered by changes of inline decisions. Works with -O and -O2 -fno-inline on trunk.
[Bug other/56664] internal compiler error: in estimate_function_body_sizes, at ipa-inline.c:1940
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56664 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-03-20 12:06:05 UTC --- dup *** This bug has been marked as a duplicate of bug 56580 ***
[Bug tree-optimization/56580] Internal compiler error when trying to compile a sequence of NOPs inside a loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56580 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC||jan.sm...@alcatel-lucent.co ||m --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-03-20 12:06:05 UTC --- *** Bug 56664 has been marked as a duplicate of this bug. ***
[Bug c++/56646] [4.7/4.8/4.9 Regression] ICE: in cp_parser_late_return_type_opt, at cp/parser.c:16970
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56646 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||jason at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2013-03-20 12:10:17 UTC --- Started with http://gcc.gnu.org/viewcvs?root=gccview=revrev=175671
[Bug fortran/56666] New: Suppression flag for DO loop at (1) will be executed zero times
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5 Bug #: 5 Summary: Suppression flag for DO loop at (1) will be executed zero times Classification: Unclassified Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: haugb...@gmail.com When running the gfortran compiler on source files with zero-trip do loops, such as do i=1,0 ...do..something... enddo the compiler will complain with the warning : Warning: DO loop at (1) will be executed zero times test.f90:10.12: do i=1,0 1 Warning: DO loop at (1) will be executed zero times We have a code, which makes use of preprocessing to select different configurations. In the default configuration there are hundreds of these kind of loops. The warning makes it harder to spot other warnings and errors. It would be nice if it were possible to suppress/enable the warning with a flag like -Wzerotrip -Wno-zerotrip
[Bug fortran/56667] New: Syntax error causes misleading message: Expected PARAMETER symbol in complex constant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56667 Bug #: 56667 Summary: Syntax error causes misleading message: Expected PARAMETER symbol in complex constant Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: arjen.mar...@deltares.nl The following program causes the error message Expected PARAMETER symbol in complex constant, whereas the true error is the omission of a closing parenthesis. ! error_message.f90 -- ! Misleading error message ! program error_message implicit none integer :: ir write(*,*) ( ir, ir = 1,10 end program error_message
[Bug bootstrap/56656] Suffix or operands invalid for 'movq'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56656 --- Comment #12 from Rich Townsend townsend at astro dot wisc.edu 2013-03-20 12:56:53 UTC --- (In reply to comment #9) So I guess an important question is if the svn-fetched 4.8.0 wasn't actually svn-fetched trunk instead, Uros' changes have been committed only for 4.9 and not on the 4.8 branch. It was indeed trunk. I wasn't aware that 4.8 is now a proper branch, so I was still fetching the trunk.
[Bug fortran/56655] Associate construct with OpenMP triggers ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56655 --- Comment #2 from Rich Townsend townsend at astro dot wisc.edu 2013-03-20 13:25:15 UTC --- (In reply to comment #1) (In reply to comment #0) Created attachment 29692 [details] Test source file to reproduce the error Attempting to compile the attached file with gfortran -fopenmp -c openmp_ice.f90 The file in the attachment is called 'test_h5_attr.f90' and I don't find any ASSOCIATE construct in there. Wrong file attached? (In reply to comment #1) (In reply to comment #0) Created attachment 29692 [details] Test source file to reproduce the error Attempting to compile the attached file with gfortran -fopenmp -c openmp_ice.f90 The file in the attachment is called 'test_h5_attr.f90' and I don't find any ASSOCIATE construct in there. Wrong file attached? Ooops -- wrong test case. Here it is: subroutine sub (x) implicit none real, intent(in) :: x !$omp single associate(x_a = x) end associate !$omp end single end subroutine sub
[Bug tree-optimization/56661] [4.8/4.9 regression] Incorrect code with -O1 -ftree-pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56661 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-03-20 13:28:23 UTC --- Author: rguenth Date: Wed Mar 20 13:26:19 2013 New Revision: 196825 URL: http://gcc.gnu.org/viewcvs?rev=196825root=gccview=rev Log: 2013-03-20 Richard Biener rguent...@suse.de PR tree-optimization/56661 * tree-ssa-sccvn.c (visit_use): Only value-number calls if the result does not have to be distinct. * gcc.dg/torture/pr56661.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/torture/pr56661.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-sccvn.c
[Bug tree-optimization/56661] [4.8/4.9 regression] Incorrect code with -O1 -ftree-pre
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56661 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2013-03-20 13:28:50 UTC --- Author: rguenth Date: Wed Mar 20 13:27:20 2013 New Revision: 196826 URL: http://gcc.gnu.org/viewcvs?rev=196826root=gccview=rev Log: 2013-03-20 Richard Biener rguent...@suse.de PR tree-optimization/56661 * tree-ssa-sccvn.c (visit_use): Only value-number calls if the result does not have to be distinct. * gcc.dg/torture/pr56661.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.dg/torture/pr56661.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/gcc/tree-ssa-sccvn.c
[Bug middle-end/56668] New: FAIL: gcc.dg/pr56494.c: ICE in simplify_subreg, at simplify-rtx.c:5725
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56668 Bug #: 56668 Summary: FAIL: gcc.dg/pr56494.c: ICE in simplify_subreg, at simplify-rtx.c:5725 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: dang...@gcc.gnu.org Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 Executing on host: /test/gnu/gcc/objdir64/gcc/xgcc -B/test/gnu/gcc/objdir64/gcc/ /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr56494.c -fno-diagnostics-show-caret -O2 -ftracer -w -S -o pr56494.s(timeout = 300) spawn /test/gnu/gcc/objdir64/gcc/xgcc -B/test/gnu/gcc/objdir64/gcc/ /test/gnu/gc c/gcc/gcc/testsuite/gcc.dg/pr56494.c -fno-diagnostics-show-caret -O2 -ftracer -w -S -o pr56494.s /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr56494.c: In function 'foo': /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/pr56494.c:13:1: internal compiler error: in simplify_subreg, at simplify-rtx.c:5725 -bash-3.2$ ./xgcc -B./ -v Reading specs from ./specs COLLECT_GCC=./xgcc COLLECT_LTO_WRAPPER=./lto-wrapper Target: hppa64-hp-hpux11.11 Configured with: ../gcc/configure --with-gnu-as --with-as=/opt/gnu64/bin/as --with-ld=/usr/ccs/bin/ld --enable-shared --with-local-prefix=/opt/gnu64 --prefix=/opt/gnu64/gcc/gcc-4.8 --build=hppa64-hp-hpux11.11 --enable-threads=posix --disable-nls --with-gmp=/opt/gnu64/gcc/gmp --with-libelf=/opt/gnu64 --enable-languages=c,c++,objc,obj-c++,fortran Thread model: posix gcc version 4.8.0 20130316 (prerelease) (GCC)
[Bug fortran/56655] [F03] ASSOCIATE construct with OpenMP triggers ICE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56655 janus at gcc dot gnu.org changed: What|Removed |Added Summary|Associate construct with|[F03] ASSOCIATE construct |OpenMP triggers ICE |with OpenMP triggers ICE --- Comment #3 from janus at gcc dot gnu.org 2013-03-20 14:27:55 UTC --- Note: OpenMP 3.1 does not handle any of Fortran 2003. In the current draft of OpenMP 4.0 (RC2), cf. http://openmp.org/wp/openmp-specifications/, many F03 features are still not supported. However, ASSOCIATE actually seems to be supported.
[Bug fortran/56305] passing array of character with len1 to c_loc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56305 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2013-03-20 14:42:19 UTC --- (In reply to comment #1) It seems to be invalid Fortran 2003 but valid Fortran 2008 Fortran 2003 has (15.1.2.5 C LOC (X)): Argument. X shall either (1) have interoperable type and type parameters and be [...] As this change is already in the Technical Corrigendum 5 to Fortran 2003, it is also valid in Fortran 2003. See PR39288.
[Bug c++/56669] New: Short code causes segfault with large -ftemplate-depth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56669 Bug #: 56669 Summary: Short code causes segfault with large -ftemplate-depth Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: antoine...@gmail.com Created attachment 29701 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29701 Code causing segault with large -ftemplate-depth Attached code compiled with g++ -Wall -std=c++11 -c -ftemplate-depth=65536 causes gcc (4.7.2 4.8.0) to segfault. The attached code is obviously a little demanding on the compiler and segfault only occurs with large -ftemplate-depth, but still a segfault is not nice and might be triggered by more mundane code?
[Bug c++/56669] Short code causes segfault with large -ftemplate-depth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56669 --- Comment #1 from Antoine Poliakov antoinep92 at gmail dot com 2013-03-20 14:46:27 UTC --- Created attachment 29702 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29702 error message from 4.8.0 with stack trace
[Bug c++/56658] Silent conversion between 'char' and 'int' even though there are 'signed char' and 'unsigned char' alternatives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56658 --- Comment #3 from GS greenscape777 at gmail dot com 2013-03-20 15:07:00 UTC --- What about warning? Would it be like harmful, or what?
[Bug tree-optimization/56355] abs and multiplication
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56355 --- Comment #3 from Marc Glisse glisse at gcc dot gnu.org 2013-03-20 15:40:30 UTC --- Jeff Law mentions that it would be good to add this squares are nonnegative information to VRP, not just tree_binary_nonnegative_warnv_p. http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00690.html
[Bug c++/51304] gcc segfaults for large -ftemplate-depth values (if depth is reached)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51304 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||antoinep92 at gmail dot com --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-20 16:17:30 UTC --- *** Bug 56669 has been marked as a duplicate of this bug. ***
[Bug c++/56669] Short code causes segfault with large -ftemplate-depth
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56669 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-20 16:17:30 UTC --- Dup. *** This bug has been marked as a duplicate of bug 51304 ***
[Bug tree-optimization/56355] abs and multiplication
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56355 --- Comment #4 from Marc Glisse glisse at gcc dot gnu.org 2013-03-20 16:19:33 UTC --- (In reply to comment #3) Jeff Law mentions that it would be good to add this squares are nonnegative information to VRP, not just tree_binary_nonnegative_warnv_p. http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00690.html Er, actually, since my patch, VRP does manage to deduce a non-negative range for squares, although, sadly, when computing x*x, it doesn't manage to merge the information from the interval of x and this non-negative property.
[Bug c++/51304] gcc segfaults for large -ftemplate-depth values (if depth is reached)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51304 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2013-03-20 16:22:26 UTC --- And indeed, I can confirm that the problem is the stack. Likewise happens with clang++.
[Bug c++/51304] gcc segfaults for large -ftemplate-depth values (if depth is reached)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51304 --- Comment #4 from Antoine Poliakov antoinep92 at gmail dot com 2013-03-20 16:52:35 UTC --- Yes, I also submitted the bug (15551) to clang. Doesn't seem to kill intel's icc though.
[Bug ada/53323] assertion failure on indefinite array of controlled objects and storage pools
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53323 --- Comment #4 from simon at pushface dot org 2013-03-20 17:24:06 UTC --- (In reply to comment #3) Confirmed on mainline, but this will compile with the 4.8.0 release. So it will (with gcc version 4.8.0 20130320 (prerelease) [gcc-4_8-branch revision 196828] (GCC)). Must have been a recent fix, cos it failed with gcc version 4.8.0 20130309 (experimental) [trunk revision 196573] (GCC)!
[Bug fortran/56670] New: Allocatable-length character var causes bogus warning with -Wall
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56670 Bug #: 56670 Summary: Allocatable-length character var causes bogus warning with -Wall Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: towns...@astro.wisc.edu Compiling this short test case with the -Wall option: program uninit_test implicit none character(LEN=:), allocatable :: name_format name_format = '' end program uninit_test ...causes the following bogus warning: uninit_test.f90: In function ‘uninit_test’: uninit_test.f90:7:0: warning: ‘.name_format’ may be used uninitialized in this function [-Wmaybe-uninitialized] name_format = '' ^ (Note also that the warning arises in the main program, and not in a function as the message suggests). gfortran -v: Using built-in specs. COLLECT_GCC=/Applications/madsdk/bin/gfortran.exec COLLECT_LTO_WRAPPER=/Applications/madsdk/libexec/gcc/x86_64-apple-darwin11.4.2/4.8.0/lto-wrapper Target: x86_64-apple-darwin11.4.2 Configured with: ./configure CC='gcc -D_FORTIFY_SOURCE=0' --build=x86_64-apple-darwin11.4.2 --prefix=/Applications/madsdk --with-gmp=/Applications/madsdk --with-mpfr=/Applications/madsdk --with-mpc=/Applications/madsdk --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.8.0 20130314 (experimental) (GCC)
[Bug ada/53323] assertion failure on indefinite array of controlled objects and storage pools
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53323 --- Comment #5 from Eric Botcazou ebotcazou at gcc dot gnu.org 2013-03-20 22:00:26 UTC --- Must have been a recent fix, cos it failed with gcc version 4.8.0 20130309 (experimental) [trunk revision 196573] (GCC)! Sort of, we now disable the front-end assertions on release branches.
[Bug target/54805] __gthread* on VxWorks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54805 Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mkuvyrkov at gcc dot ||gnu.org Resolution||FIXED --- Comment #3 from Maxim Kuvyrkov mkuvyrkov at gcc dot gnu.org 2013-03-20 23:48:11 UTC --- Fixed in revision 196842.
[Bug rtl-optimization/56434] document that __attribute__((__malloc__)) assumes returned pointer has BIGGEST_ALIGNMENT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56434 --- Comment #7 from Chip Salzenberg chip at pobox dot com 2013-03-21 00:31:40 UTC --- So ... is there still a question of the Right Thing here? It seems that fixing MALLOC_ABI_ALIGNMENT for the world, and ensuring that BIGGEST_ALIGNMENT never affects the ABI, are the actions to take. If this were done soon we could even see it fixed for 4.8.0. Help?
[Bug c++/56671] New: Gcc uses large amounts of memory and processor power with large C++11 bitsets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56671
Bug #: 56671
Summary: Gcc uses large amounts of memory and processor power
with large C++11 bitsets
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m1010...@gmail.com
When I attempt to instantiate std::bitset1024*1024*1024 in C++98 mode,
compilation takes a quarter-second and uses almost no RAM. In C++11 mode, it
takes 8 seconds and almost 2GB of RAM. The time and memory usage appear to
scale linearly with the size of the bitset. No errors or warnings are reported
in either mode.
Full code:
#include bitset
int main()
{
std::bitset1024*1024*1024 bs;
}
Compilation lines:
g++ -std=c++98 x.cpp
g++ -std=c++11 x.cpp
g++ -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.7.2/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id
--with-ppl --enable-cloog-backend=isl --disable-ppl-version-check
--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default
--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu
--enable-multilib --disable-libssp --disable-build-with-cxx
--disable-build-poststage1-with-cxx --enable-checking=release
Thread model: posix
gcc version 4.7.2 (GCC)
