[Bug target/93694] Inconsistent grammar in darwin.opt

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe  ---
Created attachment 47938
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47938=edit
Update darwin opts descriptions

Thanks for the comments.

As background, (most of) these options have ben present in the Darwin toolchain
since before my involvement - however they were never described; there is note
in the GCC manual suggesting that the user should use the man page.

The majority here are actually options passed on to the linker, and the details
can be quite complex - so that the user should still make use of the manage (so
I would not delete that statement from the GCC manual).  The idea here is a
brief summary to serve as a reminder for a more detailed description.  Perhaps
I should have left them undocumented 

an example of the manpage:
https://www.manpagez.com/man/1/ld64/

In some cases (especially for determining which options are obsolete) several
versions of the man pages were consulted - and the linker source code itself.



I will apply a patch that makes the following changes in a few days if there
are no more comments (such comments are welcome):

> Loads all members of archive libraries

Load all members of archive libraries, rather than only those that satisfy
undefined symbols.

> The version of ld64 in use for this toolchain.

-mtarget-linkerSpecify that ld64  is the toolchain
linker for the current invocation.

> Produce an output file that will bind symbols on load, rather than lazily.

Generate an output executable that binds symbols on load, rather than lazily.

> Produce a Mach-O bundle (file type MH_BUNDLE)

Generate a Mach-O bundle (file type MH_BUNDLE).

> This will allow relocs

-read_only_relocsAllow relocations in read-only pages (not
recommended).

>And a typo:
> exectuable
fixed.

>Unnecessarily unspecific wording:
> Allows setting the page 0 size to 4kb for certain special cases
>What exactly are "certain special cases"?
I don't think that can be reasonable answered in a brief option description, I
suggest what's below, it is the user's responsibility to know when the option
is required.

-pagezero_sizeAllows setting the page 0 size (for example, to 4kb)
when required.

double space:
> architecture  \"name\"
fixed.

> unnecessarily verbose:
> Specify that the output file should be generated for architecture  "name"
> Why not simply: Generate output file for the named architecture.

-arch Generate output for architecture .

>anachronism:
> MacOS X
> Should that be macOS nowadays?

Changed throughout.

> off-by-one:
> must record a greater
> I think this should rather be "greater or equal".
Actually, the man page is quite confusing on this option, I've tried to make
this more specific:

-compatibility_version  Set the version for the client interface. 
Client programs must record a value less than or equal to , or the
binding will fail at runtime.

>double space:
> dyld  will

fixed,

>  Provided
> (Obsolete after 10.3.9) Set
> Shouldn't there be a tab between the words instead of the space?

fixed.

> -pagezero_size size
> The other placeholders are written in , so should this one.

done, as per the comment above.

> (Obsolete, ld_classic only) -sectcreate segname sectname file
> segname, sectname and file should be marked as .
> (Obsolete, ld_classic only) -sectcreate segname sectname file

-sectcreateCreate section  in segment
 from the contents of .

> -segprot  max_prot init_prot\tThe protection values are
> This like only describes the syntax but doesn't lose a single word about the 
> effect.
Indeed ...

-segprot  The virtual memory protections
for segment  are set to maximum and initial values  and
 respectively.  The specified values may contain \"r\", \"w\", \"x\"
or \"-\" the latter meaning \"no access\".

> -segs_read_only_addr address
>Missing placeholder.
> space-tab.

-segs_read_only_addr   Specify that  is the base address of
the read-only segments of a dylib.

> Allows specifying
>I hope that this option actually _sets_ the address instead of only _allowing_ 
>to set. (2 times)

done as per segs_read_only_addr  above.


> Specifies content
> That's another case of very unspecific wording. As the German translator I 
> have no idea what this could mean. This option is documented nowhere. It only 
> appears in the ChangeLogs, darwin.h and darwin.opt.

As noted, the source for the information is outside the GCC tree - ld64 source
/ manages suggested change:

Add extra information to the executable that can speed up dynamic loading
(provided that dependent libraries are unchanged).

[Bug target/93985] New: Sub-optimal assembly for %st(0) constant loading with SSE enabled (x86_64)

[sagebar at web dot de]

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

Bug ID: 93985
   Summary: Sub-optimal assembly for %st(0) constant loading with
SSE enabled (x86_64)
   Product: gcc
   Version: 9.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sagebar at web dot de
  Target Milestone: ---

Created attachment 47939
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47939=edit
Inefficient code generation, similar working cases & work-around

With gcc for x86_64, where SSE is enabled by default, some situations exist
where legacy (fpu) math instructions (and their constraints) still have to be
used.
x86 offets a hand full of instructions to load specific floating point
constants more efficiently (including `1.0`).
As such, it would stand to reason to implement a function `atan()` as:
```c
double atan(double x) {
double result;
__asm__("fpatan"
: "=t" (result)
: "0" (1.0)
, "u" (x)
: "st(1)");
return result;
}
```

This code works perfectly on i386, where it compiles to:
```asm
fldl4(%esp)   # push(x)
fld1  # push(1.0)
fpatan
ret
```

However, on x86_64 it is compiled as:
```asm
movsd   .LC0(%rip), %xmm1
movsd   %xmm1, -8(%rsp)
fldl-8(%rsp)  # push(1.0)
movsd   %xmm0, -8(%rsp)
fldl-8(%rsp)  # push(x)
fxch%st(1)# { x, 1.0 } -> { 1.0, x }
fpatan
fstpl   -8(%rsp)
movsd   -8(%rsp), %xmm0
ret
...
.LC0:
.long   0 # SSE constant: 1.0
.long   1072693248# ...
```

When the optimal code would look like:
```asm
movsd   %xmm0, -8(%rsp)
fldl-8(%rsp)  # push(x)
fld1  # push(1.0)
fpatan
fstpl   -8(%rsp)
movsd   -8(%rsp), %xmm0
ret
```

Still though, it appears that GCC _is_ aware of the fld1 instruction for
encoding inline assembly operands, even when SSE is enabled (s.a.
`atan_reverse()` within the attached file).
So it would stand to reason that this is either a problem with how GCC weights
different encoding schemes, or a problem with how GCC decides if certain
encoding schemes are even possible at all (which seems quite likely, especially
considering that the x86_64 version contains an fxch-instruction which also
wouldn't be necessary if GCC had encoded the `1.0` _after_ pushing `x`
(ignoring the fact that `1.0` can be pushed using `fld1`))

NOTE: The attached file should be compiled as `gcc -O3 -S attached-file.c`

[Bug middle-end/93848] missing -Warray-bounds warning for array subscript 1 is outside array bounds

[ch3root at openwall dot com]

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

