[Bug debug/60643] ICE with -O1 and -g on mips (internal compiler error: in dwarf2out_var_location, at dwarf2out.c:20810)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60643 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #8 from Andrew Pinski pinskia at gcc dot gnu.org --- Works for me with an unmodified GCC 4.8.2. So please try removing all of the Open-embedded patches since one of them is causing this bug.
[Bug bootstrap/60644] New: [4.9 Regression] Build of i686-pc-linux-android is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60644 Bug ID: 60644 Summary: [4.9 Regression] Build of i686-pc-linux-android is broken Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: aivchenk at gmail dot com ../gcc_mainline/configure --target=i686-linux-android --disable-bootstrap --enable-languages=c,c++ --with-sysroot=[..]ndk/android-ndk-r9d/platforms/android-19/arch-x86 --disable-shared --disable-libitm --disable-libsanitizer make [..] ../../../gcc_mainline/libcilkrts/runtime/os-unix.c: In function ‘linux_gettid’: ../../../gcc_mainline/libcilkrts/runtime/os-unix.c:293:20: error: ‘SYS_gettid’ undeclared (first use in this function) return syscall(SYS_gettid); ^ ../../../gcc_mainline/libcilkrts/runtime/os-unix.c:293:20: note: each undeclared identifier is reported only once for each function it appears in ../../../gcc_mainline/libcilkrts/runtime/os-unix.c: In function ‘__cilkrts_yield’: ../../../gcc_mainline/libcilkrts/runtime/os-unix.c:419:5: warning: implicit declaration of function ‘pthread_yield’ [-Wimplicit-function-declaration] pthread_yield(); ^ make[2]: *** [os-unix.lo] Error 1 make[2]: *** Waiting for unfinished jobs mv -f .deps/spin_mutex.Tpo .deps/spin_mutex.Plo mv -f .deps/worker_mutex.Tpo .deps/worker_mutex.Plo mv -f .deps/stats.Tpo .deps/stats.Plo mv -f .deps/signal_node.Tpo .deps/signal_node.Plo mv -f .deps/symbol_test.Tpo .deps/symbol_test.Plo mv -f .deps/sysdep-unix.Tpo .deps/sysdep-unix.Plo make[2]: Leaving directory `/export/users/aivchenk/src/android_gcc_obj/i686-linux-android/libcilkrts' make[1]: *** [all-target-libcilkrts] Error 2 make[1]: Leaving directory `/export/users/aivchenk/src/android_gcc_obj' make: *** [all] Error 2
[Bug bootstrap/60644] [4.9 Regression] Build of i686-pc-linux-android is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60644 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- If SYS_gettid is not defined, then it is a bug in the bionic libc headers as NR_gettid is defined in the kernel headers. Also pthread_yield should be defined in pthread.h if it is not then it is again a bug in bionic. For no you can use --disable-libcilkrts as a workaround for bionic being broken.
[Bug bootstrap/60644] [4.9 Regression] Build of i686-pc-linux-android is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60644 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- Well pthread_yield should be replaced with the POSIX version: sched_yield() instead.
[Bug bootstrap/60644] [4.9 Regression] Build of i686-pc-linux-android is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60644 --- Comment #4 from Alexander Ivchenko aivchenk at gmail dot com --- That (In reply to Andrew Pinski from comment #2) Well pthread_yield should be replaced with the POSIX version: sched_yield() instead. Right.. the attached patch cured the build
[Bug bootstrap/60644] [4.9 Regression] Build of i686-pc-linux-android is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60644 --- Comment #3 from Alexander Ivchenko aivchenk at gmail dot com --- Created attachment 32443 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32443action=edit Renaming ANDROID to __ANDROID__
[Bug libstdc++/60645] New: locale::facet::_S_get_c_locale does not handle __gthread_once error codes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60645
Bug ID: 60645
Summary: locale::facet::_S_get_c_locale does not handle
__gthread_once error codes.
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: chris at contemporary dot net.au
RTEMS cannot use the posix thread model because the pthread_once call may
return an error code. The code libgcc/gthr-posix.h#696 returns an error yet
libstdc++-v3/src/c++98/locale.cc#209 does not check and handle the returned
error code.
The POSIX reference is:
http://pubs.opengroup.org/onlinepubs/009695399/functions/pthread_once.html
The code in question is ...
204 __c_locale
205 locale::facet::_S_get_c_locale()
206 {
207 #ifdef __GTHREADS
208 if (__gthread_active_p())
209 __gthread_once(_S_once, _S_initialize_once);
210 else
211 #endif
212 {
213 if (!_S_c_locale)
214 _S_initialize_once();
215 }
216 return _S_c_locale;
217 }
and ..
695 static inline int
696 __gthread_once (__gthread_once_t *__once, void (*__func) (void))
697 {
698 if (__gthread_active_p ())
699 return __gthrw_(pthread_once) (__once, __func);
700 else
701 return -1;
702 }
[Bug debug/60643] ICE with -O1 and -g on mips (internal compiler error: in dwarf2out_var_location, at dwarf2out.c:20810)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60643 --- Comment #10 from hongxu jia hongxu.jia at windriver dot com --- (In reply to Andrew Pinski from comment #8) Works for me with an unmodified GCC 4.8.2. So please try removing all of the Open-embedded patches since one of them is causing this bug. I have removed all of the Open-embedded patches, and cross-compiling mip-gcc on x86-64 host. But the problem still existed. //Hongxu
[Bug fortran/60646] New: Investigate improved complex division algorithms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60646 Bug ID: 60646 Summary: Investigate improved complex division algorithms Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jb at gcc dot gnu.org The paper http://arxiv.org/abs/1210.4539 analyzes several algorithms for complex division. Currently GFortran IIRC uses the Smith (1962) algorithm. We should investigate whether GFortran could switch to one of the improved algorithms without compromising performance too much.
[Bug c/45020] Useless DW_TAG_variable generated
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45020 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- I think this has been fixed in r182027 as a fix for PR51410. I tried all testcases mentioned here and see no duplicate DW_TAG_variables.
[Bug lto/60635] [4.8/4.9 Regression] ICE when mixing C and Fortran lto1: error: use operand missing for stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60635 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-03-25 Known to work||4.7.3 Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org Target Milestone|--- |4.8.3 Summary|ICE when mixing C and |[4.8/4.9 Regression] ICE |Fortran lto1: error: use|when mixing C and Fortran |operand missing for stmt|lto1: error: use operand ||missing for stmt Ever confirmed|0 |1 Known to fail||4.8.2, 4.9.0 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- I will have a look, works with 4.7.
[Bug sanitizer/60636] ubsan doesn't instrument signed integer ABS_EXPR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60636 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- We should instead instrument ABS_EXPR (you can instrument that as u 0 ? u : -u of course).
[Bug middle-end/60640] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60640 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug target/60641] Converting ushort to offset on x86_64 generates double movzwl
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60641 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target||x86_64-*-*, i?86-*-* Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-25 Component|tree-optimization |target Ever confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed on trunk and 4.8.
[Bug bootstrap/60644] [4.9 Regression] Build of i686-pc-linux-android is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60644 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug c++/60331] ICE with OpenMP #pragma omp declare reduction in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60331 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Tue Mar 25 09:30:10 2014 New Revision: 208806 URL: http://gcc.gnu.org/viewcvs?rev=208806root=gccview=rev Log: PR c++/60331 * semantics.c (potential_constant_expression_1): Handle DECL_EXPR. * testsuite/libgomp.c++/udr-11.C: New test. * testsuite/libgomp.c++/udr-12.C: New test. * testsuite/libgomp.c++/udr-13.C: New test. * testsuite/libgomp.c++/udr-14.C: New test. * testsuite/libgomp.c++/udr-15.C: New test. * testsuite/libgomp.c++/udr-16.C: New test. * testsuite/libgomp.c++/udr-17.C: New test. * testsuite/libgomp.c++/udr-18.C: New test. * testsuite/libgomp.c++/udr-19.C: New test. Added: trunk/libgomp/testsuite/libgomp.c++/udr-11.C trunk/libgomp/testsuite/libgomp.c++/udr-12.C trunk/libgomp/testsuite/libgomp.c++/udr-13.C trunk/libgomp/testsuite/libgomp.c++/udr-14.C trunk/libgomp/testsuite/libgomp.c++/udr-15.C trunk/libgomp/testsuite/libgomp.c++/udr-16.C trunk/libgomp/testsuite/libgomp.c++/udr-17.C trunk/libgomp/testsuite/libgomp.c++/udr-18.C trunk/libgomp/testsuite/libgomp.c++/udr-19.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/semantics.c trunk/libgomp/ChangeLog
[Bug c++/60331] ICE with OpenMP #pragma omp declare reduction in template class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60331 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.9.0 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Should be fixed now.
[Bug libstdc++/60645] locale::facet::_S_get_c_locale does not handle __gthread_once error codes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60645 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- The only error code specified by POSIX is EINVAL which cannot happen here, because the pthread_once_t is statically initialized and controlled entirely by the library.
[Bug libstdc++/60645] locale::facet::_S_get_c_locale does not handle __gthread_once error codes.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60645 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org --- Plus it is a question what to do if pthread_once fails, I mean, shall it just assume that no threads will be used and initialize without synchronization? Can't the initialization callback be already run when pthread_once fails?
[Bug lto/57703] Assembler function definition moved to a different ltrans then call
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57703 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added CC||jamborm at gcc dot gnu.org --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org --- I believe this could be dealt with by forcing all inline assembly from one compilation unit (including those which were inlined) to end up in one partition. If any of them defines a hidden symbol, the assembler will see it. This would of course probably be quite ugly hack to the partitioner. But perhaps we could only enable it by a switch and/or proceed only if there is a top level assembler in any particular compilation unit. I suppose definitions of symbols in non-top-level inline assembly is already fragile because functions can be inlined/cloned etc.
[Bug middle-end/60647] New: [4.8 Regression] ICE in visit_ref_for_mod_analysis, at ipa-prop.c:2112
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60647 Bug ID: 60647 Summary: [4.8 Regression] ICE in visit_ref_for_mod_analysis, at ipa-prop.c:2112 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Created attachment 32444 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32444action=edit preprocessed source seen with trunk r208764 on x86_64-linux-gnu. 4.8 branch works $ gcc -c -O2 -c dsdm.i dsdm.c: In function 'FreeDropSites': dsdm.c:535:2: warning: incompatible implicit declaration of built-in function 'free' free(next); ^ dsdm.c: In function 'WriteSiteRectList': dsdm.c:601:5: warning: incompatible implicit declaration of built-in function 'free' free(array); ^ dsdm.c: In function 'SubtractWindowFromVisibleRegion.isra.1': dsdm.c:790:1: internal compiler error: in visit_ref_for_mod_analysis, at ipa-prop.c:2112 } ^ Please submit a full bug report, with preprocessed source if appropriate.
[Bug ipa/59176] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59176 --- Comment #20 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Tue Mar 25 10:57:07 2014 New Revision: 208809 URL: http://gcc.gnu.org/viewcvs?rev=208809root=gccview=rev Log: 2014-03-25 Martin Jambor mjam...@suse.cz PR ipa/59176 * lto-cgraph.c (lto_output_node): Stream body_removed flag. (lto_output_varpool_node): Likewise. (input_overwrite_node): Likewise. (input_varpool_node): Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/lto-cgraph.c
[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025
__vic d.v.a at ngs dot ru changed:
What|Removed |Added
CC||d.v.a at ngs dot ru
--- Comment #23 from __vic d.v.a at ngs dot ru ---
Is it related bug?
struct C
{
const std::string st_ref;
explicit C(const std::string st) : st_ref{st}
{
std::cout st ' ' st_ref std::endl;
assert(st == st_ref);
}
};
assert() fires! gcc 4.8.2
If we replace st_ref{st} with st_ref(st), assert() doesn't fire.
[Bug c++/50025] [DR 1288] C++0x initialization syntax doesn't work for class members of reference type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50025 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0 --- Comment #24 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to __vic from comment #23) Is it related bug? Yes, the original C++11 rules required a temporary to be created there and the reference member binds to that temporary (which then goes out of scope). Your code works correctly with GCC 4.9
[Bug middle-end/60647] [4.8 Regression] ICE in visit_ref_for_mod_analysis, at ipa-prop.c:2112
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60647
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-03-25
CC||trippels at gcc dot gnu.org
Target Milestone|--- |4.9.0
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 tmp % cat test.i
struct _wincore
{
int y;
int width;
};
int a;
static fn1 (dpy, winInfo) struct _XDisplay *dpy;
struct _wincore *winInfo;
{
a = winInfo-width;
fn2 ();
}
static fn3 (dpy, winInfo, visrgn) struct _XDisplay *dpy;
{
int b = fn1 (0, winInfo);
fn4 (0, 0, visrgn);
}
fn5 (event) struct _XEvent *event;
{
fn3 (0, 0, 0);
}
markus@x4 tmp % gcc -O2 -c test.i
test.i: In function ‘fn3.isra.1’:
test.i:23:1: internal compiler error: in visit_ref_for_mod_analysis, at
ipa-prop.c:2112
[Bug middle-end/60647] [4.8 Regression] ICE in visit_ref_for_mod_analysis, at ipa-prop.c:2112
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60647 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Confirmed.
[Bug middle-end/60647] [4.8 Regression] ICE in visit_ref_for_mod_analysis, at ipa-prop.c:2112
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60647 --- Comment #3 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Richard, this started with r207879.
[Bug lto/60635] [4.8/4.9 Regression] ICE when mixing C and Fortran lto1: error: use operand missing for stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60635 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Tue Mar 25 11:43:03 2014 New Revision: 208811 URL: http://gcc.gnu.org/viewcvs?rev=208811root=gccview=rev Log: 2014-03-25 Richard Biener rguent...@suse.de PR middle-end/60635 * gimplify-me.c (gimple_regimplify_operands): Update the re-gimplifed stmt. * gfortran.dg/lto/pr60635_0.f90: New testcase. * gfortran.dg/lto/pr60635_1.c: Likewise. Added: trunk/gcc/testsuite/gfortran.dg/lto/pr60635_0.f90 trunk/gcc/testsuite/gfortran.dg/lto/pr60635_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/gimplify-me.c trunk/gcc/testsuite/ChangeLog
[Bug target/60648] New: [4.8 Regression] ICE (segmentation fault) in expand_binop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60648 Bug ID: 60648 Summary: [4.8 Regression] ICE (segmentation fault) in expand_binop Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Created attachment 32445 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32445action=edit preprocessed source seen with trunk r208764 on i686-linux-gnu, works on x86_64-linux-gnu, works with the 4.8 branch, can be worked around with -O2. $ gcc -O3 -fPIC -c vec.ii In file included from ../../../src/meep.hpp:23:0, from ../../../src/meep_internals.hpp:18, from ../../../src/vec.cpp:23: ../../../src/meep/vec.hpp: In function 'double (* meep::derived_component_func(meep::derived_component, const meep::grid_volume, int, meep::component*))(const std::complexdouble*, const meep::vec, void*)': ../../../src/meep/vec.hpp:325:3: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. Program received signal SIGSEGV, Segmentation fault. 0x084f5382 in expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*, int, optab_methods) () (gdb) bt #0 0x084f5382 in expand_binop(machine_mode, optab_tag, rtx_def*, rtx_def*, rtx_def*, int, optab_methods) () #1 0x083c1b6d in force_operand(rtx_def*, rtx_def*) () #2 0x083a6f1d in memory_address_addr_space(machine_mode, rtx_def*, unsigned char) () #3 0x083c2d96 in try_tablejump(tree_node*, tree_node*, tree_node*, tree_node*, rtx_def*, rtx_def*, int) () #4 0x08594c63 in ?? () #5 0x08596f25 in expand_case(gimple_statement_base*) () #6 0x0830a7a1 in ?? () #7 0x0830b5f8 in ?? () #8 0x0830d897 in ?? () #9 0x08506fc9 in execute_one_pass(opt_pass*) () #10 0x0850720f in execute_pass_list(opt_pass*) () #11 0x0832b4b8 in ?? () #12 0x0832cd6f in compile() () #13 0x0832d1c8 in finalize_compilation_unit() () #14 0x081eb3f1 in cp_write_global_declarations() () #15 0x085a0d25 in ?? () #16 0x085a28e6 in toplev_main(int, char**) () #17 0x081881cb in main ()
[Bug lto/60635] [4.8 Regression] ICE when mixing C and Fortran lto1: error: use operand missing for stmt
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60635 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P2 Known to work||4.9.0 Summary|[4.8/4.9 Regression] ICE|[4.8 Regression] ICE when |when mixing C and Fortran |mixing C and Fortran lto1: |lto1: error: use operand|error: use operand missing |missing for stmt|for stmt Known to fail|4.9.0 | --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk sofar.
[Bug sanitizer/60649] New: [ASAN] Bogus 'y' may be used uninitialized warning (affects bootstrap-asan)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60649 Bug ID: 60649 Summary: [ASAN] Bogus 'y' may be used uninitialized warning (affects bootstrap-asan) Product: gcc Version: 4.9.0 Status: UNCONFIRMED Keywords: build, diagnostic Severity: normal Priority: P3 Component: sanitizer Assignee: unassigned at gcc dot gnu.org Reporter: burnus at gcc dot gnu.org CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at gcc dot gnu.org Created attachment 32446 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32446action=edit C++ Test case (test.ii); compile as: g++ -O2 -fsanitize=address -Werror=maybe-uninitialized test.ii The following issue prevents bootstrapping GCC with --with-build-config=bootstrap-asan: gcc/explow.c:83:7: error: y may be used uninitialized in this function The reduced test case compiles warning free without ASAN, but with ASAN one gets: $ g++ -O2 -fsanitize=address -Werror=maybe-uninitialized test12.ii test12.ii: In function ‘rtx_def* plus_constant(machine_mode, rtx, long int)’: test12.ii:22:7: error: ‘y’ may be used uninitialized in this function [-Werror=maybe-uninitialized] rtx y; ^ cc1plus: some warnings being treated as errors
[Bug target/60648] [4.8 Regression] ICE (segmentation fault) in expand_binop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60648
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-03-25
CC||trippels at gcc dot gnu.org
Target Milestone|--- |4.9.0
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
markus@x4 tmp % cat test.ii
enum component
{
Ex,
Ez,
Hy,
Permeability
};
enum derived_component
{};
enum direction
{
X,
Y,
Z,
R,
P,
NO_DIRECTION
};
derived_component a;
component *b;
component c;
direction d;
inline direction fn1 (component p1)
{
switch (p1)
{
case 0:
return Y;
case 1:
return Z;
case Permeability:
return NO_DIRECTION;
}
return X;
}
inline component fn2 (direction p1)
{
switch (p1)
{
case 0:
case 1:
return component ();
case Z:
case R:
return component (1);
case P:
return component (3);
}
}
void fn3 ()
{
direction e;
switch (0)
case 0:
switch (a)
{
case 0:
c = Ex;
b[1] = Hy;
}
e = fn1 (b[1]);
b[1] = fn2 (e);
d = fn1 (c);
}
markus@x4 tmp % g++ -m32 -O2 -fPIC -c test.ii
test.ii: In function ‘void fn3()’:
test.ii:39:3: internal compiler error: Segmentation fault
switch (p1)
^
Please submit a full bug report,
[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60191 --- Comment #9 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Hmm, I debugged a bit and found this: the problem starts in gfc_get_function_type it is first called on sym-name = make_real, and then recursively again on the same sym. So this is a recursive_type. The first call returns a build_function_type_vec (with full parameter list) But the recursive call returns a build_varargs_function_type_vec (with a shorter parameter list) The problem is that these declarations are not identical: So in the case of arm with --float-abi=hard this has a somewhat surprising effect: Varargs functions return a float result in r0 Normal functions returns a float result in s0. If there were float arguments they would not be passed on FPU-Registers for varargs functions, but because fortran passes every in-parameter by reference that is not visible. However that may well be different for other targets, for instance, pass the declared parameters in registers, and pass everything after ... on stack.
[Bug testsuite/58013] main() not generated in assembler output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58013 --- Comment #4 from John David Anglin danglin at gcc dot gnu.org --- Author: danglin Date: Tue Mar 25 12:06:17 2014 New Revision: 208813 URL: http://gcc.gnu.org/viewcvs?rev=208813root=gccview=rev Log: PR testsuite/58013 * g++.dg/opt/pr56999.C: Pop hidden visibility. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/opt/pr56999.C
[Bug middle-end/60647] [4.8 Regression] ICE in visit_ref_for_mod_analysis, at ipa-prop.c:2112
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60647 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |rguenth at gcc dot gnu.org --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Oh, mine then.
[Bug testsuite/58013] main() not generated in assembler output
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58013 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #5 from John David Anglin danglin at gcc dot gnu.org --- Fixed.
[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60191 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code CC||burnus at gcc dot gnu.org --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Bernd Edlinger from comment #9) Varargs functions return a float result in r0 Normal functions returns a float result in s0. If there were float arguments they would not be passed on FPU-Registers for varargs functions, but because fortran passes every in-parameter by reference that is not visible. That sounds difficult to fix. gfortran currently generates when it does not know the explicit interface something like: float funct(...) which for normal functions can be updated via the use of the function a = funct(1.0) ! = one argument of type real. [This updated of the interface base on the usage is not yet implemented and some PR exists for this; I think it is PR44471.] The problem is with procedure pointers of the form procedure(real), pointer :: ptr Those can point to any function returning a real - and one can have different ones at different places in the program. - I have no idea how to solve this. [Note: Fortran does not support variadic arguments.] [Side note: Fortran also permits to use procedure(make_real),pointer, which provides the proper interface.]
[Bug middle-end/60647] [4.9 Regression] ICE in visit_ref_for_mod_analysis, at ipa-prop.c:2112
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60647
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
It's even wrong-code it seems. IPA SRA is confused about the KR style
functions and
static fn3 (dpy, winInfo, visrgn) struct _XDisplay *dpy;
{
int b = fn1 (0, winInfo);
fn4 (0, 0, visrgn);
}
winInfo having type 'int' here. Not sure how I exposed that with the
patch though ...
At least the testcase is broken. When I add a proper type to winInfo in fn3
it works.
Martin, do we want to guard IPA SRA against this sort of bogosities?
As of the actual transform it seems that IPA SRA misses to adjust accesses
when it removes unused params ;) (well, not actually unused ... heh)
That said, can you look into it? You are more familiar with IPA SRA and
where we'd add a sanity check that argument type and formal parameter type
match (and thus local analysis is valid).
[Bug rtl-optimization/60650] New: [ARM] LRA ICE assign_by_spills
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60650 Bug ID: 60650 Summary: [ARM] LRA ICE assign_by_spills Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization Assignee: unassigned at gcc dot gnu.org Reporter: yvan.roux at linaro dot org reported when building linux btrfs module. slightly reduced preprocessed test case attached. command line : cc1 -O2 -fno-omit-frame-pointer -mabi=apcs-gnu -march=armv7-a file-item.i cc1 outputs : In file included from /git/arm-soc/fs/btrfs/transaction.h:21:0, from /git/arm-soc/fs/btrfs/file-item.c:25: /git/arm-soc/fs/btrfs/btrfs_inode.h: In function ‘truncate_one_csum’: /git/arm-soc/fs/btrfs/btrfs_inode.h:214:1: internal compiler error: in assign_by_spills, at lra-assigns.c:1286 0x9ddf78 assign_by_spills /work/sources/gcc-fsf/trunk/gcc/lra-assigns.c:1286 0x9de921 lra_assign() /work/sources/gcc-fsf/trunk/gcc/lra-assigns.c:1444 0x9d865a lra(_IO_FILE*) /work/sources/gcc-fsf/trunk/gcc/lra.c:2370 0x98669b do_reload /work/sources/gcc-fsf/trunk/gcc/ira.c:5457 0x9869e4 rest_of_handle_reload /work/sources/gcc-fsf/trunk/gcc/ira.c:5598 0x986a2e execute /work/sources/gcc-fsf/trunk/gcc/ira.c:5627
[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60191 --- Comment #11 from Bernd Edlinger bernd.edlinger at hotmail dot de --- (In reply to Tobias Burnus from comment #10) gfortran currently generates when it does not know the explicit interface something like: float funct(...) note that: float funct(...) // this syntax is valid only in C++ returns the result in s0, because is not really considered a variadic while float funct(int, ...) uses FPU registers, at least on some ARM platforms. maybe the problem is only that gfc_get_function_type tries to give only a part of the parameter list to the back-end?
[Bug rtl-optimization/60650] [ARM] LRA ICE in assign_by_spills
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60650 --- Comment #1 from Yvan Roux yvan.roux at linaro dot org --- testcase is to big to be attached... reducing...
[Bug rtl-optimization/60651] New: Mode switching instructions are sometimes emitted in the wrong order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60651
Bug ID: 60651
Summary: Mode switching instructions are sometimes emitted in
the wrong order
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: amylaar at gcc dot gnu.org
Target: epiphany-*-*
As dicussed at
http://forums.parallella.org/viewtopic.php?f=13t=1053sid=2d28ee29b5dd3c591d947074f46ac752p=6654#p6654,
this code:
int a;
int c;
void __attribute__((interrupt))
misc_handler (void) {
a*= c;
}
Is compiled into code that uses an uninitialized register.
As it turns out, the interrupt attribute is actually a red herring (as long as
you use the default of (-mfp-mode=caller).
The problem is that, after emitting the mask-loading instruction, mode
switching emits the mode switch to the caller's mode which uses that mask
*before* the load of the mask, thus using the register uninitialized.
The mask loading instruction, thus rendered useless, is later deleted.
The things with lcm is that we have an algorithm that can be a bit expensive,
but we can process multiple entities at almost no extra cost.
The epiphany needs to load constants to do its mode switching; these constants
can be anticipated further up in the dominance graph. This can be modelled
as having a different entity for each mask needed, the need for which is
indicated at the same point as the mode switch itself. Because the mask
load entities are not subject to transparency issues (except in the unfortunate
case of abnormal edges), lcm can move the loads up in suitable dominator
positions.
The modes priorities on the epiphany are also such that the mask loads have a
mode with the same or higher priority as the mask uses.
Also, the mask loads have lowered numbered entities than the mask uses.
As the lcm part of optimize_mode_switching inserts, for each priority, the
mode setting in ascending order of entities, and insert_insn_on_edge
appends to the currently registered sequence, this works find there.
The segment-based code also preserves entity order when inserting before an
instruction.
However, when inserting after a basic block head, later inserted mode
switch instructions end up prior to ones earlier inserted into the insn
stream.
To preserve the order, in the case of an initially empty basic block,
what we have to do is append the new instructions at the end of the basic
block.
[Bug target/60648] [4.9 Regression] ICE (segmentation fault) in expand_binop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60648 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added CC||law at gcc dot gnu.org --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Started with r205074.
[Bug rtl-optimization/60651] Mode switching instructions are sometimes emitted in the wrong order
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60651 --- Comment #1 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- Created attachment 32447 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32447action=edit patch The attached patch implements this aforementioned insertion at the end of an (initially) empty basic block. I'm currently bootstrapping/regtesting this on i686-pc-linux-gnu
[Bug target/60648] [4.9 Regression] ICE (segmentation fault) in expand_binop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60648 --- Comment #3 from Jeffrey A. Law law at redhat dot com --- We're getting non-canonical as part of the index computation in do_tablejump: (gdb) p debug_rtx (index) (plus:SI (mult:SI (const_int 0 [0]) (const_int 4 [0x4])) (label_ref:SI 0)) Obviously memory_address and its children aren't prepared to deal with the non-canonical RTL. Not sure what this has to do with threading, other than perhaps threading exposing 0 as the index
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #38 from John David Anglin danglin at gcc dot gnu.org --- gfortran.dg/fmt_en.f90 tests fail on hppa*-*-hpux11* (4.8 and 4.9): (en15.0) 9.E+03 expected: 10.E+03 (en15.0) 9.E+03 expected: 10.E+03 (en15.1) 9.9E+03 expected: 10.0E+03 (en15.1) 9.9E+03 expected: 10.0E+03 (en15.0) -9.E+03 expected: -10.E+03 (en15.0) -9.E+03 expected: -10.E+03 (en15.1)-9.9E+03 expected:-10.0E+03 (en15.1)-9.9E+03 expected:-10.0E+03 (en15.1) 987.3E+03 expected:987.4E+03 (en15.1) 987.3E+03 expected:987.4E+03 (en15.1) 987.7E+03 expected:987.6E+03 (en15.2) 98.77E+03 expected:98.76E+03 (en15.2) 98.77E+03 expected:98.76E+03 (en15.2) 98.77E+03 expected:98.76E+03 (en15.3) 9.877E+03 expected:9.876E+03 (en15.1)31.3E-03 expected: 31.2E-03 (en15.2) 15.63E-03 expected:15.62E-03 (en15.3) 7.813E-03 expected:7.812E-03 (en15.3) 976.563E-06 expected: 976.562E-06 (en15.1) -987.3E+03 expected: -987.4E+03 (en15.1) -987.3E+03 expected: -987.4E+03 (en15.1) -987.7E+03 expected: -987.6E+03 (en15.2) -98.77E+03 expected: -98.76E+03 (en15.2) -98.77E+03 expected: -98.76E+03 (en15.2) -98.77E+03 expected: -98.76E+03 (en15.3) -9.877E+03 expected: -9.876E+03 (en15.1) -31.3E-03 expected:-31.2E-03 (en15.2) -15.63E-03 expected: -15.62E-03 (en15.3) -7.813E-03 expected: -7.812E-03 (en15.3)-976.563E-06 expected: -976.562E-06 This is with quad16.
[Bug target/60648] [4.9 Regression] ICE (segmentation fault) in expand_binop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60648 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #4 from Jeffrey A. Law law at redhat dot com --- Potential fix in testing.
[Bug middle-end/60640] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60640 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-03-25 Assignee|unassigned at gcc dot gnu.org |jamborm at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Martin Jambor jamborm at gcc dot gnu.org --- Confirmed, mine.
[Bug target/60653] New: [4.9 Regression] gfortran: ICE (segmentation fault) in lra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60653 Bug ID: 60653 Summary: [4.9 Regression] gfortran: ICE (segmentation fault) in lra Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org seen on arm-linux-gnueabihf, trunk r208764 (gdb) bt #0 0x0031aca6 in ?? () #1 0x0031bf30 in ?? () #2 0x0031e990 in ?? () #3 0x00320824 in lra_constraints(bool) () #4 0x00315c40 in lra(_IO_FILE*) () #5 0x002ea520 in ?? () #6 0x003551ba in execute_one_pass(opt_pass*) () #7 0x00355340 in execute_pass_list(opt_pass*) () #8 0x0035534a in execute_pass_list(opt_pass*) () #9 0x0020224c in ?? () #10 0x00203464 in compile() () #11 0x002037f0 in finalize_compilation_unit() () #12 0x00307596 in write_global_declarations() () #13 0x003c558c in ?? () #14 0x003c6cb0 in toplev_main(int, char**) () #15 0xb6d76632 in __libc_start_main () from /lib/arm-linux-gnueabihf/libc.so.6 #16 0x0010a868 in _start () $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.9/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9-20140322-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 4.9.0 20140322 (experimental) [trunk revision 208764] (Ubuntu 4.9-20140322-1ubuntu1)
[Bug fortran/60128] [4.8/4.9 Regression] Wrong ouput using en edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60128 --- Comment #39 from Dominique d'Humieres dominiq at lps dot ens.fr --- gfortran.dg/fmt_en.f90 tests fail on hppa*-*-hpux11* (4.8 and 4.9): ... After r208780 (for 4.9, not backported yet to 4.8)?
[Bug target/60653] [4.9 Regression] gfortran: ICE (segmentation fault) in lra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60653 --- Comment #1 from Matthias Klose doko at gcc dot gnu.org --- fails with -O1 and -O2, works with -O0. fails with both -marm/-mthumb
[Bug target/60653] [4.9 Regression] gfortran: ICE (segmentation fault) in lra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60653 --- Comment #2 from Matthias Klose doko at gcc dot gnu.org --- seen with a build of the paw package in Debian/unstable and Ubuntu/trusty.
[Bug rtl-optimization/60650] [ARM] LRA ICE in assign_by_spills
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60650 --- Comment #2 from Yvan Roux yvan.roux at linaro dot org --- Created attachment 32449 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32449action=edit reduced testcase
[Bug bootstrap/60644] [4.9 Regression] Build of i686-pc-linux-android is broken
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60644 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Patches (once tested) should be posted to gcc-patches. Please CC Balaji.
[Bug fortran/60646] Investigate improved complex division algorithms
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60646
kargl at gcc dot gnu.org changed:
What|Removed |Added
CC||kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
Janne,
Can you be a little more specific on what you want
to investigate? AFAIK, the general handling of
complex division is done be the middle-end.
% cat l.f90
subroutine loo(z1,z2,z3)
complex z1, z2, z3
z3 = z1 / z2
end subroutine loo
% gfc4x -fdump-tree-all -c l.f90
% ls l.f90.*
l.f90.003t.original l.f90.018t.einline
l.f90.004t.gimple l.f90.033t.profile_estimate
l.f90.006t.omplower l.f90.036t.release_ssa
l.f90.007t.lowerl.f90.037t.inline_param2
l.f90.010t.eh l.f90.161t.veclower
l.f90.011t.cfg l.f90.162t.cplxlower0
l.f90.015t.ssa l.f90.169t.optimized
l.f90.017t.inline_param1l.f90.249t.statistics
l.f90.cplxlower0 is definitely coming from the
middle-end.
The Fortran front-end will perform constant-folding.
% cat k.f90
subroutine lu(z)
complex z
complex, parameter :: a = (1,2), b=(3,4)
z = a/b
end subroutine lu
% cat k.f90.003t.original
lu (complex(kind=4) restrict z)
{
*z=__complex__(4.3997615814208984375e-1,7.99821186065673828125e-2);
}
Note, the front-end takes advantage of MPFR to do the folding, and so
it should yield an accurate result.
[Bug ada/60652] New: System.OS_Constants CRTSCTS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60652 Bug ID: 60652 Summary: System.OS_Constants CRTSCTS Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: robert.samuelsson at sscspace dot com The value of CRTSCTS in adainclude/s-oscons.ads is different to the value i have in /usr/include/bits/termios.h on my Linux system. adainclude/s-oscons.ads CRTSCTS : constant := 4294967295; -- Output hw flow control Hex: Dec: 4294967295 Oct: 377 Bin: (looks more like a mask than a flag) bits/termios.h #define CRTSCTS 0200 /* flow control */ Hex: 8000 Dec: 2147483648 Oct: 200 Bin: 1000 (ah, a bit-flag as expected) So I suspect there may be a problem with the autogenerator and octal numbers. I do not know if any other generated constants have similar problems.
[Bug c/60654] New: format warnings don't work with PROGMEM/PSTR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60654
Bug ID: 60654
Summary: format warnings don't work with PROGMEM/PSTR
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: code at dawg dot eu
Target: avr
cat bug.d CODE
#include avr/pgmspace.h
void foo(PGM_P fmt, ...) __attribute__((format(printf, 1, 2)));
void foo(PGM_P fmt, ...)
{
}
void main()
{
foo(PSTR(foobar), 12); // broken
foo(foobar, 12); // works
}
CODE
avr-gcc -mmcu=atmega8 -Wformat -c format.c
[Bug target/60655] New: [4.9 Regression] ICE: output_operand: invalid expression as operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655 Bug ID: 60655 Summary: [4.9 Regression] ICE: output_operand: invalid expression as operand Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Created attachment 32450 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32450action=edit preprocessed source seen with trunk r208764, omitting -fdata-sections works around it $ gcc -c -g -O2 -fdata-sections mpilib.i mpilib.c:1938:1: internal compiler error: output_operand: invalid expression as operand Please submit a full bug report, with preprocessed source if appropriate. $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.9/lto-wrapper Target: arm-linux-gnueabihf Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9-20140322-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-armhf --with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions --with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb --disable-werror --enable-multilib --enable-checking=release --build=arm-linux-gnueabihf --host=arm-linux-gnueabihf --target=arm-linux-gnueabihf Thread model: posix gcc version 4.9.0 20140322 (experimental) [trunk revision 208764] (Ubuntu 4.9-20140322-1ubuntu1)
[Bug tree-optimization/60656] New: [4.8/4.9 regression] x86 vectorization produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60656
Bug ID: 60656
Summary: [4.8/4.9 regression] x86 vectorization produces wrong
code
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Current trunk (r208813) and gcc-4.8 are affected, 4.7 does not appear to be.
gcc -O0 t.c ./a.out
500450210036
gcc -O3 t.c ./a.out
500450200033
gcc -O2 t.c ./a.out
500450210036
gcc -O2 t.c -ftree-vectorize ./a.out
500450200033
// t.c
#include stdio.h
int
main ()
{
int v[] = {5000, 5001, 5002, 5003};
long s = 0;
int i;
for(i = 0; i 4; ++i)
{
long P = v[i];
s += P*P*P;
}
printf(%ld\n, s);
}
[Bug target/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Created attachment 32451 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32451action=edit reduced testcase hmm -g -fdata-sections -mthumb is enough to provoke this at v7-a level of the architecture with either vfpv3-d16 or neon. -g and -fdata-sections appear to be the key here.
[Bug target/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-25 Target Milestone|--- |4.9.0 Ever confirmed|0 |1
[Bug c/37428] GNU VLA-in-structure extension is undocumented
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37428 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- I posted a patch.
[Bug target/60609] [4.8/4.9 Regression] Error: value of 256 too large for field of 1 bytes at 68242
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60609 Charles Baylis charles.baylis at linaro dot org changed: What|Removed |Added CC||charles.baylis at linaro dot org --- Comment #4 from Charles Baylis charles.baylis at linaro dot org --- I am working on this
[Bug target/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- The expression being put out is : (const:SI (not:SI (symbol_ref:SI (*.LANCHOR0) [flags 0x182]))) #0 0x003105033410 in exit () from /lib64/libc.so.6 #1 0x011c56b8 in diagnostic_action_after_output (context=0x1a6d080, diagnostic=0x7fffc110) at /work/wa1/src/gcc/gcc/diagnostic.c:487 #2 0x011c6615 in diagnostic_report_diagnostic (context=0x1a6d080, diagnostic=0x7fffc110) at /work/wa1/src/gcc/gcc/diagnostic.c:804 #3 0x011c75a1 in internal_error (gmsgid=0x12c6ad6 %s) at /work/wa1/src/gcc/gcc/diagnostic.c:1136 #4 0x007f2342 in output_operand_lossage (cmsgid=0x12c6bb6 invalid expression as operand) at /work/wa1/src/gcc/gcc/final.c:3368 #5 0x007f3656 in output_addr_const (file=0x1a73970, x=0x2ae0e290) at /work/wa1/src/gcc/gcc/final.c:3962 #6 0x007f32e9 in output_addr_const (file=0x1a73970, x=0x2ae0e2b0) at /work/wa1/src/gcc/gcc/final.c:3884 #7 0x00750035 in dw2_assemble_integer (size=4, x=0x2ae0e2b0) at /work/wa1/src/gcc/gcc/dwarf2asm.c:53 #8 0x007507fa in dw2_asm_output_addr_rtx (size=4, addr=0x2ae0e2b0, comment=0x0) at /work/wa1/src/gcc/gcc/dwarf2asm.c:279 #9 0x0075d86c in output_loc_operands (loc=0x2ae2d1e0, for_eh_or_skip=-1) at /work/wa1/src/gcc/gcc/dwarf2out.c:1954 #10 0x0075dea6 in output_loc_sequence (loc=0x2ae2d1e0, for_eh_or_skip=-1) at /work/wa1/src/gcc/gcc/dwarf2out.c:2127 #11 0x0076782a in output_loc_list (list_head=0x2ae25e40) at /work/wa1/src/gcc/gcc/dwarf2out.c:8414 #12 0x00765d9f in output_location_lists (die=0x2ae1aeb0) at /work/wa1/src/gcc/gcc/dwarf2out.c:7462 #13 0x00765deb in output_location_lists (die=0x2ae1ae60) at /work/wa1/src/gcc/gcc/dwarf2out.c:7464 #14 0x00765deb in output_location_lists (die=0x2ae1a5f0) at /work/wa1/src/gcc/gcc/dwarf2out.c:7464 #15 0x00765deb in output_location_lists (die=0x2ab219b0) at /work/wa1/src/gcc/gcc/dwarf2out.c:7464 #16 0x00790569 in dwarf2out_finish (filename=0x7fffd0d3 /home/ramrad01/reduced.c) at /work/wa1/src/gcc/gcc/dwarf2out.c:24304 #17 0x00b1b63b in compile_file () at /work/wa1/src/gcc/gcc/toplev.c:599 #18 0x00b1d712 in do_compile () at /work/wa1/src/gcc/gcc/toplev.c:1914 #19 0x00b1d87d in toplev_main (argc=9, argv=0x7fffcc38) at /work/wa1/src/gcc/gcc/toplev.c:1990 #20 0x011b24e4 in main (argc=9, argv=0x7fffcc38) at /work/wa1/src/gcc/gcc/main.c:36
[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Component|target |debug --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- (note 205 204 206 (var_location r2 (plus:SI (plus:SI (reg:SI 3 r3 [orig:192 ivtmp.37 ] [192]) (symbol_ref:SI (*.LANCHOR1) [flags 0x182])) (const:SI (not:SI (symbol_ref:SI (*.LANCHOR0) [flags 0x182]) NOTE_INSN_VAR_LOCATION) Comes from vartracking. Ramana
[Bug debug/60655] [4.9 Regression] ICE: output_operand: invalid expression as operand
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60655 --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Command lines I was using to reproduce this with a cross compiler. ./cc1 -g -mthumb -fdata-sections -mfpu=vfpv3-d16 -mfloat-abi=hard -O2 -march=armv7-a
[Bug rtl-optimization/60650] [ARM] LRA ICE in assign_by_spills
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60650 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-25 CC||ramana at gcc dot gnu.org Target Milestone|--- |4.9.0 Ever confirmed|0 |1 --- Comment #3 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Confirmed.
[Bug fortran/60191] test case gfortran.dg/dynamic_dispatch_1/3.f03 fail on ARMv7
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60191 --- Comment #12 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 32448 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32448action=edit possible fix Ok, the attached patch seems to fix at least the dynamic_dispatch_X.f03 test cases on ARMv7 with float-abi=hard. No regressions on X86_64 so far. I will run the ARMv7 test suite over the next days.
[Bug c/28575] misleading __builtin_choose_expr documentation error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28575 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org --- This was fixed in r163675.
[Bug target/60657] New: [4.9 Regression] ICE: error: insn does not satisfy its constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657
Bug ID: 60657
Summary: [4.9 Regression] ICE: error: insn does not satisfy its
constraints
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: doko at gcc dot gnu.org
Created attachment 32452
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32452action=edit
preprocessed source
seen with trunk r208764 on arm-linux-gnueabihf, works with 4.8 branch.
$ g++ -std=c++11 -c -g -O2 wide_posix_api.ii
In file included from ext/boost/regex/v4/regex.hpp:73:0,
from ext/boost/regex.hpp:31,
from ext/boost/libs/regex/src/wide_posix_api.cpp:25:
ext/boost/regex/v4/basic_regex_parser.hpp: In member function 'bool
boost::re_detail::basic_regex_parsercharT, traits::parse_extended_escape()
[with charT = wchar_t; traits = boost::c_regex_traitswchar_t]':
ext/boost/regex/v4/basic_regex_parser.hpp:910:1: error: insn does not satisfy
its constraints:
}
^
(insn 3014 3013 3015 227 (set (reg:SI 788 [ D.215148 ])
(zero_extract:SI (reg:SI 786 [ this_35(D)-D.157694.m_backrefs ])
(const_int 1 [0x1])
(const_int [0x270f])))
ext/boost/regex/v4/basic_regex_parser.hpp:876 149 {extzv_t2}
(expr_list:REG_DEAD (reg:SI 786 [ this_35(D)-D.157694.m_backrefs ])
(nil)))
ext/boost/regex/v4/basic_regex_parser.hpp:910:1: internal compiler error: in
extract_constrain_insn_cached, at recog.c:2156
Please submit a full bug report,
with preprocessed source if appropriate.
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/arm-linux-gnueabihf/4.9/lto-wrapper
Target: arm-linux-gnueabihf
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
4.9-20140322-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs
--enable-languages=c,c++,java,go,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.9 --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls
--with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap
--disable-libitm --disable-libquadmath --enable-plugin --with-system-zlib
--disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo
--with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf/jre --enable-java-home
--with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-armhf
--with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-armhf
--with-arch-directory=arm --with-ecj-jar=/usr/share/java/eclipse-ecj.jar
--enable-objc-gc --enable-multiarch --enable-multilib --disable-sjlj-exceptions
--with-arch=armv7-a --with-fpu=vfpv3-d16 --with-float=hard --with-mode=thumb
--disable-werror --enable-multilib --enable-checking=release
--build=arm-linux-gnueabihf --host=arm-linux-gnueabihf
--target=arm-linux-gnueabihf
Thread model: posix
gcc version 4.9.0 20140322 (experimental) [trunk revision 208764] (Ubuntu
4.9-20140322-1ubuntu1)
[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657 --- Comment #1 from Matthias Klose doko at gcc dot gnu.org --- seen with every package using this boost header
[Bug c/35449] extended asm documentation wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35449 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-03-25 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Missing colon was added in r195471, but the r != result issue is still there. Will fix.
[Bug target/60653] [4.9 Regression] gfortran: ICE (segmentation fault) in lra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60653 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Matthias Klose from comment #2) seen with a build of the paw package in Debian/unstable and Ubuntu/trusty. Cf. https://packages.debian.org/sid/paw and http://paw.web.cern.ch/paw/
[Bug c/35449] extended asm documentation wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35449 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- Author: mpolacek Date: Tue Mar 25 16:50:54 2014 New Revision: 208815 URL: http://gcc.gnu.org/viewcvs?rev=208815root=gccview=rev Log: PR c/35449 * doc/extend.texi (Example of asm with clobbered asm reg): Fix typo. Modified: trunk/gcc/ChangeLog trunk/gcc/doc/extend.texi
[Bug c/35449] extended asm documentation wrong
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35449 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed.
[Bug tree-optimization/59121] [4.8/4.9 Regression] endless loop with -O2 -floop-parallelize-all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121 --- Comment #17 from Mircea Namolaru mircea.namolaru at inria dot fr --- Yes, data dependencies computation is expensive in the polyehdral model and it could take considerable time - but it is worrying that in too many cases fails to provide (after a few hours left running, when I stop it) an answer for very simple programs. I will ckeck with the isl people if this is the expected behaviour of the isl_union_map_compute_flow (this is the function where the data dependency computation is stuck) and how (and if) they could help us. Many Fortran programs with loops having no-constants bounds and n-dimensional arrays (n=3) may be affected by this problem and may work only for small dimensions of the arrays. The problem touches especially Fortran, that uses linearized accesses to multi-dimensional arrays - this creates patterns leading to this problem (in this example we have an array acc of dimension 55,48,49 and the array access acc(j,k,l) is transformed to acc(j + 55*k + 2640*l). I've checked the constraints passed to isl_union_map_compute - see that wrapping is perfromed. But wrapping requires modulo operation, expressed by constraints with existential quantifier that may be harder to solve. By disabling the wrapping, some simple examples that before were stuck in data dependency computation finish immediately. In what measure is wrapping necessary ? - as a side-effect it may increase compilation time (that may be already considerable).
[Bug libstdc++/60658] New: std::atomicT* is unexpectedly not lock-free
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60658
Bug ID: 60658
Summary: std::atomicT* is unexpectedly not lock-free
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: ppluzhnikov at google dot com
Using current trunk (r208813):
g++ -std=c++11 atomic.cc -latomic ./a.out
a.out: atomic.cc:20: int main(): Assertion `b.is_lock_free()' failed.
As far as I can tell, this is happening because
std::__atomic_baseBar*::_M_type_size()
returns sizeof(Bar) instead of returning sizeof(Bar*).
// atomic.cc
#include atomic
#include assert.h
struct Foo {
char buf[1];
};
struct Bar {
char buf[100];
};
int
main ()
{
std::atomicFoo* a;
assert (a.is_lock_free());
std::atomicBar* b;
assert (b.is_lock_free());
}
Google ref: b/13626319
[Bug target/60653] [4.9 Regression] gfortran: ICE (segmentation fault) in lra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60653 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Do you have preprocessed source and command line options?
[Bug tree-optimization/59121] [4.8/4.9 Regression] endless loop with -O2 -floop-parallelize-all
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59121 --- Comment #18 from Tobias Grosser grosser at gcc dot gnu.org --- (In reply to Mircea Namolaru from comment #17) Yes, data dependencies computation is expensive in the polyehdral model and it could take considerable time - but it is worrying that in too many cases fails to provide (after a few hours left running, when I stop it) an answer for very simple programs. I will ckeck with the isl people if this is the expected behaviour of the isl_union_map_compute_flow (this is the function where the data dependency computation is stuck) and how (and if) they could help us. I would like to state that data-dependence calculation is not inherently more complex in the polyhedral mode. In fact, any simple data-dependence test that exists could be implemented in our polyhedral checker to speed up the common case if really necessary. We did not do this, as for such simple cases the dependence analysis is normally very fast. In the general case, dependence solving is inherently complex (equivalent to ILP programming - NP-complete), and we can not do better anyway. Though for the most cases of slowdown, we could probably do better. For this it is necessary to understand why a certain case is slow. Hence, it is important to look into the dependence problem we are trying to solve and see why we can not solve it quickly. The problem may be inherently complex, but there may also be a simple fix. Many Fortran programs with loops having no-constants bounds and n-dimensional arrays (n=3) may be affected by this problem and may work only for small dimensions of the arrays. The problem touches especially Fortran, that uses linearized accesses to multi-dimensional arrays - this creates patterns leading to this problem (in this example we have an array acc of dimension 55,48,49 and the array access acc(j,k,l) is transformed to acc(j + 55*k + 2640*l). So what exactly makes the problem difficult? Without understanding this, it is very difficult to predict in which situations the dependence analysis will be slow. I've checked the constraints passed to isl_union_map_compute You mean isl_union_map_compute_flow() - see that wrapping is perfromed. But wrapping requires modulo operation, expressed by constraints with existential quantifier that may be harder to solve. This is an interesting observation. Instead of modeling the modulo wrapping, we could assume it does not exist and just add a run-time check around the kernel that ensures that we only execute kernels where we know this is the case. By disabling the wrapping, some simple examples that before were stuck in data dependency computation finish immediately. Nice. In what measure is wrapping necessary ? - as a side-effect it may increase compilation time (that may be already considerable). In some cases additions/multiplications have defined the semantics in case of overflow as the computation being performed modulo the size of the type. This case rarely happens, but in case we want to be correct, we can not just ignore it. Cheers, Tobias
[Bug target/60659] New: [4.9 Regression] ICE in get_polymorphic_call_info, at ipa-devirt.c:1292
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60659 Bug ID: 60659 Summary: [4.9 Regression] ICE in get_polymorphic_call_info, at ipa-devirt.c:1292 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: doko at gcc dot gnu.org Created attachment 32453 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32453action=edit preprocessed source seen with trunk r208764 on powerpc64le-linux-gnu, works with the 4.8 ibm branch (which is pending the merge to the 4.8 fsf branch) $ g++ -c -O2 script.ii In file included from /usr/include/c++/4.9/bits/stl_algobase.h:66:0, from /usr/include/c++/4.9/memory:62, from src/mlib/ptr.h:25, from src/mbase/project/_extlibs_.h:36, from src/mgui/_extlibs_.h:31, from src/mgui/_pc_.h:29, from src/mgui/author/script.cpp:22: /usr/include/c++/4.9/bits/stl_iterator_base_funcs.h: In function 'typename std::iterator_traits_Iterator::difference_type std::__distance(_InputIterator, _InputIterator, std::input_iterator_tag) [with _InputIterator = adobe::iterboost::intrusive_ptrProject::VideoMD, boost::intrusive_ptrProject::VideoMD, long int; typename std::iterator_traits_Iterator::difference_type = long int]': /usr/include/c++/4.9/bits/stl_iterator_base_funcs.h:82:4: internal compiler error: in get_polymorphic_call_info, at ipa-devirt.c:1292 ++__first; ^ Please submit a full bug report, with preprocessed source if appropriate. $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc64le-linux-gnu/4.9/lto-wrapper Target: powerpc64le-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Ubuntu 4.9-20140322-1ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.9/README.Bugs --enable-languages=c,c++,java,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.9 --enable-shared --enable-linker-build-id --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.9 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --disable-libmudflap --disable-libsanitizer --disable-libquadmath --enable-plugin --with-system-zlib --disable-browser-plugin --enable-java-awt=gtk --enable-gtk-cairo --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-4.9-ppc64el/jre --enable-java-home --with-jvm-root-dir=/usr/lib/jvm/java-1.5.0-gcj-4.9-ppc64el --with-jvm-jar-dir=/usr/lib/jvm-exports/java-1.5.0-gcj-4.9-ppc64el --with-arch-directory=ppc64el --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --enable-objc-gc --enable-secureplt --with-cpu=power7 --with-tune=power8 --disable-multilib --enable-multiarch --disable-werror --with-long-double-128 --enable-checking=release --build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu Thread model: posix gcc version 4.9.0 20140322 (experimental) [trunk revision 208764] (Ubuntu 4.9-20140322-1ubuntu1)
[Bug c++/60375] [4.9 Regression] [c++11] ICE with invalid use of lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60375 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Mar 25 18:00:37 2014 New Revision: 208817 URL: http://gcc.gnu.org/viewcvs?rev=208817root=gccview=rev Log: PR c++/60375 * parser.c (cp_parser_lambda_expression): Don't parse the body of a lambda in unevaluated context. Added: trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-uneval2.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/parser.c trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-uneval.C
[Bug c++/60628] [4.7/4.8/4.9 Regression] [c++11] ICE initializing array of auto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60628 --- Comment #1 from Jason Merrill jason at gcc dot gnu.org --- Author: jason Date: Tue Mar 25 18:00:30 2014 New Revision: 208816 URL: http://gcc.gnu.org/viewcvs?rev=208816root=gccview=rev Log: PR c++/60628 * decl.c (create_array_type_for_decl): Complain about array of auto. Added: trunk/gcc/testsuite/g++.dg/cpp0x/auto42.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/decl.c
[Bug target/60653] [4.9 Regression] gfortran: ICE (segmentation fault) in lra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60653 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- /usr/lib/gcc/arm-linux-gnueabihf/4.9/f951 /paw-2.14.04.dfsg.2/src/pawlib/comis/code/csintx.F -ffixed-form -cpp=csintx.f90 -quiet -v -I /paw-2.14.04.dfsg.2/build/pawlib/comis -I /paw-2.14.04.dfsg.2/src/pawlib/comis -I /paw-2.14.04.dfsg.2/src/pawlib/comis/code -I /paw-2.14.04.dfsg.2/src/include -imultiarch arm-linux-gnueabihf -D _FORTIFY_SOURCE=2 -D CERNLIB_LINUX -D CERNLIB_UNIX -D CERNLIB_LNX -D CERNLIB_QMGLIBC -D CERNLIB_VERBOSE -D CERNLIB_DEBIAN -D DEBIAN_VERSION=1:2.14.04.dfsg.2-9 -D CERNLIB_QGETCWD -D _GNU_SOURCE -D CERNLIB_GFORTRAN /paw-2.14.04.dfsg.2/src/pawlib/comis/code/csintx.F -quiet -dumpbase csintx.F -march=armv7-a -mfloat-abi=hard -mfpu=vfpv3-d16 -mthumb -mtls-dialect=gnu -auxbase-strip archive/csintx.o -g -O2 -version -fno-range-check -fno-second-underscore -fstack-protector -fno-automatic --param ssp-buffer-size=4 -fintrinsic-modules-path /usr/lib/gcc/arm-linux-gnueabihf/4.9/finclude -o csintx.s GNU Fortran (Ubuntu 4.9-20140322-1ubuntu1) version 4.9.0 20140322 (experimental) [trunk revision 208764] (arm-linux-gnueabihf) compiled by GNU C version 4.9.0 20140322 (experimental) [trunk revision 208764], GMP version 5.1.3, MPFR version 3.1.2-p3, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 ignoring nonexistent directory /usr/local/include/arm-linux-gnueabihf ignoring nonexistent directory /usr/lib/gcc/arm-linux-gnueabihf/4.9/../../../../arm-linux-gnueabihf/include #include ... search starts here: #include ... search starts here: /paw-2.14.04.dfsg.2/build/pawlib/comis /paw-2.14.04.dfsg.2/src/pawlib/comis /paw-2.14.04.dfsg.2/src/pawlib/comis/code /paw-2.14.04.dfsg.2/src/include /usr/lib/gcc/arm-linux-gnueabihf/4.9/finclude /usr/lib/gcc/arm-linux-gnueabihf/4.9/include /usr/local/include /usr/lib/gcc/arm-linux-gnueabihf/4.9/include-fixed /usr/include/arm-linux-gnueabihf /usr/include End of search list. GNU Fortran (Ubuntu 4.9-20140322-1ubuntu1) version 4.9.0 20140322 (experimental) [trunk revision 208764] (arm-linux-gnueabihf) compiled by GNU C version 4.9.0 20140322 (experimental) [trunk revision 208764], GMP version 5.1.3, MPFR version 3.1.2-p3, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 /paw-2.14.04.dfsg.2/src/pawlib/comis/code/csintx.F:681.72: 7402 ASSIGN 7406 TO LAB1 1 Warning: Deleted feature: ASSIGN statement at (1) /paw-2.14.04.dfsg.2/src/pawlib/comis/code/csintx.F:704.72: GO TO LAB1 1 Warning: Deleted feature: Assigned GOTO statement at (1) /paw-2.14.04.dfsg.2/src/pawlib/comis/code/csintx.F:752.72: ASSIGN 8003 TO LAB1 1 Warning: Deleted feature: ASSIGN statement at (1) /paw-2.14.04.dfsg.2/src/pawlib/comis/code/csintx.F: In function 'csintx': /paw-2.14.04.dfsg.2/src/pawlib/comis/code/csintx.F:1920:0: internal compiler error: Segmentation fault END ^ Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.9/README.Bugs for instructions. However if I try the same with csint.f90 that's produced I get a different set of error messages but not the same failure. Slightly bizarre. 1 Error: Invalid character in name at (1) /paw-2.14.04.dfsg.2/src/pawlib/comis/comis/cspar.inc:2.1: Included at /paw-2.14.04.dfsg.2/src/pawlib/comis/code/csintx.F:21: * $Id: cspar.inc,v 1.2 2000/05/30 13:53:58 couet Exp $ 1 Error: Invalid character in name at (1) /paw-2.14.04.dfsg.2/src/pawlib/comis/comis/cspar.inc:3.1: Included at /paw-2.14.04.dfsg.2/src/pawlib/comis/code/csintx.F:21: * 1 Error: Invalid character in name at (1) /paw-2.14.04.dfsg.2/src/pawlib/comis/comis/cspar.inc:4.1: Included at /paw-2.14.04.dfsg.2/src/pawlib/comis/code/csintx.F:21: * $Log: cspar.inc,v $ 1 Error: Invalid character in name at (1) /paw-2.14.04.dfsg.2/src/pawlib/comis/comis/cspar.inc:5.1: Included at /paw-2.14.04.dfsg.2/src/pawlib/comis/code/csintx.F:21: * Revision 1.2 2000/05/30 13:53:58 couet 1 Error: Invalid character in name at (1) /paw-2.14.04.dfsg.2/src/pawlib/comis/comis/cspar.inc:6.1: Included at /paw-2.14.04.dfsg.2/src/pawlib/comis/code/csintx.F:21: * - A buffer size increased 1 Error: Invalid character in name at (1)
[Bug tree-optimization/60656] [4.8/4.9 regression] x86 vectorization produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60656 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-25 CC||jakub at gcc dot gnu.org Target Milestone|--- |4.8.3 Ever confirmed|0 |1 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org --- Started with r189006. Looking into it.
[Bug target/60657] [4.9 Regression] ICE: error: insn does not satisfy its constraints
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60657 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-25 CC||ramana at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Confirmed.
[Bug ipa/60600] [4.9 Regression] ICE in ipa_get_indirect_edge_target_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60600 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2014-03/msg01363.htm ||l --- Comment #7 from Martin Jambor jamborm at gcc dot gnu.org --- (In reply to lucdanton from comment #5) I must apologise for the peculiar testcase I produced. No need to apologize, I should have thought the downcast was originally performed after a check. The testcase is in fact very nice. And of course, gcc should not ICE even if you feed it undefined or even invalid input. The patch I am going to commit is at: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01363.html
[Bug ipa/60600] [4.9 Regression] ICE in ipa_get_indirect_edge_target_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60600 --- Comment #8 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Tue Mar 25 18:22:41 2014 New Revision: 208818 URL: http://gcc.gnu.org/viewcvs?rev=208818root=gccview=rev Log: 2014-03-25 Martin Jambor mjam...@suse.cz PR ipa/60600 * ipa-cp.c (ipa_get_indirect_edge_target_1): Redirect type inconsistent devirtualizations to __builtin_unreachable. testsuite/ * g++.dg/ipa/pr60600.C: New test. Added: trunk/gcc/testsuite/g++.dg/ipa/pr60600.C Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-cp.c trunk/gcc/testsuite/ChangeLog
[Bug other/60465] Compiling glibc-2.17,2.18 with gcc-4.8.2 and binutils-2.23.2,2.24 results in segfaults in _start / elf_get_dynamic_info
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60465 --- Comment #6 from devurandom at gmx dot net --- Did anyone figure out what's going on? Did the gdb log bring new insights?
[Bug ipa/60600] [4.9 Regression] ICE in ipa_get_indirect_edge_target_1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60600 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Martin Jambor jamborm at gcc dot gnu.org --- Fixed.
[Bug c++/60642] Unclear diagnostic with invalid use of abi_tag attribute on explicit instantiation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60642 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-25 Summary|abi_tag attribute doesn't |Unclear diagnostic with |work on explicit|invalid use of abi_tag |specializations of class|attribute on explicit |templates |instantiation Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- That's not a specialization, it's an explicit instantiation, and so you don't need the tag, it should be simply: template class testint; The error message could be clearer though, so confirming as a diagnostic bug.
[Bug libstdc++/60658] std::atomicT* is unexpectedly not lock-free
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60658 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-25 Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Oops - I thought we'd fixed all those kind of bugs in the atomicT* specialization
[Bug ipa/60659] [4.9 Regression] ICE in get_polymorphic_call_info, at ipa-devirt.c:1292
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60659
Markus Trippelsdorf trippels at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-03-25
CC||hubicka at gcc dot gnu.org,
||trippels at gcc dot gnu.org
Component|target |ipa
Ever confirmed|0 |1
--- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
Also happens on x86_64.
markus@x4 tmp % cat test.ii
template typename _InputIterator void __distance (_InputIterator);
template typename _InputIterator
void distance (_InputIterator, _InputIterator p2)
{
__distance (p2);
}
namespace boost
{
template class Iterator struct A
{
typedef typename Iterator::difference_type type;
};
template class T typename T::const_iterator end (T );
template class T typename T::const_iterator begin (T );
template class T struct D : Atypename T::const_iterator
{
};
template class T typename DT::type distance (const T p1)
{
distance (boost::begin (p1), boost::end (p1));
return 0;
}
template class IteratorT class B
{
public:
typedef B type;
typedef IteratorT const_iterator;
};
}
typedef int storage_t[];
struct F;
template template typename class struct G
{
G (const G p1) { p1.m_fn1 ().m_fn1 (0); }
const F m_fn1 () const
{
const void *a;
a = data_m;
return *static_castconst F *(a);
}
storage_t *data_m;
};
struct F
{
virtual F *m_fn1 (void *) const;
};
template typename struct H;
struct C : GH
{
typedef int difference_type;
};
boost::BC AllTransVideos ();
int b = boost::distance (AllTransVideos ());
markus@x4 tmp % g++ -c -O2 test.ii
test.ii: In function ‘void distance(_InputIterator, _InputIterator) [with
_InputIterator = C]’:
test.ii:5:17: internal compiler error: in get_polymorphic_call_info, at
ipa-devirt.c:1292
__distance (p2);
^
Please submit a full bug report,
[Bug c/60654] format warnings don't work with PROGMEM/PSTR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60654 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||mpolacek at gcc dot gnu.org --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- What is PSTR? What is PGM_P?
[Bug c/60660] New: alloca function for inlines that allocates on caller stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60660 Bug ID: 60660 Summary: alloca function for inlines that allocates on caller stack Product: gcc Version: unknown Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: josh at joshtriplett dot org To implement certain helper functions, it would help greatly to have the ability to perform stack allocations in the parent function from an inline function. If the function is guaranteed to be inline (for instance, with always_inline), this seems straightforward. A function like __builtin_alloca_caller() would make it possible to write something like alloca_sprintf safely, without multiple evaluation of the variable arguments as a macro would.
[Bug ipa/60659] [4.9 Regression] ICE in get_polymorphic_call_info, at ipa-devirt.c:1292
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60659 Jan Hubicka hubicka at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |hubicka at gcc dot gnu.org --- Comment #2 from Jan Hubicka hubicka at gcc dot gnu.org --- Mine. And I was about to declare ipa-devirt to be officially 100% bug free :)
[Bug c/60660] alloca function for inlines that allocates on caller stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60660 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- This is much harder than you think really. since you have to move all the arguments of the callee function
[Bug c/60660] alloca function for inlines that allocates on caller stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60660 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- without multiple evaluation of the variable arguments as a macro would. You can use statement expressions with typeof extension to get around the issue of multiple evaluation issue of macros already.
[Bug c/52190] question about atomic intrinsics -- test and documentation vary -- please clarify
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52190 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||mpolacek at gcc dot gnu.org Resolution|--- |FIXED --- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org --- Should be fixed.
[Bug libstdc++/60658] std::atomicT* is unexpectedly not lock-free
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60658 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
[Bug libstdc++/60658] [4.7/4.8/4.9 Regression] std::atomicT* is unexpectedly not lock-free
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60658 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Known to work||4.6.3 Target Milestone|--- |4.7.4 Summary|std::atomicT* is |[4.7/4.8/4.9 Regression] |unexpectedly not lock-free |std::atomicT* is ||unexpectedly not lock-free --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- This is a regression in all active branches
