[Bug middle-end/61118] Spurious -Wclobbered warning generated by gcc 4.9.0 for pthread_cleanup_push

[tetra2005 at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61118

--- Comment #9 from Yuri Gribov  ---
(In reply to Tavian Barnes from comment #7)
> But this condition is not met:
> 
>> - They are changed between the setjmp() invocation and longjmp() call.

I think it is - __cancel_arg is assigned inside a while loop and can thus be
overwritten on successive iterations (compiler doesn't know that longjmp will
only be from the same iteration).

[Bug middle-end/80100] New: simplify-rtx.c sanitizer detects undefined behaviour with optimization

[zeccav at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80100

Bug ID: 80100
   Summary: simplify-rtx.c sanitizer detects undefined behaviour
with optimization
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeccav at gmail dot com
  Target Milestone: ---

//gcc 7.0.1 trunk 246252 undefined behaviour with optimization
//-O0 and -Og ok, higher levels get undefined
long int
f2 (long int k)
{
  return 2L | ((k - 1L) >> ((int) sizeof (long int) * __CHAR_BIT__ - 1));
}
//../../gcc-7-246252/gcc/simplify-rtx.c:2743:49: runtime error: left shift of 2
by 63 places cannot be represented in type 'long int'
//simplify-rtx.c:2743 is "HOST_WIDE_INT mask = INTVAL (trueop1) << count;

[Bug target/80101] New: ICE in store_data_bypass_p, at recog.c:3737

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80101

Bug ID: 80101
   Summary: ICE in store_data_bypass_p, at recog.c:3737
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: ppc64le-linux-gnu

Following test-case ICE with target compiler:

$ cat /tmp/tmpczflhfjq.i
int b;

void e();

int c ()
{
  struct
  {
int a[b];
  } d;
  if (d.a[0])
e ();
}

$ ppc64le-linux-gnu-gcc -mno-sched-epilog -Ofast -mcpu=power6
/tmp/tmpczflhfjq.i
/tmp/tmpczflhfjq.i: In function ‘c’:
/tmp/tmpczflhfjq.i:13:1: internal compiler error: in store_data_bypass_p, at
recog.c:3737
 }
 ^
0xadde35 store_data_bypass_p(rtx_insn*, rtx_insn*)
.././../gcc/recog.c:3737
0x1007635 internal_insn_latency
   
/home/marxin/BIG/buildbot/slave/gcc-master-build-ppc64le-weekend/build/builddir/gcc/insn-automata.c:121583
0x1007635 insn_latency(rtx_insn*, rtx_insn*)
   
/home/marxin/BIG/buildbot/slave/gcc-master-build-ppc64le-weekend/build/builddir/gcc/insn-automata.c:122092
0x1195b3a dep_cost_1(_dep*, unsigned int)
.././../gcc/haifa-sched.c:1484
0x119798e dep_cost(_dep*)
.././../gcc/haifa-sched.c:1506
0x119798e priority
.././../gcc/haifa-sched.c:1657
0x1197a7f set_priorities(rtx_insn*, rtx_insn*)
.././../gcc/haifa-sched.c:7195
0xb1992d compute_priorities()
.././../gcc/sched-rgn.c:3015
0xb1c60d schedule_region
.././../gcc/sched-rgn.c:3108
0xb1c60d schedule_insns()
.././../gcc/sched-rgn.c:3506
0xb1cd7d schedule_insns()
.././../gcc/sched-rgn.c:3491
0xb1cd7d rest_of_handle_sched2
.././../gcc/sched-rgn.c:3730
0xb1cd7d execute
.././../gcc/sched-rgn.c:3866

[Bug debug/80102] New: ICE in maybe_record_trace_start, at dwarf2cfi.c:2330

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80102

Bug ID: 80102
   Summary: ICE in maybe_record_trace_start, at dwarf2cfi.c:2330
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: ppc64le-linux-gnu

Following test-case ICE with cross-compiler:

$ cat /tmp/tmp8e87gxzu.ii
class b
{
public:
  float a;
  b (float c)
  {
for (int g; g < c;)
  ++a;
  }
};
class d
{
public:
  d (b);
};
main ()
{
  b (1.0);
  d e (0.0), f (1.0);
}

$ ppc64le-linux-gnu-g++ -fnon-call-exceptions -mminimal-toc -Os
/tmp/tmp8e87gxzu.ii
/tmp/tmp8e87gxzu.ii: In constructor ‘b::b(float)’:
/tmp/tmp8e87gxzu.ii:9:3: internal compiler error: in maybe_record_trace_start,
at dwarf2cfi.c:2330
   }
   ^
0x9b1c1b maybe_record_trace_start
.././../gcc/dwarf2cfi.c:2330
0x9b4058 scan_trace
.././../gcc/dwarf2cfi.c:2512
0x9b487a create_cfi_notes
.././../gcc/dwarf2cfi.c:2666
0x9b487a execute_dwarf2_frame
.././../gcc/dwarf2cfi.c:3024
0x9b487a execute
.././../gcc/dwarf2cfi.c:3504

[Bug target/80103] New: ICE in output_1144, at config/rs6000/vsx.md:2298

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80103

Bug ID: 80103
   Summary: ICE in output_1144, at config/rs6000/vsx.md:2298
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: ppc64le-linux-gnu

Following test-case ICE with cross compiler:

$ cat /tmp/tmpme3mc384.i
int a;
void b (__attribute__ ((__vector_size__ (16))) char c)
{
  a = ((__attribute__ ((__vector_size__ (2 * sizeof (long long) c)[0];
}

$ ppc64le-linux-gnu-gcc -mno-direct-move -Os -mpower9-dform-vector
/tmp/tmpme3mc384.i
/tmp/tmpme3mc384.i: In function ‘b’:
/tmp/tmpme3mc384.i:5:1: internal compiler error: in output_1144, at
config/rs6000/vsx.md:2298
 }
 ^
0x109b0a3 output_1144
.././../gcc/config/rs6000/vsx.md:2298
0x85c6c1 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
.././../gcc/final.c:2991
0x85d9b2 final(rtx_insn*, _IO_FILE*, int)
.././../gcc/final.c:2051
0x85debb rest_of_handle_final
.././../gcc/final.c:4489
0x85debb execute
.././../gcc/final.c:4562

[Bug fortran/79859] diagnostics: argument quoted twice in "No initializer for allocatable compoonent"

[fmarchal at perso dot be]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79859

Frederic Marchal  changed:

   What|Removed |Added

 CC||fmarchal at perso dot be

--- Comment #2 from Frederic Marchal  ---
(In reply to Manuel López-Ibáñez from comment #1)
> (In reply to Roland Illig from comment #0)
> > from fortran/primary.c:
> > 
> > if (!gfc_notify_std (GFC_STD_F2008, "No initializer for "
> >  "allocatable component '%qs' given in the "
> >  "structure constructor at %C", comp->name))
> > 
> > The single quotes around %qs are superfluous.
> 
> There may be quite a few of this or '%s'. Fortran didn't support %qs until
> very recently.

I think you are wrong. It isn't '%s' but '%qs'. It means quotes around a quoted
string i.e. double quoted string.

In English, the above message ends up as ''%s'' which might be acceptable.

In French, the above message shows up as '« %s »' which is unacceptable.

The quotes must be dropped around %qs in the source code located in function
build_actual_constructor() near fortran/primary.c:2672.

[Bug ipa/80104] New: ICE in initialize_argument_information, at calls.c:1748

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80104

Bug ID: 80104
   Summary: ICE in initialize_argument_information, at
calls.c:1748
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: s390x-linux-gnu

Following test-case fails with ICF with cross-compiler:

$ cat /tmp/tmpcy3o5icn.i
float
a (_Complex float b)
{
  return *&b;
}
float
c (_Complex float b)
{
  return (&b)[0];
}

$ s390x-linux-gnu-gcc -fipa-icf-functions /tmp/tmpcy3o5icn.i
/tmp/tmpcy3o5icn.i: In function ‘c’:
/tmp/tmpcy3o5icn.i:7:1: internal compiler error: in
initialize_argument_information, at calls.c:1748
 c (_Complex float b)
 ^
0x7089ad initialize_argument_information
.././../gcc/calls.c:1748
0x70a80b expand_call(tree_node*, rtx_def*, int)
.././../gcc/calls.c:3275
0x8280fc expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
.././../gcc/expr.c:10825
0x834685 store_expr_with_bounds(tree_node*, rtx_def*, int, bool, bool,
tree_node*)
.././../gcc/expr.c:5552
0x8360b0 expand_assignment(tree_node*, tree_node*, bool)
.././../gcc/expr.c:5321
0x71de0a expand_call_stmt
.././../gcc/cfgexpand.c:2656
0x71de0a expand_gimple_stmt_1
.././../gcc/cfgexpand.c:3571
0x71de0a expand_gimple_stmt
.././../gcc/cfgexpand.c:3737
0x720211 expand_gimple_tailcall
.././../gcc/cfgexpand.c:3784
0x720211 expand_gimple_basic_block
.././../gcc/cfgexpand.c:5721
0x725a76 execute
.././../gcc/cfgexpand.c:6357

It's probably mine.

[Bug fortran/50542] gfortran should detect violation of Fortran 95 R536 (r178939)

[zeccav at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50542

--- Comment #3 from Vittorio Zecca  ---
Still present in 7.0.1

[Bug tree-optimization/80105] New: [6/7 Regression] ICE in outer_projection_mupa, at graphite-sese-to-poly.c:1019

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80105

Bug ID: 80105
   Summary: [6/7 Regression] ICE in outer_projection_mupa, at
graphite-sese-to-poly.c:1019
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
 Build: x86_64-linux-gnu

Starting from r244305, we ICE on:

$ gfortran
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/graphite/pr42326.f90
-fgraphite-identity -O3 -fno-tree-dce -c

internal compiler error: in outer_projection_mupa, at
graphite-sese-to-poly.c:1019
0x1163b75 outer_projection_mupa
.././../gcc/graphite-sese-to-poly.c:1019
0x1163b75 add_loop_schedule
.././../gcc/graphite-sese-to-poly.c:1067
0x1164123 embed_in_surrounding_loops
.././../gcc/graphite-sese-to-poly.c:1141
0x11667ce build_original_schedule
.././../gcc/graphite-sese-to-poly.c:1181
0x11667ce build_poly_scop(scop*)
.././../gcc/graphite-sese-to-poly.c:1209
0x114fd2c graphite_transform_loops()
.././../gcc/graphite.c:320
0x1150300 graphite_transforms
.././../gcc/graphite.c:362
0x1150300 execute
.././../gcc/graphite.c:439

[Bug fortran/50538] formal argument cannot be same as procedure name in ENTRY

[zeccav at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50538

--- Comment #3 from Vittorio Zecca  ---
Still in 7.0.1

[Bug target/80106] New: ICE on an invalid code in tree_to_uhwi, at tree.c:7344

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80106

Bug ID: 80106
   Summary: ICE on an invalid code  in tree_to_uhwi, at
tree.c:7344
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: s390x-linux-gnu

Following test-case ICEs with cross compiler:

$ cat /tmp/tmpfiu2zypj.i
int *a;
int b = __builtin_s390_vec_load_bndry(a, b);

$ s390x-linux-gnu-gcc /tmp/tmpfiu2zypj.i
/tmp/tmpfiu2zypj.i:2:1: internal compiler error: in tree_to_uhwi, at
tree.c:7344
 int b = __builtin_s390_vec_load_bndry(a, b);
 ^~~
0xe08622 tree_to_uhwi(tree_node const*)
.././../gcc/tree.c:7344
0x6d061e s390_adjust_builtin_arglist
.././../gcc/config/s390/s390-c.c:679
0x6d061e s390_resolve_overloaded_builtin(unsigned int, tree_node*, void*)
.././../gcc/config/s390/s390-c.c:987
0x600875 c_build_function_call_vec(unsigned int, vec, tree_node*, vec*, vec*)
.././../gcc/c/c-typeck.c:3175
0x6284a9 c_parser_postfix_expression_after_primary
.././../gcc/c/c-parser.c:8437
0x616440 c_parser_postfix_expression
.././../gcc/c/c-parser.c:8250
0x621d2a c_parser_unary_expression
.././../gcc/c/c-parser.c:7064
0x622b37 c_parser_cast_expression
.././../gcc/c/c-parser.c:6893
0x622d52 c_parser_binary_expression
.././../gcc/c/c-parser.c:6702
0x623a35 c_parser_conditional_expression
.././../gcc/c/c-parser.c:6470
0x624190 c_parser_expr_no_commas
.././../gcc/c/c-parser.c:6387
0x62af2a c_parser_initializer
.././../gcc/c/c-parser.c:4363
0x6376be c_parser_declaration_or_fndef
.././../gcc/c/c-parser.c:1931
0x64007b c_parser_external_declaration
.././../gcc/c/c-parser.c:1469
0x640ad9 c_parser_translation_unit
.././../gcc/c/c-parser.c:1349
0x640ad9 c_parse_file()
.././../gcc/c/c-parser.c:18176
0x69f1a2 c_common_parse_file()
.././../gcc/c-family/c-opts.c:1107

[Bug fortran/50406] ld undefined reference to __MOD_str

[zeccav at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=50406

--- Comment #5 from Vittorio Zecca  ---
With 7.0.1 20170318 compiles links and executes correctly.

[Bug fortran/79859] diagnostics: argument quoted twice in "No initializer for allocatable compoonent"

[fmarchal at perso dot be]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79859

--- Comment #3 from Frederic Marchal  ---
My mistake, I simply removed the superfluous single quotes in the translated
message. Problem solved with the translation.

The original message is still doubly quoted in English though.

[Bug target/80107] New: ICE in final_scan_insn, at final.c:2964

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80107

Bug ID: 80107
   Summary: ICE in final_scan_insn, at final.c:2964
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: ppc64-linux-gnu

We ICE on following target with cross compiler:

$ ppc64-linux-gnu-gfortran
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/g77/f90-intrinsic-numeric.f
-mpower9-dform-vector -mno-gen-cell-microcode
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/g77/f90-intrinsic-numeric.f:204:0:

   end

Error: insn does not satisfy its constraints:
(insn 887 886 888 (set (reg:DI 77 0 [458])
(sign_extend:DI (reg:HI 78 1 [460])))
"/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/g77/f90-intrinsic-numeric.f":61
35 {*extendhidi2_noload}
 (nil))
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/g77/f90-intrinsic-numeric.f:204:0:
internal compiler error: in final_scan_insn, at final.c:2964
0xb6f198 _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
.././../gcc/rtl-error.c:108
0xb6f1bf _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
.././../gcc/rtl-error.c:119
0x8cb4ea final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
.././../gcc/final.c:2964
0x8cb722 final(rtx_insn*, _IO_FILE*, int)
.././../gcc/final.c:2051
0x8cbc2b rest_of_handle_final
.././../gcc/final.c:4489
0x8cbc2b execute
.././../gcc/final.c:4562

[Bug fortran/44265] Link error with reference to parameter array in specification expression

[zeccav at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44265

--- Comment #24 from Vittorio Zecca  ---
It works on my x86_64-pc-linux-gnu with gfortran 7.0.1

[Bug target/80108] New: ICE in aggregate_value_p at function.c:2028

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80108

Bug ID: 80108
   Summary: ICE in aggregate_value_p at function.c:2028
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: ppc64-linux-gnu

Following fortran test-case fails with cross compiler:

$ ppc64-linux-gnu-gfortran
/home/marxin/Programming/gcc/gcc/testsuite/gfortran.dg/streamio_11.f90 -m32
-mcpu=405 -mpower9-minmax -mfloat128-type

internal compiler error: Segmentation fault
0xbdc9ef crash_signal
.././../gcc/toplev.c:337
0x90c99a aggregate_value_p(tree_node const*, tree_node const*)
.././../gcc/function.c:2028
0x78aedf emit_library_call_value_1
.././../gcc/calls.c:4455
0x79156f emit_library_call_value(rtx_def*, rtx_def*, libcall_type,
machine_mode, int, ...)
.././../gcc/calls.c:5159
0x8b1a90 convert_move(rtx_def*, rtx_def*, int)
.././../gcc/expr.c:314
0x8b208d convert_modes(machine_mode, machine_mode, rtx_def*, int)
.././../gcc/expr.c:685
0xae4dc2 prepare_operand(insn_code, rtx_def*, int, machine_mode, machine_mode,
int)
.././../gcc/optabs.c:3963
0xae4fda prepare_cmp_insn
.././../gcc/optabs.c:3873
0xae5a35 emit_cmp_and_jump_insns(rtx_def*, rtx_def*, rtx_code, rtx_def*,
machine_mode, int, rtx_def*, int)
.././../gcc/optabs.c:4051
0x81aa5c do_compare_rtx_and_jump(rtx_def*, rtx_def*, rtx_code, int,
machine_mode, rtx_def*, rtx_code_label*, rtx_code_label*, int)
.././../gcc/dojump.c:1145
0x81b9d9 do_compare_and_jump
.././../gcc/dojump.c:1224
0x81d69b do_jump_1(tree_code, tree_node*, tree_node*, rtx_code_label*,
rtx_code_label*, int)
.././../gcc/dojump.c:253
0x7a3554 expand_gimple_cond
.././../gcc/cfgexpand.c:2479
0x7a3554 expand_gimple_basic_block
.././../gcc/cfgexpand.c:5612
0x7a7d46 execute
.././../gcc/cfgexpand.c:6357

[Bug fortran/79859] diagnostics: argument quoted twice in "No initializer for allocatable compoonent"

[lopezibanez at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79859

--- Comment #4 from Manuel López-Ibáñez  ---
When the original is changed, the translated strings will need to be
redone. Thus, it is always better to change the original first. This change
counts as obvious, you don't need approval or copyright assignment.

On 20 Mar 2017 8:43 a.m., "fmarchal at perso dot be" <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79859
>
> --- Comment #3 from Frederic Marchal  ---
> My mistake, I simply removed the superfluous single quotes in the
> translated
> message. Problem solved with the translation.
>
> The original message is still doubly quoted in English though.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug tree-optimization/80109] New: ICE in get_range_info, at tree-ssanames.c:375

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80109

Bug ID: 80109
   Summary: ICE in get_range_info, at tree-ssanames.c:375
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: mpolacek at gcc dot gnu.org, msebor at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: arm-linux-gnueabi

Running following test-case ICEs with cross compiler:

$ cat /tmp/tmpxgun9hqd.i
int a, c;
typedef struct
{
  int b;
} d;
int e ()
{
  int *f = &a;
  d *g = __builtin_alloca (f);
  for (;; c--)
g[c].b = e;
}

$ arm-linux-gnueabi-gcc -Os -Walloca-larger-than=126812070 /tmp/tmpxgun9hqd.i
/tmp/tmpxgun9hqd.i: In function ‘e’:
/tmp/tmpxgun9hqd.i:9:28: warning: passing argument 1 of ‘__builtin_alloca’
makes integer from pointer without a cast [-Wint-conversion]
   d *g = __builtin_alloca (f);
^
/tmp/tmpxgun9hqd.i:9:28: note: expected ‘unsigned int’ but argument is of type
‘int *’
/tmp/tmpxgun9hqd.i:11:12: warning: assignment makes integer from pointer
without a cast [-Wint-conversion]
 g[c].b = e;
^
/tmp/tmpxgun9hqd.i:6:5: internal compiler error: in get_range_info, at
tree-ssanames.c:375
 int e ()
 ^
0xd9e5d7 get_range_info(tree_node const*, generic_wide_int*,
generic_wide_int*)
.././../gcc/tree-ssanames.c:375
0x11e0e68 alloca_call_type
.././../gcc/gimple-ssa-warn-alloca.c:334
0x11e0e68 pass_walloca::execute(function*)
.././../gcc/gimple-ssa-warn-alloca.c:466

[Bug fortran/49630] [OOP] ICE on obsolescent deferred-length type bound character function

[zeccav at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49630

--- Comment #12 from Vittorio Zecca  ---
I am still having an ICE as in comment 11.
Opening a new bug.

[Bug c++/68045] [concepts] segfault in contains_struct_check ../../gcc/gcc/tree.h:2971

[zeccav at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68045

Vittorio Zecca  changed:

   What|Removed |Added

 CC||zeccav at gmail dot com

--- Comment #1 from Vittorio Zecca  ---
On gfortran 7.0.1 I having the same ICE:

  module abc
  implicit none
  type,abstract::abc_abstract
  contains
  procedure(abc_interface),deferred::abc_function
  end type abc_abstract
  type,extends(abc_abstract)::abc_type
  contains
  procedure::abc_function
  end type abc_type
  abstract interface
  function abc_interface(this)
   import abc_abstract
   class(abc_abstract),intent(in)::this
   character(len=*)::abc_interface
  end function abc_interface
  end interface
  contains
  function abc_function(this)
  class(abc_type),intent(in)::this
  character(len=5)::abc_function
  abc_function="hello"
  end function abc_function
  subroutine do_something(this)
  class(abc_abstract),intent(in)::this
  print *,this%abc_function()
  end subroutine do_something
  end module abc


gfortran gfbug111.f
gfbug111.f:30:0:

   print *,this%abc_function()

internal compiler error: Segmentation fault
0xba9c5f crash_signal
../../gcc-7-246252/gcc/toplev.c:337
0x716a88 contains_struct_check(tree_node*, tree_node_structure_enum, char
const*, int, char const*)
../../gcc-7-246252/gcc/tree.h:3177
0x716a88 gfc_get_character_type(int, gfc_charlen*)
../../gcc-7-246252/gcc/fortran/trans-types.c:1059
0x6c1073 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc-7-246252/gcc/fortran/trans-expr.c:6007
0x6c212a gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc-7-246252/gcc/fortran/trans-expr.c:7797
0x6ca242 gfc_conv_expr_reference(gfc_se*, gfc_expr*)
../../gcc-7-246252/gcc/fortran/trans-expr.c:7897
0x6f15d2 gfc_trans_transfer(gfc_code*)
../../gcc-7-246252/gcc/fortran/trans-io.c:2508
0x680de7 trans_code
../../gcc-7-246252/gcc/fortran/trans.c:2017
0x6ee252 build_dt
../../gcc-7-246252/gcc/fortran/trans-io.c:1986
0x680e07 trans_code
../../gcc-7-246252/gcc/fortran/trans.c:1989
0x6b2498 gfc_generate_function_code(gfc_namespace*)
../../gcc-7-246252/gcc/fortran/trans-decl.c:6332
0x685d59 gfc_generate_module_code(gfc_namespace*)
../../gcc-7-246252/gcc/fortran/trans.c:2195
0x6395fb translate_all_program_units
../../gcc-7-246252/gcc/fortran/parse.c:6061
0x6395fb gfc_parse_file()
../../gcc-7-246252/gcc/fortran/parse.c:6274
0x67cf6f gfc_be_parse_file
../../gcc-7-246252/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug sanitizer/80110] New: [6/7 Regression] error: statement marked for throw, but doesn’t w/ -fsanitize=thread

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80110

Bug ID: 80110
   Summary: [6/7 Regression] error: statement marked for throw,
but doesn’t w/ -fsanitize=thread
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, ramana at 
gcc dot gnu.org
  Target Milestone: ---

Hello.

Starting from r224118, we ICE on:

$ cat /tmp/tmpvu2iwxks.ii
struct a
{
  int b ();
  void
  c ()
  {
static int d = b ();
  }
};
void
f ()
{
  a e;
  e.c ();
}

$ g++ -fnon-call-exceptions -fsanitize=thread /tmp/tmpvu2iwxks.ii
/tmp/tmpvu2iwxks.ii: In member function ‘void a::c()’:
/tmp/tmpvu2iwxks.ii:5:3: error: statement marked for throw, but doesn’t
   c ()
   ^
# .MEM_6 = VDEF <.MEM_23>
_7 = __builtin___tsan_atomic8_load (&_ZGVZN1a1cEvE1d, 2);
/tmp/tmpvu2iwxks.ii:5:3: internal compiler error: verify_gimple failed
0xe39786 verify_gimple_in_cfg(function*, bool)
../../gcc/tree-cfg.c:5266
0xd1aed3 execute_function_todo
../../gcc/passes.c:1966
0xd1b805 execute_todo
../../gcc/passes.c:2016

[Bug target/80082] [5/6/7 regression] GCC incorrectly assumes Cortex-r[578] have 64-bit single-copy atomic LDRD

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80082

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|7.0 |5.5

--- Comment #5 from Richard Biener  ---
If backports were not yet released this would be a P1 (no known-to-work/fail
specified though...)

[Bug c++/80091] [6 Regression] gcc-6 branch segfaults while compiling firefox

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80091

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|6.3 |6.4

[Bug target/80082] [5/6/7 regression] GCC incorrectly assumes Cortex-r[578] have 64-bit single-copy atomic LDRD

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80082

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Assignee|ktkachov at gcc dot gnu.org|prakhar.bahuguna at arm 
dot com

--- Comment #6 from ktkachov at gcc dot gnu.org ---
I believe Prakhar is working on a fix

[Bug c++/80111] New: #include kills compiler

[graeme.winter at diamond dot ac.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80111

Bug ID: 80111
   Summary: #include  kills compiler
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: graeme.winter at diamond dot ac.uk
  Target Milestone: ---

Trivial code to reproduce


#include 
#include 

int main(int argc,
 char ** argv)
{
  std::cout << "Hello, World!" << std::endl;
  return 0;
}


g++ junk.cpp
In file included from junk.cpp:2:0:
/dls_sw/apps/gcc/6.3.0/include/c++/6.3.0/limits:1598:7: internal compiler
error: Illegal instruction
   min() _GLIBCXX_USE_NOEXCEPT { return __FLT_MIN__; }
   ^~~
0xac63df crash_signal
../.././gcc/toplev.c:333
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c++/80093] missed optimization opportunity with std::uniform_int_distribution

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80093

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-20
 CC||hubicka at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
With -O2 they are comparable.  With -O3 we inline more into bar while we inline
into a IPA-CPed clone of operator() in foo instead.

Not sure where the differences are exactly, -fdump-ipa-inline-details will
tell you ... ;)

[Bug c++/80111] #include kills compiler

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80111

--- Comment #1 from Andrew Pinski  ---
This usually means the gmp or mpfr library you are using is compiled not for
the machine you are using and compiled for a new processor.

[Bug c++/80111] #include kills compiler

[graeme.winter at diamond dot ac.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80111

--- Comment #2 from Graeme Winter  ---
Ah OK, thank you - I am using a GCC compiled by $SOMEONE_ELSE so this could
very well be the case...

[Bug rtl-optimization/80112] New: ICE in doloop_condition_get at loop-doloop.c:158

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80112

Bug ID: 80112
   Summary: ICE in doloop_condition_get at loop-doloop.c:158
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: aarch64-linux-gnu

Following test-case ICEs with cross-compiler:

$ cat /tmp/tmpqlv6dcz4.i

int a;
int b (int c)
{
  void *d[] = {&&e, &&f};
  switch (c)
{
f:
  c = 9;
case 9:
  goto *a++;
e:;
}
}

$ aarch64-linux-gnu-gcc -Os -fmodulo-sched /tmp/tmpqlv6dcz4.i
/tmp/tmpqlv6dcz4.i: In function ‘b’:
/tmp/tmpqlv6dcz4.i:13:1: internal compiler error: Segmentation fault
 }
 ^
0xb76b0f crash_signal
.././../gcc/toplev.c:337
0x11b1ad6 doloop_condition_get(rtx_insn*)
.././../gcc/loop-doloop.c:158
0x11bb961 doloop_register_get
.././../gcc/modulo-sched.c:353
0x11bdee0 doloop_register_get
.././../gcc/modulo-sched.c:349
0x11bdee0 sms_schedule
.././../gcc/modulo-sched.c:1457
0x11bdee0 execute
.././../gcc/modulo-sched.c:3339

[Bug c++/80095] [5/6/7 Regression] ICE with this pointer in NSDMI

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80095

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
Version|unknown |7.0.1
   Target Milestone|--- |5.5

[Bug tree-optimization/80113] New: [6/7 Regression] ICE in set_var_live_on_entry at tree-ssa-live.c:1018

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80113

Bug ID: 80113
   Summary: [6/7 Regression] ICE in set_var_live_on_entry at
tree-ssa-live.c:1018
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: gcc-bugzilla at gcc dot gnu.org
  Target Milestone: ---

Starting from r230200, there's valgrind error:

$ valgrind --leak-check=yes --trace-children=yes gcc
/home/marxin/Programming/gcc/gcc/testsuite/gcc.dg/graphite/pr42914.c
-fgraphite-identity -Ofast -fno-tree-coalesce-vars

==4715== Invalid read of size 8
==4715==at 0x77F17F: bitmap_find_bit (bitmap.c:506)
==4715==by 0x77F17F: bitmap_set_bit(bitmap_head*, int) (bitmap.c:600)
==4715==by 0xD44E82: set_var_live_on_entry (tree-ssa-live.c:1018)
==4715==by 0xD44E82: calculate_live_ranges(_var_map*, bool)
(tree-ssa-live.c:1136)
==4715==by 0xD22AEF: coalesce_ssa_name() (tree-ssa-coalesce.c:1862)
==4715==by 0xCB3103: remove_ssa_form (tree-outof-ssa.c:948)
==4715==by 0xCB3103: rewrite_out_of_ssa(ssaexpand*) (tree-outof-ssa.c:1172)
==4715==by 0x7C7F80: (anonymous namespace)::pass_expand::execute(function*)
(cfgexpand.c:6164)
==4715==by 0xB27D7D: execute_one_pass(opt_pass*) (passes.c:2465)
==4715==by 0xB28647: execute_pass_list_1(opt_pass*) (passes.c:2554)
==4715==by 0xB286A4: execute_pass_list(function*, opt_pass*)
(passes.c:2565)
==4715==by 0x7FBC8D: cgraph_node::expand() (cgraphunit.c:2038)
==4715==by 0x7FD63F: expand_all_functions (cgraphunit.c:2174)
==4715==by 0x7FD63F: symbol_table::compile() [clone .part.52]
(cgraphunit.c:2531)
==4715==by 0x7FFB54: compile (cgraphunit.c:2595)
==4715==by 0x7FFB54: symbol_table::finalize_compilation_unit()
(cgraphunit.c:2621)
==4715==by 0xC04D39: compile_file() (toplev.c:492)

[Bug tree-optimization/80105] [6/7 Regression] ICE in outer_projection_mupa, at graphite-sese-to-poly.c:1019

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80105

Richard Biener  changed:

   What|Removed |Added

 Depends on||69728
   Target Milestone|--- |6.4

--- Comment #1 from Richard Biener  ---
Possibly related to PR69728


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69728
[Bug 69728] [6/7 Regression] internal compiler error: in outer_projection_mupa,
at graphite-sese-to-poly.c:1175

[Bug rtl-optimization/80112] [5/6/7 Regression] ICE in doloop_condition_get at loop-doloop.c:158

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80112

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-20
 CC||ktkachov at gcc dot gnu.org
  Known to work||4.9.4
Summary|ICE in doloop_condition_get |[5/6/7 Regression] ICE in
   |at loop-doloop.c:158|doloop_condition_get at
   ||loop-doloop.c:158
 Ever confirmed|0   |1
  Known to fail||5.4.1, 6.3.1, 7.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed. 4.9 doesn't ICE for me

[Bug target/78857] S390: Do not use load-and-test floating-point instruction to compare against 0.0 as SNaN is converted to QNaN.

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78857

--- Comment #1 from Andreas Krebbel  ---
Author: krebbel
Date: Mon Mar 20 09:33:11 2017
New Revision: 246274

URL: https://gcc.gnu.org/viewcvs?rev=246274&root=gcc&view=rev
Log:
S/390: PR78857: Don't use load and test if result is live.

The FP load and test instruction should not be used for a comparison
if the target operand is being used afterwards.  It unfortunately
turns SNaNs into QNaNs.

gcc/ChangeLog:

2017-03-20  Andreas Krebbel  

PR target/78857
* config/s390/s390.md ("cmp_ccs_0"): Add a clobber of the
target operand.  A new splitter adds the clobber statement in case
the target operand is dead anyway.

gcc/testsuite/ChangeLog:

2017-03-20  Andreas Krebbel  

PR target/78857
* gcc.target/s390/load-and-test-fp-1.c: New test.
* gcc.target/s390/load-and-test-fp-2.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/s390/load-and-test-fp-1.c
trunk/gcc/testsuite/gcc.target/s390/load-and-test-fp-2.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/s390/s390.md
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/79483] [7 Regression] [graphite] ICE: verify_ssa failed (error: definition in block 31 does not dominate use in block 28)

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79483

--- Comment #4 from Martin Liška  ---
OK, I've got a new test-case that fails with ILS 0.18:

$ cat /tmp/tmpunyat_pa.i
int *a;
int b[];
int c;
void d ()
{
  double e[2][3] = {0.0, 0.0, 1.0};
  for (int f = 0; f < 2; ++f)
for (int g = 0; g < 6; ++g)
  b[0] = a[g] * e[f][2];
  c = b[0];
}

$ gcc -fgraphite-identity -O2 /tmp/tmpunyat_pa.i
/tmp/tmpunyat_pa.i:2:5: warning: array ‘b’ assumed to have one element
 int b[];
 ^
/tmp/tmpunyat_pa.i: In function ‘d’:
/tmp/tmpunyat_pa.i:4:6: error: definition in block 29 does not dominate use in
block 19
 void d ()
  ^
for SSA_NAME: pretmp_43 in statement:
prephitmp_33 = PHI <1.0e+0(14), pretmp_43(19)>
PHI argument
pretmp_43
for PHI node
prephitmp_33 = PHI <1.0e+0(14), pretmp_43(19)>
/tmp/tmpunyat_pa.i:4:6: internal compiler error: verify_ssa failed
0xe20ad3 verify_ssa(bool, bool)
../../gcc/tree-ssa.c:1184
0xd6ca25 verify_loop_closed_ssa(bool)
../../gcc/tree-ssa-loop-manip.c:736
0x1307a33 checking_verify_loop_closed_ssa
../../gcc/tree-ssa-loop-manip.h:37
0x1307a33 graphite_verify
../../gcc/graphite-isl-ast-to-gimple.c:82
0x1307a33 graphite_regenerate_ast_isl(scop*)
../../gcc/graphite-isl-ast-to-gimple.c:3040
0x12fe2d7 graphite_transform_loops()
../../gcc/graphite.c:330
0x12fe890 graphite_transforms
../../gcc/graphite.c:362
0x12fe890 execute
../../gcc/graphite.c:439

[Bug target/78857] S390: Do not use load-and-test floating-point instruction to compare against 0.0 as SNaN is converted to QNaN.

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78857

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Andreas Krebbel  ---
Fixed.

[Bug c++/80111] #include kills compiler

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80111

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Richard Biener  ---
Invalid.

[Bug target/79747] Missing documentation for -malign-{jumps,label,loops,functions}= and strange value range limitation

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79747

--- Comment #3 from Martin Liška  ---
(In reply to Martin Sebor from comment #2)
> I don't see -malign-functions in the latest manual.  -falign-functions is
> documented with an optional equals at the end.
> 
> $ (cd /src/gcc/trunk && grep align-functions= gcc/doc/*)
> grep: gcc/doc/include: Is a directory
> gcc/doc/invoke.texi:@itemx -falign-functions=@var{n}
> gcc/doc/invoke.texi:@option{-falign-functions=32} aligns functions to the
> next 32-byte
> gcc/doc/invoke.texi:boundary, but @option{-falign-functions=24} aligns to
> the next
> gcc/doc/invoke.texi:@option{-fno-align-functions} and
> @option{-falign-functions=1} are

Sure, -falign-functions is documented, by -malign-functions is not.

> 
> With today's trunk I get:
> 
> $ gcc  -Wall -Wextra -Wpedantic -Wrestrict -malign-functions -xc - <
> /dev/null
> xgcc: error: unrecognized command line option ‘-malign-functions’; did you
> mean ‘-falign-functions’?

Yes, you have to provide a value for -malign-functions option:

$ gcc  -Wall -Wextra -Wpedantic -Wrestrict -malign-functions=11 -xc - <
/dev/null
cc1: warning: -malign-functions is obsolete, use -falign-functions
cc1: error: -malign-functions=11 is not between 0 and 16

That means the option is not documented.

[Bug sanitizer/80110] [6/7 Regression] error: statement marked for throw, but doesn’t w/ -fsanitize=thread

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80110

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |6.4

[Bug tree-optimization/80113] [6/7 Regression] ICE in set_var_live_on_entry at tree-ssa-live.c:1018

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80113

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-20
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Target Milestone|--- |6.4
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.  I will have a look.

[Bug tree-optimization/79811] ICE verify_flow_info failed with -param vect-epilogues-nomask=1 and -mavx512vbmi

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79811

Martin Liška  changed:

   What|Removed |Added

 CC||rguenth at gcc dot gnu.org

--- Comment #2 from Martin Liška  ---
Yes, it was fixed by Richi's r245950. Is the patch real fix, or does it just
make the issue latent?

[Bug gcov-profile/80081] gcov-dump needs man page

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80081

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #3 from Martin Liška  ---
Good point, I'll do that.

[Bug ipa/79769] [CHKP] ICE in chkp_find_bounds_1 (Unexpected tree code complex_cst)

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79769

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Mon Mar 20 10:04:06 2017
New Revision: 246275

URL: https://gcc.gnu.org/viewcvs?rev=246275&root=gcc&view=rev
Log:
Fix *_CST ICEs connected to MPX.

2017-03-20  Martin Liska  

PR target/79769
PR target/79770
* tree-chkp.c (chkp_find_bounds_1): Handle REAL_CST,
COMPLEX_CST and VECTOR_CST.
2017-03-20  Martin Liska  

PR target/79769
PR target/79770
* g++.dg/pr79769.C: New test.
* gcc.target/i386/mpx/pr79770.c: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr79769.C
trunk/gcc/testsuite/gcc.target/i386/mpx/pr79770.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-chkp.c

[Bug c/79770] [CHKP] ICE in chkp_find_bounds_1 (chkp_find_bounds: Unexpected tree code vector_cst)

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79770

--- Comment #2 from Martin Liška  ---
Author: marxin
Date: Mon Mar 20 10:04:06 2017
New Revision: 246275

URL: https://gcc.gnu.org/viewcvs?rev=246275&root=gcc&view=rev
Log:
Fix *_CST ICEs connected to MPX.

2017-03-20  Martin Liska  

PR target/79769
PR target/79770
* tree-chkp.c (chkp_find_bounds_1): Handle REAL_CST,
COMPLEX_CST and VECTOR_CST.
2017-03-20  Martin Liska  

PR target/79769
PR target/79770
* g++.dg/pr79769.C: New test.
* gcc.target/i386/mpx/pr79770.c: New test.

Added:
trunk/gcc/testsuite/g++.dg/pr79769.C
trunk/gcc/testsuite/gcc.target/i386/mpx/pr79770.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-chkp.c

[Bug c/79770] [CHKP] ICE in chkp_find_bounds_1 (chkp_find_bounds: Unexpected tree code vector_cst)

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79770

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-20
  Known to work||7.0
 Ever confirmed|0   |1

--- Comment #3 from Martin Liška  ---
Fixed on trunk so far.

[Bug ipa/79769] [CHKP] ICE in chkp_find_bounds_1 (Unexpected tree code complex_cst)

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79769

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed|2017-03-01 00:00:00 |2017-03-20
  Known to work||7.0
 Ever confirmed|0   |1
  Known to fail|7.0 |

--- Comment #3 from Martin Liška  ---
Fixed on trunk so far.

[Bug middle-end/79753] [7 Regression][CHKP] ICE in ix86_expand_builtin, at config/i386/i386.c:36869

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79753

--- Comment #7 from Martin Liška  ---
Author: marxin
Date: Mon Mar 20 10:06:00 2017
New Revision: 246276

URL: https://gcc.gnu.org/viewcvs?rev=246276&root=gcc&view=rev
Log:
MPX: fix PR middle-end/79753

2017-03-20  Martin Liska  

PR middle-end/79753
* tree-chkp.c (chkp_build_returned_bound): Do not build
returned bounds for a LHS that's not a BOUNDED_P type.
2017-03-20  Martin Liska  

PR middle-end/79753
* gcc.target/i386/mpx/pr79753.c: New test.

Added:
trunk/gcc/testsuite/gcc.target/i386/mpx/pr79753.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/tree-chkp.c

[Bug middle-end/79753] [7 Regression][CHKP] ICE in ix86_expand_builtin, at config/i386/i386.c:36869

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79753

Martin Liška  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Known to work||7.0

--- Comment #8 from Martin Liška  ---
Fixed on trunk so far.

[Bug tree-optimization/80113] [6/7 Regression] ICE in set_var_live_on_entry at tree-ssa-live.c:1018

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80113

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #2 from Richard Biener  ---
Ok, so it looks like this can happen for all not released SSA names given
that then may point to dead (and GCed) stmts which may point to BBs that
no longer exist.  Because we do

1802  /* If this optimization is disabled, we need to coalesce all the
1803 names originating from the same SSA_NAME_VAR so debug info
1804 remains undisturbed.  */
1805  if (!flag_tree_coalesce_vars)
1806{
(gdb) l
1807  hash_table ssa_name_hash (10);
1808
1809  FOR_EACH_SSA_NAME (i, a, cfun)
1810{
1811  if (SSA_NAME_VAR (a)
1812  && !DECL_IGNORED_P (SSA_NAME_VAR (a))
1813  && (!has_zero_uses (a) || !SSA_NAME_IS_DEFAULT_DEF (a)
1814  || !VAR_P (SSA_NAME_VAR (a
1815{

and in this case the SSA name is not a default def.

The extra oddity with this case is that the def is a PHI which still has
a BB assigned.  Ah this is because graphite doing

  gphi *new_phi = create_phi_node (SSA_NAME_VAR (res), new_bb);
  tree new_res = create_new_def_for (res, new_phi,
 gimple_phi_result_ptr (new_phi));
  set_rename (res, new_res);

which is ... eh?   Not sure what they are trying to do here...

[Bug tree-optimization/79811] ICE verify_flow_info failed with -param vect-epilogues-nomask=1 and -mavx512vbmi

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79811

Richard Biener  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Richard Biener  ---
Yes, it's the real fix.

[Bug tree-optimization/80109] ICE in get_range_info, at tree-ssanames.c:375

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80109

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-20
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed with a cross.

[Bug ipa/80104] ICE in initialize_argument_information, at calls.c:1748

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80104

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 CC||hubicka at ucw dot cz
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Problem is that we produce a thunk which has an invisible reference type of an
argument. Optimized tree dumps looks as follows:

;; Function c (c, funcdef_no=3, decl_uid=2001, cgraph_uid=1, symbol_order=1)

c (complex float b)
{
  complex float arg.1;
  float retval.0;

   [100.00%]:
  arg.1_2 = b;
  retval.0_4 = a (arg.1_2); [tail call]
  return retval.0_4;

}

Problem is that without any optimization level, arg.1_2 isn't a default def.
Following patch can fix that, but I'm not sure whether it's OK, or it's more a
workaround?

diff --git a/gcc/calls.c b/gcc/calls.c
index 61caf4ca752..404f9e303b7 100644
--- a/gcc/calls.c
+++ b/gcc/calls.c
@@ -1745,8 +1745,15 @@ initialize_argument_information (int num_actuals
ATTRIBUTE_UNUSED,
 address.  */
  if (TREE_CODE (args[i].tree_value) == SSA_NAME)
{
- gcc_assert (SSA_NAME_IS_DEFAULT_DEF (args[i].tree_value));
- args[i].tree_value = SSA_NAME_VAR (args[i].tree_value);
+  if (SSA_NAME_IS_DEFAULT_DEF (args[i].tree_value))
+   args[i].tree_value = SSA_NAME_VAR (args[i].tree_value);
+ else
+ {
+   gimple *g = SSA_NAME_DEF_STMT (args[i].tree_value);
+   if (gimple_assign_single_p (g))
+ args[i].tree_value = gimple_assign_rhs1 (g);
+ }
+
  gcc_assert (TREE_CODE (args[i].tree_value) == PARM_DECL);
}
  /* Argument setup code may have copied the value to register.  We

[Bug sanitizer/80114] New: asan-stack=1 with -fsanitize-address-use-after-scope and stack arrays multiplies code size

[jani.nikula at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80114

Bug ID: 80114
   Summary: asan-stack=1 with -fsanitize-address-use-after-scope
and stack arrays multiplies code size
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jani.nikula at intel dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
  Target Milestone: ---

Compiling

int main(void)
{
volatile int i = (const int []){0, 1, 2, 3, 4, 5}[1];
const int j = (const int []){0, 1, 2, 3, 4, 5}[i];
return j;
}

with --param asan-stack=1 and -fsanitize-address-use-after-scope doubles
generated code size. Compared to to the very tightly optimized non-asan code
size, this seems pretty bad. Is this to be expected?

Comparison: https://godbolt.org/g/hgS817

[Bug middle-end/67338] fold-const sanitizer runtime error in roundup_loc

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67338

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-20
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Created attachment 41001
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41001&action=edit
gcc7-pr67338.patch

Untested fix.

[Bug c/80097] internal compiler error in c_fully_fold_internal with std=c89 and -fsanitize=float-divide-by-zero

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80097

--- Comment #5 from Jakub Jelinek  ---
Created attachment 41002
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41002&action=edit
gcc7-pr80097.patch

Untested fix.

[Bug target/80115] New: [7 Regression] OpenJDK 1.8 fails to build

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80115

Bug ID: 80115
   Summary: [7 Regression] OpenJDK 1.8 fails to build
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---
Target: i?86-*-*

g++-7 /tmp/defNewGeneration.ii -S -m32 -O2 -w
/home/abuild/rpmbuild/BUILD/icedtea-3.3.0/openjdk-boot/hotspot/src/share/vm/memory/defNewGeneration.cpp:
In member function ‘virtual void DefNewGeneration::collect(bool, bool, size_t,
bool)’:
/home/abuild/rpmbuild/BUILD/icedtea-3.3.0/openjdk-boot/hotspot/src/share/vm/memory/defNewGeneration.cpp:731:1:
error: unsupported size for integer register

#1  0x015a3fa9 in print_reg (x=0x7fffee20f180, code=0, file=0x2b9fbf0)
at /space/rguenther/src/svn/gcc-7-branch/gcc/config/i386/i386.c:17667
17667   error ("unsupported size for integer register");
(gdb) l
17662 break;
17663   case 1:
17664 if (regno >= ARRAY_SIZE (qi_reg_name))
17665   goto normal;
17666 if (!ANY_QI_REGNO_P (regno))
17667   error ("unsupported size for integer register");
(gdb) p regno
$1 = 4
(gdb) p qi_reg_name[4]
$3 = 0x1f26494 "sil"

the asm in question is

(insn:TI 14 734 15 2 (parallel [
(asm_operands/v ("990: nop
.pushsection .note.stapsdt,"?","note"
.balign 4
.4byte 992f-991f,994f-993f,3
991: .asciz "stapsdt"
992: .balign 4
993: .4byte 990b
.4byte _.stapsdt.base
.4byte 0
.asciz "hotspot"
.asciz "gc__collection__defnew__begin"
.asciz "%n0@%1 %n2@%3 %n4@%5 %n6@%7"
994: .balign 4
.popsection
") ("") 0 [
(const_int -1 [0x])
(reg:QI 0 ax [orig:200 full ] [200])
(const_int -1 [0x])
(reg:QI 2 cx [orig:202 clear_all_soft_refs ] [202])
(const_int -4 [0xfffc])
(mem/c:SI (plus:SI (reg/f:SI 6 bp)
(const_int 20 [0x14])) [3 size+0 S4 A32])
(const_int -1 [0x])
(reg:QI 4 si [orig:205 is_tlab ] [205])
]
 [
(asm_input:SI ("n")
/home/abuild/rpmbuild/BUILD/icedtea-3.3.0/openjdk-boot/hotspot/src/share/vm/memory/defNewGeneration.cpp:571)
(asm_input:QI ("nor")
/home/abuild/rpmbuild/BUILD/icedtea-3.3.0/openjdk-boot/hotspot/src/share/vm/memory/defNewGeneration.cpp:571)
(asm_input:SI ("n")
/home/abuild/rpmbuild/BUILD/icedtea-3.3.0/openjdk-boot/hotspot/src/share/vm/memory/defNewGeneration.cpp:571)
(asm_input:QI ("nor")
/home/abuild/rpmbuild/BUILD/icedtea-3.3.0/openjdk-boot/hotspot/src/share/vm/memory/defNewGeneration.cpp:571)
(asm_input:SI ("n")
/home/abuild/rpmbuild/BUILD/icedtea-3.3.0/openjdk-boot/hotspot/src/share/vm/memory/defNewGeneration.cpp:571)
(asm_input:SI ("nor")
/home/abuild/rpmbuild/BUILD/icedtea-3.3.0/openjdk-boot/hotspot/src/share/vm/memory/defNewGeneration.cpp:571)
(asm_input:SI ("n")
/home/abuild/rpmbuild/BUILD/icedtea-3.3.0/openjdk-boot/hotspot/src/share/vm/memory/defNewGeneration.cpp:571)
(asm_input:QI ("nor")
/home/abuild/rpmbuild/BUILD/icedtea-3.3.0/openjdk-boot/hotspot/src/share/vm/memory/defNewGeneration.cpp:571)
]
 []
/home/abuild/rpmbuild/BUILD/icedtea-3.3.0/openjdk-boot/hotspot/src/share/vm/memory/defNewGeneration.cpp:571)
(clobber (reg:CCFP 18 fpsr))
(clobber (reg:CC 17 flags))
])
"/home/abuild/rpmbuild/BUILD/icedtea-3.3.0/openjdk-boot/hotspot/src/share/vm/memory/defNewGeneration.cpp":571
-1
 (expr_list:REG_DEAD (reg:QI 4 si [orig:205 is_tlab ] [205])
(expr_list:REG_DEAD (reg:QI 2 cx [orig:202 clear_all_soft_refs ] [202])
(expr_list:REG_DEAD (reg:QI 0 ax [orig:200 full ] [200])
(expr_list:REG_UNUSED (reg:CCFP 18 fpsr)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil)))

note that it builds successfully with -O1 or -O0.  The same issue happens
in multiple places in OpenJDK 1.8 and stems from their HS_DTRACE_PROBE4
macro expansion which eventually expands to STAP_PROBE4 / _SDT_PROBE which
is defined as

# 33 "/usr/include/sys/sdt.h" 3 4
#define _SDT_PROBE(provider,name,n,arglist) do { __asm__ __volatile__
(_SDT_ASM_BODY(provider, name, _SDT_ASM_ARGS, (n)) :: _SDT_ASM_OPERANDS_ ##n
arglist); __asm__ __volatile__ (_SDT_ASM_BASE); } while (0)

and

#define _SDT_ASM_OPERANDS_4(arg1,arg2,arg3,arg4) _SDT_ASM_OPERANDS_3(arg1,
arg2, arg3), _SDT_ARG(4, arg4)

(ick, all heavily macroized stuff)

#define _SDT_ARG(n,x) [_SDT_S ##n] "n" ((_SDT_ARGSIGNED (x) ? 1 : -1) * (int)
_SDT_ARG

[Bug target/80115] [7 Regression] OpenJDK 1.8 fails to build

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80115

--- Comment #1 from Richard Biener  ---
Created attachment 41003
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41003&action=edit
unreduced testcase

[Bug target/80115] [7 Regression] OpenJDK 1.8 fails to build

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80115

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |7.0

[Bug bootstrap/28561] Broken dependencies

[reichelt at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28561

Volker Reichelt  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #2 from Volker Reichelt  ---
This is not an issue anymore.

[Bug sanitizer/80114] asan-stack=1 with -fsanitize-address-use-after-scope and stack arrays multiplies code size

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80114

--- Comment #1 from Richard Biener  ---
I see, with -O2 and your options:

main:
.LFB0:
.cfi_startproc
movl$1, -4(%rsp)
movslq  -4(%rsp), %rax
movl._1(,%rax,4), %eax
ret

which is the same as without.  Similar for using GCC instead of G++.

[Bug tree-optimization/77498] [7 regression] Performance drop after r239414 on spec2000/172mgrid

[thopre01 at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77498

--- Comment #9 from Thomas Preud'homme  ---
Sadly I could not come up with a minimal testcase so far. What I can see from
the code is that tree code hoisting increases the live range of some values
which then translates into more spilling in reload.

As an approximation I'm wondering if the maximum distance (computer in number
of blocks traversed) from the definition to the use could be used to limit when
the optimization is applied when optimizing for speed.

[Bug c++/80029] [6/7 Regression] valgrind error in new_omp_context(omp_region_type) (gimplify.c:400)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80029

Jakub Jelinek  changed:

   What|Removed |Added

 CC||cesar at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
That doesn't work, it is too early.
With:
--- gimplify.c.jj   2017-03-08 18:19:24.0 +0100
+++ gimplify.c  2017-03-20 07:22:05.587913531 +0100
@@ -9261,6 +9261,8 @@ gimplify_oacc_declare (tree *expr_p, gim
   omp_add_variable (gimplify_omp_ctxp, decl, GOVD_SEEN);
 }

+  gimplify_adjust_omp_clauses (pre_p, NULL, &clauses, OACC_DECLARE);
+
   stmt = gimple_build_omp_target (NULL, GF_OMP_TARGET_KIND_OACC_DECLARE,
  clauses);

we don't ICE on it, but still no idea what is the right thing to do.
>From what I understand, #pragma acc declare is active for all code from the
directive till end of function (unless the variables mentioned in its clauses
go out of scope earlier), so in theory perhaps the right thing is to move the
gimplify omp context structure up in the gimplify context tree so that they are
just children of the function (what happens if you put #pragma acc declare
inside
the body of some other acc region?).
Though on the other side, e.g. for #pragma omp target enter data we adjust the
omp clauses right away, but that doesn't really affect the handling of
variables later on.  So, the important question is do you need the variables
mentioned in acc declare clauses to be in the hash tables as GOMP_MAP after
gimplify_oacc_declare returns or not?  If not, then the above patch might DTRT,
otherwise we need to figure out something different.

[Bug tree-optimization/77498] [7 regression] Performance drop after r239414 on spec2000/172mgrid

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77498

--- Comment #10 from rguenther at suse dot de  ---
On Mon, 20 Mar 2017, thopre01 at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77498
> 
> --- Comment #9 from Thomas Preud'homme  ---
> Sadly I could not come up with a minimal testcase so far. What I can see from
> the code is that tree code hoisting increases the live range of some values
> which then translates into more spilling in reload.
> 
> As an approximation I'm wondering if the maximum distance (computer in number
> of blocks traversed) from the definition to the use could be used to limit 
> when
> the optimization is applied when optimizing for speed.

Sadly the data-flow used to compute the opportunities is not suitable
for determining this.  It would probaly require "aging" of exprs in
the hoistable sets when propagating the dataflow for ANTIC_IN (in
principle PRE would have a similar issue).  We already restrict
"distance" by requiring at least one successor of the hoisting point
to provide the value directly but we do not limit proximity further.

See do_hoist_insertion.

[Bug target/80115] [7 Regression] OpenJDK 1.8 fails to build

[trippels at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80115

Markus Trippelsdorf  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-20
 CC||trippels at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Markus Trippelsdorf  ---
struct A {
  void m_fn1();
  void m_fn2(bool, bool);
};
void A::m_fn2(bool p1, bool p2) {
  m_fn1();
  __asm__(
  ".asciz \"%n[_SDT_S1]@%[_SDT_A1] @%[_SDT_A2] @%[_SDT_A3] @%[_SDT_A4]\""
::
  [_SDT_S1] "n"(0),
  [_SDT_A1] "n"(0), [_SDT_A2] "nor"(p1), [_SDT_A3] "n"(0),
  [_SDT_A4] "nor"(p2));
}

[Bug fortran/80010] diagnostics: typo $!

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80010

Jakub Jelinek  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Jakub Jelinek  ---
Fixed.

[Bug sanitizer/80114] asan-stack=1 with -fsanitize-address-use-after-scope and stack arrays multiplies code size

[marxin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80114

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2017-03-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Liška  ---
Well, just adding the param and -fsanitize-address-use-after-scope does not
enable any sanitization. One has to add -fsanitize=address to trigger real
sanitization. With Address Sanitizer, the code really grows, which is kind of
expected.

[Bug c++/80095] [5/6/7 Regression] ICE with this pointer in NSDMI

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80095

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-20
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Another case of PLACEHOLDER_EXPR leaking into the gimplifier.  I'll have a stab
at this, too.

[Bug c++/80095] [5/6/7 Regression] ICE with this pointer in NSDMI

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80095

--- Comment #2 from Marek Polacek  ---
commit 39786c804b3d3927f800bf8834ad849138d06136
Author: jason 
Date:   Fri Dec 12 03:48:55 2014 +

PR c++/57510
* typeck2.c (split_nonconstant_init_1): Handle arrays here.
(store_init_value): Not here.
(split_nonconstant_init): Look through TARGET_EXPR.  No longer
static.
* cp-tree.h: Declare split_nonconstant_init.
* call.c (set_up_extended_ref_temp): Use split_nonconstant_init.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@218653
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c++/80096] [c++1z] ICE with auto template parameter

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80096

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-03-20
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed.

[Bug c++/80096] [c++1z] ICE with auto template parameter

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80096

--- Comment #2 from Marek Polacek  ---
commit b1363399fad470a536bd8731be39c3fbfe4e6fad
Author: jason 
Date:   Wed Nov 9 20:02:50 2016 +

Implement P0127R2, Declaring non-type parameters with auto.

gcc/cp/
* cp-tree.h (enum auto_deduction_context): Add adc_unify.
* decl.c (grokdeclarator): Allow 'auto' in C++17 template non-type
parameter types.
* pt.c (do_auto_deduction): Add outer_targs parameter.
(convert_template_argument): Call do_auto_deduction.  If adc_unify,
don't give up on dependent init.
(unify): Likewise.  In C++17, walk into the type of a
TEMPLATE_PARM_INDEX.
(for_each_template_parm): Add any_fn parameter.
(struct pair_fn_data): Likewise.
(for_each_template_parm_r): Call it for any tree.  In C++17, walk
into the type of a TEMPLATE_PARM_INDEX.
(zero_r, array_deduction_r, try_array_deduction): New.
(type_unification_real): Call try_array_deduction.
(get_partial_spec_bindings): Likewise.
gcc/c-family/
* c-cppbuiltin.c (c_cpp_builtins): Define __cpp_template_auto.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@242017
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug c++/80096] [7 Regression] [c++1z] ICE with auto template parameter

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80096

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |7.0
Summary|[c++1z] ICE with auto   |[7 Regression] [c++1z] ICE
   |template parameter  |with auto template
   ||parameter

[Bug c++/80096] [7 Regression] [c++1z] ICE with auto template parameter

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80096

--- Comment #3 from Marek Polacek  ---
G++ 6:
w.C:1:10: error: ‘auto’ parameter not permitted in this context
 template struct A
  ^~~~
w.C:6:4: note: invalid template non-type parameter
 A<0> a;
^

[Bug tree-optimization/80105] [6/7 Regression] ICE in outer_projection_mupa, at graphite-sese-to-poly.c:1019

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80105

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||law at redhat dot com

[Bug plugins/80094] GCC plugin hash table corruption on hash table expansion (>10 plugins) on GCC 4.5+

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80094

--- Comment #3 from Richard Biener  ---
(In reply to Brad Spengler from comment #2)
> I've added an alternative fix at
> https://grsecurity.net/~spender/plugin_hash_fix2.diff
> 
> It's a bit smaller/cleaner and should fit in better with the existing code
> style.  Untested, but I believe it will work.
> 
> -Brad

Looks good, please send patches to gcc-patc...@gcc.gnu.org

[Bug sanitizer/80063] gcc/asan.c: PVS-Studio: Incorrect Block Delimitation (CWE-483)

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80063

--- Comment #3 from Marek Polacek  ---
Guess we should
--- a/gcc/asan.c
+++ b/gcc/asan.c
@@ -2566,11 +2566,12 @@ initialize_sanitizer_builtins (void)
 #undef DEF_BUILTIN_STUB
 #define DEF_BUILTIN_STUB(ENUM, NAME)
 #undef DEF_SANITIZER_BUILTIN
-#define DEF_SANITIZER_BUILTIN(ENUM, NAME, TYPE, ATTRS) \
+#define DEF_SANITIZER_BUILTIN(ENUM, NAME, TYPE, ATTRS) do {\
   decl = add_builtin_function ("__builtin_" NAME, TYPE, ENUM,  \
   BUILT_IN_NORMAL, NAME, NULL_TREE);   \
   set_call_expr_flags (decl, ATTRS);   \
-  set_builtin_decl (ENUM, decl, true);
+  set_builtin_decl (ENUM, decl, true); \
+} while (0);

 #include "sanitizer.def"

[Bug sanitizer/80114] asan-stack=1 with -fsanitize-address-use-after-scope and stack arrays multiplies code size

[jani.nikula at intel dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80114

--- Comment #3 from Jani Nikula  ---
(In reply to Martin Liška from comment #2)
> Well, just adding the param and -fsanitize-address-use-after-scope does not
> enable any sanitization. One has to add -fsanitize=address to trigger real
> sanitization. With Address Sanitizer, the code really grows, which is kind
> of expected.

Yes, of course. The full options (in the godbolt link) are: -O2 -std=c11 -x c
-fsanitize=kernel-address -fasan-shadow-offset=0xdfff9000 --param
asan-stack=1 --param asan-globals=1 --param
asan-instrumentation-with-call-threshold=1
-fsanitize-address-use-after-scope

I fully expect asan to grow code; I'm just not sure whether such a huge growth
particularly with the combination of --param asan-stack=1 and
-fsanitize-address-use-after-scope is expected.

[Bug tree-optimization/80113] [6/7 Regression] ICE in set_var_live_on_entry at tree-ssa-live.c:1018

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80113

--- Comment #3 from Richard Biener  ---
Author: rguenth
Date: Mon Mar 20 13:06:58 2017
New Revision: 246277

URL: https://gcc.gnu.org/viewcvs?rev=246277&root=gcc&view=rev
Log:
2017-03-20  Richard Biener  

PR tree-optimization/80113
* graphite-isl-ast-to-gimple.c (copy_loop_phi_nodes): Do not
allocate extra SSA name for PHI def.
(add_close_phis_to_outer_loops): Likewise.
(add_close_phis_to_merge_points): Likewise.
(copy_loop_close_phi_args): Likewise.
(copy_cond_phi_nodes): Likewise.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/graphite-isl-ast-to-gimple.c

[Bug target/80115] [7 Regression] OpenJDK 1.8 fails to build

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80115

--- Comment #3 from Richard Biener  ---
This is from systemtap 3.0, didn't try with 3.1 which seems to be available
since a few weeks.

[Bug sanitizer/80063] gcc/asan.c: PVS-Studio: Incorrect Block Delimitation (CWE-483)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80063

--- Comment #4 from Jakub Jelinek  ---
Please reformat it properly:
#define DEF_SANITIZER_BUILTIN(ENUM, NAME, TYPE, ATTRS) \
  do {  \
decl = add_builtin_function ("__builtin_" NAME, TYPE, ENUM, \
 BUILT_IN_NORMAL, NAME, NULL_TREE); \
set_call_expr_flags (decl, ATTRS);  \
set_builtin_decl (ENUM, decl, true);\
  } while (0);
Ok with that change.

[Bug sanitizer/80063] gcc/asan.c: PVS-Studio: Incorrect Block Delimitation (CWE-483)

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80063

--- Comment #5 from Jakub Jelinek  ---
As for the warning, we should open an enhancement request, though not sure it
is something for -Wmisleading-indentation.  I'd say that we just should warn
whenever a macro defines several statements and the macro is used as a body of
a conditional, so only the first statement from the macro is conditional.

[Bug sanitizer/78158] Strange data race detection with thread sanitizer

[dvyukov at google dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78158

--- Comment #3 from Dmitry Vyukov  ---
Also reported on stackoverflow:
http://stackoverflow.com/questions/37552866/why-does-threadsanitizer-report-a-race-with-this-lock-free-example

I've checked with
gcc version 7.0.1 20170307 (experimental) (GCC)
with -O0 false race is reported
with -O1 no false races reported.
Again atomic operation somehow end up being non-instrumented with -O0.

[Bug sanitizer/80063] gcc/asan.c: PVS-Studio: Incorrect Block Delimitation (CWE-483)

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80063

--- Comment #6 from Marek Polacek  ---
Author: mpolacek
Date: Mon Mar 20 13:31:28 2017
New Revision: 246278

URL: https://gcc.gnu.org/viewcvs?rev=246278&root=gcc&view=rev
Log:
PR sanitizer/80063
* asan.c (DEF_SANITIZER_BUILTIN): Use do { } while (0).

Modified:
trunk/gcc/ChangeLog
trunk/gcc/asan.c

[Bug sanitizer/80063] gcc/asan.c: PVS-Studio: Incorrect Block Delimitation (CWE-483)

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80063

Marek Polacek  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #7 from Marek Polacek  ---
Fixed.

[Bug c/80116] New: Warn about macros expanding to multiple statements

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80116

Bug ID: 80116
   Summary: Warn about macros expanding to multiple statements
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mpolacek at gcc dot gnu.org
  Target Milestone: ---

See PR80063:

  #define DEF_SANITIZER_BUILTIN(ENUM, NAME, TYPE, ATTRS) \
  decl = add_builtin_function ("__builtin_" NAME, TYPE, ENUM,   \
   BUILT_IN_NORMAL, NAME, NULL_TREE);   \
  set_call_expr_flags (decl, ATTRS);\
  set_builtin_decl (ENUM, decl, true);

  #include "sanitizer.def"

  /* -fsanitize=object-size uses __builtin_object_size, but that might
 not be available for e.g. Fortran at this point.  We use
 DEF_SANITIZER_BUILTIN here only as a convenience macro.  */
  if ((flag_sanitize & SANITIZE_OBJECT_SIZE)
  && !builtin_decl_implicit_p (BUILT_IN_OBJECT_SIZE))
DEF_SANITIZER_BUILTIN (BUILT_IN_OBJECT_SIZE, "object_size", // <=
   BT_FN_SIZE_CONST_PTR_INT,
   ATTR_PURE_NOTHROW_LEAF_LIST)

[Bug target/80102] ICE in maybe_record_trace_start, at dwarf2cfi.c:2330

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80102

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2017-03-20
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Created attachment 41004
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41004&action=edit
gcc7-pr80102.patch

Untested fix.

[Bug sanitizer/80063] gcc/asan.c: PVS-Studio: Incorrect Block Delimitation (CWE-483)

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80063

--- Comment #8 from Marek Polacek  ---
I created PR80116 to track the warning addition.

[Bug target/79893] ICE in s390_adjust_builtin_arglist in gcc/config/s390/s390-c.c:679

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79893

--- Comment #3 from Andreas Krebbel  ---
*** Bug 80106 has been marked as a duplicate of this bug. ***

[Bug ada/80117] New: [7 regression] a-cfinve.ads:245:04: warning: types for unchecked conversion have different sizes

[sch...@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80117

Bug ID: 80117
   Summary: [7 regression] a-cfinve.ads:245:04: warning: types for
unchecked conversion have different sizes
   Product: gcc
   Version: 7.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---
Target: aarch64-*-*

Created attachment 41005
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41005&action=edit
Full build log

When building an ada-enabled compiler for aarch64 with
--with-multilib-list=lp64,ilp32 the ilp32 adalib fails to build:

/home/abuild/rpmbuild/BUILD/gcc-7.0.1-r246083/obj-aarch64-suse-linux/./gcc/xgcc
-B/home/abuild/rpmbuild/BUILD/gcc-7.0.1-r246083/obj-aarch64-suse-linux/./gcc/
-B/usr/aarch64-suse-linux/bin/ -B/usr/aarch64-suse-linux/lib/ -isystem
/usr/aarch64-suse-linux/include -isystem /usr/aarch64-suse-linux/sys-include   
-c -g -O2 -mabi=ilp32 -fPIC  -W -Wall -gnatpg -nostdinc -mabi=ilp32 
a-finve.adb -o a-cfinve.o
a-cfinve.ads:245:04: warning: in instantiation at a-coboho.adb:55
a-cfinve.ads:245:04: warning: types for unchecked conversion have different
sizes
make[9]: *** [../gcc-interface/Makefile:296: a-cfinve.o] Error 1

[Bug target/80106] ICE on an invalid code in tree_to_uhwi, at tree.c:7344

[krebbel at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80106

Andreas Krebbel  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #1 from Andreas Krebbel  ---
Duplicate of:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79893

I have a fix for this and will commit it.

*** This bug has been marked as a duplicate of bug 79893 ***

[Bug fortran/80118] New: ICE with zero size parameter array

[mrestelli at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80118

Bug ID: 80118
   Summary: ICE with zero size parameter array
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mrestelli at gmail dot com
  Target Milestone: ---

The following code produces an internal compiler error when
referring to "empty2".

module m
implicit none

  integer, parameter :: not_empty(1) = 0
  integer, parameter :: empty1(0) = (/integer :: /)
  integer, parameter :: empty2(0) = 0

contains

 subroutine sub(v)
  integer, allocatable, intent(out) :: v(:)
   v = 2*not_empty ! works
   v = 2*empty1! works
   v = 2*empty2 ! internal compiler error
 end subroutine sub

end module m



$ gfortran -c test.f90 -o test.o
test.f90:14:0:

v = 2*empty2 ! internal compiler error

internal compiler error: Errore di segmentazione
0xa6f07f crash_signal
.././../gcc-trunk-source/gcc/toplev.c:337
0x5c9519 gfc_get_full_arrayspec_from_expr(gfc_expr*)
.././../gcc-trunk-source/gcc/fortran/expr.c:4496
0x6700c6 gfc_alloc_allocatable_for_assignment(gfc_loopinfo*, gfc_expr*,
gfc_expr*)
.././../gcc-trunk-source/gcc/fortran/trans-array.c:9127
0x69b0c3 gfc_trans_assignment_1
.././../gcc-trunk-source/gcc/fortran/trans-expr.c:10131
0x66051f trans_code
.././../gcc-trunk-source/gcc/fortran/trans.c:1817
0x6856f7 gfc_generate_function_code(gfc_namespace*)
.././../gcc-trunk-source/gcc/fortran/trans-decl.c:6332
0x6641b1 gfc_generate_module_code(gfc_namespace*)
.././../gcc-trunk-source/gcc/fortran/trans.c:2195
0x61a36b translate_all_program_units
.././../gcc-trunk-source/gcc/fortran/parse.c:6061
0x61a36b gfc_parse_file()
.././../gcc-trunk-source/gcc/fortran/parse.c:6274
0x65d05f gfc_be_parse_file
.././../gcc-trunk-source/gcc/fortran/f95-lang.c:204
Please submit a full bug report,
with preprocessed source if appropriate.



gfortran --version
GNU Fortran (GCC) 7.0.1 20170317 (experimental)

[Bug c++/80119] New: -Wmaybe-uninitialized wrongly flags the body of a short-circuited if-clause

[julian.pfeifle at upc dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80119

Bug ID: 80119
   Summary: -Wmaybe-uninitialized wrongly flags the body of a
short-circuited if-clause
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: julian.pfeifle at upc dot edu
  Target Milestone: ---

Consider

#include 

template 
void failing_function(std::integral_constant)
{
   int i;
   if (b && (i=4)) {
  ++i;
   } 
}

int main (void)
{
   failing_function(std::false_type());
}

Compiling with -Wall gives 

test.cc: In function `void failing_function(std::integral_constant)
[with bool b = false]`:
test.cc:8:7: error: `i` may be used uninitialized in this function
[-Werror=maybe-uninitialized]
   ++i;
   ^~

even though b is false, for which reason the body of the if-clause shouldn't
even be considered.

Calling failing_function(std::true_type()) compiles, as expected.

The `i=4` originally was a more complicated function call.

The error is important because it precludes compiling with -Werror.

gcc versions up to 6.1.0 handled this fine, I don't know about 6.2.*.

[Bug c++/80119] -Wmaybe-uninitialized wrongly flags the body of a short-circuited if-clause

[julian.pfeifle at upc dot edu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80119

--- Comment #1 from Julian Pfeifle  ---
The error occurs with -O0 and -O3.

[Bug c++/79986] [6/7 Regression][CHKP] ICE in fold_convert_loc with a flexible array

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79986

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #3 from Jason Merrill  ---
Since the testcase is ill-formed, I think the solution is to reject it earlier,
in the front end, rather than wait until RTL expansion; that should avoid the
need to touch chkp.

[Bug fortran/80120] New: Incorrect error with associate construct and character array (regression)

[mrestelli at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80120

Bug ID: 80120
   Summary: Incorrect error with associate construct and character
array (regression)
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mrestelli at gmail dot com
  Target Milestone: ---

Recent gfortran does not compile the following valid code:

program p
 implicit none

 type :: t
  character(len=25) :: text(2)
 end type t
 type(t) :: x

 x%text(1) = "ABC"
 x%text(2) = "defgh"

 associate( c => x%text )
 write(*,*) c(:)(:maxval(len_trim(c)))
 end associate

end program p


The error message is

$ gfortran test.f90 -o test
test.f90:13:16:

  write(*,*) c(:)(:maxval(len_trim(c)))
1
Error: Syntax error in WRITE statement at (1)


I see the problem with

$ gfortran --version
GNU Fortran (GCC) 7.0.1 20170317 (experimental)

while this version works:

$ gfortran --version
GNU Fortran (Gentoo 4.9.4 p1.0, pie-0.6.4) 4.9.4

The expected output is

$ ./test
 ABC  defgh

[Bug c++/80059] [7 Regression] ICE with invalid noexcept for __transaction_atomic

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80059

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #10 from Marek Polacek  ---
Fixed.

[Bug c/80122] New: __builtin_va_arg_pack() and __builtin_va_arg_pack_len() does not work correctly

[rpirrera at aitek dot it]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80122

Bug ID: 80122
   Summary: __builtin_va_arg_pack() and
__builtin_va_arg_pack_len() does not work correctly
   Product: gcc
   Version: 4.8.5
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rpirrera at aitek dot it
  Target Milestone: ---

Created attachment 41007
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41007&action=edit
test __builtin_va_arg_pack()

__builtin_va_arg_pack() has changed behavior from version 4.4.7.
In case of only an always inline function all work correctly but if the always
inline function passes the __builtin_va_arg_pack() to another always inline
function the computed __builtin_va_arg_pack_len() is 0 instead of the number of
variable arguments.

In attachment you will find a test program reproducing the issue.

[Bug fortran/80121] New: Memory leak when allocating a component derived type in a recursive subroutine (gfortran)

[andrew at fluidgravity dot co.uk]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80121

Bug ID: 80121
   Summary: Memory leak when allocating a component derived type
in a recursive subroutine (gfortran)
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: andrew at fluidgravity dot co.uk
  Target Milestone: ---

Created attachment 41006
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41006&action=edit
Fortran code with memory leak when compiled with gfortran

I'm getting a memory leak when I compile and run the attached code with
gfortran.
No such problem occurs when I use the Intel or Portland compilers.

> gfortran -g -O0 -std=f2008 code.f90
> valgrind --leak-check=yes ./a.out
...
==32283== HEAP SUMMARY:
==32283== in use at exit: 8 bytes in 1 blocks
==32283==   total heap usage: 28 allocs, 27 frees, 13,784 bytes allocated
==32283== 
==32283== 8 bytes in 1 blocks are definitely lost in loss record 1 of 1
==32283==at 0x4C29160: malloc (in
/usr/lib64/valgrind/vgpreload_memcheck-amd64-linux.so)
==32283==by 0x400C66: __m1_MOD_s1 (code.f90:14)
==32283==by 0x400E0F: __m1_MOD_s1 (code.f90:18)
==32283==by 0x400F1F: MAIN__ (code.f90:26)
==32283==by 0x400F56: main (code.f90:23)
==32283== 
==32283== LEAK SUMMARY:
==32283==definitely lost: 8 bytes in 1 blocks
==32283==indirectly lost: 0 bytes in 0 blocks
==32283==  possibly lost: 0 bytes in 0 blocks
==32283==still reachable: 0 bytes in 0 blocks
==32283== suppressed: 0 bytes in 0 blocks

[Bug c++/80059] [7 Regression] ICE with invalid noexcept for __transaction_atomic

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80059

--- Comment #9 from Marek Polacek  ---
Author: mpolacek
Date: Mon Mar 20 15:02:09 2017
New Revision: 246279

URL: https://gcc.gnu.org/viewcvs?rev=246279&root=gcc&view=rev
Log:
PR c++/80059 - ICE with noexcept and __transaction_atomic
* except.c (build_must_not_throw_expr): Call
instantiate_non_dependent_expr_sfinae.

* g++.dg/tm/pr80059-2.C: New test.
* g++.dg/tm/pr80059.C: New test.

Added:
trunk/gcc/testsuite/g++.dg/tm/pr80059-2.C
trunk/gcc/testsuite/g++.dg/tm/pr80059.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/except.c
trunk/gcc/testsuite/ChangeLog

[Bug tree-optimization/80109] ICE in get_range_info, at tree-ssanames.c:375

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80109

--- Comment #2 from Marek Polacek  ---
But also ICEs on x86_64.  Started with:

commit da6cf191f748d879f8be3c00d745b3bfe6e5495b
Author: aldyh 
Date:   Tue Oct 18 21:40:58 2016 +

* Makefile.in (OBJS): Add gimple-ssa-warn-alloca.o.
* passes.def: Add two instances of pass_walloca.
* tree-pass.h (make_pass_walloca): New.
* gimple-ssa-warn-walloca.c: New file.
* doc/invoke.texi: Document -Walloca, -Walloca-larger-than=, and
-Wvla-larger-than= options.

git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@241318
138bc75d-0d04-0410-961f-82ee72b054a4

[Bug tree-optimization/80109] ICE in get_range_info, at tree-ssanames.c:375

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80109

Marek Polacek  changed:

   What|Removed |Added

   Target Milestone|--- |7.0