Re: [PATCH] rs6000: fmr gets used instead of faster xxlor [PR93571]

[Ajit Agarwal via Gcc-patches]

Hello Segher:

On 24/02/23 8:41 pm, Segher Boessenkool wrote:
> Hi!
> 
> For future patches: please don't send patches as replies to existing
> threads.  Just start a new thread for a new patch (series).  You can
> mark it as [PATCH v2] in the subject, if you want.
> 
> On Fri, Feb 24, 2023 at 01:41:49PM +0530, Ajit Agarwal wrote:
>> Here is the patch that uses xxlor instead of fmr where possible.
>> Performance results shows that fmr is better in power9 and 
>> power10 architectures whereas xxlor is better in power7 and
>> power 8 architectures.
> 
> And fmr is the only option before p7.
> 
>>  rs6000: Use xxlor instead of fmr where possible
>>
>>  This patch replaces fmr with xxlor instruction for power7
>>  and power8 architectures whereas for power9 and power10
>>  replaces xxlor with fmr instruction.
> 
> Saying "this patch" in a commit message reads strangely.  Just "Replace
> fmr with" etc.?
> 

I will correct this.

> The second part is just wrong, you cannot replace xxlor by fmr in
> general.
> 
>>  Perf measurement results:
>>
>>  Power9 fmr:  201,847,661 cycles.
>>  Power9 xxlor: 201,877,78 cycles.
>>  Power8 fmr: 201,057,795 cycles.
>> Power8 xxlor: 201,004,671 cycles.
> 
> What is this measuring?  100M insns back-to-back, each dependent on the
> previous one?
> 
Yes.

> What are the results on p7 and p10?
> 
> These numbers show there is no difference on p8 either.  Did you paste
> the wrong numbers maybe?
>

I will measure it again and update with a new patch.
 
