[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

 Status|NEW |WAITING

--- Comment #4 from Thomas Koenig  ---
Waiting for a test case.

[Bug libstdc++/90252] PSTL test failures

[rodgertq at gcc dot gnu.org]

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

--- Comment #2 from Thomas Rodgers  ---
Author: rodgertq
Date: Tue May 21 04:37:45 2019
New Revision: 271451

URL: https://gcc.gnu.org/viewcvs?rev=271451=gcc=rev
Log:
tbb-backend effective target should check ability to link TBB

PR libstdc++/90252
* testsuite/lib/libstdc++.exp (check_effective_target_tbb-backend):
Changed v3_target_compile check from preprocess to executable.
Added "-ltbb" to v3_target_compile flags.

Modified:
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/lib/libstdc++.exp

[Bug middle-end/90549] missing -Wreturn-local-addr maybe returning an address of a local array plus offset

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Sebor  ---
Agreed.  Please go ahead abd create one.

I'm working on a combined patch for this and PR 71924.

[Bug tree-optimization/90525] Wrong offsets in warning text for -Warray-bounds (with subobject)

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
The part of -Warray-bounds that checks offsets in calls to built-ins (as
opposed to the subscript operator) is a part of the -Wrestrict implementation. 
It exists mainly to avoid some pathological instances of the latter warning in
corner cases.  Its goal isn't so much to detect writing past the end but to
catch invalid pointers formed by calls to the built-ins.  The warning also
detects past-the-end reads, including reads of padding bytes (this also isn't
necessarily by design, it just falls out of the invalid pointer checking).

  struct A { char a[2]; int c; } t;

  void f (void *p)
  {
__builtin_strcpy (t.a, "abc");   // no warning here :(
__builtin_strcpy (p, t.a);   // but -Warray-bounds here
  }

With that said, I agree the warning could be improved/made clearer.  The above
is just to explain why it works the way it does.

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

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
How many of these have been fixed by Martin's recent -Wformat-diag addition?

[Bug target/90545] [10 regression] gcc.target/powerpc/fold-vec-splats-floatdouble.c fails starting with r271022

[amodra at gmail dot com]

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

Alan Modra  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-21
 CC|amodra at gcc dot gnu.org  |
   Assignee|unassigned at gcc dot gnu.org  |amodra at gmail dot com
 Ever confirmed|0   |1

[Bug middle-end/90549] missing -Wreturn-local-addr maybe returning an address of a local array plus offset

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #1 from Eric Gallager  ---
I think there's enough bugs with -Wreturn-local-addr for it to have its own
meta-bug now...

[Bug c/90552] attribute((optimize(3))) not overriding -Os

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=86840

--- Comment #1 from Eric Gallager  ---
Another bug with __attribute__((optimize)) being ignored is bug 86840

[Bug target/63545] ICE when building GCC for ia64-hp-hpux11.23 in hash_table::find_slot_with_hash

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dave.anglin at bell dot net

--- Comment #8 from Eric Gallager  ---
cc-ing HPUX maintainer

[Bug middle-end/90553] Register allocation allocates post-incremented address-load of call to call-clobbered register

[hp at gcc dot gnu.org]

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

--- Comment #1 from Hans-Peter Nilsson  ---
(JFTR the cutnpaste got tangled with paste and tape everywhere; the newlib
function in newlib/libc/misc/init.c is named __libc_init_array)

[Bug middle-end/90553] Register allocation allocates post-incremented address-load of call to call-clobbered register

[hp at gcc dot gnu.org]

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-21
 Ever confirmed|0   |1

[Bug middle-end/90553] New: Register allocation allocates post-incremented address-load of call to call-clobbered register

[hp at gcc dot gnu.org]

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

Bug ID: 90553
   Summary: Register allocation allocates post-incremented
address-load of call to call-clobbered register
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
  Target Milestone: ---
Target: cris-elf

For this code, similar to the newlib newlib/libc/misc/init.c:__init_array
function, IRA is responsible for allocating a call-clobbered register for the
address to the array of functions to call.  To wit, that register is then
clobbered by the called function:

extern void (*p []) (void);

void f(int x)
{
  int i;
  for (i = 0; i < x; i++)
p[i]();
}

The generated code for cris-elf with -O2 for r271317 (leading ELF-assembly
sugar elided):
_f:
subq 4,$sp
move $srp,[$sp]
subq 8,$sp
movem $r1,[$sp]
cmpq 1,$r10
blt .L1
move.d $r10,$r1

move.d _p,$r9
clear.d $r0
.L3:
jsr [$r9+]
addq 1,$r0
cmp.d $r0,$r1
bne .L3
nop
.L1:
movem [$sp+],$r1
jump [$sp+]

To all those not fluent in CRIS assembly, in gcc-rtl, the call instruction is
(from the 312r.final dump):

(call_insn 16 14 17 (parallel [
(call (mem:QI (mem/f:SI (post_inc:SI (reg:SI 9 r9 [orig:27 ivtmp.7
] [27])) [1 MEM[base: _8, offset: 0B]+0 S4 A8]) [0 *_1 S1 A8])
(const_int 0 [0]))
(clobber (reg:SI 16 srp))
]) "t.c":7:5 220 {*expanded_call_non_v32}
 (expr_list:REG_UNUSED (reg:SI 9 r9 [orig:27 ivtmp.7 ] [27])
(expr_list:REG_INC (reg:SI 9 r9 [orig:27 ivtmp.7 ] [27])
(expr_list:REG_CALL_DECL (nil)
(nil
(nil))

That is, the address to call is loaded from the pointer in R9, which is
post-incremented.  The register R9 is call-clobbered and mentioned as such in
CALL_USED_REGISTERS.


In the IRA dump in 276r.ira, pseudo-register 27 is is allocated to register R9.
 Following ira-lives.c:process_bb_node_lives it's apparent that the
post-increment addressing is handled as the register being read at the
beginning of the call, and the updated value happening *after* the call.

It's open whether gcc *should* be able to handle this construct (a trivial
patch to ira-lives.c) or whether this should be deemed outside what gcc
currently can handle regarding register-allocation (the post-incrementing to be
disabled until post-reload and the documentation updated).  I'l marking this
middle-end for moment.  There's a tested patch, to be posted.

[Bug c/80502] Provide macro to indicate OpenMP SIMD support

[egallager at gcc dot gnu.org]

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

--- Comment #4 from Eric Gallager  ---
(In reply to Evan Nemerson from comment #3)
> (In reply to Jakub Jelinek from comment #2)
> > _OPENMP_SIMD is a bad idea, that namespace is reserved for OpenMP, so unless
> > it shows up in the OpenMP standard, it shouldn't be added.
> 
> Fair enough, I'll propose it to the OpenMP people:
> http://forum.openmp.org/forum/viewtopic.php?f=23=2031
> 
> > Why do you need a macro?  Just use #pragma omp simd etc. unconditionally,
> > compilers that don't have support for such pragmas will just ignore those.
> 
> Not necessarily; often they'll emit warnings (for GCC, -Wall even includes
> -Wunknown-pragmas). I'd much rather use the preprocessor in my code than
> teach people to disable warnings.
> 

Does Michael Klemm from that discussion have an account here on this bugzilla?

> I need to support alternatives in my code. For example, for SIMDe
> (), I try to support OpenMP SIMD and Cilk
> Plus, as well as compiler-specific pragmas for GCC (GCC ivdep), ICC (simd),
> and clang (clang loop ...), and I'd be happy to add more as necessary. I'd
> rather not end up with something like
> 
>   #pragma omp simd
>   #pragma simd
>   #pragma GCC ivdep
>   #pragma clang loop vectorize(enable)
>   for (...) { ... }
> 
> I'd much rather just have a few macros which will expand to the right pragma
> based on preprocessor macros. Right now I'm stuck using the much less
> expressive ivdep syntax for GCC unless *full* OpenMP support is enabled (or
> someone defines a macro manually to indicate OpenMP SIMD support).

[Bug c/59753] -Woverflow warning inconsistency with signed constant conversion between T_MAX+1 and UT_MAX vs larger than UT_MAX

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||dodji at gcc dot gnu.org

--- Comment #9 from Eric Gallager  ---
cc-ing diagnostics maintainers

[Bug c/80592] gcc fails to detect overflow in shift statement

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||dodji at gcc dot gnu.org

--- Comment #3 from Eric Gallager  ---
cc-ing diagnostics maintainers

[Bug testsuite/90503] [10 regression] gcc.target/i386/pr22076.c FAILs

[uros at gcc dot gnu.org]

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

--- Comment #6 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon May 20 22:24:38 2019
New Revision: 271445

URL: https://gcc.gnu.org/viewcvs?rev=271445=gcc=rev
Log:
PR testsuite/90503
* gcc.target/i386/pr22076.c (dg-options): Add -mno-sse2.
Remove -flax-vector-conversions.
(dg-additional-options): Remove.
(test): Change to void.  Declare m0 and m1 as __m64 and
cast initializer in a proper way.  Do not return result.
(dg-final): Scan for 2 instances of movq.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr22076.c

[Bug testsuite/90503] [10 regression] gcc.target/i386/pr22076.c FAILs

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Target|i?86, x86_64|x86_64
 Status|NEW |RESOLVED
  Component|target  |testsuite
 Resolution|--- |FIXED

--- Comment #5 from Uroš Bizjak  ---
Fixed.

[Bug target/90503] [10 regression] gcc.target/i386/pr22076.c FAILs

[uros at gcc dot gnu.org]

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

--- Comment #4 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon May 20 22:01:32 2019
New Revision: 271442

URL: https://gcc.gnu.org/viewcvs?rev=271442=gcc=rev
Log:
PR testsuite/90503
* gcc.target/i386/pr22076.c (dg-options): Add -mno-sse2.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr22076.c

[Bug lto/90500] ICE error in copy_forbiden

[joseph at codesourcery dot com]

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

--- Comment #17 from joseph at codesourcery dot com  ---
The copy attribute is intended to copy attributes that are properties of 
the function itself (e.g. "pure"), but not those that are properties of a 
particular symbol for the function (e.g. "visibility").  If target_clones 
does not make sense to copy, probably it should be excluded by the copy 
attribute.

[Bug bootstrap/90418] [10 Regression] powerpc-darwin9 bootstrap fails after r271013

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #15 from Jakub Jelinek  ---
Should be fixed now.

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

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2019-05-20
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com
   Target Milestone|--- |7.5
 Ever confirmed|0   |1

--- Comment #1 from Uroš Bizjak  ---
Patch in testing:

--cut here--
Index: config/i386/i386.md
===
--- config/i386/i386.md (revision 271430)
+++ config/i386/i386.md (working copy)
@@ -8525,6 +8525,14 @@
   operands[2] = shallow_copy_rtx (operands[2]);
   PUT_MODE (operands[2], SImode);
 }
+  else if (GET_CODE (operands[2]) == CONST)
+{
+  /* (const:DI (plus:DI (symbol_ref:DI ("...")) (const_int N))) */
+  operands[2] = copy_rtx (operands[2]);
+  PUT_MODE (operands[2], SImode);
+  PUT_MODE (XEXP (operands[2], 0), SImode);
+  PUT_MODE (XEXP (XEXP (operands[2], 0), 0), SImode);
+}
   else
 operands[2] = gen_lowpart (SImode, operands[2]);
 })
--cut here--

[Bug c++/55442] G++ uses up all my RAM when compiling a constexpr with exponential call graph

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jason Merrill  ---
(In reply to David Fendrich from comment #0)
> My guess is that this has something to do with unlimited memoization?

Yes.

GGC memory   GarbageFreed  
  LeakOverheadTimes

[...]
cp/constexpr.c:1761 (cxx_eval_call_expression)   0 :  0.0%0 : 
0.0%   73M: 18.5%0 :  0.0% 2340k
cp/constexpr.c:1420 (cxx_bind_parameters_in_call   182M: 96.7%0 : 
0.0%  182M: 46.2%0 :  0.0% 9362k

Both of these are involved with caching the values of constexpr calls.  Looking
at the code, it seems that we do the second allocation even when we get a cache
hit, and then don't free it, so it builds up until we can do GC later.

[Bug c++/59813] tail-call elimination didn't fire for left-shift of char to cout

[jakub at gcc dot gnu.org]

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

--- Comment #17 from Jakub Jelinek  ---
Author: jakub
Date: Mon May 20 21:33:46 2019
New Revision: 271440

URL: https://gcc.gnu.org/viewcvs?rev=271440=gcc=rev
Log:
PR c++/59813
PR target/90418
* function.h (struct function): Add calls_eh_return member.
* gimplify.c (gimplify_call_expr): Set cfun->calls_eh_return when
gimplifying __builtin_eh_return call.
* tree-inline.c (initialize_cfun): Copy calls_eh_return from src_cfun
to cfun.
(expand_call_inline): Or in src_cfun->calls_eh_return into
dst_cfun->calls_eh_return.
* tree-tailcall.c (suitable_for_tail_call_opt_p): Return false if
cfun->calls_eh_return.
* lto-streamer-in.c (input_struct_function_base): Read calls_eh_return.
* lto-streamer-out.c (output_struct_function_base): Write
calls_eh_return.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.h
trunk/gcc/gimplify.c
trunk/gcc/lto-streamer-in.c
trunk/gcc/lto-streamer-out.c
trunk/gcc/tree-inline.c
trunk/gcc/tree-tailcall.c

[Bug bootstrap/90418] [10 Regression] powerpc-darwin9 bootstrap fails after r271013

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
Author: jakub
Date: Mon May 20 21:33:46 2019
New Revision: 271440

URL: https://gcc.gnu.org/viewcvs?rev=271440=gcc=rev
Log:
PR c++/59813
PR target/90418
* function.h (struct function): Add calls_eh_return member.
* gimplify.c (gimplify_call_expr): Set cfun->calls_eh_return when
gimplifying __builtin_eh_return call.
* tree-inline.c (initialize_cfun): Copy calls_eh_return from src_cfun
to cfun.
(expand_call_inline): Or in src_cfun->calls_eh_return into
dst_cfun->calls_eh_return.
* tree-tailcall.c (suitable_for_tail_call_opt_p): Return false if
cfun->calls_eh_return.
* lto-streamer-in.c (input_struct_function_base): Read calls_eh_return.
* lto-streamer-out.c (output_struct_function_base): Write
calls_eh_return.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/function.h
trunk/gcc/gimplify.c
trunk/gcc/lto-streamer-in.c
trunk/gcc/lto-streamer-out.c
trunk/gcc/tree-inline.c
trunk/gcc/tree-tailcall.c

[Bug middle-end/89765] [9/10 Regression] Multiple problems with vec-insert implementation on PowerPC

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #16 from kelvin at gcc dot gnu.org ---
Patches committed to trunk and backported to gcc9, gcc8, and gcc7.

[Bug libgomp/90527] alloc.c:72:7: error: implicit declaration of function ‘posix_memalign’

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Mon May 20 21:29:49 2019
New Revision: 271439

URL: https://gcc.gnu.org/viewcvs?rev=271439=gcc=rev
Log:
PR libgomp/90527
* alloc.c (_GNU_SOURCE): Define.

Modified:
branches/gcc-9-branch/libgomp/ChangeLog
branches/gcc-9-branch/libgomp/alloc.c

[Bug target/89424] __builtin_vec_ext_v1ti (v, i) results in ICE with variable i (RS6000)

[kelvin at gcc dot gnu.org]

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

kelvin at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #5 from kelvin at gcc dot gnu.org ---
Patches committed to trunk and backported to gcc9, gcc8, and gcc7.

[Bug libgomp/90527] alloc.c:72:7: error: implicit declaration of function ‘posix_memalign’

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Mon May 20 21:29:17 2019
New Revision: 271438

URL: https://gcc.gnu.org/viewcvs?rev=271438=gcc=rev
Log:
PR libgomp/90527
* alloc.c (_GNU_SOURCE): Define.

Modified:
trunk/libgomp/ChangeLog
trunk/libgomp/alloc.c

[Bug c++/90548] [9/10 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:18877

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
I may have a fix.

[Bug c++/90548] [9/10 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:18877

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
We ended up with an empty call_args vec because the pack expanded here:
18842 /* Expand the pack expansion and push each entry onto
18843CALL_ARGS.  */
18844 arg = tsubst_pack_expansion (arg, args, complain,
in_decl);
expanded to an empty vector.  So nothing got pushed onto call_args.

[Bug middle-end/89765] [9/10 Regression] Multiple problems with vec-insert implementation on PowerPC

[kelvin at gcc dot gnu.org]

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

--- Comment #15 from kelvin at gcc dot gnu.org ---
Author: kelvin
Date: Mon May 20 20:07:12 2019
New Revision: 271436

URL: https://gcc.gnu.org/viewcvs?rev=271436=gcc=rev
Log:
gcc/ChangeLog:

2019-05-20  Kelvin Nilsen  

Backport from mainline.
2019-05-07  Kelvin Nilsen  

PR target/89765
* config/rs6000/rs6000-c.c (altivec_resolve_overloaded_builtin):
In handling of ALTIVEC_BUILTIN_VEC_INSERT, use modular arithmetic
to compute vector element selector for both constant and variable
operands.

gcc/testsuite/ChangeLog:

2019-05-20  Kelvin Nilsen  

Backport from mainline.
2019-05-07  Kelvin Nilsen  

PR target/89765
* gcc.target/powerpc/pr89765-mc.c: New test.
* gcc.target/powerpc/vsx-builtin-10c.c: New test.
* gcc.target/powerpc/vsx-builtin-10d.c: New test.
* gcc.target/powerpc/vsx-builtin-11c.c: New test.
* gcc.target/powerpc/vsx-builtin-11d.c: New test.
* gcc.target/powerpc/vsx-builtin-12c.c: New test.
* gcc.target/powerpc/vsx-builtin-12d.c: New test.
* gcc.target/powerpc/vsx-builtin-13c.c: New test.
* gcc.target/powerpc/vsx-builtin-13d.c: New test.
* gcc.target/powerpc/vsx-builtin-14c.c: New test.
* gcc.target/powerpc/vsx-builtin-14d.c: New test.
* gcc.target/powerpc/vsx-builtin-15c.c: New test.
* gcc.target/powerpc/vsx-builtin-15d.c: New test.
* gcc.target/powerpc/vsx-builtin-16c.c: New test.
* gcc.target/powerpc/vsx-builtin-16d.c: New test.
* gcc.target/powerpc/vsx-builtin-17c.c: New test.
* gcc.target/powerpc/vsx-builtin-17d.c: New test.
* gcc.target/powerpc/vsx-builtin-18c.c: New test.
* gcc.target/powerpc/vsx-builtin-18d.c: New test.
* gcc.target/powerpc/vsx-builtin-19c.c: New test.
* gcc.target/powerpc/vsx-builtin-19d.c: New test.
* gcc.target/powerpc/vsx-builtin-20c.c: New test.
* gcc.target/powerpc/vsx-builtin-20d.c: New test.
* gcc.target/powerpc/vsx-builtin-9c.c: New test.
* gcc.target/powerpc/vsx-builtin-9d.c: New test.


Added:
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/pr89765-mc.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10c.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-10d.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11c.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-11d.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12c.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-12d.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13c.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-13d.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14c.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-14d.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15c.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-15d.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16c.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-16d.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17c.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-17d.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-18c.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-18d.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-19c.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-19d.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20c.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-20d.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-9c.c
branches/gcc-7-branch/gcc/testsuite/gcc.target/powerpc/vsx-builtin-9d.c
Modified:
branches/gcc-7-branch/gcc/ChangeLog
branches/gcc-7-branch/gcc/config/rs6000/rs6000-c.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug tree-optimization/90525] Wrong offsets in warning text for -Warray-bounds (with subobject)

[miguel.ojeda.sandonis at gmail dot com]

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

--- Comment #2 from Miguel Ojeda  ---
I see. About offset 1: even if it is not (formally) out of bounds, memset will
end up dereferencing it. In the end, what users care about is that b and c are
being overwritten (even users that know about the one-past-the-last rules may
be surprised).

About offset 3, even if a particular memset function is implemented in C and
ends up with a pointer to offset 3 (internally), it will never be written to,
so why would it be mentioned?

Note: this is, again, just from the users' perspective :)

[Bug c++/85679] [DR2094] __is_trivially_copyable returns false with volatile scalar type

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #6 from Marek Polacek  ---
Fixed for GCC 10.  Not backporting this.

[Bug c++/85679] [DR2094] __is_trivially_copyable returns false with volatile scalar type

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek  ---
Author: mpolacek
Date: Mon May 20 19:10:57 2019
New Revision: 271435

URL: https://gcc.gnu.org/viewcvs?rev=271435=gcc=rev
Log:
CWG 2094 - volatile scalars are trivially copyable.
PR c++/85679
* tree.c (trivially_copyable_p): Don't check CP_TYPE_VOLATILE_P for
scalar types.

* g++.dg/ext/is_trivially_constructible1.C: Change the expected result
for volatile int.
* g++.dg/ext/is_trivially_copyable.C: New test.

* testsuite/20_util/is_trivially_copyable/value.cc: Change the expected
result for volatile int.

Added:
trunk/gcc/testsuite/g++.dg/ext/is_trivially_copyable.C
Modified:
trunk/gcc/cp/ChangeLog
trunk/gcc/cp/tree.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/ext/is_trivially_constructible1.C
trunk/libstdc++-v3/ChangeLog
trunk/libstdc++-v3/testsuite/20_util/is_trivially_copyable/value.cc

[Bug c++/83431] -Wformat-truncation may incorrectly report truncation

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
I'm working on the integration of the two passes for GCC 10.

[Bug c/90552] New: attribute((optimize(3))) not overriding -Os

[pskocik at gmail dot com]

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

Bug ID: 90552
   Summary: attribute((optimize(3))) not overriding -Os
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pskocik at gmail dot com
  Target Milestone: ---

I test-compiled ( https://gcc.godbolt.org/z/8bhbNa ):

__attribute((optimize(3))) int div(int X) { return X/3; }

with -O{0,1,2,3,s}, expecting to get the same assembly in all cases, but
__attribute((optimize(3))) is failing to override the last case, namely -Os.

(I'd like the function to not use the idiv instruction even if the rest of the
file is compiled with -Os).

Please correct me if I'm wrong to expect `__attribute((optimize(3)))` to be
able to override `-Os`.

This behavior appears to exist on all gcc versions.

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[tkoenig at gcc dot gnu.org]

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

--- Comment #3 from Thomas Koenig  ---
I think I have an idea what might be the problem.

Does the code do something like

call foo(a)

...

subroutine foo(a)
  real, dimension(:) :: a
  call bar(a,size(n))

...

subroutine bar(a,n)
  real, dimension(n) :: a

?

What might be missing for good performance is the
check for contiguous memory when calling bar.

[Bug testsuite/90551] New: New test case gcc.c-torture/compile/pr90263.c from r271400 reports unresolved

[seurer at gcc dot gnu.org]

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

Bug ID: 90551
   Summary: New test case gcc.c-torture/compile/pr90263.c from
r271400 reports unresolved
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

UNRESOLVED: gcc.c-torture/compile/pr90263.c   -O0   scan-assembler mempcpy
UNRESOLVED: gcc.c-torture/compile/pr90263.c   -O1   scan-assembler mempcpy
UNRESOLVED: gcc.c-torture/compile/pr90263.c   -O2   scan-assembler mempcpy
UNRESOLVED: gcc.c-torture/compile/pr90263.c   -O2 -flto -fno-use-linker-plugin
-flto-partition=none   scan-assembler mempcpy
UNRESOLVED: gcc.c-torture/compile/pr90263.c   -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects   scan-assembler mempcpy
UNRESOLVED: gcc.c-torture/compile/pr90263.c   -O3 -g   scan-assembler mempcpy
UNRESOLVED: gcc.c-torture/compile/pr90263.c   -Os   scan-assembler mempcpy

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/ -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O0 -w
-ffat-lto-objects -fno-ident -c -o pr90263.o
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.c-torture/compile/pr90263.c
PASS: gcc.c-torture/compile/pr90263.c   -O0  (test for excess errors)
gcc.c-torture/compile/pr90263.c   -O0  : output file does not exist
UNRESOLVED: gcc.c-torture/compile/pr90263.c   -O0   scan-assembler memcpy
Executing on host: /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/-fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never  -O1 -w
-ffat-lto-objects -fno-ident -c -o pr90263.o
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.c-torture/compile/pr90263.c   
(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/ -fno-diagnostics-show-caret
-fno-diagnostics-show-line-numbers -fdiagnostics-color=never -O1 -w
-ffat-lto-objects -fno-ident -c -o pr90263.o
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.c-torture/compile/pr90263.c
PASS: gcc.c-torture/compile/pr90263.c   -O1  (test for excess errors)
gcc.c-torture/compile/pr90263.c   -O1  : output file does not exist
UNRESOLVED: gcc.c-torture/compile/pr90263.c   -O1   scan-assembler memcpy

...and several more...

Is the test not set up properly to create an assembler file?



r271400 | marxin | 2019-05-20 02:55:00 -0500 (Mon, 20 May 2019) | 21 lines

Come up with hook libc_has_fast_function (PR middle-end/90263).

2019-05-20  Martin Liska  

PR middle-end/90263
* builtins.c (expand_builtin_memory_copy_args): When having a
target with fast mempcpy implementation do now use memcpy.
* config/i386/i386.c (ix86_libc_has_fast_function): New.
(TARGET_LIBC_HAS_FAST_FUNCTION): Likewise.
* doc/tm.texi: Likewise.
* doc/tm.texi.in: Likewise.
* target.def:
* expr.c (emit_block_move_hints): Add 2 new arguments.
* expr.h (emit_block_move_hints): Bail out when libcall
to memcpy would be used.
2019-05-20  Martin Liska  

PR middle-end/90263
* gcc.c-torture/compile/pr90263.c: New test.
* lib/target-supports.exp: Add check_effective_target_glibc.

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Jason, thoughts on this?

[Bug c++/88335] Implement P1073R3, C++20 immediate functions (consteval).

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Created attachment 46388
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46388=edit
gcc10-pr88335.patch

Untested WIP patch.  Need to decide now from where exactly to call the
immediate functions when not in immediate function contexts, shall that be done
say from build_call_a/build_over_call once the expression is built and if
nothing in the expression is dependent, or shall it be done say only from
cp_fold?  The latter seems better conceptually (that we don't fold stuff too
early), but might need to handle it also in various unevaluated codepaths.
Also, I guess if during !ctx->manifestly_const_eval constexpr evaluation we
encounter immediate function call, we need to evaluate the call separately in a
manifestly_const_eval mode and only then return back to the normal constexpr
evaluation.
Some work will need to be done to make sure we don't hand over immediate
functions to the middle-end, another question is what to do about virtual
immediate functions, for the constexpr evaluations we want to see them in
whatever data structures we have for virtual tables, but what we later hand
over to the middle-end and emit should not include those, what shall we do with
classes that don't have any virtual members other than immediate functions,
etc.

[Bug c++/83431] -Wformat-truncation may incorrectly report truncation

[mcroce at redhat dot com]

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

--- Comment #3 from Matteo Croce  ---
I can reproduce it with this snippet:

void f()
{
const char *dir = "a";
const char file[50] = "b";
char buf[4];
snprintf(buf, sizeof(buf), "%s/%s", dir, file);
}


$ gcc -Wall -c buf.c
buf.c: In function ‘f’:
buf.c:8:33: warning: ‘%s’ directive output may be truncated writing up to 49
bytes into a region of size 3 [-Wformat-truncation=]
8 |  snprintf(buf, sizeof(buf), "%s/%s", dir, file);
  | ^~   ~~~
buf.c:8:2: note: ‘snprintf’ output 2 or more bytes (assuming 51) into a
destination of size 4
8 |  snprintf(buf, sizeof(buf), "%s/%s", dir, file);
  |  ^~~~

$ gcc -v
Using built-in specs.
COLLECT_GCC=/usr/bin/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-redhat-linux
Configured with: ../configure --enable-bootstrap
--enable-languages=c,c++,fortran,objc,obj-c++,ada,go,d,lto --prefix=/usr
--mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-shared
--enable-threads=posix --enable-checking=release --enable-multilib
--with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions
--enable-gnu-unique-object --enable-linker-build-id
--with-gcc-major-version-only --with-linker-hash-style=gnu --enable-plugin
--enable-initfini-array --with-isl --enable-offload-targets=nvptx-none
--without-cuda-driver --enable-gnu-indirect-function --enable-cet
--with-tune=generic --with-arch_32=i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 9.1.1 20190503 (Red Hat 9.1.1-1) (GCC)

Regards,
Matteo Croce

[Bug target/90530] [9/10 Regression] Invalid SUBREG insn generated by reload

[dave.anglin at bell dot net]

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

--- Comment #17 from dave.anglin at bell dot net ---
On 2019-05-20 8:37 a.m., rguenth at gcc dot gnu.org wrote:
> AFAICS pa is using LRA now.
I wish.

[Bug libfortran/90038] execute_command_line should not use fork()

[jb at gcc dot gnu.org]

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

--- Comment #11 from Janne Blomqvist  ---
Author: jb
Date: Mon May 20 17:43:05 2019
New Revision: 271427

URL: https://gcc.gnu.org/viewcvs?rev=271427=gcc=rev
Log:
libfortran/90038 Use posix_spawn, reap dead children when wait=.false.

Backport from trunk.

When using posix_spawn or fork to launch a child process, the parent
needs to wait for the child, otherwise the dead child is left as a
zombie process. For this purpose one can install a signal handler for
SIGCHLD.

2019-05-20  Janne Blomqvist  

PR libfortran/90038
* intrinsics/execute_command_line (sigchld_handler): New function.
(execute_command_line): Install handler for SIGCHLD.
* configure.ac: Check for presence of sigaction and waitpid.
* config.h.in: Regenerated.
* configure: Regenerated.


fork() semantics can be problematic.  Most unix style OS'es have
posix_spawn which can be used to replace fork + exec in many cases.
For more information see
e.g.
https://www.microsoft.com/en-us/research/uploads/prod/2019/04/fork-hotos19.pdf

This replaces the one use of fork in libgfortran with posix_spawn.

2019-05-20  Janne Blomqvist  

PR libfortran/90038
* configure.ac (AC_CHECK_FUNCS_ONCE): Check for posix_spawn.
* intrinsics/execute_command_line (execute_command_line): Use
posix_spawn.
* Makefile.in: Regenerated.
* config.h.in: Regenerated.
* configure: Regenerated.

Regtested on x86_64-pc-linux-gnu.


Modified:
branches/gcc-9-branch/libgfortran/ChangeLog
branches/gcc-9-branch/libgfortran/Makefile.in
branches/gcc-9-branch/libgfortran/config.h.in
branches/gcc-9-branch/libgfortran/configure
branches/gcc-9-branch/libgfortran/configure.ac
branches/gcc-9-branch/libgfortran/intrinsics/execute_command_line.c

[Bug c++/87847] spec_hasher::hash does not match with spec_hasher::equal

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
Created attachment 46387
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46387=edit
patch to ignore type_canonical for TTP

Does this work better?

[Bug c++/61663] [DR 976] Deduction for const T& conversion functions

[ndkrempel at gmail dot com]

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

Nick Krempel  changed:

   What|Removed |Added

 CC||ndkrempel at gmail dot com

--- Comment #2 from Nick Krempel  ---
Clang accepts the code since at least as far back as 3.0.0.

[Bug middle-end/89371] missed vectorisation with "#pragma omp simd collapse(2)"

[arnaud02 at users dot sourceforge.net]

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

--- Comment #3 from Arnaud Desitter  ---
Considering:
#include 
#include 
#include 

void ff(double* res, double const* a, double const* b, int n1, int n2)
{
#pragma omp simd collapse(2)
  for(int i1=0; i1 < n1; ++i1)
  {
for(int i2=0; i2 < n2; ++i2)
{
  res[i1*n2+i2] = a[i1*n2+i2]-b[i1*n2+i2];
}
  }
}

int main()
{
  const auto repeat = 100*100;

  const std::size_t n1 = 100*1000;
  const std::size_t n2 = 3;

  std::vector res(n1*n2), a(n1*n2), b(n1*n2);
  std::iota(a.begin(), a.end(), 1.0);
  std::iota(b.begin(), b.end(), -200.0);

  for(int r=repeat; r>0; --r)
ff(res.data(), a.data(), b.data(), n1, n2);

  std::cout << res[0] << '\n';
}

Using clang 8.0:
>clang++ -O3 main2.cpp
>/usr/bin/time ./a.out > /dev/null
2.93user 0.00system 0:02.94elapsed 99%CPU (0avgtext+0avgdata 8424maxresident)k
>clang++ -fopenmp-simd -O3 main2.cpp > /dev/null
>/usr/bin/time ./a.out > /dev/null
2.83user 0.00system 0:02.83elapsed 99%CPU (0avgtext+0avgdata 8492maxresident)k
0inputs+0outputs (0major+2215minor)pagefaults 0swaps

Using gcc 9.1.0:
>g++ -O3 main2.cpp
>/usr/bin/time ./a.out > /dev/null
3.49user 0.00system 0:03.50elapsed 99%CPU (0avgtext+0avgdata 8488maxresident)k
0inputs+0outputs (0major+2215minor)pagefaults 0swaps
>g++ -fopenmp-simd -O3 main2.cpp
>/usr/bin/time ./a.out > /dev/null
5.83user 0.00system 0:05.84elapsed 99%CPU (0avgtext+0avgdata 8492maxresident)k
0inputs+0outputs (0major+2215minor)pagefaults 0swaps

clang 8.0 is able to produce vectorised code using "#pragma omp simd
collapse(2)" whereas gcc 9.1.0 cannot.

For record, clang 7.0 produces terrible code for this example.

[Bug fortran/90536] Spurious (?) warning when using -Wconversion with -fno-range-check

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #12 from Steve Kargl  ---
On Mon, May 20, 2019 at 03:06:32PM +, sgk at troutmask dot
apl.washington.edu wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90536
> 
> --- Comment #11 from Steve Kargl  ---
> On Mon, May 20, 2019 at 07:32:09AM +, tkoenig at gcc dot gnu.org wrote:
> > 
> > what I meant is that
> > 
> > Program main
> >   Integer(kind=1) :: n
> >   n = 1
> > End
> > 
> > should not warn with -fno-range-check -Wall, and it does.
> > 
> 
> The warning technically is correct.  It is a warning about the
> type conversion not about the value.
> 

Upon further reflection, not only is gfortran's behavior
correct, it is desireable.

This PR should be closed as INVALID.  Why?

For the above code, neither 

gfortran -c -Wconversion a.f90

nor 

gfortran -c -Wconversion-extra a.f90

emit a warning because gfortran does range checking,
determines that the INTEGER(4) '1' on the RHS is within
range of an INTEGER(1) 'n' on the LHS when type conversion
is done, and so chooses to suppress a conversion warning.

When a user uses -fno-range-check, she/he is specifically
asking the compiler to not range check.  gfortran only knows
that the RHS is an INTEGER(1) entity and the LHS is an
INTEGER(4) entity.  It has no other information upon which
to make a decision of whether to emit a warning.  So, 
gfortran informs the user that a conversion occurs.  There
is no other information without range checking.

[Bug c++/90550] ICE in determine_visibility, at cp/decl2.c:2567

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Started with r145440.  Before that:

90550.C: In function ‘void f() [with  = int]’:
90550.C:9:   instantiated from here
90550.C:5: error: ‘b’ has incomplete type

[Bug c++/90550] ICE in determine_visibility, at cp/decl2.c:2567

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/90548] [9/10 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:18877

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
(gdb) p (*call_args).is_empty()
$5 = true
so
tree arg = (*call_args)[i];
where i == 0 won't work.

[Bug c++/90546] [9.1 regression] Incorrect template argument deduction for conversion functions

[ndkrempel at gmail dot com]

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

--- Comment #2 from Nick Krempel  ---
However it's also worth noting that if you take the original snippet and change
the declaration of "test" to accept a const rvalue reference instead: "void
test(const Foo&&);", then gcc 9.1 (and all other gcc and clang versions tested)
agree that T = const Foo in that case. So even if the standard is ambiguous,
gcc is still somewhat inconsistent.

[Bug c++/90548] [9/10 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:18877

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-05-20
 CC||mpolacek at gcc dot gnu.org
   Target Milestone|--- |9.2
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
commit 64e3499e2386103c6842ffdf0b8eeae1d3798d29
Author: jason 
Date:   Wed Jan 30 02:43:04 2019 +

PR c++/86943 - wrong code converting lambda to function pointer.

In this PR, instantiating the static thunk returned from the generic lambda
conversion function template was using normal overload resolution, which
meant calling an extra constructor when forwarding its argument.  Fixed by
special-casing thunk calls significantly more.

* lambda.c (maybe_add_lambda_conv_op): Use a template-id in the
call.  Only forward parms for decltype.
* pt.c (tsubst_copy_and_build) [CALL_EXPR]: Handle
CALL_FROM_THUNK_P
specially.
* typeck.c (check_return_expr): Don't mess with a thunk call.

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

[Bug c++/90550] New: ICE in determine_visibility, at cp/decl2.c:2567

[gs...@t-online.de]

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

Bug ID: 90550
   Summary: ICE in determine_visibility, at cp/decl2.c:2567
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least gcc-4.5 :


$ cat z1.cc
template 
void f ()
{
  struct S { struct T typedef a; };
  struct S::a b;
}
void g ()
{
  f ();
}


$ g++-10-20190519 -c z1.cc
z1.cc: In instantiation of 'void f() [with  = int]':
z1.cc:9:11:   required from here
z1.cc:4:31: internal compiler error: Segmentation fault
4 |   struct S { struct T typedef a; };
  |   ^
0xb8ae7f crash_signal
../../gcc/toplev.c:326
0x64da44 determine_visibility(tree_node*)
../../gcc/cp/decl2.c:2567
0x68d077 do_pushtag
../../gcc/cp/name-lookup.c:6944
0x68d077 pushtag(tree_node*, tree_node*, tag_scope)
../../gcc/cp/name-lookup.c:6956
0x6ef215 lookup_template_class_1
../../gcc/cp/pt.c:9555
0x6ef215 lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../../gcc/cp/pt.c:9769
0x6efa85 tsubst_aggr_type
../../gcc/cp/pt.c:12777
0x6eacc9 tsubst_decl
../../gcc/cp/pt.c:13768
0x6e0be7 tsubst(tree_node*, tree_node*, int, tree_node*)
../../gcc/cp/pt.c:14378
0x6e1ccb perform_typedefs_access_check
../../gcc/cp/pt.c:10942
0x6e42b3 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:24743
0x6f9a0b instantiate_pending_templates(int)
../../gcc/cp/pt.c:24871
0x651755 c_parse_final_cleanups()
../../gcc/cp/decl2.c:4819

[Bug middle-end/90549] New: missing -Wreturn-local-addr maybe returning an address of a local array plus offset

[msebor at gcc dot gnu.org]

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

Bug ID: 90549
   Summary: missing -Wreturn-local-addr maybe returning an address
of a local array plus offset
   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: ---

While testing the enhancement to -Wreturn-local-addr in PR 71924 I noticed that
of the following two cases only the first one is diagnosed but the second
equivalent case is not.

$ cat a.c && gcc -O2 -S -Wall -fdump-tree-isolate-paths=/dev/stdout a.c
int a[2];

void* f (int i)
{
  int b[2];
  int *p = i ? [1] : [1];
  return p;// -Wreturn-local-addr (good)
}

void* g (int i)
{
  int b[2];

  int *p = i ? a : b;
  return p + 1;// missing -Wreturn-local-addr
}

;; Function f (f, funcdef_no=0, decl_uid=1907, cgraph_uid=1, symbol_order=1)

a.c: In function ‘f’:
a.c:7:10: warning: function may return address of local variable
[-Wreturn-local-addr]
7 |   return p;// -Wreturn-local-addr (good)
  |  ^
a.c:5:7: note: declared here
5 |   int b[2];
  |   ^

SSA replacement table
N_i -> { O_1 ... O_j } means that N_i replaces O_1, ..., O_j

iftmp.0_5 -> { iftmp.0_1 }
.MEM_6 -> { .MEM_4 }
Incremental SSA update started at block: 2
Number of blocks in CFG: 6
Number of blocks to update: 2 ( 33%)


Removing basic block 3
f (int i)
{
  int b[2];
  int * iftmp.0_1;
  int * iftmp.0_5;

   [local count: 1073741824]:
  if (i_2(D) == 0)
goto ; [0.00%]
  else
goto ; [100.00%]

   [local count: 536870912]:
  # iftmp.0_1 = PHI <[1](2)>
  b ={v} {CLOBBER};
  return iftmp.0_1;

   [count: 0]:
  # iftmp.0_5 = PHI <[1](2)>
  b ={v} {CLOBBER};
  return 0B;

}



;; Function g (g, funcdef_no=1, decl_uid=1912, cgraph_uid=2, symbol_order=2)

g (int i)
{
  int b[2];
  int * iftmp.1_1;
  void * _3;

   [local count: 1073741824]:
  if (i_2(D) == 0)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 536870913]:

   [local count: 1073741824]:
  # iftmp.1_1 = PHI <(2), (3)>
  _3 = iftmp.1_1 + 4;
  b ={v} {CLOBBER};
  return _3;

}

[Bug c++/90548] New: [9/10 Regression] ICE in tsubst_copy_and_build, at cp/pt.c:18877

[gs...@t-online.de]

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

Bug ID: 90548
   Summary: [9/10 Regression] ICE in tsubst_copy_and_build, at
cp/pt.c:18877
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

This changed between 20190127 and 20190203 :


$ cat z1.cc
struct S { S (void ()); }
foo ([] (auto ...) {});


$ g++-9-20190127 -c z1.cc
$
$ g++-10-20190519 -c z1.cc
z1.cc: In instantiation of 'static decltype (((const*)0)->operator()(static_cast(__lambda0::_FUN::) ...))::_FUN(auto:1 ...) [with auto:1 = {}; decltype (((const*)0)->operator()(static_cast(__lambda0::_FUN::) ...)) = void]':
z1.cc:2:21:   required from '::operator decltype
(((const*)0)->operator()(static_cast(__lambda0::_FUN::) ...)) (*)(auto:1 ...)()
const [with auto:1 = {}; decltype (((const*)0)->operator()(static_cast(__lambda0::_FUN::) ...)) = void]'
z1.cc:2:22:   required from here
z1.cc:2:21: internal compiler error: Segmentation fault
2 | foo ([] (auto ...) {});
  | ^
0xb8ae7f crash_signal
../../gcc/toplev.c:326
0x6dd614 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:18877
0x6e6609 tsubst_copy_and_build(tree_node*, tree_node*, int, tree_node*, bool,
bool)
../../gcc/cp/pt.c:18242
0x6e6609 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17918
0x6e557a tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17034
0x6e6291 tsubst_expr(tree_node*, tree_node*, int, tree_node*, bool)
../../gcc/cp/pt.c:17325
0x6e4764 instantiate_decl(tree_node*, bool, bool)
../../gcc/cp/pt.c:24755
0x6f9a0b instantiate_pending_templates(int)
../../gcc/cp/pt.c:24871
0x651755 c_parse_final_cleanups()
../../gcc/cp/decl2.c:4819

[Bug c++/90546] [9.1 regression] Incorrect template argument deduction for conversion functions

[ndkrempel at gmail dot com]

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

--- Comment #1 from Nick Krempel  ---
My interpretation of the standard didn't take into account the reference to
http://eel.is/c++draft/over.match.ref when determining the type A.

It says that A will be "lvalue reference to cv2 T2 ... where cv1 T is
reference-compatible with cv2 T2". Here "cv1 T" is "const Foo". This seems to
allows cv2 T2 to be either "Foo" or "const Foo", hence A can be either "Foo&"
or "const Foo&".

It's not clear which is supposed to be picked for use in the template argument
deduction in that case! It seems it was expected for there to be a unique type
from the wording:

"... with the type that is required as the result of the conversion (call it A;
..."

(note "*the* type", "call *it* A").

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

[gs...@t-online.de]

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

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

This is a follow-up of pr89945 :


$ cat z1.c
void
foo ()
{
  void *g[] = {&, &};

  for (unsigned c = 0x1F;; c >>= 1)
{
  unsigned d = "a"+1;
  long e = 8;

  while (e)
{
  a: goto *g[c];
  b: e--;
}
}
}


$ gcc-6 -c z1.c -O2
z1.c: In function 'foo':
z1.c:8:20: warning: initialization makes integer from pointer without a cast
[-Wint-conversion]
   unsigned d = "a"+1;
^~~

# gcc-10-20190519 -c z1.c  also compiles it.


$ gcc-10-20190519 -c z1.c -O2
z1.c: In function 'foo':
z1.c:8:20: warning: initialization of 'unsigned int' from 'char *' makes
integer from pointer without a cast [-Wint-conversion]
8 |   unsigned d = "a"+1;
  |^~~
during RTL pass: split1
z1.c:17:1: internal compiler error: in gen_lowpart_general, at rtlhooks.c:63
   17 | }
  | ^
0xa2e978 gen_lowpart_general(machine_mode, rtx_def*)
../../gcc/rtlhooks.c:63
0xf92b0e gen_split_144(rtx_insn*, rtx_def**)
../../gcc/config/i386/i386.md:8529
0x112a34f split_17
../../gcc/config/i386/i386.md:1062
0x112fd4c split_insns(rtx_def*, rtx_insn*)
../../gcc/config/i386/i386.md:13105
0x79c5f2 try_split(rtx_def*, rtx_insn*, int)
../../gcc/emit-rtl.c:3851
0x9f10f1 split_insn
../../gcc/recog.c:2901
0x9f5212 split_all_insns()
../../gcc/recog.c:3005
0x9f5318 execute
../../gcc/recog.c:3905
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++/88335] Implement P1073R3, C++20 immediate functions (consteval).

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/90546] New: [9.1 regression] Incorrect template argument deduction for conversion functions

[ndkrempel at gmail dot com]

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

Bug ID: 90546
   Summary: [9.1 regression] Incorrect template argument deduction
for conversion functions
   Product: gcc
   Version: 9.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ndkrempel at gmail dot com
  Target Milestone: ---

The following code deduces T = Foo using gcc 9.1, whereas gcc 8.3 (and clang 7
up) deduced T = const Foo. My reading of the standard (see below) is that T =
const Foo is correct.

struct Foo {};
void test(const Foo&);
struct Bar {
  template  operator T&&();
};
int main() {
  test(Bar{});
}

(compiled with -std=c++2a, but same behaviour with all language versions)

Relevant standards text: http://eel.is/c++draft/temp.deduct.conv
My reading of this applied to the above program is:
P is T&&, A is const Foo&
P is a reference type -> just treat as T from here on
A is not cv-qualified
A is a reference type -> use const Foo for type deduction
Now attempting to match T with const Foo succeeds with T = const Foo, so we
don't even need to consider the four bulleted exceptional cases ("These
alternatives are considered only if type deduction would otherwise fail.")

[Bug libstdc++/77691] [7/8/9/10 regression] experimental/memory_resource/resource_adaptor.cc FAILs

[redi at gcc dot gnu.org]

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

--- Comment #32 from Jonathan Wakely  ---
*** Bug 89732 has been marked as a duplicate of this bug. ***

[Bug libstdc++/89732] FAIL: experimental/memory_resource/new_delete_resource.cc execution test

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #4 from Jonathan Wakely  ---
I'm closing this, since the patch that caused it isn't actually committed.

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

[Bug target/90545] New: [10 regression] gcc.target/powerpc/fold-vec-splats-floatdouble.c fails starting with r271022

[seurer at gcc dot gnu.org]

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

Bug ID: 90545
   Summary: [10 regression]
gcc.target/powerpc/fold-vec-splats-floatdouble.c fails
starting with r271022
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

This happens on just power 9.

spawn -ignore SIGHUP /home3/seurer/gcc/build/gcc-test/gcc/xgcc
-B/home3/seurer/gcc/build/gcc-test/gcc/
/home/seurer/gcc/gcc-test/gcc/testsuite/gcc.target/powerpc/fold-vec-splats-floatdouble.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -mvsx -O1 -ffat-lto-objects -fno-ident -S -o
fold-vec-splats-floatdouble.s
PASS: gcc.target/powerpc/fold-vec-splats-floatdouble.c (test for excess errors)
gcc.target/powerpc/fold-vec-splats-floatdouble.c: xxpermdi found 0 times
FAIL: gcc.target/powerpc/fold-vec-splats-floatdouble.c scan-assembler-times
xxpermdi 1
PASS: gcc.target/powerpc/fold-vec-splats-floatdouble.c scan-assembler-times
\\mxscvdpspn?\\M 1
PASS: gcc.target/powerpc/fold-vec-splats-floatdouble.c scan-assembler-times
\\mvspltw\\M|\\mxxspltw\\M 1


test1f before r271022:

test1f:
.LFB1:
.cfi_startproc
xxpermdi 34,1,1,0
blr


After r271022:

test1f:
.LFB1:
.cfi_startproc
mfvsrd 9,1
mtvsrdd 34,9,9
blr


gcc.target/powerpc/fold-vec-splats-floatdouble.c:

/* Verify that overloaded built-ins for vec_splat with float and
   double inputs for VSX produce the right code.  */

/* { dg-do compile } */
/* { dg-require-effective-target powerpc_vsx_ok } */
/* { dg-options "-mvsx -O1" } */

#include 

vector float
test1d (float x)
{
  return vec_splats (x);
}

vector double
test1f (double x)
{
  return vec_splats (x);
}

// float test generates the permute instruction.
/* { dg-final { scan-assembler-times "xxpermdi" 1 } } */

// double test generates a convert (double to single non-signalling) followed
by a splat.
/* { dg-final { scan-assembler-times {\mxscvdpspn?\M} 1 } } */
/* { dg-final { scan-assembler-times {\mvspltw\M|\mxxspltw\M} 1 } } */

[Bug fortran/90536] Spurious (?) warning when using -Wconversion with -fno-range-check

[tkoenig at gcc dot gnu.org]

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

Thomas Koenig  changed:

   What|Removed |Added

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

[Bug tree-optimization/90525] Wrong offsets in warning text for -Warray-bounds (with subobject)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |UNCONFIRMED
 Ever confirmed|1   |0

--- Comment #1 from Martin Sebor  ---
The warning means to say that the pointers formed by adding the offsets to the
starting address are out-of-bounds.  Offset 1 from  isn't out-of-bounds --
it points just past the end of t.a (it just isn't dereferenceable).  But
offsets 2 and 3 definitely are out of the bounds of t.a.

[Bug c/90541] Warning not emitted on use of uninitialized variable

[wingo at igalia dot com]

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

--- Comment #2 from Andy Wingo  ---
Thanks for the information.  For what it's worth, clang issues a warning for
this code, and includes this warning under -Wall.

[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #4 from Steve Kargl  ---
On Mon, May 20, 2019 at 11:48:23AM +, egallager at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314
> 
> --- Comment #3 from Eric Gallager  ---
> is this an ice-on-valid or an ice-on-invalid?
> 

ice-on-valid

[Bug fortran/90536] Spurious (?) warning when using -Wconversion with -fno-range-check

[sgk at troutmask dot apl.washington.edu]

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

--- Comment #11 from Steve Kargl  ---
On Mon, May 20, 2019 at 07:32:09AM +, tkoenig at gcc dot gnu.org wrote:
> 
> what I meant is that
> 
> Program main
>   Integer(kind=1) :: n
>   n = 1
> End
> 
> should not warn with -fno-range-check -Wall, and it does.
> 

The warning technically is correct.  It is a warning about the
type conversion not about the value.

d.f90:3:6:

3 |   n = 1
  |  1
Warning: Conversion from 'INTEGER(4)' to 'INTEGER(1)' at (1) [-Wconversion]

Here '1' is INTEGER(4).  The assignment converts it to INTEGER(1).
Hence, a warning is issued.  Preventing range checking causes
one to take a different path through the compiler.  If -Wconversion
is active, then you shockingly might get a warning.  If a user
doesn't want to see warnings, don't ask for them!  In fact, one
might argument that if a warning isn't issued with either -Wconversion
or especially -Wconversion-extra, then these options are broken. 

Personally, I think this PR is much ado about nothing as one
can simply add -Wno-conversion to the options to suppress a
valid warning.  I closed the PR.  It has now been re-opened,
but mysteriously it has not be assigned.

[Bug tree-optimization/90106] builtin sqrt() ignoring libm's sqrt call result

[clyon at gcc dot gnu.org]

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

--- Comment #20 from Christophe Lyon  ---
Author: clyon
Date: Mon May 20 15:01:46 2019
New Revision: 271424

URL: https://gcc.gnu.org/viewcvs?rev=271424=gcc=rev
Log:
[testsuite] PR90106 Fix cdce3.c testcase

2019-05-20  Christophe Lyon  

PR tree-optimization/90106
* gcc.dg/cdce3.c: Add hard_float effective target.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/cdce3.c

[Bug target/90522] unrecognizable insn (V8SF)

[leonardo.sandoval.gonzalez at linux dot intel.com]

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

Leo Sandoval  changed:

   What|Removed |Added

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

[Bug target/90522] unrecognizable insn (V8SF)

[leonardo.sandoval.gonzalez at linux dot intel.com]

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

--- Comment #4 from Leo Sandoval  ---
I cannot reproduced the problem on neither on 10.0.0 nor gcc-9-branch. This
time I made sure that I had a clean build folder and starting from this, I did
not see the issue (somehow, when sharing the same build folder based on
different gcc versions, things go messy...).

For completeness, this is the output of gcc -v

/home/lsandov1/repos/tools-build/gcc-native/release/usr/gcc-10.0.0-native/bin/gcc
-v  
Using built-in specs.   
COLLECT_GCC=/home/lsandov1/repos/tools-build/gcc-native/release/usr/gcc-10.0.0-native/bin/gcc
 
COLLECT_LTO_WRAPPER=/home/lsandov1/repos/tools-build/gcc-native/release/usr/gcc-10.0.0-native/bin/../libexec/gcc/x86_64-pc-linux-gnu/10.0.0/lto-wrapper
 
Target: x86_64-pc-linux-gnu 
Configured with: /home/lsandov1/repos/gcc/configure --with-demangler-in-ld
--prefix=/usr/gcc-10.0.0-native --with-local-prefix=/usr/local
--enable-gnu-indirect-function --enable-clocale=gnu --with-system-zlib
--enable-libmpx --with-arch\
=native --with-cpu=native --with-fpmath=sse --enable-languages=c,c++,fortran
Thread model: posix 
gcc version 10.0.0 20190516 (experimental) (GCC)   

thanks Uros/Richard for your comments.

[Bug rtl-optimization/43147] SSE shuffle merge

[glisse at gcc dot gnu.org]

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

--- Comment #10 from Marc Glisse  ---
Author: glisse
Date: Mon May 20 14:53:29 2019
New Revision: 271422

URL: https://gcc.gnu.org/viewcvs?rev=271422=gcc=rev
Log:
[i386] Fold __builtin_ia32_shufpd to VEC_PERM_EXPR

2019-05-20  Marc Glisse  

PR rtl-optimization/43147
* config/i386/i386.c (ix86_gimple_fold_builtin): Handle
IX86_BUILTIN_SHUFPD.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[tkoenig at gcc dot gnu.org]

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

--- Comment #2 from Thomas Koenig  ---
I am a bit surprised at this, that the library version
of packing seems to be faster than the inlined one.

Or maybe some argument is now packed which should not be.

Increased code size is sort of expected, copying inline
is bigger than calling s library function. This is why
this is not done at -Os.

Is it possible to get a reduced test case that shows the
slowdown?

[Bug target/90530] [9/10 Regression] Invalid SUBREG insn generated by reload

[dave.anglin at bell dot net]

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

--- Comment #16 from dave.anglin at bell dot net ---
On 2019-05-20 8:14 a.m., rguenth at gcc dot gnu.org wrote:
>> My feeling is reload should respect  pa_can_change_mode_class().
> Maybe it's asking wrong since you have
>
>   if (GET_MODE_SIZE (from) == GET_MODE_SIZE (to))
> return true;
>
> and the size of the SUBREG_REG is the same as the FP reg?
Good point!

[Bug c/90541] Warning not emitted on use of uninitialized variable

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||amonakov at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from Alexander Monakov  ---
Documentation for -Wuninitialized points out that you need -Winit-self to catch
such patterns (and you do get a warning in that case). Seems to work exactly as
documented.

[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)

[amodra at gmail dot com]

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

--- Comment #10 from Alan Modra  ---
Yes, just like the function _ZN12Intermediate1vEv.

From here:
.set.LTHUNK0,_ZN12Intermediate1vEv

[Bug target/90513] asm thunks do not work on PowerPC64/VxWorks (kernel mode)

[segher at gcc dot gnu.org]

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

--- Comment #9 from Segher Boessenkool  ---
With a local entry offset?  Do you mean it has non-zero top three bits of
st_other?

[Bug bootstrap/90544] Build failure on MINGW for gcc-9.1.0

[baue.flor.dev at gmail dot com]

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

--- Comment #1 from Florian Bauer  ---
Created attachment 46386
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46386=edit
Occured error

[Bug bootstrap/90544] New: Build failure on MINGW for gcc-9.1.0

[baue.flor.dev at gmail dot com]

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

Bug ID: 90544
   Summary: Build failure on MINGW for gcc-9.1.0
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baue.flor.dev at gmail dot com
  Target Milestone: ---

Hello team,

the following problem (see attatchment GCCBuildError.PNG) occured during a
gcc-9.1.0 build on MINGW. I used 64-bit windows 7 as host system.

host=x86_64-w64-mingw32 
build=$host
target=aarch64-elf
targetlocal=mingw32
builddir=/build/${target}_9.1.0_x64
prefix=$builddir/cross-gcc/$target
prefixlocal=$builddir/host

Build commands:
--host=$host --build=$build --prefix=$prefix --target=$target --disable-nls
--enable-multilib --with-multilib-list=lp64,ilp32 --enable-languages=c,c++,d
--disable-decimal-float --with-sysroot=$prefix --without-headers
--disable-shared --disable-threads --disable-lto --disable-libmudflap
--disable-libssp --disable-libgomp --disable-libffi --disable-libstdcxx-pch
--disable-win32-registry '--with-host-libstdcxx=-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-newlib --with-gcc --with-gnu-as
--with-gnu-ld --with-gmp=$prefixlocal --with-mpfr=$prefixlocal
--with-mpc=$prefixlocal --with-isl=$prefixlocal

The file options-save.c contains invalid cast operations. Casting to
(uintptr_t) instead of (unsigned long) may solve the issue.

Info: options-save.c is auto-generated by optc-save-gen.awk.

I used the following fix in my case:

--- options-save.org.c  2019-05-20 12:52:48 +
+++ options-save.c  2019-05-20 11:36:06 +
@@ -3906,7 +3906,7 @@
 fprintf (file, "%*s%s (%#lx)\n",
  indent, "",
  "aarch64_branch_protection_string",
- (unsigned long)ptr->x_aarch64_branch_protection_string);
+ (uintptr_t)ptr->x_aarch64_branch_protection_string);

   if (ptr->x_target_flags)
 fprintf (file, "%*s%s (%#lx)\n",
@@ -3973,8 +3973,8 @@
 fprintf (file, "%*s%s (%#lx/%#lx)\n",
  indent, "",
  "aarch64_branch_protection_string",
- (unsigned long)ptr1->x_aarch64_branch_protection_string,
- (unsigned long)ptr2->x_aarch64_branch_protection_string);
+ (uintptr_t)ptr1->x_aarch64_branch_protection_string,
+ (uintptr_t)ptr2->x_aarch64_branch_protection_string);


Greetings,
Bauer Florian

[Bug bootstrap/90543] New: Build failure on MINGW for gcc-9.1.0

[baue.flor.dev at gmail dot com]

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

Bug ID: 90543
   Summary: Build failure on MINGW for gcc-9.1.0
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: baue.flor.dev at gmail dot com
  Target Milestone: ---

Created attachment 46385
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46385=edit
Occured error

Hello team,

the following problem (see attatchment GCCBuildError.PNG) occured during a
gcc-9.1.0 build on MINGW. I used 64-bit windows 7 as host system.

host=x86_64-w64-mingw32 
build=$host
target=aarch64-elf
targetlocal=mingw32
builddir=/build/${target}_9.1.0_x64
prefix=$builddir/cross-gcc/$target
prefixlocal=$builddir/host

Build commands:
--host=$host --build=$build --prefix=$prefix --target=$target --disable-nls
--enable-multilib --with-multilib-list=lp64,ilp32 --enable-languages=c,c++,d
--disable-decimal-float --with-sysroot=$prefix --without-headers
--disable-shared --disable-threads --disable-lto --disable-libmudflap
--disable-libssp --disable-libgomp --disable-libffi --disable-libstdcxx-pch
--disable-win32-registry '--with-host-libstdcxx=-static-libgcc
-Wl,-Bstatic,-lstdc++,-Bdynamic -lm' --with-newlib --with-gcc --with-gnu-as
--with-gnu-ld --with-gmp=$prefixlocal --with-mpfr=$prefixlocal
--with-mpc=$prefixlocal --with-isl=$prefixlocal

The file options-save.c contains invalid cast operations. Casting to
(uintptr_t) instead of (unsigned long) may solve the issue.

Info: options-save.c is auto-generated by optc-save-gen.awk.

I used the following fix in my case:

--- options-save.org.c  2019-05-20 12:52:48 +
+++ options-save.c  2019-05-20 11:36:06 +
@@ -3906,7 +3906,7 @@
 fprintf (file, "%*s%s (%#lx)\n",
  indent, "",
  "aarch64_branch_protection_string",
- (unsigned long)ptr->x_aarch64_branch_protection_string);
+ (uintptr_t)ptr->x_aarch64_branch_protection_string);

   if (ptr->x_target_flags)
 fprintf (file, "%*s%s (%#lx)\n",
@@ -3973,8 +3973,8 @@
 fprintf (file, "%*s%s (%#lx/%#lx)\n",
  indent, "",
  "aarch64_branch_protection_string",
- (unsigned long)ptr1->x_aarch64_branch_protection_string,
- (unsigned long)ptr2->x_aarch64_branch_protection_string);
+ (uintptr_t)ptr1->x_aarch64_branch_protection_string,
+ (uintptr_t)ptr2->x_aarch64_branch_protection_string);


Greetings,
Bauer Florian

[Bug libstdc++/90542] Build with --enable-libstdcxx-debug fails on Solaris due to symbol conflicts

[redi at gcc dot gnu.org]

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

--- Comment #2 from Jonathan Wakely  ---
It looks like the std::e[a-q]* pattern can simply be removed.

[Bug libstdc++/90542] Build with --enable-libstdcxx-debug fails on Solaris due to symbol conflicts

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
I haven't confirmed it, but I suspect this is a regression, because these
symbols are new in 9.1.0

[Bug libstdc++/90542] New: Build with --enable-libstdcxx-debug fails on Solaris due to symbol conflicts

[redi at gcc dot gnu.org]

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

Bug ID: 90542
   Summary: Build with --enable-libstdcxx-debug fails on Solaris
due to symbol conflicts
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: ro at gcc dot gnu.org
  Target Milestone: ---

/bin/sh ../../libtool --tag CXX   --mode=link
/export/home/jwakely/build/./gcc/xgcc -shared-libgcc
-B/export/home/jwakely/build/./gcc -nostdinc++
-L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/src
-L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/src/.libs
-L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs
-B/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/bin/
-B/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/lib/ -isystem
/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/include -isystem
/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/sys-include  
-fno-checking-std=gnu++98 -fPIC -DPIC -fno-implicit-templates  -Wall
-Wextra -Wwrite-strings -Wcast-qual -Wabi=2  -fdiagnostics-show-location=once  
-ffunction-sections -fdata-sections  -frandom-seed=libstdc++.la  -o
libstdc++.la -version-info 6:26:0 -Wl,-M,libstdc++-symbols.ver-sun -lm -rpath
/export/home/jwakely/gcc/9.1.0/lib/debug compatibility.lo
compatibility-debug_list.lo compatibility-debug_list-2.lo 
compatibility-c++0x.lo compatibility-atomic-c++0x.lo
compatibility-thread-c++0x.lo compatibility-chrono.lo compatibility-condvar.lo
-lrt ../../libsupc++/libsupc++convenience.la
../../src/debug/c++98/libc++98convenience.la
../../src/debug/c++11/libc++11convenience.la
../../src/debug/c++17/libc++17convenience.la 
libtool: link:  /export/home/jwakely/build/./gcc/xgcc -shared-libgcc
-B/export/home/jwakely/build/./gcc -nostdinc++
-L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/src
-L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/src/.libs
-L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs
-B/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/bin/
-B/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/lib/ -isystem
/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/include -isystem
/export/home/jwakely/gcc/9.1.0/sparc-sun-solaris2.11/sys-include  
-fno-checking -shared -nostdlib  /usr/lib/crti.o
/export/home/jwakely/build/./gcc/crtbegin.o  .libs/compatibility.o
.libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o
.libs/compatibility-c++0x.o .libs/compatibility-atomic-c++0x.o
.libs/compatibility-thread-c++0x.o .libs/compatibility-chrono.o
.libs/compatibility-condvar.o  -Wl,-z -Wl,allextract
../../libsupc++/.libs/libsupc++convenience.a
../../src/debug/c++98/.libs/libc++98convenience.a
../../src/debug/c++11/.libs/libc++11convenience.a
../../src/debug/c++17/.libs/libc++17convenience.a -Wl,-z -Wl,defaultextract 
-L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/libsupc++/.libs
-L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/src
-L/export/home/jwakely/build/sparc-sun-solaris2.11/libstdc++-v3/src/.libs -lm
-lrt -L/export/home/jwakely/build/./gcc -lgcc_s -lc -lgcc_s -lc
/export/home/jwakely/build/./gcc/crtend.o /usr/lib/crtn.o  -Wl,-M
-Wl,libstdc++-symbols.ver-sun   -Wl,-h -Wl,libstdc++.so.6 -o
.libs/libstdc++.so.6.0.26
ld: fatal: libstdc++-symbols.ver-sun: 5381: symbol
'std::enable_if > const&, std::basic_string_view > >,
std::__not_ > const*, std::__cxx11::basic_string, std::allocator > const*> >,
std::__not_ > const&, char const*> > >::value,
std::__cxx11::basic_string, std::allocator
>&>::type std::__cxx11::basic_string,
std::allocator >::append > >(std::basic_string_view
> const&)': symbol version conflict
ld: fatal: libstdc++-symbols.ver-sun: 5382: symbol
'std::enable_if > const&, std::basic_string_view > >,
std::__not_ > const*, std::__cxx11::basic_string, std::allocator > const*> >,
std::__not_ > const&, char const*> > >::value,
std::__cxx11::basic_string, std::allocator
>&>::type std::__cxx11::basic_string,
std::allocator >::append > >(std::basic_string_view
> const&)': symbol version conflict
ld: fatal: libstdc++-symbols.ver-sun: 5399: symbol
'std::enable_if > const&, std::basic_string_view > >,
std::__not_ > const*, std::__cxx11::basic_string, std::allocator > const*> >,
std::__not_ > const&, char const*> > >::value,
std::__cxx11::basic_string, std::allocator
>&>::type std::__cxx11::basic_string,
std::allocator >::assign > >(std::basic_string_view
> const&)': symbol version conflict
ld: fatal: libstdc++-symbols.ver-sun: 5400: symbol
'std::enable_if > const&, std::basic_string_view > >,
std::__not_ > const*, std::__cxx11::basic_string, std::allocator > const*> >,
std::__not_ > const&, char const*> > >::value,
std::__cxx11::basic_string, 

[Bug c++/90532] [8/9/10 Regression] is_constructible_v and is_default_constructible_v should agree

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #9 from Jonathan Wakely  ---
And on the branches too, for 8.4 and 9.2.

[Bug c++/90532] [8/9/10 Regression] is_constructible_v and is_default_constructible_v should agree

[redi at gcc dot gnu.org]

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

--- Comment #8 from Jonathan Wakely  ---
Author: redi
Date: Mon May 20 13:04:39 2019
New Revision: 271418

URL: https://gcc.gnu.org/viewcvs?rev=271418=gcc=rev
Log:
PR c++/90532 Ensure __is_constructible(T[]) is false

An array of an unknown bound is an incomplete type, so no object of such
a type can be constructed. This means __is_constructible should always
be false for an array of unknown bound.

This patch also changes the std::is_default_constructible trait to use
std::is_constructible, which now gives the right answer for arrays of
unknown bound.

gcc/cp:

Backported from mainline
2019-05-20  Jonathan Wakely  

PR c++/90532 Ensure __is_constructible(T[]) is false
* method.c (is_xible_helper): Return error_mark_node for construction
of an array of unknown bound.

gcc/testsuite:

Backported from mainline
2019-05-20  Jonathan Wakely  

PR c++/90532 Ensure __is_constructible(T[]) is false
* g++.dg/ext/90532.C: New test.

libstdc++-v3:

Backported from mainline
2019-05-20  Jonathan Wakely  

PR c++/90532 Ensure __is_constructible(T[]) is false
* include/std/type_traits (__do_is_default_constructible_impl)
(__is_default_constructible_atom, __is_default_constructible_safe):
Remove.
(is_default_constructible): Use is_constructible.
* testsuite/20_util/is_constructible/value.cc: Check int[] case.
* testsuite/20_util/is_default_constructible/value.cc: Likewise.
* testsuite/20_util/is_trivially_constructible/value.cc: Likewise.
* testsuite/20_util/is_trivially_default_constructible/value.cc:
Likewise.

Added:
branches/gcc-8-branch/gcc/testsuite/g++.dg/ext/90532.C
Modified:
branches/gcc-8-branch/gcc/cp/ChangeLog
branches/gcc-8-branch/gcc/cp/method.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/libstdc++-v3/ChangeLog
branches/gcc-8-branch/libstdc++-v3/include/std/type_traits
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/is_constructible/value.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/is_default_constructible/value.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/is_trivially_constructible/value.cc
   
branches/gcc-8-branch/libstdc++-v3/testsuite/20_util/is_trivially_default_constructible/value.cc

[Bug c++/90532] [8/9/10 Regression] is_constructible_v and is_default_constructible_v should agree

[redi at gcc dot gnu.org]

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

--- Comment #7 from Jonathan Wakely  ---
Author: redi
Date: Mon May 20 13:02:10 2019
New Revision: 271417

URL: https://gcc.gnu.org/viewcvs?rev=271417=gcc=rev
Log:
PR c++/90532 Ensure __is_constructible(T[]) is false

An array of an unknown bound is an incomplete type, so no object of such
a type can be constructed. This means __is_constructible should always
be false for an array of unknown bound.

This patch also changes the std::is_default_constructible trait to use
std::is_constructible, which now gives the right answer for arrays of
unknown bound.

gcc/cp:

Backported from mainline
2019-05-20  Jonathan Wakely  

PR c++/90532 Ensure __is_constructible(T[]) is false
* method.c (is_xible_helper): Return error_mark_node for construction
of an array of unknown bound.

gcc/testsuite:

Backported from mainline
2019-05-20  Jonathan Wakely  

PR c++/90532 Ensure __is_constructible(T[]) is false
* g++.dg/ext/90532.C: New test.

libstdc++-v3:

Backported from mainline
2019-05-20  Jonathan Wakely  

PR c++/90532 Ensure __is_constructible(T[]) is false
* include/std/type_traits (__do_is_default_constructible_impl)
(__is_default_constructible_atom, __is_default_constructible_safe):
Remove.
(is_default_constructible): Use is_constructible.
* testsuite/20_util/is_constructible/value.cc: Check int[] case.
* testsuite/20_util/is_default_constructible/value.cc: Likewise.
* testsuite/20_util/is_trivially_constructible/value.cc: Likewise.
* testsuite/20_util/is_trivially_default_constructible/value.cc:
Likewise.

Added:
branches/gcc-9-branch/gcc/testsuite/g++.dg/ext/90532.C
Modified:
branches/gcc-9-branch/gcc/cp/ChangeLog
branches/gcc-9-branch/gcc/cp/method.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog
branches/gcc-9-branch/libstdc++-v3/ChangeLog
branches/gcc-9-branch/libstdc++-v3/include/std/type_traits
   
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/is_constructible/value.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/is_default_constructible/value.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/is_trivially_constructible/value.cc
   
branches/gcc-9-branch/libstdc++-v3/testsuite/20_util/is_trivially_default_constructible/value.cc

[Bug testsuite/58321] FAIL: gcc.target/i386/memcpy-strategy-3.c scan-assembler-times memcpy 2 on x86_64-apple-darwin*

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

   Target Milestone|--- |7.5

[Bug target/90530] [9/10 Regression] Invalid SUBREG insn generated by reload

[rguenth at gcc dot gnu.org]

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

--- Comment #15 from Richard Biener  ---
(In reply to Richard Biener from comment #14)
> (In reply to dave.anglin from comment #13)
> > On 2019-05-20 6:26 a.m., rguenth at gcc dot gnu.org wrote:
> > > most definitely a reload as
> > >
> > > +(insn 177 176 178 2 (set (reg:SI 52 %fr24)
> > > +(subreg:SI (reg:DI 51 %fr23) 4)) -1
> > > + (nil))
> > >
> > > which isn't recognized isn't good.  I don't know PA on what it can
> > > and what not but these kind of sets from subregs appear during RTL
> > > expansion for
> > This isn't recognized because the only way to do it in general is to spill
> > reg:DI 51 to memory
> > and to read it back in SI mode.
> 
> Yeah, and for the C testcase it does...
> 
> >  Maybe we are lucky with the const_int
> > because some values
> > are forced constant pool.
> > 
> > There are no convert instructions other than sf<=>df mode and loads don't
> > zero extend as
> > they do to the integer registers.
> > 
> > As I said, pa_can_change_mode_class() is written to prevent mode changes in
> > the FP registers:
> > 
> >   /* There is no way to load QImode or HImode values directly from memory
> >  to a FP register.  SImode loads to the FP registers are not zero
> >  extended.  On the 64-bit target, this conflicts with the definition
> >  of LOAD_EXTEND_OP.  Thus, we can't allow changing between modes with
> >  different sizes in the floating-point registers.  */
> >   if (MAYBE_FP_REG_CLASS_P (rclass))
> >     return false;
> > 
> > My feeling is reload should respect  pa_can_change_mode_class().
> 
> Maybe it's asking wrong since you have
> 
>   if (GET_MODE_SIZE (from) == GET_MODE_SIZE (to))
> return true;
> 
> and the size of the SUBREG_REG is the same as the FP reg?  You'd need
> to debug here.

The only uses of can_change_mode_class are from old reload.c
and via REG_CAN_CHANGE_MODE_P (also mostly used from old reload).
AFAICS pa is using LRA now.

[Bug testsuite/58321] FAIL: gcc.target/i386/memcpy-strategy-3.c scan-assembler-times memcpy 2 on x86_64-apple-darwin*

[iains at gcc dot gnu.org]

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

--- Comment #8 from Iain Sandoe  ---
Author: iains
Date: Mon May 20 12:28:18 2019
New Revision: 271415

URL: https://gcc.gnu.org/viewcvs?rev=271415=gcc=rev
Log:
darwin, testsuite - fix PR58321

Darwin doesn't emit a .file directive by default
and one of the scan-asm hits for ELF targets comes from
this directive. Adjust for Darwin and explain.

2019-05-20  Iain Sandoe  

PR testsuite/58321
* gcc.target/i386/memcpy-strategy-3.c: Adjust count for Darwin and
add a comment as to the reason for the difference.
* gcc.target/i386/memset-strategy-1.c: Likewise.


Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/memcpy-strategy-3.c
trunk/gcc/testsuite/gcc.target/i386/memset-strategy-1.c

[Bug target/90530] [9/10 Regression] Invalid SUBREG insn generated by reload

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||ra
 CC||vmakarov at gcc dot gnu.org

--- Comment #14 from Richard Biener  ---
(In reply to dave.anglin from comment #13)
> On 2019-05-20 6:26 a.m., rguenth at gcc dot gnu.org wrote:
> > most definitely a reload as
> >
> > +(insn 177 176 178 2 (set (reg:SI 52 %fr24)
> > +(subreg:SI (reg:DI 51 %fr23) 4)) -1
> > + (nil))
> >
> > which isn't recognized isn't good.  I don't know PA on what it can
> > and what not but these kind of sets from subregs appear during RTL
> > expansion for
> This isn't recognized because the only way to do it in general is to spill
> reg:DI 51 to memory
> and to read it back in SI mode.

Yeah, and for the C testcase it does...

>  Maybe we are lucky with the const_int
> because some values
> are forced constant pool.
> 
> There are no convert instructions other than sf<=>df mode and loads don't
> zero extend as
> they do to the integer registers.
> 
> As I said, pa_can_change_mode_class() is written to prevent mode changes in
> the FP registers:
> 
>   /* There is no way to load QImode or HImode values directly from memory
>  to a FP register.  SImode loads to the FP registers are not zero
>  extended.  On the 64-bit target, this conflicts with the definition
>  of LOAD_EXTEND_OP.  Thus, we can't allow changing between modes with
>  different sizes in the floating-point registers.  */
>   if (MAYBE_FP_REG_CLASS_P (rclass))
>     return false;
> 
> My feeling is reload should respect  pa_can_change_mode_class().

Maybe it's asking wrong since you have

  if (GET_MODE_SIZE (from) == GET_MODE_SIZE (to))
return true;

and the size of the SUBREG_REG is the same as the FP reg?  You'd need
to debug here.

[Bug c/90541] New: Warning not emitted on use of uninitialized variable

[wingo at igalia dot com]

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

Bug ID: 90541
   Summary: Warning not emitted on use of uninitialized variable
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wingo at igalia dot com
  Target Milestone: ---

$ gcc --version
gcc (GCC) 9.1.0
Copyright (C) 2019 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.

$ cat /tmp/foo.c
#include 

uint16_t read_short(void) {
  uint16_t *loc = (uint16_t*)loc;
  return loc[0];
}

$ gcc -Wall -o /tmp/foo.o -c /tmp/foo.c



I would have expected that "uint16_t *loc = (uint16_t*)loc" issues an
uninitialized variable warning, but no warning is emitted.

[Bug preprocessor/90400] _Pragma not always expanded in the right location within macros

[p...@gcc-bugzilla.mail.kapsi.fi]

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

Pekka S  changed:

   What|Removed |Added

 CC||p...@gcc-bugzilla.mail.kaps
   ||i.fi

--- Comment #3 from Pekka S  ---
Created attachment 46384
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46384=edit
_Pragma tests

These all yield different results, the first two won't compile but fail on
different lines, which is a bit strange, as the preprocessor output doesn't
appear to change (e.g. if only doing -E).

The last one compiles, but obviously just because it omits the pragmas. GCC10
and GCC7 behave both the same with this test setup, so I suspect this is a long
standing feature and/or issue.

gcc -Wall -Wextra -c pragma.c
gcc -Wall -Wextra -save-temps -c pragma.c
gcc -Wall -Wextra -save-temps -DNOPRAGMA -c pragma.c

[Bug target/90530] [9/10 Regression] Invalid SUBREG insn generated by reload

[dave.anglin at bell dot net]

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

--- Comment #13 from dave.anglin at bell dot net ---
On 2019-05-20 6:26 a.m., rguenth at gcc dot gnu.org wrote:
> most definitely a reload as
>
> +(insn 177 176 178 2 (set (reg:SI 52 %fr24)
> +(subreg:SI (reg:DI 51 %fr23) 4)) -1
> + (nil))
>
> which isn't recognized isn't good.  I don't know PA on what it can
> and what not but these kind of sets from subregs appear during RTL
> expansion for
This isn't recognized because the only way to do it in general is to spill
reg:DI 51 to memory
and to read it back in SI mode.  Maybe we are lucky with the const_int because
some values
are forced constant pool.

There are no convert instructions other than sf<=>df mode and loads don't zero
extend as
they do to the integer registers.

As I said, pa_can_change_mode_class() is written to prevent mode changes in the
FP registers:

  /* There is no way to load QImode or HImode values directly from memory
 to a FP register.  SImode loads to the FP registers are not zero
 extended.  On the 64-bit target, this conflicts with the definition
 of LOAD_EXTEND_OP.  Thus, we can't allow changing between modes with
 different sizes in the floating-point registers.  */
  if (MAYBE_FP_REG_CLASS_P (rclass))
    return false;

My feeling is reload should respect  pa_can_change_mode_class().

The left and right halves of the float doubles are separately addressable, so
in this particular case
the pattern could be implemented using register renaming, but that was never
done.

[Bug c/70378] wrong warning with -Wconversion with explicit cast

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org,
   ||dodji at gcc dot gnu.org

--- Comment #5 from Eric Gallager  ---
cc-ing diagnostics maintainers

[Bug testsuite/58321] FAIL: gcc.target/i386/memcpy-strategy-3.c scan-assembler-times memcpy 2 on x86_64-apple-darwin*

[iains at gcc dot gnu.org]

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

--- Comment #7 from Iain Sandoe  ---
(In reply to Eric Gallager from comment #6)
> (In reply to Dominique d'Humieres from comment #3)
> > Still present at r220301 (see
> > https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg03581.html). Does the
> > patch in comment 2 makes sense or is there a better fix?
> 
> cc-ing FX from that

I have a local patch for this too, which I'm intending to apply as time
permits.  The main difference is explaining the reason that Darwin is different
- and simplifying the condition.

 /* { dg-do compile } */
 /* { dg-options "-O2 -march=atom
-mmemcpy-strategy=vector_loop:2000:align,libcall:-1:align" } */
-/* { dg-final { scan-assembler-times "memcpy" 2  } } */
+/* one hit comes from the .file directive.  */
+/* { dg-final { scan-assembler-times "memcpy" 2 { target { ! *-*-darwin* } } }
} */
+/* but not on Darwin.  */
+/* { dg-final { scan-assembler-times "_memcpy" 1  { target *-*-darwin* } } }
*/

 char a[2048];
 char b[2048];

[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

--- Comment #12 from Jonathan Wakely  ---
Yes.

[Bug libstdc++/66742] abort on sorting list with custom allocator that is not stateless

[egallager at gcc dot gnu.org]

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

--- Comment #11 from Eric Gallager  ---
Are you still working on this, Jonathan?

[Bug fortran/90539] [10 Regression] 481.wrf slowdown by 25% on Intel Kaby with -Ofast -march=native starting with r271377

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Haswell as well
(https://gcc.opensuse.org/gcc-old/SPEC/CFP/sb-czerny-head-64-2006/recent.html)
but only 10% and not bisected.

[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972

[egallager at gcc dot gnu.org]

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

--- Comment #3 from Eric Gallager  ---
is this an ice-on-valid or an ice-on-invalid?

[Bug testsuite/58321] FAIL: gcc.target/i386/memcpy-strategy-3.c scan-assembler-times memcpy 2 on x86_64-apple-darwin*

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||fxcoudert at gcc dot gnu.org

--- Comment #6 from Eric Gallager  ---
(In reply to Dominique d'Humieres from comment #3)
> Still present at r220301 (see
> https://gcc.gnu.org/ml/gcc-testresults/2015-01/msg03581.html). Does the
> patch in comment 2 makes sense or is there a better fix?

cc-ing FX from that

[Bug c++/90532] [8/9/10 Regression] is_constructible_v and is_default_constructible_v should agree

[redi at gcc dot gnu.org]

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

--- Comment #6 from Jonathan Wakely  ---
Fixed on trunk so far.