--- Comment #11 from Alexander Cherepanov  ---
(In reply to Martin Sebor from comment #10)
> An array is implicitly converted to a pointer; 

Sometimes converted, sometimes -- not.

> it's not an lvalue.  

Why not? Take for example p[1] that we discussed. It's equivalent to *(p+1) and
the unary * operator is explicitly documented to yield an lvalue (C11,
6.5.3.2p4):

"If the operand points to a function, the result is a function designator; if
it points to an object, the result is an lvalue designating the object."

> But I
> think we're splitting hairs.  I agree we want a warning for passing
> past-the-end pointers to functions that might inadvertently dereference it;
> I plan to implement it for GCC 11.

This is something more general and I'm not sure we want such a warning. You are
right that passing a past-the-end pointers to functions perfectly legal so
there would be false alarms. I cannot readily assess whether it's worth it.

OTOH the specific construction that started this PR is not legal and should
always give a warning, whether it's passed to an unknown function, printed
without additional dereferences or used in a computation.

> The reference in
> 
> int a[1][4];
> printf("%p\n", (void *)[1][1]);
> 
> is of course undefined, but when the warning sees the address-of operator it
> allows off-by-one indices.  That's necessary only for the rightmost index
> but not otherwise.  The missing warning here is the subject of pr84079.  I
> have a simple fix that handles this case.

Great, here we agree. But does it cover [1][0]?

[Bug debug/93988] New: invalid DWARF emitted for complex integer

[tromey at gcc dot gnu.org]

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

Bug ID: 93988
   Summary: invalid DWARF emitted for complex integer
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tromey at gcc dot gnu.org
  Target Milestone: ---

Consider this test case:

_Complex int x = 23i;


Compile with -g and examine the resulting DWARF:

 <1><31>: Abbrev Number: 3 (DW_TAG_base_type)
<32>   DW_AT_byte_size   : 8
<33>   DW_AT_encoding: 128  (HP_float80)
<34>   DW_AT_name: (indirect string, offset: 0x0): complex int


I was surprised to see that "HP_float80" here, but it turns out
that this is just an artifact of dwarf.def claiming:

/* HP extensions.  */
DW_ATE (DW_ATE_HP_float80, 0x80) /* Floating-point (80 bit).  */


In reality what gcc is doing is just returning:

  /* Dwarf2 doesn't know anything about complex ints, so use
 a user defined type for it.  */
case COMPLEX_TYPE:
  if (TREE_CODE (TREE_TYPE (type)) == REAL_TYPE)
encoding = DW_ATE_complex_float;
  else
encoding = DW_ATE_lo_user;
  break;


There are a couple of ways this could be replaced.  One would be to
give a complex base type its own DW_AT_type, holding the underlying
element type.

Another would be to pick a range, like 0xa0-0xaf, and emit
a value like 0xa0 | DW_ATE_signed.

I see in base_type_die that there are other cases that return
DW_ATE_lo_user.  These are probably also bugs.

[Bug rtl-optimization/91332] ICE: Segfault in gfortran when compiling massive subroutine with -O3

[clogged.drainpipe at gmail dot com]

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

--- Comment #3 from Madarpok .  ---
Any movement regarding this?

[Bug testsuite/91799] [10 regression] r273245 breaks test case gcc.target/powerpc/pr88233.c

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #6 from Jeffrey A. Law  ---
I pushed Segher's patch to the trunk.

[Bug testsuite/91799] [10 regression] r273245 breaks test case gcc.target/powerpc/pr88233.c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jeff Law :

https://gcc.gnu.org/g:03a71208880e60f6d9c51423a50d9de9ae26d700

commit r10-6956-g03a71208880e60f6d9c51423a50d9de9ae26d700
Author: Segher Boessenkool 
Date:   Sun Mar 1 11:13:18 2020 -0700

Fix test for pr88233.

PR testsuite/91799
* gcc.target/powerpc/pr88233.c: Update expected output and
add target selector.

[Bug target/92303] [10 regression] gcc.target/sparc/ultrasp12.c times out

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|WAITING |NEW
 CC||law at redhat dot com

[Bug target/93987] Regression (ICE) on gcc-9 branch

[gabriel at inconstante dot net.br]

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

--- Comment #2 from Gabriel F. T. Gomes  ---
Oh, I forgot to paste the output:

$
/home/debian/build/powerpc64le/tools/install/compilers/powerpc64le-linux-gnu/bin/powerpc64le-glibc-linux-gnu-gcc
-c -O2 ice.c 
ice.c: In function ‘test_addcq’:
ice.c:128:1: error: insn does not satisfy its constraints:
  128 | }
  | ^
(insn 305 304 306 3 (set (reg:V1TI 80 3)
(rotate:V1TI (mem/u/c:V1TI (and:DI (reg/f:DI 29 29 [240])
(const_int -16 [0xfff0])) [0  S16 A128])
(const_int 64 [0x40]))) 1043 {*vsx_le_permute_v1ti}
 (nil))
during RTL pass: cprop_hardreg
ice.c:128:1: internal compiler error: in extract_constrain_insn, at
recog.c:2211
0x1012c7ef _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
/home/debian/build/powerpc64le/tools/src/gcc/gcc/rtl-error.c:108
0x1012c84b _fatal_insn_not_found(rtx_def const*, char const*, int, char const*)
/home/debian/build/powerpc64le/tools/src/gcc/gcc/rtl-error.c:118
0x106f4cd7 extract_constrain_insn(rtx_insn*)
/home/debian/build/powerpc64le/tools/src/gcc/gcc/recog.c:2211
0x106f9fbb copyprop_hardreg_forward_1
/home/debian/build/powerpc64le/tools/src/gcc/gcc/regcprop.c:817
0x106faf5f execute
/home/debian/build/powerpc64le/tools/src/gcc/gcc/regcprop.c:1385
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.


I'll check with trunk and with the tip of gcc-9, thanks!

[Bug lto/93980] use of lto breaks -Wl,--exclude-libs

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #3 from H.J. Lu  ---
This seems a linker bug.  Please open a binutils bug report.

[Bug inline-asm/93981] No EH information generated for asm statements

[jwjagersma at gmail dot com]

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

--- Comment #8 from jwjagersma at gmail dot com ---
(In reply to Segher Boessenkool from comment #7)
> Ah right, only for -fnon-call-exceptions, I missed that; that is implied
> by stmt_can_throw_internal.
> 
> Why only volatile memory operands, btw?  Can't *all* memory accesses throw?

Memory access from a known valid pointer (eg. stack variables) can
reasonably be expected not to throw. So I didn't mean 'volatile' in the
literal sense but more in general, pointers that cannot be know to be
valid at compile-time.

> Is that handled somewhere else, or does it need special-casing for asm?

For general memory access I think this is checked in tree_could_trap_p.
The case for ASM_EXPR there would need to be expanded to check if any
of its operands could trap.

> Please use trunk ("master") for development, not an older release?

I was having trouble building a native (mingw-w64) compiler from git,
so I tried using 9.2.0 sources. I'm working on trunk now using an
Ubuntu VM.

> I would think the problem here is caused by your modifications to tree-eh.c,
> but that is not based on understanding this code at all ;-)

To me it seems that some part of the code does not realize that a
throwing asm must be kept at a bb boundary, and inserts statements
after it. That would need to be patched too, if I could find where that
happens.

[Bug tree-optimization/93982] [10 Regression] Assignment incorrectly omitted by -foptimize-strlen since r10-2528

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

[Bug ipa/92535] [10 regression] ICF is relatively expensive and became less effective

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

[Bug target/93987] New: Regression (ICE) on gcc-9 branch

[gabriel at inconstante dot net.br]

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

Bug ID: 93987
   Summary: Regression (ICE) on gcc-9 branch
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabriel at inconstante dot net.br
CC: bergner at vnet dot ibm.com
  Target Milestone: ---
Target: powerpc64le-glibc-linux-gnu

Created attachment 47940
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47940=edit
Reproducer

