[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #10 from Dominique d'Humieres --- > I added the test case which is at least freed from a lot of docu and > the heavy autotools/libtool setup. The makefile compiles the code and > creates a binary seg_prod. Run this as ./seg_prod input.txt to produce > the problem. I try to reduce this further. Thanks for this reduction. However make fails with make: *** No rule to make target `signal_interface.o', needed by `all'. Stop.
[Bug tree-optimization/61839] New: More optimize opportunity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61839
Bug ID: 61839
Summary: More optimize opportunity
Product: gcc
Version: 4.8.4
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: ishiura-compiler at ml dot kwansei.ac.jp
We have two equvalent programs (A) and (B), which only differ by one line
(marked by "// <---HERE"), where (B) simply folds a+972195718 to 972195717,
for local variable a=-1.
Resulting code by "x86_64-unknown-linux-gnu-gcc-4.8.4 -Os -S" is
different; the code for (A) is less optimized than that of (B).
(A)
int main (void)
{
int a = -1;
volatile unsigned b = 1U;
int c = 1;
c = (a + 972195718) >> (1LU <= b); // <---HERE
if (c == 486097858);
else __builtin_abort();
return 0;
}
(B)
int main (void)
{
int a = -1;
volatile unsigned b = 1U;
int c = 1;
c = 972195717 >> (1LU <= b);// <---HERE
if (c == 486097858);
else __builtin_abort();
return 0;
}
+-+-+
|(A) |(B) |
+-+-+
|main:|main:|
|.LFB0: |.LFB0: |
|.cfi_startproc |.cfi_startproc |
|subq$24, %rsp|subq$24, %rsp|
|.cfi_def_cfa_offset 32 |.cfi_def_cfa_offset 32 |
|movl$1, 12(%rsp) |movl$1, 12(%rsp) |
|movl12(%rsp), %eax |movl12(%rsp), %eax |
|testl %eax, %eax |testl %eax, %eax |
|movl$972195717, %eax | |
|setne %cl | |
|sarl%cl, %eax| |
|cmpl$486097858, %eax | |
|jne .L5 |jne .L2 |
|xorl%eax, %eax |callabort|
|addq$24, %rsp|.L2: |
|.cfi_remember_state |xorl%eax, %eax |
|.cfi_def_cfa_offset 8|addq$24, %rsp|
|ret |.cfi_def_cfa_offset 8|
|.L5: |ret |
|.cfi_restore_state |.cfi_endproc |
|callabort| |
|.cfi_endproc | |
+-+-+
$ x86_64-unknown-linux-gnu-gcc-4.8.4 -v
Using built-in specs.
COLLECT_GCC=x86_64-unknown-linux-gnu-gcc-4.8.4
COLLECT_LTO_WRAPPER=/usr/local/x86_64-tools/gcc-4.8.4/libexec/gcc/x86_64-unknown-linux-gnu/4.8.4/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /home/hassy/gcc/configure
--prefix=/usr/local/x86_64-tools/gcc-4.8.4/ --with-gmp=/usr/local/gmp-5.1.1/
--with-mpfr=/usr/local/mpfr-3.1.2/ --with-mpc=/usr/local/mpc-1.0.1/
--disable-multilib --disable-nls --enable-languages=c
Thread model: posix
gcc version 4.8.4 20140622 (prerelease) (GCC)
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #11 from Jürgen Reuter --- Sorry, wrong makefile logic. I will send a working and more reduced case later this afternoon.
[Bug go/61840] New: [4.9 regression] sync/atomic FAILs on x86_64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61840 Bug ID: 61840 Summary: [4.9 regression] sync/atomic FAILs on x86_64-unknown-linux-gnu Product: gcc Version: 4.9.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: go Assignee: ian at airs dot com Reporter: kdevel at vogtner dot de CC: cmang at google dot com first posted in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432 PASS: runtime/pprof Aborted testing.tRunner [redacted]/gcc-4.9.1/bld/gcc-4.9.1/libgo/go/testing/testing.go:392 goroutine 1 [chan receive]: testing.RunTests [redacted]/gcc-4.9.1/bld/gcc-4.9.1/libgo/go/testing/testing.go:472 testing.Main [redacted]/gcc-4.9.1/bld/gcc-4.9.1/libgo/go/testing/testing.go:403 main.main [redacted]/gcc-4.9.1/bld/gcc-objdir/x86_64-unknown-linux-gnu/32/libgo/gotest24424/test/_testmain.go:67 FAIL: sync/atomic make[5]: *** [sync/atomic/check] Fehler 1 Same error in April with 4.9.0: PASS: runtime/pprof Aborted testing.tRunner [redacted]/gcc-4.9.0/bld/gcc-4.9.0/libgo/go/testing/testing.go:392 goroutine 1 [chan receive]: testing.RunTests [redacted]/gcc-4.9.0/bld/gcc-4.9.0/libgo/go/testing/testing.go:472 testing.Main [redacted]/gcc-4.9.0/bld/gcc-4.9.0/libgo/go/testing/testing.go:403 main.main [redacted]/gcc-4.9.0/bld/gcc-objdir/x86_64-unknown-linux-gnu/32/libgo/gotest 24306/test/_testmain.go:67 FAIL: sync/atomic make[5]: *** [sync/atomic/check] Fehler 1
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #12 from Dominique d'Humieres --- After grabbing the missing *.c and *.f files, I end up ta gfortran signal_interface.o sprintf_interface.o iso_varying_string.o system_dependencies.o kinds.o limits.o file_utils.o diagnostics.o mrst2004qed.o cteq6pdf.o mstw2008.o ct10pdf.o CJpdf.o pythia.o pythia_pdf.o pythia_up.o unit_tests.o ifiles.o os_interface.o formats.o bytes.o md5.o cputime.o lexers.o syntax_rules.o parser.o xml.o colors.o hashes.o sorting.o pdg_arrays.o constants.o c_particles.o lorentz.o CppStringsWrap_dummy.o cpp_strings.o FastjetWrap_dummy.o fastjet.o jets.o subevents.o variables.o analysis.o user_code_interface.o expressions.o models.o flavors.o helicities.o quantum_numbers.o state_matrices.o interactions.o evaluators.o polarizations.o HepMCWrap_dummy.o hepmc_interface.o particles.o auto_components.o permutations.o process_constants.o sf_mappings.o beam_structures.o beams.o sf_aux.o sf_base.o phs_base.o mappings.o fks_regions.o phs_trees.o phs_forests.o sm_physics.o sm_qcd.o pdf_builtin.o lhapdf5_full_dummy.o LHAPDFWrap_dummy.o lhapdf.o hoppet_dummy.o hoppet_interface.o sf_pdf_builtin.o sf_lhapdf.o rng_base.o circe1.o sf_circe1.o circe2.o selectors.o sf_circe2.o sf_isr.o sf_epa.o sf_ewa.o sf_escan.o sf_beam_events.o sf_user.o phs_single.o cascades.o phs_wood.o tao_random_numbers.o rng_tao.o mci_base.o mci_midpoint.o exceptions.o vamp_stat.o utils.o divisions.o linalg.o vamp.o mci_vamp.o prclib_interfaces.o particle_specifiers.o prc_core_def.o process_libraries.o prclib_stacks.o slha_interface.o blha_config.o blha_interface.o blha_driver.o prc_test.o prc_core.o prc_template_me.o prc_omega.o subevt_expr.o integration_results.o parton_states.o fks_calculation.o phs_fks.o prc_gosam.o processes.o process_stacks.o event_transforms.o decays.o shower_base.o shower_partons.o ckkw_pseudo_weights.o shower_core.o shower_topythia.o muli_basic.o muli_momentum.o muli_interactions.o muli_cuba.o muli_trapezium.o muli_fibonacci_tree.o muli_aq.o muli_dsigma.o muli_mcint.o muli_remnant.o muli.o mlm_matching.o ckkw_matching.o hep_common.o shower.o events.o eio_data.o eio_base.o eio_raw.o eio_checkpoints.o hep_events.o eio_lhef.o eio_hepmc.o stdhep_dummy.o eio_stdhep.o eio_ascii.o eio_weights.o iterations.o user_files.o rt_data.o dispatch.o process_configurations.o compilations.o integrations.o event_streams.o simulations.o radiation_generator.o commands.o libmanager.o whizard.o -o seg_prod whizard_test.f90 gfortran: error: whizard_test.f90: No such file or directory make: *** [whizard_test] Error 1 Can you please post the file whizard_test.f90? TIA.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #13 from Jürgen Reuter --- Created attachment 33140 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33140&action=edit Abridged and hopefully working test case. In the middle of reducing the test case.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #14 from Jürgen Reuter --- By the way, the -fcheck=all triggered other problems with definitely valid code, so I guess there is another compiler bug.
[Bug fortran/60414] internal compiler error: tree check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60414 Andre Vehreschild changed: What|Removed |Added CC||vehre at gmx dot de --- Comment #2 from Andre Vehreschild --- Created attachment 33141 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33141&action=edit Patch to resolve the compile problem
[Bug fortran/60414] internal compiler error: tree check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60414 --- Comment #3 from Andre Vehreschild --- Hi, this is my first attempt on a patch. Please comment, when something is missing. The error occurs in the translation phase, but I tracked its source to the parse phase where parameter matching is done. The actual argument (array_ref) is not interpreted correctly. In fact, was the current code ignoring the array_ref and examined only the type of object to deref. Added check, if the actual argument is a deref. Added testcase. Found no regressions yet. - Andre
[Bug target/61794] internal error: unrecognizable insn, from avx512 extract instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61794
Uroš Bizjak changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |ubizjak at gmail dot com
--- Comment #2 from Uroš Bizjak ---
Patch in testing:
--cut here--
Index: sse.md
===
--- sse.md (revision 212778)
+++ sse.md (working copy)
@@ -5892,9 +5892,10 @@
(match_operand 5 "const_0_to_15_operand")]))
(match_operand: 6 "memory_operand" "0")
(match_operand:QI 7 "register_operand" "Yk")))]
- "TARGET_AVX512F && (INTVAL (operands[2]) = INTVAL (operands[3]) - 1)
- && (INTVAL (operands[3]) = INTVAL (operands[4]) - 1)
- && (INTVAL (operands[4]) = INTVAL (operands[5]) - 1)"
+ "TARGET_AVX512F
+ && (INTVAL (operands[2]) == (INTVAL (operands[3]) - 1)
+ && INTVAL (operands[3]) == (INTVAL (operands[4]) - 1)
+ && INTVAL (operands[4]) == (INTVAL (operands[5]) - 1))"
{
operands[2] = GEN_INT ((INTVAL (operands[2])) >> 2);
return "vextract32x4\t{%2, %1, %0%{%7%}|%0%{%7%}, %1, %2}";
@@ -5914,9 +5915,10 @@
(match_operand 3 "const_0_to_15_operand")
(match_operand 4 "const_0_to_15_operand")
(match_operand 5 "const_0_to_15_operand")])))]
- "TARGET_AVX512F && (INTVAL (operands[2]) = INTVAL (operands[3]) - 1)
- && (INTVAL (operands[3]) = INTVAL (operands[4]) - 1)
- && (INTVAL (operands[4]) = INTVAL (operands[5]) - 1)"
+ "TARGET_AVX512F
+ && (INTVAL (operands[2]) == (INTVAL (operands[3]) - 1)
+ && INTVAL (operands[3]) == (INTVAL (operands[4]) - 1)
+ && INTVAL (operands[4]) == (INTVAL (operands[5]) - 1))"
{
operands[2] = GEN_INT ((INTVAL (operands[2])) >> 2);
return "vextract32x4\t{%2, %1,
%0|%0, %1, %2}";
--cut here--
[Bug libstdc++/42734] trivial use of std::thread fails with "pure virtual method called"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=42734 --- Comment #41 from Jonathan Wakely --- (In reply to Damien Buhl (daminetreg) from comment #40) > I can also confirm the crash with gcc-4.8.1 for an arm platform. You'll have to provide more information about your compilation, see http://gcc.gnu.org/bugs.html You might need to link with -latomic on arm (I'm not sure)
[Bug c++/61841] New: broken std::thread on Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61841 Bug ID: 61841 Summary: broken std::thread on Hurd Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: 1o5g4r8o at gmail dot com Created attachment 33142 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33142&action=edit testcase Forwarding Debian bug https://bugs.debian.org/749290 Attached testcase. On hurd $ g++ thread.cpp -pthread -std=c++11 -o thread $ ./thread terminate called after throwing an instance of 'std::system_error' what(): Enable multithreading to use std::thread: Operation not permitted Aborted On linux it runs fine $ ./thread 1307674368000 355687428096000
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #15 from Dominique d'Humieres --- > By the way, the -fcheck=all triggered other problems with definitely valid > code, so I guess there is another compiler bug. Is it new (as in you don't see them with gfortran 4.9.0)? What are the problems?
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #16 from Dominique d'Humieres --- >From the files in the attachment in comment 8, the files that are affected by this PR are beams.f90, models.f90, and process_libraries.f90: beams.f90: In function 'beam_data_write': beams.f90:144:0: internal compiler error: in gfc_conv_expr_reference, at fortran/trans-expr.c:6519 prt_name_len = maxval (len (flavor_get_name (beam_data%flv))) models.f90:1418:0: internal compiler error: in gfc_conv_expr_reference, at fortran/trans-expr.c:6519 maxval (len (particle_data_get_name (model%prt, .true. process_libraries.f90: In function 'process_libraries_8': process_libraries.f90:2429:0: internal compiler error: in gfc_conv_expr_reference, at fortran/trans-expr.c:6519 variant = core_def) (using a version giving an ICE when using the faulty code). One thing you can try is to make WHIZARD with 4.9.1, then compile the above files with 4.9.0, make again, and see if the problem goes away.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #17 from Dominique d'Humieres --- In comment 16 I have forgotten to list commands.f90 commands.f90: In function 'create_auto_decays': commands.f90:3695:0: internal compiler error: in gfc_conv_expr_reference, at fortran/trans-expr.c:6519 new_prt_spec ([prt_in]), new_prt_spec (prt_out), global) which seems to be the culprit. If I make the reduced test attached to comment 13 with 4.9.1, the test fails; if I compile commands.f90 with gfortran, make again, then the test succeeds.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #18 from Jürgen Reuter --- I didn't get an ICE (yet) but it must in the auto_components part of the code. I'll try to reduce the case a little further.
[Bug ipa/61842] New: [4.10 Regression]: Firefox start-up SEGFAULT with LTO and O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61842 Bug ID: 61842 Summary: [4.10 Regression]: Firefox start-up SEGFAULT with LTO and O3 Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: mliska at suse dot cz Firefox: https://github.com/marxin/gecko-dev/tree/lto-stable (revision: 88a7edf3bab2d1b9a2c140c1f36217f4fbdd1e03) GCC revision: r212778 with applied (https://gcc.gnu.org/ml/gcc-patches/2014-07/msg00929.html) error: *** Error in `/home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/firefox': double free or corruption (fasttop): 0x00587930 *** === Backtrace: = /lib64/libc.so.6(+0x7410f)[0x7737d10f] /lib64/libc.so.6(+0x7996e)[0x7738296e] /lib64/libc.so.6(+0x7a647)[0x77383647] /home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0xa7120f)[0x72d0120f] /home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0xaf2e54)[0x72d82e54] /home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0xb54ebc)[0x72de4ebc] /home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0xb55d81)[0x72de5d81] /home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0xac9d77)[0x72d59d77] /home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0x244b27f)[0x746db27f] /home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(+0x244b415)[0x746db415] /home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/libxul.so(XRE_main+0x203c)[0x746e221c] /home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/firefox[0x4074af] /home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/firefox[0x402fc8] /lib64/libc.so.6(__libc_start_main+0xf5)[0x7732abe5] /home/marxin/Programming/gecko-dev/obj-x86_64-unknown-linux-gnu/dist/bin/firefox[0x403051] BT: Program received signal SIGABRT, Aborted. 0x7733e849 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 56../nptl/sysdeps/unix/sysv/linux/raise.c: No such file or directory. (gdb) bt #0 0x7733e849 in __GI_raise (sig=sig@entry=6) at ../nptl/sysdeps/unix/sysv/linux/raise.c:56 #1 0x7733fcd8 in __GI_abort () at abort.c:89 #2 0x7737d114 in __libc_message (do_abort=do_abort@entry=2, fmt=fmt@entry=0x77473220 "*** Error in `%s': %s: 0x%s ***\n") at ../sysdeps/posix/libc_fatal.c:175 #3 0x7738296e in malloc_printerr (action=3, str=0x77473408 "double free or corruption (fasttop)", ptr=) at malloc.c:4916 #4 0x77383647 in _int_free (av=, p=0x587920, have_lock=0) at malloc.c:3772 #5 0x72d0120f in operator delete () at ../../../dist/include/mozilla/mozalloc.h:225 #6 __base_dtor (this=) at ../../../dist/include/nsAutoPtr.h:73 #7 nsPrefBranch::RemoveObserver (this=, aDomain=, aObserver=) at /home/marxin/Programming/gecko-dev/modules/libpref/src/nsPrefBranch.cpp:658 #8 0x72d82e54 in nsSocketTransportService::Shutdown (this=0x586690) at /home/marxin/Programming/gecko-dev/netwerk/base/src/nsSocketTransportService2.cpp:537 #9 0x72de4ebc in nsIOService::SetOffline (this=0x582260, offline=) at /home/marxin/Programming/gecko-dev/netwerk/base/src/nsIOService.cpp:748 #10 0x72de5d81 in nsIOService::Observe (this=0x582260, subject=, topic=, data=0x756bd7a0 u"shutdown-persist") at /home/marxin/Programming/gecko-dev/netwerk/base/src/nsIOService.cpp:918 #11 0x72d59d77 in NotifyObservers ( someData=0x756bd7a0 u"shutdown-persist", aTopic=0x7542f899 "profile-change-net-teardown", aSubject=0x0, this=) at /home/marxin/Programming/gecko-dev/xpcom/ds/nsObserverList.cpp:96 #12 nsObserverService::NotifyObservers (this=0x57b8f0, aSubject=0x0, aTopic=0x7542f899 "profile-change-net-teardown", someData=0x756bd7a0 u"shutdown-persist") at /home/marxin/Programming/gecko-dev/xpcom/ds/nsObserverService.cpp:303 #13 0x746db27f in _ZN16nsXREDirProvider10DoShutdownEv.part.17 (this=0x7fffc220) at /home/marxin/Programming/gecko-dev/toolkit/xre/nsXREDirProvider.cpp:853 #14 0x746db415 in DoShutdown (this=) at /home/marxin/Programming/gecko-dev/toolkit/xre/nsAppRunner.cpp:1204 #15 __base_dtor (this=0x50bdc0) at /home/marxin/Programming/gecko-dev/toolkit/xre/nsAppRunner.cpp:1196 #16 0x746e221c in XRE_main (aAppData=, argv=, argc=, this=) at /home/marxin/Programming/gecko-dev/toolkit/xre/nsAppRunner.cpp:4109 #17 XRE_main (argc=7864321, argv=0x50bdc0, aAppData=0x1, aFlags=4294967295) at /home/marxin/Programming/gecko-dev/toolkit/xre/nsAppRunner.cpp:4298 #18 0x004074af in
[Bug go/61840] [4.9 regression] sync/atomic FAILs on x86_64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61840 --- Comment #1 from Stefan --- After configuring with --with-arch-32=i686 I get PASS: runtime/pprof Aborted testing.tRunner [redacted]/gcc-4.9.1/bld/gcc-4.9.1/libgo/go/testing/testing.go:392 goroutine 1 [chan receive]: testing.RunTests [redacted]/gcc-4.9.1/bld/gcc-4.9.1/libgo/go/testing/testing.go:472 testing.Main [redacted]/gcc-4.9.1/bld/gcc-4.9.1/libgo/go/testing/testing.go:403 main.main [redacted]/gcc-4.9.1/bld/gcc-objdir/x86_64-unknown-linux-gnu/32/libgo/gotest19278/test/_testmain.go:67 FAIL: sync/atomic
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #19 from Dominique d'Humieres --- > I didn't get an ICE (yet) but it must in the auto_components part of the code. You are not supposed to get the ICEs mentioned in comments 16 and 17, they are due to the build I am using to track down the problem. Could you can try is to make WHIZARD with 4.9.1, then compile the file commands.f90 with gfortran 4.9.0, make again, then run your tests and see if the problem is gone. > I'll try to reduce the case a little further. What would help me (although I can do it) is a list of the files needed to compile commands.f90. Also it would be nice to have a (working) replacement of the lines call prc_config%setup_component (1, & new_prt_spec ([prt_in]), new_prt_spec (prt_out), global) that does not use '[prt_in]'. Otherwise don't spend too much time right now with reducing as I think I have what I need to do the debugging (fingers crossed!-).
[Bug go/59432] [4.9/4.10 regression] sync/atomic FAILs on Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432 --- Comment #7 from Uroš Bizjak --- Please see [1] for the explanation of this problem. Your system doesn't support .cfi directives and the referred patch doesn't handle this situation. Since EBX register is marked as fixed, there is nothing we can do. [1] https://gcc.gnu.org/ml/gcc-patches/2013-11/msg00309.html
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #20 from Jürgen Reuter --- Ok, Dominique, you mean: compile everything with 4.9.1, then recompile commands.f90 with 4.9.0 and build the executable with 4.9.0?
[Bug libstdc++/61835] Invalid comment on pretty printers breaks gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61835 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-18 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #21 from Dominique d'Humieres --- > Ok, Dominique, you mean: compile everything with 4.9.1, then recompile > commands.f90 with 4.9.0 Yes > and build the executable with 4.9.0? At this point 4.9.0 or 4.9.1 should not matter. So if you use 'make' again I assume it will use 4.9.1.
[Bug libgcc/61843] New: Segmentation Fault on with avr-ld when linking with AVR C++ Linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61843 Bug ID: 61843 Summary: Segmentation Fault on with avr-ld when linking with AVR C++ Linker Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: petermilani at qfr dot net.au Linking a AVR C++ program throws the following: make all Building target: RoverMowerProject.elf Invoking: AVR C++ Linker avr-g++ --cref -s -Os -o"RoverMowerProject.elf" ./src/kalman_h/kalman.o ./src/i2c/i2c.o ./src/hmmv4_configmsg_h/hmmv4_configmsg.o ./src/fPID_h/fPID.o ./src/Wire/utility/twi.o ./src/Wire/Wire.o ./src/SPI/SPI.o ./src/RCswitch/RCSwitch.o ./src/Qbot_configmsg_h/Qbot_configmsg.o ./src/PID_h/PID.o ./src/Velocity_Controller.o -larduino_core -lm -lm -Wl,-Map,RoverMowerProject.map,--cref -mrelax -Wl,--gc-sections -Wl,--gc-sections -L"/home/petermilani/workspace/arduino_core/328P_16MHz" -mmcu=atmega328p collect2: ld terminated with signal 11 [Segmentation fault], core dumped make: *** [RoverMowerProject.elf] Error 1 let us know if you need more information.
[Bug libgcc/61843] Segmentation Fault on with avr-ld when linking with AVR C++ Linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61843 --- Comment #1 from peter --- version number: $ avr-ld -v GNU ld (GNU Binutils) 2.20.1.20100303
[Bug target/61737] ICE when building libgcc for cris cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737 --- Comment #19 from dhowells at redhat dot com --- This seems to have done the trick, thanks!
[Bug go/61840] [4.9 regression] sync/atomic FAILs on x86_64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61840 --- Comment #2 from Ian Lance Taylor --- Please tell us what kind of system you are running on and precisely how you ran configure. The error report doesn't make sense; it seems incomplete. I don't see how the test could fail without printing out more than that. What happens if you cd into the directory x86_64-unknown-linux-gnu/32/libgo and run "make sync/atomic/check"?
[Bug go/61840] [4.9 regression] sync/atomic FAILs on x86_64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61840 --- Comment #3 from Ian Lance Taylor --- On the other bug Uros Bizjak suggests that perhaps the fix is https://gcc.gnu.org/ml/gcc-patches/2013-11/msg00309.html but that that patch does not work for you because your system does not support CFI directives in the assembler.
[Bug ipa/61842] [4.10 Regression]: Firefox start-up SEGFAULT with LTO and O3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61842 --- Comment #1 from Martin Liška --- I've just double checked that I have the same issue with -O2.
[Bug libstdc++/61841] broken std::thread on Hurd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61841 Jonathan Wakely changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-18 Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jonathan Wakely --- Created attachment 33143 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33143&action=edit force dependency on pthread_create Something like this would force the user to link to libpthread (turning a runtime error into a linktime error) and would force the linker to pull in the required symbol.
[Bug c/61844] New: ICE when building libgcc for sh64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844
Bug ID: 61844
Summary: ICE when building libgcc for sh64 cross-compiler
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dhowells at redhat dot com
When trying to build a cross-compiler for sh64 with libgcc, I get the following
error and several others like it (make -j is in operation) during the compiler
build:
/data/fedora/cross-gcc/gcc-4.9.0-20140702/sh64-linux-gnu/./gcc/xgcc
-B/data/fedora/cross-gcc/gcc-4.9.0-20140702/sh64-linux-gnu/./gcc/
-B/usr/sh64-linux/bin/ -B/usr/sh64-linux/lib/ -isystem /usr/sh64-linux/include
-isystem /usr/sh64-linux/sys-include-g -O2 -mb -O2 -g -O2 -DIN_GCC
-DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-isystem ./include -fpic -DNO_FPSCR_VALUES -w -Wno-sync-nand -g -DIN_LIBGCC2
-fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -fpic -DNO_FPSCR_VALUES
-w -Wno-sync-nand -I. -I. -I../../.././gcc
-I../../../../gcc-4.9.0-20140702/libgcc
-I../../../../gcc-4.9.0-20140702/libgcc/.
-I../../../../gcc-4.9.0-20140702/libgcc/../gcc
-I../../../../gcc-4.9.0-20140702/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS
-o _addvsi3.o -MT _addvsi3.o -MD -MP -MF _addvsi3.dep -DL_addvsi3 -c
../../../../gcc-4.9.0-20140702/libgcc/libgcc2.c -fvisibility=hidden
-DHIDE_EXPORTS
../../../../gcc-4.9.0-20140702/libgcc/libgcc2.c: In function ‘__addvsi3’:
../../../../gcc-4.9.0-20140702/libgcc/libgcc2.c:84:1: error: insn does not
satisfy its constraints:
}
^
(insn 27 51 52 3 (set (reg:SI 1 r1 [172])
(mem/c:SI (plus:SI (reg:SI 2 r2)
(reg:SI 12 r12)) [0 S4 A32]))
../../../../gcc-4.9.0-20140702/libgcc/libgcc2.c:81 260 {*movsi_media}
(nil))
../../../../gcc-4.9.0-20140702/libgcc/libgcc2.c:84:1: internal compiler error:
in reload_cse_simplify_operands, at postreload.c:411
0x73b24a _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../gcc-4.9.0-20140702/gcc/rtl-error.c:109
0x73b26f _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
../../gcc-4.9.0-20140702/gcc/rtl-error.c:120
0x6f2aa0 reload_cse_simplify_operands
../../gcc-4.9.0-20140702/gcc/postreload.c:411
0x6f48cc reload_cse_simplify
../../gcc-4.9.0-20140702/gcc/postreload.c:181
0x6f48cc reload_cse_regs_1
../../gcc-4.9.0-20140702/gcc/postreload.c:220
0x6f4cbb reload_cse_regs
../../gcc-4.9.0-20140702/gcc/postreload.c:68
0x6f4cbb rest_of_handle_postreload
../../gcc-4.9.0-20140702/gcc/postreload.c:2332
0x6f4cbb execute
../../gcc-4.9.0-20140702/gcc/postreload.c:2368
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See
[Bug c/61844] ICE when building libgcc for sh64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844 --- Comment #1 from dhowells at redhat dot com --- System compiler being used: Using built-in specs. COLLECT_GCC=/usr/bin/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.3/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --enable-java-awt=gtk --disable-dssi --with-java-home=/usr/lib/jvm/java-1.5.0-gcj-1.5.0.0/jre --enable-libgcj-multifile --enable-java-maintainer-mode --with-ecj-jar=/usr/share/java/eclipse-ecj.jar --disable-libjava-multilib --with-isl=/builddir/build/BUILD/gcc-4.8.3-20140624/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.3-20140624/obj-x86_64-redhat-linux/cloog-install --with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.3 20140624 (Red Hat 4.8.3-1) (GCC)
[Bug c/61844] ICE when building libgcc for sh64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844 --- Comment #2 from dhowells at redhat dot com --- Created attachment 33144 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33144&action=edit Old, no-longer functional patch to libgcc I was given the attached patch when I was on gcc-4.7 but it doesn't seem to help with gcc-4.9. The problem occurs with or without the patch.
[Bug c/61844] ICE when building libgcc for sh64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844 --- Comment #3 from dhowells at redhat dot com --- The compiler is configured thusly: AR_FOR_TARGET=/usr/bin/sh64-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/sh64-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/sh64-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/sh64-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/sh64-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/sh64-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/sh64-linux-gnu-ranlib \ STRIP_FOR_TARGET=/usr/bin/sh64-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/sh64-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/sh64-linux-gnu-windmc \ LDFLAGS='-Wl,-z,relro ' \ ../gcc-4.9.0-20140702/configure --bindir=/usr/bin --build=x86_64-redhat-linux-gnu --datadir=/usr/share --disable-decimal-float --disable-dependency-tracking --disable-gold --disable-libgomp --disable-libmudflap --disable-libquadmath --disable-libssp --disable-nls --disable-plugin --disable-shared --disable-silent-rules --disable-sjlj-exceptions --disable-threads --enable-checking= --enable-gnu-unique-object --enable-initfini-array --enable-languages=c,c++ --enable-linker-build-id --enable-nls --enable-obsolete --enable-targets=all --exec-prefix=/usr --host=x86_64-redhat-linux-gnu --includedir=/usr/include --infodir=/usr/share/info --libexecdir=/usr/libexec --localstatedir=/var --mandir=/usr/share/man --prefix=/usr --program-prefix=sh64-linux-gnu- --sbindir=/usr/sbin --sharedstatedir=/var/lib --sysconfdir=/etc --target=sh64-linux --with-bugurl=http://bugzilla.redhat.com/bugzilla/ --with-linker-hash-style=gnu --with-newlib --with-sysroot=/usr/sh64-linux-gnu/sys-root --with-system-libunwind --with-system-zlib --without-headers --without-isl --without-cloog --with-multilib-list=m5-32media,m5-32media-nofpu,m5-compact,m5-compact-nofpu,m5-64media,m5-64media-nofpu The binutils is: sh64-linux-gnu-as -v GNU assembler version 2.24.0 (sh64-linux) using BFD version version 2.24.0-4.fc20 20140613 The compiler is built: AR_FOR_TARGET=/usr/bin/sh64-linux-gnu-ar \ AS_FOR_TARGET=/usr/bin/sh64-linux-gnu-as \ DLLTOOL_FOR_TARGET=/usr/bin/sh64-linux-gnu-dlltool \ LD_FOR_TARGET=/usr/bin/sh64-linux-gnu-ld \ NM_FOR_TARGET=/usr/bin/sh64-linux-gnu-nm \ OBJDUMP_FOR_TARGET=/usr/bin/sh64-linux-gnu-objdump \ RANLIB_FOR_TARGET=/usr/bin/sh64-linux-gnu-ranlib \ STRIP_FOR_TARGET=/usr/bin/sh64-linux-gnu-strip \ WINDRES_FOR_TARGET=/usr/bin/sh64-linux-gnu-windres \ WINDMC_FOR_TARGET=/usr/bin/sh64-linux-gnu-windmc \ make -C sh64-linux-gnu -j12 tooldir=/usr all-gcc Then libgcc is built: make -C sh64-linux-gnu -j12 tooldir=/usr all-target-libgcc
[Bug c/61844] ICE when building libgcc for sh64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844 --- Comment #4 from dhowells at redhat dot com --- This behaviour can be produced with the SVNREV 212237 (2014-07-02) gcc-4.9.0 compiler tarball and no extra patches.
[Bug c/61844] ICE when building libgcc for sh64 cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61844 --- Comment #5 from dhowells at redhat dot com --- Note that I also see a number of warnings like: /usr/bin/sh64-linux-gnu-nm: _sdivsi3_s.o: File format is ambiguous
[Bug go/59432] [4.9/4.10 regression] sync/atomic FAILs on Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432 --- Comment #8 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #7) > Please see [1] for the explanation of this problem. Your system doesn't > support .cfi directives and the referred patch doesn't handle this situation. > > Since EBX register is marked as fixed, there is nothing we can do. There is a proposal to allow EBX for allocation also in PIC mode [1]. The approach proposed in referred poposal would solve this PR (and many others, too). [1] https://gcc.gnu.org/ml/gcc/2014-07/msg00058.html
[Bug go/59432] [4.9/4.10 regression] sync/atomic FAILs on Solaris/x86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59432 --- Comment #9 from Uroš Bizjak --- This problem is also seen on CentOS 5, where CFI directives are not supported.
[Bug go/61840] [4.9 regression] sync/atomic FAILs on x86_64-unknown-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61840 --- Comment #4 from Stefan --- Thanks for the comments. I had an old as (binutils 2.19) on the system. After replacing with binutils 2.22 GCC passes the test.
[Bug target/61737] ICE when building libgcc for cris cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737 --- Comment #20 from Hans-Peter Nilsson --- Unfortunately, at the face of it, I think the only factors common with PR61844 are "rot at the RTL level" and "building libgcc". (My own involvement with SH64 is too far in the past and then only peripheral to the GCC port.)
[Bug libstdc++/61835] Invalid comment on pretty printers breaks gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61835 --- Comment #1 from Jonathan Wakely --- Author: redi Date: Fri Jul 18 15:56:00 2014 New Revision: 212822 URL: https://gcc.gnu.org/viewcvs?rev=212822&root=gcc&view=rev Log: PR libstdc++/61835 * python/libstdcxx/v6/printers.py (TemplateTypePrinter): Use raw string. (SingleObjContainerPrinter): Check if type printers are in use. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/python/libstdcxx/v6/printers.py
[Bug libstdc++/61835] Invalid comment on pretty printers breaks gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61835 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Version|unknown |4.10.0 Resolution|--- |FIXED Target Milestone|--- |4.10.0 --- Comment #2 from Jonathan Wakely --- Should be fixed
[Bug target/61737] ICE when building libgcc for cris cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737 --- Comment #21 from Hans-Peter Nilsson --- (In reply to Hans-Peter Nilsson from comment #20) > Unfortunately, at the face of it, I think the only factors common with > PR61844 are "rot at the RTL level" and "building libgcc". Apparently also "when handling PIC" (register 12 on SH says grep). Unfortunately that's unlikely to help anyone not involved with SH64.
[Bug target/61737] ICE when building libgcc for cris cross-compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61737 --- Comment #22 from dhowells at redhat dot com --- That's a shame. It's just that the error messages look very similar.
[Bug target/61794] internal error: unrecognizable insn, from avx512 extract instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61794 --- Comment #3 from uros at gcc dot gnu.org --- Author: uros Date: Fri Jul 18 16:13:45 2014 New Revision: 212824 URL: https://gcc.gnu.org/viewcvs?rev=212824&root=gcc&view=rev Log: PR target/61794 * config/i386/sse.md (avx512f_vextract32x4_1_maskm): Fix instruction constraint. (avx512f_vextract32x4_1): Ditto. testsuite/ChangeLog: PR target/61794 * gcc.target/i386/pr61794.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr61794.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/sse.md trunk/gcc/testsuite/ChangeLog
[Bug target/61794] internal error: unrecognizable insn, from avx512 extract instruction
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61794 --- Comment #4 from uros at gcc dot gnu.org --- Author: uros Date: Fri Jul 18 16:18:02 2014 New Revision: 212825 URL: https://gcc.gnu.org/viewcvs?rev=212825&root=gcc&view=rev Log: Backport from mainline 2014-07-18 Uros Bizjak PR target/61794 * config/i386/sse.md (avx512f_vextract32x4_1_maskm): Fix instruction constraint. (avx512f_vextract32x4_1): Ditto. testsuite/ChangeLog: Backport from mainline 2014-07-18 Uros Bizjak PR target/61794 * gcc.target/i386/pr61794.c: New test. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/i386/pr61794.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/i386/sse.md branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 Jürgen Reuter changed: What|Removed |Added Attachment #33138|0 |1 is obsolete|| Attachment #33140|0 |1 is obsolete|| --- Comment #22 from Jürgen Reuter --- Created attachment 33147 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33147&action=edit Even more reduced test case This test case doesn't need an input file anymore, just compile it and run ./seg_prod.
[Bug lto/61802] [4.10 Regression] AArch64 execute.exp failures with LTO after r212467
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61802 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-18 Ever confirmed|0 |1 --- Comment #5 from Andrew Pinski --- Confirmed for me too.
[Bug rtl-optimization/61461] -fdump-rtl-all-slim causes ICE with fold-const.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61461 --- Comment #1 from edlinger at gcc dot gnu.org --- Author: edlinger Date: Fri Jul 18 18:11:53 2014 New Revision: 212829 URL: https://gcc.gnu.org/viewcvs?rev=212829&root=gcc&view=rev Log: 2014-07-18 Bernd Edlinger PR rtl-optimization/61461 * sched-vis.c (print_pattern) : Fixed. Modified: trunk/gcc/ChangeLog trunk/gcc/sched-vis.c
[Bug libstdc++/61835] Invalid comment on pretty printers breaks gdb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61835 Mariano Bessone changed: What|Removed |Added Status|RESOLVED|VERIFIED --- Comment #3 from Mariano Bessone --- CONFIRMED.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831
--- Comment #23 from Dominique d'Humieres ---
Could you test the following patch?
--- ../_clean/gcc/fortran/trans-expr.c2014-07-07 22:48:04.0 +0200
+++ gcc/fortran/trans-expr.c2014-07-18 21:28:24.0 +0200
@@ -6512,7 +6512,10 @@ gfc_conv_expr_reference (gfc_se * se, gf
if (expr->ts.type == BT_DERIVED && expr->rank
&& !gfc_is_finalizable (expr->ts.u.derived, NULL)
&& expr->ts.u.derived->attr.alloc_comp
- && expr->expr_type != EXPR_VARIABLE)
+ && expr->expr_type != EXPR_VARIABLE
+ && (expr->expr_type != EXPR_ARRAY
+ || (expr->expr_type == EXPR_ARRAY
+ && expr->ts.u.derived->refs == 1)))
{
tree tmp;
[Bug c/61846] New: gcc assumes errno might be negative and issues unnecessary warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61846
Bug ID: 61846
Summary: gcc assumes errno might be negative and issues
unnecessary warning
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zbyszek at in dot waw.pl
Created attachment 33148
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33148&action=edit
sample program
I see this a lot in systemd source code, where the convention is to return a
negative integer on error. gcc warns as if errno could also be zero or negative
after a system call, and warns about unitialized variables. Simplified example
attached.
$ gcc -Wall -O3 -std=gnu99 -o readwarn readwarn.c
readwarn.c: In function ‘main’:
readwarn.c:28:9: warning: ‘ans’ may be used uninitialized in this function
[-Wmaybe-uninitialized]
printf("ans: %d", ans);
^
POSIX states that errno values are positive [1], and read may sets errno, so it
is safe to assume that if read() returned -1, errno must have a positive value.
If I replace 'return -errno' with 'return errno > 0 ? -errno : -EIO', the
warning disappers.
[1]
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/errno.h.html#tag_13_10
[Bug c/61846] gcc assumes errno might be negative and issues unnecessary warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61846 --- Comment #1 from Zbigniew Jędrzejewski-Szmek --- Created attachment 33150 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33150&action=edit compilation logs
[Bug c/61846] gcc assumes errno might be negative and issues unnecessary warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61846 --- Comment #2 from Zbigniew Jędrzejewski-Szmek --- Created attachment 33151 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33151&action=edit processed source
[Bug c/61846] gcc assumes errno might be negative and issues unnecessary warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61846 Zbigniew Jędrzejewski-Szmek changed: What|Removed |Added Attachment #33148|0 |1 is obsolete|| --- Comment #3 from Zbigniew Jędrzejewski-Szmek --- Created attachment 33152 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33152&action=edit sample program
[Bug c/61846] gcc assumes errno might be negative and issues unnecessary warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61846 --- Comment #4 from Andrew Pinski --- C99 also has this requirement. But C89 did not. >Values for errno are now required to be distinct positive values rather than > non-zero values. This change is for alignment with the ISO/IEC 9899:1999 > standard. So using -std=gnu99 should allow this to not be unitilaized except GCC has no way to know you are reading from errno just yet.
[Bug fortran/61831] [4.9/ 4.10 Regression] runtime error: pointer being freed was not allocated
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61831 --- Comment #24 from Jürgen Reuter --- Created attachment 33153 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33153&action=edit Further cutting down the example
[Bug fortran/61847] New: bug in gfortran runtime on OSX: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 Bug ID: 61847 Summary: bug in gfortran runtime on OSX: digits cut off when reading floating point number Product: gcc Version: 4.8.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: e2cd58e1 at opayq dot com Created attachment 33154 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33154&action=edit source code Reading a floating point number from a file cuts off digits, depending on the C locale. This happens on a Mac when the locale is set to de_DE UTF-8 (note: in german, the comma is used as separator for digits, but gfortran probably shouldn't do that). gcc is installed from homebrew, Mac OS X 10.9.4 Attached example was build & executed with gfortran -v -save-temps -Wall -Wextra -o bug bugf.f90 bug.c && ./bug It returns: FAIL 1. But shouldn't return something. gcc -v Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/usr/include/c++/4.2.1 Apple LLVM version 5.1 (clang-503.0.40) (based on LLVM 3.4svn) Target: x86_64-apple-darwin13.3.0 Thread model: posix gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/4.8.3_1/libexec/gcc/x86_64-apple-darwin13.2.0/4.8.3/lto-wrapper Target: x86_64-apple-darwin13.2.0 Configured with: ../configure --build=x86_64-apple-darwin13.2.0 --prefix=/usr/local/Cellar/gcc/4.8.3_1 --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-4.8 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-cloog=/usr/local/opt/cloog --with-isl=/usr/local/opt/isl --with-system-zlib --enable-version-specific-runtime-libs --enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release --enable-lto --disable-werror --with-pkgversion='Homebrew gcc 4.8.3_1' --with-bugurl=https://github.com/Homebrew/homebrew/issues --enable-plugin --disable-nls --enable-multilib Thread model: posix gcc version 4.8.3 (Homebrew gcc 4.8.3_1) -- compilation output for gfortran -v -save-temps -Wall -Wextra -o bug bugf.f90 bug.c -- Driving: gfortran -mmacosx-version-min=10.9.3 -v -save-temps -Wall -Wextra -o bug bugf.f90 bug.c -l gfortran -shared-libgcc Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/4.8.3_1/libexec/gcc/x86_64-apple-darwin13.2.0/4.8.3/lto-wrapper Target: x86_64-apple-darwin13.2.0 Configured with: ../configure --build=x86_64-apple-darwin13.2.0 --prefix=/usr/local/Cellar/gcc/4.8.3_1 --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-4.8 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-cloog=/usr/local/opt/cloog --with-isl=/usr/local/opt/isl --with-system-zlib --enable-version-specific-runtime-libs --enable-libstdcxx-time=yes --enable-stage1-checking --enable-checking=release --enable-lto --disable-werror --with-pkgversion='Homebrew gcc 4.8.3_1' --with-bugurl=https://github.com/Homebrew/homebrew/issues --enable-plugin --disable-nls --enable-multilib Thread model: posix gcc version 4.8.3 (Homebrew gcc 4.8.3_1) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.3' '-v' '-save-temps' '-Wall' '-Wextra' '-o' 'bug' '-shared-libgcc' '-mtune=core2' /usr/local/Cellar/gcc/4.8.3_1/libexec/gcc/x86_64-apple-darwin13.2.0/4.8.3/f951 bugf.f90 -fPIC -quiet -dumpbase bugf.f90 -mmacosx-version-min=10.9.3 -mtune=core2 -auxbase bugf -Wall -Wextra -version -fintrinsic-modules-path /usr/local/Cellar/gcc/4.8.3_1/lib/gcc/x86_64-apple-darwin13.2.0/4.8.3/finclude -o bugf.s GNU Fortran (Homebrew gcc 4.8.3_1) version 4.8.3 (x86_64-apple-darwin13.2.0) compiled by GNU C version 4.8.3, GMP version 6.0.0, MPFR version 3.1.2-p8, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU Fortran (Homebrew gcc 4.8.3_1) version 4.8.3 (x86_64-apple-darwin13.2.0) compiled by GNU C version 4.8.3, GMP version 6.0.0, MPFR version 3.1.2-p8, MPC version 1.0.2 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 bugf.f90:6.6: if (res.ne.1.2345d0) write(*,*) 'FAIL', res 1 Warning: Inequality comparison for REAL(8) at (1) COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.3' '-v' '-save-temps' '-Wall' '-Wextra' '-o' 'bug' '-shared-libgcc' '-mtune=core2' as -arch x86_64 -force_cpusubtype_ALL -o bugf.o bugf.s COLLECT_GCC_OPTIONS='-mmacosx-version-min=10.9.3' '-v' '-save-temps' '-Wall' '-Wextra' '-o' 'bug' '-shared-libgcc' '-mtune=core2' /usr/local/Cellar/gcc/4.8.3_1/libexec/gcc/x86_64-apple-darwin13.2.0/4.8.3/cc1 -E -quiet -v -D__DYNAMIC__ bug.c -fPIC -mmacosx-version-m
[Bug fortran/61632] Memory corruption on error when writing formatted data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 Jerry DeLisle changed: What|Removed |Added Attachment #33114|0 |1 is obsolete|| --- Comment #20 from Jerry DeLisle --- Created attachment 33155 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33155&action=edit Revised patch This patch borrows on Dominique's idea of using strchr to find the end of the format string. Tested OK on x86_64 and the various cases presented in this PR.
[Bug libgcc/61843] Segmentation Fault on with avr-ld when linking with AVR C++ Linker
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61843 --- Comment #2 from peter --- Possibly the same bug as: http://www.avrfreaks.net/index.php?name=PNphpBB2&file=printview&t=136763&start=0 segmentation fault goes away if I remove the -mrelax linker flag.
[Bug middle-end/61848] New: a previous declaration causes the section attribute to be lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848
Bug ID: 61848
Summary: a previous declaration causes the section attribute to
be lost
Product: gcc
Version: 4.10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: pinskia at gcc dot gnu.org
Take:
void f(void);
void __attribute__ ((__section__(".init.text"))) f(void)
{
}
CUT ---
The section attribute is lost from the function.
at -O1, -O0, -Og we get:
.file"t.c"
.text
.globlf
.typef, @function
f:
.LFB0:
.cfi_startproc
rep; ret
.cfi_endproc
.LFE0:
.sizef, .-f
.ident "GCC: (GNU) 4.10.0 20140718 (experimental)"
.section.note.GNU-stack,"",@progbits
While at -O2 and above (including -Os), we get:
.file"t.c"
.section.text.unlikely,"ax",@progbits
.LCOLDB0:
.text
.LHOTB0:
.p2align 4,,15
.globlf
.typef, @function
f:
.LFB0:
.cfi_startproc
rep; ret
.cfi_endproc
.LFE0:
.sizef, .-f
.section.text.unlikely
.LCOLDE0:
.text
.LHOTE0:
.ident"GCC: (GNU) 4.10.0 20140718 (experimental)"
.section.note.GNU-stack,"",@progbits
Notice how f is no longer in the correct section.
If we comment out the declaration (prototype), we get:
.file"t.c"
.section.init.text,"ax",@progbits
.globlf
.typef, @function
f:
.LFB0:
.cfi_startproc
rep; ret
.cfi_endproc
.LFE0:
.sizef, .-f
.ident"GCC: (GNU) 4.10.0 20140718 (experimental)"
.section.note.GNU-stack,"",@progbits
[Bug middle-end/61848] [4.10 Regression] a previous declaration causes the section attribute to be lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848 Andrew Pinski changed: What|Removed |Added Keywords||wrong-code Target Milestone|--- |4.10.0 Summary|a previous declaration |[4.10 Regression] a |causes the section |previous declaration causes |attribute to be lost|the section attribute to be ||lost Severity|normal |blocker --- Comment #1 from Andrew Pinski --- This causes the kernel to output messages like: WARNING: arch/arm64/mm/built-in.o(.text.unlikely+0x104): Section mismatch in reference from the function mem_init() to the function .init.text:arm64_swiotlb_init() The function mem_init() references the function __init arm64_swiotlb_init(). This is often because mem_init lacks a __init annotation or the annotation of arm64_swiotlb_init is wrong.
[Bug libstdc++/61849] New: exp(NaN+0_i) returns wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61849
Bug ID: 61849
Summary: exp(NaN+0_i) returns wrong value
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: bolero.murakami at gmail dot com
exp(NaN+0_i) returns NaN+NaN_i.
However, it should returns NaN+0_i correctly.
ISO/IEC 9899:1999
G.6.3.1 The cexp functions
— cexp(NaN + i0) returns NaN + i0.
Code:
//
#include
#include
#include
int main() {
using complex = std::complex;
auto NaN = std::numeric_limits::quiet_NaN();
// should be (nan,0), but (nan,nan)
std::cout << std::exp(complex(NaN, +0.)) << std::endl;
// should be (nan,-0), but (nan,nan)
std::cout << std::exp(complex(NaN, -0.)) << std::endl;
}
//
http://melpon.org/wandbox/permlink/asWdib1m9tY4zICI
[Bug fortran/61847] bug in gfortran runtime on OSX: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-07-19 CC||jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jerry DeLisle --- I can reproduce the results. I am not very familiar with locale so will have to study further
[Bug libstdc++/61849] exp(NaN+0_i) returns wrong value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61849 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |MOVED --- Comment #1 from Andrew Pinski --- This is a bug in your C library as GCC just emits a call to cexp. The Glibc bug was filed as https://sourceware.org/bugzilla/show_bug.cgi?id=15532 and fixed in glibc 2.19.
[Bug middle-end/61848] [4.10 Regression] a previous declaration causes the section attribute to be lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848 --- Comment #2 from Andrew Pinski --- Most likely caused by: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=738a6bdaaa22a526fae65016127c229d99f377b4 There is this comment in c-decl.c: /* Copy the assembler name. Currently, it can only be defined in the prototype. */
[Bug middle-end/61848] [4.10 Regression] a previous declaration causes the section attribute to be lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848
--- Comment #3 from Andrew Pinski ---
The documentation does not say it has to be only in the declaration:
section ("section-name")
Normally, the compiler places the code it generates in the text section.
Sometimes, however, you need additional sections, or you need certain
particular functions to appear in special sections. The section attribute
specifies that a function lives in a particular section. For example, the
declaration:
extern void foobar (void) __attribute__ ((section ("bar")));
puts the function foobar in the bar section.
Some file formats do not support arbitrary sections so the section attribute is
not available on all platforms. If you need to map the entire contents of a
module to a particular section, consider using the facilities of the linker
instead.
[Bug middle-end/61848] [4.10 Regression] a previous declaration causes the section attribute to be lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848 --- Comment #4 from Andrew Pinski --- I think we are merging the decls incorrectly. We are only merging the section name one way and both.
[Bug middle-end/61848] [4.10 Regression] a previous declaration causes the section attribute to be lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-07-19 Assignee|unassigned at gcc dot gnu.org |pinskia at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #5 from Andrew Pinski --- I have a fix.
[Bug fortran/61847] bug in gfortran runtime on OSX: digits cut off when reading floating point number
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61847 --- Comment #2 from Jerry DeLisle --- Please see PR36857 for some background. gfortran uses the glibc strtod functions to convert the string to real. I think in your C code you need to do something like this: setlocale(LC_ALL, "C"); badcall_(); setlocale(LC_ALL, "de_DE.UTF-8"); and then if your locale does use comma for the decimal point, do this on the FORTRAN side. open(unit=1,file='bug.dat', decimal="comma")
[Bug middle-end/61848] [4.10 Regression] a previous declaration causes the section attribute to be lost
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61848 --- Comment #6 from Andrew Pinski --- Created attachment 33156 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33156&action=edit Patch which I am testing Patch to the C front-end which merges the section name both directions and not just from the old decl to the new one (functions decls discard the new one anyways).
