[Bug c++/85400] invalid Local Dynamic TLS relaxation for symbol defined in method

2019-04-03 Thread P at draigBrady dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85400

Pádraig Brady  changed:

   What|Removed |Added

 CC||P at draigBrady dot com

--- Comment #9 from Pádraig Brady  ---
Note this isn't sparc specific.

I've also seen this when compiling CGAL 4.11 where gcc produced
R_X86_64_DTPOFF32 relocations for thread_local vars which lld wasn't happy with
at least.
Applying this patch to 8.3.0 (on x86_64) fixed the issue.

Seems this should be considered for 8.x branch.

thanks

[Bug target/89951] Uncorrect instructions flag for Nehalem / westmere arch

2019-04-03 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89951

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-04
 CC||marxin at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |marxin at gcc dot 
gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Lemme take a look.

[Bug c++/89958] New: ICE and duplicate diagnostic with invalid return value

2019-04-03 Thread reichelt at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89958

Bug ID: 89958
   Summary: ICE and duplicate diagnostic with invalid return value
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: diagnostic, error-recovery, ice-on-invalid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: reichelt at gcc dot gnu.org
  Target Milestone: ---

The following invalid code snippet triggers an ICE since GCC 6.1.0,
killing the diagnostic in mid-sentence. In addition, the first part
of the diagnostic is emitted twice:

=
struct A;

constexpr auto foo(A* p)
{
  return *p;
}
=

bug.cc: In function 'constexpr auto foo(A*)':
bug.cc:5:11: error: invalid use of incomplete type 'struct A'
5 |   return *p;
  |   ^
bug.cc:1:8: note: forward declaration of 'struct A'
1 | struct A;
  |^
bug.cc:5:10: error: invalid use of incomplete type 'struct A'
5 |   return *p;
  |  ^~
bug.cc:1:8: note: forward declaration of 'struct A'
1 | struct A;
  |^
bug.cc:3:16: error: invalid return type 'A' of 'constexpr' function 'constexpr
auto foo(A*)'
3 | constexpr auto foo(A* p)
  |^~~
bug.cc:1:8: note: 'A' is not literal because:
1 | struct A;
  |^
bug.cc:6:1: internal compiler error: Segmentation fault
6 | }
  | ^
0xf8203f crash_signal
../../gcc/gcc/toplev.c:326
0x8d0333 tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/gcc/tree.h:3175
0x8d0333 explain_non_literal_class(tree_node*)
../../gcc/gcc/cp/class.c:5525
0x8d91f0 is_valid_constexpr_fn(tree_node*, bool)
../../gcc/gcc/cp/constexpr.c:239
0x8e8c82 register_constexpr_fundef(tree_node*, tree_node*)
../../gcc/gcc/cp/constexpr.c:871
0x92e967 maybe_save_function_definition
../../gcc/gcc/cp/decl.c:15949
0x92e967 finish_function(bool)
../../gcc/gcc/cp/decl.c:16096
0x9cd454 cp_parser_function_definition_after_declarator
../../gcc/gcc/cp/parser.c:27803
0x9ce199 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/gcc/cp/parser.c:27716
0x9ce199 cp_parser_init_declarator
../../gcc/gcc/cp/parser.c:20295
0x9b049e cp_parser_simple_declaration
../../gcc/gcc/cp/parser.c:13539
0x9d41c0 cp_parser_declaration
../../gcc/gcc/cp/parser.c:13236
0x9d493c cp_parser_translation_unit
../../gcc/gcc/cp/parser.c:4698
0x9d493c c_parse_file()
../../gcc/gcc/cp/parser.c:41180
0xadae9b c_common_parse_file()
../../gcc/gcc/c-family/c-opts.c:1156
Please submit a full bug report, [etc.]

[Bug tree-optimization/89956] [9 Regression] ICE: Segmentation fault (in gsi_for_stmt(gimple*))

2019-04-03 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89956

Martin Liška  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug tree-optimization/89956] [9 Regression] ICE: Segmentation fault (in gsi_for_stmt(gimple*))

2019-04-03 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89956

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-04
 CC||marxin at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
  Known to work||8.3.0
 Ever confirmed|0   |1
  Known to fail||9.0

--- Comment #1 from Martin Liška  ---
Confirmed, started with r260348.

