[Bug tree-optimization/59303] [4.9 Regression] uninit-pred-8_b.c and uninit-pred-9_b.c fail after better optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303 --- Comment #8 from davidxl at google dot com --- Created attachment 31495 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31495&action=edit Patch file : cleanup + more predicate simplification rules
[Bug tree-optimization/59303] [4.9 Regression] uninit-pred-8_b.c and uninit-pred-9_b.c fail after better optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #9 from Jakub Jelinek --- Created attachment 31496 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31496&action=edit cleanups I had also a brief look at this recently, but haven't made progress beyond attached formatting/cleanup patch so far (plus only dumping details with *-details, otherwise the dumps are pretty much inconsistent). My conclusion has also been that to fix this up the predicates would need to be normalized before comparison, and simplified, at least if the initial subset check fails. On uninit-pred-8_b.c there has been additional complication because PRE decides to change the IL and we end up with: : pretmp_24 = r_10(D) <= 19; goto ; : _11 = r_10(D) <= 19; _13 = l_12(D) != 0; _14 = _11 | _13; if (_14 != 0) goto ; else goto ; : goto ; : : # v_1 = PHI # prephitmp_30 = PHI <0(15), pretmp_24(3)> if (m_7(D) != 0) goto ; else goto ; : g.0_17 = g; g.1_18 = g.0_17 + 1; g = g.1_18; goto ; : bar (); : _3 = prephitmp_30 | _9; if (_3 != 0) so the prephitmp_30 would need to be canonicalized into _14 != 0 && r_10(D) <= 19 aka (r_10(D) <= 19 || l_12(D) != 0) && r_10(D) <= 19 and from there to r_10(D) <= 19.
[Bug middle-end/59569] [4.9 Regression] r206148 causes internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Reduced testcase:
extern char c;
void
foo (int i, char **j)
{
while (i)
j[--i] = &c;
}
[Bug target/49226] problematic _Complex long double argument passing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49226 --- Comment #2 from rsandifo at gcc dot gnu.org --- Created attachment 31497 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31497&action=edit attempt to avoid invalid hard regs This patch uses the equivalent integer modes instead of :XC and :XF when passing arguments in GPRs. I worked through the before and after asm and they seem to be equivalent, but I'd appreciate it if someone with access to ia64 could try it out. The after asm seems to be worse, but this kind of usage shouldn't occur in performance-critical code anyway. I think if the speed :XC and :XF GPR handling is a concern we'd be better off making the modes valid.
[Bug libfortran/59419] [4.9 Regression] Failing OPEN with FILE='xxx' and IOSTAT creates the file 'xxx' after revision 196783
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59419 --- Comment #8 from Dominique d'Humieres --- The modified test gfortran.dg/open_negative_unit_1.f90 in the patch submitted at http://gcc.gnu.org/ml/fortran/2013-12/msg00124.html checks that this PR is fixed.
[Bug target/49226] problematic _Complex long double argument passing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49226 Eric Botcazou changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2013-12-21 Assignee|unassigned at gcc dot gnu.org |ebotcazou at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Eric Botcazou --- In order to test Richard's patch.
[Bug middle-end/59572] New: Not clear error message in smallest_mode_for_size in handled case
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59572 Bug ID: 59572 Summary: Not clear error message in smallest_mode_for_size in handled case Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: christophe.curis at free dot fr Hello, I have received this Internal Compiler error: :0:0: internal compiler error: in smallest_mode_for_size, at stor-layout.c:384 0x82ea77 smallest_mode_for_size ../../../src/gcc-4.8.2/gcc/stor-layout.c:384 0x831d94 smallest_mode_for_size ../../../src/gcc-4.8.2/gcc/stor-layout.c:495 0x831d94 layout_type(tree_node*) ../../../src/gcc-4.8.2/gcc/stor-layout.c:2081 0x8320b0 make_signed_type(int) ../../../src/gcc-4.8.2/gcc/stor-layout.c:2393 0x4da44d type_for_size ../../../src/gcc-4.8.2/gcc/vhdl/ortho-lang.c:649 0x4da4a6 type_for_mode ../../../src/gcc-4.8.2/gcc/vhdl/ortho-lang.c:669 0x9a5a14 build_common_builtin_nodes() ../../../src/gcc-4.8.2/gcc/tree.c:9795 0x4d9caa ortho_init ../../../src/gcc-4.8.2/gcc/vhdl/ortho-lang.c:328 0x4e67a6 lang_dependent_init ../../../src/gcc-4.8.2/gcc/toplev.c:1688 0x4e67a6 do_compile ../../../src/gcc-4.8.2/gcc/toplev.c:1850 I am trying to build gcc with VHDL support from GHDL: http://sourceforge.net/projects/ghdl-updates/ This work quite well, except that in current case I am trying to build a cross-compiler (--target=m68k-linux-gnu). All compilation flow works well until this step: make -C vhdl [...] ghdllib ../ghdl1 --std=87 -quiet -o std_standard.s --compile-standard My current supposition is that while compiling the standards for VHDL languages, it encouters a type that is not supported by the current arch I am targetting (maybe a 64-bits word, or a floating point type), so if gcc's smallest_mode_for_size function was able to provide a little bit of info on the type it was being called for, it would help to investigate how to provide a solution for it. Regards, Christophe.
[Bug fortran/58787] ICE (error recovery) in check_proc_interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58787 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-21 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Confirmed at r206155.
[Bug debug/54793] the location of a formal_parameter is not started from a function entry with -mfentry
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54793 Jakub Jelinek changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #8 from Jakub Jelinek --- Fixed for 4.8+.
[Bug fortran/58787] ICE (error recovery) in check_proc_interface
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58787 --- Comment #2 from Dominique d'Humieres --- Backtrace (patched tree): Program received signal SIGSEGV, Segmentation fault. gfc_resolve_expr (e=0x141e1f7a0) at ../../work/gcc/fortran/resolve.c:2827 2827 if (sym && sym->attr.intrinsic (gdb) bt #0 gfc_resolve_expr (e=0x141e1f7a0) at ../../work/gcc/fortran/resolve.c:2827 #1 0x000100088519 in resolve_index_expr (e=) at ../../work/gcc/fortran/resolve.c:10223 #2 0x000100088595 in resolve_charlen (cl=) at ../../work/gcc/fortran/resolve.c:10268 #3 0x000100093efa in resolve_types (ns=) at ../../work/gcc/fortran/resolve.c:10244 #4 0x00010008f9eb in gfc_resolve (ns=) at ../../work/gcc/fortran/resolve.c:14670 #5 0x000100079deb in gfc_parse_file () at ../../work/gcc/fortran/parse.c:4469 #6 0x0001000bc7f6 in gfc_be_parse_file () at ../../work/gcc/fortran/f95-lang.c:188 #7 0x00010084c924 in compile_file () at ../../work/gcc/toplev.c:547 #8 0x00010084ebe9 in toplev_main (argc=2, argv=0x7fff5fbff4d0) at ../../work/gcc/toplev.c:1887 (gdb) p e->symtree->n.sym $5 = (gfc_symbol *) 0x2141e201e0 (gdb) p *e->symtree->n.sym Cannot access memory at address 0x2141e201e0
[Bug fortran/58861] Realloc on assignment: Bogus "Array bound mismatch" error with -fcheck=bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58861 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-21 Ever confirmed|0 |1 --- Comment #2 from Dominique d'Humieres --- Still present at r206155.
[Bug fortran/58200] Option fcheck is misleadingly located in option descriptions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58200 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-21 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- No strong opinion, but I agree with 2.5.
[Bug fortran/58171] [F03] Incorrect error message on invalid code when using type constructor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58171 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-21 Ever confirmed|0 |1 --- Comment #3 from Dominique d'Humieres --- Confirmed at r206155.
[Bug tree-optimization/59303] [4.9 Regression] uninit-pred-8_b.c and uninit-pred-9_b.c fail after better optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303 --- Comment #10 from davidxl at google dot com --- My patch does this. 1) it first does aggressive simplification iteratively (more rules can be added later). 2) it then does normalization by building up larger predicate trees by following ud chain and bitwise or/and operations. It handles simple PHIs including also degenerated phis. The new dump reports: in foo, predicate for def: m_7(D) > 100 (.OR.) n_5(D) <= 9 (.OR.) l_12(D) != 0 (.OR.) r_10(D) <= 19 use1: m_7(D) > 100 (.OR.) n_5(D) <= 9 (.OR.) r_10(D) <= 9 use2: m_7(D) > 100 (.OR.) n_5(D) <= 9 (.OR.) r_10(D) <= 19 For foo2, the predicates are properly built, but the patch has a bug in predicate set inclusion testing leading to a false negative. David (In reply to Jakub Jelinek from comment #9) > Created attachment 31496 [details] > cleanups > > I had also a brief look at this recently, but haven't made progress beyond > attached formatting/cleanup patch so far (plus only dumping details with > *-details, otherwise the dumps are pretty much inconsistent). > My conclusion has also been that to fix this up the predicates would need to > be normalized before comparison, and simplified, at least if the initial > subset check fails. On uninit-pred-8_b.c there has been additional > complication because PRE decides to change the IL and we end up with: > : > pretmp_24 = r_10(D) <= 19; > goto ; > > : > _11 = r_10(D) <= 19; > _13 = l_12(D) != 0; > _14 = _11 | _13; > if (_14 != 0) > goto ; > else > goto ; > > : > goto ; > > : > > : > # v_1 = PHI > # prephitmp_30 = PHI <0(15), pretmp_24(3)> > if (m_7(D) != 0) > goto ; > else > goto ; > > : > g.0_17 = g; > g.1_18 = g.0_17 + 1; > g = g.1_18; > goto ; > > : > bar (); > > : > _3 = prephitmp_30 | _9; > if (_3 != 0) > so the prephitmp_30 would need to be canonicalized into _14 != 0 && r_10(D) > <= 19 aka (r_10(D) <= 19 || l_12(D) != 0) && r_10(D) <= 19 and from there to > r_10(D) <= 19.
[Bug middle-end/59569] [4.9 Regression] r206148 causes internal compiler error: in vect_create_destination_var, at tree-vect-data-refs.c:4294
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59569
Zhendong Su changed:
What|Removed |Added
CC||su at cs dot ucdavis.edu
--- Comment #4 from Zhendong Su ---
(In reply to Jakub Jelinek from comment #3)
> Reduced testcase:
> extern char c;
>
> void
> foo (int i, char **j)
> {
> while (i)
> j[--i] = &c;
> }
Below is a very similar testcase that I've encountered:
void foo (int *a, int b)
{
for (; b; b--)
a[b] = 1;
}
[Bug other/44482] some warnings in libgcc amd64-darwin 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44482 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from Dominique d'Humieres --- I see the soft-fl warning for the 4.8 branch (r206161), but not for the trunk (r206155). The "warning: no previous prototype for ..." are still there for both branches. Since this PR is more than three years old without feedback, I prefer to close as fixed (true for the soft-fl part) and open new ones for the different components generating warnings.
[Bug sanitizer/59369] c-c++-common/asan/pr59063-[1,2].c fails on darwin
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59369 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #6 from Dominique d'Humieres --- Silenced by r205699. Closing as fixed even if I am not supporting the linux only policy!-(
[Bug target/38183] Useless move to memory when passing small structs to functions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38183 Dominique d'Humieres changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #4 from Dominique d'Humieres --- > Works on Linux/x86-64 with GCC 4.8. Hence closing as fixed.
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 Bud Davis changed: What|Removed |Added CC||bdavis at gcc dot gnu.org --- Comment #2 from Bud Davis --- Is the reduced test case valid code ? Should it compile cleanly or should it provide a warning or error ?
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #3 from Dominique d'Humieres --- With the test in comment 1, I get on x86_64-apple-darwin13: TYPE(atomic_kind_type), pointer :: atomic_kind 1 Error: Derived type 'atomic_kind_type' at (1) is being used before it is defined ,:0: Included at _gfortran_dot_product:4096: Included at __convert_h1_i16:4096: Included at __builtin_frexpf:4096: Included at __atomic_fetch_and_16:4096: Included at __builtin_ia32_packssdw:4096: Included at __builtin_ia32_cvtsi2sd:4096: Included at __builtin_ia32_monitor:4096: Included at :4096: \U42C27000\x01/ f951: internal compiler error: Segmentation fault: 11 f951: internal compiler error: Abort trap: 6 gfc: internal compiler error: Abort trap: 6 (program f951) Abort
[Bug fortran/59016] f951: internal compiler error: Segmentation fault
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59016 --- Comment #4 from Dominique d'Humieres --- Backtrace is Program received signal SIGSEGV, Segmentation fault. error_print(const char *, const char *, typedef __va_list_tag __va_list_tag *) (type=, format0=, argp=) at ../../work/gcc/fortran/error.c:173 173 while (*p) (gdb) bt #0 error_print(const char *, const char *, typedef __va_list_tag __va_list_tag *) (type=, format0=, argp=) at ../../work/gcc/fortran/error.c:173 #1 0x00010002fa4e in gfc_error (gmsgid=) at ../../work/gcc/fortran/error.c:1003 #2 0x00010003827c in check_interface0 (p=0x141f05ad0, interface_name=0x7fff5fbff060 "generic interface 'atomic_kind_type'") at ../../work/gcc/fortran/interface.c:1568 #3 0x00010003b243 in check_sym_interfaces (sym=0x25) at ../../work/gcc/fortran/interface.c:1680 #4 0x0001000a98dc in do_traverse_symtree (st=, st_func=, sym_func=) at ../../work/gcc/fortran/symbol.c:3575 #5 0x00010003c01c in gfc_check_interfaces (ns=0x143020c00) at ../../work/gcc/fortran/interface.c:1790 #6 0x000100094071 in resolve_types (ns=) at ../../work/gcc/fortran/resolve.c:14589 #7 0x00010008f9eb in gfc_resolve (ns=) at ../../work/gcc/fortran/resolve.c:14670 #8 0x00010007a0a1 in gfc_parse_file () at ../../work/gcc/fortran/parse.c:4672 #9 0x0001000bc7f6 in gfc_be_parse_file () at ../../work/gcc/fortran/f95-lang.c:188 #10 0x00010084c924 in compile_file () at ../../work/gcc/toplev.c:547 #11 0x00010084ebe9 in toplev_main (argc=2, argv=0x7fff5fbff4d0) at ../../work/gcc/toplev.c:1887
[Bug tree-optimization/59303] [4.9 Regression] uninit-pred-8_b.c and uninit-pred-9_b.c fail after better optimizations
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59303 --- Comment #11 from davidxl at google dot com --- The false negative bug introduced in the patch is fixed. Will submit the patch for review soon. (In reply to davidxl from comment #10) > My patch does this. > 1) it first does aggressive simplification iteratively (more rules can be > added later). > 2) it then does normalization by building up larger predicate trees by > following ud chain and bitwise or/and operations. It handles simple PHIs > including also degenerated phis. > > The new dump reports: > > in foo, > > predicate for def: > > m_7(D) > 100 > (.OR.) > n_5(D) <= 9 > (.OR.) > l_12(D) != 0 > (.OR.) > r_10(D) <= 19 > > use1: > > m_7(D) > 100 > (.OR.) > n_5(D) <= 9 > (.OR.) > r_10(D) <= 9 > > use2: > > m_7(D) > 100 > (.OR.) > n_5(D) <= 9 > (.OR.) > r_10(D) <= 19 > > > For foo2, the predicates are properly built, but the patch has a bug in > predicate set inclusion testing leading to a false negative. > > David > > (In reply to Jakub Jelinek from comment #9) > > Created attachment 31496 [details] > > cleanups > > > > I had also a brief look at this recently, but haven't made progress beyond > > attached formatting/cleanup patch so far (plus only dumping details with > > *-details, otherwise the dumps are pretty much inconsistent). > > My conclusion has also been that to fix this up the predicates would need to > > be normalized before comparison, and simplified, at least if the initial > > subset check fails. On uninit-pred-8_b.c there has been additional > > complication because PRE decides to change the IL and we end up with: > > : > > pretmp_24 = r_10(D) <= 19; > > goto ; > > > > : > > _11 = r_10(D) <= 19; > > _13 = l_12(D) != 0; > > _14 = _11 | _13; > > if (_14 != 0) > > goto ; > > else > > goto ; > > > > : > > goto ; > > > > : > > > > : > > # v_1 = PHI > > # prephitmp_30 = PHI <0(15), pretmp_24(3)> > > if (m_7(D) != 0) > > goto ; > > else > > goto ; > > > > : > > g.0_17 = g; > > g.1_18 = g.0_17 + 1; > > g = g.1_18; > > goto ; > > > > : > > bar (); > > > > : > > _3 = prephitmp_30 | _9; > > if (_3 != 0) > > so the prephitmp_30 would need to be canonicalized into _14 != 0 && r_10(D) > > <= 19 aka (r_10(D) <= 19 || l_12(D) != 0) && r_10(D) <= 19 and from there to > > r_10(D) <= 19.
[Bug c/47901] -Wall should not imply -Wformat-zero-length by default
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47901 Samuel Bronson changed: What|Removed |Added CC||naesten at gmail dot com --- Comment #9 from Samuel Bronson --- Wouldn't the case where a given custom printf-like function does more than just print the formatted text be better solved by adding a new __attribute__ to disable this warning for such a function? (Assuming anyone actually wants these warnings ever ...) Then, you could still have warnings for code like 'printf();' that does nothing, while avoiding them for your 'custom_printf(foo, "");' that does do something.
[Bug fortran/59069] Bogus error wording for passing array to scalar dummies with user-defined operator
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59069 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-21 Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres --- Indeed the error does not help to replace 'pure' with 'elemental'. Confirmed at r206155.
[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2013-12-21 Ever confirmed|0 |1
[Bug fortran/34928] Extension: volatile common blocks
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34928 --- Comment #9 from Bud Davis --- I completely support closing this PR with a note in the documentation. On shared memory mini computers of a bygone era, it was common to map the common blocks to a specific memory address, and then more than one program (in more than one cpu) could access them. You used the volatile keyword to ensure the writes happened to memory, and didn't stay in the register set of a cpu. I also wouldn't be surprised if I/O devices (think VME) were mapped to a fortan common block name, and thus also required volatile. Both concepts are long gone, but the code still lives. A note in the documentation is all it needs. --bud p.s. This explanation may be wrong. It was a long time ago. !!
[Bug fortran/58842] libgfortran configuration error in 32-bit mode for GCC 4.8 with MacPorts "universal installation"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58842 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |WORKSFORME --- Comment #2 from Dominique d'Humieres --- No feedback. Closing as WORKSFORME.
[Bug fortran/43849] Add _gfortran_finalize function to close down the library
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43849 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2013-12-21 Ever confirmed|0 |1 --- Comment #4 from Dominique d'Humieres --- Is this PR still pertinent (2013-12-21)?
[Bug fortran/55574] [4.7/4.8 Regression] C binding access to c_ptr type
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55574 --- Comment #8 from Mikael Morin --- (In reply to Paul Thomas from comment #7) > Tell me, why was your patch never applied? You answered that question at the next line. ;-) > As far as I can see, nobody even > reviewed it - is that right? > I believe so. This bug ceased to matter much after it was fixed on mainline.
[Bug target/49226] problematic _Complex long double argument passing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49226
Eric Botcazou changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|ebotcazou at gcc dot gnu.org |unassigned at gcc dot
gnu.org
--- Comment #4 from Eric Botcazou ---
+FAIL: gcc.dg/compat/scalar-by-value-3 c_compat_x_tst.o compile
+FAIL: gcc.dg/compat/scalar-by-value-3 c_compat_x_tst.o-c_compat_y_tst.o
execute
+FAIL: gcc.dg/compat/scalar-by-value-6 c_compat_x_tst.o compile
+FAIL: gcc.dg/compat/scalar-by-value-6 c_compat_x_tst.o-c_compat_y_tst.o
execute
+FAIL: gcc.dg/compat/scalar-return-3 c_compat_x_tst.o compile
+FAIL: gcc.dg/compat/scalar-return-3 c_compat_x_tst.o-c_compat_y_tst.o execute
+FAIL: gcc.dg/compat/struct-by-value-18 c_compat_x_tst.o compile
+FAIL: gcc.dg/compat/struct-by-value-18 c_compat_x_tst.o-c_compat_y_tst.o
execute
(botcazou@saco) /nile.build/botcazou/gcc-head/ia64-linux-gnu $ cat
asm_warning.c
_Complex long double g01cld, g02cld;
extern void testvacld (int n, ...);
void testitcld (void)
{
testvacld (2, g01cld, g02cld);
}
(botcazou@saco) /nile.build/botcazou/gcc-head/ia64-linux-gnu $ gcc/xgcc -Bgcc
-c asm_warning.c -save-temps
asm_warning.s: Assembler messages:
asm_warning.s:103: Warning: Invalid use of `f0' as output operand
asm_warning.s:106: Warning: Invalid use of `f1' as output operand
asm_warning.s:134: Warning: Invalid use of `f0' as output operand
asm_warning.s:136: Warning: Invalid use of `f1' as output operand
[Bug bootstrap/50342] gcc/configure fails on Mac OS X Lion/Xcode 4.1 with recent GCCs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50342 Dominique d'Humieres changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #16 from Dominique d'Humieres --- (In reply to comment #15) > > The original problem doesn't occur with gcc version 4.8.0 20130131 > > (experimental) [trunk revision 195611] (GCC), built with GNAT GPL 2012. > > Probably fixed at http://gcc.gnu.org/viewcvs?view=revision&revision=182378. Working link http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=182378. So closing as FIXED.
[Bug target/47608] libstdc++ links to bad libgcc_s on OS X (libgcc_s rebuilt needlessly and incorrectly)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47608 Dominique d'Humieres changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #2 from Dominique d'Humieres --- We are now at darwin13 and gcc 4.8.2. AFAICT this has been fixed: /opt/gcc/gcc4.8c/lib/libstdc++.dylib: /opt/gcc/gcc4.8c/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.19.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1197.1.1) /opt/gcc/gcc4.8c/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) Same thing for 4.7 and trunk (4.9). Closing as FIXED. If you still have a problem with a supported version (4.7 or 4.8), please open a new PR.
[Bug target/52795] FAIL: gcc.dg/tree-prof/pr34999.c compilation, -fprofile-use -D_PROFILE_USE on {x86_64,i386}-apple-darwin{10,11} at -m64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52795
Dominique d'Humieres changed:
What|Removed |Added
Target|{x86_64,i386}-apple-darwin{ |{x86_64,i386}-apple-darwin1
|10,11) |*
Host|{x86_64,i386}-apple-darwin{ |{x86_64,i386}-apple-darwin1
|10,11) |*
Build|{x86_64,i386}-apple-darwin{ |{x86_64,i386}-apple-darwin1
|10,11) |*
--- Comment #3 from Dominique d'Humieres ---
Also seen with x86_64-apple-darwin13.
[Bug libstdc++/59531] string_view overrun in copy operation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59531 --- Comment #1 from Ed Smith-Rowland <3dw4rd at verizon dot net> --- Also, we should throw when pos > size() rather than pos >= size(). Spinning new patches and testing.
[Bug target/59573] New: aarch64: commit 07ca5686e64 broken glibc-2.17
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59573
Bug ID: 59573
Summary: aarch64: commit 07ca5686e64 broken glibc-2.17
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: dennis.yxun at gmail dot com
Created attachment 31498
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31498&action=edit
glibc build error
I'm using qemu-aarch64[1], and trying to build rootfs with gcc-4.9.0,
glibc-2.17, binutils-2.24.51.0.1
following commit[2] result in un-usable glibc (2.17), I haven't trace to the
root cause, but detail error can be seen in "glibc.error"[4]
btw, I'm using "git bisect" to find this commit[2]. and also tested passed with
latest commit[3], but with this commit[2] reverted.
[1] git://github.com/susematz/qemu.git, branch aarch64-1.6
[2] gcc offended commit:
commit 07ca5686e64d32f7df4ccf4205d0b914f120da5e
Author: yroux
Date: Thu Sep 26 09:09:30 2013 +
2013-09-26 Yvan Roux
* config/aarch64/aarch64.opt (mlra): New option.
* config/aarch64/aarch64.c (aarch64_lra_p): New function.
(TARGET_LRA_P): Define.
git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@202940
138bc75d-0d04-0410-961f-82ee72b054a4
[3] gcc commit: 33c503bd9001b6fe823aa9be319a09df500a6b40
[4] glibc build error, a) trigger unknown insns b) result int ld-*.so
un-usable. this two error won't happen with the commit[2] reverted
/var/tmp/portage/sys-libs/glibc-2.17/work/build-default-aarch64-unknown-linux-gnu-nptl/elf/sln
/var/tmp/portage/sys-libs/glibc-2.17/work/build-default-aarch64-unknown-linux-gnu-nptl/elf/symlink.list
rm -f
/var/tmp/portage/sys-libs/glibc-2.17/work/build-default-aarch64-unknown-linux-gnu-nptl/elf/symlink.list
make[1]: Leaving directory
'/var/tmp/portage/sys-libs/glibc-2.17/work/glibc-2.17'
* Defaulting /etc/host.conf:multi to on
unallocated encoding at line: 3465
Unknown instruction: 0x5ee09800
qemu: uncaught target signal 4 (Illegal instruction) - core dumped
/usr/portage/sys-libs/glibc/files/eblits/pkg_preinst.eblit: line 21: 28605
Illegal instruction (core dumped) ./ld-*.so --library-path . ${x} >
/dev/null
* ERROR: sys-libs/glibc-2.17::gentoo failed (preinst phase):
* simple run test (/bin/date) failed
*
* Call stack:
* ebuild.sh, line 93: Called pkg_preinst
* environment, line 3108: Called eblit-run 'pkg_preinst'
* environment, line 944: Called eblit-glibc-pkg_preinst
* pkg_preinst.eblit, line 48: Called glibc_sanity_check
* pkg_preinst.eblit, line 27: Called die
* The specific snippet of code:
* ./ld-*.so --library-path . ${x} > /dev/null \
* || die "simple run test (${x}) failed"
*
[Bug c++/59574] New: Bad -Wattributes: ignoring attributes applied after definition
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59574 Bug ID: 59574 Summary: Bad -Wattributes: ignoring attributes applied after definition Product: gcc Version: 4.8.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ Assignee: unassigned at gcc dot gnu.org Reporter: jed at 59A2 dot org Created attachment 31499 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31499&action=edit Test case. Works with gcc if renamed to "unused.c" g++ misinterprets the attribute tag in Type x,__attribute((unused)) y; when Type is a struct or union. gcc interprets this correctly (rename to "unused.c", as does clang++. unused.cc: In function ‘MyInt bad_Wattributes()’: unused.cc:11:40: warning: ignoring attributes applied to ‘MyInt’ after definition [-Wattributes] struct MyInt x,__attribute((unused)) y; ^ Verbose output below: $ g++ -v -save-temps -c -Wall -Wextra unused.cc Using built-in specs. COLLECT_GCC=g++ Target: x86_64-unknown-linux-gnu Configured with: /build/gcc-multilib/src/gcc-4.8.2/configure --prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/ --enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared --enable-threads=posix --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object --enable-linker-build-id --enable-cloog-backend=isl --disable-cloog-version-check --enable-lto --enable-plugin --enable-install-libiberty --with-linker-hash-style=gnu --enable-multilib --disable-werror --enable-checking=release Thread model: posix gcc version 4.8.2 (GCC) COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-Wall' '-Wextra' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/cc1plus -E -quiet -v -D_GNU_SOURCE unused.cc -mtune=generic -march=x86-64 -Wall -Wextra -fpch-preprocess -o unused.ii ignoring nonexistent directory "/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../x86_64-unknown-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../include/c++/4.8.2 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../include/c++/4.8.2/x86_64-unknown-linux-gnu /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../include/c++/4.8.2/backward /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/include /usr/local/include /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/include-fixed /usr/include End of search list. COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-Wall' '-Wextra' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/cc1plus -fpreprocessed unused.ii -quiet -dumpbase unused.cc -mtune=generic -march=x86-64 -auxbase unused -Wall -Wextra -version -o unused.s GNU C++ (GCC) version 4.8.2 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2-p5, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 GNU C++ (GCC) version 4.8.2 (x86_64-unknown-linux-gnu) compiled by GNU C version 4.8.2, GMP version 5.1.3, MPFR version 3.1.2-p5, MPC version 1.0.1 GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072 Compiler executable checksum: ab71b98845e83cf5a6c15196f260f6ae unused.cc: In function ‘MyInt bad_Wattributes()’: unused.cc:11:40: warning: ignoring attributes applied to ‘MyInt’ after definition [-Wattributes] struct MyInt x,__attribute((unused)) y; ^ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-Wall' '-Wextra' '-shared-libgcc' '-mtune=generic' '-march=x86-64' as -v --64 -o unused.o unused.s GNU assembler version 2.24 (x86_64-unknown-linux-gnu) using BFD version (GNU Binutils) 2.24 COMPILER_PATH=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/ LIBRARY_PATH=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../:/lib/:/usr/lib/ COLLECT_GCC_OPTIONS='-v' '-save-temps' '-c' '-Wall' '-Wextra' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
[Bug debug/59575] New: ICE in maybe_record_trace_start, at dwarf2cfi.c:2239
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59575
Bug ID: 59575
Summary: ICE in maybe_record_trace_start, at dwarf2cfi.c:2239
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
Assignee: unassigned at gcc dot gnu.org
Reporter: rmansfield at qnx dot com
Target: arm-unknown-linux-gnueabi
~/gnu/gcc/trunk/arm-eabi/gcc$ cat ~/ice.i
void
test (int *p)
{
int i;
long long j;
if (p)
{
foo (p);
}
else
{
if (p = (int *)bar (i, j, 0x1))
{
foo (p);
}
}
}
~/gnu/gcc/trunk/arm-eabi/gcc$ ./xgcc -B. ~/ice.i -Os -g -march=armv7-a -c
/home/ryan/ice.i: In function 'test':
/home/ryan/ice.i:17:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2239
}
^
0x6848bf maybe_record_trace_start
../../gcc/dwarf2cfi.c:2239
0x684f7e scan_trace
../../gcc/dwarf2cfi.c:2416
0x6857fe create_cfi_notes
../../gcc/dwarf2cfi.c:2570
0x6857fe execute_dwarf2_frame
../../gcc/dwarf2cfi.c:2925
0x6857fe execute
../../gcc/dwarf2cfi.c:3421
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See for instructions.
~/gnu/gcc/trunk/arm-eabi/gcc$ ./xgcc -v
Using built-in specs.
COLLECT_GCC=./xgcc
Target: arm-unknown-linux-gnueabi
Configured with: ../configure --target=arm-unknown-linux-gnueabi
--prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi
--with-sysroot=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi//sys-root
--disable-multilib
--with-local-prefix=/home/ryan/x-tools/arm-unknown-linux-gnueabi/arm-unknown-linux-gnueabi/sys-root
--disable-nls --enable-threads=posix --enable-symvers=gnu --enable-c99
--enable-long-long --enable-target-optspace
target_alias=arm-unknown-linux-gnueabi --enable-languages=c++ --disable-shared
--disable-libmudflap --disable-libssp --enable-checking
Thread model: posix
gcc version 4.9.0 20131222 (experimental) [trunk revision 206165] (GCC)
Started failing at rev204698
[Bug target/59576] New: "sorry, unimplemented: making multiple clones" error on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59576 Bug ID: 59576 Summary: "sorry, unimplemented: making multiple clones" error on *-apple-darwin* Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: dominiq at lps dot ens.fr CC: howarth at bromo dot med.uc.edu, iains at gcc dot gnu.org, jakub at gcc dot gnu.org Host: *-apple-darwin* Target: *-apple-darwin* Build: *-apple-darwin* The tests g++.dg/tree-prof/pr59255.C (new in r206152) and libgomp.c++/simd-1.C (new in r203408) fail on *-apple-darwin* with ... sorry, unimplemented: making multiple clones ... Is dg-skip on darwin the right fix?