Current pveclib (https://github.com/open-power-sdk/pveclib) tests fail to build
with the tip of the gcc-9 branch.  I have bisected the problem, and it seems
that the following commit is to blame:

  066184a282b622ac6880150eb4e42fe57881b606 is the first bad commit
  commit 066184a282b622ac6880150eb4e42fe57881b606
  Author: Peter Bergner 
  Date:   Sun Feb 23 18:22:57 2020 -0600

rs6000: Fix infinite loop building ghostscript and icu [PR93658]

The testcases ("make check") in pveclib fail to build with GCC-9 in Debian
Unstable, and with a compiler built locally from that commit (I'm using glibc's
build-many-glibcs.py script).

I tried to reduce the testcase to a small standalone file, but I couldn't
reduce it further than the attachement

[Bug inline-asm/93981] No EH information generated for asm statements

[jwjagersma at gmail dot com]

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

jwjagersma at gmail dot com changed:

   What|Removed |Added

  Attachment #47936|0   |1
is obsolete||

--- Comment #6 from jwjagersma at gmail dot com ---
Created attachment 47941
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47941=edit
patch v2

Small change; only call make_eh_edges for asm statements if the asm
could throw (is volatile).
This does not solve the ICE however, which is caused by a throwing
statement that appears before the end of a basic block. It seems that,
at some point, extra statements are added after the asm in a bb? But I
can't find where that happens.

[Bug inline-asm/93981] No EH information generated for asm statements

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
(In reply to jwjagersma from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > Pretending any asm can throw would be a pretty serious code degradation.
> > 
> > Any asm that is not volatile cannot throw (and be correct code).  But
> > most volatile asm in the wild can never throw, either.
> 
> The intention is to only produce EH info for volatile asms, and only if
> -fnon-call-exceptions is given. Asms that take volatile memory operands
> should be covered too.

Ah right, only for -fnon-call-exceptions, I missed that; that is implied
by stmt_can_throw_internal.

Why only volatile memory operands, btw?  Can't *all* memory accesses throw?

Is that handled somewhere else, or does it need special-casing for asm?

> Do note that the proposed patch is still incomplete, I ran into an ICE
> while building libgcc with -fnon-call-exceptions:
> 
> ```
> during GIMPLE pass: ehcleanup
> ../../../gnu/gcc-9.2.0/libgcc/config/i386/sfp-exceptions.c: In function
> '__sfp_handle_exceptions':
> ../../../gnu/gcc-9.2.0/libgcc/config/i386/sfp-exceptions.c:107:1: internal
> compiler error: in mark_reachable_handlers, at tree-eh.c:3929
>   107 | }
>   | ^
> libbacktrace could not find executable to open
> Please submit a full bug report,
> with preprocessed source if appropriate.
> See  for instructions.
> ```
> 
> However I am not knowledgable enough about gcc's inner workings to know
> what exactly is missing. I'm hoping someone can help me out with this.

Please use trunk ("master") for development, not an older release?

I would think the problem here is caused by your modifications to tree-eh.c,
but that is not based on understanding this code at all ;-)

[Bug lto/93980] use of lto breaks -Wl,--exclude-libs

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu  ---
This linker patch:

iff --git a/ld/plugin.c b/ld/plugin.c
index 47c053e5a0a..5960df65243 100644
--- a/ld/plugin.c
+++ b/ld/plugin.c
@@ -1242,6 +1242,8 @@ plugin_object_p (bfd *ibfd)
   ibfd->plugin_format = bfd_plugin_yes;
   ibfd->plugin_dummy_bfd = abfd;
   bfd_make_readable (abfd);
+  if (ibfd->my_archive != NULL)
+  abfd->no_export = ibfd->my_archive->no_export;
   return abfd->xvec;
 }
   else

fixes the testcase.

[Bug c++/93984] spurious Wclass-conversion warning

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-01
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Confirmed, but clang++ warns too.

commit fce33808678df40cce69c15141926342f8a6f47e
Author: Marek Polacek 
Date:   Wed Sep 19 16:59:51 2018 +

PR c++/87357 - missing -Wconversion warning

PR c++/87357 - missing -Wconversion warning
* decl.c (grok_op_properties): Remove diagnostic parts mentioning
a conversion to a reference to void.  Use
same_type_ignoring_top_level_qualifiers_p rather than comparing
types
directly.

* g++.dg/warn/Wconversion5.C: New test.

From-SVN: r264425

[Bug lto/93980] use of lto breaks -Wl,--exclude-libs

[sergeev917 at gmail dot com]

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