[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244

2019-04-03 Thread marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2019-04-04
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Yes, we'll need the pre-processed source file (created with -E option). Please
attach it.

[Bug middle-end/89957] ICE calling strnlen with an int128_t bound in a known range

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89957

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-04
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

[Bug middle-end/89957] ICE calling strnlen with an int128_t bound in a known range

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89957

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=89911

--- Comment #1 from Martin Sebor  ---
The crashing code (the wi::ltu_p call):

  if (!TREE_NO_WARNING (exp)
  && wi::ltu_p (wi::to_wide (maxobjsize), min)
  && warning_at (loc, OPT_Wstringop_overflow_,
 "%K%qD specified bound [%wu, %wu] "
 "exceeds maximum object size %E",
 exp, func, min.to_uhwi (), max.to_uhwi (), maxobjsize))
TREE_NO_WARNING (exp) = true;

The test case was reduced from pr89911.

[Bug middle-end/89957] New: ICE calling strnlen with an int128_t bound in a known range

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89957

Bug ID: 89957
   Summary: ICE calling strnlen with an int128_t bound in a known
range
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

$ cat z.c && gcc -c -O2 -Wall z.c
typedef __SIZE_TYPE__ size_t;

extern size_t strnlen ();

size_t foo (__int128_t n)
{
  if (n < 0)
n = 0;
  return strnlen ("", n);
}
z.c: In function ‘foo’:
z.c:9:23: warning: ‘strnlen’ argument 2 type is ‘__int128’ where ‘long unsigned
int’ is expected in a call to built-in function declared without prototype
[-Wbuiltin-declaration-mismatch]
9 |   return strnlen ("", n);
  |   ^
z.c:3:15: note: built-in ‘strnlen’ declared here
3 | extern size_t strnlen ();
  |   ^~~
during RTL pass: expand
z.c:9:10: internal compiler error: in decompose, at wide-int.h:963
9 |   return strnlen ("", n);
  |  ^~~
0x877bc0 wi::int_traits >::decompose(long*,
unsigned int, generic_wide_int const&)
/src/gcc/svn/gcc/wide-int.h:963
0x95f62a wide_int_ref_storage::wide_int_ref_storage
>(generic_wide_int const&, unsigned int)
/src/gcc/svn/gcc/wide-int.h:1013
0x95f5f6 generic_wide_int
>::generic_wide_int
>(generic_wide_int const&, unsigned int)
/src/gcc/svn/gcc/wide-int.h:788
0x9e15df bool wi::ltu_p >,
generic_wide_int
>(generic_wide_int > const&,
generic_wide_int const&)
/src/gcc/svn/gcc/wide-int.h:1913
0x9c2fea expand_builtin_strnlen
/src/gcc/svn/gcc/builtins.c:3154
0x9d22c9 expand_builtin(tree_node*, rtx_def*, rtx_def*, machine_mode, int)
/src/gcc/svn/gcc/builtins.c:7533
0xbfc03c expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/src/gcc/svn/gcc/expr.c:11029
0xbee2c3 expand_expr_real(tree_node*, rtx_def*, machine_mode, expand_modifier,
rtx_def**, bool)
/src/gcc/svn/gcc/expr.c:8274
0xbe310a store_expr(tree_node*, rtx_def*, int, bool, bool)
/src/gcc/svn/gcc/expr.c:5673
0xbe143a expand_assignment(tree_node*, tree_node*, bool)
/src/gcc/svn/gcc/expr.c:5436
0xa1ece5 expand_call_stmt
/src/gcc/svn/gcc/cfgexpand.c:2722
0xa226b3 expand_gimple_stmt_1
/src/gcc/svn/gcc/cfgexpand.c:3691
0xa22d6e expand_gimple_stmt
/src/gcc/svn/gcc/cfgexpand.c:3850
0xa22e86 expand_gimple_tailcall
/src/gcc/svn/gcc/cfgexpand.c:3897
0xa2b406 expand_gimple_basic_block
/src/gcc/svn/gcc/cfgexpand.c:5863
0xa2d224 execute
/src/gcc/svn/gcc/cfgexpand.c:6509
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-03 Thread schnetter at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #21 from Erik Schnetter  ---
https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00162.html

[Bug tree-optimization/89956] New: [9 Regression] ICE: Segmentation fault (in gsi_for_stmt(gimple*))

2019-04-03 Thread asolokha at gmx dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89956

Bug ID: 89956
   Summary: [9 Regression] ICE: Segmentation fault (in
gsi_for_stmt(gimple*))
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gfortran-9.0.0-alpha20190331 (r270048) ICEs when compiling the following
testcase w/ -O2 (-O3, -Ofast) -fno-code-hoisting -fno-signed-zeros
-fno-trapping-math -fno-tree-dominator-opts -fno-tree-forwprop -fno-tree-pre:

module de
contains
  function zu (az, xx) result (q3)
real :: az, xx, q3

q3 = 1.0 - lz (az, xx) - lz (xx, az)
  end function zu

  function lz (ho, gh) result (ye)
real :: ho, gh, ye

ye = sqrt (ho) - ho * gh
  end function lz
end module de

% powerpc-e300c3-linux-gnu-gfortran-9.0.0-alpha20190331 -O2 -fno-code-hoisting
-fno-signed-zeros -fno-trapping-math -fno-tree-dominator-opts
-fno-tree-forwprop -fno-tree-pre -c xonlkfwo.f90
during GIMPLE pass: widening_mul
xonlkfwo.f90:3:0:

3 |   function zu (az, xx) result (q3)
  | 
internal compiler error: Segmentation fault
0xd83ce6 crash_signal
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190331/work/gcc-9-20190331/gcc/toplev.c:326
0xacbfab gsi_for_stmt(gimple*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190331/work/gcc-9-20190331/gcc/gimple-iterator.c:611
0xefe0b6 convert_mult_to_fma_1
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190331/work/gcc-9-20190331/gcc/tree-ssa-math-opts.c:2882
0xf03e07 convert_mult_to_fma
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190331/work/gcc-9-20190331/gcc/tree-ssa-math-opts.c:3278
0xf048cb after_dom_children
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190331/work/gcc-9-20190331/gcc/tree-ssa-math-opts.c:3755
0x1463647 dom_walker::walk(basic_block_def*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190331/work/gcc-9-20190331/gcc/domwalk.c:395
0xf03891 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-9.0.0_alpha20190331/work/gcc-9-20190331/gcc/tree-ssa-math-opts.c:3838

==20688== Invalid read of size 8
==20688==at 0xACBFAB: gsi_for_stmt(gimple*) (gimple-iterator.c:611)
==20688==by 0xEFE0B6: convert_mult_to_fma_1(tree_node*, tree_node*,
tree_node*) (tree-ssa-math-opts.c:2882)
==20688==by 0xF03E07: convert_mult_to_fma(gimple*, tree_node*, tree_node*,
fma_deferring_state*) (tree-ssa-math-opts.c:3278)
==20688==by 0xF048CB: (anonymous
namespace)::math_opts_dom_walker::after_dom_children(basic_block_def*)
(tree-ssa-math-opts.c:3755)
==20688==by 0x1463647: dom_walker::walk(basic_block_def*) (domwalk.c:395)
==20688==by 0xF03891: (anonymous
namespace)::pass_optimize_widening_mul::execute(function*)
(tree-ssa-math-opts.c:3838)
==20688==by 0xCABD3C: execute_one_pass(opt_pass*) (passes.c:2487)
==20688==by 0xCAC497: execute_pass_list_1(opt_pass*) (passes.c:2573)
==20688==by 0xCAC4A9: execute_pass_list_1(opt_pass*) (passes.c:2574)
==20688==by 0xCAC4F0: execute_pass_list(function*, opt_pass*)
(passes.c:2584)
==20688==by 0x96EC8E: cgraph_node::expand() (cgraphunit.c:2198)
==20688==by 0x97011D: expand_all_functions (cgraphunit.c:2336)
==20688==by 0x97011D: compile (cgraphunit.c:2687)
==20688==by 0x97011D: symbol_table::compile() (cgraphunit.c:2597)
==20688==  Address 0x10 is not stack'd, malloc'd or (recently) free'd

(While my target here is powerpc, the ICE is not target-specific. One have to
add -mfma in order to reproduce it for x86_64.)

[Bug c++/86986] [7/8/9 Regression] Unexpected errors for template parameter pack in a template template parameter

2019-04-03 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86986

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug middle-end/89911] [9 Regression] ICE in get_attr_nonstring_decl, at calls.c:1502

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89911

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org

[Bug target/89955] New: riscv.h improperly defines STARTFILE_PREFIX_SPEC spec

2019-04-03 Thread kallisti5 at unixzen dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89955

Bug ID: 89955
   Summary: riscv.h improperly defines STARTFILE_PREFIX_SPEC spec
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kallisti5 at unixzen dot com
  Target Milestone: ---

https://gcc.gnu.org/viewcvs/gcc/trunk/gcc/config/riscv/riscv.h?view=markup#l885

gcc/config/riscv.h defines STARTFILE_PREFIX_SPEC which breaks sysroot's.

Under a new platform (Haiku), our bootstrap was failing missing core existing
cross-compiled system libraries which were present and accounted for.

Eventually I figured out to #undef STARTFILE_PREFIX_SPEC in our
gcc/config/riscv/haiku.h header and things magically began working.  Since
we're cross compiling with a sysroot (which is *not*) at /usr/lib,/lib,etc, it
breaks the sysroot functionality.

Likely I think STARTFILE_PREFIX_SPEC needs moved to config/riscv/linux.h ?

[Bug fortran/89375] fortran/expr.c:4723:5: warning: logical ‘or’ of equal expressions [-Wlogical-op]

2019-04-03 Thread fritzoreese at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89375

--- Comment #5 from Fritz Reese  ---
Thanks Dominiq.

On Wed, Apr 3, 2019, 05:02 dominiq at lps dot ens.fr <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89375
>
> Dominique d'Humieres  changed:
>
>What|Removed |Added
>
> 
>  Status|NEW |RESOLVED
>  Resolution|--- |FIXED
>
> --- Comment #4 from Dominique d'Humieres  ---
> Fixed.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug rtl-optimization/80960] [7/8/9 Regression] Huge memory use when compiling a very large test case

2019-04-03 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80960

--- Comment #17 from Segher Boessenkool  ---
(In reply to rguent...@suse.de from comment #16)

> I would guess so.  I wonder if the combiner could restrict itself
> here?  Maybe LUID "distances" are an approximation?  Doesn't the
> combiner use DF uses so the number of combinations shouldn't increase
> with basic-block size but only with the number of uses?  Of course
> since we don't have SSA the uses probably include those that cross
> other defs...

Combine doesn't try too many pairs: it tries every def only with its
first use, so that is linear in # insns.  But the check if a combination
is valid uses reg_used_between_p, which is no good for insns a big
distance apart.

> That said, algorithmically first building up a kind-of-SSA to
> restrict things combine will try might help to avoid this kind
> of issues.

Yup.  Not going to happen in stage4, of course :-/

There are a few other things which aren't linear, but this is the
worst one (the rest only happens occasionally, or only on successful
combinations).

> Since combine does a df_analyze we should have a way to record
> the number of insns in a block without another IL walk, it could
> also fall back to 2->1 and 2->2 insn combinations after visiting
> a new PARAM max-combine-bb-insns-3-3 number of insns in an EBB.

The 3->1 (or 3->2) isn't really the problem; there just are many more
to try than 2->[12].

> Actually it already does two walks over the whole function in
> combine_instructions it seems, so recording # insns per EBB should
> be possible?  (if that's really the key metric causing the issue)

The average distance between a set and its first use is the key metric.
The numbers make it feel like that is pretty constrained here still
(I haven't run numbers on it), but 100 is very much already if there are
1M insns in the block (or whatever).  All numbers that aren't terrible,
but combines it takes up quite a chunk of time.

Combine also makes garbage for every try, and none of that is cleaned
up during combine.  Maybe we should change that?  (I can try next week).

[Bug rtl-optimization/86928] ICE in compute_live, at sel-sched.c:3097

2019-04-03 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86928

--- Comment #6 from Segher Boessenkool  ---
(In reply to Alexander Monakov from comment #5)
> I didn't have any better ideas, so fixed via comment #2.

Thanks!

[Bug ipa/89893] Segmentation fault always occurs when node app is generated by gcc-8-branch@268745

2019-04-03 Thread kangshan0910 at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89893

--- Comment #10 from 康 珊  ---
Hi Martin Liška, I tried to build it with "-O3 -fno-strict-aliasing
-falign-functions=32 -fno-math-errno -fno-semantic-interposition
-fno-trapping-math", but it still had the issue. Can "-fno-strict-aliasing"
work normally with "-O3"?

[Bug target/89954] missed optimization for signed extension for x86-64

2019-04-03 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89954

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Target||x86_64-linux-gnu
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-04
  Component|c   |target
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

Though AARCH64 does the right thing though:
f:
adrpx0, c
ldrbw0, [x0, #:lo12:c]
eor w0, w0, 1
ret

[Bug c/89954] New: missed optimization for signed extension for x86-64

2019-04-03 Thread ntysdd at qq dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89954

Bug ID: 89954
   Summary: missed optimization for signed extension for x86-64
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ntysdd at qq dot com
  Target Milestone: ---

This code snippet 

/
char c;
int f()
{
return c ^ 1;
}
/

is compiled into these instructions with options "-O2 -S"


;
movq_c@GOTPCREL(%rip), %rax
movzbl  (%rax), %eax
xorl$1, %eax
movsbl  %al, %eax
;

Only movsbl is needed because xor by 1 doesn't change high bits.

[Bug middle-end/89934] [9 Regression] ICE on a call with fewer arguments to strncpy declared without prototype

2019-04-03 Thread JunMa at linux dot alibaba.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934

JunMa  changed:

   What|Removed |Added

 CC||JunMa at linux dot alibaba.com

--- Comment #5 from JunMa  ---
similar issue in pr89911

[Bug c++/89937] For example code, which is valid as either C or C++, optimization seems much better for C

2019-04-03 Thread wkaras at yahoo dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89937

--- Comment #2 from Walt Karas  ---
(In reply to Andrew Pinski from comment #1)
> This is because of the way inline have different semantics between the two
> langauges.
> 
> If I change TSFastDbg to be static instead of just inline, then the code
> emitted is the same.
> In the case of C, since TSFastDbg is not inlined, there exists an out of
> line version of it in a different TU.
> In the case of C++, TSFastDbg has vague linkage, there for will be emitted
> but in a comdat section.
> 
> The options you have turned on for godbolt, hide this fact; turning them off
> you get:
> 
> .Ltext0:
> .section   
> .text._Z9TSFastDbgP14TSFastDbgCntl_PKcz,"axG",@progbits,
> _Z9TSFastDbgP14TSFastDbgCntl_PKcz,comdat
> .p2align 4,,15
> .weak   _Z9TSFastDbgP14TSFastDbgCntl_PKcz
> .type   _Z9TSFastDbgP14TSFastDbgCntl_PKcz, @function
> _Z9TSFastDbgP14TSFastDbgCntl_PKcz:
> 
> See how that is a comdat section.

Hmmm it seems you are saying that inline (or weak linkage by any other name) in
C++ somehow prohibits inlining.  I thought that, in C++, a weak linkage
function may or may not be inlined.  If it isn't, its object code must be in a
vague linkage section.  But there is no requirement for its object code to
appear in a vague linkage section, is there?

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

2019-04-03 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763

--- Comment #38 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #37)
> (In reply to Jeffrey A. Law from comment #36)
> > I wonder if we could pass in a scratch register from try_combine down to
> > make_field_assignment to facilitate something like this...
> 
> I have found that make_field_assignment needs a lot of work in the past.  I
> had a few patches to make_field_assignment to improve it in the GCC 4.3 days
> but never updated them for newer compiler versions as the code generationg
> which I was fixing up was already fixed; it was for some bad generated SRA
> issue.
> Maybe for GCC 10, I will look into improving make_field_assignment.

Also I should mention I tried in the past having make_field_assignment making a
sequence of instructions (two) where one was the assignment and the second one
was the zero_extract assignment.  This was done in the 4.7 days.  I could not
fix the rest of combine doing the correct thing and had to give up as I was
running out of time before a release was needed to be made.  I will try again. 
This was exactly what you were asking to do to make_field_assignment too.

[Bug d/89255] libphobos.unittests multilib handling broken

2019-04-03 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89255

Iain Buclaw  changed:

   What|Removed |Added

  Attachment #46060|0   |1
is obsolete||
  Attachment #46069|0   |1
is obsolete||
  Attachment #46077|0   |1
is obsolete||

--- Comment #15 from Iain Buclaw  ---
Created attachment 46086
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46086&action=edit
patch for pr89255

Tracked down hang in std.net.curl module ctor/dtors inside version(unittest)
code are now added to test module info record.

Posting new patch with all so far.

[Bug d/89823] Composed message only partially translatable

2019-04-03 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89823

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #3 from Iain Buclaw  ---
For now, translation is not required as of r270074.

[Bug translation/40883] [meta-bug] Translation breakage with trivial fixes

2019-04-03 Thread ibuclaw at gdcproject dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=40883
Bug 40883 depends on bug 89823, which changed state.

Bug 89823 Summary: Composed message only partially translatable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89823

   What|Removed |Added

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

[Bug c++/89331] [8/9 Regression] internal compiler error: in build_simple_base_path, at cp/class.c:589

2019-04-03 Thread stsp at users dot sourceforge.net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89331

--- Comment #7 from Stas Sergeev  ---
(In reply to Jason Merrill from comment #4)
> But when we're in the middle of the class definition we don't know yet
> whether it's standard-layout, so we can't answer yet.  A compiler is allowed
> to reorder fields of a non-standard-layout class.

Thanks, that clears some things for me.
I definitely am not going to turn this ticket
into a forum, but I am still puzzled why the
below works (on gcc at least, not on clang):
---
#include 
#include 

class L {};
template 
struct offset_of {
constexpr operator size_t() const {
return (std::uintptr_t)&(((T*)nullptr)->*M);
}
};
template 
struct B {
char aa;
static const int off = offset_of();
};

struct A {
char a;
L _mark[0];
B b;
};

int main()
{
A a;
std::cout << "size " << sizeof(A) << " off " << a.b.off << std::endl;
return 0;
}
---

Here I do 2 emulation tricks.
I use address-of on the zero-sized mark to emulate
offsetof() in the not yet fully defined class.
And I use reinterpret cast in a constexpr to emulate
offsetof() that doesn't want to work with the template
arguments for some reason.
This works perfectly on gcc (I filled a bug report to clang).
So if the emulation works, why doesn't the original?
Are there any possibility to somehow extend __builtin_offsetof()
to cover either of those 2 cases where I currently have
to emulate it? While I understand the problem you described,
why does the above example avoids it?

[Bug fortran/89938] inconsistent wording regarding assumed shape

2019-04-03 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89938

--- Comment #5 from Dominique d'Humieres  ---
gcc/testsuite/gfortran.dg/pdt_4.f03:  type(modtype(8,*)) :: mod_r   ! {
dg-error "ASSUMED type parameters" }

The test is not part of the attached patch.

[Bug fortran/89938] inconsistent wording regarding assumed shape

2019-04-03 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89938

--- Comment #4 from Dominique d'Humieres  ---
Created attachment 46085
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46085&action=edit
Adjust the tests

[Bug fortran/89938] inconsistent wording regarding assumed shape

2019-04-03 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89938

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |dominiq at lps dot 
ens.fr

--- Comment #3 from Dominique d'Humieres  ---
> Hyphen compounds: assumed shape and other related ones

I have found several such compounds and I have added hyphens based on the
pattern

assumed-shape arrays have assumed shape.

I have also done the changes in the comments. This has been done manually and I
may
have made mistakes, so it would be nice if someone looks at the patch.

I know I have missed

gcc/fortran/resolve.c:gfc_error ("The object %qs at %L with ASSUMED type
parameters "

[Bug fortran/89938] inconsistent wording regarding assumed shape

2019-04-03 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89938

--- Comment #2 from Dominique d'Humieres  ---
Created attachment 46084
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46084&action=edit
Hyphen compounds: assumed shape and other related ones

[Bug c++/89331] [8/9 Regression] internal compiler error: in build_simple_base_path, at cp/class.c:589

2019-04-03 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89331

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|8.4 |9.0

--- Comment #6 from Jason Merrill  ---
Fixed for GCC 9.

[Bug c++/81866] [7/8 Regression] ICE with a default template parameter which is a template class nested in a template class

2019-04-03 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81866

Jason Merrill  changed:

   What|Removed |Added

Summary|[7/8/9 Regression] ICE with |[7/8 Regression] ICE with a
   |a default template  |default template parameter
   |parameter which is a|which is a template class
   |template class nested in a  |nested in a template class
   |template class  |

--- Comment #5 from Jason Merrill  ---
Fixed on trunk so far.

[Bug c++/81866] [7/8/9 Regression] ICE with a default template parameter which is a template class nested in a template class

2019-04-03 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81866

--- Comment #4 from Jason Merrill  ---
Author: jason
Date: Wed Apr  3 21:51:36 2019
New Revision: 270138

URL: https://gcc.gnu.org/viewcvs?rev=270138&root=gcc&view=rev
Log:
PR c++/81866 - ICE with member template and default targ.

This testcase manages to find a way to look up the partial instantiation of
B for the default argument of C before we've created the partial
instantiation of B as part of the normal instantiation of the members of A.
Which we can deal with, but we were getting confused because the partial
instantiation was stored with a RECORD_TYPE specialization rather than
TEMPLATE_DECL.

* pt.c (tsubst_template_decl): Handle getting a type from
retrieve_specialization.

Added:
trunk/gcc/testsuite/g++.dg/template/memtmpl6.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/pt.c

[Bug fortran/68567] ICE on using wrong defined arrays (different cases/messages)

2019-04-03 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68567

Dominique d'Humieres  changed:

   What|Removed |Added

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

--- Comment #10 from Dominique d'Humieres  ---
Fixed.

[Bug fortran/68567] ICE on using wrong defined arrays (different cases/messages)

2019-04-03 Thread dominiq at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68567

--- Comment #9 from dominiq at gcc dot gnu.org ---
Author: dominiq
Date: Wed Apr  3 21:32:13 2019
New Revision: 270137

URL: https://gcc.gnu.org/viewcvs?rev=270137&root=gcc&view=rev
Log:
2019-04-03  Steven G. Kargl  

PR fortran/68567
* expr.c (gfc_reduce_init_expr): Add extra check to avoid
dereferencing a null pointer.

2019-04-03  Dominique d'Humieres  

PR fortran/68567
* gfortran.dg/parameter_array_error_1.f90: New test.


Added:
trunk/gcc/testsuite/gfortran.dg/parameter_array_error_1.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/expr.c
trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

2019-04-03 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763

--- Comment #37 from Andrew Pinski  ---
(In reply to Jeffrey A. Law from comment #36)
> I wonder if we could pass in a scratch register from try_combine down to
> make_field_assignment to facilitate something like this...

I have found that make_field_assignment needs a lot of work in the past.  I had
a few patches to make_field_assignment to improve it in the GCC 4.3 days but
never updated them for newer compiler versions as the code generationg which I
was fixing up was already fixed; it was for some bad generated SRA issue.
Maybe for GCC 10, I will look into improving make_field_assignment.

[Bug rtl-optimization/87763] [9 Regression] aarch64 target testcases fail after r265398

2019-04-03 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87763

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #36 from Jeffrey A. Law  ---
My combiner-fu is old and getting dated.  But I wonder if we're writing off
zero_extract too quickly.

For the first test in insv1 (and I suspect others are similar) we get into
make_field_assignment with something *almost* usable.  In particular:

(set (reg/i:DI 0 x0)
(ior:DI (and:DI (reg:DI 95)
(const_int -256 [0xff00]))
(const_int 3 [0x3])))


The only reason this isn't going to be recognized as a field assignment is
because  we don't have a RMW.  But we can trivially turn that into a RMW by
emitting a copy from reg95 to reg0 and changing the source to reg0.

That runs afoul of the general direction we're taking WRT hard registers, so
another choice might be to use an existing pseudo that we know is going to die
-- reg92 in this case which isn't seen in the extraction pattern.  So we'd copy
reg95 into reg92 before the extraction and change the source & destination in
the extraction to reg92.  Then copy reg92 into reg0 after the extraction.

I wonder if we could pass in a scratch register from try_combine down to
make_field_assignment to facilitate something like this...

[Bug c++/81866] [7/8/9 Regression] ICE with a default template parameter which is a template class nested in a template class

2019-04-03 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81866

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

[Bug c++/89953] New: ICE in nothrow_spec_p, at cp/except.c:1244

2019-04-03 Thread rene.r...@fu-berlin.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89953

Bug ID: 89953
   Summary: ICE in nothrow_spec_p, at cp/except.c:1244
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rene.r...@fu-berlin.de
  Target Milestone: ---

Using gcc-9 20190331_1 experimental on mac osx causes ICE.
The respective code works fine with gcc7 and gcc8.

I added the preprocessed source in the attachment.

Let me know if you need more information or if I need to reduce it to a minimal
code example that triggers the ICE.

GCC Version: 
GNU C++17 (MacPorts gcc9 9-20190331_1) version 9.0.1 20190331 (experimental)
(x86_64-apple-darwin18)

Here the build log:

Using built-in specs.
COLLECT_GCC=/opt/local/bin/g++-mp-9
Target: x86_64-apple-darwin18
Configured with:
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_macports_release_tarballs_ports_lang_gcc9/gcc9/work/gcc-9-20190331/configure
--prefix=/opt/local --build=x86_64-apple-darwin18
--enable-languages=c,c++,objc,obj-c++,lto,fortran --libdir=/opt/local/lib/gcc9
--includedir=/opt/local/include/gcc9 --infodir=/opt/local/share/info
--mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-9
--with-local-prefix=/opt/local --with-system-zlib --disable-nls
--program-suffix=-mp-9 --with-gxx-include-dir=/opt/local/include/gcc9/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local
--with-isl=/opt/local --enable-stage1-checking --disable-multilib --enable-lto
--enable-libstdcxx-time --with-build-config=bootstrap-debug
--with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket
--disable-tls --with-pkgversion='MacPorts gcc9 9-20190331_1'
--with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
Thread model: posix
gcc version 9.0.1 20190331 (experimental) (MacPorts gcc9 9-20190331_1)
COLLECT_GCC_OPTIONS='-I'
'/Users/rmaerker/Development/seqan3/seqan3-build/unit/vendor/googletest/googletest/include'
'-I' '/Users/rmaerker/Development/seqan3/seqan3-src/test/include' '-I'
'/Users/rmaerker/Development/seqan3/seqan3-src/include' '-isystem'
'/Users/rmaerker/Development/seqan3/seqan3-src/submodules/sdsl-lite/include'
'-isystem'
'/Users/rmaerker/Development/seqan3/seqan3-src/submodules/range-v3/include'
'-isystem'
'/Users/rmaerker/Development/seqan3/seqan3-src/submodules/lemon/include'
'-isystem'
'/Users/rmaerker/Development/seqan3/seqan3-src/submodules/cereal/include'
'-isystem' '/opt/local/include' '-g' '-isysroot'
'/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk'
'-Wpedantic' '-Wall' '-Wextra' '-Werror' '-std=c++17' '-fconcepts' '-v'
'-save-temps' '-o' 'CMakeFiles/view_get_test.dir/view_get_test.cpp.o' '-c'
'-mmacosx-version-min=10.14.0' '-asm_macosx_version_min=10.14' '-shared-libgcc'
'-mtune=core2'
 /opt/local/libexec/gcc/x86_64-apple-darwin18/9.0.1/cc1plus -E -quiet -v -I
/Users/rmaerker/Development/seqan3/seqan3-build/unit/vendor/googletest/googletest/include
-I /Users/rmaerker/Development/seqan3/seqan3-src/test/include -I
/Users/rmaerker/Development/seqan3/seqan3-src/include -D__DYNAMIC__ -isystem
/Users/rmaerker/Development/seqan3/seqan3-src/submodules/sdsl-lite/include
-isystem
/Users/rmaerker/Development/seqan3/seqan3-src/submodules/range-v3/include
-isystem /Users/rmaerker/Development/seqan3/seqan3-src/submodules/lemon/include
-isystem
/Users/rmaerker/Development/seqan3/seqan3-src/submodules/cereal/include
-isystem /opt/local/include -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
/Users/rmaerker/Development/seqan3/seqan3-src/test/unit/range/view/view_get_test.cpp
-fPIC -feliminate-unused-debug-symbols -mmacosx-version-min=10.14.0
-mtune=core2 -std=c++17 -Wpedantic -Wall -Wextra -Werror -fconcepts -g
-fworking-directory -fpch-preprocess -o view_get_test.ii
ignoring nonexistent directory
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/opt/local/include"
ignoring nonexistent directory
"/opt/local/lib/gcc9/gcc/x86_64-apple-darwin18/9.0.1/../../../../../x86_64-apple-darwin18/include"
ignoring nonexistent directory
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:

/Users/rmaerker/Development/seqan3/seqan3-build/unit/vendor/googletest/googletest/include
 /Users/rmaerker/Development/seqan3/seqan3-src/test/include
 /Users/rmaerker/Development/seqan3/seqan3-src/include
 /Users/rmaerker/Development/seqan3/seqan3-src/submodules/sdsl-lite/include
 /Users/rmaerker/Development/seqan3/seqan3-src/submodules/range-v3/include
 /Users/

[Bug bootstrap/86518] Strengthen bootstrap comparison by not enabling warnings at stage3

2019-04-03 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518
Bug 86518 depends on bug 86586, which changed state.

Bug 86586 Summary: [7/8/9 Regression] -Wsign-compare affects code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86586

   What|Removed |Added

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

[Bug c++/86586] [7/8/9 Regression] -Wsign-compare affects code generation

2019-04-03 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86586

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||jason at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
   Target Milestone|7.5 |9.0

--- Comment #9 from Jason Merrill  ---
Fixed for GCC 9 by not folding on this testcase.  This doesn't address the
general issue, but reduces its scope.  Not worth backporting.

[Bug c++/86586] [7/8/9 Regression] -Wsign-compare affects code generation

2019-04-03 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86586

--- Comment #8 from Jason Merrill  ---
Author: jason
Date: Wed Apr  3 20:12:00 2019
New Revision: 270136

URL: https://gcc.gnu.org/viewcvs?rev=270136&root=gcc&view=rev
Log:
PR c++/86586 - -fcompare-debug=-Wsign-compare.

This patch limits constexpr folding for -Wsign-compare to only cases that we
would warn for without considering constant values, avoiding the folding in
the testcase in question.

gcc/c-family/
* c-warn.c (warn_for_sign_compare): Call fold_for_warn.
gcc/cp/
* typeck.c (cp_build_binary_op): Don't fold for -Wsign-compare.

Modified:
trunk/gcc/c-family/ChangeLog
trunk/gcc/c-family/c-warn.c
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/g++.target/i386/mv1.C

[Bug c++/89331] [8/9 Regression] internal compiler error: in build_simple_base_path, at cp/class.c:589

2019-04-03 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89331

--- Comment #5 from Jason Merrill  ---
Author: jason
Date: Wed Apr  3 20:09:17 2019
New Revision: 270135

URL: https://gcc.gnu.org/viewcvs?rev=270135&root=gcc&view=rev
Log:
PR c++/89331 - ICE with offsetof in incomplete class.

We were aborting when build_base_path returned an error because of the
derived class not being complete yet, which wasn't considered by the assert.
Fixed by checking for complete type first.  The semantics.c change avoids
a duplicate error message.

* semantics.c (finish_offsetof): Handle error_mark_node.
* typeck.c (build_class_member_access_expr): Call
complete_type_or_maybe_complain before converting to base.

Added:
trunk/gcc/testsuite/g++.dg/ext/builtin-offsetof4.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/semantics.c
trunk/gcc/cp/typeck.c
trunk/gcc/testsuite/g++.dg/other/offsetof8.C

[Bug bootstrap/89864] [9 regression] gcc fails to build/bootstrap with XCode 10.2

2019-04-03 Thread schnetter at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89864

--- Comment #20 from Erik Schnetter  ---
I have a patch that works for 8.3.0. It doesn't work for 9.0.0 (i.e. an svn
checkout); I'm working on this.

[Bug c++/89947] Resolution of base classes fail for some automatic types in template struct functions

2019-04-03 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89947

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-03
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Clang and EDG both accept it. Doesn't seem to be a regression.

[Bug fortran/84487] [8/9 Regression] Large rodate section increase in 465.tonto with r254427

2019-04-03 Thread tkoenig at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84487

Thomas Koenig  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #22 from Thomas Koenig  ---
This patch

Index: trans-decl.c
===
--- trans-decl.c(Revision 269895)
+++ trans-decl.c(Arbeitskopie)
@@ -1863,10 +1863,6 @@ gfc_get_symbol_decl (gfc_symbol * sym)
   if (sym->attr.associate_var)
 GFC_DECL_ASSOCIATE_VAR_P (decl) = 1;

-  if (sym->attr.vtab
-  || (sym->name[0] == '_' && gfc_str_startswith (sym->name,
"__def_init")))
-TREE_READONLY (decl) = 1;
-
   return decl;
 }

leads to

FAIL: gfortran.dg/gomp/pr52531.f90   -O  (test for excess errors)
Excess errors:
/home/ig25/Gcc/trunk/gcc/testsuite/gfortran.dg/gomp/pr52531.f90:10:0: Error:
'__vtab_test_mod_Test_type' not specified in enclosing 'parallel'
/home/ig25/Gcc/trunk/gcc/testsuite/gfortran.dg/gomp/pr52531.f90:9:0: Error:
enclosing 'parallel'

where I have no idea if this is just a cosmetic bug which
can, for example, be shut up with a check for attr.artificial,
or if this points towards a real problem.

Jakub, could you maybe shed any light?

[Bug c/89946] [8/9 Regression] ICE in assemble_start_function, at varasm.c:1871

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89946

Martin Sebor  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-04-03
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Sebor  ---
Confirmed.  The ICE first appeared in r250521 when the attribute was added. 
The handler for the attributes does no validation:

  static tree
  handle_patchable_function_entry_attribute (tree *, tree, tree, int, bool *)
  {
/* Nothing to be done here.  */
return NULL_TREE;
  }

With struct attribute_spec extended to describe basic properties of attribute
arguments besides just their number, basic attribute argument validation could
be done in decl_attributes, similarly to how mutually exclusive attributes are
handled.

[Bug target/89952] S/390: Inconsistent CFI info when restoring frame pointer from fpr

2019-04-03 Thread krebbel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89952

--- Comment #1 from Andreas Krebbel  ---
Created attachment 46083
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46083&action=edit
Experimental patch

[Bug middle-end/89934] [9 Regression] ICE on a call with fewer arguments to strncpy declared without prototype

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00149.html

[Bug target/89952] New: S/390: Inconsistent CFI info when restoring frame pointer from fpr

2019-04-03 Thread krebbel at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89952

Bug ID: 89952
   Summary: S/390: Inconsistent CFI info when restoring frame
pointer from fpr
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Created attachment 46082
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46082&action=edit
Testcase

Compiling the attached testcase with GCC built with checking enabled ICEs:

during RTL pass: dwarf2
t.c:10:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2348   
 }
 ^
0x13a7649 maybe_record_trace_start
/home/andreas/gcc/gcc/dwarf2cfi.c:2348
0x13a9d6f scan_trace
/home/andreas/gcc/gcc/dwarf2cfi.c:2541
0x13aa40b create_cfi_notes
/home/andreas/gcc/gcc/dwarf2cfi.c:2694
0x13aa40b execute_dwarf2_frame
/home/andreas/gcc/gcc/dwarf2cfi.c:3057
0x13aa40b execute
/home/andreas/gcc/gcc/dwarf2cfi.c:3545

There is an edge from very early in the function to right before the call to
"j" which is executed as sibcall. In between the hard frame pointer (r11) is
saved to and FPR, set to the stack pointer and restored from the FPR. After
restoring the hard frame pointer register to its former value the backend
misses to set the CFA register back to r15. That's why the sibcall insn can be
reached with the CFA register being either r11 or r15.

[Bug fortran/67744] [OOP] polymorphic associating entity is refused TBP invocation

2019-04-03 Thread Bader at lrz dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67744

--- Comment #5 from Bader at lrz dot de  ---
This is still not fixed in current trunk.

[Bug tree-optimization/89730] -flive-patching=inline-only-static should grant always_inline attribute for extern function

2019-04-03 Thread qinzhao at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89730

--- Comment #2 from qinzhao at gcc dot gnu.org ---
Author: qinzhao
Date: Wed Apr  3 19:00:25 2019
New Revision: 270134

URL: https://gcc.gnu.org/viewcvs?rev=270134&root=gcc&view=rev
Log:
2019-04-03  qing zhao  

PR tree-optimization/89730
* ipa-inline.c (can_inline_edge_p): Delete the checking for
-flive-patching=inline-only-static.
(can_inline_edge_by_limits_p): Add the checking for 
-flive-patching=inline-only-static and grant always_inline
even when -flive-patching=inline-only-static is specified. 

* gcc.dg/live-patching-4.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/live-patching-4.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-inline.c
trunk/gcc/testsuite/ChangeLog

[Bug target/89951] New: Uncorrect flag for Nehalem / westmere

2019-04-03 Thread bratsinot at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89951

Bug ID: 89951
   Summary: Uncorrect flag for Nehalem / westmere
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bratsinot at gmail dot com
  Target Milestone: ---

gcc set uncorrect flags -mavx256-split-unaligned-load and
-mavx256-split-unaligned-store when use -march=native or Nehalem / westmere
arch. Nehalem / westmere don't have AVX instruction set. So program with these
instructions build incorrectly.

For example:
# gcc -march=westmere -Q --help=target ... | grep avx
  -mavx [disabled]
  <...>
  -mavx256-split-unaligned-load [enabled]
  -mavx256-split-unaligned-store[enabled]
  <...>

[Bug fortran/49565] character(kind=4) is emitted as DW_ATE_unsigned, not DW_ATE_unsigned_char

2019-04-03 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49565

Dominique d'Humieres  changed:

   What|Removed |Added

   Priority|P3  |P4

--- Comment #11 from Dominique d'Humieres  ---
Frustrating!-(

[Bug fortran/41650] [Cleanup] Use gfc_expr_attr in resolve_allocate_expr/resolve_deallocate_expr

2019-04-03 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41650

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |INVALID

--- Comment #3 from Dominique d'Humieres  ---
> Is this still valid?

No answer, closing as INVALID.

[Bug c/89950] New: attribute aligned ignored with attribute vector_size

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89950

Bug ID: 89950
   Summary: attribute aligned ignored with attribute vector_size
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

When attribute aligned appears in conjunction with attribute vector_size on the
same declaration and when the former specifies a different alignment than the
latter attribute implies, the alignment specified by the former attribute is
ignored.

However, when attribute aligned is specified on a vector (re)declaration
without attribute vector_size, the alignment is honored.

$ cat z.c && gcc -O2 -S -Wall z.c
void f (void)
{
  typedef __attribute__ ((vector_size (1024))) int Vec_1k;
  typedef __attribute__ ((aligned (256)))  Vec_1k V;
  _Static_assert (__alignof__ (V) == 256);   // passes
  _Static_assert (__builtin_has_attribute (V, aligned (256)));   // passes

  V v;
  _Static_assert (__alignof__ (v) == 256);   // passes
  _Static_assert (__builtin_has_attribute (v, aligned (256)));   // passes
}

void g (void)
{
  typedef __attribute__ ((aligned (256), vector_size (1024))) int V;

  _Static_assert (__alignof__ (V) == 256);   // fails
  _Static_assert (__builtin_has_attribute (V, aligned (256)));   // fails

  V v;
  _Static_assert (__alignof__ (v) == 256);   // fails
  _Static_assert (__builtin_has_attribute (v, aligned (256)));   // fails
}
z.c: In function ‘g’:
z.c:17:3: error: static assertion failed
   17 |   _Static_assert (__alignof__ (V) == 256);   //
fails
  |   ^~
z.c:18:3: error: static assertion failed
   18 |   _Static_assert (__builtin_has_attribute (V, aligned (256)));   //
fails
  |   ^~
z.c:21:3: error: static assertion failed
   21 |   _Static_assert (__alignof__ (v) == 256);   //
fails
  |   ^~
z.c:22:3: error: static assertion failed
   22 |   _Static_assert (__builtin_has_attribute (v, aligned (256)));   //
fails
  |   ^~

[Bug fortran/89646] [7/8/9 Regression] Spurious actual argument might interfere warning

2019-04-03 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89646

--- Comment #5 from Dominique d'Humieres  ---
> I meant "replace the 0".

The replacement could be OPT_Wsurprising (-Wsurprising, included in -Wall) or
OPT_Wextra (-Wextra) or yet a new option.

The warning is tested in gfortran.dg/elemental_dependency_1.f90.

[Bug c++/89949] New: Internal compiler error with lambda as template argument

2019-04-03 Thread john.boyer at tutanota dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89949

Bug ID: 89949
   Summary: Internal compiler error with lambda as template
argument
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.boyer at tutanota dot com
  Target Milestone: ---

Since C++20 a template parameter type can be any LiteralType that has strong
structural equality.

Lambdas are classified as a LiteralType since C++17.

Reproducible example of the internal compiler error:
https://godbolt.org/z/UP3gG2.

Relevant cppreference pages:
https://en.cppreference.com/w/cpp/language/template_parameters
https://en.cppreference.com/w/cpp/named_req/LiteralType

[Bug c++/89948] New: [9 Regression] ICE in fold_convert_loc, at fold-const.c:2430

2019-04-03 Thread gs...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89948

Bug ID: 89948
   Summary: [9 Regression] ICE in fold_convert_loc, at
fold-const.c:2430
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20190217 and 20190224 :


$ cat z1.cc
void f ()
{
  int a = 0;
  for (;;)
for (;a=+({break;1;});)
  {}
}


$ g++-9-20190217 -c z1.cc
$
$ g++-9-20190224 -c z1.cc
z1.cc: In function 'void f()':
z1.cc:5:25: internal compiler error: in fold_convert_loc, at fold-const.c:2430
5 | for (;a=+({break;1;});)
  | ^
0x91f287 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2429
0x61f440 cxx_eval_constant_expression
../../gcc/cp/constexpr.c:4995
0x6200ac cxx_eval_store_expression
../../gcc/cp/constexpr.c:3678
0x61e18d cxx_eval_constant_expression
../../gcc/cp/constexpr.c:4582
0x6218d4 cxx_eval_outermost_constant_expr
../../gcc/cp/constexpr.c:5280
0x623c30 maybe_constant_value(tree_node*, tree_node*, bool)
../../gcc/cp/constexpr.c:5512
0x62e9b4 cp_fully_fold(tree_node*)
../../gcc/cp/cp-gimplify.c:2165
0x740c5b cp_build_binary_op(op_location_t const&, tree_code, tree_node*,
tree_node*, int)
../../gcc/cp/typeck.c:5539
0x742b1f build_binary_op(unsigned int, tree_code, tree_node*, tree_node*, bool)
../../gcc/cp/typeck.c:4246
0x742b63 cp_truthvalue_conversion(tree_node*)
../../gcc/cp/typeck.c:5866
0x63317e ocp_convert(tree_node*, tree_node*, int, int, int)
../../gcc/cp/cvt.c:844
0x634247 cp_convert(tree_node*, tree_node*, int)
../../gcc/cp/cvt.c:637
0x634247 cp_convert_and_check(tree_node*, tree_node*, int)
../../gcc/cp/cvt.c:656
0x5f7df1 convert_like_real
../../gcc/cp/call.c:7372
0x5f8950 perform_implicit_conversion_flags(tree_node*, tree_node*, int, int)
../../gcc/cp/call.c:11089
0x738a5a condition_conversion(tree_node*)
../../gcc/cp/typeck.c:5878
0x71f1a4 maybe_convert_cond
../../gcc/cp/semantics.c:1010
0x71f1a4 finish_for_cond(tree_node*, tree_node*, bool, unsigned short)
../../gcc/cp/semantics.c:991
0x6d2690 cp_parser_c_for
../../gcc/cp/parser.c:12148
0x6d2690 cp_parser_for
../../gcc/cp/parser.c:12116

[Bug middle-end/89934] [9 Regression] ICE on a call with fewer arguments to strncpy declared without prototype

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83655,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=83603

--- Comment #3 from Martin Sebor  ---
See also pr83603 and pr83655 for similar errors.

Now that GCC diagnoses calls with incompatible/incorrect arguments to built-ins
declared without a prototype the solution suggested in the review of the fix
for the latter:
  https://gcc.gnu.org/ml/gcc-patches/2018-01/msg00244.html
i.e., using gimple_call_builtin_p(), might be worth revisiting for GCC 10
(though it might be obviated by rejecting the incompatible calls or by
replacing them with traps).

[Bug c++/89947] New: Resolution of base classes fail for some automatic types in template struct functions

2019-04-03 Thread paolo at luccalug dot it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89947

Bug ID: 89947
   Summary: Resolution of base classes fail for some automatic
types in template struct functions
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paolo at luccalug dot it
  Target Milestone: ---

Created attachment 46081
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46081&action=edit
A minimal testcase

I'm using G++ 8.2.1 installed with the Arch Linux package `gcc
8.2.1+20181127-1`.

```
$ g++ -v
g++ (GCC) 8.2.1 20181127
Copyright (C) 2018 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.
```

A minimal source file that triggers the problem is the following:

```
namespace ns {
struct A { void f(){} };
}

template struct B { void f(){} };
struct C : public ns::A, B {};

template struct X { // NOTE: no error if X were not a template
C getC() { return C(); } // NOTE: no error if `getC` were outside of
this class
void f() {
// NOTE: no error if we're running this code from outside of
this class: `x.getC().A...`

getC().A::f(); // ‘A’ has not been declared
auto c4 = getC(); c4.A::f(); // ‘A’ has not been declared
decltype(getC()) c5 = getC(); c5.A::f(); // ‘A’ has not been
declared
C c6 = getC(); c6.A::f(); // this one works

getC().B::f(); // ‘template struct B’ used without
template parameters
auto c1 = getC(); c1.B::f(); // ‘template struct B’
used without template parameters
decltype(getC()) c2 = getC(); c1.B::f(); // ‘template
struct B’ used without template parameters
C c3 = getC(); c3.B::f(); // this one works
}
};

int main() {
X x;
x.f();
return 0;
}
```

G++ fails to build it with default options (and any options I tried):

```
$ g++ test.cpp 
test.cpp: In member function ‘void X::f()’:
test.cpp:14:10: error: ‘A’ has not been declared
   getC().A::f(); // ‘A’ has not been declared
  ^
test.cpp:15:24: error: ‘A’ has not been declared
   auto c4 = getC(); c4.A::f(); // ‘A’ has not been declared
^
test.cpp:16:36: error: ‘A’ has not been declared
   decltype(getC()) c5 = getC(); c5.A::f(); // ‘A’ has not been declared
^
test.cpp:19:10: error: ‘template struct B’ used without template
parameters
   getC().B::f(); // ‘template struct B’ used without template
parameters
  ^
test.cpp:20:24: error: ‘template struct B’ used without template
parameters
   auto c1 = getC(); c1.B::f(); // ‘template struct B’ used without
template parameters
^
test.cpp:21:36: error: ‘template struct B’ used without template
parameters
   decltype(getC()) c2 = getC(); c1.B::f(); // ‘template struct B’
used without template parameters
```

Clang (8.0.0) gives no error, and I believe that's the expected behavior.

[Bug c/89946] New: [8/9 Regression] ICE in assemble_start_function, at varasm.c:1871

2019-04-03 Thread gs...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89946

Bug ID: 89946
   Summary: [8/9 Regression] ICE in assemble_start_function, at
varasm.c:1871
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with gcc-8 (and values N < 0) :


$ cat z1.c
__attribute__((patchable_function_entry(-1)))
void f () {}


$ gcc-9-20190331 -c z1.c
during RTL pass: final
z1.c: In function 'f':
z1.c:2:1: internal compiler error: in assemble_start_function, at varasm.c:1871
2 | void f () {}
  | ^~~~
0xceabe6 assemble_start_function(tree_node*, char const*)
../../gcc/varasm.c:1871
0x7d8e2f rest_of_handle_final
../../gcc/final.c:4655
0x7d8e2f execute
../../gcc/final.c:4737

[Bug c++/86567] [8/9 Regression] -Wnonnull/-Wformat/-Wrestrict affect code generation

2019-04-03 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86567

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||dmalcolm at gcc dot gnu.org
 Depends on||56856
 Resolution|--- |FIXED

--- Comment #7 from Jason Merrill  ---
Fixed for GCC 9 by the patch for PR 56856, which removed that call to
maybe_constant_value.  Not worth backporting.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56856
[Bug 56856] -Wformat warnings don't show location *within* format string in C++
FE

[Bug bootstrap/86518] Strengthen bootstrap comparison by not enabling warnings at stage3

2019-04-03 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518
Bug 86518 depends on bug 86567, which changed state.

Bug 86567 Summary: [8/9 Regression] -Wnonnull/-Wformat/-Wrestrict affect code 
generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86567

   What|Removed |Added

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

[Bug target/89945] [7/8/9 Regression] ICE in gen_lowpart_general, at rtlhooks.c:63

2019-04-03 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89945

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target
   Target Milestone|--- |7.5

[Bug c/89945] New: [7/8/9 Regression] ICE in gen_lowpart_general, at rtlhooks.c:63

2019-04-03 Thread gs...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89945

Bug ID: 89945
   Summary: [7/8/9 Regression] ICE in gen_lowpart_general, at
rtlhooks.c:63
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects gcc-7 upwards at -O[s123], gcc-6 compiles it :


$ cat z1.c
void foo ()
{
  void *g[] = {&&a, &&b};
  for (unsigned c = 0x1F;; c >>= 1)
{
  unsigned d = (long)"a";
  long e = 8;
  while (e)
{
  a: goto *g[c&d];
  b: e--;
}
}
}


$ gcc-6  -c z1.c -O2
$ gcc-9-20190331 -c z1.c -O0
$
$ gcc-9-20190331 -c z1.c -O2
during RTL pass: split1
z1.c: In function 'foo':
z1.c:14:1: internal compiler error: in gen_lowpart_general, at rtlhooks.c:63
   14 | }
  | ^
0xa280f8 gen_lowpart_general(machine_mode, rtx_def*)
../../gcc/rtlhooks.c:63
0xf81f7e gen_split_144(rtx_insn*, rtx_def**)
../../gcc/config/i386/i386.md:8612
0x111247f split_17
../../gcc/config/i386/i386.md:1047
0x1117d94 split_insns(rtx_def*, rtx_insn*)
../../gcc/config/i386/i386.md:13199
0x796b11 try_split(rtx_def*, rtx_insn*, int)
../../gcc/emit-rtl.c:3851
0x9ea901 split_insn
../../gcc/recog.c:2901
0x9eea22 split_all_insns()
../../gcc/recog.c:3005
0x9eeb28 execute
../../gcc/recog.c:3905

[Bug target/89399] [7/8/9 Regression] ICE: RTL check: expected code 'set', 'clobber' or 'clobber_high', have 'parallel' in combine_reaching_defs, at ree.c:783

2019-04-03 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89399

--- Comment #5 from Jeffrey A. Law  ---
So I think in the immediate term any time we're using PATTERN (cand->insn) we
really should be using single_set (cand->insn).  We already know we've passed
the single_set test when we put the insn onto the candidate list.

I haven't audited all the uses of get_sub_rtx, but the ones I have looked at
look like it's used on the insn we're modifying rather than the candidate insn
(which is the extension we're trying to completely eliminate).

I'm going to spin the change to avoid incorrect uses of PATTERN (cand->insn) in
my tester.

[Bug c/89944] New: [7/8/9 Regression] ICE in mark_jump_label_1, at jump.c:1152

2019-04-03 Thread gs...@t-online.de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89944

Bug ID: 89944
   Summary: [7/8/9 Regression] ICE in mark_jump_label_1, at
jump.c:1152
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Gives an ICE down to gcc-4.6, gcc-4.5 (and others) accept it :


$ cat z1.c
void buf ()
{
  __builtin_setjmp (buf);
  __builtin_longjmp (buf, 1);
}


$ gcc-9-20190331 -c z1.c -O0
$
$ gcc-9-20190331 -c z1.c -O2
during RTL pass: cse1
z1.c: In function 'buf':
z1.c:5:1: internal compiler error: in mark_jump_label_1, at jump.c:1152
5 | }
  | ^
0x902146 mark_jump_label_1
../../gcc/jump.c:1152
0x901ec9 mark_jump_label_1
../../gcc/jump.c:1212
0x90243d mark_all_labels
../../gcc/jump.c:305
0x90243d rebuild_jump_labels_1
../../gcc/jump.c:74
0x115faa1 rest_of_handle_cse
../../gcc/cse.c:7687
0x115faa1 execute
../../gcc/cse.c:7721

[Bug middle-end/89934] [9 Regression] ICE on a call with fewer arguments to strncpy declared without prototype

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89934

Martin Sebor  changed:

   What|Removed |Added

   Keywords|ice-on-valid-code   |ice-on-invalid-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
Summary|[9 Regression] ICE in   |[9 Regression] ICE on a
   |tree_fits_uhwi_p, at|call with fewer arguments
   |tree.c:7237 |to strncpy declared without
   ||prototype

--- Comment #2 from Martin Sebor  ---
Declaring a built-in function with an incompatible signature is unsafe but GCC
only diagnoses it with -Wextra (starting with GCC 9).  Calling a library
function with fewer arguments than it expects is undefined.   Calling a
built-in function with fewer arguments is invalid and diagnosed (also starting
in GCC 9) but not rejected.

The call should either be rejected with an error (like Clang does) or replaced
with a trap to avoid the undefined behavior at runtime, but it's too late to
make that change for GCC 9.  Hopefully in GCC 10.

In the meantime, let me remove the assumption that the call is valid from the
-Wrestrict pass.

[Bug target/89929] __attribute__((target("avx512bw"))) doesn't work on non avx512bw systems

2019-04-03 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89929

--- Comment #7 from H.J. Lu  ---
__attribute__((target("foo"))) can be used in 2 different ways:

1. Enable FOO, which works for both C and C++.
2. Function versioning with FOO, which works only for C++.

2 is a subset of 1.  We should improve error message when target
is in 1, but outside of 2.

[Bug libstdc++/87431] valueless_by_exception() should unconditionally return false if all the constructors are noexcept

2019-04-03 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87431

--- Comment #18 from Jonathan Wakely  ---
Proposed new patch posted:
https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00142.html

[Bug rtl-optimization/81025] [8 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant

2019-04-03 Thread law at redhat dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025

Jeffrey A. Law  changed:

   What|Removed |Added

Summary|[8/9 Regression] gcc ICE|[8 Regression] gcc ICE
   |while building glibc for|while building glibc for
   |MIPS soft-float multi-lib   |MIPS soft-float multi-lib
   |variant |variant

--- Comment #18 from Jeffrey A. Law  ---
Fixed on the trunk.  Backporting to gcc-8 would be trivial, but I'm not sure
it's worth the effort.

[Bug rtl-optimization/81025] [8/9 Regression] gcc ICE while building glibc for MIPS soft-float multi-lib variant

2019-04-03 Thread law at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81025

--- Comment #17 from Jeffrey A. Law  ---
Author: law
Date: Wed Apr  3 16:03:37 2019
New Revision: 270129

URL: https://gcc.gnu.org/viewcvs?rev=270129&root=gcc&view=rev
Log:
PR rtl-optimization/81025
* reorg.c (skip_consecutive_labels): Do not skip past a BARRIER.

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

[Bug c++/89596] [8/9 regression] Multiple templated conversion operators result in compilation error

2019-04-03 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89596

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Jason Merrill  ---
Fixed by the patch for 86521.

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

[Bug c++/86521] [8 Regression] GCC 8 selects incorrect overload of ref-qualified conversion operator template

2019-04-03 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86521

Jason Merrill  changed:

   What|Removed |Added

 CC||jleahy+gcc at gmail dot com

--- Comment #10 from Jason Merrill  ---
*** Bug 89596 has been marked as a duplicate of this bug. ***

[Bug c++/89596] [8/9 regression] Multiple templated conversion operators result in compilation error

2019-04-03 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89596

Jason Merrill  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-03
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug c++/89331] [8/9 Regression] internal compiler error: in build_simple_base_path, at cp/class.c:589

2019-04-03 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89331

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #4 from Jason Merrill  ---
(In reply to Stas Sergeev from comment #2)
> (In reply to Jakub Jelinek from comment #1)
> > Simplified testcase:
> > struct A { char a; };
> > struct B : public A { static constexpr int b = __builtin_offsetof (B, a); };
> > 
> > clang rejects this too, not really sure if it is valid or not.
> 
> Thanks for taking a look!
> A slight off-topic: any idea why even this rejects:
> struct A {
> char a;
> static constexpr int b = __builtin_offsetof (A, a);
> };
> 
> and is there any work-around when I want to
> pass offsetof value into a template non-type,
> which also rejects:
> struct A {
> char a;
> B<__builtin_offsetof(A, a)> b;
> };
> 
> Does the standard explicitly forbids that, of just gcc?

The standard says that for a standard-layout class, the address of the first
member is the same as the address of the class, so offsetof(A,a) will be 0. 
But when we're in the middle of the class definition we don't know yet whether
it's standard-layout, so we can't answer yet.  A compiler is allowed to reorder
fields of a non-standard-layout class.

[Bug c++/89878] same specializations on a zero-initialized struct object as a non-type parameter treated as distinct

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89878

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-04-03
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=89833
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg0.html

[Bug c++/89833] [9 Regression] sorry, unimplemented: string literal in function template signature

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89833

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg0.html

[Bug c++/47488] sorry, unimplemented: string literal in function template signature

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47488

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
 CC||msebor at gcc dot gnu.org

--- Comment #14 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg0.html

[Bug middle-end/89797] ICE on a vector_size (1LU << 33) int variable

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89797

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #3 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00108.html

[Bug c++/87770] [8 Regression] ICE in type_dependent_expression_p, at cp/pt.c:25230

2019-04-03 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87770

Jason Merrill  changed:

   What|Removed |Added

 CC||roman.s.dubtsov at intel dot 
com

--- Comment #9 from Jason Merrill  ---
*** Bug 89919 has been marked as a duplicate of this bug. ***

[Bug c++/89919] [8/9 Regression] internal compiler error when building MKL-DNN

2019-04-03 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89919

Jason Merrill  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #5 from Jason Merrill  ---
Fixed on trunk by the patch for 87770.

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

[Bug c/89798] excessive vector_size silently accepted and truncated

2019-04-03 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89798

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #4 from Martin Sebor  ---
Patch: https://gcc.gnu.org/ml/gcc-patches/2019-04/msg00108.html

[Bug tree-optimization/89582] Suboptimal code generated for floating point struct in -O3 compare to -O2

2019-04-03 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89582

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #5 from H.J. Lu  ---
Is this a dup of PR 59464?

[Bug fortran/68567] ICE on using wrong defined arrays (different cases/messages)

2019-04-03 Thread dominiq at lps dot ens.fr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68567

--- Comment #8 from Dominique d'Humieres  ---
Packaging submitted at https://gcc.gnu.org/ml/fortran/2019-04/msg7.html.

[Bug c++/64095] [C++14] Ellipsis at end of generic lambda parameter-declaration-clause should be parsed as a parameter pack

2019-04-03 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095

--- Comment #16 from Jonathan Wakely  ---
(In reply to Seyyed Soroosh Hosseinalipour from comment #15)
> @jason what is work around for gcc6 ?

See comment 6. Name the pack.

[Bug lto/88643] -Wl,--wrap not supported with LTO

2019-04-03 Thread dilyan.palauzov at aegee dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643

--- Comment #11 from Дилян Палаузов  ---
Reported for ld.gold at https://sourceware.org/bugzilla/show_bug.cgi?id=24415 .

[Bug lto/88643] -Wl,--wrap not supported with LTO

2019-04-03 Thread dilyan.palauzov at aegee dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643

--- Comment #10 from Дилян Палаузов  ---
With the patch applied this works:

clang -flto -fuse-ld=bfd  -Wl,--wrap=read -O3 t.c
gcc   -flto -fuse-ld=bfd  -Wl,--wrap=read -O3 t.c
gcc   -flto -fuse-ld=bfd  -Wl,--wrap=read -O2 t.c
gcc   -flto -fuse-ld=bfd  -Wl,--wrap=read -O1 t.c

This does not work:

gcc   -flto -fuse-ld=gold -Wl,--wrap=read -O3 t.c
gcc   -flto -fuse-ld=gold -Wl,--wrap=read -O2 t.c
gcc   -flto -fuse-ld=gold -Wl,--wrap=read -O1 t.c

[Bug lto/88643] -Wl,--wrap not supported with LTO

2019-04-03 Thread dilyan.palauzov at aegee dot org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643

--- Comment #9 from Дилян Палаузов  ---
With the patch applied to ld.bfd “clang -flto -fuse-ld=bfd -Wl,--wrap=read t.c”
does work.

[Bug sanitizer/82501] AddressSanitizer does not handle negative offset for first global variable

2019-04-03 Thread a.drobyshev at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82501

--- Comment #31 from Andrey Drobyshev  ---
(In reply to Jakub Jelinek from comment #30)
> in a couple of most common data sections

In which sections exactly? If we cover only the most common ones (thus leaving
other sections which might need protection uncovered) there always be a case
when out patch won't work. On the other hand, if we include all the possible
sections which might need protection, the resulting binary would bloat with
unneeded sections.

[Bug tree-optimization/89582] Suboptimal code generated for floating point struct in -O3 compare to -O2

2019-04-03 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89582

--- Comment #4 from Richard Biener  ---
Looks like LLVM has all the ABI details exposed very early but also in a very
awkward way(?).  The vfloat one shows

define { <2 x float>, <2 x float> } @f(<2 x float> %x.coerce0, <2 x float>
%x.coerce1, <2 x float> %y.coerce0, <2 x float> %y.coerce1) #0 {
  %1 = alloca %struct.vfloat, align 16
  %x = alloca %struct.vfloat, align 16
  %y = alloca %struct.vfloat, align 16
  %2 = bitcast %struct.vfloat* %x to { <2 x float>, <2 x float> }*
  %3 = getelementptr inbounds { <2 x float>, <2 x float> }, { <2 x float>, <2 x
float> }* %2, i32 0, i32 0
  store <2 x float> %x.coerce0, <2 x float>* %3, align 16
  %4 = getelementptr inbounds { <2 x float>, <2 x float> }, { <2 x float>, <2 x
float> }* %2, i32 0, i32 1
  store <2 x float> %x.coerce1, <2 x float>* %4, align 8
  %5 = bitcast %struct.vfloat* %y to { <2 x float>, <2 x float> }*
  %6 = getelementptr inbounds { <2 x float>, <2 x float> }, { <2 x float>, <2 x
float> }* %5, i32 0, i32 0
  store <2 x float> %y.coerce0, <2 x float>* %6, align 16
  %7 = getelementptr inbounds { <2 x float>, <2 x float> }, { <2 x float>, <2 x
float> }* %5, i32 0, i32 1
  store <2 x float> %y.coerce1, <2 x float>* %7, align 8

for the parameter setup (if I deciper the IL correctly) and

  %32 = bitcast %struct.vfloat* %1 to { <2 x float>, <2 x float> }*
  %33 = load { <2 x float>, <2 x float> }, { <2 x float>, <2 x float> }* %32,
align 16
  ret { <2 x float>, <2 x float> } %33

for the return value.

I was thinking of a way to expose the ABI details to GIMPLE recently
but feared this would look a bit like a mess (also considering
prologue/epilogue expansion target constraints).

[Bug lto/88643] -Wl,--wrap not supported with LTO

2019-04-03 Thread hjl.tools at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88643

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #8 from H.J. Lu  ---
A linker patch is posted at

https://sourceware.org/ml/binutils/2019-04/msg00018.html

But it won't work with -O2 since LTO inlines cook before linker can wrap
it.

[Bug c++/64095] [C++14] Ellipsis at end of generic lambda parameter-declaration-clause should be parsed as a parameter pack

2019-04-03 Thread soorosh_abi at hotmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64095

Seyyed Soroosh Hosseinalipour  changed:

   What|Removed |Added

 CC||soorosh_abi at hotmail dot com

--- Comment #15 from Seyyed Soroosh Hosseinalipour  ---
ITNOA

@jason what is work around for gcc6 ?

thanks

[Bug c/71598] Wrong optimization with aliasing enums

2019-04-03 Thread clyon at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71598

--- Comment #15 from Christophe Lyon  ---
Author: clyon
Date: Wed Apr  3 13:17:04 2019
New Revision: 270126

URL: https://gcc.gnu.org/viewcvs?rev=270126&root=gcc&view=rev
Log:
[testsuite] PR71598: Fix testcases

2019-04-13  Christophe Lyon  

PR c/71598
* gcc.dg/torture/pr71598-1.c: Skip if short_enums target.
* gcc.dg/torture/pr71598-2.c: Skip if not short_enums target.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/torture/pr71598-1.c
trunk/gcc/testsuite/gcc.dg/torture/pr71598-2.c

[Bug libstdc++/89927] Inconsistent behavior in std::regex when optimized

2019-04-03 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89927

Jonathan Wakely  changed:

   What|Removed |Added

 Status|RESOLVED|NEW
 Resolution|INVALID |---

--- Comment #4 from Jonathan Wakely  ---
Please leave the bug open, as I said:

> It would be good if that assertion was more explanatory, or at least had a
> comment saying it will only be reached when given bad input. I'm confirming
> this bug as a reminder to improve that some time.

[Bug tree-optimization/89582] Suboptimal code generated for floating point struct in -O3 compare to -O2

2019-04-03 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89582

--- Comment #3 from Richard Biener  ---
(In reply to Richard Biener from comment #2)
> So compared to the already mitigated PR84101 this one returns in
> 
> (parallel:TI [
> (expr_list:REG_DEP_TRUE (reg:DF 20 xmm0)
> (const_int 0 [0]))
> (expr_list:REG_DEP_TRUE (reg:DF 21 xmm1)
> (const_int 8 [0x8]))
> ])
> 
> so I wonder how targets represent if they return the _same_ value in
> two different locations.  I also wonder whether the above is any
> standard form.

From docs of (set ...):

If @var{lval} is a @code{parallel}, it is used to represent the case of
a function returning a structure in multiple registers.  Each element
of the @code{parallel} is an @code{expr_list} whose first operand is a
@code{reg} and whose second operand is a @code{const_int} representing the
offset (in bytes) into the structure at which the data in that register
corresponds.  The first element may be null to indicate that the structure
is also passed partly in memory.

I guess if the offset is the same (or overlapping) that can handle
multiple locations for the same value.

For the vfloat testcase the return value on x86 is in the following
(note reg:DI pieces vs. reg:V2SF vs. reg:DF for the vdouble case)

(parallel:TI [
(expr_list:REG_DEP_TRUE (reg:DI 20 xmm0)
(const_int 0 [0]))
(expr_list:REG_DEP_TRUE (reg:DI 21 xmm1)
(const_int 8 [0x8]))
])

[Bug tree-optimization/89582] Suboptimal code generated for floating point struct in -O3 compare to -O2

2019-04-03 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89582

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
 Status|NEW |ASSIGNED
 CC||jakub at gcc dot gnu.org,
   ||law at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
  Component|target  |tree-optimization
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
So compared to the already mitigated PR84101 this one returns in

(parallel:TI [
(expr_list:REG_DEP_TRUE (reg:DF 20 xmm0)
(const_int 0 [0]))
(expr_list:REG_DEP_TRUE (reg:DF 21 xmm1)
(const_int 8 [0x8]))
])

so I wonder how targets represent if they return the _same_ value in
two different locations.  I also wonder whether the above is any
standard form.

Covering the above in the same way as PR84101 doesn't prevent vectorization:

t.c:8:14: note:  Cost model analysis:
  Vector inside of basic block cost: 48
  Vector prologue cost: 0
  Vector epilogue cost: 36
  Scalar cost of basic block: 96
t.c:8:14: note:  Basic block will be vectorized using SLP

even though we've added one vector store and two scalar loads to pessimize it.
Here the vector construction from the argument passing comes into play
which also isn't "pessimized" accordingly because the vectorizer thinks it
can perform vector loads from memory here, replacing four scalar loads
(but in fact x.x1, y.x1, x.x2 and y.x2 are readily available in %xmm0 to 3).

Another interesting testcase is

typedef struct {
float x1;
float x2;
float x3;
float x4;
} vfloat __attribute__((aligned(16)));

vfloat f(vfloat x, vfloat y)
{
  return (vfloat){x.x1 + y.x1, x.x2 + y.x2, x.x3 + y.x3, x.x4 + y.x4};
}

where the _scalar_ code is really awkward (even though for the vector
case the vectorizer still thinks it is all memory).  Passing two
floats in a single 8-bytes is a really odd ABI choice:

f:
.LFB0:
.cfi_startproc
movq%xmm0, %rdi
movq%xmm2, %r9
movq%xmm1, %rdx
movq%xmm3, %rcx
shrq$32, %rdi
addss   %xmm2, %xmm0
shrq$32, %r9
shrq$32, %rdx
movd%edi, %xmm5
shrq$32, %rcx
movd%r9d, %xmm6
movd%edx, %xmm7
addss   %xmm6, %xmm5
movd%ecx, %xmm4
movaps  %xmm1, %xmm6
addss   %xmm4, %xmm7
addss   %xmm3, %xmm6
movd%xmm5, %eax
movq%rax, %rsi
movd%xmm7, %edx
movd%xmm0, %eax
salq$32, %rsi
salq$32, %rdx
movd%xmm6, %ecx
orq %rsi, %rax
orq %rcx, %rdx
movq%rdx, %xmm1
movq%rax, %xmm0
ret

vs. vectorized:

f:
.LFB0:
.cfi_startproc
movq%xmm1, -32(%rsp)
movq%xmm0, -40(%rsp)
movaps  -40(%rsp), %xmm4
movq%xmm2, -24(%rsp)
movq%xmm3, -16(%rsp)
addps   -24(%rsp), %xmm4
movaps  %xmm4, -40(%rsp)
movq-32(%rsp), %rax
movq-40(%rsp), %xmm0
movq%rax, %xmm1
movq%rax, -24(%rsp)
ret

here the spilling is still bad (STLF penalties) but in the end vectorizing
this makes sense and we want to preserve that.

Lame attempt to handle PARALLELs:

Index: gcc/tree-vect-stmts.c
===
--- gcc/tree-vect-stmts.c   (revision 270123)
+++ gcc/tree-vect-stmts.c   (working copy)
@@ -1076,23 +1076,24 @@ vect_model_store_cost (stmt_vec_info stm
   && !aggregate_value_p (base, cfun->decl))
 {
   rtx reg = hard_function_value (TREE_TYPE (base), cfun->decl, 0, 1);
-  /* ???  Handle PARALLEL in some way.  */
+  int nregs = 1;
   if (REG_P (reg))
+   nregs = hard_regno_nregs (REGNO (reg), GET_MODE (reg));
+  /* ???  Handle PARALLEL better (see PR89582 for an example).  */
+  else if (GET_CODE (reg) == PARALLEL)
+   nregs = XVECLEN (reg, 0);
+  /* Assume that a single reg-reg move is possible and cheap,
+do not account for vector to gp register move cost.  */
+  if (nregs > 1)
{
- int nregs = hard_regno_nregs (REGNO (reg), GET_MODE (reg));
- /* Assume that a single reg-reg move is possible and cheap,
-do not account for vector to gp register move cost.  */
- if (nregs > 1)
-   {
- /* Spill.  */
- prologue_cost += record_stmt_cost (cost_vec, ncopies,
-vector_store,
-  

[Bug c++/89900] [9 Regression] ICE: Segmentation fault (in check_instantiated_arg)

2019-04-03 Thread paolo.carlini at oracle dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89900

--- Comment #2 from Paolo Carlini  ---
I think that ultimately this boils down to this code in grokdeclarator:

  if (type_was_error_mark_node && template_parm_flag)
/* FIXME we should be able to propagate the error_mark_node as is
   for other contexts too.  */
type = error_mark_node;
  else
type = integer_type_node;

where we use integer_type_node as a catch-all type in case of error. Certainly
using error_mark_node avoids this ICE, and many other I suppose, but we are not
ready yet to resolve the FIXME (what about GCC-10?!?). We may want to fix this
specific ICE in a different way, for the time being.

  1   2   >