[Bug middle-end/59223] -Wmaybe-uninitialized and -Wuninitialized relationships
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59223 --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Thu Feb 27 08:05:21 2014 New Revision: 208196 URL: http://gcc.gnu.org/viewcvs?rev=208196root=gccview=rev Log: PR middle-end/59223 * tree-ssa-uninit.c (gate_warn_uninitialized): Run the pass even for -Wmaybe-uninitialized. testsuite/ * c-c++-common/pr59223.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr59223.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-ssa-uninit.c
[Bug middle-end/59223] -Wmaybe-uninitialized and -Wuninitialized relationships
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59223 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug c++/60354] New: fails to demangle _Z3fooIPUlvE_EvT_
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60354
Bug ID: 60354
Summary: fails to demangle _Z3fooIPUlvE_EvT_
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: rguenth at gcc dot gnu.org
auto gf = []() {};
auto gfp = gf;
templatetypename T void foo(T f) { (*f)(); }
int main(void) {
foo(gfp);
auto lf = []() {};
auto lfp = lf;
foo(lfp);
}
generates, with -std=c++11
nm -C a.out | grep foo
00400624 t _Z3fooIPUlvE_EvT_
0040063e t void foomain::{lambda()#1}*(main::{lambda()#1}*)
which raises the question if that symbol is 1) correctly mangled, 2) the
demangler fails to handle it
[Bug fortran/60355] New: C519 of Fortran 2008 for BIND attribute not enforced
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60355 Bug ID: 60355 Summary: C519 of Fortran 2008 for BIND attribute not enforced Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: vladimir.fuka at gmail dot com bind(C) test_bind end is compiled without error or warning with gfortran -std=f2008 but C519 A variable with the BIND attribute shall be declared in the specification part of a module.
[Bug c++/60353] [4.9 Regression] Firefox build failure #3 caused by r208157
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60353 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug lto/55113] ICE with LTO and -fshort-double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113
--- Comment #14 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to pmatos from comment #13)
(In reply to Richard Biener from comment #11)
If double_type_node is FE dependent then it needs treatment in
tree-streamer.c:preload_common_nodes:
static void
preload_common_nodes (struct streamer_tree_cache_d *cache)
{
unsigned i;
for (i = 0; i itk_none; i++)
/* Skip itk_char. char_type_node is dependent on -f[un]signed-char. */
if (i != itk_char)
record_common_node (cache, integer_types[i]);
for (i = 0; i stk_type_kind_last; i++)
record_common_node (cache, sizetype_tab[i]);
for (i = 0; i TI_MAX; i++)
/* Skip boolean type and constants, they are frontend dependent. */
if (i != TI_BOOLEAN_TYPE
i != TI_BOOLEAN_FALSE
i != TI_BOOLEAN_TRUE)
record_common_node (cache, global_trees[i]);
}
Richard,
I tried what you suggested but led me nowhere. In the meantime I noticed
that -fshort-double shows up in COLLECT_GCC_OPTIONS before collect2 is
called:
COLLECT_GCC_OPTIONS='-fshort-double' '-flto' '-nostdlib' '-o' 'test'
'-save-temps' '-v' '-da' '-fdump-tree-all-all' '-mcpu=8540'
/home/pmatos/work/pr55113/top-4_8/toolchain/install/libexec/gcc/powerpc-
eabispe/4.8.3/collect2 -plugin
/home/pmatos/work/pr55113/top-4_8/toolchain/install/libexec/gcc/powerpc-
eabispe/4.8.3/liblto_plugin.so
-plugin-opt=/home/pmatos/work/pr55113/top-4_8/toolchain/install/libexec/gcc/
powerpc-eabispe/4.8.3/lto-wrapper -plugin-opt=-fresolution=pr55113.res -flto
--sysroot=/home/pmatos/work/pr55113/top-4_8/toolchain/prex_sysroot
--eh-frame-hdr -V -dn -Bstatic -o test
-L/home/pmatos/work/pr55113/top-4_8/toolchain/install/lib/gcc/powerpc-
eabispe/4.8.3
-L/home/pmatos/work/pr55113/top-4_8/toolchain/install/lib/gcc/powerpc-
eabispe/4.8.3/../../../../powerpc-eabispe/lib pr55113.o
but not after when lto1 is called:
COLLECT_GCC_OPTIONS='-c' '-mcpu=8540' '-nostdlib' '-save-temps' '-v' '-da'
'-fdump-tree-all-all' '-mcpu=8540' '-dumpdir' './' '-dumpbase' 'test.wpa'
'-fltrans-output-list=test.ltrans.out' '-fwpa' '-fresolution=pr55113.res'
/home/pmatos/work/pr55113/top-4_8/toolchain/install/libexec/gcc/powerpc-
eabispe/4.8.3/lto1 -quiet -da -dumpdir ./ -dumpbase test.wpa -mcpu=8540
-mcpu=8540 -auxbase pr55113 -version -fdump-tree-all-all
-fltrans-output-list=test.ltrans.out -fwpa -fresolution=pr55113.res
@/tmp/ccW7YQPl
Somewhere along the line the option is lost. It seems to be that only some
options are kept and optimization options are lost, like fshort-double.
-fshort-double is a C frontend family option and thus not generally available
(you can add LTO to the list of FEs that support it).
However, in lto/lto-lang.c:lto_init you have:
/* Create the basic integer types. */
build_common_tree_nodes (flag_signed_char, /*short_double=*/false);
This hardcodes short double to false. If I were to hardcode this to true,
Patricks example would work.
I think similarly to what we do in c-family/c-common.c:
build_common_tree_nodes (flag_signed_char, flag_short_double);
we need to pass flag_short_double but the only way to do so is by letting
fshort-double pass through the flag filtering that goes on before lto1 is
called.
Yes, see above - this will fix the immediate issue. Of course it won't
fix things if you have mismatched -fshort-double options in TUs or
in compile vs. link-time. For this was my original suggestion - do not
stream double_type_node but stream the type literally.
Index: tree-streamer.c
===
--- tree-streamer.c (revision 208066)
+++ tree-streamer.c (working copy)
@@ -264,7 +264,8 @@
gcc_checking_assert (node != boolean_type_node
node != boolean_true_node
- node != boolean_false_node);
+ node != boolean_false_node
+ node != double_type_node);
/* We have to make sure to fill exactly the same number of
elements for all frontends. That can include NULL trees.
@@ -318,7 +319,10 @@
/* Skip boolean type and constants, they are frontend dependent. */
if (i != TI_BOOLEAN_TYPE
i != TI_BOOLEAN_FALSE
-i != TI_BOOLEAN_TRUE)
+i != TI_BOOLEAN_TRUE
+i != TI_DOUBLE_TYPE
+i != TI_COMPLEX_DOUBLE_TYPE
+i != TI_DOUBLE_PTR_TYPE)
record_common_node (cache, global_trees[i]);
}
This should fix both errors - not passing on -fshort-double _and_ mixing
-f[no-]short-double.
Well. At least to my theory (didn't try).
I will prepare a patch to add this exception, let me know if you think
there's a better way.
See above - if that works I'd prefer that.
[Bug libquadmath/60349] Any call to expq (or libquadmath function that might possibly call expq) segfaults in mingw-gcc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60349 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-02-27 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Please provide at least a backtrace with debugging symbols available.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-02-27 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- It works for me. What does ldd test show? Do you have the static libstdc++/libgcc installed (Debian may package those separately?)
[Bug c++/60347] [4.9 Regression] r208153 breaks Firefox build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60347 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Maybe add the testcases to the testsuite?
[Bug lto/60295] [4.9 Regression] Too many lto1-wpa-stream processes are forked
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60295 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Fixed.
[Bug lto/55113] ICE with LTO and -fshort-double
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55113 --- Comment #15 from pmatos at gcc dot gnu.org --- (In reply to Richard Biener from comment #14) See above - if that works I'd prefer that. Makes sense. Thanks Richard. I will give that a try and if everything looks ok I will prepare a patch today along with a testcase.
[Bug testsuite/59308] [4.9 Regression] gcc.dg/tree-ssa/ssa-ifcombine-ccmp-[1456] tests fail on arm cortex-a5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59308 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Yes.
[Bug tree-optimization/59487] [4.9 Regression] When compiled with -fwhole-program rnflow.f90 runs up to 40% slower after r202826
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-02-27 Ever confirmed|0 |1 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Somebody needs to do the analysis. On our testers (all AMD) I don't see the regression.
[Bug lto/59925] [4.9 Regression] link failure in python2.7 build with -flto and -fprofile-use -fprofile-correction enabled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59925 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Somewhat unconclusive without a testcase. Does it meanwhile work by accident?
[Bug other/60133] [4.8/4.9 Regression] wrong multiarch name on aarch64-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60133 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug middle-end/60147] [4.9 Regression] ICE with -fdump-tree-original and NAMELIST
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60147 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug lto/60150] [4.9 Regression] ICE in function_and_variable_visibility, at ipa.c:1000
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60150 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-27 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug target/60169] [4.8/4.9 Regression] ICE ARM thumb1 handles far jump
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60169 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug ipa/60315] [4.8/4.9 Regression] template constructor switch optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2
[Bug ipa/60306] [4.9 Regression] Incorrect devirtualization pure virtual method called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60306 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-27 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug c++/60353] [4.9 Regression] Firefox build failure #3 caused by r208157
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60353 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Priority|P3 |P1 Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-27 Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug fortran/60334] Segmentation fault on character pointer assignments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60334 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 --- (In reply to Antony Lewis from comment #0) but compiled with gfortran -Og when run gives Program received signal 11 (SIGSEGV): Segmentation fault. I can confirm the segfault with 4.8, but I don't see it with trunk. However, also with trunk one gets some valgrind errors: ==13526== Conditional jump or move depends on uninitialised value(s) ==13526==at 0x4F0E687: _gfortran_transfer_character (in /usr/lib/x86_64-linux-gnu/libgfortran.so.3.0.0) ==13526==by 0x400806: MAIN__ (c0.f90:8) ==13526==by 0x400835: main (c0.f90:8) I don't directly see why the code would be invalid.
[Bug fortran/60334] Segmentation fault on character pointer assignments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60334 --- Comment #2 from Antony Lewis antony at cosmologist dot info --- I looked for a while for a reproducible crash, which wasn't easy - mostly behaviour was errratic crashes - I was using 4.9 trunk from a week ago. But there was definitely a general problem with the code generated by this kind of construct with various compiler options: a module full of them crashed all over the place or gave erratic results (compiled with gfortran, it's fine with ifort). It again worked fine when I changed all the character function results and temporary variables to allocatables. (my guess was the code is mistakenly auto-freeing some charater pointers in the same way it does character allocatables). Happy to provide the more realistic test case if useful to testing.
[Bug tree-optimization/59487] [4.9 Regression] When compiled with -fwhole-program rnflow.f90 runs up to 40% slower after r202826
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487 --- Comment #7 from GGanesh Ganesh.Gopalasubramanian at amd dot com --- Richard! With gcc version 4.9.0 20140224, I could see a gap between with/without -fwhole-program. with -fwhole-program : time ./rnflowWhPr real0m26.184s user0m26.018s sys 0m0.156s without -fwhole-program: time ./rnflow real0m18.251s user0m18.061s sys 0m0.180s
[Bug tree-optimization/59487] [4.9 Regression] When compiled with -fwhole-program rnflow.f90 runs up to 40% slower after r202826
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487 --- Comment #8 from rguenther at suse dot de rguenther at suse dot de --- On Thu, 27 Feb 2014, Ganesh.Gopalasubramanian at amd dot com wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487 --- Comment #7 from GGanesh Ganesh.Gopalasubramanian at amd dot com --- Richard! With gcc version 4.9.0 20140224, I could see a gap between with/without -fwhole-program. With what other options? with -fwhole-program : time ./rnflowWhPr real0m26.184s user0m26.018s sys 0m0.156s without -fwhole-program: time ./rnflow real0m18.251s user0m18.061s sys 0m0.180s
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #2 from Nach nachms+gcc at gmail dot com --- (In reply to Richard Biener from comment #1) It works for me. What does ldd test show? Do you have the static libstdc++/libgcc installed (Debian may package those separately?) ldd test linux-gate.so.1 (0xf76ff000) libm.so.6 = /lib/i386-linux-gnu/libm.so.6 (0xf7676000) libgcc_s.so.1 = /lib/i386-linux-gnu/libgcc_s.so.1 (0xf765a000) libc.so.6 = /lib/i386-linux-gnu/libc.so.6 (0xf74e7000) /lib/ld-linux.so.2 (0xf770) Recompiling with -static-libgcc added gives: 00690bc0 uDO .bss 0020 Base _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE 00690c00 uDO .bss 0020 Base _ZNSs4_Rep20_S_empty_rep_storageE And ldd: linux-vdso.so.1 (0x7011e000) libm.so.6 = /lib/x86_64-linux-gnu/libm.so.6 (0x7fecae56b000) libc.so.6 = /lib/x86_64-linux-gnu/libc.so.6 (0x7fecae1c2000) /lib64/ld-linux-x86-64.so.2 (0x7fecae8b1000) I also want to confirm that I indeed have the static libstdc++ and libgcc installed. Furthermore, I've compiled huge C++ projects which use at least a dozen std::string methods, iostream, a ton of STL, and these are the only two symbols that are missing when using -static-libstdc++. Without -static-libstdc++, a lot of other libstdc++ symbols are now present in objdump, for example: DF *UND* GLIBCXX_3.4 _ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
[Bug libquadmath/60349] Any call to expq (or libquadmath function that might possibly call expq) segfaults in mingw-gcc.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60349 Domani Hannes ssbssa at yahoo dot de changed: What|Removed |Added CC||ssbssa at yahoo dot de --- Comment #2 from Domani Hannes ssbssa at yahoo dot de --- This seems to be a bug in mingw-w64. See here: http://sourceforge.net/p/mingw-w64/bugs/368/
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #3 from Marc Glisse glisse at gcc dot gnu.org --- man nm: U The symbol is undefined. u The symbol is a unique global symbol. This is a GNU extension [...] The program does run fine for me with exactly the same compiler on debian. How did it fail to run for you, with what error message?
[Bug fortran/60356] New: Compiler segfault instead of error about module procedure / procedure with an explicit interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60356 Bug ID: 60356 Summary: Compiler segfault instead of error about module procedure / procedure with an explicit interface Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mvondomaros at gmail dot com Hi! The attached simple module causes a f951: internal compiler error: Segmentation fault. When I comment out the generic statement as indicated in the code, I get the expected error message: Error: 'my_method1_sub' must be a module procedure or an external procedure with an explicit interface at (1)
[Bug fortran/60356] Compiler segfault instead of error about module procedure / procedure with an explicit interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60356 --- Comment #1 from Mike mvondomaros at gmail dot com --- Created attachment 32223 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32223action=edit example that causes the segfault
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #4 from Nach nachms+gcc at gmail dot com --- (In reply to Marc Glisse from comment #3) man nm: U The symbol is undefined. u The symbol is a unique global symbol. This is a GNU extension [...] The program does run fine for me with exactly the same compiler on debian. How did it fail to run for you, with what error message? The issue isn't that it can't run on a machine with a proper libstdc++ installed, the issue is that -static-libstdc++ is broken, meaning the binary cannot run on a system without libstdc++ installed (or a too old version). Trying to run the Debian compiled binary on RHEL5 is giving me: ./test: symbol lookup error: ./test: undefined symbol: _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE And on RHEL5 system: objdump -T ./test | grep _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE 00690c00 DO .bss 0020 Base _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE Where on Debian it gives: 00690c00 uDO .bss 0020 Base _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE In the past when -static-libstdc++ was working, binaries ran just fine on older systems.
[Bug fortran/60289] allocating class(*) pointer as character gives type-spec requires the same character-length parameter
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60289 Mike mvondomaros at gmail dot com changed: What|Removed |Added CC||mvondomaros at gmail dot com --- Comment #3 from Mike mvondomaros at gmail dot com --- Same problem in 4.8.2
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #5 from Marc Glisse glisse at gcc dot gnu.org --- (In reply to Nach from comment #4) The issue isn't that it can't run on a machine with a proper libstdc++ installed, the issue is that -static-libstdc++ is broken, meaning the binary cannot run on a system without libstdc++ installed (or a too old version). Please don't guess what might be wrong. As strace would show, no libstdc++ is opened when executing test. Trying to run the Debian compiled binary on RHEL5 is giving me: ./test: symbol lookup error: ./test: undefined symbol: _ZNSbIwSt11char_traitsIwESaIwEE4_Rep20_S_empty_rep_storageE Does compiling with: -fuse-ld=gold -Wl,--no-gnu-unique help? Seems like your old system (ld.so?) gets confused by the new feature.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #6 from Nach nachms+gcc at gmail dot com --- Does compiling with: -fuse-ld=gold -Wl,--no-gnu-unique help? Seems like your old system (ld.so?) gets confused by the new feature. Doing so, there are no longer any u symbols appearing with objdump, nor those libstdc++ symbols appearing anywhere. Now, other systems are properly running the binary.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #7 from Nach nachms+gcc at gmail dot com --- Upon further testing, -fuse-ld=gold by itself without -Wl,--no-gnu-unique appears to get the job done.
[Bug c++/60353] [4.9 Regression] Firefox build failure #3 caused by r208157
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60353 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #8 from Marc Glisse glisse at gcc dot gnu.org --- gold also produces the unique symbols. Main difference I can think of is visible in the output of file test: ELF 64-bit LSB executable, x86-64, version 1 (SYSV) ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux)
[Bug fortran/60341] ICE compiling Nonmem 6.2.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60341 --- Comment #8 from Steve Chapel schapel at umich dot edu --- Yes, it's a regression from earlier versions of gfortran. I have verified that with the workaround, Nonmem 6.2.0 compiles and runs properly with optimization using gfortran 4.8.1 and 4.8.2. Turning optimization off also works.
[Bug ada/15606] Legal program rejected, RM 8.2(22)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15606 --- Comment #8 from nicolas.boulenguez at free dot fr --- Confirmed on 4.9-20140218.
[Bug ada/15614] Illegal program not detected, RM 12.1(11)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15614 --- Comment #5 from nicolas.boulenguez at free dot fr --- Confirmed on 4.9-20140218
[Bug ada/15615] Legal program rejected, derived tagged type in child package doesn't see parent's element
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15615 --- Comment #5 from nicolas.boulenguez at free dot fr --- Fixed in 4.9-20140218.
[Bug ada/15799] Legal program rejected, using 'Base
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15799 --- Comment #9 from nicolas.boulenguez at free dot fr --- Fixed in 4.9-20140218
[Bug fortran/60255] Deferred character length variable at (1) cannot yet be associated with unlimited polymorphic entities
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60255 --- Comment #5 from Antony Lewis antony at cosmologist dot info --- The patch generated a SIGSEGV in test code (which works with ifort), but could be another unrelated issue. Here's another simple test case for the original issue: program test character(LEN=:), allocatable :: S call subP(S) contains subroutine subP(P) class(*) :: P end subroutine end program
[Bug ada/15800] SIGSEGV on mutually recursive record type declarations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15800 --- Comment #6 from nicolas.boulenguez at free dot fr --- confirm 4.9-20140218
[Bug ada/15840] Illegal program not detected, RM 3.7(14)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15840 --- Comment #5 from nicolas.boulenguez at free dot fr --- confirm 4.9-20140218
[Bug ada/15843] Illegal program not detected, RM 3.7.2(2)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15843 --- Comment #6 from nicolas.boulenguez at free dot fr --- confirm 4.9-20140218
[Bug ada/15844] Illegal program not detected, RM 8.3(8)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15844 --- Comment #4 from nicolas.boulenguez at free dot fr --- confirm 4.9-20140218
[Bug ada/15845] Illegal program not detected, circular renames
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15845 --- Comment #4 from nicolas.boulenguez at free dot fr --- confirm 4.9-20140218
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #9 from Richard Biener rguenth at gcc dot gnu.org --- Thus, invalid.
[Bug target/60336] empty struct value is passed differently in C and C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #15 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Andrew Pinski from comment #7) No this testcase is not valid at all. See http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Empty-Structures.html#Empty- Structures where it is documented it is not valid. That only documents that sizeof is different for C and C++, the calling convention should be the same. And it seems like classify_argument should already be returning 1 with classes[0]==NO_CLASS for both C and C++. Why are we getting different results?
[Bug ada/15917] Bug box in Gigi, code=103, on legal program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15917 --- Comment #6 from nicolas.boulenguez at free dot fr --- 4.9.0 20140218 (experimental) [trunk rev 207856] (x86_64-linux-gnu) GCC error in gnat_to_gnu_entity, at ada/gcc-interface/decl.c:568 Error detected at test_70.adb:18:9
[Bug ada/16075] Wrong output from legal program, ordered generic parameter association
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16075 --- Comment #4 from nicolas.boulenguez at free dot fr --- confirm 4.9-20140218
[Bug ada/16076] Illegal program not detected, RM 13.14(5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16076 --- Comment #4 from nicolas.boulenguez at free dot fr --- confirm 4.9-20140218
[Bug ada/16077] Wrong output from legal program, pragma Import (Ada)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16077 --- Comment #4 from nicolas.boulenguez at free dot fr --- confirmed 4.9-20140218
[Bug fortran/60357] New: structure constructor with unspecified values for allocatable components
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60357 Bug ID: 60357 Summary: structure constructor with unspecified values for allocatable components Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info This valid F2008 code is rejected: module testmod Type A integer :: X = 1 integer, allocatable :: y end type A end module program testerprog use testmod Type(A) :: Me = A(X=1) end program Compiler error is: Type(A) :: Me = A(X=1) 1 Error: No initializer for component 'y' given in the structure constructor at (1)! However initialization statements are not required for allocatable components.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 Nach nachms+gcc at gmail dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|INVALID |--- --- Comment #10 from Nach nachms+gcc at gmail dot com --- While you may be marking this as invalid, isn't there a serious issue here? Shouldn't -static-libstdc++ work without any special flags? Also, using -fuse-ld=gold seems to be breaking any application I have which links to non-system libraries.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Nach from comment #10) While you may be marking this as invalid, isn't there a serious issue here? Shouldn't -static-libstdc++ work without any special flags? But it works, doesn't it? That you cannot transfer the binary to some random system is because the compiler checks the features to use (like GNU unique symbols) when building GCC. That means it's a dependency on the dynamic linker of the system, not on libstdc++. Your program can end up using GNU unique symbols, too, which would then result in exactly the same issue.
[Bug tree-optimization/59487] [4.9 Regression] When compiled with -fwhole-program rnflow.f90 runs up to 40% slower after r202826
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59487 --- Comment #9 from GGanesh Ganesh.Gopalasubramanian at amd dot com --- Other options are -Ofast -funroll-loops -fpeel-loops
[Bug driver/60358] New: [patch] ARM support broken for Haiku
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60358 Bug ID: 60358 Summary: [patch] ARM support broken for Haiku Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: driver Assignee: unassigned at gcc dot gnu.org Reporter: kallisti5 at unixzen dot com Created attachment 32224 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32224action=edit fix revision 1 host_detect_local_cpu only works on Linux platforms and should be disable on Haiku (due to the lack of /proc/cpuinfo) A more complete fix may be to implement host_detect_local_cpu for Haiku ARM, however that change could be messy (esp as the ARM Haiku port is extremely early)
[Bug driver/60358] [patch] ARM support broken for Haiku
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60358 --- Comment #1 from Alexander von Gluck kallisti5 at unixzen dot com --- Created attachment 32225 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32225action=edit rev2 an additional resolution path. This one may be better, however driver-arm.c would need additional changes to be Haiku-aware.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #12 from Nach nachms+gcc at gmail dot com --- Isn't the whole point of -static-libstdc++ is to remove the dependency of libstdc++ from the binary? Even without the option, it does indeed work fine on the system it was compiled on. However, -static-libstdc++ currently does not appear to be doing its job, and I would NOT define it as *working*. For nearly 8 years I've been able to provide ready made binaries for practically any system (as long as glibc wasn't ancient). Now after a recent upgrade of build utilities, I can't seem to provide binaries for anyone who isn't using a distro from the past year or so. Even though these are large projects and make use of many statically linked binaries, the culprit as reported is missing libstdc++ symbols which in theory should not be happening if -static-libstdc++ is used, and the two aforementioned symbols are the only libstdc++ I see listed in the binary. Using older build utilities, I've never seen any libstdc++ symbols appear in a binary when -static-libstdc++ was used. Adding -fuse-ld=gold appears to be a *workaround* which works for the sample test case I used above. But if I try using -fuse-ld=gold with more complicated projects, the binary never even ends up linking, with a whole spew of missing symbols, which I know for a fact are contained in libraries which are being specified. If this in fact a bug with binutils and not libstdc++ or GCC, then fine, I don't mind reporting it elsewhere, just please assist me in understanding the issue so I can effectively do so.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #13 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Nach from comment #12) Isn't the whole point of -static-libstdc++ is to remove the dependency of libstdc++ from the binary? Even without the option, it does indeed work fine on the system it was compiled on. However, -static-libstdc++ currently does not appear to be doing its job, and I would NOT define it as *working*. The binary is not dependent on libstdc++ anymore and providing a libstdc++ on a system where the binary doesn't work won't fix it (because libstdc++ is not even loaded). For nearly 8 years I've been able to provide ready made binaries for practically any system (as long as glibc wasn't ancient). Now after a recent upgrade of build utilities, I can't seem to provide binaries for anyone who isn't using a distro from the past year or so. Even though these are large projects and make use of many statically linked binaries, the culprit as reported is missing libstdc++ symbols which in theory should not be happening if -static-libstdc++ is used, and the two aforementioned symbols are the only libstdc++ I see listed in the binary. Using older build utilities, I've never seen any libstdc++ symbols appear in a binary when -static-libstdc++ was used. Adding -fuse-ld=gold appears to be a *workaround* which works for the sample test case I used above. But if I try using -fuse-ld=gold with more complicated projects, the binary never even ends up linking, with a whole spew of missing symbols, which I know for a fact are contained in libraries which are being specified. If this in fact a bug with binutils and not libstdc++ or GCC, then fine, I don't mind reporting it elsewhere, just please assist me in understanding the issue so I can effectively do so. If you want to target old dynamic linkers then you have to disable support for GCC features that exploit features of new dynamic linkers. You need to rebuild GCC to achieve that and provide --disable-gnu-unique-object at configure time to disable the use of unique object glibc dynamic linker extension.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #14 from Nach nachms+gcc at gmail dot com --- (In reply to Richard Biener from comment #13) If you want to target old dynamic linkers then you have to disable support for GCC features that exploit features of new dynamic linkers. You need to rebuild GCC to achieve that and provide --disable-gnu-unique-object at configure time to disable the use of unique object glibc dynamic linker extension. Okay thank you. Just one last question then, was there a specific version of GCC (and friends) that began using the glibc dynamic linker extension? Or to put it differently, how can I define whether a system has support for this extension? A certain minimum version of glibc?
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #15 from Richard Biener rguenth at gcc dot gnu.org --- (In reply to Nach from comment #14) (In reply to Richard Biener from comment #13) If you want to target old dynamic linkers then you have to disable support for GCC features that exploit features of new dynamic linkers. You need to rebuild GCC to achieve that and provide --disable-gnu-unique-object at configure time to disable the use of unique object glibc dynamic linker extension. Okay thank you. Just one last question then, was there a specific version of GCC (and friends) that began using the glibc dynamic linker extension? Or to put it differently, how can I define whether a system has support for this extension? A certain minimum version of glibc? The minimum glibc version required is 2.11 IIRC, GCC 4.5 started to use this extension if available at build time.
[Bug target/60336] empty struct value is passed differently in C and C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added CC||hjl.tools at gmail dot com --- Comment #16 from H.J. Lu hjl.tools at gmail dot com --- (In reply to Jason Merrill from comment #15) (In reply to Andrew Pinski from comment #7) No this testcase is not valid at all. See http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Empty-Structures.html#Empty- Structures where it is documented it is not valid. That only documents that sizeof is different for C and C++, the calling convention should be the same. And it seems like classify_argument should already be returning 1 with classes[0]==NO_CLASS for both C and C++. Why are we getting different results? X86 backend has some issues. But the C/C++ calling convention issue affects most, if not all, targets. You can try the test case in comment 4 on non-x86 targets.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #16 from Andreas Schwab sch...@linux-m68k.org --- If you want to build for old systems you need to use the old tools from those old systems and the output will still work on newer systems (backward compatiblity). New tools are using new features as they are available (no forward compatibility).
[Bug driver/60358] [patch] ARM support broken for Haiku
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60358 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #2 from ktkachov at gcc dot gnu.org --- Hi, I suggest you post patches for discussion to gcc-patc...@gcc.gnu.org They'll get more attention there.
[Bug libstdc++/60348] -static-libstdc++ broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60348 --- Comment #17 from Nach nachms+gcc at gmail dot com --- I just tried my above test case on RHEL6 without an up to date libstdc++ but with glibc 2.12, and the binary runs just fine. I double checked my old build system which does not produce these symbols, and I see it uses the following: Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.3-4' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.6 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.6.3 (Debian 4.6.3-4) Note the --enable-gnu-unique-object. Also the system uses glibc 2.13. Any reason why this old build setup does not use these glibc unique symbols even though every indication is that it should?
[Bug target/60336] empty struct value is passed differently in C and C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336
--- Comment #17 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Jason Merrill from comment #15)
That only documents that sizeof is different for C and C++, the calling
convention should be the same. And it seems like classify_argument should
already be returning 1 with classes[0]==NO_CLASS for both C and C++. Why
are we getting different results?
classify_argument has an early exit:
/* Zero sized arrays or structures are NO_CLASS. We return 0 to
signalize memory class, so handle it as special case. */
if (!words)
{
classes[0] = X86_64_NO_CLASS;
return 1;
}
but it doesn't trigger for c++, where words gets calculated as 1.
[Bug c++/60353] [4.9 Regression] Firefox build failure #3 caused by r208157
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60353 --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Feb 27 16:20:59 2014 New Revision: 208200 URL: http://gcc.gnu.org/viewcvs?rev=208200root=gccview=rev Log: PR c++/60353 PR c++/55877 * decl2.c (tentative_decl_linkage): Don't mess with functions that are not yet defined. Added: trunk/gcc/testsuite/g++.dg/other/anon6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c
[Bug c++/55877] [4.7/4.8/4.9 Regression] Anon visibility issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55877 --- Comment #12 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Feb 27 16:20:59 2014 New Revision: 208200 URL: http://gcc.gnu.org/viewcvs?rev=208200root=gccview=rev Log: PR c++/60353 PR c++/55877 * decl2.c (tentative_decl_linkage): Don't mess with functions that are not yet defined. Added: trunk/gcc/testsuite/g++.dg/other/anon6.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl2.c
[Bug fortran/60359] New: Assembler messages symbol `__io_MOD___copy_character_1' is already defined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60359 Bug ID: 60359 Summary: Assembler messages symbol `__io_MOD___copy_character_1' is already defined Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: antony at cosmologist dot info Created attachment 32226 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32226action=edit Source and makefile make getdist BUILD=NOMPI mkdir -p Release gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c MiscUtils.f90 -o Release/MiscUtils.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c ArrayUtils.f90 -o Release/ArrayUtils.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c StringUtils.f90 -o Release/StringUtils.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c MpiUtils.f90 -o Release/MpiUtils.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c FileUtils.f90 -o Release/FileUtils.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c RandUtils.f90 -o Release/RandUtils.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c ObjectLists.f90 -o Release/ObjectLists.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c Interpolation.f90 -o Release/Interpolation.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c IniObjects.f90 -o Release/IniObjects.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c ObjectParamNames.f90 -o Release/ObjectParamNames.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c settings.f90 -o Release/settings.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c Matrix_utils_new.f90 -o Release/Matrix_utils_new.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c samples.f90 -o Release/samples.o gfortran -cpp -O3 -ffast-math -I../camb -DNOWMAP -JRelease -IRelease/ -c IO.f90 -o Release/IO.o /tmp/cca4GMDL.s: Assembler messages: /tmp/cca4GMDL.s:102: Error: symbol `__io_MOD___copy_character_1' is already defined
[Bug c++/60353] [4.9 Regression] Firefox build failure #3 caused by r208157
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60353 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Fixed.
[Bug c++/59066] [C++11] 'using' instead of 'typedef' causes a segmentation fault.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59066 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #6 from Jason Merrill jason at gcc dot gnu.org --- I don't think the testcase is sufficiently different. Thanks. *** This bug has been marked as a duplicate of bug 60182 ***
[Bug c++/60182] g++ segfault within template expansion using using aliasing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60182 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added CC||alexandre.hamez at gmail dot com --- Comment #4 from Jason Merrill jason at gcc dot gnu.org --- *** Bug 59066 has been marked as a duplicate of this bug. ***
[Bug target/59222] [4.9 Regression] gcc.c-torture/compile/20050622-1.c ICEs at -O1 and above for aarch64-elf ILP32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59222 --- Comment #5 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Thu Feb 27 17:06:02 2014 New Revision: 208201 URL: http://gcc.gnu.org/viewcvs?rev=208201root=gccview=rev Log: 2014-02-27 Vladimir Makarov vmaka...@redhat.com PR target/59222 * lra.c (lra_emit_add): Check SUBREG too. Modified: trunk/gcc/ChangeLog trunk/gcc/lra.c
[Bug c++/58648] [c++11] ICE with variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58648 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Jason Merrill jason at gcc dot gnu.org --- Done, thanks.
[Bug c++/58648] [c++11] ICE with variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58648 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Thu Feb 27 17:06:35 2014 New Revision: 208202 URL: http://gcc.gnu.org/viewcvs?rev=208202root=gccview=rev Log: PR c++/58648 * g++.dg/cpp0x/variadic153.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/variadic153.C
[Bug c++/60347] [4.9 Regression] r208153 breaks Firefox build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60347 --- Comment #7 from Jason Merrill jason at gcc dot gnu.org --- I did add a testcase, which is not significantly different from the one in comment #3.
[Bug c/60360] New: __attribute((aligned(...))) changes sizeof(...) of struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60360
Bug ID: 60360
Summary: __attribute((aligned(...))) changes sizeof(...) of
struct
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dabler at gmail dot com
If the __attribute((aligned(...))) is used on structure, a size reported by
sizeof(...) operator is affected. Example:
struct strtype {
int i;
} __attribute((aligned(64))) s;
printf(%zu\n, sizeof(s));
This is in contrast with the behavior on other types, e.g. int type.
int i __attribute((aligned(64)));
printf(%zu\n, sizeof(i));
I believe that there is no reason to change sizeof(...) of the given struct
because an alignment can be determined by __alignof(...) operator.
[Bug c/60360] __attribute((aligned(...))) changes sizeof(...) of struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60360 --- Comment #1 from DaBler dabler at gmail dot com --- Created attachment 32227 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32227action=edit he preprocessed file that triggers the bug Output: 64 64 64 64 4 64 4 64 4 64 Expected output: 4 64 4 64 4 64 4 64 4 64
[Bug target/59222] [4.9 Regression] gcc.c-torture/compile/20050622-1.c ICEs at -O1 and above for aarch64-elf ILP32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59222 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |RESOLVED CC||law at redhat dot com Resolution|--- |FIXED --- Comment #6 from Jeffrey A. Law law at redhat dot com --- Fixed by Vlad's commit.
[Bug c/60360] __attribute((aligned(...))) changes sizeof(...) of struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60360 --- Comment #2 from DaBler dabler at gmail dot com --- The output of gcc -v: Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-cloog --with-ppl --with-cloog-include=/usr/include/cloog-ppl --disable-ppl-version-check --enable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/python --enable-checking=release --disable-libgcj --enable-libstdcxx-time --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.3 p1.13, pie-0.5.2' Thread model: posix gcc version 4.6.3 (Gentoo 4.6.3 p1.13, pie-0.5.2)
[Bug c++/58610] [4.7/4.8/4.9 Regression] [c++11] ICE with constexpr of class with template constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58610 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-02-27 Ever confirmed|0 |1
[Bug target/60336] empty struct value is passed differently in C and C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336
--- Comment #18 from Jason Merrill jason at gcc dot gnu.org ---
(In reply to Uroš Bizjak from comment #17)
classify_argument has an early exit:
/* Zero sized arrays or structures are NO_CLASS. We return 0 to
signalize memory class, so handle it as special case. */
if (!words)
{
classes[0] = X86_64_NO_CLASS;
return 1;
}
but it doesn't trigger for c++, where words gets calculated as 1.
Yes, it looks like this special case is in order to return the same thing that
C++ does through the normal logic: normally we return 'words', and since there
are no fields classes[0] is still initialized to NO_CLASS.
[Bug c++/58610] [4.7/4.8/4.9 Regression] [c++11] ICE with constexpr of class with template constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58610 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug ada/16081] Illegal program not detected, ambiguous call to =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16081 --- Comment #3 from nicolas.boulenguez at free dot fr --- confirmed with 4.9-20140218
[Bug ada/16083] Illegal program not detected, RM 3.9.2(13)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16083 --- Comment #3 from nicolas.boulenguez at free dot fr --- found in 4.9-20140218
[Bug c/60360] __attribute((aligned(...))) changes sizeof(...) of struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60360 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org --- This is expected as sizeof a struct is always multiple of the alignment because of padding. The scalar is not due to another variable can be padded after it.
[Bug ada/16095] Illegal program not detected, accessibility levels, RM 3.10.2(28)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16095 --- Comment #6 from nicolas.boulenguez at free dot fr --- found in 4.9-20140218
[Bug ada/16096] Illegal program not detected, RM 8.5.4(5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16096 --- Comment #3 from nicolas.boulenguez at free dot fr --- found in 4.9-20140218
[Bug ada/16097] Illegal program not detected, RM 6.3.1(9), RM 8.5.4(5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16097 --- Comment #3 from nicolas.boulenguez at free dot fr --- Found in 4.9-20140218
[Bug target/60336] empty struct value is passed differently in C and C++
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60336 --- Comment #19 from Jason Merrill jason at gcc dot gnu.org --- Created attachment 32228 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32228action=edit HJ's test in dejagnu form Here's HJ's testcase in a form that can be dropped into g++.dg/abi.
[Bug ada/16212] ICE ada/gcc-interface/trans.c:1626 on legal Ada 83 program
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16212 --- Comment #5 from nicolas.boulenguez at free dot fr --- 4.9.0 20140218 (experimental) [trunk rev 207856] (x86_64-linux-gnu) GCC error: in Case_Statement_to_gnu, at ada/gcc-interface/trans.c:2345 Error detected at test_106.adb:4:9
[Bug ada/16214] Legal program rejected, nested generic packages
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16214 --- Comment #3 from nicolas.boulenguez at free dot fr --- Found in 4.9-20140218
[Bug ada/17320] Illegal program not detected, RM 3.9.3(11)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17320 --- Comment #3 from nicolas.boulenguez at free dot fr --- Found in 4.9-20140218
[Bug ada/17321] Illegal program not detected, name hidden by use clauses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17321 --- Comment #3 from nicolas.boulenguez at free dot fr --- Found in 4.9-20140218
[Bug ada/16094] Illegal program not detected, RM 3.4.1(5)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16094 --- Comment #4 from nicolas.boulenguez at free dot fr --- found in 4.9-20140218
[Bug ada/17953] Illegal program not detected, RM 3.9.2(9)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17953 --- Comment #3 from nicolas.boulenguez at free dot fr --- Found in 4.9-20140218
[Bug ada/17954] Legal program rejected, packed array of booleans
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17954 --- Comment #3 from nicolas.boulenguez at free dot fr --- Found in 4.9-20140218
