[Bug bootstrap/58289] gcc/gengtype.c includes gcc/double-int.h, which uses C++ constructs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58289 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- The Makefiles use different variables for C and C++ compilers, CC for the former and CXX for the latter.
[Bug bootstrap/58289] gcc/gengtype.c includes gcc/double-int.h, which uses C++ constructs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58289 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to James K. Lowden from comment #2) 1. This is not mentioned anywhere in http://gcc.gnu.org/install/configure.html. http://gcc.gnu.org/install/prerequisites.html
[Bug c++/58294] New: ice in update_ssa_across_abnormal_edges, at tree-inline.c:1892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58294 Bug ID: 58294 Summary: ice in update_ssa_across_abnormal_edges, at tree-inline.c:1892 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: dcb314 at hotmail dot com Created attachment 30739 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30739action=edit gzipped C++ source code I just tried to compile package 0ad-0.0.13-8.fc20 with gcc 4.9 trunk dated 20130901. It said /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp: In function 'Status png_decode(rpU8, size_t, Tex*)': /usr/include/boost/smart_ptr/detail/sp_counted_base_gcc_x86.hpp:160:22: internal compiler error: in update_ssa_across_abnormal_edges, at tre e-inline.c:1892 destroy(); ^ 0xb61e7f update_ssa_across_abnormal_edges ../../src/trunk/gcc/tree-inline.c:1892 0xb61e7f copy_edges_for_bb ../../src/trunk/gcc/tree-inline.c:2002 0xb61e7f copy_cfg_body ../../src/trunk/gcc/tree-inline.c:2386 0xb61e7f copy_body ../../src/trunk/gcc/tree-inline.c:2595 0xb66acb expand_call_inline ../../src/trunk/gcc/tree-inline.c:4197 0xb66acb gimple_expand_calls_inline ../../src/trunk/gcc/tree-inline.c:4304 0xb66acb optimize_inline_calls(tree_node*) ../../src/trunk/gcc/tree-inline.c:4458 0xf83b2d inline_transform(cgraph_node*) ../../src/trunk/gcc/ipa-inline-transform.c:436 0xa55839 execute_one_ipa_transform_pass ../../src/trunk/gcc/passes.c:2039 0xa55839 execute_all_ipa_transforms() ../../src/trunk/gcc/passes.c:2079 0x7f0030 expand_function ../../src/trunk/gcc/cgraphunit.c:1683 0x7f200e expand_all_functions ../../src/trunk/gcc/cgraphunit.c:1795 0x7f200e compile() ../../src/trunk/gcc/cgraphunit.c:2132 0x7f25f9 finalize_compilation_unit() ../../src/trunk/gcc/cgraphunit.c:2209 0x5fe53d cp_write_global_declarations() ../../src/trunk/gcc/cp/decl2.c:4364 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. Preprocessed source code attached. Flag -O2 required.
[Bug c++/58294] [4.9 Regression] ice in update_ssa_across_abnormal_edges, at tree-inline.c:1892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58294 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-02 CC||mpolacek at gcc dot gnu.org Known to work||4.8.1 Target Milestone|--- |4.9.0 Summary|ice in |[4.9 Regression] ice in |update_ssa_across_abnormal_ |update_ssa_across_abnormal_ |edges, at |edges, at |tree-inline.c:1892 |tree-inline.c:1892 Ever confirmed|0 |1 Known to fail||4.9.0 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed.
[Bug c/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #11 from Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl --- I'm not going to discuss whether my example is a valid C code or not, but in FORTRAN it goes a similarly wrong way. The compiler treats incorrectly the one-element array in a common.
[Bug c/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 --- Comment #12 from Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl --- Created attachment 30740 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30740action=edit Example of failing FORTRAN code, with assembler output from gfortran 4.6.4
[Bug tree-optimization/57511] [4.8/4.9 Regression] Missing SCEV final value replacement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57511
--- Comment #5 from Richard Biener rguenth at gcc dot gnu.org ---
(In reply to Richard Biener from comment #4)
It looks like
Index: gcc/tree-scalar-evolution.c
===
--- gcc/tree-scalar-evolution.c (revision 202068)
+++ gcc/tree-scalar-evolution.c (working copy)
@@ -2252,6 +2252,7 @@ instantiate_scev_name (basic_block insta
else if (res != chrec_dont_know)
{
if (inner_loop
+ def_bb-loop_father != inner_loop
!flow_loop_nested_p (def_bb-loop_father, inner_loop))
/* ??? We could try to compute the overall effect of the loop here.
*/
res = chrec_dont_know;
should be correct, but it has some testsuite fallout that needs to be
analyzed (at least uncovering an IVOPTS issue).
Ok, the only issue is gcc.dg/tree-ssa/reassoc-19.c FAILing because IVOPTs
now detects a BIV and does something - previously it bailed out. We have
bb 2:
goto bb 4;
bb 3:
_7 = (sizetype) element_6(D);
_8 = -_7;
rite_9 = rite_1 + _8;
bar (left_5(D), rite_9, element_6(D));
bb 4:
# rite_1 = PHI rite_3(D)(2), rite_9(3)
if (left_5(D) = rite_1)
goto bb 3;
else
goto bb 5;
bb 5:
return;
and the BIV rite_1 is {rite_3(D), +, -(sizetype) element_6(D)}_1
that's good and an improvement. IVOPTs decides to use the original BIV:
candidate 8 (important)
var_before rite_1
var_after rite_9
original biv
type char *
base rite_3(D)
step -(sizetype) element_6(D)
base object (void *) rite_3(D)
which ideally would result in no code change ...?
Well.
The issue is that rewrite_use_nonlinear_expr of rite_9 = rite_1 + _8
gets things folded back to (char *) ((unsigned long) rite_1 - (unsigned long)
element_6(D)) from the more optimal
rite_1 + (-(sizetype) element_6(D))
Which is because of the way we try to get around plus vs. pointer-plus
in get_computation_aff and ultimately aff_combination_to_tree.
I'm going to clean that up ...
[Bug rtl-optimization/58295] New: The combination pass doesn't eliminates some extra zero extensions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58295
Bug ID: 58295
Summary: The combination pass doesn't eliminates some extra
zero extensions
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: uranus at tinlans dot org
$ cat test.c
extern char zeb_test_array[10];
unsigned char ee_isdigit2(unsigned int i)
{
unsigned char c = zeb_test_array[i];
unsigned char retval;
retval = ((c='0') (c='9')) ? 1 : 0;
return retval;
}
$ arm-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-eabi-gcc
COLLECT_LTO_WRAPPER=/home1/lhtseng/arm/4.9/libexec/gcc/arm-eabi/4.9.0/lto-wrapper
Target: arm-eabi
Configured with: ../../../../work/4.9/src/gcc-4.9.0/configure --target=arm-eabi
--prefix=/home1/lhtseng/arm/4.9 --disable-nls --disable-shared
--enable-languages=c --enable-__cxa_atexit --enable-c99 --enable-long-long
--enable-threads=single --with-newlib --disable-multilib --disable-libssp
--disable-libgomp --disable-decimal-float --disable-libffi --disable-libmudflap
--disable-lto --with-gmp=/home1/lhtseng/work/general
--with-mpfr=/home1/lhtseng/work/general --with-mpc=/home1/lhtseng/work/general
--with-isl=/home1/lhtseng/work/general --with-cloog=/home1/lhtseng/work/general
Thread model: single
gcc version 4.9.0 20130802 (experimental) (GCC)
$ arm-eabi-gcc -O3 -S test.c
$ cat test.s
...
ee_isdigit2:
@ Function supports interworking.
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
ldr r3, .L2
ldrbr0, [r3, r0]@ zero_extendqisi2
sub r0, r0, #48
and r0, r0, #255
cmp r0, #9
movhi r0, #0
movls r0, #1
bx lr
...
The instruction 'and r0, r0, #255' is a redundant instruction which cannot be
eliminated by the RTL instruction combination pass. This pass was able to
handle this case before this commit:
http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/simplify-rtx.c?r1=191909r2=191928pathrev=192303
And the code was re-organized to line 643 ~ 656 after this commit:
http://gcc.gnu.org/viewcvs/gcc/trunk/gcc/simplify-rtx.c?r1=192006r2=192186pathrev=192303
For example, GCC 4.6.3 can handle it perfectly.
In GCC 4.9.0, reverting the two commits or simply commeting the lines mentioned
above can make the combination pass handle this case again:
$ arm-eabi-gcc-modified -O3 -da -S test.c
$ cat test.c.166r.expand
...
(insn 9 8 10 2 (set (reg:SI 120)
(plus:SI (subreg:SI (reg:QI 118) 0)
(const_int -48 [0xffd0]))) test.c:6 -1
(nil))
(insn 10 9 11 2 (set (reg:SI 121)
(and:SI (reg:SI 120)
(const_int 255 [0xff]))) test.c:6 -1
(nil))
(insn 11 10 12 2 (set (reg:CC 100 cc)
(compare:CC (reg:SI 121)
(const_int 9 [0x9]))) test.c:6 -1
(nil))
(insn 12 11 13 2 (set (reg:SI 122)
(leu:SI (reg:CC 100 cc)
(const_int 0 [0]))) test.c:6 -1
(nil))
...
$ cat test.c.197r.combine
...
Trying 9, 10 - 11:
Failed to match this instruction:
(set (reg:CC 100 cc)
(compare:CC (plus:SI (reg:SI 119)
(const_int -48 [0xffd0]))
(const_int 9 [0x9])))
Successfully matched this instruction:
(set (reg:SI 121)
(plus:SI (reg:SI 119)
(const_int -48 [0xffd0])))
Successfully matched this instruction:
(set (reg:CC 100 cc)
(compare:CC (reg:SI 121)
(const_int 9 [0x9])))
deferring deletion of insn with uid = 9.
modifying insn i210: r121:SI=r119:SI-0x30
REG_DEAD r119:SI
deferring rescan insn with uid = 10.
modifying insn i311: cc:CC=cmp(r121:SI,0x9)
REG_DEAD r121:SI
deferring rescan insn with uid = 11.
...
The insn 10 is generated by (define_expand zero_extendqisi2 ...) of ARM's
machine description. Before the commits I mentioned above, the combination pass
successfully combines it with the insn 9. However, after those commits, the
combination pass never tries to do the combination '9, 10 - 11.'
After reading the commit messages of the file 'simplify-rtx.c', we can
understand the commits, r191928, was trying to optimize x86 code generation,
but it led to the suboptimal code generation of the ARM's target.
[Bug bootstrap/58242] [4.9 regression] linux-android.c:40:7: error: 'OPTION_BIONIC' was not declared in this scope breaks bootstrap on powerpc64-linux
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58242 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-02 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Build|powerpc64-linux |powerpc*-linux --- Comment #2 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Likewise on PowerPC/Linux.
[Bug tree-optimization/58296] New: ivopts is unable to handle some loops altered by the loop header copying pass
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58296
Bug ID: 58296
Summary: ivopts is unable to handle some loops altered by the
loop header copying pass
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: uranus at tinlans dot org
$ cat test.c
void bne_loop(unsigned int val,unsigned int N)
{
int i;
for (i=0;iN;++i)
printf(%d\n,val+i);
}
Please note that the comparison expression in the for loop, 'i N', is a
comparison between a signed int variable and an unsigned int variable. If we
change the type of i from 'int' to 'unsigned int', the issue won't be occured.
$ arm-eabi-gcc -v
Using built-in specs.
COLLECT_GCC=arm-eabi-gcc
COLLECT_LTO_WRAPPER=/home1/lhtseng/arm/4.9/libexec/gcc/arm-eabi/4.9.0/lto-wrapper
Target: arm-eabi
Configured with: ../../../../work/4.9/src/gcc-4.9.0/configure --target=arm-eabi
--prefix=/home1/lhtseng/arm/4.9 --disable-nls --disable-shared
--enable-languages=c --enable-__cxa_atexit --enable-c99 --enable-long-long
--enable-threads=single --with-newlib --disable-multilib --disable-libssp
--disable-libgomp --disable-decimal-float --disable-libffi --disable-libmudflap
--disable-lto --with-gmp=/home1/lhtseng/work/general
--with-mpfr=/home1/lhtseng/work/general --with-mpc=/home1/lhtseng/work/general
--with-isl=/home1/lhtseng/work/general --with-cloog=/home1/lhtseng/work/general
Thread model: single
gcc version 4.9.0 20130802 (experimental) (GCC)
$ arm-eabi-gcc -O3 -fdump-tree-all -O3 -da -S test.c
$ cat -n test.s
...
27 .L3:
28 add r1, r1, r5
29 add r4, r4, #1
30 ldr r0, .L9
31 bl printf
32 cmp r4, r6
33 mov r1, r4
34 bne .L3
...
The instruction 'mov r1, r4' is redundant. Reading the dump of the RTL
generation pass can understand how it's expanded:
$ cat test.c.166r.expand
...
;; i.0_4 = (unsigned int) i_9;
(insn 20 19 0 (set (reg:SI 110 [ i.0 ])
(reg/v:SI 112 [ i ])) ../test.c:6 -1
(nil))
...
$ cat test.c.165t.optimized
...
bb 4:
# i_13 = PHI i_9(5), 0(3)
# i.0_16 = PHI i.0_4(5), 0(3)
_7 = i.0_16 + val_6(D);
printf (%d\n, _7);
i_9 = i_13 + 1;
i.0_4 = (unsigned int) i_9;
if (i_9 != _15)
goto bb 5;
else
goto bb 6;
...
It's surprised that the line 'i.0_4 = (unsigned int) i_9;' cannot be handled by
any tree-level optimization passes and RTL level optimization passes. After
doing some investigations, we finally find that using '-Os' or '-fno-tree-ch'
instead of '-O3' can generate the optimized code, and the conversion was
eliminated by ivopts properly:
$ arm-eabi-gcc -O3 -fdump-tree-all -O3 -fno-tree-ch -da -S test.c
$ cat test.c.119t.ivopts
bb 3:
_7 = ivtmp.9_11;
printf (%d\n, _7);
ivtmp.9_10 = ivtmp.9_11 + 1;
bb 4:
# ivtmp.9_11 = PHI val_6(D)(2), ivtmp.9_10(3)
if (ivtmp.9_11 != _12)
goto bb 3;
else
goto bb 5;
$ cat test.s
...
.L3:
mov r1, r4
bl printf
add r4, r4, #1
.L2:
cmp r4, r5
ldr r0, .L6
bne .L3
ldmfd sp!, {r3, r4, r5, lr}
bx lr
...
Therefore, it's believed that there are something wrong with ivopts, which is
unable to handle the loop altered by the tree-ch pass when there is a
comparison (int v.s. unsigned int) in the condition field of a FOR statement.
[Bug tree-optimization/58294] [4.9 Regression] ice in update_ssa_across_abnormal_edges, at tree-inline.c:1892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58294 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added CC||hubicka at gcc dot gnu.org --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Started with r202145.
[Bug c++/21682] Disallowed using declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21682 --- Comment #8 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org --- Author: paolo Date: Mon Sep 2 09:42:39 2013 New Revision: 202163 URL: http://gcc.gnu.org/viewcvs?rev=202163root=gccview=rev Log: /cp 2013-09-02 Paolo Carlini paolo.carl...@oracle.com PR c++/21682, implement DR 565 * name-lookup.c (compparms_for_decl_and_using_decl): New. (push_overloaded_decl_1, do_nonmember_using_decl): Use it. /testsuite 2013-09-02 Paolo Carlini paolo.carl...@oracle.com PR c++/21682, implement DR 565 * g++.dg/template/using24.C: New. * g++.dg/template/using25.C: Likewise. * g++.dg/template/using26.C: Likewise. Added: trunk/gcc/testsuite/g++.dg/template/using24.C trunk/gcc/testsuite/g++.dg/template/using25.C trunk/gcc/testsuite/g++.dg/template/using26.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/testsuite/ChangeLog
[Bug c++/26605] using + function templates troubles
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26605 Bug 26605 depends on bug 21682, which changed state. Bug 21682 Summary: Disallowed using declaration http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21682 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug c++/21682] Disallowed using declaration
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21682 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED CC|gcc-bugs at gcc dot gnu.org, | |paolo.carlini at oracle dot com| Version|4.0.0 |4.9.0 Resolution|--- |FIXED --- Comment #9 from Paolo Carlini paolo.carlini at oracle dot com --- Done for 4.9.0.
[Bug tree-optimization/58282] g++.dg/tm/noexcept-1.C -fno-exceptions SIGSEGV in gimple_build_eh_must_not_throw
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58282
--- Comment #4 from vries at gcc dot gnu.org ---
Tentative fix:
...
diff --git a/gcc/cp/semantics.c b/gcc/cp/semantics.c
index ee3503c..c8b328c 100644
--- a/gcc/cp/semantics.c
+++ b/gcc/cp/semantics.c
@@ -5189,7 +5189,7 @@ finish_transaction_stmt (tree stmt, tree compound_stmt,
int flags, tree noex)
/* noexcept specifications are not allowed for function transactions. */
gcc_assert (!(noex compound_stmt));
- if (noex)
+ if (noex flag_exceptions)
{
tree body = build_must_not_throw_expr (TRANSACTION_EXPR_BODY (stmt),
noex);
@@ -5210,7 +5210,7 @@ tree
build_transaction_expr (location_t loc, tree expr, int flags, tree noex)
{
tree ret;
- if (noex)
+ if (noex flag_exceptions)
{
expr = build_must_not_throw_expr (expr, noex);
SET_EXPR_LOCATION (expr, loc);
...
[Bug tree-optimization/58294] [4.9 Regression] ice in update_ssa_across_abnormal_edges, at tree-inline.c:1892
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58294
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot de
--- Comment #3 from Markus Trippelsdorf markus at trippelsdorf dot de ---
Reduced:
struct A {
virtual ~A();
virtual void m_fn1() { delete this; }
void m_fn2() { m_fn1(); }
};
struct B {
A *pi_;
B() { pi_-m_fn2(); }
};
struct C {
B pn;
};
void _setjmp();
int png_decode() {
_setjmp();
C a;
return 0;
}
[Bug middle-end/58290] [4.9 Regression] error: virtual definition of statement not up-to-date
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58290 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-02 CC||hubicka at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- Cannot reproduce with r202097, fails with r202164. Must be one of Honzas changes.
[Bug lto/58285] ICE in lto_output_tree, at lto-streamer-out.c:1318
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58285 --- Comment #2 from Richard Biener rguenth at gcc dot gnu.org --- For a cross to mips-elf this works for me: ./cc1plus -quiet t.i -flto t.i:36:5: warning: 'typedef' was ignored in this declaration [enabled by default] }; ^
[Bug c/58283] Incorrect debug info when precompilation is on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58283
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2013-09-02
Ever confirmed|0 |1
--- Comment #1 from Richard Biener rguenth at gcc dot gnu.org ---
I get
/tmp/xtest make
g++-4.8 -gdwarf-2 -g3 -O0 -DPRECOMP `wx-config --cflags` -o precomp1.hpp.gch -c
precomp1.hpp
/bin/sh: wx-config: command not found
g++-4.8 -gdwarf-2 -g3 -O0 -DPRECOMP `wx-config --cflags` -o xtest mainmenu.cpp
/bin/sh: wx-config: command not found
nm -C xtest | grep main
U __libc_start_main@@GLIBC_2.2.5
00400620 T main
addr2line -e xtest $(nm -C xtest | grep ' main$' | awk '{print $1}')
/tmp/xtest/mainmenu.cpp:3
Same with including pecomp1.hpp from mainmenu.cpp.
(so, what does wx-config --cflags return?)
Note that you are testing GCC 4.8, not 4.7.
[Bug sanitizer/55484] gfortran.dg/realloc_on_assign_5.f03 execution failures with -fsanitize=address
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55484 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr --- Still present at revision 202154. I think it is a duplicate of PR47674. *** This bug has been marked as a duplicate of bug 47674 ***
[Bug fortran/47674] gfortran.dg/realloc_on_assign_5.f03: Segfault at run time for deferred (allocatable) string length
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47674 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||howarth at nitro dot med.uc.edu --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 55484 has been marked as a duplicate of this bug. ***
[Bug fortran/45170] [F2003] allocatable character lengths
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #44 from Dominique d'Humieres dominiq at lps dot ens.fr --- Per comment #39, it seems that this PR could be closed as FIXED. Closing as fixed. If there are issues not covered by comment #39, please open a new report.
[Bug fortran/51394] Rejects legal code involving an allocatable string
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51394 Bug 51394 depends on bug 45170, which changed state. Bug 45170 Summary: [F2003] allocatable character lengths http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/20585] [meta-bug] Fortran 2003 support
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585 Bug 20585 depends on bug 45170, which changed state. Bug 45170 Summary: [F2003] allocatable character lengths http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/51075] ICE with deferred-length character pointer component in derived types
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51075 Bug 51075 depends on bug 45170, which changed state. Bug 45170 Summary: [F2003] allocatable character lengths http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45170 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug c++/58297] New: wrong DTOR call is generated when virtual base is present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58297
Bug ID: 58297
Summary: wrong DTOR call is generated when virtual base is
present
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: kcc at gcc dot gnu.org
For some reason, g++ (r202164) generates a call to an incorrect DTOR,
but never generates the DTOR itself. As the result, we get this link error:
undefined reference to `BBB::~BBB(void const**)'
The test case is reduced from Chromium sources,
https://code.google.com/p/chromium/issues/detail?id=282285
% head z.h z1.cc z2.cc
== z.h ==
struct AAA { };
struct BBB: virtual AAA { ~BBB (); };
== z1.cc ==
#include z.h
BBB::~BBB() { }
int main() { }
== z2.cc ==
#include z.h
struct CCC: BBB { ~CCC (); };
CCC::~CCC () { }
%
% g++ z1.cc z2.cc # 4.6.3
% clang++ z1.cc z2.cc # fresh trunk
% $FRESH_GCC/bin/g++ z1.cc z2.cc
/tmp/ccO8JGGF.o: In function `CCC::~CCC()':
z2.cc:(.text+0x31): undefined reference to `BBB::~BBB(void const**)'
/tmp/ccO8JGGF.o: In function `CCC::~CCC()':
z2.cc:(.text+0x6a): undefined reference to `BBB::~BBB(void const**)'
collect2: error: ld returned 1 exit status
[Bug c++/58297] wrong DTOR call is generated when virtual base is present
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58297 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Dup. *** This bug has been marked as a duplicate of bug 58201 ***
[Bug c++/58201] [4.9 Regression] Undefined reference to `B::B(void const**)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58201 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||kcc at gcc dot gnu.org --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com --- *** Bug 58297 has been marked as a duplicate of this bug. ***
[Bug c++/58201] [4.9 Regression] Undefined reference to `B::B(void const**)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58201 --- Comment #4 from Kostya Serebryany kcc at gcc dot gnu.org --- Nice. Any hope? Chromium is another project which we can't build with gcc trunk
[Bug tree-optimization/57985] [4.8 Regression] ICE in cgraph_function_node with -fprofile-arcs -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57985 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-02 CC||mpolacek at gcc dot gnu.org Summary|ICE in cgraph_function_node |[4.8 Regression] ICE in |with -fprofile-arcs -O2 |cgraph_function_node with ||-fprofile-arcs -O2 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Confirmed with 4.8. Trunk/4.7 seem to be fine.
[Bug c/58283] Incorrect debug info when precompilation is on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58283 --- Comment #2 from Jan Engelhardt jengelh at inai dot de --- Oh, -DPRECOMP `wx-config --cflags` is a remnant and may be removed from the Makefile. The issue continues to be reproducible. It appears on openSUSE Factory's gcc 4.8. Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.8/lto-wrapper Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=release --with-gxx-include-dir=/usr/include/c++/4.8 --enable-ssp --disable-libssp --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --program-suffix=-4.8 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.8.1 20130806 [gcc-4_8-branch revision 201525] (SUSE Linux)
[Bug fortran/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #13 from Dominique d'Humieres dominiq at lps dot ens.fr --- Example of failing FORTRAN code, with assembler output from gfortran 4.6.4 This code is invalid: 5.7.2.5 Differences between named common and blank common A blank common block has the same properties as a named common block, except for the following. ... Named common blocks of the same name shall be of the same size in all scoping units of a program in which they appear, but blank common blocks may be of di erent sizes. ... If you put the two *.f files in the same one and compile the result, you get the following waring: Warning: Named COMMON block 'mem' at (1) shall be of the same size as elsewhere (24 vs 8 bytes) and the executable gives the result you expect.
[Bug c/58283] Incorrect debug info when precompilation is on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58283 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #3 from Richard Biener rguenth at gcc dot gnu.org --- As said, it works for me. Btw, including a PCH indirectly is not supported: A precompiled header file can be used only when these conditions apply: ... @item A precompiled header can't be used once the first C token is seen. You can have preprocessor directives before a precompiled header; you cannot include a precompiled header from inside another header.
[Bug fortran/57910] ICE (segfault) with deferred-length strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57910 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-02 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed at r202154.
[Bug c++/58201] [4.9 Regression] Undefined reference to `B::B(void const**)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58201 --- Comment #5 from Paolo Carlini paolo.carlini at oracle dot com --- In practice, this would block the release of 4.9.0. Thus hope for sure, it's only matter of when.
[Bug fortran/58233] null pointer cm in gfc_conv_structure at fortran/trans-expr.c:6132
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58233 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-02 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed at r202154.
[Bug fortran/58226] negative subscript pos at fortran/options.c:1205
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58226 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-09-02 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- This works for me (x86_64-apple-darwin10) with gfortran 4.8.1 and trunk r202154.
[Bug fortran/58225] In show_locus at fortran/error.c:391 pointer beyond end of line
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58225 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-02 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed.
[Bug fortran/58224] -fcheck=pointer should detect that an unallocated allocatable data-target is forbidden
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58224 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-09-02 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed. It may be a duplicate.
[Bug c/58283] Incorrect debug info when precompilation is on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58283 --- Comment #4 from Jan Engelhardt jengelh at inai dot de --- you cannot include a precompiled header from inside another header. Ok. So, this limitation was properly implemented in gcc 4.7, which simply skipped over the indirectly-included .gch file as if it did not exist. Safe thing to do. In gcc 4.8 however, the indirectly-included .gch *is* used rather than skipped, which I base upon the observation that compile time goes down significantly for projects with larger amounts of C++ code and the same indirect-inclusion scheme.
[Bug fortran/58222] built-in:0:0: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58222 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-09-02 Ever confirmed|0 |1 --- Comment #5 from Dominique d'Humieres dominiq at lps dot ens.fr --- Works also for me on x86_64-apple-darwin10.
[Bug c/58283] Incorrect debug info when precompilation is on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58283 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added CC|rguenther at suse dot de |rguenth at gcc dot gnu.org --- Comment #5 from Richard Biener rguenth at gcc dot gnu.org --- You mean the fix for PR38987?
[Bug c++/58201] [4.9 Regression] Undefined reference to `B::B(void const**)'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58201 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P2 |P1 CC||jakub at gcc dot gnu.org
[Bug java/58284] Compiling jvgenmain failes with lots of undefined reference errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58284 --- Comment #4 from Winston Smith smith_winston_6079 at hotmail dot com --- I see. Is that the cause for the issue?
[Bug fortran/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #14 from Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl --- Marking the report as invalid doesn't solve the real problem. I changed the common to unnamed and the situation is still the same. main.f: C Compile and link this file with buggy.f, using gfortran 4.6 (and probably C any newer version), with optimization enabled (at least -O1). C Run with: echo 1 2 3 | ./a.out C expected (correct) result: 1. 2. 2. program main integer*4 i1,i2,i3 real*8 dmem common dmem(3) read (*,*) i1,i2,i3 call buggy(i1,i2,i3) write (*,*) dmem(1),dmem(2),dmem(3) end buggy.f: subroutine buggy(i1, i2, i3) integer*4 i1, i2, i3 real*8 dmem common dmem(1) dmem(i1)=1. dmem(i2)=2. dmem(i3)=2. return end Better?
[Bug tree-optimization/57985] [4.8 Regression] ICE in cgraph_function_node with -fprofile-arcs -O2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57985 --- Comment #2 from Marek Polacek mpolacek at gcc dot gnu.org --- Fixed by r199422 - doesn't seem to be easily backportable.
[Bug tree-optimization/57511] [4.8/4.9 Regression] Missing SCEV final value replacement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57511 --- Comment #6 from Richard Biener rguenth at gcc dot gnu.org --- Author: rguenth Date: Mon Sep 2 13:24:30 2013 New Revision: 202168 URL: http://gcc.gnu.org/viewcvs?rev=202168root=gccview=rev Log: 2013-09-02 Richard Biener rguent...@suse.de PR middle-end/57511 * tree-scalar-evolution.c (instantiate_scev_name): Allow non-linear SCEVs. * gcc.dg/tree-ssa/sccp-1.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/tree-ssa/sccp-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/testsuite/ChangeLog trunk/gcc/tree-scalar-evolution.c
[Bug tree-optimization/57511] [4.8 Regression] Missing SCEV final value replacement
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57511 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||missed-optimization Known to work||4.9.0 Summary|[4.8/4.9 Regression]|[4.8 Regression] Missing |Missing SCEV final value|SCEV final value |replacement |replacement --- Comment #7 from Richard Biener rguenth at gcc dot gnu.org --- Fixed on trunk. Note that patch requires 2013-09-02 Richard Biener rguent...@suse.de * tree-affine.c (add_elt_to_tree): Avoid converting all pointer arithmetic to sizetype. to not regress gcc.dg/tree-ssa/reassoc-19.c which means it isn't suitable for backporting IMHO.
[Bug lto/58298] [4.9 regression] ICE in mentions_vars_p_field_decl, at lto/lto.c:1392
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58298 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug lto/58298] New: [4.9 regression] ICE in mentions_vars_p_field_decl, at lto/lto.c:1392
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58298 Bug ID: 58298 Summary: [4.9 regression] ICE in mentions_vars_p_field_decl, at lto/lto.c:1392 Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: sch...@linux-m68k.org CC: jh at suse dot cz Target: m68k-*-* SVN r202143 Author: hubicka hubicka@138bc75d-0d04-0410-961f-82ee72b054a4 Date: Sun Sep 1 12:00:35 2013 + * lto.c (tree_with_vars): Turn into vector. $ gcc/xgcc -B gcc/ ../gcc/gcc/testsuite/gcc.c-torture/execute/20040308-1.c -O2 -flto -fno-use-linker-plugin -flto-partition=none -lm lto1: internal compiler error: in mentions_vars_p_field_decl, at lto/lto.c:1392 0x4dfcaa mentions_vars_p_field_decl ../../gcc/lto/lto.c:1392 0x4dfcaa mentions_vars_p ../../gcc/lto/lto.c:1499 0x4dfcaa lto_read_decls ../../gcc/lto/lto.c:2513 0x4e06ab lto_file_finalize ../../gcc/lto/lto.c:2783 0x4e06ab lto_create_files_from_ids ../../gcc/lto/lto.c:2793 0x4e06ab lto_file_read ../../gcc/lto/lto.c:2833 0x4e06ab read_cgraph_and_symbols ../../gcc/lto/lto.c:3422 0x4e06ab lto_main() ../../gcc/lto/lto.c:3852
[Bug fortran/58222] built-in:0:0: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58222 blake.fumberger at gmail dot com changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WONTFIX --- Comment #6 from blake.fumberger at gmail dot com --- I just uninstalled and used a different compiler.
[Bug lto/58298] [4.9 regression] ICE in mentions_vars_p_field_decl, at lto/lto.c:1392
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58298 Igor Zamyatin izamyatin at gmail dot com changed: What|Removed |Added CC||izamyatin at gmail dot com --- Comment #1 from Igor Zamyatin izamyatin at gmail dot com --- Fails for x86 also
[Bug ipa/58292] ICE in ipa-devirt.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58292 --- Comment #3 from Timo Sintonen t.sintonen at luukku dot com --- It seems gdc has a fix that does not produce this any more
[Bug fortran/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-09-02 Ever confirmed|0 |1 --- Comment #15 from Dominique d'Humieres dominiq at lps dot ens.fr --- It is invalid to use subroutine buggy(i1, i2, i3) integer*4 i1, i2, i3 real*8 dmem common dmem(1) dmem(i1)=1. dmem(i2)=2. dmem(i3)=2. return end with any i* different from 1. If you compile the code with -fbounds-check (or for recent gfortran, -fcheck=bounds) you get for 'echo 1 2 3' Fortran runtime error: Index '2' of dimension 1 of array 'dmem' above upper bound of 1 As the code is invalid if one of the i* is not one, the compiler can do whatever it finds appropriate, e.g., set i1=i2=i3=1 (only valid case) and discard the other assignments. AFAICT, the following works as I expect (4.0, 2.0, 3.0): [macbook] dominiq/Downloads% cat buggy.f90 subroutine buggy(i1, i2, i3) integer*4 i1, i2, i3 real*8 dmem common dmem(1) dmem(i1)=4. ! dmem(i2)=2. ! dmem(i3)=2. return end [macbook] dominiq/Downloads% cat main.f90 ! Compile and link this file with buggy.f, using gfortran 4.6 (and probably ! any newer version), with optimization enabled (at least -O1). ! Run with: echo 1 2 3 | ./a.out ! expected (correct) result: 1. 2. 2. program main implicit none integer*4 i1,i2,i3 real*8 dmem common dmem(3) read (*,*) i1,i2,i3 dmem(i1) = 1.0 dmem(i2) = 2.0 dmem(i3) = 3.0 print *, dmem call buggy(i1,i2,i3) write (*,*) dmem(1),dmem(2),dmem(3) end I let you close the PR as INVALID.
[Bug ada/58299] New: Ada defines UNICODE and _UNICODE too late for __MINGW32__
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58299 Bug ID: 58299 Summary: Ada defines UNICODE and _UNICODE too late for __MINGW32__ Product: gcc Version: 4.8.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ada Assignee: unassigned at gcc dot gnu.org Reporter: earnie at users dot sourceforge.net Created attachment 30741 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30741action=edit Ada patch for MinGW 4.0 When building gcc-4.8.1 for MinGW 4.0 release I discovered that the private _mingw.h file was included and that UNICODE and _UNICODE were defined after headers had already been included. This caused a result of UNICODE declared data being passed to ANSI version functions. The fix was to simply move the inclusion of the mingw32.h file in the source of ada/initialize.c and to remove the inclusion of the private ada/_mingw.h file in mingw32.h. The patch I used is attached.
[Bug rtl-optimization/57708] [4.8 regression] function clobbers callee saved register on ARM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57708 --- Comment #6 from clyon at gcc dot gnu.org --- Author: clyon Date: Mon Sep 2 14:59:09 2013 New Revision: 202176 URL: http://gcc.gnu.org/viewcvs?rev=202176root=gccview=rev Log: 2013-08-26 Kugan Vivekanandarajah kug...@linaro.org Backport from trunk r201501. 2013-08-05 Richard Earnshaw rearn...@arm.com PR rtl-optimization/57708 * recog.c (peep2_find_free_register): Validate all regs in a multi-reg mode. Modified: branches/linaro/gcc-4_8-branch/gcc/ChangeLog.linaro branches/linaro/gcc-4_8-branch/gcc/recog.c
[Bug middle-end/56382] FAIL: gcc.c-torture/compile/pr55921.c (internal compiler error)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56382 --- Comment #4 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Author: ebotcazou Date: Mon Sep 2 16:19:20 2013 New Revision: 202179 URL: http://gcc.gnu.org/viewcvs?rev=202179root=gccview=rev Log: PR middle-end/56382 * expr.c (emit_move_complex): Do not move complex FP values as parts if the source or the destination is a single hard register. Modified: trunk/gcc/ChangeLog trunk/gcc/expr.c
[Bug fortran/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 --- Comment #16 from Krzysztof Strasburger strasbur at chkw386 dot ch.pwr.wroc.pl --- Dear Dominique, I cannot agree with you. You are interpreting the code that may access the array beyond declared bounds as invalid, which is simply not true. As you pointed it out before, unnamed common block may be declared larger elsewhere, so writing the dmem array beyond its first element may be a design decision and therefore may be perfectly legal. The compiler has no clue about real size of unnamed common while compiling buggy.f and bounds checking is optional. I would also like to point it out that interpreting things this way you do, you exclude some older FORTRAN77 software (for example: quantum chemistry GAMESS), in which the lack of dynamic memory allocation was overcome using the trick we are discussing here (mixing with C was needed). BTW, change the size of dmem to 2 in buggy.f and things start to work correctly, although out of bounds memory accesses still do happen. The problem occurs only if dmem is of size 1. Of course you (developers) may decide to ignore this problem anyway, so if you do so, feel free to close this bug. I'm not going to reopen it again, because I'm out of arguments. I'm also not competent enough to tamper with the compiler.
[Bug fortran/58270] Wrong code while accessing array elements in a global structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 --- Comment #17 from Dominique d'Humieres dominiq at lps dot ens.fr --- I cannot agree with you. You are interpreting the code that may access the array beyond declared bounds as invalid, which is simply not true. 6.5 Use of data objects ... The value of a subscript in an array element shall be within the bounds for its dimension. where the shall means (as elsewhere in the standard) that it is the coder responsibility to honor the constraint at run time. As you pointed it out before, unnamed common block may be declared larger elsewhere, so writing the dmem array beyond its first element may be a design decision and therefore may be perfectly legal. As above this is a wrong assumption: the design decision must be standard conforming. When you write common dmem(1) you tell the compiler that 'dmem' has only one element. The compiler has no clue about real size of unnamed common while compiling buggy.f and bounds checking is optional. When you write common dmem(1) you tell the compiler that 'dmem' has only one element. I would also like to point it out that interpreting things this way you do, This is not my interpretation, it is what the Fortran standard says. you exclude some older FORTRAN77 software (for example: quantum chemistry GAMESS), in which the lack of dynamic memory allocation was overcome using the trick we are discussing here (mixing with C was needed). Well, I have used safer tricks to overcome the limitation. BTW, change the size of dmem to 2 in buggy.f and things start to work correctly, although out of bounds memory accesses still do happen. The problem occurs only if dmem is of size 1. Because only for size 1 the optimizer can infer that valid uses will provide the (1,1,1) triplet. Of course you (developers) may decide to ignore this problem anyway, so if you do so, feel free to close this bug. I'm not going to reopen it again, because I'm out of arguments. I'm also not competent enough to tamper with the compiler. What you can do is to look at the GCC manual and try to find the optimization pass than enable the optimization you don't like and disable it. Note that most optimizations are not part of the gfortran front-end.
[Bug c++/10541] [DR 354] Is NULL a valid pointer-type template argument?
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=10541 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|NEW
[Bug ipa/58106] ICE: in ipa_edge_duplication_hook, at ipa-prop.c:2839
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58106 --- Comment #5 from Martin Jambor jamborm at gcc dot gnu.org --- Author: jamborm Date: Mon Sep 2 19:28:01 2013 New Revision: 202184 URL: http://gcc.gnu.org/viewcvs?rev=202184root=gccview=rev Log: 2013-09-02 Martin Jambor mjam...@suse.cz PR ipa/58106 * ipa-prop.c (ipa_edge_duplication_hook): Always put new rdesc to the linked list. When finding the correct duplicate, also consider also the caller in additon to its inlined_to node. testsuite/ * gcc.dg/ipa/pr58106.c: New test. Added: trunk/gcc/testsuite/gcc.dg/ipa/pr58106.c Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-prop.c trunk/gcc/testsuite/ChangeLog
[Bug c/53001] -Wfloat-conversion should be available to warn about floating point errors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53001 --- Comment #7 from Joshua Cogliati jjcogliati-r1 at yahoo dot com --- I wrote the patch for 4.8.1 (which is the easy part), now I will see if I can get approval to submit it through the bureaucracies (the hard part).
[Bug c/58283] Incorrect debug info when precompilation is on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58283 --- Comment #6 from Jan Engelhardt jengelh at inai dot de --- It seems to be ineffective.
[Bug c++/58300] New: ICE: in decide_is_symbol_needed, at cgraphunit.c:233 with -fvtable-verify=preinit on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58300
Bug ID: 58300
Summary: ICE: in decide_is_symbol_needed, at cgraphunit.c:233
with -fvtable-verify=preinit on invalid code
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: zsojka at seznam dot cz
Created attachment 30742
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30742action=edit
reduced testcase
Compiler output:
$ gcc -fvtable-verify=preinit testcase.C
testcase.C:2:1: error: explicit specialization of non-template 'A'
{
^
testcase.C:4:2: internal compiler error: in decide_is_symbol_needed, at
cgraphunit.c:233
};
^
0x887ed8 decide_is_symbol_needed(symtab_node_def*)
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:232
0x888468 cgraph_finalize_function(tree_node*, bool)
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:459
0x889f69 cgraph_process_new_functions()
/mnt/svn/gcc-trunk/gcc/cgraphunit.c:306
0x79d756 vtv_generate_init_routine()
/mnt/svn/gcc-trunk/gcc/cp/vtable-class-hierarchy.c:1190
0x68fc46 cp_write_global_declarations()
/mnt/svn/gcc-trunk/gcc/cp/decl2.c:4373
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See http://gcc.gnu.org/bugs.html for instructions.
$ gcc -v
Using built-in specs.
COLLECT_GCC=/mnt/svn/gcc-trunk/binary-latest/bin/gcc
COLLECT_LTO_WRAPPER=/mnt/svn/gcc-trunk/binary-202158-lto-fortran-checking-yes-rtl-df/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /mnt/svn/gcc-trunk//configure --enable-checking=yes,rtl,df
--enable-languages=c,c++,lto,fortran
--prefix=/mnt/svn/gcc-trunk/binary-202158-lto-fortran-checking-yes-rtl-df/
--without-cloog --without-ppl
Thread model: posix
gcc version 4.9.0 20130902 (experimental) (GCC)
[Bug rtl-optimization/58295] [4.8/4.9 regression] Missed zero-extension elimination in the combiner
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58295 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Target||arm*-*-* Status|UNCONFIRMED |NEW Keywords||missed-optimization Last reconfirmed||2013-09-02 CC||ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 Summary|The combination pass|[4.8/4.9 regression] Missed |doesn't eliminate some |zero-extension elimination |extra zero extensions |in the combiner Target Milestone|--- |4.8.2 --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org --- Confirmed. Seeing that insn 10 is redundant is not immediate but the combiner was indeed clever enough to do it. The QI subreg is clearly problematic for the ARM here (and probably most RISC architectures).
[Bug fortran/56519] DO CONCURRENT: wrongly accepts calls to impure intrinsics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56519 Thomas Koenig tkoenig at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #2 from Thomas Koenig tkoenig at gcc dot gnu.org --- Author: tkoenig Date: Mon Sep 2 22:09:07 2013 New Revision: 202188 URL: http://gcc.gnu.org/viewcvs?rev=202188root=gccview=rev Log: 2013-09-02 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/PR56519 * gfortran.h: Declare gfc_do_concurrent_flag as extern. * resolve.c: Rename do_concurrent_flag to gfc_do_concurrent_flag and make non-static. (resolve_function): Use gfc_do_concurrent_flag instead of do_concurrent_flag. (pure_subroutine): Likewise. (resolve_code): Likewise. (resolve_types): Likewise. * intrinsic.c (gfc_intrinsic_sub_interface): Raise error for non-pure intrinsic subroutines within DO CONCURRENT. 2013-09-02 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/PR56519 * gfortran.dg/do_concurrent_3.f90: New test case. Added: trunk/gcc/testsuite/gfortran.dg/do_concurrent_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/intrinsic.c trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug lto/58301] New: [4.9 Regression] error: inlining failed in call to always_inline 'set_mem_alias_set'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58301 Bug ID: 58301 Summary: [4.9 Regression] error: inlining failed in call to always_inline 'set_mem_alias_set' Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: lto Assignee: unassigned at gcc dot gnu.org Reporter: danglin at gcc dot gnu.org Host: hppa64-hp-hpux11.11 Target: hppa64-hp-hpux11.11 Build: hppa64-hp-hpux11.11 spawn /test/gnu/gcc/objdir/gcc/xgcc -B/test/gnu/gcc/objdir/gcc/ c_lto_20090218-1_0.o c_lto_20090218-1_1.o -fno-diagnostics-show-caret -fdiagnostics-color=never -O0 -flto -flto-partition=none -o gcc-dg-lto-20090218-1-01.exe/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/20090218-1_0.c: In function 'emit_push_insn':/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/20090218-1_1.c:7:46: error: inlining failed in call to always_inline 'set_mem_alias_set': function body not available/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/20090218-1_0.c:3:21: error: called from here lto-wrapper: /test/gnu/gcc/objdir/gcc/xgcc returned 1 exit statuscollect2: error: lto-wrapper returned 1 exit status compiler exited with status 1output is:/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/20090218-1_0.c: In function 'emit_push_insn': /test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/20090218-1_1.c:7:46: error: inlining failed in call to always_inline 'set_mem_alias_set': function body not available/test/gnu/gcc/gcc/gcc/testsuite/gcc.dg/lto/20090218-1_0.c:3:21: error: called fr om herelto-wrapper: /test/gnu/gcc/objdir/gcc/xgcc returned 1 exit status collect2: error: lto-wrapper returned 1 exit status FAIL: gcc.dg/lto/20090218-1 c_lto_20090218-1_0.o-c_lto_20090218-1_1.o link, -O0
[Bug middle-end/57748] [4.8/4.9 Regression] ICE when expanding assignment to unaligned zero-sized array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57748 --- Comment #24 from Bernd Edlinger bernd.edlinger at hotmail dot de --- Created attachment 30743 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=30743action=edit Yet another untested fix Ok, this is somewhat similar to Martin's very first attempt to fix this. After staring at the code for quite a long time, I believe the misalign code path is meant for structures or unions that can be accessed in a mode != BLKmode which is the mode of the largest member of a union for instance. But if that mode has a movmisalign op that should be used. However that is only an optimization, store_field will always be able to store the value byte by byte if necessary. If offset != 0 we have a non-constant (or maybe negative) array index here. If volatile we have a volatile access. If bitpos + bitsize GET_MODE_BITSIZE we probably have an array with a constant index. If any of these happens, better not go the misalign code path. The second hunk is necessary because the if block sets bitpos = 0, but leaves bitregion_start and bitregion_end untouched, creating an inconsistent bitregion, which may or may not assert later. Therefore check that this is no bitregion. If it is a bit region store_field can handle it. How do you like this patch?
[Bug middle-end/57287] [4.9 Regression] Bogus uninitialized warning with abnormal control flow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57287 Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org changed: What|Removed |Added CC||amylaar at gcc dot gnu.org --- Comment #21 from Jorn Wolfgang Rennecke amylaar at gcc dot gnu.org --- (In reply to Richard Biener from comment #18) Added: trunk/gcc/testsuite/gcc.dg/pr57287-2.c Why is that using __sigsetjmp ? That's not a standard function. E.g. newlib doesn't have it.
[Bug target/57848] internal compiler error on builtin and '#pragma GCC target()' option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57848 --- Comment #10 from Dongsheng Song dongsheng.song at gmail dot com --- If your compiler default target support sse4.2, then you can't reproduce it: i686-w64-mingw32-gcc -march=corei7 pr57848.c But when you use target which do not support sse4.2, then the internal compiler error occurred: $ i686-w64-mingw32-gcc -c -march=core2 pr57848.c pr57848.c:2:9: internal compiler error: in c_builtin_function_ext_scope, at c/c-decl.c:3633 #pragma GCC target(sse4.2) ^ 0x57024b c_builtin_function_ext_scope(tree_node*) /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-decl.c:3633 0x79f288 add_builtin_function_common /home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:561 0x79fb43 add_builtin_function_ext_scope(char const*, tree_node*, int, built_in_class, char const*, tree_node*) /home/cauchy/vcs/svn/gcc/trunk/gcc/langhooks.c:597 0xa63224 ix86_add_new_builtins /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:27368 0xa63224 ix86_valid_target_attribute_tree(tree_node*) /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386.c:4631 0x5f2000 ix86_pragma_target_parse /home/cauchy/vcs/svn/gcc/trunk/gcc/config/i386/i386-c.c:393 0x5e237d handle_pragma_target /home/cauchy/vcs/svn/gcc/trunk/gcc/c-family/c-pragma.c:805 0x59696e c_parser_pragma /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:8972 0x5a4f5b c_parser_external_declaration /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:1345 0x5a58c7 c_parser_translation_unit /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:1251 0x5a58c7 c_parse_file() /home/cauchy/vcs/svn/gcc/trunk/gcc/c/c-parser.c:11223 0x5dfec4 c_common_parse_file() /home/cauchy/vcs/svn/gcc/trunk/gcc/c-family/c-opts.c:1046 Please submit a full bug report, with preprocessed source if appropriate. Please include the complete backtrace with any bug report. See http://gcc.gnu.org/bugs.html for instructions. i686-w64-mingw32-gcc -v Using built-in specs. COLLECT_GCC=i686-w64-mingw32-gcc COLLECT_LTO_WRAPPER=/home/cauchy/cross/i686-windows-gcc49/libexec/gcc/i686-w64-mingw32/4.9.0/lto-wrapper Target: i686-w64-mingw32 Configured with: /home/cauchy/vcs/svn/gcc/trunk/configure --prefix=/home/cauchy/cross/i686-windows-gcc49 --with-sysroot=/home/cauchy/cross/i686-windows-gcc49 --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=i686-w64-mingw32 --disable-multilib --disable-nls --enable-checking=release --enable-languages=c,c++,fortran --with-arch=i686 --with-tune=generic Thread model: win32 gcc version 4.9.0 20130902 (experimental) (GCC)
[Bug libstdc++/58302] New: compilation error : std::negative_binomial_distribution::operator(e, p)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58302
Bug ID: 58302
Summary: compilation error :
std::negative_binomial_distribution::operator(e, p)
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: faithandbrave at gmail dot com
Follow code become compilation error:
#include random
int main()
{
typedef std::negative_binomial_distribution dist_type;
std::default_random_engine engine;
dist_type dist;
dist_type::param_type param(3, 0.5);
int result = dist(engine, param); // compile error!
}
error description:
prog.cc: In function 'int main()':
prog.cc:12:7: warning: unused variable 'result' [-Wunused-variable]
int result = dist(engine, param); // compile error!
^
In file included from /usr/local/gcc-head/include/c++/4.9.0/random:49:0,
from prog.cc:1:
/usr/local/gcc-head/include/c++/4.9.0/bits/random.h: In instantiation of 'class
std::gamma_distributionint':
/usr/local/gcc-head/include/c++/4.9.0/bits/random.tcc:1295:4: required from
'std::negative_binomial_distribution_IntType::result_type
std::negative_binomial_distribution_IntType::operator()(_UniformRandomNumberGenerator,
const std::negative_binomial_distribution_IntType::param_type) [with
_UniformRandomNumberGenerator = std::linear_congruential_enginelong unsigned
int, 16807ul, 0ul, 2147483647ul; _IntType = int;
std::negative_binomial_distribution_IntType::result_type = int]'
prog.cc:12:34: required from here
/usr/local/gcc-head/include/c++/4.9.0/bits/random.h:2504:7: error: static
assertion failed: template argument not a floating point type
static_assert(std::is_floating_point_RealType::value,
^
/usr/local/gcc-head/include/c++/4.9.0/bits/random.h: In instantiation of 'class
std::normal_distributionint':
/usr/local/gcc-head/include/c++/4.9.0/bits/random.h:2699:45: required from
'class std::gamma_distributionint'
/usr/local/gcc-head/include/c++/4.9.0/bits/random.tcc:1295:4: required from
'std::negative_binomial_distribution_IntType::result_type
std::negative_binomial_distribution_IntType::operator()(_UniformRandomNumberGenerator,
const std::negative_binomial_distribution_IntType::param_type) [with
_UniformRandomNumberGenerator = std::linear_congruential_enginelong unsigned
int, 16807ul, 0ul, 2147483647ul; _IntType = int;
std::negative_binomial_distribution_IntType::result_type = int]'
prog.cc:12:34: required from here
/usr/local/gcc-head/include/c++/4.9.0/bits/random.h:2087:7: error: static
assertion failed: template argument not a floating point type
static_assert(std::is_floating_point_RealType::value,
^
In file included from /usr/local/gcc-head/include/c++/4.9.0/random:51:0,
from prog.cc:1:
/usr/local/gcc-head/include/c++/4.9.0/bits/random.tcc: In instantiation of
'std::negative_binomial_distribution_IntType::result_type
std::negative_binomial_distribution_IntType::operator()(_UniformRandomNumberGenerator,
const std::negative_binomial_distribution_IntType::param_type) [with
_UniformRandomNumberGenerator = std::linear_congruential_enginelong unsigned
int, 16807ul, 0ul, 2147483647ul; _IntType = int;
std::negative_binomial_distribution_IntType::result_type = int]':
prog.cc:12:34: required from here
/usr/local/gcc-head/include/c++/4.9.0/bits/random.tcc:1298:64: error: no match
for call to '(std::gamma_distributiondouble)
(std::linear_congruential_enginelong unsigned int, 16807ul, 0ul,
2147483647ul, param_type)'
_M_gd(__urng, param_type(__p.k(), (1.0 - __p.p()) / __p.p()));
^
In file included from /usr/local/gcc-head/include/c++/4.9.0/random:49:0,
from prog.cc:1:
/usr/local/gcc-head/include/c++/4.9.0/bits/random.h:2502:11: note: candidates
are:
class gamma_distribution
^
/usr/local/gcc-head/include/c++/4.9.0/bits/random.h:2619:2: note:
templateclass _UniformRandomNumberGenerator
std::gamma_distribution_RealType::result_type
std::gamma_distribution_RealType::operator()(_UniformRandomNumberGenerator)
[with _UniformRandomNumberGenerator = _UniformRandomNumberGenerator; _RealType
= double]
operator()(_UniformRandomNumberGenerator __urng)
^
/usr/local/gcc-head/include/c++/4.9.0/bits/random.h:2619:2: note: template
argument deduction/substitution failed:
In file included from /usr/local/gcc-head/include/c++/4.9.0/random:51:0,
from prog.cc:1:
/usr/local/gcc-head/include/c++/4.9.0/bits/random.tcc:1298:64: note:
candidate expects 1 argument, 2 provided
_M_gd(__urng, param_type(__p.k(), (1.0 - __p.p()) / __p.p()));
^
In file included from /usr/local/gcc-head/include/c++/4.9.0/random:49:0,
from prog.cc:1:
[Bug c/58303] New: C99 union initializers new union members clobber earlier data
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58303
Bug ID: 58303
Summary: C99 union initializers new union members clobber
earlier data
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: darrenrjenkins at gmail dot com
If using C99 initializers on a union, and using different union members.
The later members seem to clobber the previous members data.
I haven't looked at the standards with respect to this, but it seems wrong.
#include stdio.h
typedef struct
{
int a;
int b;
} a_t;
typedef struct
{
int c;
int d;
} b_t;
typedef union
{
a_t a;
b_t b;
} c_t;
void main( int argc, char *argv[] )
{
c_t var = { .a.a = 4, .b.d = 7 };
printf( .a.a = %d .b.d = %d\n, var.a.a, var.b.d );
}
[Bug ipa/58292] ICE in ipa-devirt.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58292 Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #4 from Joost VandeVondele Joost.VandeVondele at mat dot ethz.ch --- (In reply to Timo Sintonen from comment #3) It seems gdc has a fix that does not produce this any more OK, lets close this bug as fixed, to be reopened with a testcase if this resurfaces
