[Bug fortran/60522] [4.7/4.8/4.9 Regression] WHERE construct causes an ICE in gfc_trans_where_2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60522 --- Comment #6 from Thomas Koenig tkoenig at gcc dot gnu.org --- Author: tkoenig Date: Fri Mar 28 07:17:13 2014 New Revision: 208890 URL: http://gcc.gnu.org/viewcvs?rev=208890root=gccview=rev Log: 2014-04-28 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/60522 * frontend-passes.c (cfe_code): Do not walk subtrees for WHERE. 2014-04-28 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/60522 * gfortran.dg/where_4.f90: New test case. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/where_4.f90 Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/frontend-passes.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug c++/60689] Bogus error with atomic::exchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60689 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Attachment #32469|0 |1 is obsolete|| --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32470 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32470action=edit gcc49-pr60689.patch Ugh, except it doesn't work, it breaks C. The problem is that add_atomic_size_parameter calls build_function_call_vec which behaves differently between C and C++. For C that function calls resolve_overloaded_builtin, thus it recurses and adds the needed parameter in there and if we add the extra parameter as in my earlier patch, the recursive resolve_overloaded_builtin will complain that __atomic_exchange has too many parameters. For C++ it doesn't call that (finish_call_expr calls that instead), thus if we don't add the parameter there, nothing adds it. So, the options I see are: 1) what I'm attaching, make build_function_call_vec which is in C++ FE only called from c-common/ bits behave like C build_function_call_vec and call resolve_overloaded_builtin there 2) some static flag which will do nothing in resolve_overloaded_builtin if called recursively (but, David Malcolm will complain about global state) 3) when checking number of arguments, allow the case when there is the extra integer argument for the size; the problem with that is that I'd be afraid we'd allow people that way to call __atomic_exchange (9, ptr1, ptr2, ptr3, __ATOMIC_SEQ_CST); which we don't want to
[Bug lto/60690] Chromium build error with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60690 --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Trying to build new ffmpeg-2.2 this morning shows the same issue: ... /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /var/tmp/portage/media-video/ffmpeg-2.2/temp/cccBaTIP.ltrans0.ltrans.o: requires dynamic R_X86_64_PC32 reloc against 'w04' which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /var/tmp/portage/media-video/ffmpeg-2.2/temp/cccBaTIP.ltrans1.ltrans.o: requires dynamic R_X86_64_PC32 reloc against 'w04' which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /var/tmp/portage/media-video/ffmpeg-2.2/temp/cccBaTIP.ltrans2.ltrans.o: requires dynamic R_X86_64_PC32 reloc against 'w04' which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /var/tmp/portage/media-video/ffmpeg-2.2/temp/cccBaTIP.ltrans3.ltrans.o: requires dynamic R_X86_64_PC32 reloc against 'w04' which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /var/tmp/portage/media-video/ffmpeg-2.2/temp/cccBaTIP.ltrans5.ltrans.o: requires dynamic R_X86_64_PC32 reloc against 'deringThreshold' which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /var/tmp/portage/media-video/ffmpeg-2.2/temp/cccBaTIP.ltrans8.ltrans.o: requires dynamic R_X86_64_PC32 reloc against 'b80' which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /var/tmp/portage/media-video/ffmpeg-2.2/temp/cccBaTIP.ltrans10.ltrans.o: requires dynami c R_X86_64_PC32 reloc against 'b80' which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /var/tmp/portage/media-video/ffmpeg-2.2/temp/cccBaTIP.ltrans11.ltrans.o: requires dynami c R_X86_64_PC32 reloc against 'deringThreshold' which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /var/tmp/portage/media-video/ffmpeg-2.2/temp/cccBaTIP.ltrans13.ltrans.o: requires dynami c R_X86_64_PC32 reloc against 'deringThreshold' which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /var/tmp/portage/media-video/ffmpeg-2.2/temp/cccBaTIP.ltrans15.ltrans.o: requires dynami c R_X86_64_PC32 reloc against 'w05' which may overflow at runtime; recompile with -fPIC collect2: error: ld returned 1 exit status /var/tmp/portage/media-video/ffmpeg-2.2/work/ffmpeg-2.2/library.mak:106: recipe for target 'libpostproc/libpostproc.so.52' failed make: *** [libpostproc/libpostproc.so.52] Error 1 make: *** Waiting for unfinished jobs /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /var/tmp/portage/media-video/ffmpeg-2.2/temp/ccSxjMsO.ltrans8.ltrans.o: requires dynamic R_X86_64_PC32 reloc against 'mmx_00ffw' which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /var/tmp/portage/media-video/ffmpeg-2.2/temp/ccSxjMsO.ltrans10.ltrans.o: requires dynami c R_X86_64_PC32 reloc against 'mmx_ff' which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /var/tmp/portage/media-video/ffmpeg-2.2/temp/ccSxjMsO.ltrans17.ltrans.o: requires dynami c R_X86_64_PC32 reloc against 'mmx_00ffw' which may overflow at runtime; recompile with -fPIC /usr/lib/gcc/x86_64-pc-linux-gnu/4.9.0/../../../../x86_64-pc-linux-gnu/bin/ld: error: /var/tmp/portage/media-video/ffmpeg-2.2/temp/ccSxjMsO.ltrans27.ltrans.o: requires dynami c R_X86_64_PC32 reloc against 'mul15_hi' which may overflow at runtime; recompile with -fPIC collect2: error: ld returned 1 exit status /var/tmp/portage/media-video/ffmpeg-2.2/work/ffmpeg-2.2/library.mak:106: recipe for target 'libswscale/libswscale.so.2' failed x4 ffmpeg-2.2 # grep -D skip -R -i w04 . ./libpostproc/postprocess_template.c:paddw MANGLE(w04), %%mm0 \n\t ./libpostproc/postprocess_template.c:paddw MANGLE(w04), %%mm1 \n\t ./libpostproc/postprocess.c:DECLARE_ASM_CONST(8, uint64_t, w04)= 0x0004000400040004LL; x4 ffmpeg-2.2 # grep -D skip -R -i deringThreshold . ./libpostproc/postprocess_template.c:cmpb MANGLE(deringThreshold), %b4\n\t ./libpostproc/postprocess_template.c:if(max - min deringThreshold) return; ./libpostproc/postprocess.c:DECLARE_ASM_CONST(8, int, deringThreshold)= 20;
[Bug c/60693] New: ICE on funny memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60693
Bug ID: 60693
Summary: ICE on funny memcpy
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: luto at mit dot edu
This little program:
int main()
{
char buf[4096];
memcpy(buf, (void *)0xff60, 4096);
return 0;
}
does this:
$ gcc ice.c
ice.c: In function ‘main’:
ice.c:4:3: warning: incompatible implicit declaration of built-in function
‘memcpy’ [enabled by default]
memcpy(buf, (void *)0xff60, 4096);
^
ice.c:4:9: internal compiler error: in ix86_copy_addr_to_reg, at
config/i386/i386.c:21886
memcpy(buf, (void *)0xff60, 4096);
^
Please submit a full bug report,
with preprocessed source if appropriate.
See http://bugzilla.redhat.com/bugzilla for instructions.
Preprocessed source stored into /tmp/ccJqACry.out file, please attach this to
your bugreport.
This is gcc (GCC) 4.8.2 20131212 (Red Hat 4.8.2-7).
[Bug target/60693] ICE on funny memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60693 Markus Trippelsdorf trippels at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Known to work||4.7.3 Last reconfirmed||2014-03-28 Component|c |target CC||hjl at gcc dot gnu.org, ||trippels at gcc dot gnu.org Ever confirmed|0 |1 Target Milestone|--- |4.8.3 Known to fail||4.8.3, 4.9.0 --- Comment #1 from Markus Trippelsdorf trippels at gcc dot gnu.org --- Started with r203486.
[Bug target/60693] ICE on funny memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60693 --- Comment #2 from Markus Trippelsdorf trippels at gcc dot gnu.org --- And with r204338 on the 4.8 branch.
[Bug middle-end/60682] [4.9 Regression][OpenMP] ICE on an assignment of local variable inside SIMD loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60682 --- Comment #3 from Igor Zamyatin izamyatin at gmail dot com --- Thanks for the quick fix!
[Bug target/60693] [4.8/4.9 Regression] ICE on funny memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60693 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 Summary|ICE on funny memcpy |[4.8/4.9 Regression] ICE on ||funny memcpy
[Bug fortran/60677] [4.9 Regression] FAIL: gfortran.dg/ichar_3.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60677 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug fortran/60678] [4.9 Regression] FAIL: gfortran.dg/intrinsics_kind_argument_1.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60678 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.9.0
[Bug libgomp/60670] omp.h may differ between multilibs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60670 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Or the header needs to include all variants with proper #ifdef-ery
[Bug libgomp/60670] omp.h may differ between multilibs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60670 --- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE --- --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- Or the header needs to include all variants with proper #ifdef-ery This is difficult for a header generated per multilib at build time. Rainer
[Bug middle-end/48099] Evaluation order of arguments in a call expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48099 --- Comment #4 from Richard Biener rguenth at gcc dot gnu.org --- Java.
[Bug c/60018] Bogus conversion warning with optimization flag -O1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60018 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #3 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Marek Polacek from comment #2) The issue is that at -O0 conversion_warning gets (fn3(), 0) || 0 and doesn't call unsafe_conversion_p on it, while on -O fold_binary folds away the || 0 part and conversion_warning sees COMPOUND_EXPR, it then calls unsafe_conversion_p on it. But in any case, it should look to the last operand of (... , ...) and see that it is a constant 0. I think there is a duplicate already about -Wconversion not recursing into compound expressions.
[Bug ipa/60315] [4.8/4.9 Regression] template constructor switch optimization
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60315 --- Comment #18 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Mar 28 10:25:34 2014 New Revision: 208893 URL: http://gcc.gnu.org/viewcvs?rev=208893root=gccview=rev Log: PR ipa/60315 * g++.dg/torture/pr60315.C: Add -std=c++11 to dg-options. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/torture/pr60315.C
[Bug tree-optimization/60694] New: Gcc-4.2.4 hangs during compilation of the attached test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60694 Bug ID: 60694 Summary: Gcc-4.2.4 hangs during compilation of the attached test Product: gcc Version: 4.2.4 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: niva at niisi dot msk.ru Created attachment 32471 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32471action=edit The test file. Native gcc-4.1.2 and gcc-4.2.4 hang during compilation of the attached test. It seems that some analysis pass in cc1 exponentially depends on the size of expressions being analyzed. When I reduce the number of basic blocks in the loop the compilation time varies as follows: $ time gcc -O3 -S smuladd16.c real0m0.431s user0m0.069s sys 0m0.014s $ time gcc -O3 -S smuladd24.c real0m7.041s user0m7.011s sys 0m0.013s $ time gcc -O3 -S smuladd28.c real1m50.267s user1m49.829s sys 0m0.109s I checked that later versions of gcc (4.4.6, 4.7.3, gcc-4.9.0) behave normally. But actually we are using a cross-compiler based on gcc-4.1.2 with plenty of changes and we cannot migrate to to a later gcc version quickly. Is there a patch which solves the problem?
[Bug target/60693] [4.8/4.9 Regression] ICE on funny memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60693 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||jakub at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32472 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32472action=edit gcc49-pr60693.patch Untested fix.
[Bug tree-optimization/60656] [4.8/4.9 regression] x86 vectorization produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60656
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Cong Hou from comment #4)
Yes, there is a quick fix: we can check if the def with
vect_used_by_reduction is immediately used by a reduction stmt. After all,
it seems that supportable_widening_operation() is the only place that takes
advantage of this the element order doesn't matter feature.
diff --git a/gcc/tree-vect-stmts.c b/gcc/tree-vect-stmts.c
index 70fb411..7442d0c 100644
--- a/gcc/tree-vect-stmts.c
+++ b/gcc/tree-vect-stmts.c
@@ -7827,7 +7827,16 @@ supportable_widening_operation (enum tree_code code,
gimple stmt,
stmt, vectype_out, vectype_in,
code1, code2, multi_step_cvt,
interm_types))
- return true;
+{
+ tree lhs = gimple_assign_lhs (stmt);
+ use_operand_p dummy;
+ gimple use_stmt;
+ stmt_vec_info use_stmt_info = NULL;
+ if (single_imm_use (lhs, dummy, use_stmt)
+ (use_stmt_info = vinfo_for_stmt (use_stmt))
+ STMT_VINFO_DEF_TYPE (use_stmt_info) == vect_reduction_def)
+return true;
+}
c1 = VEC_WIDEN_MULT_LO_EXPR;
c2 = VEC_WIDEN_MULT_HI_EXPR;
break;
Looks good to me, perhaps just no need to initialize use_stmt_info to NULL.
Are you going to bootstrap/regtest this and post to gcc-patches?
[Bug middle-end/48099] Evaluation order of arguments in a call expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48099 --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Richard Biener from comment #4) Java. Even with the removal of the Java source compiler (the byte code one should be safe enough).
[Bug target/60675] [4.9 regression][aarch64] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60675 --- Comment #9 from Jakub Jelinek jakub at gcc dot gnu.org --- Note I couldn't reproduce this with a cross from x86_64-linux to aarch64-linux, wonder what is the important difference. While I don't have cross binutils installed, I made sure I have HAVE_GAS_HIDDEN and HAVE_AS_TLS enabled in auto-host.h.
[Bug middle-end/60647] [4.9 Regression] ICE in visit_ref_for_mod_analysis, at ipa-prop.c:2112
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60647
--- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org ---
Non-KR that ICEs the same way (with call through incompatible function pointer
type):
struct _wincore
{
int width, height;
};
static void
foo (void *dpy, struct _wincore *winInfo, int offset)
{
fn1 (winInfo-height);
}
static void
bar (void *dpy, int winInfo, int *visrgn)
{
((void (*) (void *, int, int)) foo) ((void *) 0, winInfo, 0);
fn2 (0, 0, visrgn);
}
void
baz (void *dpy, int win, int prop)
{
bar ((void *) 0, 0, (int *) 0);
}
[Bug target/60675] [4.9 regression][aarch64] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60675 --- Comment #10 from ktkachov at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #9) Note I couldn't reproduce this with a cross from x86_64-linux to aarch64-linux, wonder what is the important difference. While I don't have cross binutils installed, I made sure I have HAVE_GAS_HIDDEN and HAVE_AS_TLS enabled in auto-host.h. I can reproduce it with an aarch64-none-elf cross compiler at revision 208889 configured with: --with-pkgversion=unknown --disable-shared --disable-nls --disable-threads --disable-tls --enable-checking=yes --enable-languages=c,c++,fortran --with-newlib --with-cpu=cortex-a53 --with-arch=armv8-a I haven't tried a linux compiler, I'll try that next...
[Bug middle-end/60640] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60640 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P1 CC||jakub at gcc dot gnu.org
[Bug middle-end/60640] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60640
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
Reduced testcase:
struct A {};
struct E { ~E (); };
struct B { virtual unsigned foo () const; };
struct C { virtual void foo (); };
struct D : public A { D (A *); };
struct I : public D { A i; I (int) : D (0) {} };
struct F : E { virtual unsigned foo (bool) const; };
template class T
struct G : public T {};
struct J : C, public F {};
struct K : public J { unsigned foo (bool) const { return 0; } };
struct H : B
{
H (A);
unsigned foo () const { return bar ().foo (0); }
const F bar () const { return h; }
GK h;
};
template class T
void
baz ()
{
I f (0);
T d (f);
}
void
test ()
{
bazH ();
}
Regressed with r205019.
[Bug fortran/60677] [4.9 Regression] FAIL: gfortran.dg/ichar_3.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60677
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
Status|UNCONFIRMED |NEW
Last reconfirmed||2014-03-28
CC||burnus at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Tobias Burnus burnus at gcc dot gnu.org ---
We have:
gfc_conv_intrinsic_ichar (gfc_se * se, gfc_expr * expr)
{
tree args[2], type, pchartype;
int nargs;
nargs = gfc_intrinsic_argument_list_length (expr);
gfc_conv_intrinsic_function_args (se, expr, args, nargs);
The problem is that nargs == 3, but we have args[2]. The arguments are the
character (BT_CHARACTER) and the kind (BT_INTEGER). However,
gfc_intrinsic_argument_list_length counts character types as len==2 as one
usually has a character length. Hence, one accesses invalid memory with
gfc_conv_intrinsic_function_args.
[Bug middle-end/60640] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60640
--- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org ---
That is still too big, here is a smaller one:
struct B { virtual unsigned f () const; };
struct C { virtual void f (); };
struct F { virtual unsigned f (bool) const; ~F (); };
struct J : C, F {};
struct G : J { unsigned f (bool) const { return 0; } };
struct H : B
{
H (int);
unsigned f () const { return ((const F ) h).f (0); }
G h;
};
H h (0);
[Bug middle-end/60640] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60640
--- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #4)
That is still too big, here is a smaller one:
struct B { virtual unsigned f () const; };
struct C { virtual void f (); };
struct F { virtual unsigned f (bool) const; ~F (); };
struct J : C, F {};
struct G : J { unsigned f (bool) const { return 0; } };
struct H : B
{
H (int);
unsigned f () const { return ((const F ) h).f (0); }
G h;
};
H h (0);
Though, on this reduced testcase the ICE started with r176424, i.e. making it a
4.7/4.8/4.9 Regression on that testcase.
[Bug c++/60695] New: std::atomicX doesn't work when X is of zero size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60695
Bug ID: 60695
Summary: std::atomicX doesn't work when X is of zero size
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roman at binarylife dot net
$ cat test.cc
#include atomic
struct X {
char stuff[0];
};
X foo(std::atomicX a, X x) {
a = x;
return a;
}
$ g++ -std=c++11 -c test.cc
In file included from test.cc:1:0:
/home/abend/local/gcc-4.9/include/c++/4.9.0/atomic: In instantiation of ‘void
std::atomic_Tp::store(_Tp, std::memory_order) [with _Tp = X;
std::memory_order = std::memory_order]’:
/home/abend/local/gcc-4.9/include/c++/4.9.0/atomic:183:18: required from ‘_Tp
std::atomic_Tp::operator=(_Tp) [with _Tp = X]’
test.cc:8:5: required from here
/home/abend/local/gcc-4.9/include/c++/4.9.0/atomic:199:39: error: argument 1 of
‘__atomic_store’ must be a pointer to a nonzero size object
{ __atomic_store(_M_i, __i, _m); }
^
/home/abend/local/gcc-4.9/include/c++/4.9.0/atomic: In instantiation of ‘_Tp
std::atomic_Tp::load(std::memory_order) const [with _Tp = X;
std::memory_order = std::memory_order]’:
/home/abend/local/gcc-4.9/include/c++/4.9.0/atomic:176:21: required from
‘std::atomic_Tp::operator _Tp() const [with _Tp = X]’
test.cc:9:10: required from here
/home/abend/local/gcc-4.9/include/c++/4.9.0/atomic:209:31: error: argument 1 of
‘__atomic_load’ must be a pointer to a nonzero size object
__atomic_load(_M_i, tmp, _m);
^
$ g++ --version
g++ (GCC) 4.9.0 20140327 (experimental)
...
[Bug fortran/60677] [4.9 Regression] FAIL: gfortran.dg/ichar_3.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60677 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- *** Bug 60678 has been marked as a duplicate of this bug. ***
[Bug fortran/60678] [4.9 Regression] FAIL: gfortran.dg/intrinsics_kind_argument_1.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60678 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||burnus at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- Same backtrace - very likely the same issue as PR60677; diagnosed at PR60677 comment 1. *** This bug has been marked as a duplicate of bug 60677 ***
[Bug fortran/60576] [4.8/4.9 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576 --- Comment #7 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #6) H.J. just filed a separate PR about the ichar_3.f90 failure in PR60678. And one at PR 60677, which is due to the same cause. (The issue is there that one has a len=1 character argument and a kind, but the BT_CHARACTER leads to an extra length argument, which exceeds an array bound expecting only two arguments.)
[Bug c++/60695] std::atomicX doesn't work when X is of zero size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60695 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- That type isn't valid in ISO C++ and I don't see how you can usefully use it as an atomic object, so I don't think this failure matters. My preference would be to add this to std::atomic_Tp: static_assert( sizeof(_Tp) 0, Don't be silly );
[Bug target/60675] [4.9 regression][aarch64] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60675 --- Comment #11 from Vladimir Makarov vmakarov at gcc dot gnu.org --- I've been working on it. I hope the patch will be ready today.
[Bug libstdc++/60695] std::atomicX doesn't work when X is of zero size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60695 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-03-28 Component|c++ |libstdc++ Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org --- I'll add that assertion in the library.
[Bug other/60681] Libbacktrace library doesn't work with QEMU in application mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60681 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added CC||ian at airs dot com --- Comment #1 from Ian Lance Taylor ian at airs dot com --- I don't think there is anything useful that the libbacktrace library can do. When running under an emulator, opening /proc/self/exe should open the program being emulated. It shouldn't open the emulator itself. The libbacktrace library does permit the program to provide the name of the executable file. For the case of GCC in particular, we could modify it so that it passes argv[0] to backtrace_create_state in diagnostic_action_after_output in gcc/diagnostic.c. I didn't do that already because GCC does not currently record the unmodified argv[0] anywhere, and there are several different places that would need to be modified. I don't know that it's worth it for such an odd use case. But I wouldn't block such a patch if someone else writes it. And, of course, modifying GCC itself would not fix your problem since as far as I can tell you aren't running GCC anyhow. What program are you running? Can you arrange for it to pass argv[0] to backtrace_create_state? On GNU/Linux the libbacktrace library could try to get the executable name from /proc/self/cmdline, but I'm guessing that under QEMU that would give you the wrong answer just as /proc/self/exe does.
[Bug libstdc++/60695] std::atomicX doesn't work when X is of zero size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60695 --- Comment #3 from Roman Kononov roman at binarylife dot net --- Yes, it is definitely silly in some sense. But, some templated user code might become more complex with this behaviour. If gcc supports zero-sized objects it would be nice to support them fully. The implementation for this case might do the synchronization part without any data exchange.
[Bug c/51088] undefined label with statement expression and cond expression
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51088 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Keywords||documentation Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org --- Comment #4 from Marek Polacek mpolacek at gcc dot gnu.org --- We should make it clear in the documentation that this is invalid code. Mine.
[Bug c++/57493] Incorrect name lookup for range loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57493 Thomas Lamb tclamb at ufl dot edu changed: What|Removed |Added CC||tclamb at ufl dot edu --- Comment #1 from Thomas Lamb tclamb at ufl dot edu --- This bug is a duplicate of #54430.
[Bug c++/57493] Incorrect name lookup for range loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57493 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added Resolution|FIXED |DUPLICATE --- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com --- Dup of PR54430 *** This bug has been marked as a duplicate of bug 54430 ***
[Bug c++/54430] [C++11] For-Loop: Scope of iterating variable begins too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54430 Thomas Lamb tclamb at ufl dot edu changed: What|Removed |Added CC||tclamb at ufl dot edu --- Comment #1 from Thomas Lamb tclamb at ufl dot edu --- Just hit this bug in GCC 4.9. Again, the lhs side has scope before the rhs has been evaluated, which is against the standardese in section 6.5.4 of both N3936 and N3291.
[Bug c++/57493] Incorrect name lookup for range loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57493 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Paul Pluzhnikov ppluzhnikov at google dot com --- Dup.
[Bug java/60667] Undefined behavior in Java FE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60667 --- Comment #4 from Andrew Haley aph at gcc dot gnu.org --- Still no luck with ubsan, which seems to be broken: /usr/local/i686-pc-linux-gnu/sys-include-O2 -g -O2 -DIN_GCC-W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -fpic -mlong-double-80 -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -shared -nodefaultlibs -Wl,--soname=libgcc_s.so.1 -Wl,--version-script=libgcc.map -o ./libgcc_s.so.1.tmp -g -O2 -B./ _muldi3_s.o _negdi2_s.o _lshrdi3_s.o _ashldi3_s.o _ashrdi3_s.o _cmpdi2_s.o _ucmpdi2_s.o _clear_cache_s.o _trampoline_s.o __main_s.o _absvsi2_s.o _absvdi2_s.o _addvsi3_s.o _addvdi3_s.o _subvsi3_s.o _subvdi3_s.o _mulvsi3_s.o _mulvdi3_s.o _negvsi2_s.o _negvdi2_s.o _ctors_s.o _ffssi2_s.o _ffsdi2_s.o _clz_s.o _clzsi2_s.o _clzdi2_s.o _ctzsi2_s.o _ctzdi2_s.o _popcount_tab_s.o _popcountsi2_s.o _popcountdi2_s.o _paritysi2_s.o _paritydi2_s.o _powisf2_s.o _powidf2_s.o _powixf2_s.o _powitf2_s.o _mulsc3_s.o _muldc3_s.o _mulxc3_s.o _multc3_s.o _divsc3_s.o _divdc3_s.o _divxc3_s.o _divtc3_s.o _bswapsi2_s.o _bswapdi2_s.o _clrsbsi2_s.o _clrsbdi2_s.o _fixunssfsi_s.o _fixunsdfsi_s.o _fixunsxfsi_s.o _fixsfdi_s.o _fixdfdi_s.o _fixxfdi_s.o _fixunssfdi_s.o _fixunsdfdi_s.o _fixunsxfdi_s.o _floatdisf_s.o _floatdidf_s.o _floatdixf_s.o _floatundisf_s.o _floatundidf_s.o _floatundixf_s.o _divdi3_s.o _moddi3_s.o _udivdi3_s.o _umoddi3_s.o _udiv_w_sdiv_s.o _udivmoddi4_s.o cpuinfo_s.o tf-signs_s.o sfp-exceptions_s.o addtf3_s.o divtf3_s.o eqtf2_s.o getf2_s.o letf2_s.o multf3_s.o negtf2_s.o subtf3_s.o unordtf2_s.o fixtfsi_s.o fixunstfsi_s.o floatsitf_s.o floatunsitf_s.o fixtfdi_s.o fixunstfdi_s.o floatditf_s.o floatunditf_s.o extendsftf2_s.o extenddftf2_s.o extendxftf2_s.o trunctfsf2_s.o trunctfdf2_s.o trunctfxf2_s.o enable-execute-stack_s.o unwind-dw2_s.o unwind-dw2-fde-dip_s.o unwind-sjlj_s.o unwind-c_s.o emutls_s.o libgcc.a -lc rm -f ./libgcc_s.so if [ -f ./libgcc_s.so.1 ]; then mv -f ./libgcc_s.so.1 ./libgcc_s.so.1.backup; else true; fi mv ./libgcc_s.so.1.tmp ./libgcc_s.so.1 ln -s libgcc_s.so.1 ./libgcc_s.so /usr/bin/ld: /gcc/obj-i686-pc-linux-gnu/./gcc/liblto_plugin.so: error loading plugin: /gcc/obj-i686-pc-linux-gnu/./gcc/liblto_plugin.so: undefined symbol: __ubsan_handle_type_mismatch collect2: error: ld returned 1 exit status make[3]: *** [libgcc_s.so] Error 1 make[3]: Leaving directory `/gcc/obj-i686-pc-linux-gnu/i686-pc-linux-gnu/libgcc' make[2]: *** [all-stage2-target-libgcc] Error 2 make[2]: Leaving directory `/gcc/obj-i686-pc-linux-gnu' make[1]: *** [stage2-bubble] Error 2 make[1]: Leaving directory `/gcc/obj-i686-pc-linux-gnu' make: *** [all] Error 2 If you can tell me how you do a build I'll be grateful.
[Bug java/60667] Undefined behavior in Java FE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60667 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- Supposedly you could just try to configure with --disable-lto to workaround it. Not to mention that you really don't need to do bootstrap-ubsan for this, just add --- gcc/double-int.c2014-01-03 11:40:46.102383481 +0100 +++ gcc/double-int.c2014-03-28 17:05:37.237498526 +0100 @@ -1060,9 +1060,11 @@ double_int::set_bit (unsigned bitpos) co double_int a = *this; if (bitpos HOST_BITS_PER_WIDE_INT) a.low |= (unsigned HOST_WIDE_INT) 1 bitpos; - else + else if (bitpos HOST_BITS_PER_DOUBLE_INT) a.high |= (HOST_WIDE_INT) 1 (bitpos - HOST_BITS_PER_WIDE_INT); - + else +gcc_unreachable (); + return a; } and you should be able to reproduce it with normal bootstrap/regtest.
[Bug sanitizer/60275] [UBSAN] Add -f[no-]sanitize-recover/-fsanitize-undefined-trap-on-error to make UBSAN's runtime errors fatal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60275 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org --- (In reply to Jakub Jelinek from comment #3) I guess we shouldn't copy the design mistakes clang makes. What action to take on detected undefined behavior should be orthogonal to how to report it (runtime error message with recovery, fatal runtime error message or abort without error message). The question is how to implement this properly. One way is using environment variables such as ASAN and TSAN do, which have environment variables, e.g. ASAN has https://code.google.com/p/address-sanitizer/wiki/Flags#Run-time_flags , which permits: ASAN_OPTIONS= abort_on_error (default 0) exitcode (default 1) etc. It would be also nice to have a back trace. (I had an always inlined add function, which overflows and there pointing to the header file does not help much.) Still, it is also nice to be able to tell at compile time that failures should be fatal as one can easily forget to set the environment variable. If one does not want to go the route of Clang, I wonder how to handle it instead as one does not have one initializing call to the library.
[Bug c++/60698] New: non-empty braced-or-equal-initializer of non-static data member T[N] in class template results in error diagnostic, if T is a class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60698
Bug ID: 60698
Summary: non-empty braced-or-equal-initializer of non-static
data member T[N] in class template results in error
diagnostic, if T is a class
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: filip.roseen at gmail dot com
Created attachment 32476
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32476action=edit
testcase.cpp
struct A { };
templateclass
struct B {
A a[1] = { A () };
};
int main () { Bvoid b; }
--
The above is a legal construct, but gcc rejects it with the following
diagnostic:
testcase.cpp: In constructor ‘constexpr Bvoid::B()’:
testcase.cpp:4:8: error: invalid initializer for array member ‘A Bvoid::a
[1]’
struct B {
^
testcase.cpp: In function ‘int main()’:
testcase.cpp:8:24: note: synthesized method ‘constexpr Bvoid::B()’ first
required here
int main () { Bvoid {}; }
[ Note: Both `clang` and `icc` correctly accepts the snippet provided. ]
[Bug tree-optimization/60656] [4.8/4.9 regression] x86 vectorization produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60656 --- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org --- Created attachment 32475 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32475action=edit gcc49-pr60656.patch I've bootstrapped/regtested in the mean time this patch on x86_64-linux and i686-linux, no regression. As it is your patch, can you please post it?
[Bug debug/58150] debug info about definition of enum class not emitted if the declaration was already used in a class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58150 --- Comment #1 from Ben Longbons b.r.longbons at gmail dot com --- Still present in gcc 4.9 as of 2014-03-22 Currently I'm hacking around this by using a gdb pretty printer that hard-codes the enum values and turns them into strings, but that only works for printing, not calls.
[Bug c++/58678] [4.9 Regression] pykde4-4.11.2 link error (devirtualization too trigger happy)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58678 --- Comment #56 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Mar 28 17:17:56 2014 New Revision: 208907 URL: http://gcc.gnu.org/viewcvs?rev=208907root=gccview=rev Log: PR c++/58678 * g++.dg/abi/thunk6.C: Scan assembler for _ZTv0_n32_N1CD1Ev only for lp64 targets and scan for _ZTv0_n16_N1CD1Ev for ilp32 targets. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/abi/thunk6.C
[Bug c++/52369] Const-qualified non-class base member and defaulted default constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52369 fabien at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |4.8.3 --- Comment #4 from fabien at gcc dot gnu.org --- Fixed.
[Bug c++/49604] forward-declared enum's elements in class scope gets default access (class vs struct)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49604 --- Comment #2 from Ben Longbons b.r.longbons at gmail dot com --- Still an issue with 4.9 as of 2014-03-22
[Bug sanitizer/60275] [UBSAN] Add -f[no-]sanitize-recover/-fsanitize-undefined-trap-on-error to make UBSAN's runtime errors fatal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60275 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org --- I guess we shouldn't copy the design mistakes clang makes. What action to take on detected undefined behavior should be orthogonal to how to report it (runtime error message with recovery, fatal runtime error message or abort without error message).
[Bug target/60697] [aarch64] LRA ICE (Segfault) while building 435.gromacs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60697 --- Comment #2 from ktkachov at gcc dot gnu.org --- The compiler has been configured with: --with-pkgversion=unknown --disable-shared --disable-nls --disable-threads --disable-tls --enable-checking=yes --enable-languages=c,c++,fortran --with-newlib --with-cpu=cortex-a53 --with-arch=armv8-a
[Bug middle-end/60647] [4.9 Regression] ICE in visit_ref_for_mod_analysis, at ipa-prop.c:2112
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60647 Martin Jambor jamborm at gcc dot gnu.org changed: What|Removed |Added URL||http://gcc.gnu.org/ml/gcc-p ||atches/2014-03/msg01629.htm ||l --- Comment #8 from Martin Jambor jamborm at gcc dot gnu.org --- I've proposed a fix on the mailing list: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01629.html
[Bug c++/54430] [C++11] For-Loop: Scope of iterating variable begins too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54430 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-28 Ever confirmed|0 |1
[Bug libstdc++/60695] std::atomicX doesn't work when X is of zero size
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60695 --- Comment #4 from Jonathan Wakely redi at gcc dot gnu.org --- I don't buy it. That zero-size struct type has very limited uses, it's not the sort of type you use like other value types, and I can't imagine any scenario where that type is useful where you're also storing generic types in std::atomic. I don't want to complicate the implementation even if someone thinks of an obscure hypothetical use case.
[Bug c++/60699] New: empty braced-init-list of non-static data member T[N] in class template results in ICE, if T is a class
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60699
Bug ID: 60699
Summary: empty braced-init-list of non-static data member T[N]
in class template results in ICE, if T is a class
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: filip.roseen at gmail dot com
Created attachment 32477
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32477action=edit
testcase.cpp
struct A { };
templateclass
struct B {
A a[1] = { };
};
int main () { Bvoid b; }
---
testcase.cpp: In constructor ?constexpr Bvoid::B()?:
testcase.cpp:4:8: internal compiler error: Segmentation fault
struct B {
^
Please submit a full bug report,
with preprocessed source if appropriate.
See https://bugs.archlinux.org/ for instructions
[Bug middle-end/60640] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60640 --- Comment #6 from Martin Jambor jamborm at gcc dot gnu.org --- I added the newest testcase to the patch a proposed it on the mailing list: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01640.html
[Bug java/60667] Undefined behavior in Java FE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60667 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- The http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01370.html fix is still waiting for review, you need that for both --with-build-config=bootstrap-ubsan and --with-build-config=bootstrap-asan. For --with-build-config=bootstrap-asan also the http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01433.html patch is needed, plus --with-build-config=bootstrap-asan will only work with -disable-werror for now (fix for that expected only in stage1).
[Bug target/60696] [aarch64] vld1 intrinsics gives unexpected result in big_endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60696 christophe.lyon at st dot com changed: What|Removed |Added Target||aarch64 Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #1 from christophe.lyon at st dot com --- After I updated my trunk copy, the problem vanished.
[Bug c/60700] New: missing dependency between %ax and %eax when compiling 32bit on 64bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60700
Bug ID: 60700
Summary: missing dependency between %ax and %eax when compiling
32bit on 64bit
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: yzhou61 at gmail dot com
When compiling with -m32 on a 64bit machine, gcc is generating wrong code for
the following snippet. The dependencies between %ax and %eax seems to have been
dropped, causing the memset to use the wrong value. Please fix. Thanks.
$ cat repro.c
#include stdlib.h
#include string.h
extern int foo(void);
void *g = (void *)1;
struct st {
char data[36]; // must be greater than 32
};
int repro(struct st **out)
{
int status = 0;
*out = NULL;
status = foo();
if (status != 0) {
return status;
}
if (NULL == g) {
status = 999;
return status;
}
*out = (struct st *)malloc(sizeof(struct st));
if (NULL == (*out)) {
status = 42;
return status;
}
memset(*out, 0, sizeof(struct st));
return status;
}
$ gcc -c -o repro.o repro.c -m32 -march=i686 -O3 -I. -Wall -Wextra
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -save-temps
$ cat repro.s
.file repro.c
.text
.p2align 4,,15
.globl repro
.type repro, @function
repro:
.LFB19:
.cfi_startproc
pushl %edi
.cfi_def_cfa_offset 8
.cfi_offset 7, -8
pushl %esi
.cfi_def_cfa_offset 12
.cfi_offset 6, -12
pushl %ebx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
subl$16, %esp
.cfi_def_cfa_offset 32
movl32(%esp), %ebx
movl$0, (%ebx)
callfoo
testl %eax, %eax
jne .L2
movlg, %edx
movw$999, %ax
testl %edx, %edx
je .L2
movl$36, (%esp)
movl%eax, %esi
callmalloc
movl%eax, %edx
testl %edx, %edx
movl%eax, (%ebx)
movl$42, %eax
je .L2
movl%esi, %eax
movl$9, %ecx
movl%edx, %edi
rep; stosl
xorl%eax, %eax
.p2align 4,,7
.p2align 3
.L2:
addl$16, %esp
.cfi_def_cfa_offset 16
popl%ebx
.cfi_restore 3
.cfi_def_cfa_offset 12
popl%esi
.cfi_restore 6
.cfi_def_cfa_offset 8
popl%edi
.cfi_restore 7
.cfi_def_cfa_offset 4
ret
.cfi_endproc
.LFE19:
.size repro, .-repro
.globl g
.data
.align 4
.type g, @object
.size g, 4
g:
.long 1
.ident GCC: (GNU) 4.8.2
.section.note.GNU-stack,,@progbits
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure
Thread model: posix
gcc version 4.8.2 (GCC)
[Bug target/60675] [4.9 regression][aarch64] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60675 --- Comment #12 from Vladimir Makarov vmakarov at gcc dot gnu.org --- Author: vmakarov Date: Fri Mar 28 15:27:58 2014 New Revision: 208900 URL: http://gcc.gnu.org/viewcvs?rev=208900root=gccview=rev Log: 2014-03-28 Vladimir Makarov vmaka...@redhat.com PR target/60675 * lra-assigns.c (find_hard_regno_for): Remove unavailable hard regs from checking multi-reg pseudos. 2014-03-28 Vladimir Makarov vmaka...@redhat.com PR target/60675 * gcc.target/aarch64/pr60675.C: New. Added: trunk/gcc/testsuite/gcc.target/aarch64/pr60675.C Modified: trunk/gcc/ChangeLog trunk/gcc/lra-assigns.c trunk/gcc/testsuite/ChangeLog
[Bug target/60675] [4.9 regression][aarch64] internal compiler error: Max. number of generated reload insns per insn is achieved (90)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60675 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed then.
[Bug fortran/60677] [4.9 Regression] FAIL: gfortran.dg/ichar_3.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60677 Mikael Morin mikael at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||mikael at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin mikael at gcc dot gnu.org --- This bug is a follow-up to pr59599. Thanks for diagnosing the problem. I will commit a fix.
[Bug libfortran/60701] internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:551
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60701 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- The test succeeds with 4.6 to trunk, but ICE (in gfc_build_null_descriptor) with 4.5. Could you post the output of gfortran -v?
[Bug middle-end/60640] [4.9 Regression] ICE edge points to wrong declaration / verify_cgraph_node failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60640 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- (In reply to Martin Jambor from comment #6) I added the newest testcase to the patch a proposed it on the mailing list: http://gcc.gnu.org/ml/gcc-patches/2014-03/msg01640.html I still see the old testcase only there ;).
[Bug libfortran/60701] internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:551
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60701 --- Comment #2 from Peter Machon peter.machon at arcor dot de --- (In reply to Dominique d'Humieres from comment #1) The test succeeds with 4.6 to trunk, but ICE (in gfc_build_null_descriptor) with 4.5. Could you post the output of gfortran -v? Sure: Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/Users/pm/gcc_build_4.5/libexec/gcc/x86_64-apple-darwin10.7.0/4.5.2/lto-wrapper Target: x86_64-apple-darwin10.7.0 Configured with: ./configure --prefix=/Users/pm/gcc_build_4.5/ --enable-cloog-backend=isl --enable-languages=c,c++,fortran,objc Thread model: posix gcc version 4.5.2 (GCC)
[Bug c++/60689] Bogus error with atomic::exchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60689 --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Mar 28 18:16:32 2014 New Revision: 208912 URL: http://gcc.gnu.org/viewcvs?rev=208912root=gccview=rev Log: PR c++/60689 * c-tree.h (c_build_function_call_vec): New prototype. * c-typeck.c (build_function_call_vec): Don't call resolve_overloaded_builtin here. (c_build_function_call_vec): New wrapper function around build_function_call_vec. Call resolve_overloaded_builtin here. (convert_lvalue_to_rvalue, build_function_call, build_atomic_assign): Call c_build_function_call_vec instead of build_function_call_vec. * c-parser.c (c_parser_postfix_expression_after_primary): Likewise. * c-decl.c (finish_decl): Likewise. * c-common.c (add_atomic_size_parameter): When creating new params vector, push the size argument first. * c-c++-common/pr60689.c: New test. Added: trunk/gcc/testsuite/c-c++-common/pr60689.c Modified: trunk/gcc/c-family/ChangeLog trunk/gcc/c-family/c-common.c trunk/gcc/c/ChangeLog trunk/gcc/c/c-decl.c trunk/gcc/c/c-parser.c trunk/gcc/c/c-tree.h trunk/gcc/c/c-typeck.c trunk/gcc/testsuite/ChangeLog
[Bug c++/54430] [C++11] For-Loop: Scope of iterating variable begins too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54430 --- Comment #3 from Paul Pluzhnikov ppluzhnikov at google dot com --- From PR57493: Google ref: b/9229787
[Bug target/60697] New: [aarch64] LRA ICE (Segfault) while building 435.gromacs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60697 Bug ID: 60697 Summary: [aarch64] LRA ICE (Segfault) while building 435.gromacs Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: ktkachov at gcc dot gnu.org Created attachment 32474 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32474action=edit Reduced testcase AArch64 compiler ICEs when building SPEC2k6. besttry.c:393:1: internal compiler error: Segmentation fault } ^ 0x9d311f crash_signal $TOP/gcc/gcc/toplev.c:337 0x8c73af base_plus_disp_to_reg $TOP/gcc/gcc/lra-constraints.c:2630 0x8c9f80 process_address $TOP/gcc/gcc/lra-constraints.c:2942 0x8cd10c curr_insn_transform $TOP/gcc/gcc/lra-constraints.c:3230 0x8cfebc lra_constraints(bool) $TOP/gcc/gcc/lra-constraints.c:4175 0x8c0e23 lra(_IO_FILE*) $TOP/gcc/gcc/lra.c:2353 0x88215e do_reload $TOP/gcc/gcc/ira.c:5457 0x88215e rest_of_handle_reload $TOP/gcc/gcc/ira.c:5598 0x88215e execute $TOP/gcc/gcc/ira.c:5627 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. Reduced testcase is attached. Fails with -O3 -mcpu=cortex-a53. Doesn't ICE with -O2
[Bug libfortran/60701] New: internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:551
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60701
Bug ID: 60701
Summary: internal compiler error: in gfc_conv_variable, at
fortran/trans-expr.c:551
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libfortran
Assignee: unassigned at gcc dot gnu.org
Reporter: peter.machon at arcor dot de
Created attachment 32478
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32478action=edit
called by main program just some matrix definitions.
The attached code produces the following error code:
test.f90: In function 'test':
test.f90:84:0: internal compiler error: in gfc_conv_variable, at
fortran/trans-expr.c:551
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
If gf in the function g(x,e) is not an array but a scalar, it's compiling and
running without an issue.
System: Mac OSX 10.6.8
Best, Peter
PS.: I saw a similar report (43896). So I'm sorry, in case, the issue is
already solved in a never version of gfortran.
Source:
module test_mod
implicit none
type terminal
character(len=1) :: typ
real(8) :: d
contains
procedure,pass :: g
end type
type(terminal),dimension(1:2) :: t
contains
function g(x,e) result(gf)
use pauli
class(terminal),intent(inout) :: x
real(8),intent(in) :: e
complex(8),dimension(1:2,1:2) :: gf
select case (x%typ)
case('N')
gf=sigma_3
case('S')
gf=e*sigma_3+x%d*sigma_1
end select
end function
end module
program test
use test_mod
implicit none
t(1)%typ='N'
t(2)%typ='S'
t(2)%d=3d0
write(*,*)t(1)%g(2d0)
write(*,*)t(2)%g(2d0)
end program
[Bug c++/54430] [C++11] For-Loop: Scope of iterating variable begins too early
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54430 Paul Pluzhnikov ppluzhnikov at google dot com changed: What|Removed |Added CC||ppluzhnikov at google dot com --- Comment #2 from Paul Pluzhnikov ppluzhnikov at google dot com --- *** Bug 57493 has been marked as a duplicate of this bug. ***
[Bug fortran/43896] [OOP] ICE in gfc_conv_variable, at fortran/trans-expr.c:551
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43896 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added CC||peter.machon at arcor dot de --- Comment #23 from Dominique d'Humieres dominiq at lps dot ens.fr --- *** Bug 60701 has been marked as a duplicate of this bug. ***
[Bug libfortran/60701] internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:551
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60701 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 --- gcc version 4.5.2 (GCC) 4.5 and 4.6 are no longer supported. You should upgrade to 4.8.2: pr43896 has been fixed by r158910, Apr 29 2010 (BTW where did you get your gfortran?). *** This bug has been marked as a duplicate of bug 43896 ***
[Bug java/60667] Undefined behavior in Java FE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60667 --- Comment #6 from Andrew Haley aph at gcc dot gnu.org --- OK, pls ping me whan the tree is stable and I'll fix the Java FE.
[Bug libfortran/60701] internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:551
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60701 --- Comment #4 from Peter Machon peter.machon at arcor dot de --- (In reply to Dominique d'Humieres from comment #3) gcc version 4.5.2 (GCC) 4.5 and 4.6 are no longer supported. You should upgrade to 4.8.2: pr43896 has been fixed by r158910, Apr 29 2010 (BTW where did you get your gfortran?). *** This bug has been marked as a duplicate of bug 43896 *** Yes thanks a lot. Upgrading is probably the best solution. I don't entirely get your question. I think I downloaded the source from your web-page and just compiled it. But that's already some years ago.
[Bug target/60697] [aarch64] LRA ICE (Segfault) while building 435.gromacs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60697 Vladimir Makarov vmakarov at gcc dot gnu.org changed: What|Removed |Added CC||vmakarov at gcc dot gnu.org --- Comment #3 from Vladimir Makarov vmakarov at gcc dot gnu.org --- LRA changes DImode pseudo onto equiv memory and subreg of the pseudo is transformed by MEM of SImode for each address index scaling by 8 becomes wrong for AARCH64. The problem can be fixed by prohibiting such equiv substitution (more complicated approach) or by transforming the index address (less complicated). I'll try to fix it for a couple days. Thanks.
[Bug tree-optimization/60656] [4.8/4.9 regression] x86 vectorization produces wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60656 --- Comment #7 from Cong Hou congh at google dot com --- Yes, will do it. Thank you a lot!
[Bug libfortran/52539] I/O: Wrong result for UTF-8/UCS-4 list-directed and namelist read and nml write
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52539 Jerry DeLisle jvdelisle at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #4 from Jerry DeLisle jvdelisle at gcc dot gnu.org --- I will start working on this one.
[Bug fortran/60677] [4.9 Regression] FAIL: gfortran.dg/ichar_3.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60677 --- Comment #4 from Mikael Morin mikael at gcc dot gnu.org --- Author: mikael Date: Fri Mar 28 18:58:44 2014 New Revision: 208913 URL: http://gcc.gnu.org/viewcvs?rev=208913root=gccview=rev Log: fortran/ PR fortran/60677 * trans-intrinsic.c (gfc_conv_intrinsic_ichar): Enlarge argument list buffer. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-intrinsic.c
[Bug c++/60687] [4.8.0] Infinite loop compiling recursive templates indirectly by local class in function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60687 Yury Usishchev jolfzverb at gmail dot com changed: What|Removed |Added CC||jolfzverb at gmail dot com --- Comment #2 from Yury Usishchev jolfzverb at gmail dot com --- Created attachment 32479 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32479action=edit Reduced testcase The loop is not infinite, eventually(after 30 minutes for my workstation) build fails with error: main.cpp:35:60: error: template instantiation depth exceeds maximum of 900 you can use -ftemplate-depth=100 to achieve it faster.
[Bug target/60696] New: [aarch64] vld1 intrinsics gives unexpected result in big_endian
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60696 Bug ID: 60696 Summary: [aarch64] vld1 intrinsics gives unexpected result in big_endian Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: christophe.lyon at st dot com Created attachment 32473 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32473action=edit ref_vld1.c testcase When invoking the attached test through gcc-dg-runtest, execution fails for target aarch64_be (using the Foundation Model), and works OK for these other targets: aarch64-none-linux-gnu \ aarch64-none-elf \ arm-none-linux-gnueabihf \ armeb-none-linux-gnueabihf \ arm-none-linux-gnueabi \ armeb-none-linux-gnueabi \ arm-none-eabi
[Bug sanitizer/60275] [UBSAN] Add -f[no-]sanitize-recover/-fsanitize-undefined-trap-on-error to make UBSAN's runtime errors fatal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60275 --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- Post script: CLANG has: '-fsanitize=undefined' not allowed with '-fsanitize-undefined-trap-on-error' And regarding the function call: With -fno-sanitize-recover one simply appends an _abort to the function call, i.e. __ubsan_handle_add_overflow becomes __ubsan_handle_add_overflow_abort. [For all functions but __ubsan_handle_builtin_unreachable and __ubsan_handle_missing_return, which always abort / Die() themselves.]
[Bug target/60697] [aarch64] LRA ICE (Segfault) while building 435.gromacs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60697 ktkachov at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Target||aarch64-linux-gnu CC||vmakarov at redhat dot com Host||aarch64-linux-gnu Known to fail||4.9.0 --- Comment #1 from ktkachov at gcc dot gnu.org --- Also, doesn't ICE with -mno-lra
[Bug target/60693] [4.8/4.9 Regression] ICE on funny memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60693 --- Comment #4 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: jakub Date: Fri Mar 28 19:31:17 2014 New Revision: 208915 URL: http://gcc.gnu.org/viewcvs?rev=208915root=gccview=rev Log: PR target/60693 * config/i386/i386.c (ix86_copy_addr_to_reg): Call copy_addr_to_reg also if addr has VOIDmode. * gcc.target/i386/pr60693.c: New test. Added: trunk/gcc/testsuite/gcc.target/i386/pr60693.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/i386.c trunk/gcc/testsuite/ChangeLog
[Bug target/60693] [4.8 Regression] ICE on funny memcpy
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60693 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Known to work||4.9.0 Summary|[4.8/4.9 Regression] ICE on |[4.8 Regression] ICE on |funny memcpy|funny memcpy Known to fail|4.9.0 | --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed on the trunk so far.
[Bug other/60681] Libbacktrace library doesn't work with QEMU in application mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60681
Yuri Gribov tetra2005 at gmail dot com changed:
What|Removed |Added
CC||tetra2005 at gmail dot com
--- Comment #2 from Yuri Gribov tetra2005 at gmail dot com ---
(In reply to Maxim Ostapenko from comment #0)
After investigation I discovered that libbacktrace scans /proc/self/exe to
init symbolizer and in QEMU case it finds information about qemu-arm binary
itself, not a.out.
I think this needs to be fixed (or rather implemented) in QEMU. They already
intercept accesses to /proc/self/{maps,stat,auxv}.
See https://github.com/qemu/qemu/blob/master/linux-user/syscall.c
[Bug fortran/60677] [4.7/4.8 Regression] FAIL: gfortran.dg/ichar_3.f90 -O (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60677 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org Target Milestone|4.9.0 |4.7.4 Summary|[4.9 Regression] FAIL: |[4.7/4.8 Regression] FAIL: |gfortran.dg/ichar_3.f90 -O |gfortran.dg/ichar_3.f90 -O | (test for excess errors) | (test for excess errors) --- Comment #5 from Jakub Jelinek jakub at gcc dot gnu.org --- Fixed on the trunk. From the referenced PR, seems like this bug now exists also on 4.7/4.8.
[Bug ipa/60243] IPA is slow on large cgraph tree
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60243 --- Comment #14 from Jan Hubicka hubicka at gcc dot gnu.org --- Author: hubicka Date: Fri Mar 28 19:50:28 2014 New Revision: 208916 URL: http://gcc.gnu.org/viewcvs?rev=208916root=gccview=rev Log: PR ipa/60243 * ipa-inline.c (want_inline_small_function_p): Short circuit large functions; reorganize to make cheap checks first. (inline_small_functions): Do not estimate growth when dumping; it is expensive. * ipa-inline.h (inline_summary): Add min_size. (growth_likely_positive): New function. * ipa-inline-analysis.c (dump_inline_summary): Add min_size. (set_cond_stmt_execution_predicate): Cleanup. (estimate_edge_size_and_time): Compute min_size. (estimate_calls_size_and_time): Likewise. (estimate_node_size_and_time): Likewise. (inline_update_overall_summary): Update min_size. (do_estimate_edge_time): Likewise. (do_estimate_edge_size): Update. (do_estimate_edge_hints): Update. (growth_likely_positive): New function. Modified: trunk/gcc/ChangeLog trunk/gcc/ipa-inline-analysis.c trunk/gcc/ipa-inline.c trunk/gcc/ipa-inline.h
[Bug other/60681] Libbacktrace library doesn't work with QEMU in application mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60681 --- Comment #3 from Yuri Gribov tetra2005 at gmail dot com --- (In reply to Yuri Gribov from comment #2) I think this needs to be fixed (or rather implemented) in QEMU. QEMU bug: https://bugs.launchpad.net/qemu/+bug/1299190
[Bug target/60700] [4.8 Regression] missing dependency between %ax and %eax when compiling 32bit on 64bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60700 H.J. Lu hjl.tools at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-03-28 Target Milestone|--- |4.8.3 Summary|missing dependency between |[4.8 Regression] missing |%ax and %eax when compiling |dependency between %ax and |32bit on 64bit |%eax when compiling 32bit ||on 64bit Ever confirmed|0 |1 --- Comment #1 from H.J. Lu hjl.tools at gmail dot com --- It is fixed on trunk by r201326.
[Bug other/60681] Libbacktrace library doesn't work with QEMU in application mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60681 Ian Lance Taylor ian at airs dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WONTFIX --- Comment #4 from Ian Lance Taylor ian at airs dot com --- Thanks for filing the bug against qemu. Nothing to fix in GCC.
[Bug ipa/60659] [4.9 Regression] ICE in get_polymorphic_call_info, at ipa-devirt.c:1292
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60659 --- Comment #4 from Jan Hubicka hubicka at gcc dot gnu.org --- OK, this is ICE on type inconsistent program (it looks up virtual function in non-virtual type). I forgot gcc_unreacable on that code path from earlier sanity checking. I will arrange such inconsistent calls to be builtin_unreachable.
[Bug fortran/60576] [4.8 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Summary|[4.8/4.9 Regression] FAIL: |[4.8 Regression] FAIL: |gfortran.dg/assumed_rank_7. |gfortran.dg/assumed_rank_7. |f90 |f90 --- Comment #8 from Jakub Jelinek jakub at gcc dot gnu.org --- Author: burnus Date: Fri Mar 28 20:04:01 2014 New Revision: 208918 URL: http://gcc.gnu.org/viewcvs?rev=208918root=gccview=rev Log: 2014-03-28 Mikael Morin mik...@gcc.gnu.org Tobias Burnus bur...@net-b.de PR fortran/ * trans-expr.c (gfc_conv_derived_to_class): Avoid generation of out-of-bounds range expr. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c
[Bug fortran/60576] [4.8 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576 --- Comment #9 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Revision: 208918 Modified property: svn:log Modified: svn:log at Fri Mar 28 20:34:48 2014 -- --- svn:log (original) +++ svn:log Fri Mar 28 20:34:48 2014 @@ -1,7 +1,7 @@ 2014-03-28 Mikael Morin mik...@gcc.gnu.org Tobias Burnus bur...@net-b.de -PR fortran/ +PR fortran/60576 * trans-expr.c (gfc_conv_derived_to_class): Avoid generation of out-of-bounds range expr.
[Bug c++/60573] [c++1y] ICE with defining generic function of nested class in class scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60573 --- Comment #1 from Adam Butcher abutcher at gcc dot gnu.org --- Author: abutcher Date: Fri Mar 28 20:41:45 2014 New Revision: 208921 URL: http://gcc.gnu.org/viewcvs?rev=208921root=gccview=rev Log: Fix PR c++/60573 PR c++/60573 * name-lookup.h (cp_binding_level): New transient field defining_class_p to indicate whether a scope is in the process of defining a class. * semantics.c (begin_class_definition): Set defining_class_p. * name-lookup.c (leave_scope): Reset defining_class_p. * parser.c (synthesize_implicit_template_parm): Use cp_binding_level:: defining_class_p rather than TYPE_BEING_DEFINED as the predicate for unwinding to class-defining scope to handle the erroneous definition of a generic function of an arbitrarily nested class within an enclosing class. PR c++/60573 * g++.dg/cpp1y/pr60573.C: New testcase. Added: trunk/gcc/testsuite/g++.dg/cpp1y/pr60573.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/name-lookup.c trunk/gcc/cp/name-lookup.h trunk/gcc/cp/parser.c trunk/gcc/cp/semantics.c trunk/gcc/testsuite/ChangeLog
[Bug c++/60573] [c++1y] ICE with defining generic function of nested class in class scope
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60573 Adam Butcher abutcher at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #2 from Adam Butcher abutcher at gcc dot gnu.org --- Fixed in 4.9.
[Bug libfortran/60701] internal compiler error: in gfc_conv_variable, at fortran/trans-expr.c:551
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60701 --- Comment #5 from Peter Machon peter.machon at arcor dot de --- Addendum: With version 4.8.2 it works just fine, thanks a lot!
[Bug fortran/60576] [4.8 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576 --- Comment #10 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Fri Mar 28 20:56:28 2014 New Revision: 208923 URL: http://gcc.gnu.org/viewcvs?rev=208923root=gccview=rev Log: 2014-03-28 Mikael Morin mik...@gcc.gnu.org Tobias Burnus bur...@net-b.de PR fortran/60576 * trans-expr.c (gfc_conv_derived_to_class): Avoid generation of out-of-bounds range expr. Modified: branches/gcc-4_8-branch/gcc/fortran/ChangeLog branches/gcc-4_8-branch/gcc/fortran/trans-expr.c
[Bug fortran/60576] [4.8 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576
--- Comment #11 from Tobias Burnus burnus at gcc dot gnu.org ---
(In reply to H.J. Lu from comment #0)
It only happens when running
make check-gfortran RUNTESTFLAGS=dg.exp=assumed_rank_7.f90
--target_board='unix{-march=corei7\ -fno-backtrace}'
Can you confirm that it is now fixed? Not that we only fixed part of the
problem.
[Bug target/60700] [4.8 Regression] missing dependency between %ax and %eax when compiling 32bit on 64bit
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60700 --- Comment #2 from H.J. Lu hjl.tools at gmail dot com --- It was triggered by r190339.