--- Comment #5 from Alexander Sergeyev  ---
(In reply to H.J. Lu from comment #3)
> This seems a linker bug.  Please open a binutils bug report.

The bug report is at https://sourceware.org/bugzilla/show_bug.cgi?id=25618

[Bug tree-optimization/93986] [10 Regression] ICE in decompose, at wide-int.h:984 since r10-5451

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-03-01
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |10.0
Summary|[10 Regression] ICE in  |[10 Regression] ICE in
   |decompose, at   |decompose, at
   |wide-int.h:984  |wide-int.h:984 since
   ||r10-5451
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r10-5451-gef29b12cfbb4979a89b3cbadbf485a77c8fd8fce.

[Bug tree-optimization/93986] New: [10 Regression] ICE in decompose, at wide-int.h:984

[asolokha at gmx dot com]

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

Bug ID: 93986
   Summary: [10 Regression] ICE in decompose, at wide-int.h:984
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc-10.0.1-alpha20200223 snapshot (g:3133bed5d0327e8a9cd0a601b7ecdb9de4fc825d)
ICEs when compiling the following testcase w/ -O1 -foptimize-strlen
-ftree-slp-vectorize:

int
dd (void);

void
ya (int cm)
{
  char s2[cm];

  s2[cm-12] = s2[cm-11] = s2[cm-10] = s2[cm-9] = s2[cm-8] = s2[cm-7] = s2[cm-6]
= s2[cm-5] = ' ';

  if (dd ())
__builtin_exit (0);
}

% gcc-10.0.1 -O1 -foptimize-strlen -ftree-slp-vectorize -c ch4gpdst.c
during GIMPLE pass: strlen
ch4gpdst.c: In function 'ya':
ch4gpdst.c:5:1: internal compiler error: in decompose, at wide-int.h:984
5 | ya (int cm)
  | ^~
0x5ee66a wi::int_traits >::decompose(long*,
unsigned int, generic_wide_int const&)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/wide-int.h:984
0x8d1f74 wi::int_traits >::decompose(long*,
unsigned int, generic_wide_int const&)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/wide-int.h:2456
0x8d1f74 wide_int_ref_storage::wide_int_ref_storage
>(generic_wide_int const&, unsigned int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/wide-int.h:1034
0x8d1f74 generic_wide_int
>::generic_wide_int
>(generic_wide_int const&, unsigned int)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/wide-int.h:790
0x8d1f74 wi::binary_traits,
generic_wide_int,
wi::int_traits >::precision_type,
wi::int_traits
>::precision_type>::result_type wi::add,
generic_wide_int >(generic_wide_int const&,
generic_wide_int const&)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/wide-int.h:2425
0xf605cc generic_wide_int&
generic_wide_int::operator+=
>(generic_wide_int const&)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/wide-int.h:757
0xf605cc maybe_warn_overflow
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/tree-ssa-strlen.c:1977
0xf64ac8 maybe_warn_overflow
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/tree-ssa-strlen.c:2312
0xf64ac8 handle_store
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/tree-ssa-strlen.c:4976
0xf672a9 check_and_optimize_stmt
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/tree-ssa-strlen.c:5614
0xf672a9 strlen_dom_walker::before_dom_children(basic_block_def*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/tree-ssa-strlen.c:5791
0x1664567 dom_walker::walk(basic_block_def*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/domwalk.c:309
0xf5b75e printf_strlen_execute
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200223/work/gcc-10-20200223/gcc/tree-ssa-strlen.c:5857

[Bug target/93987] Regression (ICE) on gcc-9 branch

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||bergner at gcc dot gnu.org

--- Comment #1 from Peter Bergner  ---
I actually just reverted that fix yesterday due to PR93974.  Please pull new
sources and try again.

That said, does it also fail on trunk?  If so, what compile options did you
use?  And what was the failure?  An ICE or ???

[Bug middle-end/82798] Inconsistent descriptions for warning options in documentation

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #4 from Eric Gallager  ---
Sandra has a big documentation patch that might address some of these

[Bug fortran/93581] [9/10 Regression] ICE in gfc_get_dataptr_offset, at fortran/trans-array.c:6951

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #5 from Paul Thomas  ---
Created attachment 47942
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47942=edit
Patch for the PR

Hi Gerhard,

I must applaud you on your efforts to look into every dark corner of gfortran.
I hope that you are not too disheartened by the slow pace at which we fix your
bugs.

Cheers

Paul

[Bug lto/93980] use of lto breaks -Wl,--exclude-libs

[sergeev917 at gmail dot com]

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

--- Comment #6 from Alexander Sergeyev  ---
(In reply to H.J. Lu from comment #4)
> This linker patch:

Thank you! I've linked the patch to the binutils bug report.

[Bug sanitizer/93731] [10 regression] asan tests cause kernel panic on Darwin 11

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:63cc547f6d85819192afa795e9ade14f0800eda9

commit r10-6951-g63cc547f6d85819192afa795e9ade14f0800eda9
Author: Iain Sandoe 
Date:   Sun Mar 1 14:40:57 2020 +

Darwin, libsanitizer: Adjust minimum supported Darwin version (PR93731).

The current imported libsanitizer code produces kernel panics for
Darwin 11 (macOS 10.7) and is unsupported for earlier versions already.

It is not clear if the current sources are even intended to be supported
on Darwin 11, so this patch causes the default to be build without
sanitizers for Darwin <= 11.

2020-03-01  Iain Sandoe  

PR sanitizer/93731
* configure.tgt (x86_64-*-darwin*, i?86-*-darwin*): Enable by
default only for Darwin versions greater than 12 (macOS 10.8).

[Bug c++/71283] Inconsistent location for C++ warning options in the manual

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org

--- Comment #11 from Eric Gallager  ---
Martin, did you want to stay the assignee for this? Sandra seemed to want to
address this bug here: https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01522.html

[Bug testsuite/91797] [10 regression] r273240 breaks test case gcc.target/powerpc/pr68805.c

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #9 from Jeffrey A. Law  ---
I pushed Segher's patch.

[Bug testsuite/91797] [10 regression] r273240 breaks test case gcc.target/powerpc/pr68805.c

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Jeff Law :

https://gcc.gnu.org/g:151bf47e78f5d919f6cc591d11cc1f6aff61078f

commit r10-6957-g151bf47e78f5d919f6cc591d11cc1f6aff61078f
Author: Segher Boessenkool 
Date:   Sun Mar 1 11:17:30 2020 -0700

Fix test for pr68805.

PR testsuite/91797
* gcc.target/pwoerpc/pr68805.c: Update expected output.

[Bug inline-asm/93981] No EH information generated for asm statements

[jwjagersma at gmail dot com]

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

--- Comment #9 from jwjagersma at gmail dot com ---
ICE can be replicated with:

```
$ ./cc1plus -O -g -fnon-call-exceptions -I../../gcc/libgcc
../../gcc/libgcc/config/i386/sfp-exceptions.c
 void __sfp_handle_exceptions(int)
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>  
../../gcc/libgcc/config/i386/sfp-exceptions.c:107:1: error: statement marked
for throw in middle of block
  107 | }
  | ^
# VUSE <.MEM_31>
__asm__ __volatile__("fdivs %1" : "=t" f_32 : "m" g, "0" f_30);
../../gcc/libgcc/config/i386/sfp-exceptions.c:107:1: error: statement marked
for throw in middle of block
# VUSE <.MEM_46>
__asm__ __volatile__("fdivs %1" : "=t" f_47 : "m" g, "0" f_45);
during GIMPLE pass: ssa
../../gcc/libgcc/config/i386/sfp-exceptions.c:107:1: internal compiler error:
verify_gimple failed
```

The error message is different but it's the same problem.
When I break there in gdb:

```
(gdb) break tree-cfg.c:5439
Breakpoint 5 at 0xf93816: file ../../gcc/gcc/tree-cfg.c, line 5439.
(gdb) r
Starting program: D:\vmshare\gcc-build\gcc\cc1plus.exe -O -g
-fnon-call-exceptions -I../../gcc/libgcc
../../gcc/libgcc/config/i386/sfp-exceptions.c
 void __sfp_handle_exceptions(int)
Analyzing compilation unit
Performing interprocedural optimizations
 <*free_lang_data>  
Breakpoint 5, verify_gimple_in_cfg (fn=0x3b9e10b8,
verify_nothrow=verify_nothrow@entry=true) at ../../gcc/gcc/tree-cfg.c:5439
warning: Source file is more recent than executable.
5439  error ("statement marked for throw in middle of
block");
=> 0x00f93816 : 48 8d
0d 83 44 1c 01learcx,[rip+0x11c4483]#0x2157ca0 <(anonymous
namespace)::pass_data_call_cdce+14848>
   0x00f9381d : e8 86
00 de 00  call   0x1d738a8 
(gdb) pp bb
 :
# DEBUG BEGIN_STMT
f_30 = 1.0e+0;
# DEBUG f => f_30
g = 0.0;
# DEBUG BEGIN_STMT
__asm__ __volatile__("fdivs %1" : "=t" f_32 : "m" g, "0" f_30);
# DEBUG f => f_32

(gdb) c
Continuing.

../../gcc/libgcc/config/i386/sfp-exceptions.c:107:1: error: statement marked
for throw in middle of block
  107 | }
  | ^
# VUSE <.MEM_31>
__asm__ __volatile__("fdivs %1" : "=t" f_32 : "m" g, "0" f_30);

Breakpoint 5, verify_gimple_in_cfg (fn=0x3b9e10b8,
verify_nothrow=verify_nothrow@entry=true) at ../../gcc/gcc/tree-cfg.c:5439
5439  error ("statement marked for throw in middle of
block");
=> 0x00f93816 : 48 8d
0d 83 44 1c 01learcx,[rip+0x11c4483]#0x2157ca0 <(anonymous
namespace)::pass_data_call_cdce+14848>
   0x00f9381d : e8 86
00 de 00  call   0x1d738a8 
(gdb) pp bb
 :
# DEBUG BEGIN_STMT
f_45 = 1.0e+0;
# DEBUG f => f_45
g = 3.0e+0;
# DEBUG BEGIN_STMT
__asm__ __volatile__("fdivs %1" : "=t" f_47 : "m" g, "0" f_45);
# DEBUG f => f_47
```

So the problem is that DEBUG stmts are inserted after a throwing asm.

[Bug c++/93989] [c++20] Error initializing trivial types in constexpr constructor

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #1 from Marek Polacek  ---
Could you compile that TU with -save-temps and post the .ii file here?

[Bug target/93990] [x86] Silly code generation for _addcarry_u32/_addcarry_u64

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
This is already been fixed in GCC 10:
addq%rdx, %rdi
movq%rsi, %rax
adcq%rcx, %rax
xorq%rdi, %rax
ret
.ident  "GCC: (GNU) 10.0.1 20200121 (experimental) [master revision
e0a5b313c1a:f4dc220f630:b313d3c49c2387b5e212df22a5e6ecc0c4e95c0a]"

[Bug libstdc++/93991] New: FAIL: 22_locale/time_get/get_time/char/2.cc execution test - 'errorstate == ios_base::eofbit' failed

[danglin at gcc dot gnu.org]

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

Bug ID: 93991
   Summary: FAIL: 22_locale/time_get/get_time/char/2.cc execution
test - 'errorstate == ios_base::eofbit' failed
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

spawn -ignore SIGHUP /home/dave/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc
-B/home
/dave/gnu/gcc/objdir/./gcc -nostdinc++
-L/home/dave/gnu/gcc/objdir/hppa-linux-gn
u/libstdc++-v3/src
-L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.
libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/
home/dave/opt/gnu/gcc/gcc-10/hppa-linux-gnu/bin/
-B/home/dave/opt/gnu/gcc/gcc-10
/hppa-linux-gnu/lib/ -isystem
/home/dave/opt/gnu/gcc/gcc-10/hppa-linux-gnu/inclu
de -isystem /home/dave/opt/gnu/gcc/gcc-10/hppa-linux-gnu/sys-include
-fchecking=
1 -B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libstdc++-v3/src/.libs
-fmessage-
length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOUR
CE -DLOCALEDIR="." -nostdinc++
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstd
c++-v3/include/hppa-linux-gnu
-I/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc
++-v3/include -I/home/dave/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/home/dave/gnu/g
cc/gcc/libstdc++-v3/include/backward
-I/home/dave/gnu/gcc/gcc/libstdc++-v3/tests
uite/util
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/22_locale/time_get/get_t
ime/char/2.cc -include bits/stdc++.h -fno-diagnostics-show-caret
-fdiagnostics-c
olor=never -fdiagnostics-urls=never ./libtestc++.a -Wl,--gc-sections
-L/home/dav
e/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/filesystem/.libs -lm -o
./2.exe
PASS: 22_locale/time_get/get_time/char/2.cc (test for excess errors)
Setting LD_LIBRARY_PATH to
:/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gcc/obj
dir/hppa-linux-gnu/./libstdc++-v3/../libatomic/.libs:/home/dave/gnu/gcc/objdir/h
ppa-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-lin
ux-gnu/./libstdc++-v3/src/.libs::/home/dave/gnu/gcc/objdir/gcc:/home/dave/gnu/gc
c/objdir/hppa-linux-gnu/./libstdc++-v3/../libatomic/.libs:/home/dave/gnu/gcc/obj
dir/hppa-linux-gnu/./libstdc++-v3/../libgomp/.libs:/home/dave/gnu/gcc/objdir/hpp
a-linux-gnu/./libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/li
bstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home
/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa
-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/ob
jdir/./prev-gcc
Execution timeout is: 300
spawn [open ...]
/home/dave/gnu/gcc/gcc/libstdc++-v3/testsuite/22_locale/time_get/get_time/char/2
.cc:62: void test02(): Assertion 'errorstate == ios_base::eofbit' failed.
FAIL: 22_locale/time_get/get_time/char/2.cc execution test
extra_tool_flags are:
  -include bits/stdc++.h

This is with Debian unstable.  There are several similar failures.

[Bug tree-optimization/93970] load via restricted pointer not eliminated after a store via a restricted pointer of incompatible type

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Blocks|49774   |
 Resolution|--- |INVALID

--- Comment #1 from Martin Sebor  ---
The test case in comment #0 cannot be optimized as suggested because *q can be
equal to NaN.  Replacing the (unfortunately chosen) double with some other type
like long shows that the expected optimization is done as expected.

$ cat pr93970.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout pr93970.c
void f (int *__restrict p, int *__restrict q)
{
  int t = *q;
  *p = 0;
  if (t != *q)// folded to false
__builtin_abort ();
}

void g (int *__restrict p, long *__restrict q)
{ 
  long t = *q;
  *p = 0;
  if (t != *q)// also folded as expected
__builtin_abort ();
}

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

f (int * restrict p, int * restrict q)
{
   [local count: 1073741824]:
  *p_3(D) = 0;
  return;

}



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

g (int * restrict p, long int * restrict q)
{
   [local count: 1073741824]:
  *p_2(D) = 0;
  return;

}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49774
[Bug 49774] [meta-bug] restrict qualification aliasing issues

[Bug target/93990] New: [x86] Silly code generation for _addcarry_u32/_addcarry_u64

[lloyd at randombit dot net]

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

Bug ID: 93990
   Summary: [x86] Silly code generation for
_addcarry_u32/_addcarry_u64
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lloyd at randombit dot net
  Target Milestone: ---

Bug 67317 has regressed, starting in GCC 6

Same test case as 67317:

#include 
#include 

unsigned long long testcarry(unsigned long long a, unsigned long long
b, unsigned long long c, unsigned long long d)
{
unsigned long long result0, result1;
_addcarry_u64(_addcarry_u64(0, a, c, ), b, d,
);
return result0 ^ result1;
}

GCC 5.4.1 (only) produces the expected output

.cfi_startproc
addq%rdi, %rdx  # a, tmp99
adcq%rsi, %rcx  # b, tmp107
movq%rdx, %rax  # tmp99, D.28638
xorq%rcx, %rax  # tmp107, D.28638
ret
.cfi_endproc

GCC 6.4.1, 7.4.1, 8.3.0 and 9.2.0 all produce variations on this [GCC 9.2.0
output here]:

.cfi_startproc
subq$40, %rsp   #,
.cfi_def_cfa_offset 48
# adx.cpp:5:{
movq%fs:40, %rax# MEM[( long unsigned int
*)40B], tmp107
movq%rax, 24(%rsp)  # tmp107, D.33144
xorl%eax, %eax  # tmp107
# /usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/include/adxintrin.h:69:   return
__builtin_ia32_addcarryx_u64 (__CF, __X, __Y, __P);
addq%rdx, %rdi  # tmp105, tmp93
movq%rsi, %rax  # tmp104, tmp104
setc%r8b#, _12
movq%rdi, 8(%rsp)   # tmp93,
addb$-1, %r8b   #, _12
adcq%rcx, %rax  # tmp106, tmp104
movq%rax, 16(%rsp)  # tmp97,
# adx.cpp:8:return result0 ^ result1;
xorq%rdi, %rax  # tmp93, 
# adx.cpp:9:}
movq24(%rsp), %rdx  # D.33144, tmp109
xorq%fs:40, %rdx# MEM[( long unsigned int
*)40B], tmp109
jne .L5 #,
addq$40, %rsp   #,
.cfi_remember_state
.cfi_def_cfa_offset 8
ret 

