[Bug c++/6273] [DR 502] Dependency of nested enumerations and enumerators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6273 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||paolo.carlini at oracle dot com --- Comment #16 from Paolo Carlini paolo.carlini at oracle dot com --- Jason, I'm having a look to this, and I'm not sure there is still something to do. For example, our type_dependent_type_p returns true for the snippet in 1) of Core/502. As regards the reduced testcase in Comment #2 here, we still reject it, as does clang too, but we accept (as does clang) it if we change operator+ to be constexpr.
[Bug libstdc++/61143] [4.9/4.10 Regression] Arithmetic exception on emplacing into unordered_map moved out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61143 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org --- (In reply to François Dumont from comment #4) I simply considered that the moved container instance wouldn't be reused this way, just potentially for some immutable operations. I should have checked the Standard regarding the meaning of valid by unspecified state. Objects can definitely be re-used after being moved from. This has to work. There are indeed numerous places to consider to make this code and any other mutable code valid. I would also prefer to avoid those checks but I remember that I needed to leave the container in this state for exception guaranty reasons in some move operations. I will recall rational of this as soon as I can take a look to the code. We wanted the move constructor to be noexcept. That's important, but so is being able to reuse the object again.
[Bug c++/6273] [DR 502] Dependency of nested enumerations and enumerators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6273 --- Comment #17 from Paolo Carlini paolo.carlini at oracle dot com --- ... of course I meant that dependent_type_p returns true for enum E therein.
[Bug libstdc++/61143] [4.9/4.10 Regression] Arithmetic exception on emplacing into unordered_map moved out
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61143 --- Comment #6 from Marc Glisse glisse at gcc dot gnu.org --- There was that whole discussion on how much sense it makes to make move constructors noexcept when default constructors aren't...
[Bug libgcc/61152] New: Missing GCC Runtime Library Exception in some files that are included in libgcc
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61152 Bug ID: 61152 Summary: Missing GCC Runtime Library Exception in some files that are included in libgcc Product: gcc Version: unknown Status: UNCONFIRMED Severity: trivial Priority: P3 Component: libgcc Assignee: unassigned at gcc dot gnu.org Reporter: gjl at gcc dot gnu.org libgcc sources are not yet separated completey from the compiler, i.e. it includes tm.h which in turn will include files from the compiler backend like arm.h. As such files go into libgcc, they should contain the GCC Runtime Library Exception (RLE) in their license headers. I know that these files actually don't add executable code to libgcc and that the FSF is fine without RLE in these files, yet there are potential users of GCC that are very concerned about linking their code against libgcc and about the non-RLE files that are part of the libgcc sources: as soon as a single file that goes into libgcc (e.g. by include) is GPL but does not contain the RLE, they won't use GCC as a whole. Thus, adding RLE to these files can greatly increase acceptance of GCC/libgcc.
[Bug rtl-optimization/61058] [4.7/4.8/4.9/4.10 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreach
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61058
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek jakub at gcc dot gnu.org ---
I think the buggy pass here is:
static unsigned int
cleanup_barriers (void)
{
rtx insn, next, prev;
for (insn = get_insns (); insn; insn = next)
{
next = NEXT_INSN (insn);
if (BARRIER_P (insn))
{
prev = prev_nonnote_insn (insn);
if (!prev)
continue;
if (BARRIER_P (prev))
delete_insn (insn);
else if (prev != PREV_INSN (insn))
reorder_insns_nobb (insn, insn, prev);
}
}
return 0;
}
At the start of that pass we have:
(note 3 1 9 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn/f 9 3 10 2 (set (mem:DI (pre_dec:DI (reg/f:DI 7 sp)) [0 S8 A8])
(reg/f:DI 6 bp)) pr61058.c:3 -1
(nil))
(insn/f 10 9 11 2 (set (reg/f:DI 6 bp)
(reg/f:DI 7 sp)) pr61058.c:3 -1
(nil))
(note 11 10 2 2 NOTE_INSN_PROLOGUE_END)
(note 2 11 5 2 NOTE_INSN_FUNCTION_BEG)
(barrier 5 2 8)
(note 8 5 0 NOTE_INSN_DELETED)
where BB_HEAD (bb2) is note 3 and BB_END (bb2) is note 2, note 8 has been added
by LRA (but reload does that too AFAIK), both barrier and note are outside of
the bb 2.
Now, the above reorders the barrier after insn 10, making it part of bb2
because BB_END (bb2) isn't adjusted.
So, either cleanup_barriers should not move anything here (e.g. because prev
doesn't satisfy control_flow_insn_p (prev)), and/or, of it decides to move
something, it has to take care of adjusting the affected basic blocks (but how?
Would we keep the two notes (11 and 2) without basic block).
Do we need the cleanup_barriers pass at all these days?
[Bug target/60617] [4.8 Regression] unable to find a register to spill in class 'LO_REGS'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60617 --- Comment #3 from Venkataramanan venkataramanan.kumar at amd dot com --- The bug is now hidden in trunk by revision 209897 The patch Remove PUSH_ARGS_REVERSED from the RTL expander (reference below) seems to change the way arguments are handled in RTL. Ref: http://gcc.gnu.org/git/?p=gcc.git;a=commit;h=bf29c577b9128551d76adc5b0331d375be49d7d3
[Bug rtl-optimization/61058] [4.7/4.8/4.9/4.10 Regression] ICE: RTL check: expected elt 3 type 'B', have '0' (rtx barrier) in distance_agu_use_in_bb, at config/i386/i386.c:16740 with __builtin_unreach
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61058 --- Comment #7 from Jakub Jelinek jakub at gcc dot gnu.org --- On the other side, pass_cleanup_barriers is performed after pass_free_cfg, so making it unconditionally cfg-aware is not going to work, it is just that i386 (as well as few other targets) calls compute_bb_for_insn in its mach_reorg pass and doesn't free_bb_for_insn afterwards. So perhaps do nothing if BLOCK_FOR_INSN (prev), or call reorder_insns instead of reorder_insns_nobb if BLOCK_FOR_INSN (prev)? Though, calling reorder_insns there doesn't seem to work either, it isn't prepared to handle the case of moving a BARRIER into the middle of some bb.
[Bug target/60617] [4.8 Regression] unable to find a register to spill in class 'LO_REGS'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60617
--- Comment #4 from Venkataramanan venkataramanan.kumar at amd dot com ---
Reverting this patch in 209897 bug still occurs in trunk with -mno-lra.
SPILL failure occurs for regno 110 (dst operand) in below instruction
(insn 634 633 635 27 (parallel [
(set (reg:SI 3 r3)
(ior:SI (eq:SI (reg/v:SI 110 [ dst ]) == This operand r5 is
registers gets assigned
(reg/v:SI 112 [ op2 ]))
(eq:SI (reg/v:SI 110 [ dst ]) == This operand
(reg/v:SI 111 [ op1 ]
(clobber (reg:CC 100 cc))
]) ../Source/JavaScriptCore/jit/JITArithmetic32_64.cpp:179 300
{*ior_scc_scc
First observation is that reload is not able to reuse r5 that was used in
second reload in operation for the same register id 110 dst
The IRA Dump shows.
(insn 632 631 633 27 (set (reg:SI 1 r1)
(reg/v:SI 110 [ dst ]))
../Source/JavaScriptCore/jit/JITArithmetic32_64.cpp:179 667 {*thumb2_movsi_vfp}
(nil))
(insn 633 632 634 27 (set (reg:SI 2 r2)
(const_int 0 [0]))
../Source/JavaScriptCore/jit/JITArithmetic32_64.cpp:179 667 {*thumb2_movsi_vfp}
(nil))
(insn 634 633 635 27 (parallel [
(set (reg:SI 3 r3)
(ior:SI (eq:SI (reg/v:SI 110 [ dst ])
(reg/v:SI 112 [ op2 ]))
(eq:SI (reg/v:SI 110 [ dst ])
(reg/v:SI 111 [ op1 ]
(clobber (reg:CC 100 cc))
]) ../Source/JavaScriptCore/jit/JITArithmetic32_64.cpp:179 300
{*ior_scc_scc}
The register operand 110 dst is already passed as argument 1 and hence gets
register r1. See insn 632.
But this is not reused by insn 634.
However there are some other places in IRA dump where the same expression
occurs and there register r1 is used. Here operand dst 110 is marked as dead.
(insn 431 430 433 24 (set (reg:SI 1 r1)
(reg/v:SI 110 [ dst ]))
../Source/JavaScriptCore/jit/JITArithmetic32_64.cpp:388 667 {*thumb2_movsi_vfp}
(expr_list:REG_DEAD (reg/v:SI 110 [ dst ])
(nil)))
(insn 433 431 432 24 (parallel [
(set (reg:SI 3 r3)
(ior:SI (eq:SI (reg/v:SI 112 [ op ])
(reg:SI 1 r1))
(eq:SI (reg/v:SI 111 [ op ])
(reg:SI 1 r1
(clobber (reg:CC 100 cc))
]) ../Source/JavaScriptCore/jit/JITArithmetic32_64.cpp:388 300
{*ior_scc_scc
Still working on why IRA is not replacing the operand with R1 here, but
replaces in other places.
[Bug middle-end/61141] [4.10 Regression] c-common.c:1502:1: ICE: in reset_insn_used_flags, at emit-rtl.c:2677
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61141
--- Comment #2 from John David Anglin danglin at gcc dot gnu.org ---
In the Linux case, we also have a note in a NOTE_INSN_DELETED delayed
branch sequence:
(gdb) ignor 1 9396470
Will ignore next 9396470 crossings of breakpoint 1.
(gdb) r
Starting program: /home/dave/gnu/gcc/objdir/gcc/../prev-gcc/cc1plus
-fpreprocessed c-common.ii -quiet -dumpbase c-common.c -auxbase-strip
c-family/c-common.o -g -O2 -Wextra -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wsuggest-attribute=format -Woverloaded-virtual -Wpedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Werror -version
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -fno-common -o
c-common.s
GNU C++ (GCC) version 4.10.0 20140509 (experimental) [trunk revision 210292]
(hppa-linux-gnu)
compiled by GNU C version 4.9.0, GMP version 6.0.0, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
GNU C++ (GCC) version 4.10.0 20140509 (experimental) [trunk revision 210292]
(hppa-linux-gnu)
compiled by GNU C version 4.9.0, GMP version 6.0.0, MPFR version 3.1.2-p3,
MPC version 1.0.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 58ab86f8e667281199dd64bcf3941150
Breakpoint 1, reset_insn_used_flags (insn=0xf7abc190)
at ../../gcc/gcc/emit-rtl.c:2677
2677 gcc_assert (INSN_P (insn));
(gdb) p debug_rtx(insn)
(note 5678 5679 5680 NOTE_INSN_DELETED)
(gdb) p debug_rtx_list (insn, -7)
(insn:TI 5677 5676 12940 (set (reg:SI 25 %r25)
(reg/v/f:SI 6 %r6 [orig:914 expr ] [914])) ../../gcc/gcc/tree.h:3183 40
{*pa.md:2211}
(expr_list:REG_DEAD (reg/v/f:SI 6 %r6 [orig:914 expr ] [914])
(nil)))
(note 12940 5677 25145 (var_location in_init (entry_value:QI (reg:QI 25 %r25 [
in_init ]))) NOTE_INSN_VAR_LOCATION)
(insn 25145 12940 5680 (sequence [
(call_insn:TI 5679 12940 5678 (parallel [
(call (mem:SI (symbol_ref/v:SI
(@_Z25tree_operand_check_failediPK9tree_nodePKciS3_) [flags 0x241]
function_decl 0xfa55a500 tree_operand_check_failed) [0
tree_operand_check_failed S4 A32])
(const_int 24 [0x18]))
(clobber (reg:SI 1 %r1))
(clobber (reg:SI 2 %r2))
(use (const_int 0 [0]))
]) ../../gcc/gcc/tree.h:3183 195 {call_symref}
(expr_list:REG_DEAD (reg:SI 26 %r26)
(expr_list:REG_DEAD (reg:SI 25 %r25)
(expr_list:REG_DEAD (reg:SI 24 %r24)
(expr_list:REG_DEAD (reg:SI 23 %r23)
(expr_list:REG_NORETURN (const_int 0 [0])
(nil))
(expr_list:SI (use (reg:SI 26 %r26))
(expr_list:SI (use (reg:SI 25 %r25))
(expr_list:SI (use (reg:SI 24 %r24))
(expr_list:SI (use (reg:SI 23 %r23))
(expr_list:SI (use (mem/f:SI (plus:SI (reg/f:SI
30 %r30)
(const_int -52
[0xffcc])) [0 S4 A32]))
(nil)))
(note 5678 5679 5680 NOTE_INSN_DELETED)
]) ../../gcc/gcc/tree.h:3183 -1
(nil))
(barrier 5680 25145 12943)
(note 12943 5680 12942 (expr_list:REG_DEP_TRUE (concat:SI (reg:SI 26 %r26)
(const_int 1 [0x1]))
(expr_list:REG_DEP_TRUE (concat:SI (reg:SI 25 %r25)
(reg/v/f:SI 6 %r6 [orig:914 expr ] [914]))
(expr_list:REG_DEP_TRUE (concat:SI (reg:SI 24 %r24)
(symbol_ref/v/f:SI (*.LC0) [flags 0x202] var_decl 0xf845cd80
*.LC0))
(expr_list:REG_DEP_TRUE (concat:SI (reg:SI 23 %r23)
(const_int 1205 [0x4b5]))
(expr_list:REG_DEP_TRUE (concat:SI (mem/f:SI (plus:SI (reg/f:SI
30 %r30)
(const_int -52 [0xffcc])) [0 S4
A32])
(symbol_ref/v:SI
(_ZZL21c_fully_fold_internalP9tree_nodebPbS1_E12__FUNCTION__) [flags 0x202]
var_decl 0xfa3ea0c0 __FUNCTION__))
(nil)) NOTE_INSN_CALL_ARG_LOCATION)
(note/c 12942 12943 12941 (var_location kind (nil)) NOTE_INSN_VAR_LOCATION)
(note/c 12941 12942 12944 (var_location __c (nil)) NOTE_INSN_VAR_LOCATION)
$3 = void
[Bug middle-end/61141] [4.10 Regression] c-common.c:1502:1: ICE: in reset_insn_used_flags, at emit-rtl.c:2677
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61141
--- Comment #3 from John David Anglin danglin at gcc dot gnu.org ---
(gdb) p *pass
$4 = {pass_data = {type = RTL_PASS, name = 0x1afa7c0 final,
optinfo_flags = 0, has_execute = true, tv_id = TV_FINAL,
properties_required = 0, properties_provided = 0,
properties_destroyed = 0, todo_flags_start = 524288,
todo_flags_finish = 0},
_vptr.opt_pass = 0x1afa758 vtable for (anonymous namespace)::pass_final+8,
sub = 0x0, next = 0x0, static_pass_number = 251,
graph_dump_initialized = false, m_ctxt = 0x1ed64f8}
[Bug target/59904] [ARM] tls-reload-1.c fails
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59904 --- Comment #3 from christophe.lyon at st dot com --- Sorry I no longer have the elf file available. I've just looked at the current trunk status and I have a failure at link time for these tests: ld: gcc_tg.o: relocation R_ARM_MOVW_ABS_NC against `a local symbol' can not be used when making a shared object; recompile with -fPIC gcc_tg.o: error adding symbols: Bad value collect2: error: ld returned 1 exit status compiler exited with status 1 Not sure if it's a problem with the binutils I use (linaro-2.24-2013.12) or a known problem with the GCC test?
[Bug middle-end/61141] [4.10 Regression] c-common.c:1502:1: ICE: in reset_insn_used_flags, at emit-rtl.c:2677
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61141
--- Comment #4 from John David Anglin danglin at gcc dot gnu.org ---
(gdb) p *fn
$5 = {eh = 0xfa483f48, cfg = 0xf7f60a10, gimple_body = 0x0,
gimple_df = 0xf7ba6900, x_current_loops = 0x0, su = 0x0,
value_histograms = 0x0, decl = 0xf8f39100, static_chain_decl = 0x0,
nonlocal_goto_save_area = 0x0, local_decls = 0x0, cilk_frame_decl = 0x0,
machine = 0xfabd95f8, language = 0xf93de900, used_types_hash = 0xfaba0180,
fde = 0xf8b9ad38, last_stmt_uid = 3927, funcdef_no = 719,
function_start_locus = 6286828, function_end_locus = 6403815,
curr_properties = 5312, last_verified = 0, cannot_be_copied_reason = 0x0,
va_list_gpr_size = 255, va_list_fpr_size = 255, calls_setjmp = 0,
calls_alloca = 0, is_cilk_function = 0, calls_cilk_spawn = 0,
has_nonlocal_label = 0, cannot_be_copied_set = 1, stdarg = 0,
after_inlining = 1, always_inline_functions_inlined = 1,
can_throw_non_call_exceptions = 0, can_delete_dead_exceptions = 0,
returns_struct = 0, returns_pcc_struct = 0, has_local_explicit_reg_vars = 0,
is_thunk = 0, has_force_vectorize_loops = 0, has_simduid_loops = 0,
tail_call_marked = 0}
(gdb) p debug_tree (fn-decl)
function_decl 0xf8f39100 c_fully_fold_internal
type function_type 0xf8f3b600
type pointer_type 0xf9be9960 tree type union_type 0xf9be98a0
tree_node
sizes-gimplified asm_written public unsigned type_6 SI
size integer_cst 0xfad01570 constant 32
unit size integer_cst 0xfad01588 constant 4
align 32 symtab -104946992 alias set -1 canonical type 0xf9be9900
pointer_to_this pointer_type 0xfa4f62a0
SI size integer_cst 0xfad01570 32 unit size integer_cst 0xfad01588
4
align 32 symtab 0 alias set -1 canonical type 0xf8f3b660
arg-types tree_list 0xf8f38bb8 value pointer_type 0xf9be9960 tree
chain tree_list 0xf8f38bd0 value boolean_type 0xfad0a5a0 bool
chain tree_list 0xf8f38be8 value pointer_type 0xfaad38a0
chain tree_list 0xf8f38c00 value pointer_type 0xfaad38a0
chain tree_list 0xfad01db0 value void_type 0xfad0a8a0
void
pointer_to_this pointer_type 0xfa40cc00
addressable asm_written used nothrow static decl_5 decl_6 SI file
../../gcc/gcc/c-family/c-common.c line 1113 col 1 align 32 context
translation_unit_decl 0xfad09070 D.1 initial error_mark 0xfad063b0
arguments parm_decl 0xf91fb5f0 expr type pointer_type 0xf9be9960 tree
used visited unsigned SI file ../../gcc/gcc/c-family/c-common.c line
1113 col 29 size integer_cst 0xfad01570 32 unit size integer_cst 0xfad01588
4
align 32 context function_decl 0xf8f39100 c_fully_fold_internal
(reg/v/f:SI 6 %r6 [orig:914 expr ] [914]) arg-type pointer_type
0xf9be9960 tree
incoming-rtl (reg:SI 26 %r26 [ expr ])
chain parm_decl 0xf91fb6e0 in_init type boolean_type 0xfad0a5a0 bool
used visited unsigned QI file ../../gcc/gcc/c-family/c-common.c
line 1113 col 40
size integer_cst 0xfad016a8 constant 8
unit size integer_cst 0xfad016c0 constant 1
align 8 context function_decl 0xf8f39100 c_fully_fold_internal
(reg/v:SI 9 %r9 [orig:915 in_init+-3 ] [915]) arg-type
integer_type 0xfad0a360 int
incoming-rtl (reg:SI 25 %r25 [ in_init+-3 ]) chain parm_decl
0xf91fb7d0 maybe_const_operands
result result_decl 0xf91fb870 D.36357 type pointer_type 0xf9be9960 tree
unsigned ignored regdecl SI file ../../gcc/gcc/c-family/c-common.c line
1114 col 34 size integer_cst 0xfad01570 32 unit size integer_cst 0xfad01588
4
align 32 context function_decl 0xf8f39100 c_fully_fold_internal
(reg/f:SI 913 [ retval ])
full-name tree_node* c_fully_fold_internal(tree, bool, bool*, bool*)
pending-inline-info 0xf93dea68
(mem:SI (symbol_ref/v:SI (@_ZL21c_fully_fold_internalP9tree_nodebPbS1_)
[flags 0x203] function_decl 0xf8f39100 c_fully_fold_internal) [0 S4 A32])
struct-function 0xfa576478 chain var_decl 0xf8f3b3c0 fname_vars
$8 = void
[Bug target/61153] New: [ARM] vbic vorn tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 Bug ID: 61153 Summary: [ARM] vbic vorn tests fail Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: christophe.lyon at st dot com Since commit 210216 Neon intrinsics TLC - Replace intrinsics with GNU C implementations, I have noticed regressions in the following tests: gcc.target/arm/neon/vbicQs16.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQs32.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQs64.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQs8.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQu16.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQu32.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQu64.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQu8.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbics16.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbics32.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbics8.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicu16.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicu32.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicu8.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQs16.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQs32.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQs64.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQs8.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQu16.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQu32.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQu64.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQu8.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vorns16.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vorns32.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vorns8.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornu16.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornu32.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornu8.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n with many --with-target/--with-cpu/--with-fpu configurations as can be seen on http://cbuild.validation.linaro.org/build/cross-validation/gcc/210216/report-build-info.html
[Bug rtl-optimization/61094] [4.9/4.10 Regression] -O3 insn Internal compiler error in copyprop_hardreg_forward_1, at regcprop.c:775
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61094 Jeffrey A. Law law at redhat dot com changed: What|Removed |Added CC||law at redhat dot com Assignee|unassigned at gcc dot gnu.org |law at redhat dot com --- Comment #8 from Jeffrey A. Law law at redhat dot com --- Mine :-)
[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #5 from Manuel López-Ibáñez manu at gcc dot gnu.org --- Could you produce a complete testcase that (In reply to D. Hugh Redelmeier from comment #4) I have this problem too. I'm writing a wrapper for strftime. I get a warning on the actual strftime call. warning: format not a string literal, format string not checked [-Wformat-nonliteral] strftime(buf, buflen, fmt, t); Surely GCC should not that for fmt argument has been checked to be a valid strftime format at the points where prettynow gets called. So there is no need to whine that it is unchecked. You should be able to produce a minimal self-contained testcase (the one you posted doesn't compile). See http://gcc.gnu.org/bugs/minimize.html The best would be to include only the definitions of the types that you need and declare as 'extern' library functions that you use to avoid including headers. If you can produce another similar example that works with printf, that would also help. The second step would be to find out why it works with printf and not with strftime, but that would require debugging GCC while compiling your (new) testcases, so saving the first step will make it more likely that someone will do the second.
[Bug other/61146] wide-int error when building GCC with clang
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61146 Manuel López-Ibáñez manu at gcc dot gnu.org changed: What|Removed |Added CC||manu at gcc dot gnu.org --- Comment #4 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to Oleg Endo from comment #0) The *FLAGS_FOR_TARGET are required or else they will be set to *FLAGS, which will pass -fheinous-gnu-extensions to the SH xgcc when building libgcc etc. (PR 25672) It is funny that Clang has a flag called heinous-gnu-extensions. I wonder what other things are enabled by that (what they think are heinous GNU extensions and why).
[Bug c/61144] Invalid optimizations for extern vars with local weak definitions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 --- Comment #8 from Rich Felker bugdal at aerifal dot cx --- Further investigation suggests that the real gcc 4.8.2 is not affected; I was mislead by the fact that Debian is shipping as gcc-4.8_4.8.2-21 an svn snapshot that's actually post-4.8.2. So 4.9.0 seems to be the only official release that's affected.
[Bug middle-end/61154] New: [ARM] wide-int merge introduced regressions in vshuf tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61154 Bug ID: 61154 Summary: [ARM] wide-int merge introduced regressions in vshuf tests Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: christophe.lyon at st dot com Commit 210113 (Merge in wide-int) made several tests (mostly vshuf) to fail on hf ARM targets (both little and big endian). For instance, with GCC configured as: --target=arm-none-linux-gnueabihf --with-mode=arm --with-cpu=cortex-a9 --with-fpu=neon-fp16 I can see: Passed now fails [PASS = FAIL]: c-c++-common/torture/vshuf-v16hi.c -O1 (test for excess errors) c-c++-common/torture/vshuf-v16hi.c -O2 (test for excess errors) c-c++-common/torture/vshuf-v16hi.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) c-c++-common/torture/vshuf-v16hi.c -O3 -fomit-frame-pointer (test for excess errors) c-c++-common/torture/vshuf-v16hi.c -O3 -g (test for excess errors) c-c++-common/torture/vshuf-v16hi.c -Os (test for excess errors) gcc.dg/torture/vshuf-v16hi.c -O2 (test for excess errors) gcc.dg/torture/vshuf-v32qi.c -O2 (test for excess errors) gcc.dg/tree-ssa/ssa-fre-31.c (test for excess errors) Pass disappears [PASS = ]: gcc.dg/torture/vshuf-v16hi.c -O2 execution test gcc.dg/torture/vshuf-v32qi.c -O2 execution test gcc.dg/tree-ssa/pr45427.c scan-tree-dump-times cunrolli bounded by 0 0 Fail appears [ = FAIL]: c-c++-common/torture/vshuf-v16hi.c -O1 (internal compiler error) c-c++-common/torture/vshuf-v16hi.c -O2 (internal compiler error) c-c++-common/torture/vshuf-v16hi.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) c-c++-common/torture/vshuf-v16hi.c -O3 -fomit-frame-pointer (internal compiler error) c-c++-common/torture/vshuf-v16hi.c -O3 -g (internal compiler error) c-c++-common/torture/vshuf-v16hi.c -Os (internal compiler error) gcc.dg/torture/vshuf-v16hi.c -O2 (internal compiler error) gcc.dg/torture/vshuf-v32qi.c -O2 (internal compiler error) gcc.dg/tree-ssa/ssa-fre-31.c (internal compiler error)
[Bug target/61153] [ARM] vbic vorn tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ktkachov at gcc dot gnu.org --- Comment #1 from ktkachov at gcc dot gnu.org --- These are caused by r210216 when those intrinsics were reimplemented in C rather than using builtins. The only reason they fail is because the tests are compiled with -O0 which prevents combine from matching the corresponding patterns. If compiled with optimisation the tests all work. I believe the plan is to remove these tests sometime soon anyway. See http://gcc.gnu.org/ml/gcc-patches/2014-04/msg01836.html for more.
[Bug target/61153] [ARM] vbic vorn tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 --- Comment #2 from christophe.lyon at st dot com --- OK, but my tests currently don't inspect the generated code. They are execution tests, which means the could be PASS using only core instructions, and no Neon one. So maybe we should add some optimization level to the existing tests in the meantime?
[Bug target/61153] [ARM] vbic vorn tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153
--- Comment #3 from ktkachov at gcc dot gnu.org ---
So maybe we should add some optimization level to the existing tests in the
meantime?
Transforming them into something like
#include arm_neon.h
volatile int16x8_t arg0_int16x8_t;
volatile int16x8_t arg1_int16x8_t;
int16x8_t test_vbicQs16 (void)
{
int16x8_t out_int16x8_t;
return vbicq_s16 (arg0_int16x8_t, arg1_int16x8_t);
}
seems to work at -O2 (i.e. generates vbic and doesn't optimise away the whole
test), so it could be a way to go if the maintainers want it.
To be a bit pedantic, the ACLE spec doesn't strictly require the intrinsics
that the particular NEON instruction is generated, just that the functionality
is as defined in the spec (although the NEON instruction is likely to be the
optimal implementation of that functionality).
Do we plan to keep these scan-assembler tests? or go with just functional
tests?
[Bug target/61153] [ARM] vbic vorn tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #4 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Since commit 210216 Neon intrinsics TLC - Replace intrinsics with GNU C implementations, I have noticed regressions in the following tests: gcc.target/arm/neon/vbicQs16.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQs32.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQs64.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQs8.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQu16.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQu32.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQu64.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicQu8.c scan-assembler vbic[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbics16.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbics32.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbics8.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicu16.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicu32.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vbicu8.c scan-assembler vbic[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQs16.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQs32.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQs64.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQs8.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQu16.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQu32.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQu64.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornQu8.c scan-assembler vorn[ \t]+[qQ][0-9]+, [qQ][0-9]+, [qQ][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vorns16.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vorns32.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vorns8.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornu16.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornu32.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n gcc.target/arm/neon/vornu8.c scan-assembler vorn[ \t]+[dD][0-9]+, [dD][0-9]+, [dD][0-9]+!?([ \t]+@[a-zA-Z0-9 ]+)?\n Yes that is expected as per my original patch submission. Patch 1/3 said these tests would fail because at O0 combine doesn't run. I'm expecting your run time tests to go in and for cases where we need them, we may want to put out some kind of basic scan assembler tests for them. I'm tempted to mark this as invalid. with many --with-target/--with-cpu/--with-fpu configurations as can be seen on http://cbuild.validation.linaro.org/build/cross-validation/gcc/210216/report- build-info.html
[Bug target/61153] [ARM] vbic vorn tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 --- Comment #5 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- Do we plan to keep these scan-assembler tests? or go with just functional tests? No, not these scan assembler tests. They serve no purpose. I'm expecting them to get replaced by the testsuite you've been writing up and would like them to include any kind of scan-assembler tests if possible. Ramana
[Bug target/61153] [ARM] vbic vorn tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 --- Comment #6 from christophe.lyon at st dot com --- (In reply to Ramana Radhakrishnan from comment #4) Yes that is expected as per my original patch submission. Patch 1/3 said these tests would fail because at O0 combine doesn't run. Indeed, sorry I forgot about it. I'm expecting your run time tests to go in and for cases where we need them, we may want to put out some kind of basic scan assembler tests for them. I'm tempted to mark this as invalid. How do we define cases where we need them? My concern is that some compiler change might cause a suboptimal-yet-functional code to be generated, and we wouldn't notice it.
[Bug target/61153] [ARM] vbic vorn tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 --- Comment #7 from christophe.lyon at st dot com --- (In reply to Ramana Radhakrishnan from comment #5) Do we plan to keep these scan-assembler tests? or go with just functional tests? No, not these scan assembler tests. They serve no purpose. I'm expecting them to get replaced by the testsuite you've been writing up and would like them to include any kind of scan-assembler tests if possible. Good suggestion, I'll look at how easily I can add that.
[Bug target/61153] [ARM] vbic vorn tests fail
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61153 --- Comment #8 from ramana.radhakrishnan at arm dot com ramana.radhakrishnan at arm dot com --- How do we define cases where we need them? My concern is that some compiler change might cause a suboptimal-yet-functional code to be generated, and we wouldn't notice it. Well, currently tests in gcc.target/arm/neon serve no functional / correctness purpose. The only thing they check is if the correct instruction is generated at O0 which is probably enough for that case. I would rather that we put in scan-assembler tests in your testsuite rather than anything else. regards Ramana
[Bug c/61144] Invalid optimizations for extern vars with local weak definitions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 --- Comment #9 from Jody Lee Bruchon jody at jodybruchon dot com --- For my gcc versions (x86_64) compiled from release sources, I have the following for this testcase, with and without static, using -O2: === gcc 4.8.2, with and without static === $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.8.2/configure --prefix=/usr --mandir=/usr/man --libexecdir=/usr/lib --enable-languages=c,c++,objc --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-shared --disable-nls --with-x=no --with-system-zlib --disable-multilib --disable-bootstrap --disable-debug Thread model: posix gcc version 4.8.2 (GCC) $ objdump -dr test.o test.o: file format elf64-x86-64 Disassembly of section .text: bar: 0: 8b 15 00 00 00 00 mov0x0(%rip),%edx# 6 bar+0x6 2: R_X86_64_PC32foo-0x4 6: 31 c0 xor%eax,%eax 8: 85 d2 test %edx,%edx a: 0f 95 c0setne %al d: c3 retq === gcc 4.9.0 === $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.9.0/configure --prefix=/usr --mandir=/usr/man --libexecdir=/usr/lib --enable-languages=c,c++,objc --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-shared --disable-nls --with-x=no --with-system-zlib --disable-multilib --disable-debug Thread model: posix gcc version 4.9.0 (GCC) === With static (4.9.0) === $ objdump -dr test.o test.o: file format elf64-x86-64 Disassembly of section .text: bar: 0: 31 c0 xor%eax,%eax 2: c3 retq === Without static (4.9.0) === $ objdump -dr test.o test.o: file format elf64-x86-64 Disassembly of section .text: bar: 0: 8b 15 00 00 00 00 mov0x0(%rip),%edx# 6 bar+0x6 2: R_X86_64_PC32foo-0x4 6: 31 c0 xor%eax,%eax 8: 85 d2 test %edx,%edx a: 0f 95 c0setne %al d: c3 retq
[Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60300 Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com changed: What|Removed |Added CC||senthil_kumar.selvaraj@atme ||l.com --- Comment #4 from Senthil Kumar Selvaraj senthil_kumar.selvaraj at atmel dot com --- It doesn't actually get to that - avr_sp_immediate_operand returns false if the operand is not IN_RANGE(-6,6). The comments are a bit misleading though - the shortest sequence only applies if the addend is within that range. Like Johann said, it must be a deliberate decision in favor of speed - the attached program with a stub implementation of bar and main calling foo clocks a couple of cycles lesser with DSIZE=7 than with DSIZE=6(as measured with avrtest), although the code is 6 bytes longer. If RCALLs and PUSH had been generated, the code would be 4 bytes shorter, but would need 4 more clock cycles.
[Bug middle-end/61155] New: vshuf-v16hi failures for arm-none-linux-gnueabihf since the wide-int merge.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61155 Bug ID: 61155 Summary: vshuf-v16hi failures for arm-none-linux-gnueabihf since the wide-int merge. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end Assignee: unassigned at gcc dot gnu.org Reporter: ramana at gcc dot gnu.org I've recently started seeing these testfailures on arm-none-linux-gnueabihf. Appears to be from the wide-int merge. $TOPDIR/configure --target=arm-none-linux-gnueabihf --with-cpu=cortex-a15 --with-fpu=neon --with-float=hard FAIL: c-c++-common/torture/vshuf-v16hi.c -O1 (internal compiler error) FAIL: c-c++-common/torture/vshuf-v16hi.c -O1 (test for excess errors) FAIL: c-c++-common/torture/vshuf-v16hi.c -O2 (internal compiler error) FAIL: c-c++-common/torture/vshuf-v16hi.c -O2 (test for excess errors) FAIL: c-c++-common/torture/vshuf-v16hi.c -O3 -fomit-frame-pointer (internal compiler error) FAIL: c-c++-common/torture/vshuf-v16hi.c -O3 -fomit-frame-pointer (test for excess errors) FAIL: c-c++-common/torture/vshuf-v16hi.c -O3 -g (internal compiler error) FAIL: c-c++-common/torture/vshuf-v16hi.c -O3 -g (test for excess errors) FAIL: c-c++-common/torture/vshuf-v16hi.c -Os (internal compiler error) FAIL: c-c++-common/torture/vshuf-v16hi.c -Os (test for excess errors) FAIL: c-c++-common/torture/vshuf-v16hi.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (internal compiler error) FAIL: c-c++-common/torture/vshuf-v16hi.c -O2 -flto -fno-use-linker-plugin -flto-partition=none (test for excess errors) ./cc1plus -O2 -mcpu=cortex-a15 -mfpu=neon -mfloat-abi=hard vshuf-v16hi.ii
[Bug middle-end/61155] vshuf-v16hi failures for arm-none-linux-gnueabihf since the wide-int merge.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61155 --- Comment #1 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- These also look related to the same FAIL: gcc.dg/torture/vshuf-v32qi.c -O2 (internal compiler error) FAIL: gcc.dg/torture/vshuf-v32qi.c -O2 (test for excess errors)
[Bug middle-end/61155] vshuf-v16hi failures for arm-none-linux-gnueabihf since the wide-int merge.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61155 ktkachov at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||ktkachov at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from ktkachov at gcc dot gnu.org --- Seems like a duplicate of PR 61154 *** This bug has been marked as a duplicate of bug 61154 ***
[Bug target/61154] [ARM] wide-int merge introduced regressions in vshuf tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61154 ktkachov at gcc dot gnu.org changed: What|Removed |Added CC||ramana at gcc dot gnu.org --- Comment #1 from ktkachov at gcc dot gnu.org --- *** Bug 61155 has been marked as a duplicate of this bug. ***
[Bug target/61154] [ARM] wide-int merge introduced regressions in vshuf tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61154 Ramana Radhakrishnan ramana at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Target||arm-none-linux-gnueabihf Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-12 Ever confirmed|0 |1 --- Comment #2 from Ramana Radhakrishnan ramana at gcc dot gnu.org --- I see the same.
[Bug c++/60209] Declaration of user-defined literal operator cause error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60209 --- Comment #3 from emsr at gcc dot gnu.org --- Created attachment 32779 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32779action=edit Just parse a whole string instread of consuming one token. This builds and tests clean on x86_64-linux. I would like to hold out for a slightly better design that could simplifiy code a tiny bit and handle maybe these: void operator _x(unsigned long long); // This patch diagnoses this. void operator boo _y(unsigned long long); // I'd like to diagnose this. void operator u _u(unsigned long long); // I'd like to diagnose this. void operator u _v(unsigned long long); // Diagnosed correctly now. void operator _w(unsigned long long); // This might be harder/messier and may be out of scope.
[Bug c++/60209] Declaration of user-defined literal operator cause error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60209 emsr at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-12 Assignee|unassigned at gcc dot gnu.org |emsr at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from emsr at gcc dot gnu.org --- Created attachment 32780 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32780action=edit attach patch for previous message...
[Bug c/61144] Invalid optimizations for extern vars with local weak definitions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 --- Comment #10 from James Cloos cloos at jhcloos dot com --- My tests on debian sid with GCC: (Debian 4.8.2-21) 4.8.2 do not replicate the bug. On debian sid, only 4.9 and gcc-snapshot (the 4.10 branch) show the bug.
[Bug lto/54108] 35% bigger binary
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54108 wbrana wbrana at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from wbrana wbrana at gmail dot com --- Difference is about 3% in 4.8 and 4.9.
[Bug c++/61038] g++ -E is unusable with UDL strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038 --- Comment #2 from emsr at gcc dot gnu.org --- Created attachment 32781 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32781action=edit g++ -E pr61038.C pr61038_cxx98.ii Get preprocessed output in C++98 mode.
[Bug c++/61038] g++ -E is unusable with UDL strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038 --- Comment #3 from emsr at gcc dot gnu.org --- Created attachment 32782 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32782action=edit g++ -std=c++11 -E pr61038.C pr61038_cxx11.ii Get preprocessed output in C++11 mode.
[Bug fortran/61147] Incorrect behavior using function that returns deferred length character pointer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61147 Dominique d'Humieres dominiq at lps dot ens.fr changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-12 CC||janus at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Dominique d'Humieres dominiq at lps dot ens.fr --- Confirmed on 4.9.0 and trunk. The code works if I replace class (B), intent(in), target :: this with type (B), intent(in), target :: this however print *, ', toPointer(obj), ' prints ''.
[Bug c++/6273] [DR 502] Dependency of nested enumerations and enumerators
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6273 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #18 from Jason Merrill jason at gcc dot gnu.org --- (In reply to Paolo Carlini from comment #16) Jason, I'm having a look to this, and I'm not sure there is still something to do. I agree. The template op+ is found by argument-dependent lookup.
[Bug fortran/59537] No Automatic array cannot have an initializer, for -finit-real without a SAVE statement present in subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59537 --- Comment #6 from Lorenz Hüdepohl bugs at stellardeath dot org --- Nonetheless, code that compiles without -finit-real should also compile with -finit-real, right? I disagree: C506 states that automatic object cannot be initialized. What is wrong is that it depends on the presence of the SAVE statement without a saved entity list. Well, I guess it depends on what meaning one wants to assign to the flag -finit-real, which is anyway not something the standard specifies, right? Do you really want to restrict the usage of -finit-real to programs where every last variable is initializable? I always use -finit-real as a kind of debug feature, with -finit-real=snan, to check for the use of uninitialized values. I did never expect that it should have a well defined, standard-mandated effect.
[Bug fortran/61156] New: Internal compiler error for Fortran files when specifying a file instead of an include directory with -I
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61156 Bug ID: 61156 Summary: Internal compiler error for Fortran files when specifying a file instead of an include directory with -I Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: trivial Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: bugs at stellardeath dot org gfortran produces an internal compiler error when one mistakenly specifies a file instead of a directory with -I: # touch file.h # touch src.F90 # gcc-4.9 -I./file.h src.F90 Warning: ./file.h is not a directory f951: internal compiler error: Aborted Please submit a full bug report, with preprocessed source if appropriate. See http://bugs.opensuse.org/ for instructions. # Happens both withe shipped gcc-4.8.1 from openSUSE 13.1 and their gcc-4.9.0 from a development repository: # gcc-4.9 --version gcc-4.9 (SUSE Linux) 4.9.0 Copyright (C) 2014 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. I could also trigger this with versions 4.8.1, 4.7.3, and 4.6.4, - but not with 4.3.4 :)
[Bug c++/61038] g++ -E is unusable with UDL strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038 emsr at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-05-12 Assignee|unassigned at gcc dot gnu.org |emsr at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #4 from emsr at gcc dot gnu.org --- Created attachment 32783 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32783action=edit In libcpp, is stringify_arg, test for user-defined literal strings. libcpp/ 2014-05-12 Edward Smith-Rowland 3dw...@verizon.net PR c++/61038 * module.c (stringify_arg (cpp_reader *, macro_arg *)): Check for user-defined literal strings to escape quotes. I need testcases. Also, it just occurred to me that I should test for user-defined *chars* too. After work...
[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438
--- Comment #6 from D. Hugh Redelmeier hugh at mimosa dot com ---
Responding to Comment 5 by Manuel López-Ibáñez:
Thanks for looking at this.
Could you produce a complete testcase
===
/* compile with -c -Wformat -Werror=format-nonliteral */
#include time.h
extern void prettynow(char *buf, size_t buflen, const char *fmt, struct tm *t)
__attribute__ ((format (__strftime__, 3, 0)));
void prettynow(char *buf, size_t buflen, const char *fmt, struct tm *t)
{
strftime(buf, buflen, fmt, t);
}
===
The best would be to include only the definitions of the types that you need
and declare as 'extern' library functions that you use to avoid including
headers.
I didn't do this part. My excuses: the type declarations are not portable but
the example should be; the solution might be in fixing headers; this way is
shorter too.
If you can produce another similar example that works with printf, that would
also help.
I don't think that printf is similar enough. A strftime format doesn't
interact with varargs in a complex and problematic way. A string, on its own,
is or is not a valid strftime format; a string is only a valid printf format
when considered with the argument list.
If an arg is marked as a const char * (i.e. unchanging) and has the strftime
format attribute, it should be accepted as if it were a literal strftime
argument. After all, the necessary checking would have been done at this
routine's points of call.
[Bug c/61144] Invalid optimizations for extern vars with local weak definitions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 --- Comment #11 from Rich Felker bugdal at aerifal dot cx --- Adding __attribute__((__used__)) to the static object suppresses the symptom in case that helps to isolate what's causing it.
[Bug target/60991] [avr] Stack corruption when using 24-bit integers __int24 or __memx pointers in large stack frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60991 --- Comment #4 from denisc at gcc dot gnu.org --- Author: denisc Date: Mon May 12 15:33:00 2014 New Revision: 210325 URL: http://gcc.gnu.org/viewcvs?rev=210325root=gccview=rev Log: gcc/ChangeLog PR target/60991 * config/avr/avr.c (avr_out_store_psi): Use correct constant to restore Y. gcc/testsuite/ChangeLog PR target/60991 * gcc.target/avr/pr60991.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/avr/pr60991.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr.c trunk/gcc/testsuite/ChangeLog
[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438 --- Comment #7 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to D. Hugh Redelmeier from comment #6) The best would be to include only the definitions of the types that you need and declare as 'extern' library functions that you use to avoid including headers. I didn't do this part. My excuses: the type declarations are not portable but the example should be; the solution might be in fixing headers; this way is shorter too. If you compile with --save-temps (as the instruction say), you will see what GCC parses. All that code makes debugging more complex. So if someone had to debug this, he would have to cut down that code to a few lines. This is one reason why examples should be minimal.
[Bug target/60300] [avr] Suboptimal stack pointer manipulation for frame setup
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60300 --- Comment #5 from Matthijs Kooijman matthijs at stdin dot nl --- Ah, then the comments are a bit misleading, yes. Wouldn't it make sense to put this decision outside of avr_sp_immediate_operand, in the same area where the decision between the two options is made? Might lead to a bit of duplication, though, it seems the function is callled twice. In any case, from a user perspective, it surprises me that this exception is made, even when compiling with -Os. Wouldn't it make sense to ignore the range check with -Os? Or is -Os really only used to determine the list of optimizations to (not) run and not supposed to influence the behaviour of the compiler otherwise?
[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438 --- Comment #8 from Manuel López-Ibáñez manu at gcc dot gnu.org --- (In reply to D. Hugh Redelmeier from comment #6) If you can produce another similar example that works with printf, that would also help. I don't think that printf is similar enough. A strftime format doesn't interact with varargs in a complex and problematic way. A string, on its own, is or is not a valid strftime format; a string is only a valid printf format when considered with the argument list. If an arg is marked as a const char * (i.e. unchanging) and has the strftime format attribute, it should be accepted as if it were a literal strftime argument. After all, the necessary checking would have been done at this routine's points of call. Assuming that the wrapper is marked with the correct attribute, GCC would need to know that this const char* comes from the correct wrapper's argument. I am not sure this is trivial to know at the point of warning without additional work/info in the front-end. Some comments above have suggested that this work/info is done for printf, so the first thing someone looking at this should do is to understand how printf detects this case, and why the same is not done for strftime, and then try to share as much code between the two cases as possible. Perhaps it is a bug, perhaps it was never implemented for strftime. In any case, one would need to debug GCC using two similar and minimal testcases to understand what is going on. See http://gcc.gnu.org/wiki/DebuggingGCC if you want to see how this works. As an exercise, try to find the point of warning while debugging using your testcase. Bugs/features are more likely to be fixed if: 1. There is a minimal testcase that reproduces the problem 2. Someone has debugged GCC and identified the problem 3. Someone has done all the legal prerequisites and posted a patch that fixes the problem 4. Someone has tested and submitted the patch for review 5. Someone has taken care of the review comments and committed the patch We are not even in 1 and the real work is 2 and 3.
[Bug target/60991] [avr] Stack corruption when using 24-bit integers __int24 or __memx pointers in large stack frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60991 --- Comment #5 from denisc at gcc dot gnu.org --- Author: denisc Date: Mon May 12 15:57:52 2014 New Revision: 210327 URL: http://gcc.gnu.org/viewcvs?rev=210327root=gccview=rev Log: Backport from mainline 2014-05-12 Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com PR target/60991 * config/avr/avr.c (avr_out_store_psi): Use correct constant to restore Y. Backport from mainline 2014-05-12 Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com PR target/60991 * gcc.target/avr/pr60991.c: New testcase. Added: branches/gcc-4_9-branch/gcc/testsuite/gcc.target/avr/pr60991.c Modified: branches/gcc-4_9-branch/gcc/ChangeLog branches/gcc-4_9-branch/gcc/config/avr/avr.c branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
[Bug target/61154] [ARM] wide-int merge introduced regressions in vshuf tests
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61154 --- Comment #3 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org --- This code is doing an OImode ASHIFT and fails the check: #if TARGET_SUPPORTS_WIDE_INT == 0 /* This assert keeps the simplification from producing a result that cannot be represented in a CONST_DOUBLE but a lot of upstream callers expect that this function never fails to simplify something and so you if you added this to the test above the code would die later anyway. If this assert happens, you just need to make the port support wide int. */ gcc_assert (width = HOST_BITS_PER_DOUBLE_INT); #endif since without CONST_WIDE_INT we won't be able to represent all results correctly. Unfortunately porting to CONST_WIDE_INT is something that needs knowledge of the target-specific code, but it shouldn't be much work. It's just a case of auditing each use of const_double in config/arm to see whether it is handling integer const_doubles or floating-point const_doubles. Since ARM is a 32-bit target and since HWI and CONST_INT are 64 bits, I assume most places really are handling floating-point values. (A grep makes that obvious for some things, but arm_immediate_di_operand does accept const_double. I'm not sure whether that's just a left-over from pre need_64bit_hwint days though.) Adding: #define TARGET_SUPPORTS_WIDE_INT 1 does fix the ICE but it'd be good audit the use of const_doubles too.
[Bug target/60991] [avr] Stack corruption when using 24-bit integers __int24 or __memx pointers in large stack frame
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60991 --- Comment #6 from denisc at gcc dot gnu.org --- Author: denisc Date: Mon May 12 16:07:44 2014 New Revision: 210328 URL: http://gcc.gnu.org/viewcvs?rev=210328root=gccview=rev Log: Backport from mainline 2014-05-12 Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com PR target/60991 * config/avr/avr.c (avr_out_store_psi): Use correct constant to restore Y. Backport from mainline 2014-05-12 Senthil Kumar Selvaraj senthil_kumar.selva...@atmel.com PR target/60991 * gcc.target/avr/pr60991.c: New testcase. Added: branches/gcc-4_8-branch/gcc/testsuite/gcc.target/avr/pr60991.c Modified: branches/gcc-4_8-branch/gcc/ChangeLog branches/gcc-4_8-branch/gcc/config/avr/avr.c branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
[Bug fortran/60834] [OOP] ICE with ASSOCIATE construct (gimplify_var_or_parm_decl, at gimplify.c:1721)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60834 --- Comment #3 from Thomas Koenig tkoenig at gcc dot gnu.org --- Author: tkoenig Date: Mon May 12 16:17:09 2014 New Revision: 210329 URL: http://gcc.gnu.org/viewcvs?rev=210329root=gccview=rev Log: 2014-05-12 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/60834 * frontend-passes.c (in_assoc_list): New variable. (optimize_namespace): Initialize in_assoc_list (combine_array_constructor): Don't try to combine assoc lists. (gfc_code_walker): Keep track of in_assoc_list. 2014-05-12 Thomas Koenig tkoe...@gcc.gnu.org PR fortran/60834 * gfortran.dg/associate_16.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/associate_16.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/frontend-passes.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/61126] gfortran does not enable -Wununused-parameter with -Wextra
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61126 --- Comment #17 from Matthias Klose doko at gcc dot gnu.org --- patch posted at http://gcc.gnu.org/ml/gcc-patches/2014-05/msg00785.html
[Bug target/61131] [4.8 regression] ARM -Os: incorrect code generation
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61131 --- Comment #5 from Mikael Pettersson mikpelinux at gmail dot com --- (In reply to Stephen Warren from comment #3) Or is the definition of undefined such that it propagates through the entire expression irrespective of the expression's logic? It is. Once execution hits undefined behaviour all bets are off. Undefined is not some unspecified value you can choose to ignore.
[Bug c/61144] Invalid optimizations for extern vars with local weak definitions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 --- Comment #12 from Rich Felker bugdal at aerifal dot cx --- Furthermore, __builtin_constant_p(dummy) wrongly returns 1, even though dummy is modifiable externally via foo (assuming foo is not replaced by a strong definition elsewhere). Perhaps this should be filed as a separate bug since it's also user-visible, but I think the cause is the same. On the other hand, according to my tests on gcc.godbolt.org, the incorrect value for __builtin_constant_p predates the optimization bug. This could mean they're separate bugs, but I suspect the later changes that cause the optimization bug were correct except that they're using the wrong concept of is this expression constant? from the earlier bug.
[Bug target/61157] New: [SH] Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61157 Bug ID: 61157 Summary: [SH] Implement TARGET_ATOMIC_ASSIGN_EXPAND_FENV Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: olegendo at gcc dot gnu.org Target: sh*-*-* http://gcc.gnu.org/ml/gcc/2013-11/msg00131.html
[Bug c++/61038] g++ -E is unusable with UDL strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038 --- Comment #5 from Ed Smith-Rowland 3dw4rd at verizon dot net --- I'm pretty sure I have my arms around this one. Two questions: 1. Any ideas on how to make testsuite cases? Any examples of looking at preprocessed files in the testsuite? 2. Assuming this gets into mainline, how far can we backport?
[Bug c/61158] New: negative shift at fold-const.c:12095
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61158
Bug ID: 61158
Summary: negative shift at fold-const.c:12095
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: zeccav at gmail dot com
Compilation of the following forces a negative shift, result undefined in my
opinion
/* gcc -S negative shift at fold-const.c:12095
* x86_64
* zerobits = prec - shiftc;
* because prec - shiftc = -8
* result is undefined
* compiling Linux Fedora 20 source code kernel/trace/blktrace.c
* checked with gcc_assert(prec = shiftc prec-shiftc
HOST_BITS_PER_WIDE_INT); immediately before
*/
typedef unsigned long long __u64;
void blk_add_trace_unplug(unsigned int depth)
{
((__u64)(depth) (__u64)0x00ffULL) 40;
}
[Bug ipa/61159] New: __builtin_constant_p gives incorrect results with aliases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61159 Bug ID: 61159 Summary: __builtin_constant_p gives incorrect results with aliases Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: bugdal at aerifal dot cx This issue is closely related to #61144, but seems to have appeared earlier. Consider the following test case: static int dummy = 0; extern int foo __attribute__((__weak__, __alias__(dummy))); typedef char check[2*!__builtin_constant_p(dummy)-1]; typedef char check[2*!__builtin_constant_p(foo)-1]; While the static dummy could be considered constant if its address did not leak outside the translation unit, its address DOES leak via the weak alias foo. As long as there is no strong definition for foo in another translation unit, dummy may be externally modified via the alias foo. As for foo, it is external and thus may never be considered constant. Thus, __builtin_constant_p(dummy) and __builtin_constant_p(foo) should both yield zero and the above translation unit should compile successfully. The results observed vary highly with gcc version. A number of versions were observed giving __builtin_constant_p(dummy)==1, including 4.8.1, but __builtin_constant_p(foo) was more rare, showing up only in 4.9.0 and some really old versions like 4.4.7 (tested via gcc.godbolt.org since I don't have that many gcc versions lying around to test locally).
[Bug target/60588] AVR target does not support init_priority attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60588
Charles Lohr charles at cnlohr dot com changed:
What|Removed |Added
CC||charles at cnlohr dot com
--- Comment #1 from Charles Lohr charles at cnlohr dot com ---
I am frustrated by this as well, and was hoping that since both AVRs and ARMs
are bare metal systems, it could be done in a similar way. With ARMs, the
constructors are placed into a list that can be manually executed after main()
starts.
I.e.
constructor_t *fn = _init_array_start;
while(fn _init_array_end)
{
(*fn++)();
}
[Bug c++/61038] g++ -E is unusable with UDL strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038 --- Comment #6 from Paolo Carlini paolo.carlini at oracle dot com --- Please send your patches, questions, etc, about this and the other bug to the mailing list, with Jason in CC, otherwise we seriously risk unnecessarily delaying the resolution of the issues.
[Bug fortran/60127] ICE with OpenMP and DO CONCURRENT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60127 --- Comment #4 from Tobias Burnus burnus at gcc dot gnu.org --- Author: burnus Date: Mon May 12 19:00:08 2014 New Revision: 210331 URL: http://gcc.gnu.org/viewcvs?rev=210331root=gccview=rev Log: 2014-05-12 Tobias Burnus bur...@net-b.de PR fortran/60127 * openmp.c (resolve_omp_do): Reject do concurrent loops. 2014-05-12 Tobias Burnus bur...@net-b.de PR fortran/60127 * gfortran.dg/gomp/omp_do_concurrent.f90: New. Added: trunk/gcc/testsuite/gfortran.dg/gomp/omp_do_concurrent.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/openmp.c trunk/gcc/testsuite/ChangeLog
[Bug c/61144] Invalid optimizations for extern vars with local weak definitions
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 --- Comment #13 from Rich Felker bugdal at aerifal dot cx --- I've added the related issue 61159.
[Bug fortran/60127] ICE with OpenMP and DO CONCURRENT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60127 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from Tobias Burnus burnus at gcc dot gnu.org --- FIXED on the 4.10 trunk.
[Bug libfortran/61035] Crash in getcwd intrinsic due to stack overflow
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61035 --- Comment #3 from Janne Blomqvist jb at gcc dot gnu.org --- Author: jb Date: Mon May 12 19:23:11 2014 New Revision: 210335 URL: http://gcc.gnu.org/viewcvs?rev=210335root=gccview=rev Log: Fix stack overflow crash in getcwd intrinsic. 2014-05-12 Janne Blomqvist j...@gcc.gnu.org PR libfortran/61035 * intrinsics/getcwd.c (getcwd_i4_sub): Avoid potentially large stack allocation, avoid extra copying in the common case. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/intrinsics/getcwd.c
[Bug c/39438] Can't compile a wrapper around strftime with -Werror=format-nonliteral
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39438 --- Comment #9 from D. Hugh Redelmeier hugh at mimosa dot com --- Created attachment 32784 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32784action=edit minimal C source code that demonstrates the problem minimal C source code that demonstrates the problem. Notice that the (system-provided) declaration annotates the format argument dirrectly with __format. I haven't found documentation for that.
[Bug ipa/61159] __builtin_constant_p gives incorrect results with aliases
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61159 --- Comment #1 from Rich Felker bugdal at aerifal dot cx --- I should amend this report with further info: __builtin_constant_p is giving different results for dummy and foo depending on whether it's used at file scope or in a function. I've also observed some other really weird behavior from it that I need to summarize and report.
[Bug ipa/61160] New: [4.9/4.10 Regression] wrong code with -O3 (or ICE: verify_cgraph_node failed: edge points to wrong declaration)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61160 Bug ID: 61160 Summary: [4.9/4.10 Regression] wrong code with -O3 (or ICE: verify_cgraph_node failed: edge points to wrong declaration) Product: gcc Version: 4.10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: ipa Assignee: unassigned at gcc dot gnu.org Reporter: zsojka at seznam dot cz Created attachment 32785 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=32785action=edit reduced testcase (from g++.old-deja/g++.jason/thunk1.C) Output: $ g++ -O3 testcase.C $ valgrind ./a.out ==21283== Invalid read of size 8 ==21283==at 0x400740: CExample::MixinFunc(int, A) [clone .constprop.0] (testcase.C:3) ==21283==by 0x40062A: main (testcase.C:27) ==21283== Address 0x1 is not stack'd, malloc'd or (recently) free'd Tested revisions: r210308 - fail 4.9 r210307 - fail 4.8 r210303 - OK
[Bug ipa/61160] [4.9/4.10 Regression] wrong code with -O3 (or ICE: verify_cgraph_node failed: edge points to wrong declaration)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61160 --- Comment #1 from Zdenek Sojka zsojka at seznam dot cz --- Created attachment 32786 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32786action=edit testcase causing ICE Slightly modified, struct A replaced by void *. Compiler output: $ g++ -O3 testcase.C testcase.C:28:1: error: edge points to wrong declaration: } ^ function_decl 0x7f09e2392600 _ZThn8_N8CExample9MixinFuncEiPv.artificial_thunk.1.artificial_thunk.3 type method_type 0x7f09e237c348 type pointer_type 0x7f09e22130a8 type void_type 0x7f09e2213000 void public unsigned DI size integer_cst 0x7f09e21edf78 constant 64 unit size integer_cst 0x7f09e21edf90 constant 8 align 64 symtab 0 alias set 3 canonical type 0x7f09e22130a8 pointer_to_this pointer_type 0x7f09e2219e70 QI size integer_cst 0x7f09e220c078 constant 8 unit size integer_cst 0x7f09e220c090 constant 1 align 8 symtab 0 alias set -1 canonical type 0x7f09e237c348 method basetype record_type 0x7f09e2374000 CExample arg-types tree_list 0x7f09e2396708 value pointer_type 0x7f09e23742a0 chain tree_list 0x7f09e21fdbb8 value void_type 0x7f09e2213000 void readonly addressable used decl_5 QI file testcase.C line 11 col 9 align 8 context record_type 0x7f09e2374000 CExample arguments parm_decl 0x7f09e236d580 this type pointer_type 0x7f09e2374348 type record_type 0x7f09e2374000 CExample readonly unsigned DI size integer_cst 0x7f09e21edf78 64 unit size integer_cst 0x7f09e21edf90 8 align 64 symtab 0 alias set -1 canonical type 0x7f09e2374348 readonly unsigned DI file testcase.C line 11 col 39 size integer_cst 0x7f09e21edf78 64 unit size integer_cst 0x7f09e21edf90 8 align 64 context function_decl 0x7f09e235ce00 _ZThn8_N8CExample9MixinFuncEiPv arg-type pointer_type 0x7f09e2374348 chain parm_decl 0x7f09e236d600 arg type integer_type 0x7f09e21ff690 int used SI file testcase.C line 11 col 24 size integer_cst 0x7f09e220c1c8 constant 32 unit size integer_cst 0x7f09e220c1e0 constant 4 align 32 context function_decl 0x7f09e235ce00 _ZThn8_N8CExample9MixinFuncEiPv arg-type integer_type 0x7f09e21ff690 int chain parm_decl 0x7f09e236d680 arg2 Instead of: function_decl 0x7f09e235ce00 _ZThn8_N8CExample9MixinFuncEiPv type method_type 0x7f09e23741f8 type pointer_type 0x7f09e22130a8 type void_type 0x7f09e2213000 void public unsigned DI size integer_cst 0x7f09e21edf78 constant 64 unit size integer_cst 0x7f09e21edf90 constant 8 align 64 symtab 0 alias set 3 canonical type 0x7f09e22130a8 pointer_to_this pointer_type 0x7f09e2219e70 QI size integer_cst 0x7f09e220c078 constant 8 unit size integer_cst 0x7f09e220c090 constant 1 align 8 symtab 0 alias set -1 canonical type 0x7f09e23741f8 method basetype record_type 0x7f09e2374000 CExample arg-types tree_list 0x7f09e2356938 value pointer_type 0x7f09e23742a0 chain tree_list 0x7f09e2356618 value integer_type 0x7f09e21ff690 int chain tree_list 0x7f09e2356640 value pointer_type 0x7f09e22130a8 chain tree_list 0x7f09e21fdbb8 value void_type 0x7f09e2213000 void pointer_to_this pointer_type 0x7f09e2374888 readonly addressable asm_written used public weak virtual decl_5 QI file testcase.C line 11 col 9 align 8 context record_type 0x7f09e2374000 CExample arguments parm_decl 0x7f09e236d580 this type pointer_type 0x7f09e2374348 type record_type 0x7f09e2374000 CExample readonly unsigned DI size integer_cst 0x7f09e21edf78 64 unit size integer_cst 0x7f09e21edf90 8 align 64 symtab 0 alias set -1 canonical type 0x7f09e2374348 readonly unsigned DI file testcase.C line 11 col 39 size integer_cst 0x7f09e21edf78 64 unit size integer_cst 0x7f09e21edf90 8 align 64 context function_decl 0x7f09e235ce00 _ZThn8_N8CExample9MixinFuncEiPv arg-type pointer_type 0x7f09e2374348 chain parm_decl 0x7f09e236d600 arg type integer_type 0x7f09e21ff690 int used SI file testcase.C line 11 col 24 size integer_cst 0x7f09e220c1c8 constant 32 unit size integer_cst 0x7f09e220c1e0 constant 4 align 32 context function_decl 0x7f09e235ce00 _ZThn8_N8CExample9MixinFuncEiPv arg-type integer_type 0x7f09e21ff690 int chain parm_decl 0x7f09e236d680 arg2 full-name virtual void* CExample::_ZThn8_N8CExample9MixinFuncEiPv(int, void*) main/14 (int main()) @0x7f09e237f7b0 Type: function definition analyzed Visibility: externally_visible public References: Referring: Availability: available First run: 0 Function flags: body only_called_at_startup Called by: Calls:
[Bug c/61144] Invalid optimizations for extern vars with local weak definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 --- Comment #14 from Marc Glisse glisse at gcc dot gnu.org --- This seems related to PR 59948 where Honza says the code is really broken.
[Bug c++/61161] New: wrong two-stage name lookup for overloaded operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61161
Bug ID: 61161
Summary: wrong two-stage name lookup for overloaded operators
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
GCC rejects-valid on this:
struct T {
templatetypename T void f(const T v) {
0 v;
}
};
namespace N {
struct X {};
struct Y : X {};
void operator(int, const X) {}
}
void operator(int, const N::Y) = delete;
int main() {
N::Y d;
T().f(d);
}
This is valid because the deleted operator is found by neither unqualified
lookup (within the template) or argument-dependent lookup (which searches
namespace N and not the global namespace).
This seems to be specific to operator syntax; if 'f' is changed to
operator(0, v);
then the code is accepted.
[Bug c++/61038] g++ -E is unusable with UDL strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038
--- Comment #7 from Ed Smith-Rowland 3dw4rd at verizon dot net ---
Note to self: you DO need to take care of char...
void
operator _t(const char)
{
}
#define QUOTE(s) #s
int
main()
{
QUOTE(''_t);
QUOTE('\''_t);
QUOTE('\\'_t);
}
[Bug other/31778] genattrtab.c doesn't record filename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31778 --- Comment #4 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- Author: mrs Date: Mon May 12 21:22:20 2014 New Revision: 210340 URL: http://gcc.gnu.org/viewcvs?rev=210340root=gccview=rev Log: PR other/31778 * genattrtab.c (filename): Add. (convert_set_attr_alternative): Improve error message. (check_defs): Restore read_md_filename for error messages. (gen_insn): Save filename. Modified: trunk/gcc/ChangeLog trunk/gcc/genattrtab.c
[Bug other/31778] genattrtab.c doesn't record filename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31778 mrs at gcc dot gnu.org mrs at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from mrs at gcc dot gnu.org mrs at gcc dot gnu.org --- Fixed.
[Bug c++/61038] g++ -E is unusable with UDL strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038 --- Comment #8 from Ben Longbons b.r.longbons at gmail dot com --- (In reply to Ed Smith-Rowland from comment #7) Note to self: you DO need to take care of char... What about multi-char constants, or are they not permitted in C++ UDLs? Normally they get converted to int, so they're not *meaningful*, but ... Also, remember the different prefixes: L for wchar_t, u8 for char-but-utf8, u for char16_t, and U for char32_t unsigned int fourcc = 'ABCD';
[Bug c++/61038] g++ -E is unusable with UDL strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038 --- Comment #9 from Daniel Krügler daniel.kruegler at googlemail dot com --- (In reply to Ben Longbons from comment #8) What about multi-char constants, or are they not permitted in C++ UDLs? Normally they get converted to int, so they're not *meaningful*, but ... There exists a core language issue for this: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1723
[Bug c++/61161] wrong two-stage name lookup for overloaded operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61161 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org --- Maybe related to PR51577
[Bug c++/60373] half warning: visibility attribute ignored because it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60373 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-12 Assignee|unassigned at gcc dot gnu.org |paolo.carlini at oracle dot com Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com --- Mine.
[Bug target/60735] GCC targeting E500 with SPE has errors with the _Decimal64 type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60735 --- Comment #15 from Peter Bergner bergner at gcc dot gnu.org --- Author: bergner Date: Mon May 12 23:08:22 2014 New Revision: 210344 URL: http://gcc.gnu.org/viewcvs?rev=210344root=gccview=rev Log: Reapply the old IBM 4.8 branch patches that are not upstream. gcc/ Back port mainline subversion id 209025. 2014-04-02 Michael Meissner meiss...@linux.vnet.ibm.com PR target/60735 * config/rs6000/rs6000.c (rs6000_hard_regno_mode_ok): If we have software floating point or no floating point registers, do not allow any type in the FPRs. Eliminate a test for SPE SIMD types in GPRs that occurs after we tested for GPRs that would never be true. Back port from main line: 2014-03-27 Michael Meissner meiss...@linux.vnet.ibm.com * config/rs6000/constraints.md (wD constraint): New constraint to match the constant integer to get the top DImode/DFmode out of a vector in a VSX register. * config/rs6000/predicates.md (vsx_scalar_64bit): New predicate to match the constant integer to get the top DImode/DFmode out of a vector in a VSX register. * config/rs6000/rs6000.c (rs6000_debug_reg_global): If -mdebug=reg, print value of VECTOR_ELEMENT_SCALAR_64BIT. * config/rs6000/rs6000.h (VECTOR_ELEMENT_SCALAR_64BIT): Macro to define the top 64-bit vector element. * config/rs6000/vsx.md (vsx_extract_mode, V2DI/V2DF modes): Optimize vec_extract of 64-bit values, where the value being extracted is in the top word, where we can use scalar instructions. Add direct move and store support. Combine the big endian/little endian vector select load support into a single insn. (vsx_extract_mode_internal1): Likewise. (vsx_extract_mode_internal2): Likewise. (vsx_extract_mode_load): Likewise. (vsx_extract_mode_store): Likewise. (vsx_extract_mode_zero): Delete, big and little endian insns are combined into vsx_extract_mode_load. (vsx_extract_mode_one_le): Likewise. * doc/md.texi (PowerPC and IBM RS6000 constraints): Document wD constraint. * gcc.target/powerpc/vsx-extract-1.c: New test to test VSX vec_select optimizations. * gcc.target/powerpc/vsx-extract-2.c: Likewise. * gcc.target/powerpc/vsx-extract-3.c: Likewise. PR target/60672 * gcc.target/powerpc/pr60676.c: New file, make sure xxsldwi and xxpermdi builtins are supported. Backport from mainline 2013-08-01 Fabien Chêne fab...@gcc.gnu.org PR c++/54537 * include/tr1/cmath: Remove pow(double,double) overload, remove a duplicated comment about DR 550. Add a comment to explain the issue. * testsuite/tr1/8_c_compatibility/cmath/pow_cmath.cc: New. gcc/testsuite/ Back port from mainline 2013-08-01 Fabien Chêne fab...@gcc.gnu.org Peter Bergner berg...@vnet.ibm.com PR c++/54537 * g++.dg/overload/using3.C: New. * g++.dg/overload/using2.C: Adjust. * g++.dg/lookup/using9.C: Likewise. gcc/cp/ Back port from mainline 2013-08-01 Fabien Chêne fab...@gcc.gnu.org PR c++/54537 * cp-tree.h: Check OVL_USED with OVERLOAD_CHECK. * name-lookup.c (do_nonmember_using_decl): Make sure we have an OVERLOAD before calling OVL_USED. Call diagnose_name_conflict instead of issuing an error without mentioning the conflicting declaration. libgcc/ * config/rs6000/ibm-ldouble.c (pack_ldouble): New function. (__gcc_qadd): Use it. (__gcc_qmul): Likewise. (__gcc_qdiv): Likewise. (__gcc_qneg): Likewise. (__gcc_stoq): Likewise. (__gcc_dtoq): Likewise. Added: branches/ibm/gcc-4_8-branch/gcc/cp/ChangeLog.ibm branches/ibm/gcc-4_8-branch/gcc/testsuite/g++.dg/overload/using3.C branches/ibm/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/pr60676.c branches/ibm/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/vsx-extract-1.c branches/ibm/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/vsx-extract-2.c branches/ibm/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/vsx-extract-3.c branches/ibm/gcc-4_8-branch/libgcc/ChangeLog.ibm branches/ibm/gcc-4_8-branch/libstdc++-v3/testsuite/tr1/8_c_compatibility/cmath/pow_cmath.cc Modified: branches/ibm/gcc-4_8-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_8-branch/gcc/config/rs6000/constraints.md branches/ibm/gcc-4_8-branch/gcc/config/rs6000/predicates.md branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.c branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.h branches/ibm/gcc-4_8-branch/gcc/config/rs6000/vsx.md branches/ibm/gcc-4_8-branch/gcc/cp/cp-tree.h branches/ibm/gcc-4_8-branch/gcc/cp/name-lookup.c branches/ibm/gcc-4_8-branch/gcc/doc/md.texi branches/ibm/gcc-4_8-branch/gcc/testsuite/ChangeLog.ibm branches/ibm/gcc-4_8-branch/gcc/testsuite/g++.dg/lookup/using9.C branches/ibm/gcc-4_8-branch/gcc/testsuite/g++.dg/overload/using2.C
[Bug testsuite/60672] FAIL: g++.dg/cpp1y/auto-fn25.C -std=gnu++1y (test for errors, line 7)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60672 --- Comment #7 from Peter Bergner bergner at gcc dot gnu.org --- Author: bergner Date: Mon May 12 23:08:22 2014 New Revision: 210344 URL: http://gcc.gnu.org/viewcvs?rev=210344root=gccview=rev Log: Reapply the old IBM 4.8 branch patches that are not upstream. gcc/ Back port mainline subversion id 209025. 2014-04-02 Michael Meissner meiss...@linux.vnet.ibm.com PR target/60735 * config/rs6000/rs6000.c (rs6000_hard_regno_mode_ok): If we have software floating point or no floating point registers, do not allow any type in the FPRs. Eliminate a test for SPE SIMD types in GPRs that occurs after we tested for GPRs that would never be true. Back port from main line: 2014-03-27 Michael Meissner meiss...@linux.vnet.ibm.com * config/rs6000/constraints.md (wD constraint): New constraint to match the constant integer to get the top DImode/DFmode out of a vector in a VSX register. * config/rs6000/predicates.md (vsx_scalar_64bit): New predicate to match the constant integer to get the top DImode/DFmode out of a vector in a VSX register. * config/rs6000/rs6000.c (rs6000_debug_reg_global): If -mdebug=reg, print value of VECTOR_ELEMENT_SCALAR_64BIT. * config/rs6000/rs6000.h (VECTOR_ELEMENT_SCALAR_64BIT): Macro to define the top 64-bit vector element. * config/rs6000/vsx.md (vsx_extract_mode, V2DI/V2DF modes): Optimize vec_extract of 64-bit values, where the value being extracted is in the top word, where we can use scalar instructions. Add direct move and store support. Combine the big endian/little endian vector select load support into a single insn. (vsx_extract_mode_internal1): Likewise. (vsx_extract_mode_internal2): Likewise. (vsx_extract_mode_load): Likewise. (vsx_extract_mode_store): Likewise. (vsx_extract_mode_zero): Delete, big and little endian insns are combined into vsx_extract_mode_load. (vsx_extract_mode_one_le): Likewise. * doc/md.texi (PowerPC and IBM RS6000 constraints): Document wD constraint. * gcc.target/powerpc/vsx-extract-1.c: New test to test VSX vec_select optimizations. * gcc.target/powerpc/vsx-extract-2.c: Likewise. * gcc.target/powerpc/vsx-extract-3.c: Likewise. PR target/60672 * gcc.target/powerpc/pr60676.c: New file, make sure xxsldwi and xxpermdi builtins are supported. Backport from mainline 2013-08-01 Fabien Chêne fab...@gcc.gnu.org PR c++/54537 * include/tr1/cmath: Remove pow(double,double) overload, remove a duplicated comment about DR 550. Add a comment to explain the issue. * testsuite/tr1/8_c_compatibility/cmath/pow_cmath.cc: New. gcc/testsuite/ Back port from mainline 2013-08-01 Fabien Chêne fab...@gcc.gnu.org Peter Bergner berg...@vnet.ibm.com PR c++/54537 * g++.dg/overload/using3.C: New. * g++.dg/overload/using2.C: Adjust. * g++.dg/lookup/using9.C: Likewise. gcc/cp/ Back port from mainline 2013-08-01 Fabien Chêne fab...@gcc.gnu.org PR c++/54537 * cp-tree.h: Check OVL_USED with OVERLOAD_CHECK. * name-lookup.c (do_nonmember_using_decl): Make sure we have an OVERLOAD before calling OVL_USED. Call diagnose_name_conflict instead of issuing an error without mentioning the conflicting declaration. libgcc/ * config/rs6000/ibm-ldouble.c (pack_ldouble): New function. (__gcc_qadd): Use it. (__gcc_qmul): Likewise. (__gcc_qdiv): Likewise. (__gcc_qneg): Likewise. (__gcc_stoq): Likewise. (__gcc_dtoq): Likewise. Added: branches/ibm/gcc-4_8-branch/gcc/cp/ChangeLog.ibm branches/ibm/gcc-4_8-branch/gcc/testsuite/g++.dg/overload/using3.C branches/ibm/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/pr60676.c branches/ibm/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/vsx-extract-1.c branches/ibm/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/vsx-extract-2.c branches/ibm/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/vsx-extract-3.c branches/ibm/gcc-4_8-branch/libgcc/ChangeLog.ibm branches/ibm/gcc-4_8-branch/libstdc++-v3/testsuite/tr1/8_c_compatibility/cmath/pow_cmath.cc Modified: branches/ibm/gcc-4_8-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_8-branch/gcc/config/rs6000/constraints.md branches/ibm/gcc-4_8-branch/gcc/config/rs6000/predicates.md branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.c branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.h branches/ibm/gcc-4_8-branch/gcc/config/rs6000/vsx.md branches/ibm/gcc-4_8-branch/gcc/cp/cp-tree.h branches/ibm/gcc-4_8-branch/gcc/cp/name-lookup.c branches/ibm/gcc-4_8-branch/gcc/doc/md.texi branches/ibm/gcc-4_8-branch/gcc/testsuite/ChangeLog.ibm branches/ibm/gcc-4_8-branch/gcc/testsuite/g++.dg/lookup/using9.C branches/ibm/gcc-4_8-branch/gcc/testsuite/g++.dg/overload/using2.C
[Bug c++/54537] undiagnosed using-declaration conflicting with used function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54537 --- Comment #4 from Peter Bergner bergner at gcc dot gnu.org --- Author: bergner Date: Mon May 12 23:08:22 2014 New Revision: 210344 URL: http://gcc.gnu.org/viewcvs?rev=210344root=gccview=rev Log: Reapply the old IBM 4.8 branch patches that are not upstream. gcc/ Back port mainline subversion id 209025. 2014-04-02 Michael Meissner meiss...@linux.vnet.ibm.com PR target/60735 * config/rs6000/rs6000.c (rs6000_hard_regno_mode_ok): If we have software floating point or no floating point registers, do not allow any type in the FPRs. Eliminate a test for SPE SIMD types in GPRs that occurs after we tested for GPRs that would never be true. Back port from main line: 2014-03-27 Michael Meissner meiss...@linux.vnet.ibm.com * config/rs6000/constraints.md (wD constraint): New constraint to match the constant integer to get the top DImode/DFmode out of a vector in a VSX register. * config/rs6000/predicates.md (vsx_scalar_64bit): New predicate to match the constant integer to get the top DImode/DFmode out of a vector in a VSX register. * config/rs6000/rs6000.c (rs6000_debug_reg_global): If -mdebug=reg, print value of VECTOR_ELEMENT_SCALAR_64BIT. * config/rs6000/rs6000.h (VECTOR_ELEMENT_SCALAR_64BIT): Macro to define the top 64-bit vector element. * config/rs6000/vsx.md (vsx_extract_mode, V2DI/V2DF modes): Optimize vec_extract of 64-bit values, where the value being extracted is in the top word, where we can use scalar instructions. Add direct move and store support. Combine the big endian/little endian vector select load support into a single insn. (vsx_extract_mode_internal1): Likewise. (vsx_extract_mode_internal2): Likewise. (vsx_extract_mode_load): Likewise. (vsx_extract_mode_store): Likewise. (vsx_extract_mode_zero): Delete, big and little endian insns are combined into vsx_extract_mode_load. (vsx_extract_mode_one_le): Likewise. * doc/md.texi (PowerPC and IBM RS6000 constraints): Document wD constraint. * gcc.target/powerpc/vsx-extract-1.c: New test to test VSX vec_select optimizations. * gcc.target/powerpc/vsx-extract-2.c: Likewise. * gcc.target/powerpc/vsx-extract-3.c: Likewise. PR target/60672 * gcc.target/powerpc/pr60676.c: New file, make sure xxsldwi and xxpermdi builtins are supported. Backport from mainline 2013-08-01 Fabien Chêne fab...@gcc.gnu.org PR c++/54537 * include/tr1/cmath: Remove pow(double,double) overload, remove a duplicated comment about DR 550. Add a comment to explain the issue. * testsuite/tr1/8_c_compatibility/cmath/pow_cmath.cc: New. gcc/testsuite/ Back port from mainline 2013-08-01 Fabien Chêne fab...@gcc.gnu.org Peter Bergner berg...@vnet.ibm.com PR c++/54537 * g++.dg/overload/using3.C: New. * g++.dg/overload/using2.C: Adjust. * g++.dg/lookup/using9.C: Likewise. gcc/cp/ Back port from mainline 2013-08-01 Fabien Chêne fab...@gcc.gnu.org PR c++/54537 * cp-tree.h: Check OVL_USED with OVERLOAD_CHECK. * name-lookup.c (do_nonmember_using_decl): Make sure we have an OVERLOAD before calling OVL_USED. Call diagnose_name_conflict instead of issuing an error without mentioning the conflicting declaration. libgcc/ * config/rs6000/ibm-ldouble.c (pack_ldouble): New function. (__gcc_qadd): Use it. (__gcc_qmul): Likewise. (__gcc_qdiv): Likewise. (__gcc_qneg): Likewise. (__gcc_stoq): Likewise. (__gcc_dtoq): Likewise. Added: branches/ibm/gcc-4_8-branch/gcc/cp/ChangeLog.ibm branches/ibm/gcc-4_8-branch/gcc/testsuite/g++.dg/overload/using3.C branches/ibm/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/pr60676.c branches/ibm/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/vsx-extract-1.c branches/ibm/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/vsx-extract-2.c branches/ibm/gcc-4_8-branch/gcc/testsuite/gcc.target/powerpc/vsx-extract-3.c branches/ibm/gcc-4_8-branch/libgcc/ChangeLog.ibm branches/ibm/gcc-4_8-branch/libstdc++-v3/testsuite/tr1/8_c_compatibility/cmath/pow_cmath.cc Modified: branches/ibm/gcc-4_8-branch/gcc/ChangeLog.ibm branches/ibm/gcc-4_8-branch/gcc/config/rs6000/constraints.md branches/ibm/gcc-4_8-branch/gcc/config/rs6000/predicates.md branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.c branches/ibm/gcc-4_8-branch/gcc/config/rs6000/rs6000.h branches/ibm/gcc-4_8-branch/gcc/config/rs6000/vsx.md branches/ibm/gcc-4_8-branch/gcc/cp/cp-tree.h branches/ibm/gcc-4_8-branch/gcc/cp/name-lookup.c branches/ibm/gcc-4_8-branch/gcc/doc/md.texi branches/ibm/gcc-4_8-branch/gcc/testsuite/ChangeLog.ibm branches/ibm/gcc-4_8-branch/gcc/testsuite/g++.dg/lookup/using9.C branches/ibm/gcc-4_8-branch/gcc/testsuite/g++.dg/overload/using2.C
[Bug c++/61038] g++ -E is unusable with UDL strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61038 emsr at gcc dot gnu.org changed: What|Removed |Added Attachment #32783|0 |1 is obsolete|| --- Comment #10 from emsr at gcc dot gnu.org --- Created attachment 32787 -- https://gcc.gnu.org/bugzilla/attachment.cgi?id=32787action=edit In libcpp, is stringify_arg, test for user-defined literal strings and literal chars. libcpp/ 2014-05-12 Edward Smith-Rowland 3dw...@verizon.net PR c++/61038 * module.c (stringify_arg (cpp_reader *, macro_arg *)): Check for user-defined literal strings and user-defined literal chars to escape necessary characters.
[Bug c++/51577] dependent name lookup finds operator in global namespace
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51577 Richard Smith richard-gccbugzilla at metafoo dot co.uk changed: What|Removed |Added CC||richard-gccbugzilla@metafoo ||.co.uk --- Comment #8 from Richard Smith richard-gccbugzilla at metafoo dot co.uk --- *** Bug 61161 has been marked as a duplicate of this bug. ***
[Bug c++/61161] wrong two-stage name lookup for overloaded operators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61161 Richard Smith richard-gccbugzilla at metafoo dot co.uk changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from Richard Smith richard-gccbugzilla at metafoo dot co.uk --- (In reply to Jonathan Wakely from comment #1) Maybe related to PR51577 Thanks, I'm pretty sure it's the same thing, dup'ing. *** This bug has been marked as a duplicate of bug 51577 ***
[Bug c++/12944] [meta-bug] C++ name-lookup problems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12944 Bug 12944 depends on bug 61161, which changed state. Bug 61161 Summary: wrong two-stage name lookup for overloaded operators https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61161 What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE
[Bug c++/10437] using namespace at global scope creates incorrect code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10437 Richard Smith richard-gccbugzilla at metafoo dot co.uk changed: What|Removed |Added CC||richard-gccbugzilla@metafoo ||.co.uk --- Comment #11 from Richard Smith richard-gccbugzilla at metafoo dot co.uk --- (In reply to Nathan Sidwell from comment #9) Now the second point. This a case of SFINAE failure, no diagnostic should be issued. I disagree. The failure is not in the immediate context of the substitution, so this is a hard error. GCC seems to be doing the right thing in all cases here.
[Bug c/61144] Invalid optimizations for extern vars with local weak definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61144 --- Comment #15 from Rich Felker bugdal at aerifal dot cx --- Can you clarify? As far as I can tell, the other bug is a missed optimization and this is an overly-aggressive, incorrect optimization.
[Bug c/61162] New: possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
Bug ID: 61162
Summary: possibly bad error location with -Wc++-compat
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: tromey at gcc dot gnu.org
Consider this source:
enum e { ZERO = 0, ONE };
enum e e_val;
void f(void)
{
e_val = 0;
}
Compile with -Wc++-compat:
bapiya. gcc -Wc++-compat --syntax-only r.c
r.c: In function ‘f’:
r.c:7:3: warning: enum conversion in assignment is invalid in C++
[-Wc++-compat]
e_val = 0;
^
I think perhaps using the location of the = would be preferable.
[Bug c++/61163] New: Placement arguments shared between allocation and deallocation even when copies prohibited
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61163
Bug ID: 61163
Summary: Placement arguments shared between allocation and
deallocation even when copies prohibited
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: hstong at ca dot ibm.com
In N3290 subclause 5.3.4 [expr.new] paragraph 21, the leeway to reuse the same
copy of the initialized parameter for both the call to the allocation function
and the call to the deallocation function is prefaced with [i]f the
implementation is allowed to make a copy.
Since, in the case below, list initialization does not involve copying
following the call to the converting constructor, there is no copying to speak
of and the leeway is not given.
GCC performs the reuse anyway.
### SOURCE: cat gccListInitNewPlacement.cc
extern C int printf(const char *, ...);
struct A {
A(const A ) = delete;
A(A ) = delete;
A(int) : x(0) { printf(%s\n, __PRETTY_FUNCTION__); }
~A() { printf(%s\n, __PRETTY_FUNCTION__); }
int x;
};
struct B {
static void *operator new(decltype(sizeof(0)) sz, A a) {
printf(%d %s\n, a.x++, __PRETTY_FUNCTION__);
return ::operator new(sz);
}
static void operator delete(void *ptr, A a) {
printf(%d %s\n, a.x++, __PRETTY_FUNCTION__);
return ::operator delete(ptr);
}
B() { throw 0; }
};
int main() {
try { new ({0}) B; } catch(...) { }
}
### COMPILER INVOCATION: g++ -std=c++11 -pedantic-errors -Wall -Wextra
gccListInitNewPlacement.cc -o gccListInitNewPlacement
### OUTPUT FROM RESULTING BINARY: ./gccListInitNewPlacement
A::A(int)
0 static void* B::operator new(long unsigned int, A)
1 static void B::operator delete(void*, A)
A::~A()
### EXPECTED OUTPUT:
A::A(int)
0 static void* B::operator new(long unsigned int, A)
A::A(int)
0 static void B::operator delete(void*, A)
A::~A()
A::~A()
### VERSION INFO: g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-cygwin/4.8.2/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with:
/cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.2-3/src/gcc-4.8.2/configure
--srcdir=/cygdrive/i/szsz/tmpp/cygwin64/gcc/gcc-4.8.2-3/src/gcc-4.8.2
--prefix=/usr --exec-prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share --localstatedir=/var
--sysconfdir=/etc --libdir=/usr/lib --datarootdir=/usr/share
--docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
--build=x86_64-pc-cygwin --host=x86_64-pc-cygwin --target=x86_64-pc-cygwin
--without-libiconv-prefix --without-libintl-prefix --enable-shared
--enable-shared-libgcc --enable-static --enable-version-specific-runtime-libs
--enable-bootstrap --disable-__cxa_atexit --with-dwarf2 --with-tune=generic
--enable-languages=ada,c,c++,fortran,lto,objc,obj-c++ --enable-graphite
--enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm
--enable-libquadmath --enable-libquadmath-support --enable-libssp
--enable-libada --enable-libgcj-sublibs --disable-java-awt --disable-symvers
--with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld --with-gnu-as
--with-cloog-include=/usr/include/cloog-isl --without-libiconv-prefix
--without-libintl-prefix --with-system-zlib --libexecdir=/usr/lib
Thread model: posix
gcc version 4.8.2 (GCC)
[Bug libitm/61164] New: GCC 4.9.0 fails to build libitm with fortification enabled
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61164 Bug ID: 61164 Summary: GCC 4.9.0 fails to build libitm with fortification enabled Product: gcc Version: 4.9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libitm Assignee: unassigned at gcc dot gnu.org Reporter: rhill at gentoo dot org We enable -D_FORTIFY_SOURCE=2 by default, but with 4.9.0 we're encountering an error while building libitm. It can be reproduced without modifying the compiler by configuring with: CXXFLAGS=-O2 -g -D_FORTIFY_SOURCE=2 ../dist/gcc/gcc-4.9.0/configure --enable-languages=c,c++ --disable-werror --disable-bootstrap The error is: libtool: compile: /home/dirtyepic/build/./gcc/xg++ -B/home/dirtyepic/build/./gcc/ -nostdinc++ -nostdinc++ -I/home/dirtyepic/build/x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu -I/home/dirtyepic/build/x86_64-unknown-linux-gnu/libstdc++-v3/include -I/home/dirtyepic/dist/gcc/gcc-4.9.0/libstdc++-v3/libsupc++ -I/home/dirtyepic/dist/gcc/gcc-4.9.0/libstdc++-v3/include/backward -I/home/dirtyepic/dist/gcc/gcc-4.9.0/libstdc++-v3/testsuite/util -L/home/dirtyepic/build/x86_64-unknown-linux-gnu/libstdc++-v3/src -L/home/dirtyepic/build/x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs -L/home/dirtyepic/build/x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs -B/usr/local/x86_64-unknown-linux-gnu/bin/ -B/usr/local/x86_64-unknown-linux-gnu/lib/ -isystem /usr/local/x86_64-unknown-linux-gnu/include -isystem /usr/local/x86_64-unknown-linux-gnu/sys-include -DHAVE_CONFIG_H -I. -I../../../dist/gcc/gcc-4.9.0/libitm -I../../../dist/gcc/gcc-4.9.0/libitm/config/linux/x86 -I../../../dist/gcc/gcc-4.9.0/libitm/config/linux -I../../../dist/gcc/gcc-4.9.0/libitm/config/x86 -I../../../dist/gcc/gcc-4.9.0/libitm/config/posix -I../../../dist/gcc/gcc-4.9.0/libitm/config/generic -I../../../dist/gcc/gcc-4.9.0/libitm -mrtm -Wall -pthread -Werror -std=gnu++0x -funwind-tables -fno-exceptions -fno-rtti -fabi-version=4 -O2 -g -D_FORTIFY_SOURCE=2 -D_GNU_SOURCE -MT util.lo -MD -MP -MF .deps/util.Tpo -c ../../../dist/gcc/gcc-4.9.0/libitm/util.cc -fPIC -DPIC -o .libs/util.o In file included from /usr/include/stdio.h:937:0, from ../../../dist/gcc/gcc-4.9.0/libitm/util.cc:27: /usr/include/bits/stdio2.h: In function ‘void GTM::gtm_verror(const char*, __va_list_tag*)’: /usr/include/bits/stdio2.h:124:1: error: inlining failed in call to always_inline ‘int vfprintf(FILE*, const char*, __va_list_tag*)’: function body can be overwritten at link time vfprintf (FILE *__restrict __stream, ^ ../../../dist/gcc/gcc-4.9.0/libitm/util.cc:35:31: error: called from here vfprintf (stderr, fmt, list); ^ Comparing the preprocessor output for util.cc and a couple other C++ files that use vfprintf the most obvious difference is the declaration is missing __inline, ie. extern __attribute__((always_inline)) __attribute__ ((__gnu_inline__)) __attribute__ ((__artificial__)) int vfprintf instead of extern __inline __attribute__ ((__always_inline__)) __attribute__ ((__gnu_inline__)) __attribute__ ((__artificial__)) int vfprintf
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162 Marek Polacek mpolacek at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2014-05-13 CC||mpolacek at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |mpolacek at gcc dot gnu.org Target Milestone|--- |4.10.0 Ever confirmed|0 |1 --- Comment #1 from Marek Polacek mpolacek at gcc dot gnu.org --- Yep.
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162
--- Comment #2 from Tom Tromey tromey at gcc dot gnu.org ---
Note that it is also wrong for a conversion diagnosed
in a return:
enum e { ZERO = 0, ONE };
enum e f(void)
{
return 0;
}
barimba. gcc --syntax-only -Wc++-compat r.c
r.c: In function ‘f’:
r.c:5:3: warning: enum conversion in return is invalid in C++ [-Wc++-compat]
return 0;
^
I think it should point to the expression.
[Bug c/61162] possibly bad error location with -Wc++-compat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61162 --- Comment #3 from Marek Polacek mpolacek at gcc dot gnu.org --- I posted a patch, but the location for a return stmt will need more surgery than that.
