[Bug middle-end/91060] [10 regression] gcc.c-torture/execute/scal-to-vec1.c fails on armeb-none-linux-gnueabihf since r272843

[rsandifo at gcc dot gnu.org]

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

--- Comment #9 from rsandifo at gcc dot gnu.org  
---
(In reply to rsand...@gcc.gnu.org from comment #7)
> (In reply to Christophe Lyon from comment #4)
> > Unfortunately, it's still failing as of r273133.
> > 
> > It fails at the very first check:
> > v1 = 2 + v0;   check (short, 8, v0, v1, 2, +, l);
> > 
> > The generated code for main is:
> > main:
> ...
> > vmov.16 d16[0], r0
> > sxthr1, r0
> > vadd.i16q0, q8, q9
> > add ip, r1, #2
> > vmov.s16r2, d0[3]
> 
> Yeah, this looks wrong.  We should be adding 2 to a single element
> here, but we're extracting from one index and inserting into another.
> The first quoted instruction should be using [3] as well.
> 
> I'd be unsurprised if this was a target bug.

Er, pretend that message never happened, first thing Monday morning :-)

[Bug middle-end/91060] [10 regression] gcc.c-torture/execute/scal-to-vec1.c fails on armeb-none-linux-gnueabihf since r272843

[clyon at gcc dot gnu.org]

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

--- Comment #8 from Christophe Lyon  ---
(In reply to Richard Biener from comment #5)
> Hmm, using a cross configured as
> 
> trunk/configure --target=armeb-none-linux-gnueabihf --with-cpu=cortex-a9
> --with-fpu=neon-fp16 --enable-languages=c
> 
> and trimming the testcase to the first line I cannot reproduce the reported
> assembly.  I get at -O3
> 
> .arm
> .fpu softvfp

For some reason, you are not targeting the right FPU, I have:
.arm
.fpu neon-fp16

[Bug middle-end/91060] [10 regression] gcc.c-torture/execute/scal-to-vec1.c fails on armeb-none-linux-gnueabihf since r272843

[rsandifo at gcc dot gnu.org]

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

--- Comment #7 from rsandifo at gcc dot gnu.org  
---
(In reply to Christophe Lyon from comment #4)
> Unfortunately, it's still failing as of r273133.
> 
> It fails at the very first check:
> v1 = 2 + v0;   check (short, 8, v0, v1, 2, +, l);
> 
> The generated code for main is:
> main:
...
> vmov.16 d16[0], r0
> sxthr1, r0
> vadd.i16q0, q8, q9
> add ip, r1, #2
> vmov.s16r2, d0[3]

Yeah, this looks wrong.  We should be adding 2 to a single element
here, but we're extracting from one index and inserting into another.
The first quoted instruction should be using [3] as well.

I'd be unsurprised if this was a target bug.

[Bug c++/85746] Premature evaluation of __builtin_constant_p?

[rsandifo at gcc dot gnu.org]

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

--- Comment #8 from rsandifo at gcc dot gnu.org  
---
(In reply to Marc Glisse from comment #7)
> (In reply to Marc Glisse from comment #6)
> >  && xi.val[0] <= (HOST_WIDE_INT) ((unsigned HOST_WIDE_INT)
> >   HOST_WIDE_INT_MAX >> shift))
> 
> The issue occurs with xi.val[0] == -9223372036854775808 (lshift_large
> returns a result of length 2 for that). I don't know if the code mishandles
> this case, or if such a number is not supposed to exist in the first place,
> but that does seem like a bug.

Yeah, looks like this should have been an unsigned HOST_WIDE_INT comparison
instead, i.e. casting xi.val[0] rather than the shift result.

[Bug c++/80518] -Wsuggest-override does not warn about missing override on destructor

[egallager at gcc dot gnu.org]

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

--- Comment #6 from Eric Gallager  ---
(In reply to Arnaud Desitter from comment #2)
> Interesting. Shame that there is no rationale.
> 
> I suppose that "-Wsuggest-override=2" could warn about "override" missing
> for destructor.

I'd just like to repeat my preference for named options over numeric warning
levels here; named options are separately controllable and thus more useful.
Maybe call it -Wsuggest-override-destructor instead?

[Bug c++/87274] -std=c++11 breaks quadmath macros

[egallager at gcc dot gnu.org]

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

--- Comment #5 from Eric Gallager  ---
(In reply to Manuel López-Ibáñez from comment #4)
> (In reply to Jonathan Wakely from comment #2)
> > (In reply to Patrick J. LoPresti from comment #0)
> > > Note that my code does not use any quad-precision literals; just the
> > > documented `FLT128_MAX` macro.
> > 
> > Which is a quad-precision literal, of course.
> > 
> > > I realize quadmath is more a C thing than a C++ thing... But it would
> > > still be nice if this worked, IMO.
> > 
> > It does work if you use the right options to allow the necessary extensions.
> > 
> > > On a possibly related note, writing "__extension__" before a
> > > quad-precision literal does not silence this error. Perhaps it should (?)
> > 
> > Yes, maybe. Confirming for that feature request.
> 
> 
> This is an error, not a warning nor a warning converted to an error.
> __extension__ silences warnings, it does not make something that should not
> compile into something that should compile.
> 
> However, the following should work and it doesn't:
> 
> // with -Wpedantic -std=gnu++11
> #include 
> __float128 x0 = FLT128_MAX; /* warn */
> __float128 x1 = __extension__ FLT128_MAX; /* no warn */

That sounds like bug 71003 (which apparently was already added as related from
the other end, but just making sure to mention it on this end as well, since I
filed it and would like to see it fixed)

[Bug bootstrap/77510] genautomata memory footprint for MIPS

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||mfortune at gmail dot com

--- Comment #2 from Eric Gallager  ---
cc-ing MIPS maintainer

[Bug middle-end/44566] configuration with multiple targets / backends is not supported.

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||froydnj at gcc dot gnu.org,
   ||mark at codesourcery dot com,
   ||steven at gcc dot gnu.org

--- Comment #10 from Eric Gallager  ---
(In reply to Jorn Wolfgang Rennecke from comment #7)
> The patches have been tested & posted to gcc-patches:
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02492.html
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02452.html
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02495.html
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02618.html
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02645.html
> http://gcc.gnu.org/ml/gcc-patches/2010-06/msg02649.html

cc-ing some people from these threads

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[elowe at elowe dot com]

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

--- Comment #59 from EML  ---
Created attachment 46575
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46575&action=edit
islower 32 bit test assembler

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[elowe at elowe dot com]

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

--- Comment #58 from EML  ---
32 Bit:

Second Test Program (derived from a crashing conftest)

#include 

int
main ()
{
  int j = 0;

  j = islower(0);

  printf("j is: %d\n", j);

  return 0;
}


[.LCFI2:]
mov r35 = r1
.body
.loc 1 6 7
;;
st4 [r34] = r0
.loc 1 8 18
addl r14 = @ltoffx(__SB_masks#), r1
;;
ld8.mov r14 = [r14], __SB_masks#
;;
ld4 r14 = [r14]
.loc 1 8 16
;;
cmp.eq p6, p7 = 0, r14
(p6) br.cond.dptk .L2
.loc 1 8 35 discriminator 1
addl r14 = @ltoffx(__SB_masks#), r1
;;
ld8.mov r14 = [r14], __SB_masks#
;;
ld4 r14 = [r14]
;;
ld4 r14 = [r14] <<<--- crashes here. Missing addp4 r14 = 0,r14
.loc 1 8 16 discriminator 1
;;
and r14 = 64, r14
br .L3
;;


If you insert the addp4 r14 = 0,r14 before that command (like gcc 4.9.3 does),
the program compiles and runs correctly

I'll upload the .s for "IsLower.c" - it's definitely a 32 bit executable, so
the correct options are being passed around.

[Bug middle-end/84877] Local stack copy of BLKmode parameter on the stack is not aligned when the requested alignment exceeds MAX_SUPPORTED_STACK_ALIGNMENT

[hp at gcc dot gnu.org]

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

--- Comment #16 from Hans-Peter Nilsson  ---
(In reply to Jorn Wolfgang Rennecke from comment #13)
> I tried if I could reproduce this with a cross-compiler built for
> --target=hppa-linux-gnu;

My target of concern is cris-elf, just as in my earlier comment in this PR.
Sorry I missed mentioning this in my latest reply.  A cross from x86_64-linux
should do it.

[Bug middle-end/84877] Local stack copy of BLKmode parameter on the stack is not aligned when the requested alignment exceeds MAX_SUPPORTED_STACK_ALIGNMENT

[amylaar at gcc dot gnu.org]

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

--- Comment #15 from Jorn Wolfgang Rennecke  ---
Created attachment 46574
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46574&action=edit
patch for the case that the stack is sufficiently aligned

(In reply to dave.anglin from comment #11)
 > $sp is aligned on entry to main:
> (gdb) p/x $sp
> $1 = 0xf8d02300
> 
> However, the invisible reference is a $sp - 0x78.  That's not sufficiently
> aligned.

I've built a cross compiler to take a closer look. 
MAX_SUPPORTED_STACK_ALIGNMENT is 512, so the problem is completely different
for this target.  Looking at pa.h, the value comes from
PREFERRED_STACK_BOUNDARY :

/* Boundary (in *bits*) on which stack pointer is always aligned;
   certain optimizations in combine depend on this.

   The HP-UX runtime documents mandate 64-byte and 16-byte alignment for
   the stack on the 32 and 64-bit ports, respectively.  However, we
   are only guaranteed that the stack is aligned to BIGGEST_ALIGNMENT
   in main.  Thus, we treat the former as the preferred alignment.  */
#define STACK_BOUNDARY BIGGEST_ALIGNMENT
#define PREFERRED_STACK_BOUNDARY (TARGET_64BIT ? 128 : 512)
...
/* No data type wants to be aligned rounder than this.  The long double
   type has 16-byte alignment on the 64-bit target even though it was never
   implemented in hardware.  The software implementation only needs 8-byte
   alignment.  This matches the biggest alignment of the HP compilers.  */
#define BIGGEST_ALIGNMENT (2 * BITS_PER_WORD)


Even with TARGET_64_BIT, we got a PREFERRED_STACK_BOUNDARY of 128 .

However:
#define UNITS_PER_WORD (TARGET_64BIT ? 8 : 4)

It seems suspicious that PREFERRED_STACK_BOUNDARY is smaller for TARGET_64BIT ?

Be this as it may, the problem for the 84877 testcase is not that the stack has
insufficient alignment, but that the stack slot doesn't have an aligned offset.

The alignment gets pruned in function.c:get_stack_local_alignment :

  if (mode == BLKmode)
alignment = BIGGEST_ALIGNMENT;

I have attached a patch to preserve the alignment of the passed type for the
case that the stack is already sufficiently aligned.

To test the case where the stack is insufficiently aligned, for hppa we should
use a different testcase with > 512 bit alignment of the type.

[Bug middle-end/84877] Local stack copy of BLKmode parameter on the stack is not aligned when the requested alignment exceeds MAX_SUPPORTED_STACK_ALIGNMENT

[danglin at gcc dot gnu.org]

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

--- Comment #14 from John David Anglin  ---
Created attachment 46573
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46573&action=edit
Preproccessed source for pr84877.c

I don't believe there are any new failures or ICEs on hppa-linux with your
patch.
pr84877 aborts due stack alignment as noted in prior comment.

[Bug middle-end/84877] Local stack copy of BLKmode parameter on the stack is not aligned when the requested alignment exceeds MAX_SUPPORTED_STACK_ALIGNMENT

[amylaar at gcc dot gnu.org]

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

--- Comment #13 from Jorn Wolfgang Rennecke  ---
(In reply to Hans-Peter Nilsson from comment #12)
> (In reply to Jorn Wolfgang Rennecke from comment #10)
> > Created attachment 46567 [details]
> > Fix for targets that pass the argument by invisible reference
> 
> Thanks for your efforts.  This *may* have affected the code generated by
> gcc.dg/pr84877.c; that test now passes, but that's unreliable as I've seen
> the outcome depends on random stack alignment of the context, and my
> baseline is from a context different enough.  I believe inspecting the
> generated code isn't of much interest given David Anglin's observations for
> hppa and...
> 
> However, it introduces these regressions:
> +gcc.sum gcc.dg/pr80286.c
> +gcc.sum gcc.dg/torture/pr78542.c
> +gcc.sum gcc.dg/torture/pr86363.c
> +gcc.sum gcc.dg/torture/va-arg-25.c

I tried if I could reproduce this with a cross-compiler built for
--target=hppa-linux-gnu; the va-arg-25.c test case needs headers, but the
others can be
compiled just using xgcc & cc1.  I tried with the options in dg-options,
and for pr78542.c / pr86363.c I also tried additional -O options.
However, I don't see any ICE.  Is there a special configuration or set of
options needed, or is this just impossible with a cross compiler?

[Bug target/91102] [9/10 Regression] aarch64 ICE on Linux kernel with -Os starting with r270266

[vmakarov at gcc dot gnu.org]

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

--- Comment #5 from Vladimir Makarov  ---
(In reply to Jakub Jelinek from comment #1)
> 
> Vlad, could you please have a look?

The culprit patch is actually 

https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=265942 

Prohibiting reload for any user defined registers which should be matched is
too harsh.  We still can reload operands using the match if no one is an
earlier clobber operand.

The following patch should solve the problem:

Index: ../../gcc/gcc/lra-constraints.c
===
--- ../../gcc/gcc/lra-constraints.c (revision 273177)
+++ ../../gcc/gcc/lra-constraints.c (working copy)
@@ -2172,8 +2172,9 @@
else
  {
/* Operands don't match.  If the operands are
-  different user defined explicit hard registers,
-  then we cannot make them match.  */
+  different user defined explicit hard
+  registers, then we cannot make them match
+  when one is early clobber operand.  */
if ((REG_P (*curr_id->operand_loc[nop])
 || SUBREG_P (*curr_id->operand_loc[nop]))
&& (REG_P (*curr_id->operand_loc[m])
@@ -2191,10 +2192,14 @@
&& REG_USERVAR_P (nop_reg)
&& REG_P (m_reg)
&& HARD_REGISTER_P (m_reg)
-   && REG_USERVAR_P (m_reg))
- break;
+   && REG_USERVAR_P (m_reg)) {
+ for (int i = 0; i < early_clobbered_regs_num;
i++)
+   if (m == early_clobbered_nops[i])
+ break;
+ if (i < early_clobbered_regs_num ||
early_clobber_p)
+   break;
+   }
  }
-
/* Both operands must allow a reload register,
   otherwise we cannot make them match.  */
if (curr_alt[m] == NO_REGS)

Although I'll take some time to think about the solution before submitting it
into the trunk.

[Bug target/61577] [4.9.0] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #57 from dave.anglin at bell dot net ---
On 2019-07-05 7:57 p.m., elowe at elowe dot com wrote:
> Doing some more testing on my "gprel unfixed fix" 32-bit gcc, I found out that
> it seems to be missing the 32-bit pointer swizzling needed to make 32bit
> executables on 64-bit IA-64.  The test program assembler is missing an addp4
> instruction - when I add in this instruction, my second test program also
> works.
It's not clear to me that this is necessary.  The movl instruction loads a
64-bit immediate.
In this case, it should be the offset between gp (r1) and .LC0.  At the
br.call.sptk.many b0
instruction, r36 should contain the address of .LC0.  You should be able to see
this with gdb.
It should be possible to adjust the offset to account for any difference
between 32 and
64-bit runtimes.

If the offset value is wrong, I think we have a binutils issue.  Maybe -milp32
is not being
passed on hpux to assembler.

I don't see any difference between 32-bit and 64-bit code, or between hpux and
linux.

[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian

[jb at gcc dot gnu.org]

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

--- Comment #37 from Janne Blomqvist  ---
One thing we could do would be to switch to pread and pwrite instead of using
lseek. That would avoid a few syscalls when updating the record length marker.
Though I guess the issue with GPFS isn't directly related to the number of
syscalls?

[Bug libfortran/91030] Poor performance of I/O -fconvert=big-endian

[jb at gcc dot gnu.org]

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

Janne Blomqvist  changed:

   What|Removed |Added

 CC||jb at gcc dot gnu.org

--- Comment #36 from Janne Blomqvist  ---
I have access to a system with Lustre, which is another parallel file system
popular in HPC. Unfortunately I don't have gcc trunk setup there, but I can
easily test the C benchmark; give me a day or two.

[Bug c++/61339] add mismatch between struct and class [-Wmismatched-tags] to non-bugs

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #10 from Martin Sebor  ---
Testing a patch.

[Bug tree-optimization/91090] A suspicious code in tree-ssa-dom.c

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #4 from Jeffrey A. Law  ---
Fixed on the trunk.  Only causes missed optimizations, so I don't think there's
a strong need to backport to the release branches.

[Bug tree-optimization/91090] A suspicious code in tree-ssa-dom.c

[law at gcc dot gnu.org]

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

--- Comment #3 from Jeffrey A. Law  ---
Author: law
Date: Sun Jul  7 18:42:45 2019
New Revision: 273184

URL: https://gcc.gnu.org/viewcvs?rev=273184&root=gcc&view=rev
Log:
PR tree-optimization/91090
* tree-ssa-dom.c (simplify_stmt_for_jump_threading): Fix logic error
in handling of ranges to simplify switch statements.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/tree-ssa-dom.c

[Bug middle-end/84877] Local stack copy of BLKmode parameter on the stack is not aligned when the requested alignment exceeds MAX_SUPPORTED_STACK_ALIGNMENT

[hp at gcc dot gnu.org]

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

--- Comment #12 from Hans-Peter Nilsson  ---
(In reply to Jorn Wolfgang Rennecke from comment #10)
> Created attachment 46567 [details]
> Fix for targets that pass the argument by invisible reference

Thanks for your efforts.  This *may* have affected the code generated by
gcc.dg/pr84877.c; that test now passes, but that's unreliable as I've seen the
outcome depends on random stack alignment of the context, and my baseline is
from a context different enough.  I believe inspecting the generated code isn't
of much interest given David Anglin's observations for hppa and...

However, it introduces these regressions:
+gcc.sum gcc.dg/pr80286.c
+gcc.sum gcc.dg/torture/pr78542.c
+gcc.sum gcc.dg/torture/pr86363.c
+gcc.sum gcc.dg/torture/va-arg-25.c

They are all internal compiler errors that seem to be one and the same (beware
of copypaste):

/netapp/hp3_storage/hp/autotest/pr84877-amylaar1/gcc/gcc/testsuite/gcc.dg/pr80286.c:
In function 'main':
/netapp/hp3_storage/hp/autotest/pr84877-amylaar1/gcc/gcc/testsuite/gcc.dg/pr80286.c:18:9:
internal compiler error: in co
nvert_move, at expr.c:217
0x7f6763 convert_move(rtx_def*, rtx_def*, int)
/netapp/hp3_storage/hp/autotest/pr84877-amylaar1/gcc/gcc/expr.c:217
0x7f6cf1 convert_modes(machine_mode, machine_mode, rtx_def*, int)
/netapp/hp3_storage/hp/autotest/pr84877-amylaar1/gcc/gcc/expr.c:712
0x7fd420 store_expr(tree_node*, rtx_def*, int, bool, bool)
/netapp/hp3_storage/hp/autotest/pr84877-amylaar1/gcc/gcc/expr.c:5710
0x6af577 initialize_argument_information
/netapp/hp3_storage/hp/autotest/pr84877-amylaar1/gcc/gcc/calls.c:2090
0x6b0d28 expand_call(tree_node*, rtx_def*, int)
/netapp/hp3_storage/hp/autotest/pr84877-amylaar1/gcc/gcc/calls.c:3612
0x7efcf7 expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/netapp/hp3_storage/hp/autotest/pr84877-amylaar1/gcc/gcc/expr.c:11044
0x7fcd74 store_expr(tree_node*, rtx_def*, int, bool, bool)
/netapp/hp3_storage/hp/autotest/pr84877-amylaar1/gcc/gcc/expr.c:5685
0x7fe7e6 expand_assignment(tree_node*, tree_node*, bool)
/netapp/hp3_storage/hp/autotest/pr84877-amylaar1/gcc/gcc/expr.c:5447
0x6ca297 expand_call_stmt
   
/netapp/hp3_storage/hp/autotest/pr84877-amylaar1/gcc/gcc/cfgexpand.c:2727
0x6ca297 expand_gimple_stmt_1
   
/netapp/hp3_storage/hp/autotest/pr84877-amylaar1/gcc/gcc/cfgexpand.c:3708
0x6cb0e6 expand_gimple_stmt
   
/netapp/hp3_storage/hp/autotest/pr84877-amylaar1/gcc/gcc/cfgexpand.c:3867
0x6d08c5 expand_gimple_basic_block
   
/netapp/hp3_storage/hp/autotest/pr84877-amylaar1/gcc/gcc/cfgexpand.c:5907
0x6d3616 execute
   
/netapp/hp3_storage/hp/autotest/pr84877-amylaar1/gcc/gcc/cfgexpand.c:6530
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
compiler exited with status 1
FAIL: gcc.dg/pr80286.c (internal compiler error)
FAIL: gcc.dg/pr80286.c (test for excess errors)

[Bug c/91107] New: __attribute__((pure)) to function with non-const pointers

[colomar.6.4.3 at gmail dot com]

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

Bug ID: 91107
   Summary: __attribute__((pure)) to function with non-const
pointers
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: colomar.6.4.3 at gmail dot com
  Target Milestone: ---

I have a function that takes two arrays and writes into a third array the
result of a pure function (c_i = a_i / b_i):

inline
voidarray_division  (ptrdiff_t nmemb,
 double dest[static nmemb],
 const double src1[static nmemb],
 const double src2[static nmemb])
__attribute__((nonnull, pure));

inline
voidarray_division  (ptrdiff_t nmemb,
 double dest[static nmemb],
 const double src1[static nmemb],
 const double src2[static nmemb])
{

for (ptrdiff_t i = 0; i < nmemb; i++)
dest[i] = src1[i] / src2[i];
}

Given that it works with full arrays instead of single variables, I can't just
return the output, and therefore need to modify the array through a pointer,
which goes against what a pure function is by the docs.

However, I think it is still as valid as any other pure function to be
optimized as a pure function.

A pure function is one that acts as a function of its parameters, and the
values pointed to by those parameters; and if none of the parameters, nor the
values pointed to by them, change between two calls, they should be redundant
and the call can be omitted, evaluating to the same value returned by the
previous call.

This function follows all those rules: If none of the 3 arrays change between
two function calls, the function call can be completely removed; and they
evaluate to the same value (which is none, because it's void).

Am I right in thinking that GCC should allow this usage of
__attibute__((pure))?

Or is there any optimization achieved by pure that would be defeated by this
function?


Btw, I tricked GCC into accepting to compile this code just by adding a dummy
`return 0;`.  Is that safe, or is the optimization likely to produce broken
code?


If this function is finally accepted as a pure function, pure should be
accepted to be used in a void function, and accept non-const parameters, but if
not, I think there's no reason at all to allow non-const pointers, and should
probably be banned.

[Bug fortran/91077] [8/9/10 Regression] Wrong indexing when using a pointer

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

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

--- Comment #11 from Paul Thomas  ---
Fixed on all three branches.

Thanks for the report, Ygal.

Paul

[Bug middle-end/84877] Local stack copy of BLKmode parameter on the stack is not aligned when the requested alignment exceeds MAX_SUPPORTED_STACK_ALIGNMENT

[dave.anglin at bell dot net]

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

--- Comment #11 from dave.anglin at bell dot net ---
On 2019-07-06 3:39 p.m., amylaar at gcc dot gnu.org wrote:
> Since the esirisc port is not in the FSF tree, it doesn't really count for
> testing; also, the behaviour will vary depending on argument passing of the
> target, so we need to test a variety of targets.
Test still fails on hppa:

(gdb) disass
Dump of assembler code for function main:
=> 0x00010388 <+0>: stw rp,-14(sp)
   0x0001038c <+4>: addil L%0,dp,r1
   0x00010390 <+8>: ldo 80(sp),sp
   0x00010394 <+12>:    ldo 10(r1),r1
   0x00010398 <+16>:    ldw 0(r1),ret0
   0x0001039c <+20>:    ldw 4(r1),ret1
   0x000103a0 <+24>:    stw ret0,-78(sp)
   0x000103a4 <+28>:    stw ret1,-74(sp)
   0x000103a8 <+32>:    ldo -78(sp),r26
   0x000103ac <+36>:    ldw 8(r1),r19
   0x000103b0 <+40>:    ldw c(r1),r20
   0x000103b4 <+44>:    stw r19,-70(sp)
   0x000103b8 <+48>:    stw r20,-6c(sp)
   0x000103bc <+52>:    b,l 0x10660 ,rp
   0x000103c0 <+56>:    nop

$sp is aligned on entry to main:
(gdb) p/x $sp
$1 = 0xf8d02300

However, the invisible reference is a $sp - 0x78.  That's not sufficiently
aligned.

Dave

[Bug fortran/91077] [8/9/10 Regression] Wrong indexing when using a pointer

[pault at gcc dot gnu.org]

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

--- Comment #10 from Paul Thomas  ---
Author: pault
Date: Sun Jul  7 14:50:53 2019
New Revision: 273178

URL: https://gcc.gnu.org/viewcvs?rev=273178&root=gcc&view=rev
Log:
2019-07-07  Paul Thomas  

PR fortran/91077
* trans-array.c (gfc_conv_scalarized_array_ref) Delete code
that gave symbol backend decl for subref arrays.

2019-07-07  Paul Thomas  

PR fortran/91077
* gfortran.dg/pointer_array_11.f90 : New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pointer_array_11.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/trans-array.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084

[rguenther at suse dot de]

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

--- Comment #28 from rguenther at suse dot de  ---
On July 7, 2019 2:59:29 PM GMT+02:00, "tkoenig at gcc dot gnu.org"
 wrote:
>https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90813
>
>--- Comment #27 from Thomas Koenig  ---
>(In reply to Richard Biener from comment #26)
>
>> The odd thing is that for the Fortran example even the tree oracle
>claims
>> the store doesn't alias the load...
>> 
>> Because they are different variables!  Dumping with -uid shows
>> 
>>   c_D.3918 = cD.3925;
>>   c_.5_12 = c_D.3933;
>>   rhs.2D.4008 = c_.5_12 ();
>> 
>> that's probably not intended either...  c_D.3933 is never initialized
>> anywhere in the testcase.
>
>Sorry to have to ask but...  How did you get this dump? 
>
>gfortran -O3 -fdump-tree-all -uid proc_ptr_51.f90 

-fdump-tree-all-uid without the space 

>
>and grepping for c_D under proc_ptr.f90.* (on POWER) does not show any
>hits for me.  (And what does -uid do?)
>
>The last useful dump I can find results in what can be seen in
>comment #14, which seems correct.

[Bug fortran/91077] [8/9/10 Regression] Wrong indexing when using a pointer

[pault at gcc dot gnu.org]

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

--- Comment #9 from Paul Thomas  ---
Author: pault
Date: Sun Jul  7 14:32:53 2019
New Revision: 273177

URL: https://gcc.gnu.org/viewcvs?rev=273177&root=gcc&view=rev
Log:
2019-07-07  Paul Thomas  

PR fortran/91077
* trans-array.c (gfc_conv_scalarized_array_ref) Delete code
that gave symbol backend decl for subref arrays and deferred
length variables.

2019-07-07  Paul Thomas  

PR fortran/91077
* gfortran.dg/pointer_array_11.f90 : New test.

Added:
branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pointer_array_11.f90
Modified:
branches/gcc-9-branch/gcc/fortran/ChangeLog
branches/gcc-9-branch/gcc/fortran/trans-array.c
branches/gcc-9-branch/gcc/testsuite/ChangeLog

[Bug middle-end/91106] New: internal compiler error: output_operand: invalid use of register 'frame'

[gsocshubham at gmail dot com]

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

Bug ID: 91106
   Summary: internal compiler error: output_operand: invalid use
of register 'frame'
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gsocshubham at gmail dot com
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
 Build: x86_64-linux-gnu

Created attachment 46572
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46572&action=edit
Preprocessed code of ICE causing program "crash2.c"

---COMPILER CONFIGURATION-

Using built-in specs.
COLLECT_GCC=/home/extended_csmith/pull-martin-compiler/build/gcc/xgcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --enable-lto
--disable-bootstrap : (reconfigured) ../gcc/configure --enable-lto
--disable-bootstrap --enable-languages=c,c++,lto --no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20190707 (experimental) (GCC)




-COMMAND LINE USED FOR COMPILATION-

~/pull-martin-compiler/build/gcc/xgcc -B ~/pull-martin-compiler/build/gcc/ -O0
crash2.i -w
during RTL pass: final
crash2.c: In function ‘func_1’:
crash2.c:982:1: internal compiler error: output_operand: invalid use of
register 'frame'
0x90fd53 output_operand_lossage(char const*, ...)
../../gcc/gcc/final.c:3610
0x101cdd4 ix86_print_operand_address_as
../../gcc/gcc/config/i386/i386.c:13152
0x101eaff ix86_print_operand(_IO_FILE*, rtx_def*, int)
../../gcc/gcc/config/i386/i386.c:12901
0x91006c output_operand(rtx_def*, int)
../../gcc/gcc/final.c:4052
0x91093e output_asm_insn(char const*, rtx_def**)
../../gcc/gcc/final.c:3964
0x91203f final_scan_insn_1
../../gcc/gcc/final.c:3107
0x9134fb final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../gcc/gcc/final.c:3153
0x913649 final_1
../../gcc/gcc/final.c:2021
0x914404 rest_of_handle_final
../../gcc/gcc/final.c:4659
0x914404 execute
../../gcc/gcc/final.c:4737
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

-REDUCED CODE---

void f();

#pragma pack(1)
struct a {
  int b;
  char c;
};
union {
  struct a b;
} __attribute__((aligned(32), transparent_union)) d;
void e() { f(d); }

[Bug middle-end/91105] New: internal compiler error: maximum number of generated reload insns per insn achieved (90)

[gsocshubham at gmail dot com]

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

Bug ID: 91105
   Summary: internal compiler error: maximum number of generated
reload insns per insn achieved (90)
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gsocshubham at gmail dot com
  Target Milestone: ---
  Host: x86_64-linux-gnu
Target: x86_64-linux-gnu
 Build: x86_64-linux-gnu

Created attachment 46571
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46571&action=edit
Preprocessed code of ICE causing program "crash1.c"

COMPILER CONFIGURATION--

Using built-in specs.
COLLECT_GCC=./xgcc
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --enable-languages=c,c++ --enable-lto
--disable-bootstrap : (reconfigured) ../gcc/configure --enable-lto
--disable-bootstrap --enable-languages=c,c++,lto --no-create --no-recursion
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.0 20190707 (experimental) (GCC) 

COMMAND LINE USED FOR COMPILATION---

~/pull-martin-compiler/build/gcc/xgcc -B ~/pull-martin-compiler/build/gcc/
crash1.i -O0 -w
during RTL pass: reload
crash1.c: In function ‘func_1’:
crash1.c:1317:1: internal compiler error: maximum number of generated reload
insns per insn achieved (90)
0xadf746 lra_constraints(bool)
../../gcc/gcc/lra-constraints.c:4902
0xac711c lra(_IO_FILE*)
../../gcc/gcc/lra.c:2468
0xa7a4b9 do_reload
../../gcc/gcc/ira.c:5522
0xa7a4b9 execute
../../gcc/gcc/ira.c:5706
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

---REDUCED TEST CASE--

void g();

struct a {
  short b;
  short c;
  short d;
};
union {
  struct a b;
} __attribute__((aligned(32), transparent_union)) e;
void f() { g(e); }

[Bug ada/91100] [9,10 Regression] FAIL: gnat.dg/socket1.adb execution test

[dave.anglin at bell dot net]

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

--- Comment #2 from dave.anglin at bell dot net ---
On 2019-07-07 4:10 a.m., ebotcazou at gcc dot gnu.org wrote:
> Let's just disable the test on HP-UX as it is on Solaris.
Okay.  The pass/fail seems inconsistent.

[Bug fortran/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084

[tkoenig at gcc dot gnu.org]

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

--- Comment #27 from Thomas Koenig  ---
(In reply to Richard Biener from comment #26)

> The odd thing is that for the Fortran example even the tree oracle claims
> the store doesn't alias the load...
> 
> Because they are different variables!  Dumping with -uid shows
> 
>   c_D.3918 = cD.3925;
>   c_.5_12 = c_D.3933;
>   rhs.2D.4008 = c_.5_12 ();
> 
> that's probably not intended either...  c_D.3933 is never initialized
> anywhere in the testcase.

Sorry to have to ask but...  How did you get this dump? 

gfortran -O3 -fdump-tree-all -uid proc_ptr_51.f90 

and grepping for c_D under proc_ptr.f90.* (on POWER) does not show any
hits for me.  (And what does -uid do?)

The last useful dump I can find results in what can be seen in
comment #14, which seems correct.

[Bug c++/91104] New: auto... in lambda expression reorders parameters

[antifermion at protonmail dot com]

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

Bug ID: 91104
   Summary: auto... in lambda expression reorders parameters
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antifermion at protonmail dot com
  Target Milestone: ---

Created attachment 46570
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46570&action=edit
source file to reproduce the bug

Code:

void test(void (*f)(int, int, int)) {
f(1, 2, 3);
}

int main() {
test([](auto... args) {
printf("%d %d %d\n", args...);
});
test([](int a, int b, int c) {
printf("%d %d %d\n", a, b, c);
});
}

Actual Output:

2 3 1
1 2 3

Expected Output:

1 2 3
1 2 3

Compiler flags:

g++ -std=c++17 -Wall -Wextra -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations main.cpp -o main && ./main

(c++14 has the same behavior)

Output of g++ -v:

Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-linux-gnu/9.1.0/lto-wrapper
Target: x86_64-linux-gnu
Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu
--disable-multilib --enable-languages=c,c++,fortran,go
Thread model: posix
gcc version 9.1.0 (GCC)

System type: Debian Stretch (amd64)

[Bug middle-end/91060] [10 regression] gcc.c-torture/execute/scal-to-vec1.c fails on armeb-none-linux-gnueabihf since r272843

[rguenth at gcc dot gnu.org]

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

--- Comment #6 from Richard Biener  ---
hmm, armeb-linux doesn't use newlib.  awkward to set up a cross :/

[Bug middle-end/91060] [10 regression] gcc.c-torture/execute/scal-to-vec1.c fails on armeb-none-linux-gnueabihf since r272843

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #5 from Richard Biener  ---
Hmm, using a cross configured as

trunk/configure --target=armeb-none-linux-gnueabihf --with-cpu=cortex-a9
--with-fpu=neon-fp16 --enable-languages=c

and trimming the testcase to the first line I cannot reproduce the reported
assembly.  I get at -O3

.arm
.fpu softvfp
.type   main, %function
main:
@ args = 0, pretend = 0, frame = 16
@ frame_needed = 0, uses_anonymous_args = 0
movwip, #:lower16:.LANCHOR0
push{r4, r5, lr}
movtip, #:upper16:.LANCHOR0
mov r0, #0
mov r1, r0
mov r2, r0
ldr ip, [ip]
mov r3, r0
mov r5, #3
mov r4, #5
movtr1, 4
movtr2, 6
movtr3, 8
sub sp, sp, #20
sxthip, ip
bfi r1, r4, #0, #16
add ip, ip, #2
sxthlr, ip
bfi r0, lr, #16, #16
cmp ip, lr
mov lr, #7
mov ip, #9
bfi r0, r5, #0, #16
bfi r2, lr, #0, #16
bfi r3, ip, #0, #16
strdr0, [sp]
strdr2, [sp, #8]
bne .L5
mov r0, #0
add sp, sp, #20
@ sp needed
pop {r4, r5, pc}
.L5:
bl  abort

also the GIMPLE looks good to me, we compare only the first non-constant
element and optimized the others at compile-time.

Are you sure the first line fails?  The ones with bitwise handling look
more "interesting" (^, & and |) since vector lowering plays odd tricks there
and VN elides an intermediate VIEW_CONVERT_EXPR.

Not sure what is required to do a runtest with qemu, I can try throwing
in newlib and binutils into a combined tree, but is that enough?

Maybe Richard can help here as well.

[Bug fortran/91077] [8/9/10 Regression] Wrong indexing when using a pointer

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas  ---
Author: pault
Date: Sun Jul  7 10:53:37 2019
New Revision: 273176

URL: https://gcc.gnu.org/viewcvs?rev=273176&root=gcc&view=rev
Log:
2019-07-07  Paul Thomas  

PR fortran/91077
* trans-array.c (gfc_conv_scalarized_array_ref) Delete code
that gave symbol backend decl for subref arrays and deferred
length variables.

2019-07-07  Paul Thomas  

PR fortran/91077
* gfortran.dg/pointer_array_11.f90 : New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pointer_array_11.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/trans-array.c
trunk/gcc/testsuite/ChangeLog

[Bug c++/85746] Premature evaluation of __builtin_constant_p?

[glisse at gcc dot gnu.org]

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

Marc Glisse  changed:

   What|Removed |Added

 CC||rsandifo at gcc dot gnu.org

--- Comment #7 from Marc Glisse  ---
(In reply to Marc Glisse from comment #6)
>  && xi.val[0] <= (HOST_WIDE_INT) ((unsigned HOST_WIDE_INT)
>   HOST_WIDE_INT_MAX >> shift))

The issue occurs with xi.val[0] == -9223372036854775808 (lshift_large returns a
result of length 2 for that). I don't know if the code mishandles this case, or
if such a number is not supposed to exist in the first place, but that does
seem like a bug.

[Bug rtl-optimization/91068] [10 regression][MIPS] New FAIL: madd-3.c and msub-5.c start with r272849

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Fixed on trunk.

[Bug rtl-optimization/91068] [10 regression][MIPS] New FAIL: madd-3.c and msub-5.c start with r272849

[rsandifo at gcc dot gnu.org]

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

--- Comment #2 from rsandifo at gcc dot gnu.org  
---
Author: rsandifo
Date: Sun Jul  7 09:49:24 2019
New Revision: 273175

URL: https://gcc.gnu.org/viewcvs?rev=273175&root=gcc&view=rev
Log:
PR91068: Fix MIPS fallout from IRA matched operand changes

PR91068 is a case in which we have (ignoring non-LRA alternatives):

  [(set (match_operand:SI 0 "register_operand" "=l,d?")
(plus:SI (mult:SI (match_operand:SI 1 "register_operand" "d,d")
  (match_operand:SI 2 "register_operand" "d,d"))
 (match_operand:SI 3 "register_operand" "0,d")))
   (clobber (match_scratch:SI 4 "=X,l"))
   (clobber (match_scratch:SI 5 "=X,&d"))]

where the first alternative is one instruction but the second is two.
This is very similar to the case that my recent IRA patches were
supposed to help.  The crucial difference is that the cheap
alternative requires a single-register class while the expensive
alternative uses general registers.

This makes a difference when one of operand 0 or 3 can naturally be
allocated to LO but the other can't.  If IRA makes that allocation,
both alternatives require one reload of equal cost and so the first
alternative clearly wins.

However, if we say that tying operands 0 and 3 saves the cost of a full
move, then all other things being equal, IRA will prefer to allocate
both registers to the same GPR.  The registers will then naturally
fit the second alternative.

This has a more drastic effect in the MIPS case than it should because
using the GPR alternative is much more expensive there than it appears
to the RA.  But that's really a separate problem and something we were
able to live with before my IRA patch.

What makes tying less useful here is the fact that the tied register is
a single-register class.  I think in those circumstances it's better not
to use tied operands at all and instead use "l" for the inputs.
Allocating the input to LO, and allocating the output to LO, then depend
naturally on class costs.  If we decide to allocate at least one of them
to LO, we'll use the cheap alternative, otherwise we'll (correctly) use
the expensive alternative.  This effectively restores the situation
before my IRA patch, but this time making the preference on the input
register more explicit.

I originally wrote the patterns in the early days of IRA, and certainly
well before LRA.  I think they were largely influened by reload rather
than RA proper (see the comment above *mul_acc_si, which is all about
the reload behaviour).  LRA copes with the two-"l" case just fine.

The patch may well cause problems for -mno-lra, but I think we should
cull that option anyway.

2019-07-07  Richard Sandiford  

gcc/
PR target/91068
* config/mips/mips.md (*mul_acc_si, *mul_acc_si_r3900, *macc)
(*msac, *msac_using_macc, *mul_sub_si): Use "l" for input operands
instead of matching them to "l" output operands.

Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/mips/mips.md

[Bug rtl-optimization/90813] [10 regression] gfortran.dg/proc_ptr_51.f90 fails (SIGSEGV) after 272084

[rguenth at gcc dot gnu.org]

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

--- Comment #26 from Richard Biener  ---
(In reply to Segher Boessenkool from comment #25)
> At expand time, the assignment is
> 
> 
> ;; c_ = c;
> 
> (insn 35 34 36 (set (reg/f:DI 140)
> (unspec:DI [
> (symbol_ref:DI ("*.LANCHOR1") [flags 0x182])
> (reg:DI 2 2)
> ] UNSPEC_TOCREL)) "proc_ptr_51.f90":26:0 -1
>  (expr_list:REG_EQUAL (symbol_ref:DI ("*.LANCHOR1") [flags 0x182])
> (nil)))
> 
> (insn 36 35 37 (set (reg/f:DI 141)
> (unspec:DI [
> (symbol_ref:DI ("__f_MOD_c") [flags 0x3]   0x3fff7
> 86a7d00 c>)
> (reg:DI 2 2)
> ] UNSPEC_TOCREL)) "proc_ptr_51.f90":26:0 -1
>  (expr_list:REG_EQUAL (symbol_ref:DI ("__f_MOD_c") [flags 0x3] 
>  cl 0x3fff786a7d00 c>)
> (nil)))
> 
> (insn 37 36 0 (set (mem/f/c:DI (reg/f:DI 140) [13 c_+0 S8 A64])
> (reg/f:DI 141)) "proc_ptr_51.f90":26:0 -1
>  (nil))
> 
> 
> while the use is (immediately after that!)
> 
> 
> ;; rhs.2 = c_.5_12 (); [return slot optimization]
> 
> (insn 38 37 39 (set (reg:DI 142)
> (plus:DI (reg/f:DI 112 virtual-stack-vars)
> (const_int 48 [0x30]))) "proc_ptr_51.f90":35:0 -1
>  (nil))
> 
> (insn 39 38 40 (set (reg/f:DI 143)
> (mem/u/c:DI (unspec:DI [
> (symbol_ref/u:DI ("*.LC1") [flags 0x2])
> (reg:DI 2 2)
> ] UNSPEC_TOCREL) [21  S8 A8])) "proc_ptr_51.f90":35:0 -1
>  (expr_list:REG_EQUAL (symbol_ref:DI ("__f_MOD_c_") [flags 0xc0] 
> )
> (nil)))
> 
> (insn 40 39 41 (set (reg/f:DI 144)
> (mem/f/c:DI (reg/f:DI 143) [13 c_+0 S8 A64])) "proc_ptr_51.f90":35:0
> -1
>  (nil))
> 
> (insn 41 40 42 (set (reg:DI 3 3)
> (reg:DI 142)) "proc_ptr_51.f90":35:0 -1
>  (nil))
> 
> (insn 42 41 43 (set (reg:DI 145)
> (mem:DI (reg/f:DI 144) [0  S8 A8])) "proc_ptr_51.f90":35:0 -1
>  (nil))
> 
> (insn 43 42 44 (set (reg:DI 97 ctr)
> (reg:DI 145)) "proc_ptr_51.f90":35:0 -1
>  (nil))
> 
> (insn 44 43 45 (set (reg:DI 11 11)
> (mem:DI (plus:DI (reg/f:DI 144)
> (const_int 16 [0x10])) [0  S8 A8])) "proc_ptr_51.f90":35:0 -1
>  (nil))
> 
> (call_insn 45 44 46 (parallel [
> (call (mem:SI (reg:DI 97 ctr) [0 *c_.5_12 S4 A8])
> (const_int 64 [0x40]))
> (use (mem:DI (plus:DI (reg/f:DI 144)
> (const_int 8 [0x8])) [0  S8 A8]))
> (set (reg:DI 2 2)
> (unspec:DI [
> (const_int 40 [0x28])
> ] UNSPEC_TOCSLOT))
> (clobber (reg:DI 96 lr))
> ]) "proc_ptr_51.f90":35:0 -1
>  (expr_list:REG_CALL_DECL (nil)
> (nil))
> (expr_list (use (reg:DI 11 11))
> (expr_list:DI (use (reg:DI 3 3))
> (nil
> 
> (insn 46 45 47 (set (reg:DI 146)
> (plus:DI (reg/f:DI 112 virtual-stack-vars)
> (const_int 48 [0x30]))) "proc_ptr_51.f90":35:0 -1
>  (nil))
> 
> (insn 47 46 0 (set (reg:TI 127 [ rhs.2 ])
> (mem:TI (reg:DI 146) [7  S16 A64])) "proc_ptr_51.f90":35:0 -1
>  (nil))
> 
> 
> 
> so it is wrong (if this is wrong!) at expand already.
> 
> 
> In gimple this was:
> 
>   c_ = c;
>   c_.5_12 = c_;
>   rhs.2 = c_.5_12 (); [return slot optimization]

OK, so this is really

  static fnptrtype c_ = &c;

dumped in a weird way and then a load from the global var.  Not sure why this
isn't optimized on GIMPLE (to a direct call)...

Note the type we're basing the indirect call ABI on is

struct __class_f_S_p (*) (void) _12;

not sure if that's correct.  To me it seems the function returns a pointer,
not an aggregate.  That may be very well the (frontend) issue?

For the C testcase

typedef void (*fnptr)(void);
void bar(void);
fnptr g;
fnptr foo()
{
g = bar;
return g;
}

we happily optimize the load, even when I make the types mismatching.

The odd thing is that for the Fortran example even the tree oracle claims
the store doesn't alias the load...

Because they are different variables!  Dumping with -uid shows

  c_D.3918 = cD.3925;
  c_.5_12 = c_D.3933;
  rhs.2D.4008 = c_.5_12 ();

that's probably not intended either...  c_D.3933 is never initialized
anywhere in the testcase.

[Bug target/91102] [9/10 Regression] aarch64 ICE on Linux kernel with -Os starting with r270266

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
(In reply to Segher Boessenkool from comment #2)
> 91102.c: In function 'foo':
> 91102.c:7:1: warning: control reaches end of non-void function
> [-Wreturn-type]
> 7 | }
>   | ^
> 
> so ice-on-invalid-code?

Well, invalid at runtime, so valid if not called.

> Although, hrm, inserting "return 3;" there still ICEs.

The testcase has been creduced and hand cleaned up, forgot about the return
value.
Let's talk about

int
foo (long d, long l)
{
  register long e asm ("x1") = d;
  register long f asm("x2") = l;
  asm ("" : : "r" (e), "r" (f));
  return 3;
}

struct T { int i; int j; };
union S { long h; struct T t; };

void
bar (union S b)
{
  while (1)
{
  union S c = b;
  c.t.j++;
  b.h = foo (b.h, c.h);
}
}

then.  The change is done in decrease_live_ranges_number:
2128if (sregno < FIRST_PSEUDO_REGISTER
2129&& reg_mentioned_p (dest, PATTERN (q)))
2130  failed = 1;
2131
2132/* Attempt to replace all uses.  */
2133else if (!validate_replace_rtx (src, dest, q))
2134  failed = 1;

So, shouldn't we have some code for dregno < FIRST_PSEUDO_REGISTER that checks
for cases like this (dunno what exactly, just insns where already at least one
of the operands from extract_operands is a hard register, or more specifically
don't propagate into an operand that has number in a constraint and
corresponding argument is already (a different) hard register, something else?

[Bug c++/85746] Premature evaluation of __builtin_constant_p?

[glisse at gcc dot gnu.org]

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

--- Comment #6 from Marc Glisse  ---
The problematic file seems to be tree-dfa.o, and the only difference I see in
the .original dump is the use of __builtin_constant_p in wi::lshift (3
occurrences because of templates)

-  if (precision <= 64)
+  if (__builtin_constant_p (xi.D.16865.D.16740.precision > 64) != 0 &&
xi.D.16865.D.16740.precision > 64 ? ((__builtin_constant_p (shift <= 62) != 0
&& shift <= 62) && xi.D.16865.D.16740.len == 1) && *NON_LVALUE_EXPR
 <= (const long int) (9223372036854775807 >> shift) :
precision <= 64)

which corresponds to the use of STATIC_CONSTANT_P in wide-int.h

  if (STATIC_CONSTANT_P (xi.precision > HOST_BITS_PER_WIDE_INT)
  ? (STATIC_CONSTANT_P (shift < HOST_BITS_PER_WIDE_INT - 1)
 && xi.len == 1
 && xi.val[0] <= (HOST_WIDE_INT) ((unsigned HOST_WIDE_INT)
  HOST_WIDE_INT_MAX >> shift))
  : precision <= HOST_BITS_PER_WIDE_INT)
{
  val[0] = xi.ulow () << shift;
  result.set_len (1);
}

[Bug ada/91100] [9,10 Regression] FAIL: gnat.dg/socket1.adb execution test

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2019-07-07
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Eric Botcazou  ---
Let's just disable the test on HP-UX as it is on Solaris.