All were compiled with -O3. I checked 9.2.0 output with -O and -O2 as well,
with no significant change.

[Bug target/93990] [x86] Silly code generation for _addcarry_u32/_addcarry_u64

[lloyd at randombit dot net]

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

Jack Lloyd  changed:

   What|Removed |Added

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

--- Comment #2 from Jack Lloyd  ---
Good enough for me, closing, thanks.

[Bug target/93987] Regression (ICE) on gcc-9 branch

[gabriel at inconstante dot net.br]

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

--- Comment #3 from Gabriel F. T. Gomes  ---
Update: with the tip of the gcc-9 branch (commit ID 4630b748e63c), as well as
with the tip of trunk (commit ID 151bf47e78f5), it works.

[Bug lto/93980] use of lto breaks -Wl,--exclude-libs

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   See Also||https://sourceware.org/bugz
   ||illa/show_bug.cgi?id=25618
 Resolution|--- |MOVED

--- Comment #7 from H.J. Lu  ---
This is a linker bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=25618

[Bug c++/93989] [c++20] Error initializing trivial types in constexpr constructor

[kingoipo at gmail dot com]

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

--- Comment #2 from Michael de Lang  ---
Created attachment 47943
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47943=edit
save-temps copy_assign_constexpr.ii

[Bug tree-optimization/93971] std::string considered to alias declared objects of incompatible types

[msebor at gcc dot gnu.org]

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

--- Comment #6 from Martin Sebor  ---
As a baseline, I think it would be great to get std::string to enjoy the same
benefits as other containers WRT aliasing.  Going a step further, I'd expect
users of all containers to benefit from the aliasing guarantee the containers
already provide: that modifying one doesn't change the other.  E.g., here it
should be possible to eliminate the test:

  #include 

  struct S { std::vector a, b; };

  void f (struct S )
  {
int t = s.a[0];
s.b[0] = 0;
if (t != s.a[0])   // can be folded to false
  __builtin_abort ();
  }

I've been thinking of one of two kinds of annotation that wouldn't require
programs to change and would be sufficient if applied only to the definition of
the containers: (1) one that would make "std::string::ptr" on par with that of
any other pointer other than char (i.e., a char that's not allowed to be used
to access anything but a char object), and (2) another that could basically be
described as having the effect you suggest.

An example of the former would be an attribute "noalias" applicable only to
narrow character types.  The latter could be done by applying the same
attribute (or some other) to the std::vector and std::basic_string templates.

It might take yet another extension to also express the same guarantee for
node-based containers.

Like you I'm not sure that just slapping restrict on
std::string::_M_dataplus._M_p would have the desired effect (even if GCC did
pay attention to restrict on struct members).

