[Bug rtl-optimization/55838] [4.6/4.7/4.8 Regression] ICE in extract_insn (unrecognizable insn) with -O -funroll-loops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55838 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org, ||rakdver at gcc dot gnu.org --- Comment #11 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-02 08:24:34 UTC --- I wonder if that isn't unnecessarily pessimizing, plus it won't catch all cases anyway, steps can be added etc. afterwards, in the extend_mode/comp_mode. The following fixes the ICE for me too, the second hunk is supposedly not enough, because in some places afterwards we e.g. count inc from iv0.step and iv1.step directly, plus for say comp_mode SImode and mode QImode with iv0.step 256 we supposedly want to bail out early (infinite loop or zero iterations). --- gcc/loop-iv.c.jj2012-10-22 08:42:25.0 +0200 +++ gcc/loop-iv.c2013-01-02 09:17:42.215591646 +0100 @@ -2406,6 +2406,9 @@ iv_number_of_iterations (struct loop *lo iv1.step = const0_rtx; } + iv0.step = lowpart_subreg (mode, iv0.step, comp_mode); + iv1.step = lowpart_subreg (mode, iv1.step, comp_mode); + /* This is either infinite loop or the one that ends immediately, depending on initial values. Unswitching should remove this kind of conditions. */ if (iv0.step == const0_rtx iv1.step == const0_rtx) @@ -2516,6 +2519,7 @@ iv_number_of_iterations (struct loop *lo step = simplify_gen_unary (NEG, comp_mode, iv1.step, comp_mode); else step = iv0.step; + step = lowpart_subreg (mode, step, comp_mode); delta = simplify_gen_binary (MINUS, comp_mode, iv1.base, iv0.base); delta = lowpart_subreg (mode, delta, comp_mode); delta = simplify_gen_binary (UMOD, mode, delta, step);
[Bug rtl-optimization/55547] [4.8 Regression] Alias analysis does not handle AND addresses correctly
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55547 --- Comment #7 from Uros Bizjak ubizjak at gmail dot com 2013-01-02 08:30:26 UTC --- Alexandre, do you plan to proceed with the patch in Comment #4?
[Bug middle-end/55832] [4.8 Regression] ICE in fold_convert_loc, at fold-const.c:1967
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55832 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-02 09:07:06 UTC --- Created attachment 29072 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29072 gcc48-pr55832.patch Indeed, and omit_one_operand_loc can deal with converting integer_zero_node to a zero vector, but can't cope with converting integer_one_node into a constant boolean true vector. I've slightly adjusted the testcase, so that it at least doesn't violate strict aliasing, unfortunately without the uninitialized c it doesn't trigger. And I couldn't find a way to create ABS_EXPR of vectors using vector types directly.
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561
--- Comment #29 from Dmitry Vyukov dvyukov at google dot com 2013-01-02
09:09:11 UTC ---
(In reply to comment #28)
(In reply to comment #26)
For config/linux/ptrlock the changes are:
[...]
Following your suggestions, I applied the following patch (mistakes are mine),
which allows me to run without warnings from libgomp:
Index: config/linux/wait.h
===
--- config/linux/wait.h (revision 194730)
+++ config/linux/wait.h (working copy)
@@ -51,7 +51,7 @@
if (__builtin_expect (gomp_managed_threads gomp_available_cpus, 0))
count = gomp_throttled_spin_count_var;
for (i = 0; i count; i++)
-if (__builtin_expect (*addr != val, 0))
+if (__builtin_expect (__atomic_load_n(addr,MEMMODEL_RELAXED) != val, 0))
return 0;
else
cpu_relax ();
Index: config/linux/ptrlock.c
===
--- config/linux/ptrlock.c (revision 194730)
+++ config/linux/ptrlock.c (working copy)
@@ -50,9 +50,9 @@
#endif
do
do_wait (intptr, 2);
- while (*intptr == 2);
+ while (__atomic_load_n(intptr, MEMMODEL_RELAXED) == 2);
__asm volatile ( : : : memory);
- return *ptrlock;
+ return (void*)__atomic_load_n(ptrlock, MEMMODEL_ACQUIRE);
}
void
Index: config/linux/ptrlock.h
===
--- config/linux/ptrlock.h (revision 194730)
+++ config/linux/ptrlock.h (working copy)
@@ -48,8 +48,9 @@
{
uintptr_t oldval;
- if ((uintptr_t) *ptrlock 2)
-return *ptrlock;
+ uintptr_t v = (uintptr_t)__atomic_load_n(ptrlock, MEMMODEL_ACQUIRE);
+ if (v 2)
+return (void*)v;
oldval = 0;
if (__atomic_compare_exchange_n (ptrlock, oldval, 1, false,
Great!
Please post the patch to http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40362
I believe it is the correct fix for the bug.
[Bug c++/54526] [C++11] :: is incorrectly treated as digraph : followed by colon
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54526 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com 2013-01-02 09:12:53 UTC --- Let's keep this open.
[Bug rtl-optimization/55845] New: 454.calculix miscompares with -march=btver2 -O3 -ffastmath -fschedule-insns -mvzeroupper for test data run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55845 Bug #: 55845 Summary: 454.calculix miscompares with -march=btver2 -O3 -ffastmath -fschedule-insns -mvzeroupper for test data run Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: rtl-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: venkataramanan.ku...@amd.com Host: x86_64-unknown-linux-gnu Target: x86_64-unknown-linux-gnu Build: x86_64-unknown-linux-gnu GCC revision used: 194705 Flags used: -march=btver2 -O3 -ffastmath -fschedule-insns -mvzeroupper Observation: (Snip) *** Miscompare of beampic.dat; for details see /local/home/vekumar/specruns/benchspec/CPU2006/454.calculix/run/run_base_test_gcc480_bt_sched.exe_nofma./beampic.dat.mis Error: 1x454.calculix Producing Raw Reports (Snip) On triaging further the file SPOOLES/Utilities/src/Utilities_DV.Utilities_DV.c when compiled with -march=btver2 -O3 -ffastmath -fschedule-insns -mvzeroupper seems to schedule vzeroupper incorrectly. vzeroupper will clobber all ymm registers, so should not be moved arround. Also using -march=corei7-avx seems to have problem. I am drilling down further.
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #30 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-02 09:43:29 UTC --- The formatting in the patch is wrong (multiple issues). I don't see a point in the __atomic_load_n (addr, MEMMODEL_RELAXED), for aligned ints or pointers the loads are atomic on all architectures libgomp is supported on, after all kernel is also using just a normal load in the futex syscall, not __atomic_load_n (which expands to the normal load only anyway).
[Bug rtl-optimization/55845] 454.calculix miscompares with -march=btver2 -O3 -ffastmath -fschedule-insns -mvzeroupper for test data run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55845 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added CC||vbyakovl23 at gmail dot com --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2013-01-02 10:10:01 UTC --- Adding CC.
[Bug rtl-optimization/55845] 454.calculix miscompares with -march=btver2 -O3 -ffastmath -fschedule-insns -mvzeroupper for test data run
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55845 --- Comment #2 from Uros Bizjak ubizjak at gmail dot com 2013-01-02 10:15:16 UTC --- It looks to me that scheduler is doing something with unspec_volatile instructions, since vzeroupper insertion will be cancelled if there are live call-saved SSE registers at the insertion point. Please see ix86_avx_emit_vzeroupper function in i386.c
[Bug bootstrap/55784] [4.8 regression] declaration of C function 'const char* strsignal(int)' conflicts with /usr/include/string.h:112: error: previous declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55784 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org |gnu.org | --- Comment #10 from Richard Biener rguenth at gcc dot gnu.org 2013-01-02 10:26:25 UTC --- I'm combining the patches from comment#3 and comment#5, do a bootstrap and regtest and commit them.
[Bug sanitizer/55561] TSAN: Fortran/OMP yields false positives
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55561 --- Comment #31 from Dmitry Vyukov dvyukov at google dot com 2013-01-02 10:28:00 UTC --- (In reply to comment #30) The formatting in the patch is wrong (multiple issues). I don't see a point in the __atomic_load_n (addr, MEMMODEL_RELAXED), for aligned ints or pointers the loads are atomic on all architectures libgomp is supported on, after all kernel is also using just a normal load in the futex syscall, not __atomic_load_n (which expands to the normal load only anyway). Do you agree about MEMMODEL_ACQUIRE? Regarding MEMMODEL_RELAXED, there are 2 reasons to use it correctness aside. First, it greatly contributes to code readability and self-documentation, and allows readers to easily distinguish between plain loads and inter-thread synchronization shared loads which are hideously different things. Seconds, it allows tools like tsan to work properly on such code and point to more serious issues (like that MEMMODEL_ACQUIRE above). As for correctness, below is an example that I usually provide (and there is also How to miscompile programs with benign data races paper by Boehm with other good examples): - Consider that you have an atomic (which is not actually marked as atomic for compiler) store and some code w/o sync operations around it (potentially from inlined functions): ... *p = x; ... C++ compiler assumes absence of data races. So if it sees a store to p, then it is allowed to use it as a scratch storage for any garbage in the same synchronization region. I.e. it can do: ... *p = foo; ... *p = x; ... Note that it can't affect any correct race-free program. This way, other threads will read random garbage from p. Now imagine that foo is a function pointer: ... *p = foo; // spill from register ... foo = *p; // restore to register if (bar) foo(); // and execute ... *p = x; ... Now imagine that this thread spills ReadFile to p, and another thread spills LaunchNuclearMissle to p in between (but was not intended to execute it due to bar==0). Ooops, this benign race just caused accidental launch of nuclear missiles.
[Bug tree-optimization/55823] [4.8 Regression] ice in inline_call, at ipa-inline-transform.c:270
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55823 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1
[Bug tree-optimization/55833] ICE in verify_loop_structure, at cfgloop.c:1582 (BB should be marked irreducible !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55833 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-02 CC||mpolacek at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org 2013-01-02 10:33:06 UTC --- Thus marking as NEW. Related to PR52996.
[Bug c++/55842] [4.7/4.8 Regression] C++11 ICE with boost multi-precision and boost variant
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55842 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-02 Known to work||4.6.3 Target Milestone|--- |4.7.3 Summary|C++11 ICE with boost|[4.7/4.8 Regression] C++11 |multi-precision and boost |ICE with boost |variant |multi-precision and boost ||variant Ever Confirmed|0 |1 Known to fail||4.7.0, 4.8.0 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-01-02 10:35:07 UTC --- Confirmed.
[Bug middle-end/55840] valgrind errors in sparseset.h
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55840 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-01-02 10:35:50 UTC --- That's known and not a bug (there is a dup of this).
[Bug lto/54728] [4.8 regression] ICE in input_gimple_stmt, at gimple-streamer-in.c:254
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54728 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org 2013-01-02 10:41:32 UTC --- Fixed.
[Bug tree-optimization/55802] Various missed optimizations for a simple function in GCC itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55802 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-01-02 11:00:54 UTC --- The sink issue is that we cannot sink PHI nodes: bb 4: ... if (_11 _20) goto bb 5; else goto bb 6; bb 5: _26 = _19-block_info; _27 = (long unsigned int) _11; _28 = _27 * 8; _29 = _26 + _28; bb 6: # _30 = PHI 0B(4), _29(5) ... if (_14 != 0) goto bb 8; else goto bb 7; bb 7: op2_12 = _30-out; ... to be able to sink the definition of _30 into basic-block 7 we'd have to sink the whole control structure. Similar to how we only (very) weakly handle hoisting loop invaraint conditional code we cannot at all sink conditional code. - more specific bug
[Bug tree-optimization/55846] New: Cannot sink conditional code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55846
Bug #: 55846
Summary: Cannot sink conditional code
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: enhancement
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: rgue...@gcc.gnu.org
Blocks: 55802
Code sinking (tree-ssa-sink.c) cannot sink conditional code:
int foo (int b, int c)
{
int res = 0;
if (b)
res = b * 2 + 4;
if (c)
return res;
return 0;
}
here we want to sink the whole if (b) res = b * 2 + 4; block into
the if (c) block.
Profitable if the original conditional becomes dead after sinking
the PHI node for 'res' and its dependencies.
Happens in GCC itself - usually exposed via inlining.
[Bug tree-optimization/55802] Various missed optimizations for a simple function in GCC itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55802
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2013-01-02
Ever Confirmed|0 |1
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-01-02
11:12:11 UTC ---
The -block_info load is
if (a)
and load -block_info
if (b)
and load -block_info
-block_info isn't used outside of the conditional regions so this is
neither a hoisting nor a missed (partial) redundancy opportunity.
We might be able to speculate loading -block_info, but speculating
indirect loads would only be possible if we know the load will never
trap (which in this case we might derive from the fact that we load
-block_info_size unconditionally). phiopt does some load speculation
already - but for adjacent loads only, like
if (...)
x = y-left;
else
x = y-right;
which then enables conditional move generation.
But I guess the case from this bug would fit parts of the framework
that are already present in phiopt. Eventually cselim could be
used to speculate the loads as well.
Note that SCCVN already value-numbers both loads the same (but for some
reason _not_ the dependent calculation ...).
This we track here.
[Bug tree-optimization/55802] Various missed optimizations for a simple function in GCC itself
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55802 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-01-02 11:13:52 UTC --- Note that SCCVN already value-numbers both loads the same (but for some reason _not_ the dependent calculation ...). This we track here. Ah, of course - they are not the same.
[Bug tree-optimization/55833] ICE in verify_loop_structure, at cfgloop.c:1582 (BB should be marked irreducible !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55833 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org 2013-01-02 11:22:00 UTC --- Cannot reproduce with xgcc (GCC) 4.6.4 20130102 (prerelease).
[Bug tree-optimization/55833] ICE in verify_loop_structure, at cfgloop.c:1582 (BB should be marked irreducible !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55833 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org 2013-01-02 11:30:37 UTC --- (In reply to comment #3) Cannot reproduce with xgcc (GCC) 4.6.4 20130102 (prerelease). Make sure to have checking enabled.
[Bug rtl-optimization/55833] [4.6/4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1582 (BB should be marked irreducible !)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55833 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Component|tree-optimization |rtl-optimization Known to work||4.1.2, 4.7.2 Target Milestone|--- |4.6.4 Summary|ICE in |[4.6/4.8 Regression] ICE in |verify_loop_structure, at |verify_loop_structure, at |cfgloop.c:1582 (BB should |cfgloop.c:1582 (BB should |be marked irreducible !)|be marked irreducible !) Known to fail||4.3.6 --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org 2013-01-02 11:33:28 UTC --- Also fails with 4.3.6, works with 4.1.2 though. Thus, technically a regression. Seems to work with 4.7 as well. RTL unswitching.
[Bug bootstrap/55784] [4.8 regression] declaration of C function 'const char* strsignal(int)' conflicts with /usr/include/string.h:112: error: previous declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55784 --- Comment #11 from Richard Biener rguenth at gcc dot gnu.org 2013-01-02 11:57:36 UTC --- Author: rguenth Date: Wed Jan 2 11:57:31 2013 New Revision: 194804 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194804 Log: 2013-01-02 Richard Biener rguent...@suse.de PR bootstrap/55784 * configure.ac: Add $GMPINC to CFLAGS/CXXFLAGS. * configure: Regenerate. ada/ * gcc-interface/Makefile.in: Add $(GMPINC) to includes. Modified: trunk/gcc/ChangeLog trunk/gcc/ada/ChangeLog trunk/gcc/ada/gcc-interface/Makefile.in trunk/gcc/configure trunk/gcc/configure.ac
[Bug bootstrap/55784] [4.8 regression] declaration of C function 'const char* strsignal(int)' conflicts with /usr/include/string.h:112: error: previous declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55784 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Richard Biener rguenth at gcc dot gnu.org 2013-01-02 11:58:08 UTC --- Fixed.
[Bug testsuite/55780] effective targets arm_arch_v*_multilib are not strict enough
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55780
gretay at gcc dot gnu.org changed:
What|Removed |Added
CC||gretay at gcc dot gnu.org
--- Comment #1 from gretay at gcc dot gnu.org 2013-01-02 12:17:07 UTC ---
The intention of arm_arch_v*_multilib is to check which multilibs available in
the toolchain rather than hardware capabilities. These effective target checks
fail at link time, but there is no check_link procedure in gcc/testsuite/lib so
check_runtime is used instead.
For example, using compiler with armv7a (cortex-a15) libraries only,
arm_arch_v6m_multilib effective target check fails and the test is UNSUPPORTED
in my setting on qemu:
$ cat arm_arch_v6m_multilib8582.c
int
main (void)
{
return 0;
}
$ /work/dec-builds/base/install/bin/arm-none-eabi-gcc
arm_arch_v6m_multilib8582.c -fno-diagnostics-show-caret -march=armv6-m
-mthumb -DSTACK_SIZE=16384 -lm -o arm_arch_v6m_multilib8582.exe
/work/dec-builds/base/install/lib/gcc/arm-none-eabi/4.8.0/../../../../arm-none-eabi/bin/ld:
error: /tmp/ccwSCtn0.o: Conflicting architecture profiles M/A
/work/dec-builds/base/install/lib/gcc/arm-none-eabi/4.8.0/../../../../arm-none-eabi/bin/ld:
failed to merge target specific data of file /tmp/ccwSCtn0.o
collect2: error: ld returned 1 exit status
UNSUPPORTED: gcc.target/arm/ftest-armv6m-thumb.c
Configured with: --target=arm-none-eabi --with-newlib --with-gnu-as
--with-gnu-ld --enable-languages=c,c++ --disable-shared --disable-nls
--disable-threads --disable-lto --disable-tls --enable-checking=yes
--disable-libssp --disable-libgomp --disable-libmudflap --with-cpu=cortex-a15
--with-fpu=neon-vfpv4 --with-float=softfp
Thread model: single
gcc version 4.8.0 20121213 (experimental) (GCC)
[Bug libstdc++/55847] New: mistake bad_weak_ptr::what() message
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55847 Bug #: 55847 Summary: mistake bad_weak_ptr::what() message Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: faithandbr...@gmail.com C++11 Standard says follow: 20.7.2.1 p2 bad_weak_ptr() noexcept; Postconditions: what() returns bad_weak_ptr But, libstdc++'s bad_weak_ptr::what() return std::bad_weak_ptr. std:: is unnecessary.
[Bug fortran/55172] [4.7/4.8 Regression] [OOP] ICE on invalid: gfc_variable_attr(): Bad array reference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55172 Paul Thomas pault at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |pault at gcc dot gnu.org |gnu.org | --- Comment #3 from Paul Thomas pault at gcc dot gnu.org 2013-01-02 12:34:35 UTC --- (In reply to comment #2) I suspect the 4.8-problem of having only the ICE without a prior error message might be due to this commit: http://gcc.gnu.org/viewcvs?view=revisionrevision=187192 I think the function 'copy_ts_from_selector_to_associate' comes too early (namely during parsing). It tries to resolve the target expr, which should rather wait until resolution stage!?! This is partially correct. Unfortunately, the selector expression comes from the parser with the ar-type == AR_UNKNOWN and it was this that gfc_resolve_expr was putting right. As long as all the variables were declared or had implicit types, all was well. Th is fixed by removing the call to gfc_resolve_expr and adding explicit code, copied from resolve_array_ref, to set the correct type. It is also necessary/advisable to add a call to resolve the selector expression in resolve_select_type. I will submit a patch later today. Cheers Paul PS If the index 'i' is declared, wrong code results as in pr54990.
[Bug lto/54728] [4.8 regression] ICE in input_gimple_stmt, at gimple-streamer-in.c:254
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54728 --- Comment #13 from Dmitry G. Dyachenko dimhen at gmail dot com 2013-01-02 13:47:43 UTC --- fix original problem for me too Thank You
[Bug libstdc++/55728] std::bad_function_call has misleading what() result
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55728 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2013-01-02 14:18:24 UTC --- Maybe for consistency with bad_weak_ptr it should return bad_function_call without the std:: qualification (see Bug 55847)
[Bug lto/55848] New: internal compiler error: verify_cgraph_node failed (with `-flto' and `-fopenmp')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55848
Bug #: 55848
Summary: internal compiler error: verify_cgraph_node failed
(with `-flto' and `-fopenmp')
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ai.az...@gmail.com
Created attachment 29073
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29073
Output of -v option and preprocessed file
The following C++ source code results in an ICE when compiling on GCC 4.8.0
20121230 with `-flto' and `-fopenmp' command-line options.
//
typedef long unsigned int size_t;
extern C {
extern int omp_get_thread_num (void) throw ();
}
extern C {
extern int snprintf(char *__restrict __s, size_t __maxlen, const char
*__restrict __format, ...) throw ()
__attribute__ ((__format__ (__printf__, 3, 4)));
}
void f()
{
char msg[1024] = ;
snprintf( msg, sizeof(msg)-1, [%d] , omp_get_thread_num() );
}
void g()
{
#pragma omp parallel for
for( int i = 0; i 0; i += 1 ) {
f();
}
}
//
Note that the ICE is not reproduced with GCC 4.6.4 20121228 or 4.7.3 20121229.
[Bug c++/55804] [4.7/4.8 regression] GCC omits required call to constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55804 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jason at gcc dot gnu.org |gnu.org | Severity|blocker |normal
[Bug lto/55848] [4.8 Regression] internal compiler error: verify_cgraph_node failed (with `-flto' and `-fopenmp')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55848 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-02 CC||hubicka at gcc dot gnu.org, ||rguenth at gcc dot gnu.org Target Milestone|--- |4.8.0 Summary|internal compiler error:|[4.8 Regression] internal |verify_cgraph_node failed |compiler error: |(with `-flto' and |verify_cgraph_node failed |`-fopenmp') |(with `-flto' and ||`-fopenmp') Ever Confirmed|0 |1 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org 2013-01-02 15:11:05 UTC --- Confirmed. The ICE is lto1: error: edge points to wrong declaration: function_decl 0x7fc05f843f00 omp_get_thread_num type function_type 0x7fc05f84a2a0 type integer_type 0x7fc05f7165e8 int public SI size integer_cst 0x7fc05f71a0a0 constant 32 unit size integer_cst 0x7fc05f71a0c0 constant 4 align 32 symtab 0 alias set -1 canonical type 0x7fc05f7165e8 precision 32 min integer_cst 0x7fc05f71a040 -2147483648 max integer_cst 0x7fc05f71a060 2147483647 pointer_to_this pointer_type 0x7fc05f71e2a0 QI size integer_cst 0x7fc05f705ee0 constant 8 unit size integer_cst 0x7fc05f705f00 constant 1 align 8 symtab 0 alias set -1 canonical type 0x7fc05f84a348 arg-types tree_list 0x7fc05f7106b8 value void_type 0x7fc05f716bd0 void pointer_to_this pointer_type 0x7fc05f84a888 addressable used nothrow public external QI file t.ii line 4 col 14 align 8 context translation_unit_decl 0x7fc05f721e60 D.2381 Instead of: function_decl 0x7fc05f7b7100 __builtin_omp_get_thread_num type function_type 0x7fc05f7253f0 type integer_type 0x7fc05f7165e8 int public SI size integer_cst 0x7fc05f71a0a0 constant 32 unit size integer_cst 0x7fc05f71a0c0 constant 4 align 32 symtab 0 alias set -1 canonical type 0x7fc05f7165e8 precision 32 min integer_cst 0x7fc05f71a040 -2147483648 max integer_cst 0x7fc05f71a060 2147483647 pointer_to_this pointer_type 0x7fc05f71e2a0 QI size integer_cst 0x7fc05f705ee0 constant 8 unit size integer_cst 0x7fc05f705f00 constant 1 align 8 symtab 0 alias set -1 canonical type 0x7fc05f7253f0 arg-types tree_list 0x7fc05f7106b8 value void_type 0x7fc05f716bd0 void readonly addressable nothrow public external built-in QI file built-in line 0 col 0 align 8 built-in BUILT_IN_NORMAL:BUILT_IN_OMP_GET_THREAD_NUM attributes tree_list 0x7fc05f7b5c30 _Z1fv.2384/0 (f) @0x7fc05f70ea68 Type: function Visibility: force_output prevailing_def_ironly References: Referring: Read from file: /tmp/cclvzgQr.ltrans0.o Availability: available Function flags: analyzed body finalized Called by: _Z1gv._omp_fn.0.2380.2377/4 (1.00 per call) Calls: snprintf/3 (1.00 per call) omp_get_thread_num/2 (1.00 per call) lto1: internal compiler error: verify_cgraph_node failed 0x6344ed verify_cgraph_node(cgraph_node*) /space/rguenther/src/svn/trunk/gcc/cgraph.c:2582 0x62d71c verify_symtab_node(symtab_node_def*) /space/rguenther/src/svn/trunk/gcc/symtab.c:681 0x62d783 verify_symtab() /space/rguenther/src/svn/trunk/gcc/symtab.c:698 0x63bfd1 compile() /space/rguenther/src/svn/trunk/gcc/cgraphunit.c:1973 0x59db35 lto_main() /space/rguenther/src/svn/trunk/gcc/lto/lto.c:3390
[Bug lto/55848] [4.8 Regression] internal compiler error: verify_cgraph_node failed (with `-flto' and `-fopenmp')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55848
--- Comment #2 from Richard Biener rguenth at gcc dot gnu.org 2013-01-02
15:18:47 UTC ---
Reduced C testcase:
extern int omp_get_thread_num (void);
void __attribute ((noinline)) f()
{
omp_get_thread_num();
}
int main()
{
int i;
#pragma omp parallel for
for (i = 0; i 0; i += 1)
f();
return 0;
}
[Bug lto/55848] [4.8 Regression] internal compiler error: verify_cgraph_node failed (with `-flto' and `-fopenmp')
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55848
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |rguenth at gcc dot gnu.org
|gnu.org |
--- Comment #3 from Richard Biener rguenth at gcc dot gnu.org 2013-01-02
15:30:45 UTC ---
The builtin does not prevail over the extern decl for some reason (but it's in
the symtab of course). builtins have LDPR_UNKNOWN resolution, the extern
has LDPR_RESOLVED_DYN.
So we end up with no prevailing decl ... and in
/* If there's not a prevailing symbol yet it's an external reference.
Happens a lot during ltrans. Choose the first symbol with a
cgraph or a varpool node. */
if (!prevailing)
{
prevailing = first;
/* For variables chose with a priority variant with vnode
attached (i.e. from unit where external declaration of
variable is actually used).
When there are multiple variants, chose one with size.
This is needed for C++ typeinfos, for example in
lto/20081204-1 there are typeifos in both units, just
one of them do have size. */
if (TREE_CODE (prevailing-symbol.decl) == VAR_DECL)
{
for (e = prevailing-symbol.next_sharing_asm_name;
e; e = e-symbol.next_sharing_asm_name)
if (!COMPLETE_TYPE_P (TREE_TYPE (prevailing-symbol.decl))
COMPLETE_TYPE_P (TREE_TYPE (e-symbol.decl)))
prevailing = e;
}
}
where we probably should prefer builtins as we never replace those
when fixing up the cgraph.
Mine.
[Bug fortran/55818] Reading a REAL from a file which doesn't end in a new line fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55818 --- Comment #8 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2013-01-02 17:09:17 UTC --- Author: jvdelisle Date: Wed Jan 2 17:09:09 2013 New Revision: 194809 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194809 Log: 2013-01-02 Jerry DeLisle jvdeli...@gcc.gnu.org PR libfortran/55818 * io/list_read.c (read_real): Do not call hit_eof when EOF can be treated as a value separator. (parse_real): Likewise. (read_logical): Likewise. (read_character): Likewise. (read_complex): Likewise. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c
[Bug libfortran/49791] [4.6/4.7/4.8 Regression] Formatted namelist reads fails with: Cannot match namelist object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org --- Comment #23 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2013-01-02 17:17:53 UTC --- I will work this one along with pr51825
[Bug libfortran/50105] [4.6/4.7/4.8 Regression] I/O with g6.5 - wrong number of ** shown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50105 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #20 from Tobias Burnus burnus at gcc dot gnu.org 2013-01-02 17:24:12 UTC --- (In reply to comment #17) 10.7.2.3.2 says the field occupies w positions, the fractional part of which consists of d digits and this does not make sense if wd. Therefore, according to the first sentence of 1.5 Conformance, the program is not standard conforming. There are therefore no requirements on the processor for this program, and it may produce either output, or even a runtime error. Disclaimer: WG5 might still revise the J3 answer; there will be also an J3 email voting on the IR. Latest result version ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1932.txt (search for F08/0063) Result was: YES WITH COMMENTS, with 7 YES votes, 1 YES WITH COMMENT and 1 NO vote (or two? At the top it lists one, below it has two comments claiming a NO.) ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1944.txt Additionally, it is listed in the Corrigendum 2 draft as being contained in the document, though no edits have been done: ftp://ftp.nag.co.uk/sc22wg5/N1901-N1950/N1948.pdf
[Bug sanitizer/55844] -fsanitize=address -Os -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55844 --- Comment #3 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-02 17:31:05 UTC --- we should just move over to using the dwarf unwinder and forget about the manually unwinding the stack Upstream asan-rt has two flags now: -- fast_unwind_on_fatal 1 Use Fast/Slow unwinder when found a bug. The fast one relies on frame pointers, while slow one does not. The default may change to 0 soon. fast_unwind_on_malloc 1 Same as fast_unwind_on_fatal, but control unwinding inside malloc/free, i.e. performance critical. -- I am going to switch the default for fast_unwind_on_fatal to 0 somewhere in Jan and then merge to gcc. fast_unwind_on_malloc will remain 1 by default; see the rationale in http://code.google.com/p/address-sanitizer/issues/detail?id=137#c6
[Bug middle-end/23868] [4.6/4.7/4.8 regression] builtin_apply uses wrong mode for multi-hard-register return values
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23868 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P2 |P4 CC||jakub at gcc dot gnu.org --- Comment #22 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-02 17:55:14 UTC --- SH is neither primary nor secondary target.
[Bug c++/48914] #pragma GCC diagnostic ignored -Wc++0x-compat doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48914 --- Comment #7 from Roger Jarrett rjarrett at mathworks dot com 2013-01-02 18:51:12 UTC --- Additional workaround (big hammer) #pragma GCC system_header Best used when the code generating the warning is in an isolated header file --Roger
[Bug c++/55804] [4.7/4.8 regression] GCC omits required call to constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55804 --- Comment #3 from Jason Merrill jason at gcc dot gnu.org 2013-01-02 19:03:17 UTC --- Author: jason Date: Wed Jan 2 19:03:04 2013 New Revision: 194811 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194811 Log: PR c++/55804 PR c++/55032 PR c++/55245 * tree.c (build_array_type_1): Revert earlier change. * cp/tree.c (build_cplus_array_type): Copy layout information to main variant if necessary. Added: trunk/gcc/testsuite/g++.dg/init/array33.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/tree.c
[Bug c++/55245] [4.6 Regression] Compiler segfault when compiling a small test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245 --- Comment #11 from Jason Merrill jason at gcc dot gnu.org 2013-01-02 19:03:17 UTC --- Author: jason Date: Wed Jan 2 19:03:04 2013 New Revision: 194811 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194811 Log: PR c++/55804 PR c++/55032 PR c++/55245 * tree.c (build_array_type_1): Revert earlier change. * cp/tree.c (build_cplus_array_type): Copy layout information to main variant if necessary. Added: trunk/gcc/testsuite/g++.dg/init/array33.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/tree.c
[Bug c++/55032] [4.7/4.8 Regression] Internal compiler error: in strip_typedefs, at cp/tree.c:1199
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55032 --- Comment #8 from Jason Merrill jason at gcc dot gnu.org 2013-01-02 19:03:19 UTC --- Author: jason Date: Wed Jan 2 19:03:04 2013 New Revision: 194811 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194811 Log: PR c++/55804 PR c++/55032 PR c++/55245 * tree.c (build_array_type_1): Revert earlier change. * cp/tree.c (build_cplus_array_type): Copy layout information to main variant if necessary. Added: trunk/gcc/testsuite/g++.dg/init/array33.C Modified: trunk/gcc/ChangeLog trunk/gcc/cp/ChangeLog trunk/gcc/cp/tree.c trunk/gcc/tree.c
[Bug c++/55032] [4.7/4.8 Regression] Internal compiler error: in strip_typedefs, at cp/tree.c:1199
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55032 --- Comment #9 from Jason Merrill jason at gcc dot gnu.org 2013-01-02 19:03:55 UTC --- Author: jason Date: Wed Jan 2 19:03:37 2013 New Revision: 194812 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194812 Log: PR c++/55804 PR c++/55032 PR c++/55245 * tree.c (build_array_type_1): Revert earlier change. * cp/tree.c (build_cplus_array_type): Copy layout information to main variant if necessary. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/init/array33.C Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/tree.c branches/gcc-4_7-branch/gcc/tree.c
[Bug c++/55032] [4.7/4.8 Regression] Internal compiler error: in strip_typedefs, at cp/tree.c:1199
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55032 --- Comment #10 from Jason Merrill jason at gcc dot gnu.org 2013-01-02 19:04:07 UTC --- Author: jason Date: Wed Jan 2 19:03:46 2013 New Revision: 194813 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194813 Log: PR c++/55804 PR c++/55032 PR c++/55245 * tree.c (build_array_type_1): Revert earlier change. * cp/tree.c (build_cplus_array_type): Copy layout information to main variant if necessary. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/init/array33.C Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/tree.c branches/gcc-4_6-branch/gcc/tree.c
[Bug c++/55245] [4.6 Regression] Compiler segfault when compiling a small test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245 --- Comment #12 from Jason Merrill jason at gcc dot gnu.org 2013-01-02 19:03:55 UTC --- Author: jason Date: Wed Jan 2 19:03:37 2013 New Revision: 194812 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194812 Log: PR c++/55804 PR c++/55032 PR c++/55245 * tree.c (build_array_type_1): Revert earlier change. * cp/tree.c (build_cplus_array_type): Copy layout information to main variant if necessary. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/init/array33.C Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/tree.c branches/gcc-4_7-branch/gcc/tree.c
[Bug c++/55804] [4.7/4.8 regression] GCC omits required call to constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55804 --- Comment #4 from Jason Merrill jason at gcc dot gnu.org 2013-01-02 19:03:57 UTC --- Author: jason Date: Wed Jan 2 19:03:37 2013 New Revision: 194812 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194812 Log: PR c++/55804 PR c++/55032 PR c++/55245 * tree.c (build_array_type_1): Revert earlier change. * cp/tree.c (build_cplus_array_type): Copy layout information to main variant if necessary. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/init/array33.C Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/tree.c branches/gcc-4_7-branch/gcc/tree.c
[Bug c++/55804] [4.7/4.8 regression] GCC omits required call to constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55804 --- Comment #5 from Jason Merrill jason at gcc dot gnu.org 2013-01-02 19:04:10 UTC --- Author: jason Date: Wed Jan 2 19:03:46 2013 New Revision: 194813 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194813 Log: PR c++/55804 PR c++/55032 PR c++/55245 * tree.c (build_array_type_1): Revert earlier change. * cp/tree.c (build_cplus_array_type): Copy layout information to main variant if necessary. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/init/array33.C Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/tree.c branches/gcc-4_6-branch/gcc/tree.c
[Bug c++/55245] [4.6 Regression] Compiler segfault when compiling a small test case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55245 --- Comment #13 from Jason Merrill jason at gcc dot gnu.org 2013-01-02 19:04:07 UTC --- Author: jason Date: Wed Jan 2 19:03:46 2013 New Revision: 194813 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194813 Log: PR c++/55804 PR c++/55032 PR c++/55245 * tree.c (build_array_type_1): Revert earlier change. * cp/tree.c (build_cplus_array_type): Copy layout information to main variant if necessary. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/init/array33.C Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/tree.c branches/gcc-4_6-branch/gcc/tree.c
[Bug libfortran/48785] BOZ editing of real numbers not working with -std=f2008
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48785 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #9 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2013-01-02 20:02:51 UTC --- Looking at transfer.c and trying the test case provided here, I believe this is fixed. Closing.
[Bug c++/55804] [4.7/4.8 regression] GCC omits required call to constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55804 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2013-01-02 20:15:10 UTC --- Fixed.
[Bug fortran/55818] Reading a REAL from a file which doesn't end in a new line fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55818 --- Comment #9 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2013-01-02 20:29:35 UTC --- Author: jvdelisle Date: Wed Jan 2 20:29:28 2013 New Revision: 194819 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194819 Log: 2013-01-02 Jerry DeLisle jvdeli...@gcc.gnu.org PR fortran/55818 * gfortran.dg/eof_4.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/eof_4.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug libfortran/50105] [4.6/4.7/4.8 Regression] I/O with g6.5 - wrong number of ** shown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50105 --- Comment #21 from Jerry DeLisle jvdelisle at gcc dot gnu.org 2013-01-02 20:46:02 UTC --- Based on the interp, current gfortran is acceptable and we can close this PR.
[Bug c++/54325] [4.7/4.8 Regression] C++11 uniform initialization syntax for argument-less abstract base class constructor fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54325 --- Comment #11 from Jason Merrill jason at gcc dot gnu.org 2013-01-02 20:54:46 UTC --- Author: jason Date: Wed Jan 2 20:54:42 2013 New Revision: 194820 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194820 Log: PR c++/54325 * call.c (build_new_method_call_1): Don't use build_value_init for user-provided default constructors. Added: trunk/gcc/testsuite/g++.dg/cpp0x/initlist-protected.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c
[Bug c++/54325] [4.7/4.8 Regression] C++11 uniform initialization syntax for argument-less abstract base class constructor fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54325 --- Comment #12 from Jason Merrill jason at gcc dot gnu.org 2013-01-02 20:56:37 UTC --- Author: jason Date: Wed Jan 2 20:56:29 2013 New Revision: 194821 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194821 Log: PR c++/54325 * call.c (build_new_method_call_1): Don't use build_value_init for user-provided default constructors. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/initlist-protected.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/call.c
[Bug c++/54325] [4.7/4.8 Regression] C++11 uniform initialization syntax for argument-less abstract base class constructor fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54325 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution||FIXED --- Comment #13 from Jason Merrill jason at gcc dot gnu.org 2013-01-02 21:05:46 UTC --- Testcase from comment #1 fixed as well.
[Bug sanitizer/55844] -fsanitize=address -Os -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55844 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-02 21:07:21 UTC --- Could you please do an extra merge soon, even before switching the default? You've raised some cases where on ubuntu _Unwind_* based backtrace wasn't accurrate, it would be nice to check it out on other distros and find out the reason. BTW, glibc backtrace(3) on i?86 (32-bit only) uses a combination of _Unwind_* based backtrace for as long as unwind info is provided, and then grabs ebp from the unwind info at the outermost frame before unwind info isn't provided, and from there attempts to use the fast backtrace method (for cases where older i?86 code when gcc still didn't default to asynchronous unwind tables on i?86 calls newer code where gcc defaults to it). On x86_64 this isn't done, as asynchronous unwind tables have been the default basically for the whole support of the architecture.
[Bug middle-end/55198] [4.8 Regression] libquadmath/math/fmaq.c:233:7: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55198 --- Comment #8 from John David Anglin danglin at gcc dot gnu.org 2013-01-02 21:14:22 UTC --- Author: danglin Date: Wed Jan 2 21:14:13 2013 New Revision: 194822 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194822 Log: PR middle-end/55198 * expr.c (expand_expr_real_1): Don't use bitfield extraction for non BLKmode objects when EXPAND_MEMORY is specified. Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c
[Bug middle-end/55198] [4.8 Regression] libquadmath/math/fmaq.c:233:7: internal compiler error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55198 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||jakub at gcc dot gnu.org Resolution||FIXED --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org 2013-01-02 21:17:01 UTC --- Assuming fixed.
[Bug libfortran/50105] [4.6/4.7/4.8 Regression] I/O with g6.5 - wrong number of ** shown
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50105 Harald Anlauf anlauf at gmx dot de changed: What|Removed |Added CC||anlauf at gmx dot de --- Comment #22 from Harald Anlauf anlauf at gmx dot de 2013-01-02 21:40:03 UTC --- (In reply to comment #17) We should be able to diagnose this at compile time. It might make sense to link PR45129 (and possibly PR28397) to this one as part of a test suite.
[Bug fortran/55849] New: [OOP] Implement temporary support for SELECT TYPE(name = array ( [vector-subscript] ))
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55849 Bug #: 55849 Summary: [OOP] Implement temporary support for SELECT TYPE(name = array ( [vector-subscript] )) Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: rejects-valid Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org From http://gcc.gnu.org/ml/fortran/2013-01/msg4.html. The following program fails with: Error: CLASS selector at (1) needs a temporary which is not yet implemented module gn type :: ncb end type ncb type, public :: tn class(ncb), allocatable, dimension(:) :: cb end type tn contains integer function name(self) implicit none class (tn), intent(in) :: self select type (component = self%cb([4,7+1])) end select end function name end module gn
[Bug fortran/55850] New: [OOP] SELECT TYPE issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55850 Bug #: 55850 Summary: [OOP] SELECT TYPE issues Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Keywords: accepts-invalid, ice-on-invalid-code Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org CC: pa...@gcc.gnu.org a) Accepts invalid with coindexed variables. Fortran 2008: R804 association is associate-name = selector R805 selector is expr or variable C801 (R804) If selector is not a variable or is a variable that has a vector subscript, associate-name shall not appear in a variable definition context (16.6.7). C802 (R804) An associate-name shall not be the same as another associate-name in the same associate-stmt. C803 (R805) variable shall not be a coindexed object. C804 (R805) expr shall not be a variable. I think that prohibits: associate (myname = coarray[i]) For ASSOCIATE, one gets: associate (x = caf[4]) 1 Error: Association target at (1) must not be coindexed But for SELECT TYPE, it is accepted: module gn type :: ncb end type ncb type, public :: tn class(ncb), allocatable :: cb(:)[:] end type tn contains integer function name(self) implicit none class (tn), intent(in) :: self select type (component = self%cb(1)[4]) ! INVALID due to the [4] end select end function name end module gn Note: The problem is not the coarray, just the coindex (gfc_is_coindexed). b) ICE with the following: select type (t = self%cb) Note the = opposed to =. Backtrace: 0x5e32d0 gfc_undo_symbols() ../../gcc/fortran/symbol.c:2972 0x5af3aa reject_statement ../../gcc/fortran/parse.c:1747 0x5af4dc match_word ../../gcc/fortran/parse.c:72 module gn type :: ncb end type ncb type, public :: tn class(ncb), allocatable :: cb end type tn contains integer function name(self) implicit none class (tn), intent(in) :: self select type (t = self%cb) end select end function name end module gn c) The following also ICEs: 0x5cd395 resolve_select_type ../../gcc/fortran/resolve.c:7791 0x5cd395 resolve_code ../../gcc/fortran/resolve.c:9707 module gn type :: ncb end type ncb type, public :: tn type(ncb), allocatable :: cb end type tn contains integer function name(self) implicit none class (tn), intent(in) :: self select type (t = self%cb) type is (ncb) t = 5 end select end function name end module gn
[Bug fortran/55850] [OOP] SELECT TYPE issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55850 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org 2013-01-02 22:45:38 UTC --- See also PR 55172, the coarray issue (http://gcc.gnu.org/ml/fortran/2013-01/msg4.html) and PR 54990.
[Bug target/43961] [ARM thumb] branch out of range with thumb1_output_casesi
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43961 --- Comment #8 from Joseph S. Myers jsm28 at gcc dot gnu.org 2013-01-03 00:00:08 UTC --- Mikael, ping on this patch from June 2010 ... what happened in testing? And shouldn't this bug be marked as a regression, given the identification of the responsible revision?
[Bug middle-end/55851] New: ICE in size_binop_loc, at fold-const.c:1385
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55851 Bug #: 55851 Summary: ICE in size_binop_loc, at fold-const.c:1385 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: jan.sm...@alcatel-lucent.com Created attachment 29074 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29074 testcase Trunk, testcase attached. /tmp/ice.c: In function 'test': /tmp/ice.c:36:45: internal compiler error: in size_binop_loc, at fold-const.c:1385 if ((found_bit_mask[dqs][word] (1 j)) == 0) ^ 0x6de9b5 size_binop_loc(unsigned int, tree_code, tree_node*, tree_node*) ../../trunk/gcc/fold-const.c:1385 0x74c4ec gimplify_compound_lval ../../trunk/gcc/gimplify.c:2239 0x744f5f gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) ../../trunk/gcc/gimplify.c:7146 0x7442b5 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) ../../trunk/gcc/gimplify.c:7459 0x74530b gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) ../../trunk/gcc/gimplify.c:7814 0x74530b gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) ../../trunk/gcc/gimplify.c:7814 0x74530b gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) ../../trunk/gcc/gimplify.c:7814 0x7512bc gimplify_cond_expr ../../trunk/gcc/gimplify.c:3285 0x74542d gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) ../../trunk/gcc/gimplify.c:7150 0x74d978 gimplify_stmt(tree_node**, gimple_statement_d**) ../../trunk/gcc/gimplify.c:5726 0x7449e3 gimplify_statement_list ../../trunk/gcc/gimplify.c:1562 0x7449e3 gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) ../../trunk/gcc/gimplify.c:7583 0x74d978 gimplify_stmt(tree_node**, gimple_statement_d**) ../../trunk/gcc/gimplify.c:5726 0x74e898 gimplify_bind_expr ../../trunk/gcc/gimplify.c:1254 0x7455fe gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) ../../trunk/gcc/gimplify.c:7365 0x74d978 gimplify_stmt(tree_node**, gimple_statement_d**) ../../trunk/gcc/gimplify.c:5726 0x751845 gimplify_cond_expr ../../trunk/gcc/gimplify.c:3349 0x74542d gimplify_expr(tree_node**, gimple_statement_d**, gimple_statement_d**, bool (*)(tree_node*), int) ../../trunk/gcc/gimplify.c:7150 0x74d978 gimplify_stmt(tree_node**, gimple_statement_d**) ../../trunk/gcc/gimplify.c:5726 0x7449e3 gimplify_statement_list ../../trunk/gcc/gimplify.c:1562
[Bug fortran/55852] New: internal compiler error: in gfc_build_intrinsic_call, at fortran/expr.c:4647
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55852 Bug #: 55852 Summary: internal compiler error: in gfc_build_intrinsic_call, at fortran/expr.c:4647 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: latlon90180+gcc_bugzi...@gmail.com Compilation of the following program causes internal compiler error: !--- program bug implicit none Real, allocatable:: a(:) allocate(a(1:3)) print*, ubound((a), 1) ! Bad ! print*, ubound(a, 1) ! OK ! print*, lbound((a), 1) ! OK ! print*, lbound(a, 1) ! OK stop end program bug ! $ gfortran-mp-4.8 -Wall -Wextra bug.F90 f951: internal compiler error: in gfc_build_intrinsic_call, at fortran/expr.c:4647 f951: internal compiler error: Abort trap gfortran-mp-4.8: internal compiler error: Abort trap (program f951) Abort trap $ gfortran-mp-4.8 -v Using built-in specs. COLLECT_GCC=gfortran-mp-4.8 COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.8.0/lto-wrapper Target: x86_64-apple-darwin10 Configured with: ../gcc-4.8-20121223/configure --prefix=/opt/local --build=x86_64-apple-darwin10 --enable-languages=c,c++,objc,obj-c++,fortran,java --libdir=/opt/local/lib/gcc48 --includedir=/opt/local/include/gcc48 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-4.8 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-4.8 --with-gxx-include-dir=/opt/local/include/gcc48/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-ppl=/opt/local --with-cloog=/opt/local --enable-cloog-backend=isl --disable-cloog-version-check --enable-stage1-checking --disable-multilib --enable-lto --enable-libstdcxx-time --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --with-pkgversion='MacPorts gcc48 4.8-20121223_0' Thread model: posix gcc version 4.8.0 20121223 (experimental) (MacPorts gcc48 4.8-20121223_0)
[Bug c++/55853] New: [C++11] ICE calling member function of templated class in lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55853
Bug #: 55853
Summary: [C++11] ICE calling member function of templated class
in lambda
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: kyle.t.kon...@gmail.com
Created attachment 29075
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=29075
preprocessed source
This appears to be similar but not identical to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54604.
Repro case:
#include map
#include functional
using namespace std;
struct tData {
double a;
};
templateclass DataType
class MapWrap {
public:
void Insert(const int p, const DataType data) {
m_[p] = data;
}
functionvoid(const DataType) CreateInserter(functionint(const DataType)
data_to_int) {
return [this, data_to_int](const DataType data) {
Insert(data_to_int(data), data); };
}
private:
mapint, DataType m_;
};
int main(int argc, char **argv) {
MapWraptData m;
auto fn = m.CreateInserter([](const tData d) { return static_castint(d.a);
});
fn({12});
}
[Bug c++/55853] [C++11] ICE calling member function of templated class in lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55853 --- Comment #1 from Kyle Konrad kyle.t.konrad at gmail dot com 2013-01-03 01:13:26 UTC --- I forgot to mention that adding this- to the Insert() call causes compilation to succeed.
[Bug c++/55853] [C++11] ICE calling member function of templated class in lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55853 --- Comment #2 from Kyle Konrad kyle.t.konrad at gmail dot com 2013-01-03 01:15:56 UTC --- Version information: $ g++ -v Using built-in specs. COLLECT_GCC=g++ COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.7/lto-wrapper Target: x86_64-linux-gnu Configured with: ../src/configure -v --with-pkgversion='Debian 4.7.2-4' --with-bugurl=file:///usr/share/doc/gcc-4.7/README.Bugs --enable-languages=c,c++,go,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.7 --enable-shared --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.7 --libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-gnu-unique-object --enable-plugin --enable-objc-gc --with-arch-32=i586 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu Thread model: posix gcc version 4.7.2 (Debian 4.7.2-4)
[Bug middle-end/55851] ICE in size_binop_loc, at fold-const.c:1385
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55851 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-03 01:28:28 UTC --- What options are you using and what is the target?
[Bug middle-end/55851] ICE in size_binop_loc, at fold-const.c:1385
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55851 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-03 01:33:19 UTC --- This works for me on x86_64-linux-gnu with revision 194774.
[Bug middle-end/55851] ICE in size_binop_loc, at fold-const.c:1385
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55851 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Target||i?86-*-* --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-03 01:36:09 UTC --- apinski@apinskidesktop:~$ ./gcc-126/bin/gcc ice.c -m32 ice.c: In function ‘test’: ice.c:36:45: internal compiler error: in size_binop_loc, at fold-const.c:1385 if ((found_bit_mask[dqs][word] (1 j)) == 0) Needed -m32.
[Bug middle-end/55851] ICE in size_binop_loc, at fold-const.c:1385
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55851
--- Comment #4 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-03
01:42:37 UTC ---
Confirmed reduced testcase:
enum { A=1 } something = A;
void test(void)
{
char found_bit_mask[1][something];
found_bit_mask[0][0] = 1;
}
--- CUT
Fails with:
GNU C (GCC) version 4.8.0 20121127 (experimental) [trunk revision 193870]
(x86_64-unknown-linux-gnu)
[Bug middle-end/55851] [4.8 Regression] ICE in size_binop_loc, at fold-const.c:1385
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55851 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-01-03 Known to work||4.7.0 Target Milestone|--- |4.8.0 Summary|ICE in size_binop_loc, at |[4.8 Regression] ICE in |fold-const.c:1385 |size_binop_loc, at ||fold-const.c:1385 Ever Confirmed|0 |1 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org 2013-01-03 01:47:47 UTC --- Confirmed a regression from 4.7.0.
[Bug fortran/55854] New: ICE on intent(out) dummy argument with unlimited polymorphic component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55854 Bug #: 55854 Summary: ICE on intent(out) dummy argument with unlimited polymorphic component Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: dam...@rouson.net As demonstrated below, having an intent(out) dummy argument with an unlimited polymorphic component generates an internal compiler error with a December 23 build of gfortran 4.8: $ cat ice_on_intent_out_with_unlimted.f90 type foo class(*), allocatable :: x end type contains subroutine bar(this) type(foo), intent(out) :: this end end $ gfortran ice_on_intent_out_with_unlimted.f90 ice_on_intent_out_with_unlimted.f90: In function 'bar': ice_on_intent_out_with_unlimted.f90:5:0: internal compiler error: Segmentation fault: 11 subroutine bar(this) ^ ice_on_intent_out_with_unlimted.f90:5:0: internal compiler error: Abort trap: 6 gfortran: internal compiler error: Abort trap: 6 (program f951) Abort trap: 6 $ gfortran --version GNU Fortran (MacPorts gcc48 4.8-20121223_0) 4.8.0 20121223 (experimental)
[Bug libgcj/50895] Build failure in jni.cc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50895 Nicholas Wourms nwourms at gmail dot com changed: What|Removed |Added CC||nwourms at gmail dot com --- Comment #6 from Nicholas Wourms nwourms at gmail dot com 2013-01-03 03:03:13 UTC --- (In reply to comment #4) A question about this build-failure. Were you using posix-threading model for 4.6 ? I can't speak for Ruben, but now that thread models have been inextricably entwined into the core compiler, libjava really should be updated to handle mingw64's posix thread support. It shouldn't be too difficult, but does require some unraveling of the various Posix/Win32 native functions. I think the main problem is the lack of any decent signal handling in win32. As such, files such as: libjava/java/lang/natWin32Process.cc libjava/gnu/java/nio/natVMSelectorWin32.cc seem to involve event handling that is linked to Win32 threading model, specifically using the _Jv_Win32GetInterruptEvent() function. It appears that libjava/win32-threads.cc also has some similarities to the underlying pthread_cond* implementation in mingw-w64's pthreads library, so in theory it could just be a matter of porting the interrupt event handlers to posix-threads.cc to provide ifdef'd alternates to the signal handlers. Alternatively, Kai and friends at mingw-w64 could implement improved signal handling in librt, but that may be defeating the purpose of mingw.
[Bug sanitizer/55844] -fsanitize=address -Os -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -m64 doesn't work
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55844 --- Comment #5 from Kostya Serebryany kcc at gcc dot gnu.org 2013-01-03 06:17:38 UTC --- Could you please do an extra merge soon, even before switching the default? I'll start somewhere after Jan 10. (I am on holidays before that. There are substantial changes in asan-rt, I afraid I won't be able to fix things if they break on non-x86 before I am back to office)
[Bug fortran/55855] New: incorrect warning with type-bound procedure pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55855 Bug #: 55855 Summary: incorrect warning with type-bound procedure pointer Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: abenso...@gmail.com The following: module eventMod type, public :: event private procedure(eventTask ), pointer, public :: task end type event abstract interface logical function eventTask(self) import event class(event), intent(in) :: self end function eventTask end interface end module eventMod program test use eventMod implicit none logical :: r type(event), pointer :: myEvent allocate(myEvent) r=myEvent%task() end program test causes the following warning when compiled (with gfortran 4.8.0): $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/home/abenson/Galacticus/Tools/libexec/gcc/x86_64-unknown- linux-gnu/4.8.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-trunk/configure -- prefix=/home/abenson/Galacticus/Tools --enable-languages=c,c++,fortran -- disable-multilib --with-gmp=/home/abenson/Galacticus/Tools Thread model: posix gcc version 4.8.0 20121219 (experimental) (GCC) $ gfortran -o warn.exe warn.F90 -Wall warn.F90:19.4: r=myEvent%task() 1 Warning: POINTER valued function appears on right-hand side of assignment at (1) As far as I can tell, the code runs correctly despite this warning. the warning is spurious as the task function returns a logical, not a pointer.