>>  * config/rs6000/rs6000.md (*movdf_hardfloat64): Use xxlor
>>  for power7 and power8 and fmr for power9 and power10.
> 
> Please don't break lines early.  Changelogs lines can be 80 columns
> wide, just like source code lines.
> 
>> --- a/gcc/config/rs6000/rs6000.md
>> +++ b/gcc/config/rs6000/rs6000.md
>> @@ -354,7 +354,7 @@ (define_attr "cpu"
>>(const (symbol_ref "(enum attr_cpu) rs6000_tune")))
>>  
>>  ;; The ISA we implement.
>> -(define_attr "isa" "any,p5,p6,p7,p7v,p8v,p9,p9v,p9kf,p9tf,p10"
>> +(define_attr "isa" "any,p5,p6,p7,p7v,p8v,p9,p9v,p9kf,p9tf,p7p8,p10"
> 
> p78v, and sort it after p8v please.
> 
>> + (and (eq_attr "isa" "p7p8")
>> +  (match_test "TARGET_VSX && !TARGET_P9_VECTOR"))
>> + (const_int 1)
> 
> Okay.
> 
>>  (define_insn "*mov_hardfloat64"
>>[(set (match_operand:FMOVE64 0 "nonimmediate_operand"
>> -   "=m,   d,  d,  ,   wY,
>> - ,Z,  ,  ,  !r,
>> - YZ,  r,  !r, *c*l,   !r,
>> -*h,   r,  ,   wa")
>> +   "=m,   d,  ,  ,   wY,
>> +, Z,  wa, ,  !r,
>> +YZ,   r,  !r, *c*l,   !r,
>> +*h,   r,  ,   d,  wn,
>> +wa")
>>  (match_operand:FMOVE64 1 "input_operand"
> 
> (You posted this mail as wrapping.  That means the patch cannot be
> applied non-manually, and that replies to your mail will be mangled.
> Just get a Real mail client, and configure it correctly :-) )
>

I am using Thunderbird as mail client and the settings are all correct.
I have set the mailnews.wrapLength 0.

 
>> -"d,   m,  d,  wY, ,
>> - Z,   ,   ,  ,  ,
>> +"d,   m,  ,  wY, ,
>> + Z,   ,   wa, ,  ,
>>   r,   YZ, r,  r,  *h,
>> - 0,   ,   r,  eP"))]
>> + 0,   ,   r,  d,  wn,
>> + eP"))]
> 
> No.  It is impossible to figure out what you changed here by just
> reading it.
> 
> There is no requirement there should be exactly five alternatives per
> line, and/or that there should be the same number everywhere.
> 
> If the indentation was incorrect, and you want to fix that, do that in a
> separate *earlier* patch in the series, please.
> 

I will Keep indentation as same.
>>"TARGET_POWERPC64 && TARGET_HARD_FLOAT
>> && (gpc_reg_operand (operands[0], mode)
>> || gpc_reg_operand (operands[1], mode))"
>>"@
>> stfd%U0%X0 %1,%0
>> lfd%U1%X1 %0,%1
>> -   fmr %0,%1
>> +   xxlor %x0,%x1,%x1
>> lxsd %0,%1
>> stxsd %1,%0
>> lxsdx %x0,%y1
>> stxsdx %x1,%y0
>> -   xxlor %x0,%x1,%x1
>> +   fmr %0,%1
>> xxlxor %x0,%x0,%x0
>> li %0,0
>> std%U0%X0 %1,%0
>> @@ -8467,23 +8474,28 @@ (define_insn "*mov_hardfloat64"
>> nop
>> mfvsrd %0,%x1
>> mtvsrd %x0,%1
>> +   fmr %0,%1
>> +   fmr %0,%1
>> #"
>>[(set_attr "type"
>> -"fpstore, fpload, fpsimple,   fpload, fpstore,
>> +"fpstore, fpload, veclogical, fpload, fpstore,
>>   fpload,  fpstore,veclogical, veclogical, integer,
>>   store,   load,   *,  mtjmpr, mfjmpr,
>> -   

[Bug target/55218] armv6 doesn't use unaligned access for packed structures

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-02-25
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
Confirmed. very similar to PR 51709 if not the same.

[Bug middle-end/55658] bitfields and __attribute__((packed)) generate horrible code on x86_64

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||rogero at howzatt dot co.uk

--- Comment #5 from Andrew Pinski  ---
*** Bug 66364 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/66364] poor optimization of packed structs containing bitfields

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup of bug 55658.

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

[Bug middle-end/55658] bitfields and __attribute__((packed)) generate horrible code on x86_64

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
Mine, I am going to look into this for GCC 14 (seperately from the bitfield
lower since it also still happens with that pass).

That pass does give some extra information though on this (a slightly different
but similar enough testcase):
```
Trying to expand bitfield reference:
a_3(D)->la
base: *a_3(D) orig bitpos: 0 bytepos: 0
after bit_range bitpos: 0 bytepos: 0 bitregion_start: 0 bitregion_end: 63
align: 8 word_size: 64.
failed, get_best_mode return false.
```

So basically get_best_mode failed with the above arguments ...

[Bug middle-end/108920] Condition falsely optimized out

[agner at agner dot org via Gcc-bugs]

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

--- Comment #3 from Agner Fog  ---
It seems to work with gcc 9.4.0.
Thank you

[Bug target/108922] fmod() 13x slowdown in gcc4.9 dropping "fprem" and calling fmod()

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-02-25
 Status|UNCONFIRMED |WAITING

--- Comment #2 from Andrew Pinski  ---
So the simple test is run the full GCC bootstrap/test with all languages and
check if the testcase fails or not. I suspect it will.

[Bug target/108922] fmod() 13x slowdown in gcc4.9 dropping "fprem" and calling fmod()

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
>The committer also claims "fixes ieee_2.f90 testsuite failure" but I have no 
>idea where to find this testsuite.


./testsuite/gfortran.dg/ieee/ieee_2.f90

Re: [PATCH] RISC-V: Disable attribute generation by default

[Palmer Dabbelt]

On Fri, 24 Feb 2023 05:09:30 PST (-0800), gcc-patches@gcc.gnu.org wrote:

It did help people to identify what extension used in the binary, so I
would prefer keep that enable by default.


IMO it actually hurts more than helps, as it's not really encoding what 
extensions are in the binary (or necessary to run the binary) but 
instead just encodes what was in -march (with some noise added due to 
the merging bugs and ISA string changes).  Having the attributes just 
ends up tricking users into thinking the information is accurate when 
it's not.



and lld is begin fix those merge issue, so the situation should be improved
soon.


If toolchains are just going to ignore then attributes then it's a 
pretty good sign they're not useful.



Palmer Dabbelt  於 2023年2月24日 週五 10:29 寫道：


We generate a handful of attributes by default, but they don't really
encode any useful information.  We've broadly stopped ascribing any
meaning to them in binutils; but they trip up LLVM, older toolchains,
and users.  So let's just turn them off by default.  The old binaries
will still be floating around, but at least this way we'll stop tripping
over new incompatibilities.

If we get to a point where there's some attributes that are defined that
we can use then we can sort out how to turn those on without turning on
the old ones, but unless I'm missing something the current set of
attributes are too broken to be useful for anything.

gcc/ChangeLog:

* config.gcc (--with-riscv-attribute): Default to off.
---
I know it's pretty late, but I'd like to target this for GCC-13.  The
Zmmul stuff has resulted in another round of build breakages that we're
going to have to chase down, and while we could update everything to
turn off the attributes it seems easier to just set the default.
---
 gcc/config.gcc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config.gcc b/gcc/config.gcc
index c070e6ecd2e..52639cf26d6 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -4596,7 +4596,7 @@ case "${target}" in
tm_defines="${tm_defines} TARGET_RISCV_ATTRIBUTE=0"
;;
""|default)
-   tm_defines="${tm_defines} TARGET_RISCV_ATTRIBUTE=1"
+   tm_defines="${tm_defines} TARGET_RISCV_ATTRIBUTE=0"
;;
*)
echo
"--with-riscv-attribute=${with_riscv_attribute} is not supported.  The
argument must begin with yes, no or default." 1>&2
--
2.39.1

[Bug middle-end/108920] Condition falsely optimized out

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
I linked a few bugs which might be the same issue here (I have not looked into
the code otherwise) and they were both fixed in GCC 9.4.0 even.
So yes please try out GCC 9.5.0 or 10.x even.

[Bug c++/108893] attribute access read_only

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from Andrew Pinski  ---
access attribute says if it is access, then it will be that. It does not say it
MUST be accessed. That is what nonnull is for.

>I didn't want to use __attribute__((nonnull)) because the optimizer may use 
>that knowledge to remove nullptr checks. 

It only uses it afterwards or inside the function.
It cannot use nonnull attribute to optimize before the access has happened.

[Bug c++/108893] attribute access read_only

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|DUPLICATE   |INVALID

--- Comment #6 from Andrew Pinski  ---
>From the manual:
Also, the access attribute does not imply the attribute nonnull; it may be
appropriate to add both attributes at the declaration of a function that
unconditionally manipulates a buffer via a pointer argument. See the nonnull
attribute for more information and caveats.

[Bug c++/108893] attribute access read_only

[jg at jguk dot org via Gcc-bugs]

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

--- Comment #5 from Jonny Grant  ---
Here is an example, no warnings during compilation.

https://godbolt.org/z/h8E7r3Wf8

#include 
// Try get a build warning for nullptr dereference
__attribute__ ((access (read_only, 1, 2))) void f(char * s, size_t size);

void f(char * s, size_t size)
{
*s = 'a';
}

int main()
{
char * s = nullptr;
f(s, 1);
}

[Bug c++/108930] Internal compiler error with -fopenmp (tsubst_omp_for_iterator)

[michael_greenburg at byu dot edu via Gcc-bugs]

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

--- Comment #2 from michael_greenburg at byu dot edu ---
Created attachment 54535
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54535=edit
The *.ii file from `-save-temps`

[Bug c++/108930] Internal compiler error with -fopenmp (tsubst_omp_for_iterator)

[michael_greenburg at byu dot edu via Gcc-bugs]

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

--- Comment #1 from michael_greenburg at byu dot edu ---
Created attachment 54534
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54534=edit
The *.out file from `-freport-bug`

[Bug c++/108930] New: Internal compiler error with -fopenmp (tsubst_omp_for_iterator)

[michael_greenburg at byu dot edu via Gcc-bugs]

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

Bug ID: 108930
   Summary: Internal compiler error with -fopenmp
(tsubst_omp_for_iterator)
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: michael_greenburg at byu dot edu
  Target Milestone: ---

Created attachment 54533
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54533=edit
The source file

GCC VERSION: 12.1.0. The error also occurs with versions 10.2.0, 11.2.0, and
12.2.1; 12.2.1 is the default GCC that comes with Arch, the others I built on
the same system as 12.1.0.

SYSTEM TYPE: Linux x86_64 (RHEL 7.9)

CONFIGURED WITH: /apps/src/gcc/src/gcc-12.1.0/configure
--prefix=/apps/gcc/12.1.0 --with-arch=haswell --with-tune=znver3
--with-fpmath=avx --enable-host-shared --enable-threads --enable-__cxa_atexit
--enable-valgrind-annotations --disable-multilib --with-dwarf2

GCC COMMAND LINE: g++ -std=c++20 -fopenmp -freport-bug -save-temps -Wall
-Wextra trigger_bug.cc

OBSERVED AND EXPECTED BEHAVIOR: I would expect the program to compile and run
successfully (as it does without `-fopenmp`) rather than dying on an internal
compiler error.

I've attached `trigger_bug.cc` (a minimal example) and will also attach the
*.out file that resulted from `-freport-bug` and the *.ii file that resulted
from `-save-temps`.

It seems like this might be related:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105839



COMPILER OUTPUT:
trigger_bug.cc: In instantiation of 'const auto product(std::array<_Tp, _Nm>)
[with T = int; long unsigned int N = 3]':
trigger_bug.cc:39:25:   required from here
trigger_bug.cc:26:9: internal compiler error: in tsubst_omp_for_iterator, at
cp/pt.cc:18126
   26 | for (auto i=ibegin; ihttps://gcc.gnu.org/bugs/> for instructions.
Preprocessed source stored into /tmp/ccvkbzHf.out file, please attach this to
your bugreport.

gcc-11-20230224 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20230224 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20230224/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 11 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch 
releases/gcc-11 revision d832f1977440565f9cb8e154c8ff92c36714d2e8

You'll find:

 gcc-11-20230224.tar.xz   Complete GCC

  SHA256=73ac9c6d8dedf9f160e3a58815485282646dd802b1f561b56f274fc786867917
  SHA1=5a84a87983bd6ae8b1e557cc9d8b05a86ae45e96

Diffs from 11-20230217 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-11
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug ipa/108871] attribute nonnull does not spot nullptr O2 and above when function inlined

[jg at jguk dot org via Gcc-bugs]

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

--- Comment #7 from Jonny Grant  ---
(In reply to Jakub Jelinek from comment #6)
> (In reply to Jonathan Wakely from comment #5)
> > (In reply to Andrew Pinski from comment #3)
> > > *** Bug 108893 has been marked as a duplicate of this bug. ***
> > 
> > N.B. this one is about __attribute__((access(read_only, 1))) not nonnull.
> > The docs already seem to imply that it requires a non-null pointer:
> > 
> >   The read_only access mode specifies that the pointer to which it applies
> > is used to
> >   read the referenced object but not write to it. Unless the argument
> > specifying the
> >   size of the access denoted by size-index is zero, the referenced object
> > must be
> >   initialized.
> > 
> > If a non-zero size implies an initialized object, then it also implies a
> > non-null pointer (since a null pointer doesn't point to an initialized
> > object).
> > 
> > I don't know if we want this PR to be specific to the nonnull attribute, or
> > if it makes sense to use it for access(read_only) too.
> 
> On the other side, looking at glibc sources, access attributes there are
> used on many functions together with nonnull attributes for the same
> arguments and in many cases in places where there are not nonnull
> attributes.  So, making access attribute imply non-null might not be
> desirable in real-world unless it is already implied.
> So it might be just that it is badly documented.

Hi Jakub, Did you manage to get gcc to give a build warning from those
__attr_access read_only lines in glibc?  I haven't found a way to activate any
build warnings.  

attribute nonnull seems to be used by optimizer to remove any NULL checks it
finds.

Re: Support for WEAK attribute, part 2

[Harald Anlauf via Gcc-patches]

Hi Rimvydas,

Am 24.02.23 um 06:16 schrieb Rimvydas Jasinskas via Gcc-patches:

On Thu, Feb 23, 2023 at 10:53 PM Harald Anlauf  wrote:

the patch is mostly fine, but there is a minor style issue:

+  if (sym->attr.ext_attr & (1 << EXT_ATTR_WEAK))
+   gfc_error ("Symbol %qs at %L has the WEAK attribute but is a %s",
+  sym->name, >declared_at, sym->attr.dummy
+  ? "dummy argument" : "local variable");
+

It is my understanding that this is not translation-friendly.
Please use separate error texts for either case instead.

Interesting, I was under the impression this was fixed with OO-inlines
around the *.c rename.


if this is the case, I must have missed it.

> In any case, adjusted in v2 to use:

+  if (sym->attr.ext_attr & (1 << EXT_ATTR_WEAK))
+{
+  if (sym->attr.dummy)
+gfc_error ("Symbol %qs at %L has the WEAK attribute but is a "
+   "dummy argument", sym->name, >declared_at);
+  else
+gfc_error ("Symbol %qs at %L has the WEAK attribute but is a "
+   "local variable", sym->name, >declared_at);
+}


This is ok.


These testcases are dg-compile and do not go through the "-O0 -O1 -O2
-O3 -Os" options like dg-run.  Combining the testcases does not reduce
gfortran.sum a lot:


I wasn't thinking of gfortran.sum, it's about the total overhead of
the testsuite (dejagnu etc.).  But thanks for combining the tests!


Finally, please do not forget to CC patches to gcc-patches@
so that others can see them.

Out of curiosity, what is the purpose of CC patches to gcc-patches
too?  Attachments are even available in web mailing list too, like in:
https://gcc.gnu.org/pipermail/fortran/2023-February/058953.html


Well, patches should always go the gcc-patches@, see e.g.

https://gcc.gnu.org/gitwrite.html

On the other hand, many *Fortran* reviewers will ignore patches
there and look at them only when they are sent to fortran@.

Thanks for your patch, pushed as r13-6338-gbcbeebc498126c .

Harald


Regards,
Rimvydas

[Bug fortran/108923] memory leak of get_intrinsic_dummy_arg result

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #5 from anlauf at gcc dot gnu.org ---
At r13-6337-g24c9edfa73632276d7698c103f35833f29804d98 is still get for
testcase

  gcc/testsuite/gfortran.dg/predcom-1.f


==2885== 32 bytes in 2 blocks are definitely lost in loss record 8 of 354
==2885==at 0x4C39571: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==2885==by 0x2077B44: xcalloc (xmalloc.c:164)
==2885==by 0x90FE52: get_intrinsic_dummy_arg (intrinsic.cc:4265)
==2885==by 0x90FE52: sort_actual(char const*, gfc_actual_arglist**,
gfc_intrinsic_arg*, locus*) (intrinsic.cc:4433)
==2885==by 0x9100E8: check_specific(gfc_intrinsic_sym*, gfc_expr*, int)
(intrinsic.cc:4774)
==2885==by 0x918D29: gfc_intrinsic_func_interface(gfc_expr*, int)
(intrinsic.cc:5032)
==2885==by 0x97DB9D: resolve_generic_f0 (resolve.cc:2772)
==2885==by 0x97DB9D: resolve_generic_f (resolve.cc:2789)
==2885==by 0x97DB9D: resolve_function (resolve.cc:3347)
==2885==by 0x97DB9D: gfc_resolve_expr(gfc_expr*) [clone .part.0]
(resolve.cc:7211)
==2885==by 0x980B4F: gfc_resolve_expr (resolve.cc:7177)
==2885==by 0x980B4F: resolve_operator(gfc_expr*) (resolve.cc:4092)
==2885==by 0x97BC57: gfc_resolve_expr(gfc_expr*) [clone .part.0]
(resolve.cc:7204)
==2885==by 0x985AF8: gfc_resolve_expr (resolve.cc:7177)
==2885==by 0x985AF8: gfc_resolve_code(gfc_code*, gfc_namespace*)
(resolve.cc:12011)
==2885==by 0x989425: gfc_resolve_blocks(gfc_code*, gfc_namespace*)
(resolve.cc:10996)
==2885==by 0x985AAD: gfc_resolve_code(gfc_code*, gfc_namespace*)
(resolve.cc:11997)
==2885==by 0x98921D: resolve_codes(gfc_namespace*) (resolve.cc:17670)

Re: [Patch] Fortran: Skip bound conv in gfc_conv_gfc_desc_to_cfi_desc with intent(out) ptr [PR108621]

[Harald Anlauf via Gcc-patches]

Hi Tobias,

Am 24.02.23 um 12:31 schrieb Tobias Burnus:

(B) The attached patch:

With 'intent(out)' there is no reason to do the conversions. While for
nullified
pointers the bounds-conversion loop is skipped, it may still be executed
for undefined
pointers. (Which is usually harmless.) In either case, not generating
this code makes
sense.

OK for mainline?


LGTM.

I was pondering whether one should keep the testcase closer to the
one in the PR, but the essence of the bug and the fix is well
represented in the reduced version, and also the tree dump tells
the whole story anyway.


Regarding GCC 12:  I am not really sure as it is no real regression.
Besides bogus
warnings, there might be an issue for undefined pointers and
-fsanitize=undefined, namely
if 'ubound - lbound' evaluated on random numbers overflows (such as for
ubound = huge(..)
and lbound = -huge(..)). But that looks like a rather special case. -
Thoughts?


I'd rather consider the case of undefined pointers as of practical
importance.  It's up to you or others to decide whether it should
be backported.  I would not oppose.

Thanks for the patch!

Harald


Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201,
80634 München; Gesellschaft mit beschränkter Haftung; Geschäftsführer:
Thomas Heurung, Frank Thürauf; Sitz der Gesellschaft: München;
Registergericht München, HRB 106955

[pushed] fortran: Plug leak of associated_dummy memory. [PR108923]

[Mikael Morin]

Hello,

I have just pushed a for PR108923 (a memory leak).
It fixes the small reproducer that I pasted in bugzilla, and I have run 
it through the fortran regression testsuite.

More details in the patch.From 545a7d5da5fcc338e29c5241b574ac99d03f4454 Mon Sep 17 00:00:00 2001
From: Mikael Morin 
Date: Fri, 24 Feb 2023 22:11:17 +0100
Subject: [PATCH] fortran: Plug leak of associated_dummy memory. [PR108923]

This fixes a memory leak by accompanying the release of
gfc_actual_arglist elements' memory with a release of the
associated_dummy field memory (if allocated).
Actual argument copy is adjusted as well so that each copy can free
its field independently.

	PR fortran/108923

gcc/fortran/ChangeLog:

	* expr.cc (gfc_free_actual_arglist): Free associated_dummy
	memory.
	(gfc_copy_actual_arglist): Make a copy of the associated_dummy
	field if it is set in the original element.
---
 gcc/fortran/expr.cc | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index c295721b9d6..4662328bf31 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -545,6 +545,7 @@ gfc_free_actual_arglist (gfc_actual_arglist *a1)
   a2 = a1->next;
   if (a1->expr)
 	gfc_free_expr (a1->expr);
+  free (a1->associated_dummy);
   free (a1);
   a1 = a2;
 }
@@ -565,6 +566,12 @@ gfc_copy_actual_arglist (gfc_actual_arglist *p)
   new_arg = gfc_get_actual_arglist ();
   *new_arg = *p;
 
+  if (p->associated_dummy != NULL)
+	{
+	  new_arg->associated_dummy = gfc_get_dummy_arg ();
+	  *new_arg->associated_dummy = *p->associated_dummy;
+	}
+
   new_arg->expr = gfc_copy_expr (p->expr);
   new_arg->next = NULL;
 
-- 
2.39.1

[Bug fortran/108923] memory leak of get_intrinsic_dummy_arg result

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Mikael Morin :

https://gcc.gnu.org/g:24c9edfa73632276d7698c103f35833f29804d98

commit r13-6337-g24c9edfa73632276d7698c103f35833f29804d98
Author: Mikael Morin 
Date:   Fri Feb 24 22:11:17 2023 +0100

fortran: Plug leak of associated_dummy memory. [PR108923]

This fixes a memory leak by accompanying the release of
gfc_actual_arglist elements' memory with a release of the
associated_dummy field memory (if allocated).
Actual argument copy is adjusted as well so that each copy can free
its field independently.

PR fortran/108923

gcc/fortran/ChangeLog:

* expr.cc (gfc_free_actual_arglist): Free associated_dummy
memory.
(gfc_copy_actual_arglist): Make a copy of the associated_dummy
field if it is set in the original element.

[Bug fortran/68800] Fortran FE produces many memory leaks

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #7 from anlauf at gcc dot gnu.org ---
gfortran.dg/gomp/associate1.f90 is another candidate showing one of the
tracebacks as in comment#0, even without -fopenmp:

==5113== 224 bytes in 1 blocks are definitely lost in loss record 276 of 356
==5113==at 0x4C39571: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5113==by 0x205F054: xcalloc (xmalloc.c:164)
==5113==by 0x8F891F: gfc_get_expr() (expr.cc:49)
==5113==by 0x96ED01: gfc_match_rvalue(gfc_expr**) (primary.cc:3831)
==5113==by 0x9338DE: match_primary (matchexp.cc:157)
==5113==by 0x9338DE: match_level_1 (matchexp.cc:211)
==5113==by 0x9338DE: match_mult_operand(gfc_expr**) (matchexp.cc:267)
==5113==by 0x933C18: match_add_operand(gfc_expr**) (matchexp.cc:356)
==5113==by 0x933F0F: match_level_2(gfc_expr**) (matchexp.cc:480)
==5113==by 0x9340D6: match_level_3(gfc_expr**) (matchexp.cc:551)
==5113==by 0x934212: match_level_4 (matchexp.cc:599)
==5113==by 0x934212: match_and_operand(gfc_expr**) (matchexp.cc:693)
==5113==by 0x9343F6: match_or_operand(gfc_expr**) (matchexp.cc:722)
==5113==by 0x934506: match_equiv_operand(gfc_expr**) (matchexp.cc:765)
==5113==by 0x934618: match_level_5(gfc_expr**) (matchexp.cc:811)
==5113== 
==5113== 3,232 (672 direct, 2,560 indirect) bytes in 3 blocks are definitely
lost in loss record 322 of 356
==5113==at 0x4C39571: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5113==by 0x205F054: xcalloc (xmalloc.c:164)
==5113==by 0x8F891F: gfc_get_expr() (expr.cc:49)
==5113==by 0x96EABE: gfc_match_rvalue(gfc_expr**) (primary.cc:3579)
==5113==by 0x9338DE: match_primary (matchexp.cc:157)
==5113==by 0x9338DE: match_level_1 (matchexp.cc:211)
==5113==by 0x9338DE: match_mult_operand(gfc_expr**) (matchexp.cc:267)
==5113==by 0x933C18: match_add_operand(gfc_expr**) (matchexp.cc:356)
==5113==by 0x933F0F: match_level_2(gfc_expr**) (matchexp.cc:480)
==5113==by 0x9340D6: match_level_3(gfc_expr**) (matchexp.cc:551)
==5113==by 0x934212: match_level_4 (matchexp.cc:599)
==5113==by 0x934212: match_and_operand(gfc_expr**) (matchexp.cc:693)
==5113==by 0x9343F6: match_or_operand(gfc_expr**) (matchexp.cc:722)
==5113==by 0x934506: match_equiv_operand(gfc_expr**) (matchexp.cc:765)
==5113==by 0x934618: match_level_5(gfc_expr**) (matchexp.cc:811)
==5113== 
==5113== 4,864 (448 direct, 4,416 indirect) bytes in 2 blocks are definitely
lost in loss record 329 of 356
==5113==at 0x4C39571: calloc (in
/usr/lib/valgrind/vgpreload_memcheck-amd64-linux.so)
==5113==by 0x205F054: xcalloc (xmalloc.c:164)
==5113==by 0x8F891F: gfc_get_expr() (expr.cc:49)
==5113==by 0x96ED72: gfc_match_rvalue(gfc_expr**) (primary.cc:3816)
==5113==by 0x9338DE: match_primary (matchexp.cc:157)
==5113==by 0x9338DE: match_level_1 (matchexp.cc:211)
==5113==by 0x9338DE: match_mult_operand(gfc_expr**) (matchexp.cc:267)
==5113==by 0x933C18: match_add_operand(gfc_expr**) (matchexp.cc:356)
==5113==by 0x933F0F: match_level_2(gfc_expr**) (matchexp.cc:480)
==5113==by 0x9340D6: match_level_3(gfc_expr**) (matchexp.cc:551)
==5113==by 0x934212: match_level_4 (matchexp.cc:599)
==5113==by 0x934212: match_and_operand(gfc_expr**) (matchexp.cc:693)
==5113==by 0x9343F6: match_or_operand(gfc_expr**) (matchexp.cc:722)
==5113==by 0x934506: match_equiv_operand(gfc_expr**) (matchexp.cc:765)
==5113==by 0x934618: match_level_5(gfc_expr**) (matchexp.cc:811)

[Bug fortran/108924] memory leak in doloop_warn

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-02-24
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Taken.  Waiting on feedback.

[PATCH, committed] Fortran: frontend passes do_subscript leaks gmp memory [PR108924]

[Harald Anlauf via Gcc-patches]

Dear all,

as reported by Richard - although without a testcase - we leak
gmp memory in do_subscript().  The attached patch was derived
by inspection of the code pointed at by valgrind and regtested
on x86_64-pc-linux-gnu.

Committed as obvious as

commit r13-6336-g45f406c4f62e516b58dcda20b5a7aa43ff0aa0f3
Author: Harald Anlauf 
Date: Fri Feb 24 19:56:32 2023 +0100

Thanks,
Harald

From 45f406c4f62e516b58dcda20b5a7aa43ff0aa0f3 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Fri, 24 Feb 2023 19:56:32 +0100
Subject: [PATCH] Fortran: frontend passes do_subscript leaks gmp memory
 [PR108924]

gcc/fortran/ChangeLog:

	PR fortran/108924
	* frontend-passes.cc (do_subscript): Clear used gmp variable.
---
 gcc/fortran/frontend-passes.cc | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gcc/fortran/frontend-passes.cc b/gcc/fortran/frontend-passes.cc
index 02fcb41dbc4..90428982023 100644
--- a/gcc/fortran/frontend-passes.cc
+++ b/gcc/fortran/frontend-passes.cc
@@ -2883,7 +2883,10 @@ do_subscript (gfc_expr **e)
 		have_do_end = false;

 	  if (!have_do_start && !have_do_end)
-		return 0;
+		{
+		  mpz_clear (do_step);
+		  return 0;
+		}

 	  /* No warning inside a zero-trip loop.  */
 	  if (have_do_start && have_do_end)
--
2.35.3

[Bug bootstrap/108929] bfin-openbsd: Issues calling `as` when trying to build Module-2 components

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---

[cfg 2023-02-21 16:27:09] checking for as... no
[cfg 2023-02-21 16:27:09] checking for bfin-openbsd-as... no
..
[cfg 2023-02-21 16:27:09] checking where to find the target ar... pre-installed
[cfg 2023-02-21 16:27:09] checking where to find the target as... pre-installed

NOT a GCC bug.
There was no target as installed ...

[Bug fortran/108924] memory leak in doloop_warn

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:45f406c4f62e516b58dcda20b5a7aa43ff0aa0f3

commit r13-6336-g45f406c4f62e516b58dcda20b5a7aa43ff0aa0f3
Author: Harald Anlauf 
Date:   Fri Feb 24 19:56:32 2023 +0100

Fortran: frontend passes do_subscript leaks gmp memory [PR108924]

gcc/fortran/ChangeLog:

PR fortran/108924
* frontend-passes.cc (do_subscript): Clear used gmp variable.

[Bug driver/108929] bfin-openbsd: Issues calling `as` when trying to build Module-2 components

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2023-02-24

--- Comment #1 from Andrew Pinski  ---
>[all 2023-02-21 19:37:04] 
>/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/as: 114: exec: 
>-o: not found

Can you attach the toplevel config.log ?
I suspect you didn't build binutils first or not doing a combined build or
bfin-openbsd is not supported by binutils ...

[Bug driver/108929] New: bfin-openbsd: Issues calling `as` when trying to build Module-2 components

[jbglaw--- via Gcc-bugs]

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

Bug ID: 108929
   Summary: bfin-openbsd: Issues calling `as` when trying to build
Module-2 components
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jbg...@lug-owl.de
  Target Milestone: ---

Hi!

For --target=bfin-openbsd, I see the assembler being called in some way that
doesn't seem to work:

[all 2023-02-21 19:37:03] test -d
/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/gcc/m2/gm2-libs ||
/bin/bash ../../gcc/gcc/../mkinstalldirs
/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/gcc/m2/gm2-libs
[all 2023-02-21 19:37:03] echo "GM2_FOR_TARGET
/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/gm2
-B/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/ "
[all 2023-02-21 19:37:03] GM2_FOR_TARGET
/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/gm2
-B/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/ 
[all 2023-02-21 19:37:03] echo "GCC_FOR_TARGET
/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/xgcc
-B/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/ "
[all 2023-02-21 19:37:03] GCC_FOR_TARGET
/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/xgcc
-B/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/ 
[all 2023-02-21 19:37:03] /bin/bash ../../gcc/gcc/m2/tools-src/makeSystem -fpim
\
[all 2023-02-21 19:37:03]  ../../gcc/gcc/m2/gm2-libs/SYSTEM.def \
[all 2023-02-21 19:37:03]  ../../gcc/gcc/m2/gm2-libs/SYSTEM.mod \
[all 2023-02-21 19:37:03]  -I../../gcc/gcc/m2/gm2-libs \
[all 2023-02-21 19:37:03] 
"/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/gm2
-B/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/ "
/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/gcc/m2/gm2-libs/SYSTEM.def
[all 2023-02-21 19:37:04]
/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/as: 114: exec:
-o: not found
[all 2023-02-21 19:37:04] SYSTEM module creates type: LOC
[all 2023-02-21 19:37:04] SYSTEM module creates type: WORD
[all 2023-02-21 19:37:04] SYSTEM module creates type: BYTE
[all 2023-02-21 19:37:04] SYSTEM module creates type: ADDRESS
[all 2023-02-21 19:37:04] SYSTEM module creates type: INTEGER8
[all 2023-02-21 19:37:04] SYSTEM module creates type: INTEGER16
[all 2023-02-21 19:37:04] SYSTEM module creates type: INTEGER32
[all 2023-02-21 19:37:04] SYSTEM module creates type: INTEGER64
[all 2023-02-21 19:37:04] SYSTEM module creates type: CARDINAL8
[all 2023-02-21 19:37:04] SYSTEM module creates type: CARDINAL16
[all 2023-02-21 19:37:04] SYSTEM module creates type: CARDINAL32
[all 2023-02-21 19:37:04] SYSTEM module creates type: CARDINAL64
[all 2023-02-21 19:37:04] SYSTEM module creates type: WORD16
[all 2023-02-21 19:37:04] SYSTEM module creates type: WORD32
[all 2023-02-21 19:37:04] SYSTEM module creates type: WORD64
[all 2023-02-21 19:37:04] SYSTEM module creates type: BITSET8
[all 2023-02-21 19:37:04] SYSTEM module creates type: BITSET16
[all 2023-02-21 19:37:04] SYSTEM module creates type: BITSET32
[all 2023-02-21 19:37:04] SYSTEM module creates type: REAL32
[all 2023-02-21 19:37:04] SYSTEM module creates type: REAL64
[all 2023-02-21 19:37:04] SYSTEM module creates type: COMPLEX32
[all 2023-02-21 19:37:04] SYSTEM module creates type: COMPLEX64
[all 2023-02-21 19:37:04] SYSTEM module creates type: CSIZE_T
[all 2023-02-21 19:37:04] SYSTEM module creates type: CSSIZE_T
[all 2023-02-21 19:37:04]
/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/./gcc/as: 114: exec:
-o: not found
[all 2023-02-21 19:37:04] make[1]: *** [../../gcc/gcc/m2/Make-lang.in:1564:
/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/gcc/m2/gm2-libs/SYSTEM.def]
Error 1
[all 2023-02-21 19:37:04] rm m2/gm2-compiler-boot/P2Build.mod
m2/gm2-compiler-boot/P0SyntaxCheck.mod m2/gm2-compiler-boot/PCBuild.mod
m2/gm2-compiler-boot/PHBuild.mod m2/gm2-compiler-boot/P1Build.mod
m2/gm2-compiler-boot/P3Build.mod
[all 2023-02-21 19:37:04] make[1]: Leaving directory
'/var/lib/laminar/run/gcc-bfin-openbsd/35/toolchain-build/gcc'
[all 2023-02-21 19:37:05] make: *** [Makefile:4623: all-gcc] Error 2


(Full build lot at http://toolchain.lug-owl.de/laminar/log/gcc-bfin-openbsd/35)

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #30 from Iain Sandoe  ---
(In reply to ibuclaw from comment #29)
> (In reply to Iain Sandoe from comment #27)
> > great!
> > 
> > we make more progress now - at least past libphobos configure:
> > 
> > we now fail building druntime/core/atomic.d and I am not quite sure how to
> > interpret the backtrace (from b internal_error).
> >
> > d21`_D3dmd6access17checkSymbolAccessFPSQBh6dscope5ScopeCQBy7dsymbol7DsymbolZb
> > (sc=, s=) at access.d:296
> >
> My fear is that now it's corrupting the return in other ways now, this time
> within D itself.

I see.. that might be the tricky aspect of trying to have a different ABI
internally and for accessing C/C++.  Not sure how to solve it (are functions
with C-family interfaces marked as such?)

[Bug fortran/108923] memory leak of get_intrinsic_dummy_arg result

[mikael at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Mikael Morin  ---
Here is a small reproducer by the way:

program p
  implicit none
  call s(0)
contains
  subroutine s(i)
integer :: i
  end subroutine s
end program p

[Bug fortran/108923] memory leak of get_intrinsic_dummy_arg result

[mikael at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Mikael Morin  ---
(In reply to Mikael Morin from comment #1)
> Should be easy to fix anyway.

Not that easy after all.
The following (obvious) fix regresses heavily.

diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index c295721b9d6..73ee50e385c 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -545,6 +545,7 @@ gfc_free_actual_arglist (gfc_actual_arglist *a1)
   a2 = a1->next;
   if (a1->expr)
gfc_free_expr (a1->expr);
+  free (a1->associated_dummy);
   free (a1);
   a1 = a2;
 }

[Bug target/86802] riscv port needs updating for CVE-2017-5753

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
I doubt Jim is working on this any more.
I suspect we might need to have this defined for some cores and a way to
disable it fully for others (maybe even an option at build time). E.g. Linux
compilers should always define this while the elf compiler might not define
this.

[Bug target/108928] New: epiphany-elf: unrecognizable insn (internal compiler error: in extract_insn, at recog.cc:2791) triggered during Modula-2 build

[jbglaw--- via Gcc-bugs]

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

Bug ID: 108928
   Summary: epiphany-elf: unrecognizable insn (internal compiler
error: in extract_insn, at recog.cc:2791) triggered
during Modula-2 build
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jbg...@lug-owl.de
  Target Milestone: ---

Hi!

My automated testing found an issue with --target=epiphany-elf:

.../gcc/configure '--with-pkgversion=basepoints/gcc-13-6140-g63471c50088, built
at 1677005096'
--prefix=/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-install
--enable-werror-always --enable-languages=all --disable-gcov --disable-shared
--disable-threads --target=epiphany-elf --without-headers
[...]
make V=1 all-gcc
[...]
[all 2023-02-21 21:50:49] if test "xinfo" = xinfo; then \
[all 2023-02-21 21:50:49]   rm -f doc/gccgo.info*; \
[all 2023-02-21 21:50:49]   makeinfo --split-size=500 --no-split -I
../../gcc/gcc/doc \
[all 2023-02-21 21:50:49]   -I ../../gcc/gcc/doc/include -o doc/gccgo.info
../../gcc/gcc/go/gccgo.texi; \
[all 2023-02-21 21:50:49] else true; fi
[all 2023-02-21 21:50:50] test -d
/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/gcc/m2/gm2-libs ||
/bin/bash ../../gcc/gcc/../mkinstalldirs
/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/gcc/m2/gm2-libs
[all 2023-02-21 21:50:50] echo "GM2_FOR_TARGET
/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/gm2
-B/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/ "
[all 2023-02-21 21:50:50] GM2_FOR_TARGET
/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/gm2
-B/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/ 
[all 2023-02-21 21:50:50] echo "GCC_FOR_TARGET
/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/xgcc
-B/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/ "
[all 2023-02-21 21:50:50] GCC_FOR_TARGET
/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/xgcc
-B/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/ 
[all 2023-02-21 21:50:50] /bin/bash ../../gcc/gcc/m2/tools-src/makeSystem -fpim
\
[all 2023-02-21 21:50:50]  ../../gcc/gcc/m2/gm2-libs/SYSTEM.def \
[all 2023-02-21 21:50:50]  ../../gcc/gcc/m2/gm2-libs/SYSTEM.mod \
[all 2023-02-21 21:50:50]  -I../../gcc/gcc/m2/gm2-libs \
[all 2023-02-21 21:50:50] 
"/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/gm2
-B/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/./gcc/ "
/var/lib/laminar/run/gcc-epiphany-elf/34/toolchain-build/gcc/m2/gm2-libs/SYSTEM.def
[all 2023-02-21 21:50:50] ../../gcc/gcc/m2/gm2-libs/SYSTEM.mod: In function
'ShiftVal':
[all 2023-02-21 21:50:50] ../../gcc/gcc/m2/gm2-libs/SYSTEM.mod:89:1: error:
unrecognizable insn:
[all 2023-02-21 21:50:50]89 | END ShiftVal ;
[all 2023-02-21 21:50:50]   | ^~~
[all 2023-02-21 21:50:50] (insn 400 342 343 7 (parallel [
[all 2023-02-21 21:50:50] (set (mem/c:CC (plus:SI (reg/f:SI 11 fp)
[all 2023-02-21 21:50:50] (const_int 84 [0x54])) [7
%sfp+-20 S4 A32])
[all 2023-02-21 21:50:50] (reg:CC 18 r18))
[all 2023-02-21 21:50:50] (use (const_int -4337
[0xef0f]))
[all 2023-02-21 21:50:50] (clobber (scratch:SI))
[all 2023-02-21 21:50:50] ])
"../../gcc/gcc/m2/gm2-libs/SYSTEM.mod":80:32 discrim 1 -1
[all 2023-02-21 21:50:50]  (nil))
[all 2023-02-21 21:50:50] during RTL pass: reload
[all 2023-02-21 21:50:50] ../../gcc/gcc/m2/gm2-libs/SYSTEM.mod:89:1: internal
compiler error: in extract_insn, at recog.cc:2791
[all 2023-02-21 21:50:50] 0x670d08 _fatal_insn(char const*, rtx_def const*,
char const*, int, char const*)
[all 2023-02-21 21:50:50]   ../../gcc/gcc/rtl-error.cc:108
[all 2023-02-21 21:50:50] 0x670d24 _fatal_insn_not_found(rtx_def const*, char
const*, int, char const*)
[all 2023-02-21 21:50:50]   ../../gcc/gcc/rtl-error.cc:116
[all 2023-02-21 21:50:50] 0x66f763 extract_insn(rtx_insn*)
[all 2023-02-21 21:50:50]   ../../gcc/gcc/recog.cc:2791
[all 2023-02-21 21:50:50] 0xce5a14 extract_insn_cached(rtx_insn*)
[all 2023-02-21 21:50:50]   ../../gcc/gcc/recog.cc:2680
[all 2023-02-21 21:50:50] 0x9fa4a4 cleanup_subreg_operands(rtx_insn*)
[all 2023-02-21 21:50:50]   ../../gcc/gcc/final.cc:3054
[all 2023-02-21 21:50:50] 0xd10ff2 reload(rtx_insn*, int)
[all 2023-02-21 21:50:50]   ../../gcc/gcc/reload1.cc:1232
[all 2023-02-21 21:50:50] 0xb97f3e do_reload
[all 2023-02-21 21:50:50]   ../../gcc/gcc/ira.cc:5975
[all 2023-02-21 21:50:50] 0xb97f3e execute
[all 2023-02-21 21:50:50]   ../../gcc/gcc/ira.cc:6149
[all 2023-02-21 21:50:50] Please submit a full bug report, with preprocessed
source (by using -freport-bug).
[all 2023-02-21 21:50:50] Please include 

[Bug libstdc++/108846] std::copy, std::copy_n and std::copy_backward on potentially overlapping subobjects

[dangelog at gmail dot com via Gcc-bugs]

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

--- Comment #12 from Giuseppe D'Angelo  ---
(In reply to Jonathan Wakely from comment #9)
> (In reply to Giuseppe D'Angelo from comment #5)
> > https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/include/bits/
> > stl_algobase.h#L417-L437
> > 
> > Is the extent of the fix just to add another branch to the if (_Num) check
> > here?
> 
> Yes, I think that's the simplest place to fix it.
> 
> And we can even get rid of the static assertion, because the Num==1 branch
> will require assignability now.
> 
> --- a/libstdc++-v3/include/bits/stl_algobase.h
> +++ b/libstdc++-v3/include/bits/stl_algobase.h
> @@ -737,16 +737,11 @@ _GLIBCXX_END_NAMESPACE_CONTAINER
> static _Tp*
> __copy_move_b(const _Tp* __first, const _Tp* __last, _Tp* __result)
> {
> -#if __cplusplus >= 201103L
> - using __assignable = __conditional_t<_IsMove,
> -  is_move_assignable<_Tp>,
> -  is_copy_assignable<_Tp>>;
> - // trivial types can have deleted assignment
> - static_assert( __assignable::value, "type must be assignable" );
> -#endif
>   const ptrdiff_t _Num = __last - __first;
> - if (_Num)
> + if (__builtin_expect(_Num > 1, true))
> __builtin_memmove(__result - _Num, __first, sizeof(_Tp) * _Num);
> + else if (_Num == 1)
> +   *__result = *__first;
>   return __result - _Num;
> }
>  };


If this code path also takes care of std::move(b,e,o), then this doesn't sound
correct -- for _Num==1 and _IsMove==true, then it should use a move assignment
(std::move(*__first)). But then that std::move doesn't actually work as __first
is a pointer to const...

[PATCH 2/2] testsuite: Fix gcc.dg/analyzer/allocation-size-multiline-3.c

[Hans-Peter Nilsson via Gcc-patches]

I'll install this as obvious provided that the prerequisite
multiline.exp patch is approved.
-- >8 --
For 32-bit newlib targets (such as cris-elf and pru-elf),
that int32_t is "long int".  See other regexps in the
testsuite matching "aka (long )?int" (with single-quotes
where needed) where the pattern in
allocation-size-multiline-3.c matches plain "int".  Uses the
special syntax recently introduced for multi-line patterns.

testsuite:
* gcc.dg/analyzer/allocation-size-multiline-3.c: Handle
int32_t being "long int".
---
 gcc/testsuite/gcc.dg/analyzer/allocation-size-multiline-3.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/analyzer/allocation-size-multiline-3.c 
b/gcc/testsuite/gcc.dg/analyzer/allocation-size-multiline-3.c
index e27364a8e839..b3de582368fc 100644
--- a/gcc/testsuite/gcc.dg/analyzer/allocation-size-multiline-3.c
+++ b/gcc/testsuite/gcc.dg/analyzer/allocation-size-multiline-3.c
@@ -21,7 +21,7 @@ void test_constant_99 (void)
 |  ^~
 |  |
 |  (1) allocated 99 bytes here
-|  (2) assigned to 'int32_t *' {aka 'int *'} here; 'sizeof 
(int32_t {aka int})' is '4'
+|  (2) assigned to 'int32_t *' {aka '{re:long :re?}int *'} 
here; 'sizeof (int32_t {aka {re:long :re?}int})' is '4'
 |
{ dg-end-multiline-output "" } */
 
@@ -39,6 +39,6 @@ void test_symbolic (int n)
 |  ^~
 |  |
 |  (1) allocated 'n * 2' bytes here
-|  (2) assigned to 'int32_t *' {aka 'int *'} here; 'sizeof 
(int32_t {aka int})' is '4'
+|  (2) assigned to 'int32_t *' {aka '{re:long :re?}int *'} 
here; 'sizeof (int32_t {aka {re:long :re?}int})' is '4'
 |
{ dg-end-multiline-output "" } */
-- 
2.30.2

[PATCH 1/2] testsuite: Provide means to regexp in multiline patterns

[Hans-Peter Nilsson via Gcc-patches]

Ok to commit?
-- >8 --
Those multi-line-patterns are literal.  Sometimes a regexp
needs to be matched.  This is a start: just three elements
are supported: "(" ")" and the compound ")?" (and on second
thought, it can be argued that "(...)" alone is not useful).
Note that Tcl "string map" is documented to have the desired
effect: a once-over but no re-recognitions of previously
replaced mapped elements.  Also, drop a doubled "containing".

testsuite:
* lib/multiline.exp (_build_multiline_regex): Map
"{re:" to "(", ":re}" to ")" and ":re?}" to ")?".
---
 gcc/testsuite/lib/multiline.exp | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/lib/multiline.exp b/gcc/testsuite/lib/multiline.exp
index 5eccf2bbebc1..f746bc3a618e 100644
--- a/gcc/testsuite/lib/multiline.exp
+++ b/gcc/testsuite/lib/multiline.exp
@@ -297,7 +297,7 @@ proc _get_lines { filename first_line last_line } {
 
 # Convert $multiline from a list of strings to a multiline regex
 # We need to support matching arbitrary followup text on each line,
-# to deal with comments containing containing DejaGnu directives.
+# to deal with comments containing DejaGnu directives.
 
 proc _build_multiline_regex { multiline index } {
 verbose "_build_multiline_regex: $multiline $index" 4
@@ -307,7 +307,10 @@ proc _build_multiline_regex { multiline index } {
verbose "  line: $line" 4
 
# We need to escape "^" and other regexp metacharacters.
-   set line [string map {"^" "\\^"
+   set line [string map {"\{re:" "("
+ ":re?\}" ")?"
+ ":re\}" ")"
+ "^" "\\^"
  "(" "\\("
  ")" "\\)"
  "[" "\\["
-- 
2.30.2

Re: [PATCH] testsuite: Don't include multiline regexps in the the pass/fail log

[David Malcolm via Gcc-patches]

On Fri, 2023-02-24 at 18:54 +0100, Hans-Peter Nilsson wrote:
> Ok to commit?

Looks good to me [1]

Thanks
Dave

[1] though FWIW although I wrote this code, my DejaGnu skills are weak
and I'm not a testsuite maintainer :-/

> 
> -- >8 --
> I see overlong lines in the output when a test fails, for
> example for a bug exposed for cris-elf and pru-elf in
> gcc.dg/analyzer/allocation-size-multiline-3.c:
> 
> Running /x/gcc/testsuite/gcc.dg/analyzer/analyzer.exp ...
> FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c expected
> multiline pattern lines 16-25 not found: "\s*int32_t \*ptr = alloca
> \(99\);[^\n\r]*\n  \^~\n  'test_constant_99':
> events 1-2[^\n\r]*\n    \|[^\n\r]*\n    \|   int32_t \*ptr = alloca
> \(99\);[^\n\r]*\n    \|  \^~\n   
> \|  \|[^\n\r]*\n    \|  \(1\)
> allocated 99 bytes here[^\n\r]*\n    \|  \(2\)
> assigned to 'int32_t \*' \{aka 'int \*'\} here; 'sizeof \(int32_t
> \{aka int\}\)' is '4'[^\n\r]*\n    \|[^\n\r]*\n"
> FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c expected
> multiline pattern lines 34-43 not found: "   int32_t \*ptr = alloca
> \(n \* 2\);[^\n\r]*\n  \^~\n  'test_symbolic':
> events 1-2[^\n\r]*\n    \|[^\n\r]*\n    \|   int32_t \*ptr = alloca
> \(n \* 2\);[^\n\r]*\n    \|  \^~\n   
> \|  \|[^\n\r]*\n    \|  \(1\)
> allocated 'n \* 2' bytes here[^\n\r]*\n    \|  \(2\)
> assigned to 'int32_t \*' \{aka 'int \*'\} here; 'sizeof \(int32_t
> \{aka int\}\)' is '4'[^\n\r]*\n    \|[^\n\r]*\n"
> FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c (test for excess
> errors)
> 
> That multiline-regexp-quoted-on-a-single-line is redundant
> when also outputting "lines 16-25" and "lines 34-43".  It's
> also so noisy that it can be mistaken for a testsuite error.
> If there's a need to inspect it, it can be seen at
> verbose-level 4, i.e. persons interested in seeing it
> without editing sources can just add "-v -v -v -v".
> 
> Let's "prune" the regexp from regular output, instead producing:
> Running /x/gcc/testsuite/gcc.dg/analyzer/analyzer.exp ...
> FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c expected
> multiline pattern lines 16-25 not found
> FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c expected
> multiline pattern lines 34-43 not found
> FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c (test for excess
> errors)
> 
> * lib/multiline.exp (handle-multiline-outputs): Don't include
> the
> quoted multiline regexp in the pass/fail output.
> ---
>  gcc/testsuite/lib/multiline.exp | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/gcc/testsuite/lib/multiline.exp
> b/gcc/testsuite/lib/multiline.exp
> index 84ba9216642e..5eccf2bbebc1 100644
> --- a/gcc/testsuite/lib/multiline.exp
> +++ b/gcc/testsuite/lib/multiline.exp
> @@ -169,9 +169,9 @@ proc handle-multiline-outputs { text } {
> # Use "regsub" to attempt to prune the pattern from $text
> if {[regsub -line $rexp $text "" text]} {
>     # The multiline pattern was pruned.
> -   ${maybe_x}pass "$title was found: \"$escaped_regex\""
> +   ${maybe_x}pass "$title was found"
> } else {
> -   ${maybe_x}fail "$title not found: \"$escaped_regex\""
> +   ${maybe_x}fail "$title not found"
> }
>  
> set index [expr $index + 1]

[Bug libstdc++/108030] `std::experimental::simd` not inlined

[mkretz at gcc dot gnu.org via Gcc-bugs]

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

Matthias Kretz (Vir)  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #13 from Matthias Kretz (Vir)  ---
Fixed on trunk. Will backport later if no issues crop up.

Re: [PATCH 6/8] libstdc++: Fix formatting

[Matthias Kretz via Gcc-patches]

On Friday, 24 February 2023 18:14:53 CET Jonathan Wakely wrote:
> Looks like there are a few remaining spaces that could be removed
> where you've joined lines, e.g.

Fixed and pushed.

> OK for trunk anyway (and the branches if you want).

I'll likely backport after I backported all other patches to trunk that came 
before this one.

-- 
──
 Dr. Matthias Kretz   https://mattkretz.github.io
 GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
 stdₓ::simd
──

[Bug libstdc++/108030] `std::experimental::simd` not inlined

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Matthias Kretz :

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

commit r13-6334-ge37b04328ae68f91efe1fb2c5de9122be34bc74a
Author: Matthias Kretz 
Date:   Mon Feb 20 17:49:37 2023 +0100

libstdc++: Always-inline most of non-cmath fixed_size implementation

For simd, the inlining behavior should be similar to builtin types. (No
operator on buitin types is ever translated into a function call.)
Therefore, always_inline is the right choice (i.e. inline on -O0 as
well).

Signed-off-by: Matthias Kretz 

libstdc++-v3/ChangeLog:

PR libstdc++/108030
* include/experimental/bits/simd_fixed_size.h
(_SimdImplFixedSize::_S_broadcast): Replace inline with
_GLIBCXX_SIMD_INTRINSIC.
(_SimdImplFixedSize::_S_generate): Likewise.
(_SimdImplFixedSize::_S_load): Likewise.
(_SimdImplFixedSize::_S_masked_load): Likewise.
(_SimdImplFixedSize::_S_store): Likewise.
(_SimdImplFixedSize::_S_masked_store): Likewise.
(_SimdImplFixedSize::_S_min): Likewise.
(_SimdImplFixedSize::_S_max): Likewise.
(_SimdImplFixedSize::_S_complement): Likewise.
(_SimdImplFixedSize::_S_unary_minus): Likewise.
(_SimdImplFixedSize::_S_plus): Likewise.
(_SimdImplFixedSize::_S_minus): Likewise.
(_SimdImplFixedSize::_S_multiplies): Likewise.
(_SimdImplFixedSize::_S_divides): Likewise.
(_SimdImplFixedSize::_S_modulus): Likewise.
(_SimdImplFixedSize::_S_bit_and): Likewise.
(_SimdImplFixedSize::_S_bit_or): Likewise.
(_SimdImplFixedSize::_S_bit_xor): Likewise.
(_SimdImplFixedSize::_S_bit_shift_left): Likewise.
(_SimdImplFixedSize::_S_bit_shift_right): Likewise.
(_SimdImplFixedSize::_S_remquo): Add inline keyword (to be
explicit about not always-inline, yet).
(_SimdImplFixedSize::_S_isinf): Likewise.
(_SimdImplFixedSize::_S_isfinite): Likewise.
(_SimdImplFixedSize::_S_isnan): Likewise.
(_SimdImplFixedSize::_S_isnormal): Likewise.
(_SimdImplFixedSize::_S_signbit): Likewise.

[Bug libstdc++/108856] Increment and decrement on std::experimental::where_expression should optimize better

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Matthias Kretz :

https://gcc.gnu.org/g:6ce55180d494b616e2e3e68ffedfe9007e42ca06

commit r13-6333-g6ce55180d494b616e2e3e68ffedfe9007e42ca06
Author: Matthias Kretz 
Date:   Mon Feb 20 16:33:31 2023 +0100

libstdc++: More efficient masked inc-/decrement implementation

Signed-off-by: Matthias Kretz 

libstdc++-v3/ChangeLog:

PR libstdc++/108856
* include/experimental/bits/simd_builtin.h
(_SimdImplBuiltin::_S_masked_unary): More efficient
implementation of masked inc-/decrement for integers and floats
without AVX2.
* include/experimental/bits/simd_x86.h
(_SimdImplX86::_S_masked_unary): New. Use AVX512 masked subtract
builtins for masked inc-/decrement.

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[ibuclaw at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #29 from ibuclaw at gcc dot gnu.org ---
(In reply to Iain Sandoe from comment #27)
> great!
> 
> we make more progress now - at least past libphobos configure:
> 
> we now fail building druntime/core/atomic.d and I am not quite sure how to
> interpret the backtrace (from b internal_error).
>
> d21`_D3dmd6access17checkSymbolAccessFPSQBh6dscope5ScopeCQBy7dsymbol7DsymbolZb
> (sc=, s=) at access.d:296
>
My fear is that now it's corrupting the return in other ways now, this time
within D itself.

access.d:296: final switch (s.visible().kind)

[r13-6278 Regression] FAIL: gcc.dg/vect/vect-simd-clone-18f.c scan-tree-dump-times vect "[\\n\\r] [^\\n]* = foo\\.simdclone" 2 on Linux/x86_64

[haochen.jiang via Gcc-patches]

On Linux/x86_64,

3da77f217c8b2089ecba3eb201e727c3fcdcd19d is the first bad commit
commit 3da77f217c8b2089ecba3eb201e727c3fcdcd19d
Author: Andrew Stubbs 
Date:   Thu Jul 28 16:07:22 2022 +0100

vect: inbranch SIMD clones

caused

FAIL: gcc.dg/vect/vect-simd-clone-16.c scan-tree-dump-times vect "[\\n\\r] 
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-16e.c scan-tree-dump-times vect "[\\n\\r] 
[^\\n]* = foo\\.simdclone" 3
FAIL: gcc.dg/vect/vect-simd-clone-16f.c scan-tree-dump-times vect "[\\n\\r] 
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-17.c scan-tree-dump-times vect "[\\n\\r] 
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-17e.c scan-tree-dump-times vect "[\\n\\r] 
[^\\n]* = foo\\.simdclone" 3
FAIL: gcc.dg/vect/vect-simd-clone-17f.c scan-tree-dump-times vect "[\\n\\r] 
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-18.c scan-tree-dump-times vect "[\\n\\r] 
[^\\n]* = foo\\.simdclone" 2
FAIL: gcc.dg/vect/vect-simd-clone-18e.c scan-tree-dump-times vect "[\\n\\r] 
[^\\n]* = foo\\.simdclone" 3
FAIL: gcc.dg/vect/vect-simd-clone-18f.c scan-tree-dump-times vect "[\\n\\r] 
[^\\n]* = foo\\.simdclone" 2

with GCC configured with

../../gcc/configure 
--prefix=/export/users/haochenj/src/gcc-bisect/master/master/r13-6278/usr 
--enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
--with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet --without-isl 
--enable-libmpx x86_64-linux --disable-bootstrap

To reproduce:

$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-16.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-16.c 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-16e.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-16e.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-16f.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-16f.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-16f.c 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-17.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-17.c 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-17e.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-17e.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-17f.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-17f.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-17f.c 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-18.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-18.c 
--target_board='unix{-m64\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-18e.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-18e.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-18f.c 
--target_board='unix{-m32}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-18f.c 
--target_board='unix{-m32\ -march=cascadelake}'"
$ cd {build_dir}/gcc && make check 
RUNTESTFLAGS="vect.exp=gcc.dg/vect/vect-simd-clone-18f.c 
--target_board='unix{-m64\ -march=cascadelake}'"

(Please do not reply to this email, for question about this report, contact me 
at haochen dot jiang at intel.com)

[V4][PATCH 2/2] Update documentation to clarify a GCC extension

[Qing Zhao via Gcc-patches]

on a structure with a C99 flexible array member being nested in
another structure.

"GCC extension accepts a structure containing an ISO C99 "flexible array
member", or a union containing such a structure (possibly recursively)
to be a member of a structure.

 There are two situations:

   * The structure with a C99 flexible array member is the last field of
 another structure, for example:

  struct flex  { int length; char data[]; };
  union union_flex { int others; struct flex f; };

  struct out_flex_struct { int m; struct flex flex_data; };
  struct out_flex_union { int n; union union_flex flex_data; };

 In the above, both 'out_flex_struct.flex_data.data[]' and
 'out_flex_union.flex_data.f.data[]' are considered as flexible
 arrays too.

   * The structure with a C99 flexible array member is the middle field
 of another structure, for example:

  struct flex  { int length; char data[]; };

  struct mid_flex { int m; struct flex flex_data; int n; };

 In the above, 'mid_flex.flex_data.data[]' is allowed to be extended
 flexibly to the padding.  E.g, up to 4 elements.

 However, relying on space in struct padding is a bad programming
 practice, compilers do not handle such extension consistently, Any
 code relying on this behavior should be modified to ensure that
 flexible array members only end up at the ends of structures.

 Please use warning option '-Wgnu-variable-sized-type-not-at-end' to
 identify all such cases in the source code and modify them.  This
 extension will be deprecated from gcc in the next release.
"

gcc/c-family/ChangeLog:

* c.opt: New option -Wgnu-variable-sized-type-not-at-end.

gcc/c/ChangeLog:

* c-decl.cc (finish_struct): Issue warnings for new option.

gcc/ChangeLog:

* doc/extend.texi: Document GCC extension on a structure containing
a flexible array member to be a member of another structure.

gcc/testsuite/ChangeLog:

* gcc.dg/variable-sized-type-flex-array.c: New test.
---
 gcc/c-family/c.opt|  5 ++
 gcc/c/c-decl.cc   |  7 +++
 gcc/doc/extend.texi   | 48 ++-
 .../gcc.dg/variable-sized-type-flex-array.c   | 31 
 4 files changed, 90 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/gcc.dg/variable-sized-type-flex-array.c

diff --git a/gcc/c-family/c.opt b/gcc/c-family/c.opt
index cddeece..660ac07f3d4 100644
--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -737,6 +737,11 @@ Wformat-truncation=
 C ObjC C++ LTO ObjC++ Joined RejectNegative UInteger Var(warn_format_trunc) 
Warning LangEnabledBy(C ObjC C++ LTO ObjC++,Wformat=, warn_format >= 1, 0) 
IntegerRange(0, 2)
 Warn about calls to snprintf and similar functions that truncate output.
 
+Wgnu-variable-sized-type-not-at-end
+C C++ Var(warn_variable_sized_type_not_at_end) Warning
+Warn about structures or unions with C99 flexible array members are not
+at the end of a structure.
+
 Wif-not-aligned
 C ObjC C++ ObjC++ Var(warn_if_not_aligned) Init(1) Warning
 Warn when the field in a struct is not aligned.
diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index f589a2f5192..c5b54f07965 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -9296,6 +9296,13 @@ finish_struct (location_t loc, tree t, tree fieldlist, 
tree attributes,
   && is_last_field)
TYPE_INCLUDE_FLEXARRAY (t) = true;
 
+  if (warn_variable_sized_type_not_at_end
+ && !is_last_field
+ && TYPE_INCLUDE_FLEXARRAY (TREE_TYPE (x)))
+   warning_at (DECL_SOURCE_LOCATION (x),
+   OPT_Wgnu_variable_sized_type_not_at_end,
+   "variable sized type not at the end of a struct");
+
   if (DECL_NAME (x)
  || RECORD_OR_UNION_TYPE_P (TREE_TYPE (x)))
saw_named_field = true;
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index c1122916255..e278148c332 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -1748,7 +1748,53 @@ Flexible array members may only appear as the last 
member of a
 A structure containing a flexible array member, or a union containing
 such a structure (possibly recursively), may not be a member of a
 structure or an element of an array.  (However, these uses are
-permitted by GCC as extensions.)
+permitted by GCC as extensions, see details below.)
+@end itemize
+
+GCC extension accepts a structure containing an ISO C99 @dfn{flexible array
+member}, or a union containing such a structure (possibly recursively)
+to be a member of a structure.
+
+There are two situations:
+
+@itemize @bullet
+@item
+The structure with a C99 flexible array member is the last field of another
+structure, for example:
+
+@smallexample
+struct flex  @{ int length; char data[]; @};
+union union_flex @{ int others; struct flex f; @};
+
+struct out_flex_struct @{ int m; struct flex flex_data; @};
+struct 

[v4][PATCH 1/2] Handle component_ref to a structre/union field including C99 FAM [PR101832]

[Qing Zhao via Gcc-patches]

GCC extension accepts the case when a struct with a C99 flexible array member
is embedded into another struct or union (possibly recursively).
__builtin_object_size should treat such struct as flexible size.

gcc/c/ChangeLog:

PR tree-optimization/101832
* c-decl.cc (finish_struct): Set TYPE_INCLUDE_FLEXARRAY for
struct/union type.

gcc/cp/ChangeLog:

PR tree-optimization/101832
* module.cc (trees_out::core_bools): Stream out new bit
type_include_flexarray.
(trees_in::core_bools): Stream in new bit type_include_flexarray.

gcc/ChangeLog:

PR tree-optimization/101832
* print-tree.cc (print_node): Print new bit type_include_flexarray.
* tree-core.h (struct tree_type_common): New bit
type_include_flexarray.
* tree-object-size.cc (addr_object_size): Handle structure/union type
when it has flexible size.
* tree-streamer-in.cc (unpack_ts_type_common_value_fields): Stream
in new bit type_include_flexarray.
* tree-streamer-out.cc (pack_ts_type_common_value_fields): Stream
out new bit type_include_flexarray.
* tree.h (TYPE_INCLUDE_FLEXARRAY): New macro
TYPE_INCLUDE_FLEXARRAY.

gcc/testsuite/ChangeLog:

PR tree-optimization/101832
* gcc.dg/builtin-object-size-pr101832.c: New test.
---
 gcc/c/c-decl.cc   |  12 ++
 gcc/cp/module.cc  |   2 +
 gcc/print-tree.cc |   5 +
 .../gcc.dg/builtin-object-size-pr101832.c | 134 ++
 gcc/tree-core.h   |   4 +-
 gcc/tree-object-size.cc   |  79 +++
 gcc/tree-streamer-in.cc   |   1 +
 gcc/tree-streamer-out.cc  |   1 +
 gcc/tree.h|   6 +
 9 files changed, 215 insertions(+), 29 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/builtin-object-size-pr101832.c

diff --git a/gcc/c/c-decl.cc b/gcc/c/c-decl.cc
index 08078eadeb8..f589a2f5192 100644
--- a/gcc/c/c-decl.cc
+++ b/gcc/c/c-decl.cc
@@ -9284,6 +9284,18 @@ finish_struct (location_t loc, tree t, tree fieldlist, 
tree attributes,
   /* Set DECL_NOT_FLEXARRAY flag for FIELD_DECL x.  */
   DECL_NOT_FLEXARRAY (x) = !is_flexible_array_member_p (is_last_field, x);
 
+  /* Set TYPE_INCLUDE_FLEXARRAY for the context of x, t
+   * when x is an array.  */
+  if (TREE_CODE (TREE_TYPE (x)) == ARRAY_TYPE)
+   TYPE_INCLUDE_FLEXARRAY (t) = flexible_array_member_type_p (TREE_TYPE 
(x)) ;
+  /* Recursively set TYPE_INCLUDE_FLEXARRAY for the context of x, t
+when x is the last field.  */
+  else if ((TREE_CODE (TREE_TYPE (x)) == RECORD_TYPE
+   || TREE_CODE (TREE_TYPE (x)) == UNION_TYPE)
+  && TYPE_INCLUDE_FLEXARRAY (TREE_TYPE (x))
+  && is_last_field)
+   TYPE_INCLUDE_FLEXARRAY (t) = true;
+
   if (DECL_NAME (x)
  || RECORD_OR_UNION_TYPE_P (TREE_TYPE (x)))
saw_named_field = true;
diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index ac2fe66b080..c750361b704 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -5371,6 +5371,7 @@ trees_out::core_bools (tree t)
   WB (t->type_common.lang_flag_5);
   WB (t->type_common.lang_flag_6);
   WB (t->type_common.typeless_storage);
+  WB (t->type_common.type_include_flexarray);
 }
 
   if (CODE_CONTAINS_STRUCT (code, TS_DECL_COMMON))
@@ -5551,6 +5552,7 @@ trees_in::core_bools (tree t)
   RB (t->type_common.lang_flag_5);
   RB (t->type_common.lang_flag_6);
   RB (t->type_common.typeless_storage);
+  RB (t->type_common.type_include_flexarray);
 }
 
   if (CODE_CONTAINS_STRUCT (code, TS_DECL_COMMON))
diff --git a/gcc/print-tree.cc b/gcc/print-tree.cc
index 1f3afcbbc86..efacdb7686f 100644
--- a/gcc/print-tree.cc
+++ b/gcc/print-tree.cc
@@ -631,6 +631,11 @@ print_node (FILE *file, const char *prefix, tree node, int 
indent,
  && TYPE_CXX_ODR_P (node))
fputs (" cxx-odr-p", file);
 
+  if ((code == RECORD_TYPE
+  || code == UNION_TYPE)
+ && TYPE_INCLUDE_FLEXARRAY (node))
+   fputs (" include-flexarray", file);
+
   /* The transparent-union flag is used for different things in
 different nodes.  */
   if ((code == UNION_TYPE || code == RECORD_TYPE)
diff --git a/gcc/testsuite/gcc.dg/builtin-object-size-pr101832.c 
b/gcc/testsuite/gcc.dg/builtin-object-size-pr101832.c
new file mode 100644
index 000..60078e11634
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/builtin-object-size-pr101832.c
@@ -0,0 +1,134 @@
+/* PR 101832: 
+   GCC extension accepts the case when a struct with a C99 flexible array
+   member is embedded into another struct (possibly recursively).
+   __builtin_object_size will treat such struct as flexible size.
+   However, when a structure with non-C99 flexible array member, i.e, trailing
+   [0], [1], or [4], 

[V4][PATCH 0/2] Handle component_ref to a structure/union field including FAM for builtin_object_size

[Qing Zhao via Gcc-patches]

Hi, Joseph and Richard,

Could you please review this patch and let me know whether it???s ready
 for committing into GCC13?

The fix to Bug PR101832 is an important patch for kernel security
purpose. it's better to be put into GCC13.

=

These are the 4th version of the patches for PR101832, to fix
builtin_object_size to correctly handle component_ref to a
structure/union field that includes a flexible array member.

also includes a documentation update for the GCC extension on embedding
a structure/union with flexible array member into another structure.
which includes a fix to PR77650.

compared to the 3rd version of the patch, the major changes are:

1. update the documentation part per Joseph's comments.

compared to the 2nd version of the patch, the major changes are:

1. only include C99 flexible array member to this extension, trailing [0], [1]
  and [4] are all excluded.
2. for the new bit type_include_flexarray in tree_type_common, print it
  and also stream in/out it. 
3. update testing cases.
4. more clarification on the documentation. warnings for deprecating the 
  case when the structure with C99 FAM is embedded in the middle of
  another structure. 
5. add a new warning option -Wgnu-variable-sized-type-not-at-end for
  identifing all such cases.

bootstrapped and regression tested on aarch64 and x86.

Okay for commit?

thanks.

Qing

Qing Zhao (2):
  Handle component_ref to a structre/union field including C99 FAM
[PR101832]
  Update documentation to clarify a GCC extension

 gcc/c-family/c.opt|   5 +
 gcc/c/c-decl.cc   |  19 +++
 gcc/cp/module.cc  |   2 +
 gcc/doc/extend.texi   |  48 ++-
 gcc/print-tree.cc |   5 +
 .../gcc.dg/builtin-object-size-pr101832.c | 134 ++
 .../gcc.dg/variable-sized-type-flex-array.c   |  31 
 gcc/tree-core.h   |   4 +-
 gcc/tree-object-size.cc   |  79 +++
 gcc/tree-streamer-in.cc   |   1 +
 gcc/tree-streamer-out.cc  |   1 +
 gcc/tree.h|   6 +
 12 files changed, 305 insertions(+), 30 deletions(-)
 create mode 100644 gcc/testsuite/gcc.dg/builtin-object-size-pr101832.c
 create mode 100644 gcc/testsuite/gcc.dg/variable-sized-type-flex-array.c

-- 
2.31.1

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #28 from Iain Sandoe  ---
(In reply to Iain Sandoe from comment #27)
> great!
> 
> we make more progress now - at least past libphobos configure:
> 
> we now fail building druntime/core/atomic.d and I am not quite sure how to
> interpret the backtrace (from b internal_error).


> 

frame #9: 0x2a18
d21`_D4core9exception__T15__switch_errorTZQsFNaNbNiNeAyakZv(file=,
line=) at exception.d:17
   14   {
   15   // Consider making this a compile time check.
   16   version (D_Exceptions)
-> 17   throw staticError!SwitchError("No appropriate switch clause
found", file, line, null);
   18   else
   19   assert(0, "No appropriate switch clause found");

[PATCH] testsuite: Don't include multiline regexps in the the pass/fail log

[Hans-Peter Nilsson via Gcc-patches]

Ok to commit?

-- >8 --
I see overlong lines in the output when a test fails, for
example for a bug exposed for cris-elf and pru-elf in
gcc.dg/analyzer/allocation-size-multiline-3.c:

Running /x/gcc/testsuite/gcc.dg/analyzer/analyzer.exp ...
FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c expected multiline pattern 
lines 16-25 not found: "\s*int32_t \*ptr = alloca \(99\);[^\n\r]*\n 
 \^~\n  'test_constant_99': events 1-2[^\n\r]*\n\|[^\n\r]*\n\|  
 int32_t \*ptr = alloca \(99\);[^\n\r]*\n\|  \^~\n
\|  \|[^\n\r]*\n\|  \(1\) allocated 99 
bytes here[^\n\r]*\n\|  \(2\) assigned to 'int32_t \*' 
\{aka 'int \*'\} here; 'sizeof \(int32_t \{aka int\}\)' is '4'[^\n\r]*\n
\|[^\n\r]*\n"
FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c expected multiline pattern 
lines 34-43 not found: "   int32_t \*ptr = alloca \(n \* 2\);[^\n\r]*\n 
 \^~\n  'test_symbolic': events 1-2[^\n\r]*\n\|[^\n\r]*\n\| 
  int32_t \*ptr = alloca \(n \* 2\);[^\n\r]*\n\|  \^~\n 
   \|  \|[^\n\r]*\n\|  \(1\) allocated 'n 
\* 2' bytes here[^\n\r]*\n\|  \(2\) assigned to 'int32_t 
\*' \{aka 'int \*'\} here; 'sizeof \(int32_t \{aka int\}\)' is '4'[^\n\r]*\n
\|[^\n\r]*\n"
FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c (test for excess errors)

That multiline-regexp-quoted-on-a-single-line is redundant
when also outputting "lines 16-25" and "lines 34-43".  It's
also so noisy that it can be mistaken for a testsuite error.
If there's a need to inspect it, it can be seen at
verbose-level 4, i.e. persons interested in seeing it
without editing sources can just add "-v -v -v -v".

Let's "prune" the regexp from regular output, instead producing:
Running /x/gcc/testsuite/gcc.dg/analyzer/analyzer.exp ...
FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c expected multiline pattern 
lines 16-25 not found
FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c expected multiline pattern 
lines 34-43 not found
FAIL: gcc.dg/analyzer/allocation-size-multiline-3.c (test for excess errors)

* lib/multiline.exp (handle-multiline-outputs): Don't include the
quoted multiline regexp in the pass/fail output.
---
 gcc/testsuite/lib/multiline.exp | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/lib/multiline.exp b/gcc/testsuite/lib/multiline.exp
index 84ba9216642e..5eccf2bbebc1 100644
--- a/gcc/testsuite/lib/multiline.exp
+++ b/gcc/testsuite/lib/multiline.exp
@@ -169,9 +169,9 @@ proc handle-multiline-outputs { text } {
# Use "regsub" to attempt to prune the pattern from $text
if {[regsub -line $rexp $text "" text]} {
# The multiline pattern was pruned.
-   ${maybe_x}pass "$title was found: \"$escaped_regex\""
+   ${maybe_x}pass "$title was found"
} else {
-   ${maybe_x}fail "$title not found: \"$escaped_regex\""
+   ${maybe_x}fail "$title not found"
}
 
set index [expr $index + 1]
-- 
2.30.2

[Bug d/106977] [13 regression] d21 dies with SIGBUS on 32-bit Darwin

[iains at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #27 from Iain Sandoe  ---
great!

we make more progress now - at least past libphobos configure:

we now fail building druntime/core/atomic.d and I am not quite sure how to
interpret the backtrace (from b internal_error).


(lldb) bt
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=EXC_I386_GPFLT)
  * frame #0: 0xa7273850 libdyld.dylib`misaligned_stack_error_
frame #1: 0xa9847000 libsystem_malloc.dylib
frame #2: 0x01a2e40b d21`backtrace_simple + 75
frame #3: 0x01bfcca4
d21`_D3gcc9backtrace12LibBacktrace6__ctorMFNiiZCQBqQBpQBi(this=0x052c3800,
firstFrame=4) at backtrace.d:207
frame #4: 0x01c3370a
d21`_D4core8lifetime__T7emplaceTC3gcc9backtrace12LibBacktraceTiZQBpFNiQBmKiZQBs(chunk=0x052c3800,
_param_1=0xbfffefa4) at lifetime.d:126
frame #5: 0x01c3373a
d21`_D4core7runtime19defaultTraceHandlerFPvZ__T8allocateTC3gcc9backtrace12LibBacktraceTiZQBqFNiiZQBo(_param_0=)
at runtime.d:752
frame #6: 0x01c3374a
d21`_D4core7runtime19defaultTraceHandlerFPvZC6object9Throwable9TraceInfo(ptr=0x)
at runtime.d:762
frame #7: 0x01c1f560 d21`_d_createTrace(t=0x04615108, context=0x)
at deh.d:51
frame #8: 0x01c013cb d21`_d_throw(object=0x04615108) at deh.d:484
frame #9: 0x2a18
d21`_D4core9exception__T15__switch_errorTZQsFNaNbNiNeAyakZv(file=,
line=) at exception.d:17
frame #10: 0x29d5
d21`_D4core9exception__T15__switch_errorTZQsFNaNbNiNeAyakZv(file=(length = 40,
ptr = "/src-local/gcc-master/gcc/d/dmd/access.d"), line=296) at exception.d:13
frame #11: 0x2c8b
d21`_D3dmd6access17checkSymbolAccessFPSQBh6dscope5ScopeCQBy7dsymbol7DsymbolZb(sc=,
s=) at access.d:296

[Bug fortran/108921] ICE: using the result of an impure function in automatic character allocation

[kargl at gcc dot gnu.org via Gcc-bugs]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
   Keywords||ice-on-invalid-code
 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
The ever popular NULL pointer dereference from
parsing invalid code.
With this patch

diff --git a/gcc/fortran/class.cc b/gcc/fortran/class.cc
index ae653e74437..9ece4482f76 100644
--- a/gcc/fortran/class.cc
+++ b/gcc/fortran/class.cc
@@ -2491,7 +2491,7 @@ gfc_find_derived_vtab (gfc_symbol *derived)
  /* This is elemental so that arrays are automatically
 treated correctly by the scalarizer.  */
  copy->attr.elemental = 1;
- if (ns->proc_name->attr.flavor == FL_MODULE)
+ if (ns->proc_name && ns->proc_name->attr.flavor == FL_MODULE)
copy->module = ns->proc_name->name;
  gfc_set_sym_referenced (copy);
  /* Set up formal arguments.  */
diff --git a/gcc/fortran/symbol.cc b/gcc/fortran/symbol.cc
index 2ce0f3e4df7..54c9441d7fd 100644
--- a/gcc/fortran/symbol.cc
+++ b/gcc/fortran/symbol.cc
@@ -2499,7 +2499,7 @@ gfc_find_component (gfc_symbol *sym, const char *name,
   if (sym->attr.flavor == FL_DERIVED)
 sym = gfc_use_derived (sym);
   else
-gcc_assert (gfc_fl_struct (sym->attr.flavor));
+return NULL;

   if (sym == NULL)
 return NULL;

I get 
% gfcx -c a.f90
a.f90:13:34:

   13 | character(len=this%f())::r  ! problem appears here
  |  1
Error: Symbol 'r' at (1) already has basic type of REAL
a.f90:13:22:

   13 | character(len=this%f())::r  ! problem appears here
  |  1
Error: Function 'this' at (1) must be PURE
a.f90:14:10:

   14 | r='42'
  |  1
Error: Cannot convert CHARACTER(2) to REAL(4) at (1)
a.f90:19:9:

   19 | use lib
  | 1
Fatal Error: Cannot open module file 'lib.mod' for reading at (1): No such file
or directory
compilation terminated.

The first and last errors appear to be run on errors.  The second error appears
to be the relevant one, but the 'name' of the function is munged.

Anywhoo, the patch fixes the ICE

Re: [PATCH 6/8] libstdc++: Fix formatting

[Jonathan Wakely via Gcc-patches]

On Thu, 23 Feb 2023 at 08:54, Matthias Kretz via Libstdc++
 wrote:
>
>
>
> Whitespace changes only.

Looks like there are a few remaining spaces that could be removed
where you've joined lines, e.g.

+{ return static_cast<_Up*>( __builtin_assume_aligned(__ptr,
_S_alignment<_Tp, _Up>)); }

and

+  { return __vector_type_t<_Tp, _Np>{
static_cast<_Tp>(__gen(_SizeConstant<_I>()))...}; }

OK for trunk anyway (and the branches if you want).


>
> Signed-off-by: Matthias Kretz 
>
> libstdc++-v3/ChangeLog:
>
> * include/experimental/bits/simd.h: Line breaks and indenting
> fixed to follow the libstdc++ standard.
> * include/experimental/bits/simd_builtin.h: Likewise.
> * include/experimental/bits/simd_fixed_size.h: Likewise.
> * include/experimental/bits/simd_neon.h: Likewise.
> * include/experimental/bits/simd_ppc.h: Likewise.
> * include/experimental/bits/simd_scalar.h: Likewise.
> * include/experimental/bits/simd_x86.h: Likewise.
> ---
>  libstdc++-v3/include/experimental/bits/simd.h | 473 ++--
>  .../include/experimental/bits/simd_builtin.h  | 692 +-
>  .../experimental/bits/simd_fixed_size.h   | 228 +++---
>  .../include/experimental/bits/simd_neon.h |  24 +-
>  .../include/experimental/bits/simd_ppc.h  |   3 +-
>  .../include/experimental/bits/simd_scalar.h   | 362 +
>  .../include/experimental/bits/simd_x86.h  |  90 ++-
>  7 files changed, 942 insertions(+), 930 deletions(-)
>
>
> --
> ──
>  Dr. Matthias Kretz   https://mattkretz.github.io
>  GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
>  stdₓ::simd
> ──

Re: [PATCH 5/8] libstdc++: Always-inline most of non-cmath fixed_size implementation

[Jonathan Wakely via Gcc-patches]

On Thu, 23 Feb 2023 at 08:54, Matthias Kretz via Libstdc++
 wrote:
>
>
>
> For simd, the inlining behavior should be similar to builtin types. (No
> operator on buitin types is ever translated into a function call.)
> Therefore, always_inline is the right choice (i.e. inline on -O0 as
> well).

OK for trunk (and OK for backport later if no problems show up from
the extra inlining).


>
> Signed-off-by: Matthias Kretz 
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/108030
> * include/experimental/bits/simd_fixed_size.h
> (_SimdImplFixedSize::_S_broadcast): Replace inline with
> _GLIBCXX_SIMD_INTRINSIC.
> (_SimdImplFixedSize::_S_generate): Likewise.
> (_SimdImplFixedSize::_S_load): Likewise.
> (_SimdImplFixedSize::_S_masked_load): Likewise.
> (_SimdImplFixedSize::_S_store): Likewise.
> (_SimdImplFixedSize::_S_masked_store): Likewise.
> (_SimdImplFixedSize::_S_min): Likewise.
> (_SimdImplFixedSize::_S_max): Likewise.
> (_SimdImplFixedSize::_S_complement): Likewise.
> (_SimdImplFixedSize::_S_unary_minus): Likewise.
> (_SimdImplFixedSize::_S_plus): Likewise.
> (_SimdImplFixedSize::_S_minus): Likewise.
> (_SimdImplFixedSize::_S_multiplies): Likewise.
> (_SimdImplFixedSize::_S_divides): Likewise.
> (_SimdImplFixedSize::_S_modulus): Likewise.
> (_SimdImplFixedSize::_S_bit_and): Likewise.
> (_SimdImplFixedSize::_S_bit_or): Likewise.
> (_SimdImplFixedSize::_S_bit_xor): Likewise.
> (_SimdImplFixedSize::_S_bit_shift_left): Likewise.
> (_SimdImplFixedSize::_S_bit_shift_right): Likewise.
> (_SimdImplFixedSize::_S_remquo): Add inline keyword (to be
> explicit about not always-inline, yet).
> (_SimdImplFixedSize::_S_isinf): Likewise.
> (_SimdImplFixedSize::_S_isfinite): Likewise.
> (_SimdImplFixedSize::_S_isnan): Likewise.
> (_SimdImplFixedSize::_S_isnormal): Likewise.
> (_SimdImplFixedSize::_S_signbit): Likewise.
> ---
>  .../experimental/bits/simd_fixed_size.h   | 60 +--
>  1 file changed, 30 insertions(+), 30 deletions(-)
>
>
> --
> ──
>  Dr. Matthias Kretz   https://mattkretz.github.io
>  GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
>  stdₓ::simd
> ──

Re: [PATCH 3/8] libstdc++: More efficient masked inc-/decrement implementation

[Jonathan Wakely via Gcc-patches]

On Thu, 23 Feb 2023 at 08:55, Matthias Kretz via Libstdc++
 wrote:
>


OK for trunk (and maybe backport later if you want to).


>
> Signed-off-by: Matthias Kretz 
>
> libstdc++-v3/ChangeLog:
>
> PR libstdc++/108856
> * include/experimental/bits/simd_builtin.h
> (_SimdImplBuiltin::_S_masked_unary): More efficient
> implementation of masked inc-/decrement for integers and floats
> without AVX2.
> * include/experimental/bits/simd_x86.h
> (_SimdImplX86::_S_masked_unary): New. Use AVX512 masked subtract
> builtins for masked inc-/decrement.
> ---
>  .../include/experimental/bits/simd_builtin.h  | 27 +++-
>  .../include/experimental/bits/simd_x86.h  | 68 +++
>  2 files changed, 93 insertions(+), 2 deletions(-)
>
>
> --
> ──
>  Dr. Matthias Kretz   https://mattkretz.github.io
>  GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
>  stdₓ::simd
> ──

[Bug target/108927] error: too few arguments to function 'long unsigned int __riscv_vsetvlmax_e8mf8(void)'

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
You are using a month old sources, can you try with a much newer trunk sources?

[Bug fortran/108923] memory leak of get_intrinsic_dummy_arg result

[mikael at gcc dot gnu.org via Gcc-bugs]

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

Mikael Morin  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |mikael at gcc dot 
gnu.org
   Last reconfirmed||2023-02-24
 CC||mikael at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Mikael Morin  ---
I'm the culprit I guess.
Should be easy to fix anyway.
Taking.

Re: Missed warning (-Wuse-after-free)

[Martin Uecker via Gcc]

Am Freitag, dem 24.02.2023 um 10:01 -0600 schrieb Serge E. Hallyn:
> On Fri, Feb 24, 2023 at 09:36:45AM +0100, Martin Uecker wrote:
> > Am Donnerstag, dem 23.02.2023 um 19:21 -0600 schrieb Serge E. Hallyn:

...
> > 
> > Yes, but one comment about terminology:. The C standard
> > differentiates between the representation, i.e. the bytes on
> > the stack, and the value.  The representation is converted to
> > a value during lvalue conversion.  For an invalid pointer
> > the representation is indeterminate because it now does not
> > point to a valid object anymore.  So it is not possible to
> > convert the representation to a value during lvalue conversion.
> > In other words, it does not make sense to speak of the value
> > of the pointer anymore.
> 
> I'm sure there are, especially from an implementer's point of view,
> great reasons for this.
> 
> However, as just a user, the "value" of 'void *p' should absolutely
> not be tied to whatever is at that address.

Think about it in this way: The set of possible values for a pointer
is the set of objects that exist at a point in time. If one object
disappears, a pointer can not point to it anymore. So it is not that
the pointer changes, but the set of valid values.

>   I'm given a simple
> linear memory space, under which sits an entirely different view
> obfuscated by page tables, but that doesn't concern me.  if I say
> void *p = -1, then if I print p, then I expect to see that value.

If you store an integer into a pointer (you need a cast), then
this is implementation-defined and may also produce an invalid
pointer.

> 
> Since I'm complaining about standards I'm picking and choosing here,
> but I'll still point at the printf(3) manpage :)  :
> 
>    p  The  void * pointer argument is printed in hexadecimal (as if 
> by %#x
>   or %#lx).

This is valid if the pointer is valid, but if the pointer
is invalid, this is undefined behavior.

In C one not think about pointers as addresses. They
are abstract handles that point to objects, and compilers
do exploit this for optimization.

If you need an address, you can cast it to uintptr_t
(but see below).

> 
> > > I realize C11 appears to have changed that.  I fear that in doing so it
> > > actually risks increasing the confusion about pointers.  IMO it's much
> > > easier to reason about
> > > 
> > >   o = realloc(p, X);
> > > 
> > > (and more baroque constructions) when keeping in mind that o, p, and the
> > > object pointed to by either one are all different things.
> > > 
> > 
> > What did change in C11? As far as I know, the pointer model
> > did not change in C11.
> 
> I haven't looked in more detail, and don't really plan to, but my
> understanding is that the text of:
> 
>   The lifetime of an object is the portion of program execution during which 
> storage is
>   guaranteed to be reserved for it. An object exists, has a constant address, 
> and retains
>   its last-stored value throughout its lifetime. If an object is referred to 
> outside of its
>   lifetime, the behavior is undefined. The value of a pointer becomes 
> indeterminate when
>   the object it points to (or just past) reaches the end of its lifetime.
> 
> (especially the last sentence) was new.

This is not new.

C99 "The value of a pointer becomes indeterminate when
the object it points to reaches the end of its lifetime."

C90: "The value of a pointer that referred to an object
with automatic storage duration that is no longer
guaranteed to be reserved is indeterminate."

and

"The value of a pointer that refers to freed space is
indeterminate."

> Maybe the words "value of a pointer" don't mean what I think they
> mean.  But that's the phrase to which I object.  The n bytes on
> the stack, p, are not changed just because something happened with
> the accounting for the memory at the address represented by that
> value.  If they do, then that's not 'C' any more.

It is not about the bytes of the pointer changing. But if
the object is freed they do not represent a valid pointer
anymore.  There were CPUs that trapped when an invalid
address is loaded, e.g. because the data segment for the
object was removed from the segment tables. So this is a 
rule in portable 'C'  for more than 30 years.

Nowadays compilers exploit the knowledge that the
object is freed. So you can not reliably use such
a pointer. If you do this, your code will be broken on
most modern compilers.


> 
> > > > > Reading an uninitialized value of automatic storage whose
> > > > > address was not taken is undefined behavior, so everything
> > > > > is possible afterwards.
> > > > > 
> > > > > An uninitialized variable whose address was taken has a
> > > > > representation which can represent an unspecified value
> > > > > or a no-value (trap) representation. Reading the
> > > > > representation itself is always ok and gives consistent
> > > > > results. Reading the variable can be undefined behavior
> > > > > iff it is a trap representation, 

[PATCH] testsuite: Add -fno-ivopts to gcc.dg/Wuse-after-free-2.c, PR108828

[Hans-Peter Nilsson via Gcc-patches]

Ok to commit?

I suggest that when committed I'll also set the bugzilla
entry in SUSPENDED mode, as opposed to RESOLVED.  I mean,
the issue isn't really solved; that'd be a patch improving
pointer tracking across ivopts.

-- >8 --
For cris-elf before this patch, ever since it was added,
this test gets:

Running /x/gcc/testsuite/gcc.dg/dg.exp ...
FAIL: gcc.dg/Wuse-after-free-2.c  (test for warnings, line 115)
FAIL: gcc.dg/Wuse-after-free-2.c  (test for warnings, line 116)

and comparing tree dumps with a native x86_64-pc-linux-gnu
run shows a suspicious difference in the "180t.ivopts" dump.
Indeed -fno-ivopts makes the warning appear for cris-elf
too.  It was suggested to simply add -fno-ivopts to the
test-flags, like before -fno-tree-loop-distribute-patterns
was added; thus.

PR tree-optimization/108828
* gcc.dg/Wuse-after-free-2.c: Add -fno-ivopts.
---
 gcc/testsuite/gcc.dg/Wuse-after-free-2.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gcc.dg/Wuse-after-free-2.c 
b/gcc/testsuite/gcc.dg/Wuse-after-free-2.c
index 68ec75845cec..ebc051690db5 100644
--- a/gcc/testsuite/gcc.dg/Wuse-after-free-2.c
+++ b/gcc/testsuite/gcc.dg/Wuse-after-free-2.c
@@ -1,6 +1,6 @@
 /* PR middle-end/104232 - spurious -Wuse-after-free after conditional free
{ dg-do compile }
-   { dg-options "-O2 -Wall -fno-tree-loop-distribute-patterns" }  */
+   { dg-options "-O2 -Wall -fno-tree-loop-distribute-patterns -fno-ivopts" }  
*/
 
 void free (void*);
 
@@ -108,7 +108,8 @@ int warn_cond_loop (char *p)
   char *q = p;
 
   /*  -fno-tree-loop-distribute-patterns ensures this does not get converted
-  into rawmemchr (making q and p unrelated).  */
+  into rawmemchr (making q and p unrelated).  Also, -fno-ivopts is required
+  for some targets, to not lose track of the pointer.  */
   while (*q)
 ++q;
 
-- 
2.30.2

[Bug fortran/108924] memory leak in doloop_warn

[anlauf at gcc dot gnu.org via Gcc-bugs]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
Created attachment 54532
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54532=edit
Tentative patch

Does the attached fix this?  Without a testcase this seems to be the fix
obtained from reviewing the surrounding code.  Regtests cleanly here.

[Bug c++/108927] New: error: too few arguments to function 'long unsigned int __riscv_vsetvlmax_e8mf8(void)'

[malat at debian dot org via Gcc-bugs]

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

Bug ID: 108927
   Summary: error: too few arguments to function 'long unsigned
int __riscv_vsetvlmax_e8mf8(void)'
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: malat at debian dot org
  Target Milestone: ---

For some reason riscv64 rvv extension is broken. It is supposed to work with
the new naming convention:

* https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg298381.html

  % head ./gcc/testsuite/gcc.target/riscv/rvv/base/vsetvl-1.c
  /* { dg-do compile } */
  /* { dg-options "-march=rv32gcv -mabi=ilp32d -O3" } */

However consider now

```
% cat t.c
#include 

int main()
{
   size_t vl = __riscv_vsetvlmax_e8mf8();
   return vl;
}
```

gives:

```
g++  -march=rv64gcv1p0   t.c
t.c: In function 'int main()':
t.c:5:39: error: too few arguments to function 'long unsigned int
__riscv_vsetvlmax_e8mf8(void)'
5 |size_t vl = __riscv_vsetvlmax_e8mf8();
  |~~~^~
In file included from t.c:1:
/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/include/riscv_vector.h:94:25:
note: declared here
   94 | #pragma riscv intrinsic "vector"
  | ^~~~
```

Full log:


 % LIBRARY_PATH=/usr/lib/gcc-snapshot/lib /usr/lib/gcc-snapshot/bin/g++ 
-march=rv64gcv1p0 -v   t.c
Using built-in specs.
COLLECT_GCC=/usr/lib/gcc-snapshot/bin/g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc-snapshot/libexec/gcc/riscv64-linux-gnu/13/lto-wrapper
Target: riscv64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 20230108-1'
--with-bugurl=file:///usr/share/doc/gcc-snapshot/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2,rust
--prefix=/usr/lib/gcc-snapshot --with-gcc-major-version-only --program-prefix=
--enable-shared --enable-linker-build-id --disable-nls --enable-bootstrap
--enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object --disable-libitm
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--disable-werror --disable-multilib --with-arch=rv64gc --with-abi=lp64d
--enable-checking=yes --build=riscv64-linux-gnu --host=riscv64-linux-gnu
--target=riscv64-linux-gnu --with-build-config=bootstrap-lto-lean
--enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20230108 (experimental) [master r13-5059-gd901bf8a44a]
(Debian 20230108-1)
COLLECT_GCC_OPTIONS='-march=rv64gcv1p0' '-v' '-shared-libgcc' '-mabi=lp64d'
'-misa-spec=20191213'
'-march=rv64imafdc_v1p0_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b'
'-dumpdir' 'a-'
 /usr/lib/gcc-snapshot/libexec/gcc/riscv64-linux-gnu/13/cc1plus -quiet -v
-imultilib . -imultiarch riscv64-linux-gnu -D_GNU_SOURCE t.c -quiet -dumpdir a-
-dumpbase t.c -dumpbase-ext .c -march=rv64gcv1p0 -mabi=lp64d
-misa-spec=20191213
-march=rv64imafdc_v1p0_zicsr_zifencei_zve32f_zve32x_zve64d_zve64f_zve64x_zvl128b_zvl32b_zvl64b
-version -o /tmp/ccVVv6RI.s
GNU C++17 (Debian 20230108-1) version 13.0.0 20230108 (experimental) [master
r13-5059-gd901bf8a44a] (riscv64-linux-gnu)
compiled by GNU C version 13.0.0 20230108 (experimental) [master
r13-5059-gd901bf8a44a], GMP version 6.2.1, MPFR version 4.1.1-p1, MPC version
1.3.1, isl version isl-0.25-GMP

warning: MPFR header version 4.1.1-p1 differs from library version 4.2.0.
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/usr/local/include/riscv64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/include-fixed/riscv64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/../../../../riscv64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/../../../../include/c++/13

/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/../../../../include/c++/13/riscv64-linux-gnu/.

/usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/../../../../include/c++/13/backward
 /usr/lib/gcc-snapshot/lib/gcc/riscv64-linux-gnu/13/include
 /usr/local/include
 /usr/lib/gcc-snapshot/include
 /usr/include/riscv64-linux-gnu
 /usr/include
End of search list.
GNU C++17 (Debian 20230108-1) version 13.0.0 20230108 (experimental) [master
r13-5059-gd901bf8a44a] (riscv64-linux-gnu)
compiled by GNU C version 13.0.0 20230108 (experimental) [master
r13-5059-gd901bf8a44a], GMP version 6.2.1, MPFR version 4.1.1-p1, 

Re: Missed warning (-Wuse-after-free)

[Serge E. Hallyn]

On Fri, Feb 24, 2023 at 02:42:32AM +0100, Alex Colomar wrote:
> Hi Serge, Martin,
> 
> On 2/24/23 02:21, Serge E. Hallyn wrote:
> > > Does all this imply that the following is well defined behavior (and shall
> > > print what one would expect)?
> > > 
> > >free(p);
> > > 
> > >(void)   // take the address
> > >// or maybe we should (void) memcmp(, , sizeof(p)); ?
> > > 
> > >printf("%p\n", p);  // we took previously its address,
> > >// so now it has to hold consistently
> > >// the previous value
> > > 
> > > 
> > > This feels weird.  And a bit of a Schroedinger's pointer.  I'm not 
> > > entirely
> > > convinced, but might be.
> > 
> > Again, p is just an n byte variable which happens to have (one hopes)
> > pointed at a previously malloc'd address.
> > 
> > And I'd argue that pre-C11, this was not confusing, and would not have
> > felt weird to you.
> > 
> > But I am most grateful to you for having brought this to my attention.
> > I may not agree with it and not like it, but it's right there in the
> > spec, so time for me to adjust :)
> 
> I'll try to show why this feels weird to me (even in C89):
> 
> 
> alx@dell7760:~/tmp$ cat pointers.c
> #include 
> #include 
> 
> 
> int
> main(void)
> {
>   char  *p, *q;
> 
>   p = malloc(42);
>   if (p == NULL)
>   exit(1);
> 
>   q = realloc(p, 42);
>   if (q == NULL)
>   exit(1);
> 
>   (void)   // If we remove this, we get -Wuse-after-free

(which I would argue is a bug in the compiler)

>   printf("(%p == %p) = %i\n", p, q, (p == q));
> }
> alx@dell7760:~/tmp$ cc -Wall -Wextra pointers.c  -Wuse-after-free=3
> alx@dell7760:~/tmp$ ./a.out
> (0x5642cd9022a0 == 0x5642cd9022a0) = 1
> 
> 
> This pointers point to different objects (actually, one of them doesn't even
> point to an object anymore), so they can't compare equal, according to both:
> 
> 
> 
> 
> 
> (I believe C89 already had the concept of lifetime well defined as it is
> now, so the object had finished it's lifetime after realloc(3)).
> 
> How can we justify that true, if the pointer don't point to the same object?

Because what's pointed to does not matter.

You are comparing the memory address p, not the contents of the memory address.

By way of analogy, if I do

   mkdir -p /tmp/1/a
   ln -s /tmp/1 /tmp/2
   rm -rf /tmp/1

then /tmp/2 is still a symlink.  'stat /tmp/2' still works and is well
defined.  And if I create a new /tmp/1, then /tmp/2 starts pointing to
that.  Yes, re-useing p like that is a very bad idea, in many cases :)

> And how can we justify a hypothetical false (which compilers don't
> implement), if compilers will really just read the value?  To implement this
> as well defined behavior, it could result in no other than false, and it
> would require heavy overhead for the compilers to detect that the
> seemingly-equal values are indeed different, don't you think?  The easiest
> solution is for the standard to just declare this outlaw, IMO.
> 
> Maybe it could do an exception for printing, that is, reading a pointer is
> not a problem in itself, a long as you don't compare it, but I'm not such an
> expert about this.
> 
> Cheers,
> 
> Alex
> 
> > 
> > -serge
> 
> -- 
> 
> GPG key fingerprint: A9348594CE31283A826FBDD8D57633D441E25BB5
> 

[GSoC] Introduction and query on LTO object emmission project

[Peter Lafreniere via Gcc]

Hi! I've been interested in compiler development for a while, and would love to
work with any of you as part of GSoC, or even just as a side-project on my own.

I'm an 18 year-old student going into university next year with a passion for 
all
things open source and low level. I consider myself fluent in c, and proficient
with c++, rust, and x86 assembly, but unfamiliar with practical compiler design.
I have done some reading on the theoretical aspects of compilers, however.

While I haven't worked with the GCC community before, I have worked with the 
linux
community and have made several small patches there, so I am familiar with both
email-based workflows and the principles of open-source development. 

This summer, I'm looking for more experience working on larger projects, as well
as getting into real compilers.

Of particular interest to me is the project idea labelled "Bypass assembler when
generating LTO object files." I see that the project was taken last year, but
I can find no sign of any changes committed to trunk 
(`git shortlog --after=2022-01-01 | grep -i -E "lto|assembl(er|y)"` shows 
nothing
related to this project) and no sign of any needed change made in the code.
Is this project still available?

I'm also willing to work on other projects, ideally in the middle/backend, but
currently I have only been experimenting with the gcc/[lto,data]-streamer* 
files.
If anyone has a small or medium sized project idea, please feel free to let me 
know.


I look forward to working with all of you in the future,

Peter Lafreniere

Re: Missed warning (-Wuse-after-free)

[Serge E. Hallyn]

On Fri, Feb 24, 2023 at 09:36:45AM +0100, Martin Uecker wrote:
> Am Donnerstag, dem 23.02.2023 um 19:21 -0600 schrieb Serge E. Hallyn:
> > On Fri, Feb 24, 2023 at 01:02:54AM +0100, Alex Colomar wrote:
> > > Hi Martin,
> > > 
> > > On 2/23/23 20:57, Martin Uecker wrote:
> > > > Am Donnerstag, dem 23.02.2023 um 20:23 +0100 schrieb Alex Colomar:
> > > > > Hi Martin,
> > > > > 
> > > > > On 2/17/23 14:48, Martin Uecker wrote:
> > > > > > > This new wording doesn't even allow one to use memcmp(3);
> > > > > > > just reading the pointer value, however you do it, is UB.
> > > > > > 
> > > > > > memcmp would not use the pointer value but work
> > > > > > on the representation bytes and is still allowed.
> > > > > 
> > > > > Hmm, interesting.  It's rather unspecified behavior. Still
> > > > > unpredictable: (memcmp(, , sizeof(p) == 0) might evaluate to true 
> > > > > or
> > > > > false randomly; the compiler may compile out the call to memcmp(3),
> > > > > since it knows it won't produce any observable behavior.
> > > > > 
> > > > > 
> > > > 
> > > > No, I think several things get mixed up here.
> > > > 
> > > > The representation of a pointer that becomes invalid
> > > > does not change.
> > > > 
> > > > So (0 === memcmp(, , sizeof(p)) always
> > > > evaluates to true.
> > > > 
> > > > Also in general, an unspecified value is simply unspecified
> > > > but does not change anymore.
> > 
> > Right.  p is its own thing - n bytes on the stack containing some value.
> > Once it comes into scope, it doesn't change on its own.  And if I do
> > free(p) or o = realloc(p), then the value of p itself - the n bytes on
> > the stack - does not change.
> 
> Yes, but one comment about terminology:. The C standard
> differentiates between the representation, i.e. the bytes on
> the stack, and the value.  The representation is converted to
> a value during lvalue conversion.  For an invalid pointer
> the representation is indeterminate because it now does not
> point to a valid object anymore.  So it is not possible to
> convert the representation to a value during lvalue conversion.
> In other words, it does not make sense to speak of the value
> of the pointer anymore.

I'm sure there are, especially from an implementer's point of view,
great reasons for this.

However, as just a user, the "value" of 'void *p' should absolutely
not be tied to whatever is at that address.  I'm given a simple
linear memory space, under which sits an entirely different view
obfuscated by page tables, but that doesn't concern me.  if I say
void *p = -1, then if I print p, then I expect to see that value.

Since I'm complaining about standards I'm picking and choosing here,
but I'll still point at the printf(3) manpage :)  :

   p  The  void * pointer argument is printed in hexadecimal (as if by 
%#x
  or %#lx).

> > I realize C11 appears to have changed that.  I fear that in doing so it
> > actually risks increasing the confusion about pointers.  IMO it's much
> > easier to reason about
> > 
> > o = realloc(p, X);
> > 
> > (and more baroque constructions) when keeping in mind that o, p, and the
> > object pointed to by either one are all different things.
> > 
> 
> What did change in C11? As far as I know, the pointer model
> did not change in C11.

I haven't looked in more detail, and don't really plan to, but my
understanding is that the text of:

  The lifetime of an object is the portion of program execution during which 
storage is
  guaranteed to be reserved for it. An object exists, has a constant address, 
and retains
  its last-stored value throughout its lifetime. If an object is referred to 
outside of its
  lifetime, the behavior is undefined. The value of a pointer becomes 
indeterminate when
  the object it points to (or just past) reaches the end of its lifetime.

(especially the last sentence) was new.

Maybe the words "value of a pointer" don't mean what I think they
mean.  But that's the phrase to which I object.  The n bytes on
the stack, p, are not changed just because something happened with
the accounting for the memory at the address represented by that
value.  If they do, then that's not 'C' any more.

> > > > Reading an uninitialized value of automatic storage whose
> > > > address was not taken is undefined behavior, so everything
> > > > is possible afterwards.
> > > > 
> > > > An uninitialized variable whose address was taken has a
> > > > representation which can represent an unspecified value
> > > > or a no-value (trap) representation. Reading the
> > > > representation itself is always ok and gives consistent
> > > > results. Reading the variable can be undefined behavior
> > > > iff it is a trap representation, otherwise you get
> > > > the unspecified value which is stored there.
> > > > 
> > > > At least this is my reading of the C standard. Compilers
> > > > are not full conformant.
> > > 
> > > Does all this imply that the following is well 

[GSoC][C++: Compiler Built-in Traits]: Example Impls & Small Patches

[Ken Matsui via Gcc]

Hi,

My name is Ken Matsui. I am highly interested in contributing to the
project idea, "C++: Implement compiler built-in traits for the
standard library traits." To understand how to implement those traits,
could you please give me some example implementations of the compiler
built-in traits, as well as some recommended traits to get started
with making small patches?

Also, I would appreciate receiving the contact information for the
project mentor, Patrick Palka.

Sincerely,
Ken Matsui

[Bug middle-end/108545] [13 Regression] ICE in install_var_field, at omp-low.cc:799 since r13-2665-g23baa717c991d77f

[burnus at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Tobias Burnus  ---
For the C/C++ testcase of comment 3, bisecting points to
  commit r12-5835-g0ab29cf0bb68960c1f87405f14b4fb2109254e2f
  "openmp: Improve OpenMP target support for C++ (PR92120)"

Re: [PATCH v3 09/11] riscv: thead: Add support for the XTheadMemPair ISA extension

[Kito Cheng via Gcc-patches]

Could you move those thead_* and th_* functions into thead.cc

> +static bool
> +thead_mempair_operand_p (rtx mem, machine_mode mode)
> +{
> +  if (!MEM_SIZE_KNOWN_P (mem))
> +return false;
> +
> +  /* Only DI or SI mempair instructions exist.  */

add gcc_assert (mode == SImode || mode == DImode); here

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

 CC||muecker at gwdg dot de

--- Comment #4 from Martin Uecker  ---

What could work is using a subset of designator syntax.

struct {
  int count;
  char data[.count];
};

But I do not think this should be a flexible array member that is simply
ignored except for sizeof but a complete type (maybe with some restrictions). 

Then we could also have

struct {
  int count;
  char (*buf)[.count];
};

which would be incredible useful.

[Bug target/108840] Aarch64 doesn't optimize away shift counter masking

[ktkachov at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from ktkachov at gcc dot gnu.org ---
Created attachment 54531
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54531=edit
Candidate patch

Candidate patch attached.

[Bug demangler/107884] H8/300: cp-demangle.c fix warning related demangle.h

[mike at mnmoran dot org via Gcc-bugs]

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

--- Comment #8 from Michael N. Moran  ---
I tried to build with after patching with
https://gcc.gnu.org/bugzilla/attachment.cgi?id=53980 and now get an assembler
failure.

/tmp/cc2C1wMh.s: Assembler messages:
/tmp/cc2C1wMh.s:82060: Error: value of 00012570 too large for field of 2 bytes
at 0002

I created a corresponding cp-demangle.s file and attached it
https://gcc.gnu.org/bugzilla/attachment.cgi?id=54530

The offending line looks like this:


.Ldebug_line0:
.2byte  0, .LELT0-.LSLT0 << line 82060
.LSLT0:
.2byte  0x5

[Bug demangler/107884] H8/300: cp-demangle.c fix warning related demangle.h

[mike at mnmoran dot org via Gcc-bugs]

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

Michael N. Moran  changed:

   What|Removed |Added

 CC||mike at mnmoran dot org

--- Comment #7 from Michael N. Moran  ---
Created attachment 54530
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54530=edit
Assembler file produced from cp-demangle.c

[Bug sanitizer/108834] LTO: ltrans temporary file is used as module name in ASAN

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

  Known to fail||12.2.0
  Known to work||13.0

--- Comment #12 from Martin Liška  ---
Fixed on master so far, I'm going to cherry-pick it at least for gcc-12.

[Bug sanitizer/108834] LTO: ltrans temporary file is used as module name in ASAN

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:94c9b1bb79f63d000ebb05efc155c149325e332d

commit r13-6330-g94c9b1bb79f63d000ebb05efc155c149325e332d
Author: Martin Liska 
Date:   Fri Feb 17 15:11:02 2023 +0100

asan: adjust module name for global variables

As mentioned in the PR, when we use LTO, we wrongly use ltrans output
file name as a module name of a global variable. That leads to a
non-reproducible output.

After the suggested change, we emit context name of normal global
variables. And for artificial variables (like .Lubsan_data3), we use
aux_base_name (e.g. "./a.ltrans0.ltrans").

PR sanitizer/108834

gcc/ChangeLog:

* asan.cc (asan_add_global): Use proper TU name for normal
global variables (and aux_base_name for the artificial one).

gcc/testsuite/ChangeLog:

* c-c++-common/asan/global-overflow-1.c: Test line and column
info for a global variable.

Re: [PATCH] asan: adjust module name for global variables

[Martin Liška]

On 2/24/23 10:07, Jakub Jelinek wrote:
> On Fri, Feb 24, 2023 at 10:00:01AM +0100, Martin Liška wrote:
>> As mentioned in the PR, when we use LTO, we wrongly use ltrans output
>> file name as a module name of a global variable. That leads to a
>> non-reproducible output.
>>
>> After the suggested change, we emit context name of normal global
>> variables. And for artificial variables (like .Lubsan_data3), we use
>> aux_base_name (e.g. "./a.ltrans0.ltrans").
>>
>> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>>
>> Ready to be installed?
>> Thanks,
>> Martin
>>
>>  PR asan/108834
>>
>> gcc/ChangeLog:
>>
>>  * asan.cc (asan_add_global): Use proper TU name for normal
>>global variables (and aux_base_name for the artificial one).
>>
>> gcc/testsuite/ChangeLog:
>>
>>  * c-c++-common/asan/global-overflow-1.c: Test line and column
>>  info for a global variable.
>> ---
>>  gcc/asan.cc | 7 ++-
>>  gcc/testsuite/c-c++-common/asan/global-overflow-1.c | 2 +-
>>  2 files changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/gcc/asan.cc b/gcc/asan.cc
>> index f56d084bc7a..245abb14388 100644
>> --- a/gcc/asan.cc
>> +++ b/gcc/asan.cc
>> @@ -3287,7 +3287,12 @@ asan_add_global (tree decl, tree type, 
>> vec *v)
>>  pp_string (_pp, "");
>>str_cst = asan_pp_string (_pp);
>>  
>> -  pp_string (_name_pp, main_input_filename);
>> +  const_tree tu = get_ultimate_context ((const_tree)decl);
>> +  if (tu != NULL_TREE)
>> +pp_string (_name_pp, IDENTIFIER_POINTER (DECL_NAME (tu)));
>> +  else
>> +pp_string (_name_pp, aux_base_name);
> 
> I think for !in_lto_p we don't need to bother with get_ultimate_context
> and should just use main_input_filename as before.

All right, pushed with that change.

Thanks,
Martin

> 
> Otherwise LGTM.
> 
>   Jakub
> 

[PATCH] RISC-V: Add testcase for VSETVL PASS

[juzhe . zhong]

From: Ju-Zhe Zhong 

gcc/testsuite/ChangeLog:

* gcc.target/riscv/rvv/base/scalar_move-1.c: New test.
* gcc.target/riscv/rvv/base/scalar_move-2.c: New test.
* gcc.target/riscv/rvv/base/scalar_move-3.c: New test.
* gcc.target/riscv/rvv/base/scalar_move-4.c: New test.
* gcc.target/riscv/rvv/base/scalar_move-5.c: New test.
* gcc.target/riscv/rvv/base/scalar_move-6.c: New test.
* gcc.target/riscv/rvv/base/scalar_move-7.c: New test.
* gcc.target/riscv/rvv/base/scalar_move-8.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-100.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-101.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-78.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-79.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-80.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-81.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-82.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-83.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-84.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-85.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-86.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-87.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-88.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-89.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-90.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-91.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-92.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-93.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-94.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-95.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-96.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-97.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-98.c: New test.
* gcc.target/riscv/rvv/vsetvl/avl_single-99.c: New test.

---
 .../gcc.target/riscv/rvv/base/scalar_move-1.c |  75 +++
 .../gcc.target/riscv/rvv/base/scalar_move-2.c |  62 ++
 .../gcc.target/riscv/rvv/base/scalar_move-3.c |  58 +
 .../gcc.target/riscv/rvv/base/scalar_move-4.c |  54 +
 .../gcc.target/riscv/rvv/base/scalar_move-5.c | 176 +++
 .../gcc.target/riscv/rvv/base/scalar_move-6.c | 209 ++
 .../gcc.target/riscv/rvv/base/scalar_move-7.c | 176 +++
 .../gcc.target/riscv/rvv/base/scalar_move-8.c | 201 +
 .../riscv/rvv/vsetvl/avl_single-100.c |  25 +++
 .../riscv/rvv/vsetvl/avl_single-101.c |  29 +++
 .../riscv/rvv/vsetvl/avl_single-78.c  |  24 ++
 .../riscv/rvv/vsetvl/avl_single-79.c  |  22 ++
 .../riscv/rvv/vsetvl/avl_single-80.c  |  22 ++
 .../riscv/rvv/vsetvl/avl_single-81.c  |  23 ++
 .../riscv/rvv/vsetvl/avl_single-82.c  |  30 +++
 .../riscv/rvv/vsetvl/avl_single-83.c  |  31 +++
 .../riscv/rvv/vsetvl/avl_single-84.c  |  23 ++
 .../riscv/rvv/vsetvl/avl_single-85.c  |  22 ++
 .../riscv/rvv/vsetvl/avl_single-86.c  |  29 +++
 .../riscv/rvv/vsetvl/avl_single-87.c  |  30 +++
 .../riscv/rvv/vsetvl/avl_single-88.c  |  29 +++
 .../riscv/rvv/vsetvl/avl_single-89.c  |  31 +++
 .../riscv/rvv/vsetvl/avl_single-90.c  |  30 +++
 .../riscv/rvv/vsetvl/avl_single-91.c  |  33 +++
 .../riscv/rvv/vsetvl/avl_single-92.c  |  26 +++
 .../riscv/rvv/vsetvl/avl_single-93.c  |  21 ++
 .../riscv/rvv/vsetvl/avl_single-94.c  |  20 ++
 .../riscv/rvv/vsetvl/avl_single-95.c  |  20 ++
 .../riscv/rvv/vsetvl/avl_single-96.c  |  21 ++
 .../riscv/rvv/vsetvl/avl_single-97.c  |  22 ++
 .../riscv/rvv/vsetvl/avl_single-98.c  |  25 +++
 .../riscv/rvv/vsetvl/avl_single-99.c  |  23 ++
 32 files changed, 1622 insertions(+)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/scalar_move-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/scalar_move-2.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/scalar_move-3.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/scalar_move-4.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/scalar_move-5.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/scalar_move-6.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/scalar_move-7.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/scalar_move-8.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-100.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-101.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-78.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/vsetvl/avl_single-79.c
 create mode 100644 

[PATCH] RISC-V: Add scalar move support and fix VSETVL bugs

[juzhe . zhong]

From: Ju-Zhe Zhong 

gcc/ChangeLog:

* config/riscv/constraints.md (Wb1): New constraint.
* config/riscv/predicates.md 
(vector_least_significant_set_mask_operand): New predicate.
(vector_broadcast_mask_operand): Ditto.
* config/riscv/riscv-protos.h (enum vlmul_type): Adjust.
(gen_scalar_move_mask): New function.
* config/riscv/riscv-v.cc (gen_scalar_move_mask): Ditto.
* config/riscv/riscv-vector-builtins-bases.cc (class vmv): New class.
(class vmv_s): Ditto.
(BASE): Ditto.
* config/riscv/riscv-vector-builtins-bases.h: Ditto.
* config/riscv/riscv-vector-builtins-functions.def (vmv_x): Ditto.
(vmv_s): Ditto.
(vfmv_f): Ditto.
(vfmv_s): Ditto.
* config/riscv/riscv-vector-builtins-shapes.cc (struct 
scalar_move_def): Ditto.
(SHAPE): Ditto.
* config/riscv/riscv-vector-builtins-shapes.h: Ditto.
* config/riscv/riscv-vector-builtins.cc (function_expander::mask_mode): 
Ditto.
(function_expander::use_exact_insn): New function.
(function_expander::use_contiguous_load_insn): New function.
(function_expander::use_contiguous_store_insn): New function.
(function_expander::use_ternop_insn): New function.
(function_expander::use_widen_ternop_insn): New function.
(function_expander::use_scalar_move_insn): New function.
* config/riscv/riscv-vector-builtins.def (s): New operand suffix.
* config/riscv/riscv-vector-builtins.h 
(function_expander::add_scalar_move_mask_operand): New class.
* config/riscv/riscv-vsetvl.cc (ignore_vlmul_insn_p): New function.
(scalar_move_insn_p): Ditto.
(has_vsetvl_killed_avl_p): Ditto.
(anticipatable_occurrence_p): Ditto.
(insert_vsetvl): Ditto.
(get_vl_vtype_info): Ditto.
(calculate_sew): Ditto.
(calculate_vlmul): Ditto.
(incompatible_avl_p): Ditto.
(different_sew_p): Ditto.
(different_lmul_p): Ditto.
(different_ratio_p): Ditto.
(different_tail_policy_p): Ditto.
(different_mask_policy_p): Ditto.
(possible_zero_avl_p): Ditto.
(first_ratio_invalid_for_second_sew_p): Ditto.
(first_ratio_invalid_for_second_lmul_p): Ditto.
(second_ratio_invalid_for_first_sew_p): Ditto.
(second_ratio_invalid_for_first_lmul_p): Ditto.
(second_sew_less_than_first_sew_p): Ditto.
(first_sew_less_than_second_sew_p): Ditto.
(compare_lmul): Ditto.
(second_lmul_less_than_first_lmul_p): Ditto.
(first_lmul_less_than_second_lmul_p): Ditto.
(first_ratio_less_than_second_ratio_p): Ditto.
(second_ratio_less_than_first_ratio_p): Ditto.
(DEF_INCOMPATIBLE_COND): Ditto.
(greatest_sew): Ditto.
(first_sew): Ditto.
(second_sew): Ditto.
(first_vlmul): Ditto.
(second_vlmul): Ditto.
(first_ratio): Ditto.
(second_ratio): Ditto.
(vlmul_for_first_sew_second_ratio): Ditto.
(ratio_for_second_sew_first_vlmul): Ditto.
(DEF_SEW_LMUL_FUSE_RULE): Ditto.
(always_unavailable): Ditto.
(avl_unavailable_p): Ditto.
(sew_unavailable_p): Ditto.
(lmul_unavailable_p): Ditto.
(ge_sew_unavailable_p): Ditto.
(ge_sew_lmul_unavailable_p): Ditto.
(ge_sew_ratio_unavailable_p): Ditto.
(DEF_UNAVAILABLE_COND): Ditto.
(same_sew_lmul_demand_p): Ditto.
(propagate_avl_across_demands_p): Ditto.
(reg_available_p): Ditto.
(avl_info::has_non_zero_avl): Ditto.
(vl_vtype_info::has_non_zero_avl): Ditto.
(vector_insn_info::operator>=): Refactor.
(vector_insn_info::parse_insn): Adjust for scalar move.
(vector_insn_info::demand_vl_vtype): Remove.
(vector_insn_info::compatible_p): New function.
(vector_insn_info::compatible_avl_p): Ditto.
(vector_insn_info::compatible_vtype_p): Ditto.
(vector_insn_info::available_p): Ditto.
(vector_insn_info::merge): Ditto.
(vector_insn_info::fuse_avl): Ditto.
(vector_insn_info::fuse_sew_lmul): Ditto.
(vector_insn_info::fuse_tail_policy): Ditto.
(vector_insn_info::fuse_mask_policy): Ditto.
(vector_insn_info::dump): Ditto.
(vector_infos_manager::release): Ditto.
(pass_vsetvl::compute_local_backward_infos): Adjust for scalar move 
support.
(pass_vsetvl::get_backward_fusion_type): Adjust for scalar move support.
(pass_vsetvl::hard_empty_block_p): Ditto.
(pass_vsetvl::backward_demand_fusion): Ditto.
(pass_vsetvl::forward_demand_fusion): Ditto.
(pass_vsetvl::refine_vsetvls): Ditto.
(pass_vsetvl::cleanup_vsetvls): Ditto.
(pass_vsetvl::commit_vsetvls): Ditto.
(pass_vsetvl::propagate_avl): Ditto.
* config/riscv/riscv-vsetvl.h (enum demand_status): New class.
(struct 

Re: [PATCH] rs6000: fmr gets used instead of faster xxlor [PR93571]

[Segher Boessenkool]

Hi!

For future patches: please don't send patches as replies to existing
threads.  Just start a new thread for a new patch (series).  You can
mark it as [PATCH v2] in the subject, if you want.

On Fri, Feb 24, 2023 at 01:41:49PM +0530, Ajit Agarwal wrote:
> Here is the patch that uses xxlor instead of fmr where possible.
> Performance results shows that fmr is better in power9 and 
> power10 architectures whereas xxlor is better in power7 and
> power 8 architectures.

And fmr is the only option before p7.

>   rs6000: Use xxlor instead of fmr where possible
> 
>   This patch replaces fmr with xxlor instruction for power7
>   and power8 architectures whereas for power9 and power10
>   replaces xxlor with fmr instruction.

Saying "this patch" in a commit message reads strangely.  Just "Replace
fmr with" etc.?

The second part is just wrong, you cannot replace xxlor by fmr in
general.

>   Perf measurement results:
> 
>   Power9 fmr:  201,847,661 cycles.
>   Power9 xxlor: 201,877,78 cycles.
>   Power8 fmr: 201,057,795 cycles.
> Power8 xxlor: 201,004,671 cycles.

What is this measuring?  100M insns back-to-back, each dependent on the
previous one?

What are the results on p7 and p10?

These numbers show there is no difference on p8 either.  Did you paste
the wrong numbers maybe?

>   * config/rs6000/rs6000.md (*movdf_hardfloat64): Use xxlor
>   for power7 and power8 and fmr for power9 and power10.

Please don't break lines early.  Changelogs lines can be 80 columns
wide, just like source code lines.

> --- a/gcc/config/rs6000/rs6000.md
> +++ b/gcc/config/rs6000/rs6000.md
> @@ -354,7 +354,7 @@ (define_attr "cpu"
>(const (symbol_ref "(enum attr_cpu) rs6000_tune")))
>  
>  ;; The ISA we implement.
> -(define_attr "isa" "any,p5,p6,p7,p7v,p8v,p9,p9v,p9kf,p9tf,p10"
> +(define_attr "isa" "any,p5,p6,p7,p7v,p8v,p9,p9v,p9kf,p9tf,p7p8,p10"

p78v, and sort it after p8v please.

> + (and (eq_attr "isa" "p7p8")
> +   (match_test "TARGET_VSX && !TARGET_P9_VECTOR"))
> + (const_int 1)

Okay.

>  (define_insn "*mov_hardfloat64"
>[(set (match_operand:FMOVE64 0 "nonimmediate_operand"
> -   "=m,   d,  d,  ,   wY,
> - ,Z,  ,  ,  !r,
> - YZ,  r,  !r, *c*l,   !r,
> -*h,   r,  ,   wa")
> +   "=m,   d,  ,  ,   wY,
> +, Z,  wa, ,  !r,
> +YZ,   r,  !r, *c*l,   !r,
> +*h,   r,  ,   d,  wn,
> +wa")
>   (match_operand:FMOVE64 1 "input_operand"

(You posted this mail as wrapping.  That means the patch cannot be
applied non-manually, and that replies to your mail will be mangled.
Just get a Real mail client, and configure it correctly :-) )

> -"d,   m,  d,  wY, ,
> - Z,   ,   ,  ,  ,
> +"d,   m,  ,  wY, ,
> + Z,   ,   wa, ,  ,
>   r,   YZ, r,  r,  *h,
> - 0,   ,   r,  eP"))]
> + 0,   ,   r,  d,  wn,
> + eP"))]

No.  It is impossible to figure out what you changed here by just
reading it.

There is no requirement there should be exactly five alternatives per
line, and/or that there should be the same number everywhere.

If the indentation was incorrect, and you want to fix that, do that in a
separate *earlier* patch in the series, please.

>"TARGET_POWERPC64 && TARGET_HARD_FLOAT
> && (gpc_reg_operand (operands[0], mode)
> || gpc_reg_operand (operands[1], mode))"
>"@
> stfd%U0%X0 %1,%0
> lfd%U1%X1 %0,%1
> -   fmr %0,%1
> +   xxlor %x0,%x1,%x1
> lxsd %0,%1
> stxsd %1,%0
> lxsdx %x0,%y1
> stxsdx %x1,%y0
> -   xxlor %x0,%x1,%x1
> +   fmr %0,%1
> xxlxor %x0,%x0,%x0
> li %0,0
> std%U0%X0 %1,%0
> @@ -8467,23 +8474,28 @@ (define_insn "*mov_hardfloat64"
> nop
> mfvsrd %0,%x1
> mtvsrd %x0,%1
> +   fmr %0,%1
> +   fmr %0,%1
> #"
>[(set_attr "type"
> -"fpstore, fpload, fpsimple,   fpload, fpstore,
> +"fpstore, fpload, veclogical, fpload, fpstore,
>   fpload,  fpstore,veclogical, veclogical, integer,
>   store,   load,   *,  mtjmpr, mfjmpr,
> - *,   mfvsr,  mtvsr,  vecperm")
> + *,   mfvsr,  mtvsr,  fpsimple,   fpsimple,
> + vecperm")
> (set_attr "size" "64")
> (set_attr "isa"
> -"*,   *,  *,  p9v,p9v,
> - p7v, p7v,*,  *,  *,
> - *,   *,  *,  *,  *,
> - *,   p8v,p8v,   

[Bug middle-end/108545] [13 Regression] ICE in install_var_field, at omp-low.cc:799 since r13-2665-g23baa717c991d77f

[burnus at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Tobias Burnus  ---
Fortran: Same issue (ICE) also with:
   !$omp target enter data map(to: x)

Crucial is the VOLATILE attribute.

 * * *

The following C code already gives an ICE with GCC 12, it works with GCC 11.
(Either of the two lines fail. I think that's invalid OpenMP code, but
I do not have a real overview about 'map' - and I fear no one has.)


volatile struct t {
  struct t2 { int *a; int c; } u;
  int b;
} my_struct;
volatile struct t3 { int *a; int c; } my_struct3;

void f() {
  #pragma omp target enter data map(to:my_struct.u) map(to:my_struct.u.a)
  #pragma omp target enter data map(to:my_struct3) map(to:my_struct3.a)
}

[Bug c++/105224] [modules] g++.dg/modules/virt-2_a.C: inline key methods: c++ modules and arm aapcs clash

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Alexandre Oliva :

https://gcc.gnu.org/g:3d1d3ece9bc5a1baa2feb4bf231b709c097b8434

commit r13-6329-g3d1d3ece9bc5a1baa2feb4bf231b709c097b8434
Author: Alexandre Oliva 
Date:   Fri Feb 24 11:31:05 2023 -0300

[PR105224] C++ modules and AAPCS/ARM EABI clash on inline key methods

g++.dg/modules/virt-2_a.C fails on arm-eabi and many other arm targets
that use the AAPCS variant.  ARM is the only target that overrides
TARGET_CXX_KEY_METHOD_MAY_BE_INLINE.  It's not clear to me which way
the clash between AAPCS and C++ Modules design should be resolved, but
currently it favors AAPCS and thus the test fails, so skip it on
arm_eabi.


for  gcc/testsuite/ChangeLog

PR c++/105224
* g++.dg/modules/virt-2_a.C: Skip on arm_eabi.

Re: C++ modules and AAPCS/ARM EABI clash on inline key methods

[Alexandre Oliva via Gcc-patches]

On Feb 24, 2023, Richard Earnshaw  wrote:

> Given the logic of this macro, the text should be
> "!TARGET_CXX_METHOD_MAY_BE_INLINE".

I was thinking just "related to that macro", but yeah, negating it makes
sense.

> OK with that change.

Thanks, here's what I'm checking in.


[PR105224] C++ modules and AAPCS/ARM EABI clash on inline key methods

From: Alexandre Oliva 

g++.dg/modules/virt-2_a.C fails on arm-eabi and many other arm targets
that use the AAPCS variant.  ARM is the only target that overrides
TARGET_CXX_KEY_METHOD_MAY_BE_INLINE.  It's not clear to me which way
the clash between AAPCS and C++ Modules design should be resolved, but
currently it favors AAPCS and thus the test fails, so skip it on
arm_eabi.


for  gcc/testsuite/ChangeLog

PR c++/105224
* g++.dg/modules/virt-2_a.C: Skip on arm_eabi.
---
 gcc/testsuite/g++.dg/modules/virt-2_a.C |3 +++
 1 file changed, 3 insertions(+)

diff --git a/gcc/testsuite/g++.dg/modules/virt-2_a.C 
b/gcc/testsuite/g++.dg/modules/virt-2_a.C
index 580552be5a0d8..b5050445c3f15 100644
--- a/gcc/testsuite/g++.dg/modules/virt-2_a.C
+++ b/gcc/testsuite/g++.dg/modules/virt-2_a.C
@@ -1,3 +1,6 @@
+// AAPCS overrides TARGET_CXX_KEY_METHOD_MAY_BE_INLINE,
+// in a way that invalidates this test.
+// { dg-skip-if "!TARGET_CXX_KEY_METHOD_MAY_BE_INLINE" { arm_eabi } } 
 // { dg-module-do run }
 // { dg-additional-options -fmodules-ts }
 export module foo;


-- 
Alexandre Oliva, happy hackerhttps://FSFLA.org/blogs/lxo/
   Free Software Activist   GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about 

[Bug c/107557] [12/13 Regression] ICE -fsanitize=undefined and VLA as argument type to a function

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #7 from Martin Uecker  ---
Created attachment 54529
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54529=edit
new version of patch


Here is another patch that does all the recursion in gimplify_type_sizes.
Unfortunately, there are regression tests failing for fortran.

[committed 2/5] libstdc++: Fix conversion to/from net::ip::address_v4::bytes_type

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux. Pushed to trunk.

-- >8 --

I messed up the endianness of the address_v4::bytes_type array, which
should always be in network byte order. We can just use bit_cast to
convert the _M_addr member to/from bytes_type.

libstdc++-v3/ChangeLog:

* include/experimental/internet (address_4(const bytes_type&)):
Use __builtin_bit_cast if available, otherwise convert to
network byte order.
(address_v4::to_bytes()): Likewise, but convert from network
byte order.
* testsuite/experimental/net/internet/address/v4/cons.cc: Fix
incorrect tests. Check for constexpr too.
* testsuite/experimental/net/internet/address/v4/creation.cc:
Likewise.
* testsuite/experimental/net/internet/address/v4/members.cc:
Check that bytes_type is a standard-layout type.
---
 libstdc++-v3/include/experimental/internet| 20 ---
 .../net/internet/address/v4/cons.cc   | 33 ---
 .../net/internet/address/v4/creation.cc   | 24 +++---
 .../net/internet/address/v4/members.cc|  3 ++
 4 files changed, 60 insertions(+), 20 deletions(-)

diff --git a/libstdc++-v3/include/experimental/internet 
b/libstdc++-v3/include/experimental/internet
index 08bd0db4bb2..3fd200251fa 100644
--- a/libstdc++-v3/include/experimental/internet
+++ b/libstdc++-v3/include/experimental/internet
@@ -198,7 +198,12 @@ namespace ip
 
 constexpr
 address_v4(const bytes_type& __b)
-: _M_addr((__b[0] << 24) | (__b[1] << 16) | (__b[2] << 8) | __b[3])
+#if __has_builtin(__builtin_bit_cast)
+: _M_addr(__builtin_bit_cast(uint_type, __b))
+#else
+: _M_addr(_S_hton_32((__b[0] << 24) | (__b[1] << 16)
+  | (__b[2] << 8) | __b[3]))
+#endif
 { }
 
 explicit constexpr
@@ -227,12 +232,17 @@ namespace ip
 constexpr bytes_type
 to_bytes() const noexcept
 {
+#if __has_builtin(__builtin_bit_cast)
+  return __builtin_bit_cast(bytes_type, _M_addr);
+#else
+  auto __host = to_uint();
   return bytes_type{
- (_M_addr >> 24) & 0xFF,
- (_M_addr >> 16) & 0xFF,
- (_M_addr >> 8) & 0xFF,
- _M_addr & 0xFF
+   (__host >> 24) & 0xFF,
+   (__host >> 16) & 0xFF,
+   (__host >> 8) & 0xFF,
+   __host & 0xFF
   };
+#endif
 }
 
 constexpr uint_type
diff --git 
a/libstdc++-v3/testsuite/experimental/net/internet/address/v4/cons.cc 
b/libstdc++-v3/testsuite/experimental/net/internet/address/v4/cons.cc
index 65f23642de4..af9fef2215e 100644
--- a/libstdc++-v3/testsuite/experimental/net/internet/address/v4/cons.cc
+++ b/libstdc++-v3/testsuite/experimental/net/internet/address/v4/cons.cc
@@ -24,41 +24,45 @@
 
 using std::experimental::net::ip::address_v4;
 
-void
+#if __cplusplus < 202002L
+// Naughty, but operator== for std::array is not constexpr until C++20.
+constexpr bool
+operator==(const address_v4::bytes_type& lhs, const address_v4::bytes_type& 
rhs)
+{
+  return lhs[0] == rhs[0] && lhs[1] == rhs[1]
+  && lhs[2] == rhs[2] && lhs[3] == rhs[3];
+}
+#endif
+
+constexpr void
 test01()
 {
-  bool test __attribute__((unused)) = false;
-
   address_v4 a0;
   VERIFY( a0.to_uint() == 0 );
   VERIFY( a0.to_bytes() == address_v4::bytes_type{} );
 }
 
-void
+constexpr void
 test02()
 {
-  bool test __attribute__((unused)) = false;
-
   address_v4 a0{ address_v4::bytes_type{} };
   VERIFY( a0.to_uint() == 0 );
   VERIFY( a0.to_bytes() == address_v4::bytes_type{} );
 
   address_v4::bytes_type b1{ 1, 2, 3, 4 };
   address_v4 a1{ b1 };
-  VERIFY( a1.to_uint() == ntohl((1 << 24) | (2 << 16) | (3 << 8) | 4) );
+  VERIFY( a1.to_uint() == ((1 << 24) | (2 << 16) | (3 << 8) | 4) );
   VERIFY( a1.to_bytes() == b1 );
 }
 
-void
+constexpr void
 test03()
 {
-  bool test __attribute__((unused)) = false;
-
   address_v4 a0{ 0u };
   VERIFY( a0.to_uint() == 0 );
   VERIFY( a0.to_bytes() == address_v4::bytes_type{} );
 
-  address_v4::uint_type u1 = ntohl((5 << 24) | (6 << 16) | (7 << 8) | 8);
+  address_v4::uint_type u1 = (5 << 24) | (6 << 16) | (7 << 8) | 8;
   address_v4 a1{ u1 };
   VERIFY( a1.to_uint() == u1 );
   VERIFY( a1.to_bytes() == address_v4::bytes_type( 5, 6, 7, 8 ) );
@@ -70,4 +74,11 @@ main()
   test01();
   test02();
   test03();
+
+  constexpr bool c = []{
+test01();
+test02();
+test03();
+return true;
+  };
 }
diff --git 
a/libstdc++-v3/testsuite/experimental/net/internet/address/v4/creation.cc 
b/libstdc++-v3/testsuite/experimental/net/internet/address/v4/creation.cc
index 441c832bf54..84aebbb7adc 100644
--- a/libstdc++-v3/testsuite/experimental/net/internet/address/v4/creation.cc
+++ b/libstdc++-v3/testsuite/experimental/net/internet/address/v4/creation.cc
@@ -25,7 +25,17 @@
 namespace net = std::experimental::net;
 using net::ip::address_v4;
 
-void
+#if __cplusplus < 202002L
+// Naughty, but operator== for std::array is not constexpr until C++20.
+constexpr bool
+operator==(const address_v4::bytes_type& lhs, 

[committed 3/5] libstdc++: Fix members of net::ip::network_v4

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux. Pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* include/experimental/internet (network_v4::netmask()): Avoid
undefined shift.
(network_v4::broadcast()): Optimize and fix for targets with
uint_least32_t wider than 32 bits.
(network_v4::to_string(const Allocator&)): Fix for custom
allocators and optimize using to_chars.
(operator==(const network_v4&, const network_v4&)): Add missing
constexpr.
(operator==(const network_v6&, const network_v6&)): Likewise.
* testsuite/experimental/net/internet/network/v4/cons.cc: New test.
* testsuite/experimental/net/internet/network/v4/members.cc: New test.
---
 libstdc++-v3/include/experimental/internet|  41 ++--
 .../net/internet/network/v4/cons.cc   | 129 
 .../net/internet/network/v4/members.cc| 186 ++
 3 files changed, 343 insertions(+), 13 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/experimental/net/internet/network/v4/cons.cc
 create mode 100644 
libstdc++-v3/testsuite/experimental/net/internet/network/v4/members.cc

diff --git a/libstdc++-v3/include/experimental/internet 
b/libstdc++-v3/include/experimental/internet
index 3fd200251fa..5336b8a8ce3 100644
--- a/libstdc++-v3/include/experimental/internet
+++ b/libstdc++-v3/include/experimental/internet
@@ -1219,10 +1219,10 @@ namespace ip
 
   /// @}
 
-  bool
+  constexpr bool
   operator==(const network_v4& __a, const network_v4& __b) noexcept;
 
-  bool
+  constexpr bool
   operator==(const network_v6& __a, const network_v6& __b) noexcept;
 
 
@@ -1263,10 +1263,10 @@ namespace ip
 constexpr address_v4
 netmask() const noexcept
 {
-  address_v4::uint_type __val = address_v4::broadcast().to_uint();
-  __val >>= (32 - _M_prefix_len);
-  __val <<= (32 - _M_prefix_len);
-  return address_v4{__val};
+  address_v4 __m;
+  if (_M_prefix_len)
+   __m = address_v4(0xu << (32 - _M_prefix_len));
+  return __m;
 }
 
 constexpr address_v4
@@ -1275,7 +1275,7 @@ namespace ip
 
 constexpr address_v4
 broadcast() const noexcept
-{ return address_v4{_M_addr.to_uint() | ~netmask().to_uint()}; }
+{ return address_v4{_M_addr.to_uint() | (0xu >> _M_prefix_len)}; }
 
 address_v4_range
 hosts() const noexcept
@@ -1306,8 +1306,23 @@ namespace ip
   __string_with<_Allocator>
   to_string(const _Allocator& __a = _Allocator()) const
   {
-   return address().to_string(__a) + '/'
- + std::to_string(prefix_length());
+   auto __str = address().to_string(__a);
+   const unsigned __addrlen = __str.length();
+   const unsigned __preflen = prefix_length() >= 10 ? 2 : 1;
+   auto __write = [=](char* __p, size_t __n) {
+ __p[__addrlen] = '/';
+ std::__detail::__to_chars_10_impl(__p + __addrlen + 1, __preflen,
+   (unsigned char)prefix_length());
+ return __n;
+   };
+   const unsigned __len = __addrlen + 1 + __preflen;
+#if __cpp_lib_string_resize_and_overwrite
+   __str.resize_and_overwrite(__len, __write);
+#else
+   __str.resize(__len);
+   __write(&__str.front(), __len);
+#endif
+   return __str;
   }
 
   private:
@@ -1379,14 +1394,14 @@ namespace ip
* @{
*/
 
-  inline bool
+  constexpr bool
   operator==(const network_v4& __a, const network_v4& __b) noexcept
   {
 return __a.address() == __b.address()
   && __a.prefix_length() == __b.prefix_length();
   }
 
-  inline bool
+  constexpr bool
   operator!=(const network_v4& __a, const network_v4& __b) noexcept
   { return !(__a == __b); }
 
@@ -1396,14 +1411,14 @@ namespace ip
* @{
*/
 
-  inline bool
+  constexpr bool
   operator==(const network_v6& __a, const network_v6& __b) noexcept
   {
 return __a.address() == __b.address()
   && __a.prefix_length() == __b.prefix_length();
   }
 
-  inline bool
+  constexpr bool
   operator!=(const network_v6& __a, const network_v6& __b) noexcept
   { return !(__a == __b); }
 
diff --git 
a/libstdc++-v3/testsuite/experimental/net/internet/network/v4/cons.cc 
b/libstdc++-v3/testsuite/experimental/net/internet/network/v4/cons.cc
new file mode 100644
index 000..7784b6f6f58
--- /dev/null
+++ b/libstdc++-v3/testsuite/experimental/net/internet/network/v4/cons.cc
@@ -0,0 +1,129 @@
+// { dg-do run { target c++14 } }
+// { dg-require-effective-target net_ts_ip }
+// { dg-add-options net_ts }
+
+#include 
+#include 
+#include 
+
+using std::experimental::net::ip::network_v4;
+using std::experimental::net::ip::address_v4;
+
+constexpr void
+test01()
+{
+  network_v4 n0;
+  VERIFY( n0.address().is_unspecified() );
+  VERIFY( n0.prefix_length() == 0 );
+}
+
+constexpr void
+test02()
+{
+  address_v4 a0;
+  network_v4 n0{ a0, 0 };
+  VERIFY( n0.address() == a0 );
+  VERIFY( n0.prefix_length() == 0 );
+
+  address_v4 a1{ 

[committed 4/5] libstdc++: Make net::ip::basic_endpoint comparisons constexpr

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux. Pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* include/experimental/internet (basic_endpoint): Add missing
constexpr to comparison operators.
* testsuite/experimental/net/internet/endpoint/cons.cc: New test.
---
 libstdc++-v3/include/experimental/internet| 12 ++--
 .../net/internet/endpoint/cons.cc | 66 +++
 2 files changed, 72 insertions(+), 6 deletions(-)
 create mode 100644 
libstdc++-v3/testsuite/experimental/net/internet/endpoint/cons.cc

diff --git a/libstdc++-v3/include/experimental/internet 
b/libstdc++-v3/include/experimental/internet
index 5336b8a8ce3..cae07f466da 100644
--- a/libstdc++-v3/include/experimental/internet
+++ b/libstdc++-v3/include/experimental/internet
@@ -1626,19 +1626,19 @@ namespace ip
*/
 
   template
-inline bool
+constexpr bool
 operator==(const basic_endpoint<_InternetProtocol>& __a,
   const basic_endpoint<_InternetProtocol>& __b)
 { return __a.address() == __b.address() && __a.port() == __b.port(); }
 
   template
-inline bool
+constexpr bool
 operator!=(const basic_endpoint<_InternetProtocol>& __a,
   const basic_endpoint<_InternetProtocol>& __b)
 { return !(__a == __b); }
 
   template
-inline bool
+constexpr bool
 operator< (const basic_endpoint<_InternetProtocol>& __a,
   const basic_endpoint<_InternetProtocol>& __b)
 {
@@ -1647,19 +1647,19 @@ namespace ip
 }
 
   template
-inline bool
+constexpr bool
 operator> (const basic_endpoint<_InternetProtocol>& __a,
   const basic_endpoint<_InternetProtocol>& __b)
 { return __b < __a; }
 
   template
-inline bool
+constexpr bool
 operator<=(const basic_endpoint<_InternetProtocol>& __a,
   const basic_endpoint<_InternetProtocol>& __b)
 { return !(__b < __a); }
 
   template
-inline bool
+constexpr bool
 operator>=(const basic_endpoint<_InternetProtocol>& __a,
   const basic_endpoint<_InternetProtocol>& __b)
 { return !(__a < __b); }
diff --git a/libstdc++-v3/testsuite/experimental/net/internet/endpoint/cons.cc 
b/libstdc++-v3/testsuite/experimental/net/internet/endpoint/cons.cc
new file mode 100644
index 000..1b5c92c0b58
--- /dev/null
+++ b/libstdc++-v3/testsuite/experimental/net/internet/endpoint/cons.cc
@@ -0,0 +1,66 @@
+// { dg-do run { target c++14 } }
+// { dg-require-effective-target net_ts_ip }
+// { dg-add-options net_ts }
+
+#include 
+#include 
+
+using namespace std::experimental::net;
+
+constexpr void
+test_default()
+{
+  ip::tcp::endpoint t1;
+  VERIFY( t1.protocol() == ip::tcp::v4() );
+  VERIFY( t1.address() == ip::address() );
+  VERIFY( t1.port() == 0 );
+
+  ip::udp::endpoint t2;
+  VERIFY( t2.protocol() == ip::udp::v4() );
+  VERIFY( t2.address() == ip::address() );
+  VERIFY( t2.port() == 0 );
+}
+
+constexpr void
+test_proto()
+{
+  ip::tcp::endpoint t1(ip::tcp::v4(), 22);
+  VERIFY( t1.protocol() == ip::tcp::v4() );
+  VERIFY( t1.address() == ip::address_v4() );
+  VERIFY( t1.port() == 22 );
+
+  ip::tcp::endpoint t2(ip::tcp::v6(), 80);
+  VERIFY( t2.protocol() == ip::tcp::v6() );
+  VERIFY( t2.address() == ip::address_v6() );
+  VERIFY( t2.port() == 80 );
+}
+
+constexpr void
+test_addr()
+{
+  ip::address_v4 a1(ip::address_v4::bytes_type(1, 2, 3, 4));
+  ip::tcp::endpoint t1(a1, 22);
+  VERIFY( t1.protocol() == ip::tcp::v4() );
+  VERIFY( t1.address() == a1 );
+  VERIFY( t1.port() == 22 );
+
+  ip::address_v6 a2(ip::address_v6::bytes_type(21,22,23,24,25,26,27,28,29));
+  ip::tcp::endpoint t2(a2, 80);
+  VERIFY( t2.protocol() == ip::tcp::v6() );
+  VERIFY( t2.address() == a2 );
+  VERIFY( t2.port() == 80 );
+}
+
+int main()
+{
+  test_default();
+  test_proto();
+  test_addr();
+
+  constexpr bool c = [] {
+test_default();
+test_proto();
+test_addr();
+return true;
+  };
+}
-- 
2.39.2

[committed 5/5] libstdc++: Constrain net::executor constructors

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux. Pushed to trunk.

-- >8 --

The TS says the arguments to these constructors shall meet the Executor
requirements, so it's undefined if they don't. Constraining on a subset
of those requirements won't affect valid cases, but prevents the
majority of invalid cases from trying to instantiate the constructor.

This prevents the non-explicit executor(Executor) constructor being a
candidate anywhere that a net::executor could be constructed e.g.
comparing ip::tcp::v4() == ip::udp::v4() would try to convert both
operands to executor using that constructor, then compare then using
operator==(const executor&, const executor&).

libstdc++-v3/ChangeLog:

* include/experimental/executor (executor): Constrain template
constructors.
---
 libstdc++-v3/include/experimental/executor | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/include/experimental/executor 
b/libstdc++-v3/include/experimental/executor
index cd75d99ddb3..1dae8925916 100644
--- a/libstdc++-v3/include/experimental/executor
+++ b/libstdc++-v3/include/experimental/executor
@@ -1012,6 +1012,9 @@ inline namespace v1
 
   class executor
   {
+template
+  using _Context_t = decltype(std::declval<_Executor&>().context());
+
   public:
 // construct / copy / destroy:
 
@@ -1021,12 +1024,14 @@ inline namespace v1
 executor(const executor&) noexcept = default;
 executor(executor&&) noexcept = default;
 
-template
+template>>>
   executor(_Executor __e)
   : _M_target(make_shared<_Tgt1<_Executor>>(std::move(__e)))
   { }
 
-template
+template>>>
   executor(allocator_arg_t, const _ProtoAlloc& __a, _Executor __e)
   : _M_target(allocate_shared<_Tgt2<_Executor, _ProtoAlloc>>(__a,
std::move(__e), __a))
-- 
2.39.2

[committed 1/5] libstdc++: Optimize net::ip::address_v4::to_string()

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux. Pushed to trunk.

-- >8 --

This is an order of magnitude faster than calling inet_ntop (and not
only because we now avoid allocating a string that is one byte larger
than the SSO buffer).

libstdc++-v3/ChangeLog:

* include/experimental/internet (address_v4::to_string):
Optimize.
* testsuite/experimental/net/internet/address/v4/members.cc:
Check more addresses.
---
 libstdc++-v3/include/experimental/internet| 28 +--
 .../net/internet/address/v4/members.cc| 11 
 2 files changed, 31 insertions(+), 8 deletions(-)

diff --git a/libstdc++-v3/include/experimental/internet 
b/libstdc++-v3/include/experimental/internet
index 707370d5611..08bd0db4bb2 100644
--- a/libstdc++-v3/include/experimental/internet
+++ b/libstdc++-v3/include/experimental/internet
@@ -44,6 +44,7 @@
 #include 
 #include 
 #include 
+#include 
 #ifdef _GLIBCXX_HAVE_UNISTD_H
 # include 
 #endif
@@ -241,17 +242,28 @@ namespace ip
   __string_with<_Allocator>
   to_string(const _Allocator& __a = _Allocator()) const
   {
-#ifdef _GLIBCXX_HAVE_ARPA_INET_H
+   auto __write = [__addr = to_uint()](char* __p, size_t __n) {
+ auto __to_chars = [](char* __p, uint8_t __v) {
+   unsigned __n = __v >= 100u ? 3 : __v >= 10u ? 2 : 1;
+   std::__detail::__to_chars_10_impl(__p, __n, __v);
+   return __p + __n;
+ };
+ const auto __begin = __p;
+ __p = __to_chars(__p, uint8_t(__addr >> 24));
+ for (int __i = 2; __i >= 0; __i--) {
+   *__p++ = '.';
+   __p = __to_chars(__p, uint8_t(__addr >> (__i * 8)));
+ }
+ return __p - __begin;
+   };
__string_with<_Allocator> __str(__a);
-   __str.resize(INET_ADDRSTRLEN);
-   if (inet_ntop(AF_INET, &_M_addr, &__str.front(), __str.size()))
- __str.erase(__str.find('\0'));
-   else
- __str.resize(0);
-   return __str;
+#if __cpp_lib_string_resize_and_overwrite
+   __str.resize_and_overwrite(15, __write);
 #else
-   std::__throw_system_error((int)__unsupported_err());
+   __str.resize(15);
+   __str.resize(__write(&__str.front(), 15));
 #endif
+   return __str;
   }
 
 // static members:
diff --git 
a/libstdc++-v3/testsuite/experimental/net/internet/address/v4/members.cc 
b/libstdc++-v3/testsuite/experimental/net/internet/address/v4/members.cc
index df19b11804d..c40a8103664 100644
--- a/libstdc++-v3/testsuite/experimental/net/internet/address/v4/members.cc
+++ b/libstdc++-v3/testsuite/experimental/net/internet/address/v4/members.cc
@@ -22,6 +22,7 @@
 #include 
 #include 
 #include 
+#include 
 
 using std::experimental::net::ip::address_v4;
 
@@ -100,6 +101,16 @@ test04()
   VERIFY( address_v4::any().to_string() == "0.0.0.0" );
   VERIFY( address_v4::loopback().to_string() == "127.0.0.1" );
   VERIFY( address_v4::broadcast().to_string() == "255.255.255.255" );
+  using b = address_v4::bytes_type;
+  VERIFY( address_v4(b(1, 23, 45, 67)).to_string() == "1.23.45.67" );
+  VERIFY( address_v4(b(12, 34, 56, 78)).to_string() == "12.34.56.78" );
+  VERIFY( address_v4(b(123, 4, 5, 6)).to_string() == "123.4.5.6" );
+  VERIFY( address_v4(b(123, 234, 124, 235)).to_string() == "123.234.124.235" );
+
+  __gnu_test::uneq_allocator alloc(123);
+  auto str = address_v4(b(12, 34, 56, 78)).to_string(alloc);
+  VERIFY(str.get_allocator().get_personality() == alloc.get_personality());
+  VERIFY( str == "12.34.56.78" );
 }
 
 void
-- 
2.39.2

[committed] libstdc++: Suppress warnings about use of deprecated std::aligned_storage

[Jonathan Wakely via Gcc-patches]

Tested powerpc64le-linux. Pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* include/ext/aligned_buffer.h (__aligned_buffer): Add
diagnostic pragmas.
---
 libstdc++-v3/include/ext/aligned_buffer.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/libstdc++-v3/include/ext/aligned_buffer.h 
b/libstdc++-v3/include/ext/aligned_buffer.h
index 765d14684f2..dc62dfc8741 100644
--- a/libstdc++-v3/include/ext/aligned_buffer.h
+++ b/libstdc++-v3/include/ext/aligned_buffer.h
@@ -81,6 +81,8 @@ namespace __gnu_cxx
   template
 using __aligned_buffer = __aligned_membuf<_Tp>;
 #else
+#pragma GCC diagnostic push
+#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
   // Similar to __aligned_membuf but aligned for complete objects, not members.
   // This type is used in , , 
   // and , but ideally they would use __aligned_membuf
@@ -118,6 +120,7 @@ namespace __gnu_cxx
   _M_ptr() const noexcept
   { return static_cast(_M_addr()); }
 };
+#pragma GCC diagnostic pop
 #endif
 
 } // namespace
-- 
2.39.2

[Bug c/63357] Warn for P && P and P || P (same expression used multiple times in a condition)

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #10 from David Binderman  ---
(In reply to Manuel López-Ibáñez from comment #9)
> Please open a new PR mentioning this one.

Done. See 108926.

[Bug c/108926] No warning for same expression in chain of | or & ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
(In reply to David Binderman from comment #0)
> This bug is related to 53357.

Sorry. 63357.

[Bug c/108926] New: No warning for same expression in chain of | or & ?

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 108926
   Summary: No warning for same expression in chain of | or & ?
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Static analyser cppcheck has the ability to produce a style warning
for the same identifier used multiple times in the same expression.

Two examples are

linux-6.2/drivers/spi/spi-sn-f-ospi.c:614:31: style: Same expression
'SPI_TX_OCTAL' found multiple times in chain of '|' operators.
[duplicateExpression]

Source code is

ctlr->mode_bits = SPI_TX_DUAL | SPI_TX_QUAD | SPI_TX_OCTAL
| SPI_RX_DUAL | SPI_RX_QUAD | SPI_TX_OCTAL
| SPI_MODE_0 | SPI_MODE_1 | SPI_LSB_FIRST;

linux-6.2/tools/testing/selftests/powerpc/pmu/sampling_tests/mmcra_thresh_marked_sample_test.c:68:10:
style: Same expression '0x3' found multiple times in chain of '&' operators.
[duplicateExpression]

If gcc had this ability, then two kernel bugs would be found easily.
I will check binutils and glibc.

This bug is related to 53357.

[committed] libstdc++: Reorder dg-options before dg-do

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux. Pushed to trunk.

-- >8 --

The options need to be set first, so that -std=gnu++20 is used when
checking the c++20 effective target.

libstdc++-v3/ChangeLog:

* testsuite/std/format/arguments/lwg3810.cc: Move dg-options
before dg-do.
---
 libstdc++-v3/testsuite/std/format/arguments/lwg3810.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libstdc++-v3/testsuite/std/format/arguments/lwg3810.cc 
b/libstdc++-v3/testsuite/std/format/arguments/lwg3810.cc
index 60587a93d2c..9ccb654de1b 100644
--- a/libstdc++-v3/testsuite/std/format/arguments/lwg3810.cc
+++ b/libstdc++-v3/testsuite/std/format/arguments/lwg3810.cc
@@ -1,5 +1,5 @@
-// { dg-do compile { target c++20 } }
 // { dg-options "-std=gnu++20" }
+// { dg-do compile { target c++20 } }
 
 // LWG 3810. CTAD for std::basic_format_args
 
-- 
2.39.2

[Bug middle-end/108545] [13 Regression] ICE in install_var_field, at omp-low.cc:799 since r13-2665-g23baa717c991d77f

[burnus at gcc dot gnu.org via Gcc-bugs]

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #2 from Tobias Burnus  ---
 !$omp target enter data map(to: x%a)

The original tree has the expected:

#pragma omp target enter data
 map(to:x.a [len: 64])
 map(to:*(integer(kind=4)[0:] *) x.a.data [len: D.4282 * 4])
 map(always_pointer:(integer(kind=4)[0:] *) x.a.data [pointer assign, bias: 0])

The gimple dump adds a single 'struct':

#pragma omp target enter data
 map(struct:x [len: 1])
 map(to:x.a [len: 64])
map(struct:x [len: 1])
map(alloc:x.a.data [len: 8])
 map(to:MEM  [(integer(kind=4)[0:] *)_6] [len: _5])
 map(always_pointer:x.a.data [pointer assign, bias: 0])

The nonindented lines are new in GCC 13 (mainline) compared to GCC 12
and obviously wrong.

 * * *

Observations:
* OG12 is not affected but it also does not have the commit
  r13-2665-g23baa717c991d77f206a9358ce2c04960ccf9eea
  "struct sibling list gimplification extension and rework"

* Except for an added 'always', the dump does not change with my pending
  patch https://gcc.gnu.org/pipermail/gcc-patches/2023-February/612678.html
  "Fortran/OpenMP: Fix mapping of array descriptors and deferred-length
strings"

Re: [PATCH 2/2] Avoid default-initializing auto_vec storage, fix vec

[Richard Biener via Gcc-patches]

On Fri, 24 Feb 2023, Jakub Jelinek wrote:

> On Fri, Feb 24, 2023 at 02:47:39PM +0100, Richard Biener wrote:
> > * vec.h (vec::m_vecdata): Remove.
> > (vec::m_vecpfx): Align as T to avoid
> > changing alignment of vec and simplifying
> > address.
> > (vec::address): Compute as this + 1.
> > (vec::embedded_size): Use sizeof the
> > vector instead of the offset of the m_vecdata member.
> > (auto_vec::m_data): Turn storage into
> > uninitialized unsigned char.
> > (auto_vec::auto_vec): Allow allocation of one
> > stack member.  Initialize m_vec in a special way to
> > avoid later stringop overflow diagnostics.
> > * vec.cc (test_auto_alias): New.
> > (vec_cc_tests): Call it.
> > @@ -1559,8 +1560,14 @@ class auto_vec : public vec
> >  public:
> >auto_vec ()
> >{
> > -m_auto.embedded_init (MAX (N, 2), 0, 1);
> > -this->m_vec = _auto;
> > +m_auto.embedded_init (N, 0, 1);
> > +/* ???  Instead of initializing m_vec from _auto directly use an
> > +   expression that avoids refering to a specific member of 'this'
> > +   to derail the -Wstringop-overflow diagnostic code, avoiding
> > +   the impression that data accesses are supposed to be to the
> > +   m_auto memmber storage.  */
> 
> s/memmber/member/
> 
> > +size_t off = (char *) _auto - (char *) this;
> > +this->m_vec = (vec *) ((char *) this + off);
> >}
> >  
> >auto_vec (size_t s CXX_MEM_STAT_INFO)
> > @@ -1571,7 +1578,7 @@ public:
> > return;
> >}
> >  
> > -m_auto.embedded_init (MAX (N, 2), 0, 1);
> > +m_auto.embedded_init (N, 0, 1);
> >  this->m_vec = _auto;
> 
> Don't we need the above 2 lines here as well (perhaps with a shorter comment
> just referencing the earlier comment)?

I've noticed that as well and put it there now, it wasn't necessary
to get bootstrap working.

> Otherwise LGTM, thanks.

Thanks,
Richard.

[Bug tree-optimization/105329] [12/13 Regression] Bogus restrict warning when assigning 1-char string literal to std::string since r12-3347-g8af8abfbbace49e6

[wielkiegie at gmail dot com via Gcc-bugs]

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

Gustaw Smolarczyk  changed:

   What|Removed |Added

 CC||wielkiegie at gmail dot com

--- Comment #30 from Gustaw Smolarczyk  ---
I have encountered a similar bug, reproducer:


#include 

std::string foo()
{
return "_" + std::to_string(0);
}

Re: [PATCH 2/2] Avoid default-initializing auto_vec storage, fix vec

[Jakub Jelinek via Gcc-patches]

On Fri, Feb 24, 2023 at 02:47:39PM +0100, Richard Biener wrote:
>   * vec.h (vec::m_vecdata): Remove.
>   (vec::m_vecpfx): Align as T to avoid
>   changing alignment of vec and simplifying
>   address.
>   (vec::address): Compute as this + 1.
>   (vec::embedded_size): Use sizeof the
>   vector instead of the offset of the m_vecdata member.
>   (auto_vec::m_data): Turn storage into
>   uninitialized unsigned char.
>   (auto_vec::auto_vec): Allow allocation of one
>   stack member.  Initialize m_vec in a special way to
>   avoid later stringop overflow diagnostics.
>   * vec.cc (test_auto_alias): New.
>   (vec_cc_tests): Call it.
> @@ -1559,8 +1560,14 @@ class auto_vec : public vec
>  public:
>auto_vec ()
>{
> -m_auto.embedded_init (MAX (N, 2), 0, 1);
> -this->m_vec = _auto;
> +m_auto.embedded_init (N, 0, 1);
> +/* ???  Instead of initializing m_vec from _auto directly use an
> +   expression that avoids refering to a specific member of 'this'
> +   to derail the -Wstringop-overflow diagnostic code, avoiding
> +   the impression that data accesses are supposed to be to the
> +   m_auto memmber storage.  */

s/memmber/member/

> +size_t off = (char *) _auto - (char *) this;
> +this->m_vec = (vec *) ((char *) this + off);
>}
>  
>auto_vec (size_t s CXX_MEM_STAT_INFO)
> @@ -1571,7 +1578,7 @@ public:
>   return;
>}
>  
> -m_auto.embedded_init (MAX (N, 2), 0, 1);
> +m_auto.embedded_init (N, 0, 1);
>  this->m_vec = _auto;

Don't we need the above 2 lines here as well (perhaps with a shorter comment
just referencing the earlier comment)?

Otherwise LGTM, thanks.

Jakub

Re: [PATCH 1/2] Change vec<,,vl_embed>::m_vecdata refrences into address ()

[Jakub Jelinek via Gcc-patches]

On Fri, Feb 24, 2023 at 02:46:21PM +0100, Richard Biener wrote:
> As preparation to remove m_vecdata in the vl_embed vector this
> changes references to it into calls to address ().
> 
> As I was here it also fixes ::contains to avoid repeated bounds
> checking and the same issue in ::lower_bound which also suffers
> from unnecessary copying around values.
> 
>   * vec.h: Change m_vecdata references to address ().
>   * vec.h (vec::lower_bound): Adjust to
>   take a const reference to the object, use address to
>   access data.
>   (vec::contains): Use address to access data.
>   (vec::operator[]): Use address instead of
>   m_vecdata to access data.
>   (vec::iterate): Likewise.
>   (vec::copy): Likewise.
>   (vec::quick_push): Likewise.
>   (vec::pop): Likewise.
>   (vec::quick_insert): Likewise.
>   (vec::ordered_remove): Likewise.
>   (vec::unordered_remove): Likewise.
>   (vec::block_remove): Likewise.
>   (vec::address): Likewise.

Ok, thanks.

Jakub

Re: [v3][PATCH 2/2] Update documentation to clarify a GCC extension (PR77650)

[Qing Zhao via Gcc-patches]

> On Feb 23, 2023, at 7:56 PM, Joseph Myers  wrote:
> 
> On Thu, 23 Feb 2023, Qing Zhao via Gcc-patches wrote:
> 
>> But the following:
>> 
>> struct flex1  { int length1; char data1[]; };
>> struct flex2  { int length2; char data2[]; };
>> union union_flex { struct flex1 f1; struct flex2 f2; };  /* this is C 
>> standard.  */
>> 
>> struct out_flex { int n; union union_flex flex_data1;};  /* this is GNU 
>> extension.  */
>> 
>> Should add this item into the documentation?
> 
> "union that contains a structure with a flexible array member" is just 
> like "structure with a flexible array member".  I suppose the 
> documentation should try to make that clear, without repeating it too much 
> for every separate case.

Okay, thanks.

Qing
> 
> -- 
> Joseph S. Myers
> jos...@codesourcery.com

[PATCH 2/2] Avoid default-initializing auto_vec storage, fix vec

[Richard Biener via Gcc-patches]

The following avoids default-initializing auto_vec storage for
non-POD T since that's not what the allocated storage fallback
will do and it's also not expected for existing cases like

  auto_vec, 64> elts;

which exist to optimize the allocation.

It also fixes the array accesses done by vec to not
use its own m_vecdata member but instead access the container
provided storage via pointer arithmetic.

I've built the series with GCC 4.8 and clang 13 up to the stage1
target libs, a bootstrap and regtest on x86_64-unknown-linux-gnu
with GCC 12 was successful with the diagnostic pragma, I'm
currently re-bootstrapping and testing with a GCC 7 host compiler.

OK if that succeeds?

Thanks,
Richard.

* vec.h (vec::m_vecdata): Remove.
(vec::m_vecpfx): Align as T to avoid
changing alignment of vec and simplifying
address.
(vec::address): Compute as this + 1.
(vec::embedded_size): Use sizeof the
vector instead of the offset of the m_vecdata member.
(auto_vec::m_data): Turn storage into
uninitialized unsigned char.
(auto_vec::auto_vec): Allow allocation of one
stack member.  Initialize m_vec in a special way to
avoid later stringop overflow diagnostics.
* vec.cc (test_auto_alias): New.
(vec_cc_tests): Call it.
---
 gcc/vec.cc | 17 +
 gcc/vec.h  | 27 +--
 2 files changed, 34 insertions(+), 10 deletions(-)

diff --git a/gcc/vec.cc b/gcc/vec.cc
index 511e6dff50d..2128fb1 100644
--- a/gcc/vec.cc
+++ b/gcc/vec.cc
@@ -568,6 +568,22 @@ test_auto_delete_vec ()
   ASSERT_EQ (dtor_count, 2);
 }
 
+/* Verify accesses to m_vecdata are done indirectly.  */
+
+static void
+test_auto_alias ()
+{
+  volatile int i = 1;
+  auto_vec v;
+  v.quick_grow (2);
+  v[0] = 1;
+  v[1] = 2;
+  int val;
+  for (int ix = i; v.iterate (ix, ); ix++)
+ASSERT_EQ (val, 2);
+  ASSERT_EQ (val, 0);
+}
+
 /* Run all of the selftests within this file.  */
 
 void
@@ -587,6 +603,7 @@ vec_cc_tests ()
   test_qsort ();
   test_reverse ();
   test_auto_delete_vec ();
+  test_auto_alias ();
 }
 
 } // namespace selftest
diff --git a/gcc/vec.h b/gcc/vec.h
index 2b36f065234..3b03bfe076a 100644
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -586,8 +586,9 @@ public:
   unsigned allocated (void) const { return m_vecpfx.m_alloc; }
   unsigned length (void) const { return m_vecpfx.m_num; }
   bool is_empty (void) const { return m_vecpfx.m_num == 0; }
-  T *address (void) { return m_vecdata; }
-  const T *address (void) const { return m_vecdata; }
+  T *address (void) { return reinterpret_cast  (this + 1); }
+  const T *address (void) const
+{ return reinterpret_cast  (this + 1); }
   T *begin () { return address (); }
   const T *begin () const { return address (); }
   T *end () { return address () + length (); }
@@ -629,10 +630,10 @@ public:
   friend struct va_gc_atomic;
   friend struct va_heap;
 
-  /* FIXME - These fields should be private, but we need to cater to
+  /* FIXME - This field should be private, but we need to cater to
 compilers that have stricter notions of PODness for types.  */
-  vec_prefix m_vecpfx;
-  T m_vecdata[1];
+  /* Align m_vecpfx to simplify address ().  */
+  alignas (T) alignas (vec_prefix) vec_prefix m_vecpfx;
 };
 
 
@@ -1315,7 +1316,7 @@ vec::embedded_size (unsigned alloc)
vec, vec_embedded>::type vec_stdlayout;
   static_assert (sizeof (vec_stdlayout) == sizeof (vec), "");
   static_assert (alignof (vec_stdlayout) == alignof (vec), "");
-  return offsetof (vec_stdlayout, m_vecdata) + alloc * sizeof (T);
+  return sizeof (vec_stdlayout) + alloc * sizeof (T);
 }
 
 
@@ -1559,8 +1560,14 @@ class auto_vec : public vec
 public:
   auto_vec ()
   {
-m_auto.embedded_init (MAX (N, 2), 0, 1);
-this->m_vec = _auto;
+m_auto.embedded_init (N, 0, 1);
+/* ???  Instead of initializing m_vec from _auto directly use an
+   expression that avoids refering to a specific member of 'this'
+   to derail the -Wstringop-overflow diagnostic code, avoiding
+   the impression that data accesses are supposed to be to the
+   m_auto memmber storage.  */
+size_t off = (char *) _auto - (char *) this;
+this->m_vec = (vec *) ((char *) this + off);
   }
 
   auto_vec (size_t s CXX_MEM_STAT_INFO)
@@ -1571,7 +1578,7 @@ public:
return;
   }
 
-m_auto.embedded_init (MAX (N, 2), 0, 1);
+m_auto.embedded_init (N, 0, 1);
 this->m_vec = _auto;
   }
 
@@ -1590,7 +1597,7 @@ public:
 
 private:
   vec m_auto;
-  T m_data[MAX (N - 1, 1)];
+  unsigned char m_data[sizeof (T) * N];
 };
 
 /* auto_vec is a sub class of vec whose storage is released when it is
-- 
2.35.3

[PATCH 1/2] Change vec<, , vl_embed>::m_vecdata refrences into address ()

[Richard Biener via Gcc-patches]

As preparation to remove m_vecdata in the vl_embed vector this
changes references to it into calls to address ().

As I was here it also fixes ::contains to avoid repeated bounds
checking and the same issue in ::lower_bound which also suffers
from unnecessary copying around values.

* vec.h: Change m_vecdata references to address ().
* vec.h (vec::lower_bound): Adjust to
take a const reference to the object, use address to
access data.
(vec::contains): Use address to access data.
(vec::operator[]): Use address instead of
m_vecdata to access data.
(vec::iterate): Likewise.
(vec::copy): Likewise.
(vec::quick_push): Likewise.
(vec::pop): Likewise.
(vec::quick_insert): Likewise.
(vec::ordered_remove): Likewise.
(vec::unordered_remove): Likewise.
(vec::block_remove): Likewise.
(vec::address): Likewise.
---
 gcc/vec.h | 44 +---
 1 file changed, 25 insertions(+), 19 deletions(-)

diff --git a/gcc/vec.h b/gcc/vec.h
index a536b68732d..2b36f065234 100644
--- a/gcc/vec.h
+++ b/gcc/vec.h
@@ -611,10 +611,10 @@ public:
   void qsort (int (*) (const void *, const void *));
   void sort (int (*) (const void *, const void *, void *), void *);
   void stablesort (int (*) (const void *, const void *, void *), void *);
-  T *bsearch (const void *key, int (*compar)(const void *, const void *));
+  T *bsearch (const void *key, int (*compar) (const void *, const void *));
   T *bsearch (const void *key,
  int (*compar)(const void *, const void *, void *), void *);
-  unsigned lower_bound (T, bool (*)(const T &, const T &)) const;
+  unsigned lower_bound (const T &, bool (*) (const T &, const T &)) const;
   bool contains (const T ) const;
   static size_t embedded_size (unsigned);
   void embedded_init (unsigned, unsigned = 0, unsigned = 0);
@@ -879,7 +879,7 @@ inline const T &
 vec::operator[] (unsigned ix) const
 {
   gcc_checking_assert (ix < m_vecpfx.m_num);
-  return m_vecdata[ix];
+  return address ()[ix];
 }
 
 template
@@ -887,7 +887,7 @@ inline T &
 vec::operator[] (unsigned ix)
 {
   gcc_checking_assert (ix < m_vecpfx.m_num);
-  return m_vecdata[ix];
+  return address ()[ix];
 }
 
 
@@ -929,7 +929,7 @@ vec::iterate (unsigned ix, T *ptr) const
 {
   if (ix < m_vecpfx.m_num)
 {
-  *ptr = m_vecdata[ix];
+  *ptr = address ()[ix];
   return true;
 }
   else
@@ -955,7 +955,7 @@ vec::iterate (unsigned ix, T **ptr) const
 {
   if (ix < m_vecpfx.m_num)
 {
-  *ptr = CONST_CAST (T *, _vecdata[ix]);
+  *ptr = CONST_CAST (T *,  ()[ix]);
   return true;
 }
   else
@@ -978,7 +978,7 @@ vec::copy (ALONE_MEM_STAT_DECL) const
 {
   vec_alloc (new_vec, len PASS_MEM_STAT);
   new_vec->embedded_init (len, len);
-  vec_copy_construct (new_vec->address (), m_vecdata, len);
+  vec_copy_construct (new_vec->address (), address (), len);
 }
   return new_vec;
 }
@@ -1018,7 +1018,7 @@ inline T *
 vec::quick_push (const T )
 {
   gcc_checking_assert (space (1));
-  T *slot = _vecdata[m_vecpfx.m_num++];
+  T *slot =  ()[m_vecpfx.m_num++];
   *slot = obj;
   return slot;
 }
@@ -1031,7 +1031,7 @@ inline T &
 vec::pop (void)
 {
   gcc_checking_assert (length () > 0);
-  return m_vecdata[--m_vecpfx.m_num];
+  return address ()[--m_vecpfx.m_num];
 }
 
 
@@ -1056,7 +1056,7 @@ vec::quick_insert (unsigned ix, const T 
)
 {
   gcc_checking_assert (length () < allocated ());
   gcc_checking_assert (ix <= length ());
-  T *slot = _vecdata[ix];
+  T *slot =  ()[ix];
   memmove (slot + 1, slot, (m_vecpfx.m_num++ - ix) * sizeof (T));
   *slot = obj;
 }
@@ -1071,7 +1071,7 @@ inline void
 vec::ordered_remove (unsigned ix)
 {
   gcc_checking_assert (ix < length ());
-  T *slot = _vecdata[ix];
+  T *slot =  ()[ix];
   memmove (slot, slot + 1, (--m_vecpfx.m_num - ix) * sizeof (T));
 }
 
@@ -1118,7 +1118,8 @@ inline void
 vec::unordered_remove (unsigned ix)
 {
   gcc_checking_assert (ix < length ());
-  m_vecdata[ix] = m_vecdata[--m_vecpfx.m_num];
+  T *p = address ();
+  p[ix] = p[--m_vecpfx.m_num];
 }
 
 
@@ -1130,7 +1131,7 @@ inline void
 vec::block_remove (unsigned ix, unsigned len)
 {
   gcc_checking_assert (ix + len <= length ());
-  T *slot = _vecdata[ix];
+  T *slot =  ()[ix];
   m_vecpfx.m_num -= len;
   memmove (slot, slot + len, (m_vecpfx.m_num - ix) * sizeof (T));
 }
@@ -1248,9 +1249,13 @@ inline bool
 vec::contains (const T ) const
 {
   unsigned int len = length ();
+  const T *p = address ();
   for (unsigned int i = 0; i < len; i++)
-if ((*this)[i] == search)
-  return true;
+{
+  const T *slot = [i];
+  if (*slot == search)
+   return true;
+}
 
   return false;
 }
@@ -1262,7 +1267,8 @@ vec::contains (const T ) const
 
 template
 unsigned
-vec::lower_bound (T obj, bool (*lessthan)(const T &, const T 
&))
+vec::lower_bound (const T ,
+ bool 

Re: [PATCH] cgraphclones: Don't share DECL_ARGUMENTS between thunk and its artificial thunk [PR108854]

[Jan Hubicka via Gcc-patches]

> Hi!
> 
> The following testcase ICEs on x86_64-linux with -m32.  The problem is
> we create an artificial thunk and because of -fPIC, ia32 and thunk
> destination which doesn't bind locally can't use a mi thunk.
> The ICE is because during expansion to RTL we see SSA_NAME for a PARM_DECL,
> but the PARM_DECL doesn't have DECL_CONTEXT of the current function.
> This is because duplicate_thunk_for_node creates a new DECL_ARGUMENTS chain
> only if some arguments need modification.
> 
> The following patch fixes it by copying the DECL_ARGUMENTS list even if
> the arguments can stay as is, to update DECL_CONTEXT on them.  While for
> mi thunks it doesn't really matter because we don't use those arguments
> in any way, for other thunks it is important.
> 
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
> 
> 2023-02-23  Jakub Jelinek  
> 
>   PR middle-end/108854
>   * cgraphclones.cc (duplicate_thunk_for_node): If no parameter
>   changes are needed, copy at least DECL_ARGUMENTS PARM_DECL
>   nodes and adjust their DECL_CONTEXT.
> 
>   * g++.dg/opt/pr108854.C: New test.
> 
> --- gcc/cgraphclones.cc.jj2023-02-22 20:50:27.417519830 +0100
> +++ gcc/cgraphclones.cc   2023-02-23 17:12:59.875133883 +0100
> @@ -218,7 +218,17 @@ duplicate_thunk_for_node (cgraph_node *t
>body_adj.modify_formal_parameters ();
>  }
>else
> -new_decl = copy_node (thunk->decl);
> +{
> +  new_decl = copy_node (thunk->decl);
> +  for (tree *arg = _ARGUMENTS (new_decl);
> +*arg; arg = _CHAIN (*arg))
> + {
> +   tree next = DECL_CHAIN (*arg);
> +   *arg = copy_node (*arg);
> +   DECL_CONTEXT (*arg) = new_decl;
> +   DECL_CHAIN (*arg) = next;

This makes sense to me. I wonder if we don't want to update abstract
origin too like we do in tree-inline?
Maybe it is unecessary since we don't do debug info for thunks

Jan