[Bug target/93985] Sub-optimal assembly for %st(0) constant loading with SSE enabled (x86_64)

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #1 from Uroš Bizjak  ---
To prevent unwanted use of x87 registers, register allocator is prohibited from
freely allocating x87 registers without -mfpmath=387 for SFmode and DFmode. You
should use long double and 1.0L to get what you want, e.g:

--cut here--
double
atan (double x)
{
  long double _x = x;
  long double _res;
  __asm__("fpatan"
  : "=t" (_res)
  : "0" (1.0L) , "u" (_x)
  : "st(1)");

  return _res;
}
--cut here--

Alternatively, you could use -mfpmath=387,sse to enable x87 regs and x87
instructions also for x86_64.

[Bug c++/93989] New: [c++20] Error initializing trivial types in constexpr constructor

[kingoipo at gmail dot com]

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

Bug ID: 93989
   Summary: [c++20] Error initializing trivial types in constexpr
constructor
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kingoipo at gmail dot com
  Target Milestone: ---

In trying to implement p0980r1, I encountered the following error when calling
the constexpr basic_string(const _Alloc& __a) constructor:


/home/oipo-unencrypted/Programming/gcc/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/copy_assign_constexpr.cc:
In function ‘consteval void test01()’:
/home/oipo-unencrypted/Programming/gcc/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/copy_assign_constexpr.cc:37:
error: ‘test_type{std::__cxx11::basic_string,
__gnu_test::constexpr_allocator
>::_Alloc_hider{__gnu_test::constexpr_allocator{1}, ((char*)(&
v1.std::__cxx11::basic_string,
__gnu_test::constexpr_allocator
>::.std::__cxx11::basic_string,
__gnu_test::constexpr_allocator >_M_local_buf))}, 0,
std::__cxx11::basic_string,
__gnu_test::constexpr_allocator >::{char [16]{0}}}’ is not
a constant expression
/home/oipo-unencrypted/Programming/gcc/libstdc++-v3/testsuite/21_strings/basic_string/allocator/char/copy_assign_constexpr.cc:37:
error: ‘std::__cxx11::basic_string,
__gnu_test::constexpr_allocator >(a1)’ is not a constant expression
because it refers to an incompletely initialized variable



This is reproducible by checking out the code from https://github.com/Oipo/gcc
and running the new libstdc++3 testcase
https://github.com/Oipo/gcc/blob/master/libstdc%2B%2B-v3/testsuite/21_strings/basic_string/allocator/char/copy_assign_constexpr.cc
. This can be done with "make -jN check-target-libstdc++-v3".

A noteworthy extra change is the introduction of a constexpr_allocator in
testsuite_allocator.h. 


Apologies for not being able to make a smaller reproducible case.

[Bug libstdc++/93983] std::filesystem::path is not concept-friendly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #3 from Jonathan Wakely  ---
This is nothing to do with concepts:

#include 

struct path {
template ::value_type,
char>>
>
path(Source const&);
};

struct Bar
{
Bar(const path& p);
};

#ifdef ADD_THIS
static_assert(!std::is_constructible_v);
#endif
static_assert(std::is_copy_constructible_v);


See also PR 93923.

[Bug c++/93989] [c++20] Error initializing trivial types in constexpr constructor

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Unfortunately that generates literally hundreds of errors when compiled with
-std=c++20 so it's nearly impossible for me to analyze it and see if there's a
real problem.

[Bug middle-end/93829] [10 Regression] bogus -Wstringop-overflow on memcpy of a struct with a pointer member from another with a long string

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:1e9369c5dcf301e090d3a83e2c210cd6b96ac08c

commit r10-6959-g1e9369c5dcf301e090d3a83e2c210cd6b96ac08c
Author: Martin Sebor 
Date:   Sun Mar 1 17:35:49 2020 -0700

PR middle-end/93829 - bogus -Wstringop-overflow on memcpy of a struct with
a pointer member from another with a long string

gcc/testsuite/ChangeLog:

PR middle-end/93829
* gcc.dg/Wstringop-overflow-32.c: New test.

gcc/ChangeLog:

PR middle-end/93829
* tree-ssa-strlen.c (count_nonzero_bytes): Set the size to that
  of a pointer in the outermost ADDR_EXPRs.

[Bug c/93812] [9/10 Regression] ICE on redeclaration of an attribute format function without protoype

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Sebor  ---
Fixed.

[Bug tree-optimization/93927] ICE: 'verify_gimple' failed (error: invalid conversion in gimple call)

[msebor at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93927
Bug 93927 depends on bug 93926, which changed state.

Bug 93926 Summary: [10 Regression] ICE: verify_cgraph_node failed (error: 
malloc attribute should be used for a function that returns a pointer)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93926

   What|Removed |Added

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

[Bug middle-end/93926] [10 Regression] ICE: verify_cgraph_node failed (error: malloc attribute should be used for a function that returns a pointer)

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Sebor  ---
Fixed.

[Bug libstdc++/93991] FAIL: 22_locale/time_get/get_time/char/2.cc execution test - 'errorstate == ios_base::eofbit' failed

[danglin at gcc dot gnu.org]

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

--- Comment #1 from John David Anglin  ---
Revision 275589 was okay.

[Bug middle-end/93518] missing warning on a possible overflow by sprintf %s with an allocated argument

[xerofoify at gmail dot com]

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

Nicholas Krause  changed:

   What|Removed |Added

 CC||xerofoify at gmail dot com

--- Comment #1 from Nicholas Krause  ---
Hi Martin,

I'm not sure if my analysis is correct but it seems that:
int idx = get_stridx (src);

is only for string lengths and not POINTER_TYPE_P. There
are versions for ADDR expressions but don't seem to be
any for POINTER_TYPE_P. I'm wondering if we can implement
around version of stridx for this as it seems that the
line mentioned would need to call one for POINTER_P types
to fix the issue. Not sure how trivial it would be implement
that.

[Bug c++/93992] New: faile to compile specialization of inner class with template template parameter pack

[yawaraka.7-11.hemogurobin at ezweb dot ne.jp]

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

Bug ID: 93992
   Summary: faile to compile specialization of inner class with
template template parameter pack
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yawaraka.7-11.hemogurobin at ezweb dot ne.jp
  Target Milestone: ---

// Source

#include 
#include 
#include 
#include 

template class A {
};

template class, T...> struct args_union;
template class TemplateType, T Head, T... Tail>
struct args_union {
template struct args_union_sub;
template struct args_union_sub {
template using template_type =   
std::conditional_t<(Head2 < Head), TemplateType,// if (Head2 < Head) TemplateType;
TemplateType>;  
// else TemplateType;

using type = std::conditional_t::template args_union_sub::type,//   
args_union、args_union_sub
std::conditional_t<(Head < Head2), 
   
// else if (Head < Head2)
typename args_union::template args_union_sub::type, //args_union
   
   
// else
typename args_union::template args_union_sub::type>>;//args_union_sub
};
template<> struct args_union_sub<> {
template using template_type = TemplateType<>;
using type = TemplateType;
};
};

template class TemplateType> struct args_union {
template struct args_union_sub;
template struct args_union_sub {
template using template_type = TemplateType;
using type = TemplateType;
};
template<> struct args_union_sub<> {
template using template_type = TemplateType<>;
using type = TemplateType<>;
};
};

template struct Asub {
template using type = A;
};

template constexpr auto tmp_union(const
A&, const A&) {
return typename args_union::template type,
Value1...>::template args_union_sub::type();
}

int main() {
A a;
A b;  
std::cout << std::boolalpha << std::is_same_v> << std::endl;
std::cout << typeid(tmp_union(a, b)).name() << std::endl;
}

// error message
Using built-in specs.
COLLECT_GCC=/opt/wandbox/gcc-head/bin/g++
COLLECT_LTO_WRAPPER=/opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../source/configure --prefix=/opt/wandbox/gcc-head
--enable-languages=c,c++ --disable-multilib --without-ppl --without-cloog-ppl
--enable-checking=release --disable-nls --enable-lto
LDFLAGS=-Wl,-rpath,/opt/wandbox/gcc-head/lib,-rpath,/opt/wandbox/gcc-head/lib64,-rpath,/opt/wandbox/gcc-head/lib32
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200229 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-o' 'prog.exe' '-I' '/opt/wandbox/boost-sml/include' '-I'
'/opt/wandbox/boost-di/include' '-I' '/opt/wandbox/range-v3/include' '-I'
'/opt/wandbox/nlohmann-json/include' '-I' '/opt/wandbox/cmcstl2/include' '-I'
'/opt/wandbox/te/include' '-Wall' '-Wextra' '-O2' '-march=native' '-v'
'-std=gnu++2a' '-I' '/opt/wandbox/boost-1.72.0/gcc-head/include'
'-L/opt/wandbox/boost-1.72.0/gcc-head/lib' '-shared-libgcc'
 /opt/wandbox/gcc-head/libexec/gcc/x86_64-pc-linux-gnu/10.0.1/cc1plus -quiet -v
-I /opt/wandbox/boost-sml/include -I /opt/wandbox/boost-di/include -I
/opt/wandbox/range-v3/include -I /opt/wandbox/nlohmann-json/include -I
/opt/wandbox/cmcstl2/include -I /opt/wandbox/te/include -I
/opt/wandbox/boost-1.72.0/gcc-head/include -imultiarch x86_64-linux-gnu
-D_GNU_SOURCE prog.cc -march=sandybridge -mmmx -mno-3dnow -msse -msse2 -msse3
-mssse3 -mno-sse4a -mcx16 -msahf -mno-movbe -maes -mno-sha -mpclmul -mpopcnt
-mno-abm -mno-lwp -mno-fma -mno-fma4 -mno-xop -mno-bmi -mno-sgx -mno-bmi2
-mno-pconfig -mno-wbnoinvd -mno-tbm -mavx -mno-avx2 -msse4.2 -msse4.1
-mno-lzcnt -mno-rtm -mno-hle -mno-rdrnd -mno-f16c -mno-fsgsbase -mno-rdseed
-mno-prfchw -mno-adx -mfxsr -mxsave -mxsaveopt -mno-avx512f -mno-avx512er
-mno-avx512cd -mno-avx512pf -mno-prefetchwt1 -mno-clflushopt -mno-xsavec
-mno-xsaves -mno-avx512dq -mno-avx512bw -mno-avx512vl -mno-avx512ifma
-mno-avx512vbmi -mno-avx5124fmaps -mno-avx5124vnniw -mno-clwb -mno-mwaitx
-mno-clzero -mno-pku -mno-rdpid -mno-gfni -mno-shstk -mno-avx512vbmi2
-mno-avx512vnni -mno-vaes 

[Bug middle-end/93829] [10 Regression] bogus -Wstringop-overflow on memcpy of a struct with a pointer member from another with a long string

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Fixed.

[Bug c/93812] [9/10 Regression] ICE on redeclaration of an attribute format function without protoype

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:a499c2f899961f2c09db2dc33e60b66e8d770092

commit r10-6960-ga499c2f899961f2c09db2dc33e60b66e8d770092
Author: Martin Sebor 
Date:   Sun Mar 1 17:41:45 2020 -0700

PR c/93812 - ICE on redeclaration of an attribute format function without
protoype

gcc/c/ChangeLog:

PR c/93812
* c-typeck.c (build_functype_attribute_variant): New function.
(composite_type): Call it.

gcc/testsuite/ChangeLog:

PR c/93812
* gcc.dg/format/proto.c: New test.

[Bug tree-optimization/93971] std::string considered to alias declared objects of incompatible types

[glisse at gcc dot gnu.org]

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

--- Comment #7 from Marc Glisse  ---
(In reply to Martin Sebor from comment #6)
> (1) one that would make "std::string::ptr" on par with
> that of any other pointer other than char (i.e., a char that's not allowed
> to be used to access anything but a char object),

Are you sure a user isn't allowed to use placement new to construct an int in
the middle of a string? Maybe we should just encourage the use of u8string...

[Bug middle-end/93926] [10 Regression] ICE: verify_cgraph_node failed (error: malloc attribute should be used for a function that returns a pointer)

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:726e292d410fc29812a95eb6d88a2ceb82d9080d

commit r10-6961-g726e292d410fc29812a95eb6d88a2ceb82d9080d
Author: Martin Sebor 
Date:   Sun Mar 1 17:52:44 2020 -0700

PR middle-end/93926 - ICE on a built-in redeclaration returning an integer
instead of a pointer

gcc/c/ChangeLog:

PR middle-end/93926
* c-decl.c (types_close_enough_to_match): New function.
(match_builtin_function_types):
(diagnose_mismatched_decls): Add missing inform call to a warning.

gcc/testsuite/ChangeLog:

PR middle-end/93926
* gcc.dg/Wbuiltin-declaration-mismatch-13.c: New test.

[Bug middle-end/92721] [10 Regression] checking ICE on attribute access redeclaration

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|checking ICE on attribute   |[10 Regression] checking
   |access redeclaration|ICE on attribute access
   ||redeclaration

--- Comment #10 from Martin Sebor  ---
Fixed.

[Bug middle-end/92721] checking ICE on attribute access redeclaration

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:649e174102a8ae2d570616d09aa336b712e1baae

commit r10-6962-g649e174102a8ae2d570616d09aa336b712e1baae
Author: Martin Sebor 
Date:   Sun Mar 1 17:58:45 2020 -0700

PR middle-end/92721 - checking ICE on attribute access redeclaration

gcc/c-family/ChangeLog:

PR c++/92721
* c-attribs.c (append_access_attrs): Correctly handle attribute.
(handle_access_attribute): Same.

gcc/ChangeLog:

PR c++/92721
* calls.c (init_attr_rdwr_indices): Correctly handle attribute.

gcc/testsuite/ChangeLog:

PR c++/92721
g++.dg/ext/attr-access.C: New test.

[Bug testsuite/91799] [10 regression] r273245 breaks test case gcc.target/powerpc/pr88233.c

[segher at gcc dot gnu.org]

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

--- Comment #7 from Segher Boessenkool  ---
I hadn't fully tested it yet.

[Bug analyzer/93993] New: ICE in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4786

[asolokha at gmx dot com]

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

Bug ID: 93993
   Summary: ICE in make_region_for_unexpected_tree_code, at
analyzer/region-model.cc:4786
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gfortran-10.0.1-alpha20200301 snapshot
(g:151bf47e78f5d919f6cc591d11cc1f6aff61078f) ICEs when compiling the following
testcase w/ -O1 -fanalyzer:

module np
  implicit none
  integer, parameter :: za = selected_real_kind(15, 307)
end module np

module gg
  use np

  type et(real_kind)
integer, kind :: real_kind
  end type et

contains

  function hv (tm) result(ce)
type (et(real_kind=za)), allocatable, target :: tm
type (et(real_kind=za)), pointer :: ce

allocate (tm)
ce => tm
  end function hv

end module gg

program a5
  use np
  use gg
  implicit none
  type (et(real_kind=za)), allocatable :: qb
  type (et(real_kind=za)), pointer :: vt

  vt => hv (qb)
end program a5

% powerpc-e300c3-linux-gnu-gfortran-10.0.1 -O1 -fanalyzer -w -c ineya7os.f90
during IPA pass: analyzer
ineya7os.f90:21:0:

   21 |   end function hv
  | 
internal compiler error: in make_region_for_unexpected_tree_code, at
analyzer/region-model.cc:4786
0x74c35f
ana::region_model::make_region_for_unexpected_tree_code(ana::region_model_context*,
tree_node*, dump_location_t const&)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/region-model.cc:4786
0x74c35f
ana::region_model::make_region_for_unexpected_tree_code(ana::region_model_context*,
tree_node*, dump_location_t const&)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/region-model.cc:4782
0x1271af6 ana::region_model::get_lvalue_1(ana::path_var,
ana::region_model_context*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/region-model.cc:4650
0x1272043 ana::region_model::get_lvalue(ana::path_var,
ana::region_model_context*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/region-model.cc:4811
0x17fb7d5 ana::state_change_event::get_lvalue(tree_node*) const
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/checker-path.h:206
0x17fb7d5 ana::diagnostic_manager::prune_for_sm_diagnostic(ana::checker_path*,
ana::state_machine const*, tree_node*, unsigned int) const
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/diagnostic-manager.cc:1161
0x17fba62 ana::diagnostic_manager::prune_path(ana::checker_path*,
ana::state_machine const*, tree_node*, unsigned int) const
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/diagnostic-manager.cc:1056
0x17fbd5c ana::diagnostic_manager::emit_saved_diagnostic(ana::exploded_graph
const&, ana::saved_diagnostic const&, ana::exploded_path const&, gimple const*,
int)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/diagnostic-manager.cc:520
0x17fc86a ana::dedupe_winners::emit_best(ana::diagnostic_manager*,
ana::exploded_graph const&)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/diagnostic-manager.cc:446
0x17fc86a ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/diagnostic-manager.cc:489
0x1253aaf ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/engine.cc:3807
0x12548c1 ana::run_checkers()
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/engine.cc:3850
0x1248518 execute
   
/var/tmp/portage/cross-powerpc-e300c3-linux-gnu/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/analyzer-pass.cc:84

(While my target here is powerpc, the ICE is not target-specific.)

[Bug tree-optimization/93745] Redundant store not eliminated with intermediate instruction

[rguenther at suse dot de]

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

--- Comment #13 from rguenther at suse dot de  ---
On Thu, 27 Feb 2020, msebor at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93745
> 
> --- Comment #11 from Martin Sebor  ---
> Regarding the DECL_FIXED_DYNAMIC_TYPE flag: it seems like in C every DECL 
> would
> have it set, but in C++ none could (because placement new can change the
> dynamic type of decls), and so GCC would not be able to optimize the example 
> in
> that language even though there the read via *p means that p cannot alias d.
> 
> If what's keeping GCC from optimizing the code is the fact that the middle-end
> doesn't distinguish placement new from plain assignment, i.e., that it can't
> tell that the original source didn't look like this:
> 
>   double d;
> 
>   void f (long *p)
>   {
> long i = *p;
> new () double (3);
> *p = i;
>   }
> 
> wouldn't the solution be to keep placement new around in some form and teach
> the middle-end how to work with it?

We had this and it didn't work (OK, we only kept it in GIMPLE but not RTL
which is of course a non-starter).  Feel free to come up with a solid
proposal and implementation.

What would eventually work (but again not for the specific example TU)
is an IPA pass constraining the dynamic type of global variables.  But
then that's then a natural extension of our lack of a flow-sensitive
[IPA] points-to analysis.

[Bug target/92658] x86 lacks vector extend / truncate

[rguenther at suse dot de]

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

--- Comment #8 from rguenther at suse dot de  ---
On Fri, 28 Feb 2020, ubizjak at gmail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
> 
> --- Comment #3 from Uroš Bizjak  ---
> Richi, should the following test also vectorize?

In priciple yes.  I see both cases "vectorized" to a store
from a CTOR but then my primitive pattern matching in forwprop
not applying because supportable_convert_operation is confused
about a vector(4) char type having SImode and bailing out at the

292   if (!VECTOR_MODE_P (m1) || !VECTOR_MODE_P (m2))
293 return false;

check.  So it looks like with just SSE2 the backend doesn't
consider V4QImode a supported vector type.  I'm not sure we
want to fix that but then this means regular optab checks
won't do it here.

Interesting cases nevertheless.

Would those conversions map to good assembly?

> --cut here--
> typedef unsigned char v16qi __attribute__((vector_size (16)));
> typedef unsigned int v4si __attribute__((vector_size (16)));
> 
> void
> foo_u8_u32 (v4si * dst, v16qi * __restrict src)
> {
>   unsigned int tem[4];
>   tem[0] = (*src)[0];
>   tem[1] = (*src)[1];
>   tem[2] = (*src)[2];
>   tem[3] = (*src)[3];
>   dst[0] = *(v4si *) tem;
> }
> 
> void
> bar_u8_u32 (v4si * dst, v16qi src)
> {
>   unsigned int tem[4];
>   tem[0] = src[0];
>   tem[1] = src[1];
>   tem[2] = src[2];
>   tem[3] = src[3];
>   dst[0] = *(v4si *) tem;
> }
> --cut here--

[Bug analyzer/93994] New: ICE in get_or_create_mem_ref, at analyzer/region-model.cc:6599

[asolokha at gmx dot com]

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

Bug ID: 93994
   Summary: ICE in get_or_create_mem_ref, at
analyzer/region-model.cc:6599
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

g++-10.0.1-alpha20200301 snapshot (g:151bf47e78f5d919f6cc591d11cc1f6aff61078f)
ICEs when compiling
libstdc++-v3/testsuite/20_util/function_objects/mem_fn/adl.cc w/ -fanalyzer:

% g++-10.0.1 -fanalyzer -c
libstdc++-v3/testsuite/20_util/function_objects/mem_fn/adl.cc
during IPA pass: analyzer   
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/10.0.1/include/g++-v10/tuple:41,
 from
/usr/lib/gcc/x86_64-pc-linux-gnu/10.0.1/include/g++-v10/functional:54,
 from
libstdc++-v3/testsuite/20_util/function_objects/mem_fn/adl.cc:20:
/usr/lib/gcc/x86_64-pc-linux-gnu/10.0.1/include/g++-v10/bits/invoke.h: In
function 'constexpr _Res std::__invoke_impl(std::__invoke_memobj_ref,
_MemPtr&&, _Tp&&) [with _Res = int&&; _MemPtr = int n::X::*&; _Tp = n::X]':
/usr/lib/gcc/x86_64-pc-linux-gnu/10.0.1/include/g++-v10/bits/invoke.h:79:34:
internal compiler error: in get_or_create_mem_ref, at
analyzer/region-model.cc:6599
   79 | { return __invfwd<_Tp>(__t).*__f; }
  |  ^~~
0x7dd077 ana::region_model::get_or_create_mem_ref(tree_node*, ana::svalue_id,
ana::svalue_id, ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/region-model.cc:6599
0x136366c ana::region_model::get_or_create_pointer_plus_expr(tree_node*,
ana::svalue_id, ana::svalue_id, ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/region-model.cc:6682
0x136366c ana::region_model::on_assignment(gassign const*,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/region-model.cc:4005
0x133c998 ana::exploded_node::on_stmt(ana::exploded_graph&, ana::supernode
const*, gimple const*, ana::program_state*, ana::state_change*) const
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/engine.cc:1006
0x133d3c1 ana::exploded_graph::process_node(ana::exploded_node*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/engine.cc:2517
0x133d8aa ana::exploded_graph::process_worklist()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/engine.cc:2335
0x133dfd9 ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/engine.cc:3793
0x133ea7c ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/engine.cc:3850
0x1333908 execute
   
/var/tmp/portage/sys-devel/gcc-10.0.1_alpha20200301/work/gcc-10-20200301/gcc/analyzer/analyzer-pass.cc:84

[Bug fortran/93794] [8/9/10 Regression] ICE in gfc_conv_component_ref, at fortran/trans-expr.c:2497

[pault at gcc dot gnu.org]

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pault at gcc dot gnu.org

--- Comment #2 from Paul Thomas  ---
Created attachment 47944
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47944=edit
Patch for the PR

The test below does the right thing and the code is as expected.

Paul

program p
   type t
  character(:), pointer :: a
   end type
   type(t) :: z
   character(4), target :: c = 'abcd'
   z%a => c
   associate (y => z%a)
  print *, y
   end associate
end