Re: [PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

[Xi Ruoyao via Gcc-patches]

On Tue, 2023-02-21 at 15:20 +0800, Lulu Cheng wrote:
> Like la264 only has 40 effective bits of virtual address space.

I'm OK with the change.  But the VA length is configurable building the
kernel.  Is there any specific reason LA264 has to use the 40-bit
configuration, or should we reword the commit message like "for
supporting the configuration with less page table level or smaller page
size"?

> When TRY_EMPTY_VM_SPACE is set to 0x80, it just exceeds
> the range of 40-bit virtual address, causing the mmap mapping
> to fail, thus causing the pch function to fail. To be compatible
> with this situation set the macro to 0x10.
> 
> gcc/ChangeLog:
> 
> * config/host-linux.cc (TRY_EMPTY_VM_SPACE): Modify the value
> of
> the macro to 0x10.
> ---
>  gcc/config/host-linux.cc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/gcc/config/host-linux.cc b/gcc/config/host-linux.cc
> index a891651a7b6..d1aa7ab28ca 100644
> --- a/gcc/config/host-linux.cc
> +++ b/gcc/config/host-linux.cc
> @@ -99,7 +99,7 @@
>  #elif defined(__riscv) && defined (__LP64__)
>  # define TRY_EMPTY_VM_SPACE0x10
>  #elif defined(__loongarch__) && defined(__LP64__)
> -# define TRY_EMPTY_VM_SPACE0x80
> +# define TRY_EMPTY_VM_SPACE0x10
>  #else
>  # define TRY_EMPTY_VM_SPACE0
>  #endif

-- 
Xi Ruoyao 
School of Aerospace Science and Technology, Xidian University

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #19 from rguenther at suse dot de  ---
On Tue, 21 Feb 2023, ishikawa at yk dot rim.or.jp wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107931
> 
> --- Comment #18 from ishikawa,chiaki  ---
> I reported the issue to the following github for a very fast hashing function
> library.
> https://github.com/Cyan4973/xxHash/issues/800
> 
> From the discussion there, I figured -Og does not define __NO_INLINE__ as -O0
> would define it.
> Well the discussion refers to the problem mentioned earlier about the same
> issue.
> In there, the following mentions something about __NO_INLINE__.
> https://github.com/Cyan4973/xxHash/pull/720#issuecomment-1414481935
> 
> 
> So I settled on manually define __NO_INLINE__ on the compiler command line.
> This makes it the compilation succeed.
> (The code seems to be written in such a manner that always_inline is not 
> declared for the two functions if __NO_INLINE__ is defiend.)
> 
> It would be great if -Og can define macro __NO_INLINE__ as -O0 does.
> Oh wait, -fno-inline has the same effect(?).

-Og does inline small functions so defining __NO_INLINE__ would not
be correct

[Bug target/108851] gcc -pie generates unwanted PE export table

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

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

--- Comment #1 from Andrew Pinski  ---
I doubt GCC has control over this. I suspect the issue is in the binutils side
...

[Bug ipa/107931] [12/13 Regression] -Og causes always_inline to fail since r12-6677-gc952126870c92cf2

[ishikawa at yk dot rim.or.jp via Gcc-bugs]

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

--- Comment #18 from ishikawa,chiaki  ---
I reported the issue to the following github for a very fast hashing function
library.
https://github.com/Cyan4973/xxHash/issues/800

>From the discussion there, I figured -Og does not define __NO_INLINE__ as -O0
would define it.
Well the discussion refers to the problem mentioned earlier about the same
issue.
In there, the following mentions something about __NO_INLINE__.
https://github.com/Cyan4973/xxHash/pull/720#issuecomment-1414481935


So I settled on manually define __NO_INLINE__ on the compiler command line.
This makes it the compilation succeed.
(The code seems to be written in such a manner that always_inline is not 
declared for the two functions if __NO_INLINE__ is defiend.)

It would be great if -Og can define macro __NO_INLINE__ as -O0 does.
Oh wait, -fno-inline has the same effect(?).

Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types

[Richard Biener via Gcc-patches]

On Mon, Feb 20, 2023 at 5:23 PM Tobias Burnus  wrote:
>
> Hi Richard, hi all,
>
> On 20.02.23 13:46, Richard Biener wrote:
> > +  /* TODO: A more middle-end friendly alternative would be to use 
> > NULL_TREE
> > +as upper bound and store the value, e.g. as GFC_DECL_STRING_LEN.
> > +Caveat: this requires some cleanup throughout the code to 
> > consistently
> > +use some wrapper function.  */
> > +  gcc_assert (TREE_CODE (TYPE_SIZE_UNIT (type)) == SAVE_EXPR);
> > +  tree tmp = TREE_TYPE (TYPE_SIZE (eltype));
> >
> > ...
> >
> > you are probably breaking type sharing here.  You could use
> > build_array_type_1 and pass false for 'shared' to get around that.  Note
> > that there's also canonical type building done in case 'eltype' is not
> > canonical itself.
>
> My feeling is that this is already somewhat broken. Currently, there
> is one type per decl as each has its own artificial length variable.
> I have no idea how this will be handled in the ME in terms of alias
> analysis. And whether shared=false makes sense here and what effect
> is has. (Probably yes.)
>
> In principle,
>integer(kind=8) .str., .str2;
>character(kind=1)[1:.str] * str;
>character(kind=1)[1:.str2] * str2;
> have the same type and iff .str == .str at runtime, they can alias.
> Example:
>str2 = str;
>.str2 = .str;
>
> I have no idea how the type analysis currently works (with or without 
> SAVE_EXPR)
> nor what effect shared=false has in this case.

alias analysis for array types looks only at the element type

> > The solution to the actual problem is a hack - you are relying on
> > re-evaluation of TYPE_SIZE, and for that, only from within accesses
> > from inside the frontend?
>
> I think this mostly helps with access inside the FE of the type 'size =
> TYPE_SIZE_UNIT(type)', which is used surprisingly often and is often
> directly evaluated (i.e. assigned to a temporary).

that's what I thought

> > Since gimplification will produce the result into a single temporary again, 
> > re-storing the "breakage".
> > So, does it_really_  fix things?
>
> It does seem to fix cases which do  'size = TYPE_SIZE_UNIT (type);' in
> the front end and then uses this size expression. Thus, there are fixed.
> However, there are many cases where things go wrong - with and without
> the patch. I keep discovering more and more :-(

I guess test coverage isn't too great with this feature then ;)

> * * *
>
> I still think that the proper way is to have NULL_TREE as upper value
> would be better in several ways, except that there is (too) much code

Yep.

> which relies on TYPE_UNIT_SIZE to work. (There are 117 occurrences).
> Additionally, there is more code doing assumptions in this area.
>
> Thus, the question is whether it makes sense as hackish partial solution
> or whether it should remain in the current broken stage until it is
> fixed properly.

I wonder if it makes more sense to individually fix the places using
TYPE_UNIT_SIZE in a wrong way?  You'd also get only "partial"
fixes, but at least those will be true and good?

Otherwise I defer to frontend maintainers if they agree to put in
a (partially working) hack like this.

Richard.

> Tobias,
>
> who would like to have more time for fixing such issues.
>
> -
> 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

[PATCH] LoongArch: Change the value of macro TRY_EMPTY_VM_SPACE from 0x8000000000 to 0x1000000000.

[Lulu Cheng]

Like la264 only has 40 effective bits of virtual address space.
When TRY_EMPTY_VM_SPACE is set to 0x80, it just exceeds
the range of 40-bit virtual address, causing the mmap mapping
to fail, thus causing the pch function to fail. To be compatible
with this situation set the macro to 0x10.

gcc/ChangeLog:

* config/host-linux.cc (TRY_EMPTY_VM_SPACE): Modify the value of
the macro to 0x10.
---
 gcc/config/host-linux.cc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/gcc/config/host-linux.cc b/gcc/config/host-linux.cc
index a891651a7b6..d1aa7ab28ca 100644
--- a/gcc/config/host-linux.cc
+++ b/gcc/config/host-linux.cc
@@ -99,7 +99,7 @@
 #elif defined(__riscv) && defined (__LP64__)
 # define TRY_EMPTY_VM_SPACE0x10
 #elif defined(__loongarch__) && defined(__LP64__)
-# define TRY_EMPTY_VM_SPACE0x80
+# define TRY_EMPTY_VM_SPACE0x10
 #else
 # define TRY_EMPTY_VM_SPACE0
 #endif
-- 
2.31.1

[Bug tree-optimization/108868] [13 Regression] ocaml-dune miscompilation on i686 since r13-5965

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

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

--- Comment #5 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #4)
> I think the reason why it doesn't work is clear, call_can_make_abnormal_goto
> on the vfork call is false, because it is leaf (and that is how glibc
> declares vfork BTW) and ctrl_altering flag is initialized by
> gimple_call_initialize_ctrl_altering based on that or if it is noreturn etc.
> (nothing applies).
> So, I think as discussed in another PR, I think we really should make if not
> call_can_make_abnormal_goto at least gimple_call_initialize_ctrl_altering be
> true for
> RETURNS_TWICE calls.

I think I'm going to revert r13-5965 since neither setjmp nor [v]fork alter
control flow.  They receive additional control flow.

I'm not sure why we have abnormal edges into fork(), fork simply returns
twice but you can't longjmp to it.  It's probably the same reason we
have them on setjmp - to avoid code motion across the call, though as
you can't jump to it I wonder if that's necessary there.

r13-5965 has the side-effect of removing the RTL side-effects as well,
though that's probably only ->calls_setjmp, forks never had REG_SETJMP
on them?

That said, if we choose to set ctrl-altering for setjmp + fork (see
PR108855 for the problem with that), we need to do that explicitely
rather than relying on call_can_make_abnormal_goto as you say.

I still prefer to revert the offending revision and see how to handle
the indirect -> direct transform better (in the end reverting the assert
in DCE will solve these ICEs for us and get us back to previous behavior)

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

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

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

--- Comment #7 from Andrew Pinski  ---
I suspect std::move has the same issue too. The ability to use memmove with
trivial copyable subobjects ...

Re: [PATCH] Fortran: improve checking of character length specification [PR96025]

[Thomas Koenig via Gcc-patches]

Hi Harald,


the attached patch fixes an ICE on invalid (non-integer)
specification expressions for character length in function
declarations.  It appears that the error handling was
already in place (mostly) and we need to essentially
prevent run-on errors.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

As a very minor matter of style, you might want to write

  function_result_typed = check_function_result_typed ();

instead of

  if (check_function_result_typed ())
function_result_typed = true;

OK either way.


The PR is marked as a 10/11/12/13 regression, so I would
like to backport this as far as it seems reasonable.


Also OK.

Thanks for the patch!

Best regards

Thomas

RE: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

[Li, Pan2 via Gcc-patches]

Hi,

Kindly reminder for this PR.

Pan

-Original Message-
From: Li, Pan2 
Sent: Friday, February 17, 2023 4:39 PM
To: richard.sandif...@arm.com; juzhe.zhong 
Cc: incarnation.p@outlook.com; gcc-patches@gcc.gnu.org; 
kito.ch...@sifive.com; Richard Biener 
Subject: RE: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

Cool, thank you!

Hi Richard S,

Could you please help to do me a fever for this change when you free? Thank you!

Pan

-Original Message-
From: Richard Biener 
Sent: Friday, February 17, 2023 3:36 PM
To: juzhe.zhong 
Cc: incarnation.p@outlook.com; gcc-patches@gcc.gnu.org; 
kito.ch...@sifive.com; Li, Pan2 ; richard.sandif...@arm.com
Subject: Re: [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment

On Thu, 16 Feb 2023, juzhe.zhong wrote:

> Thanks for the great work to fix this issue for rvv.Hi，richard. This 
> is the patch to differentiate mask mode of same bytesize. Adjust the 
> precision correctly according to rvv isa. Would you mind helping us 
> with this patch ？
> Since it‘s very important for rvv support in gcc

If adjusting the precision works fine then I suppose the patch looks 
reasonable.  I'll defer to Richard S. though since he's the one knowing the 
mode stuff better.  I'd have integrated the precision adjustment with the 
ADJUST_NITER hook since that is also documented to adjust the precision btw.

Richard.

> Thanks.
>  Replied Message 
> From
> incarnation.p@outlook.com
> Date
> 02/16/2023 23:12
> To
> gcc-patches@gcc.gnu.org
> Cc
> juzhe.zh...@rivai.ai,
> kito.ch...@sifive.com,
> rguent...@suse.de,
> pan2...@intel.com
> Subject
> [PATCH] RISC-V: Bugfix for rvv bool mode precision adjustment
> From: Pan Li 
> 
>    Fix the bug of the rvv bool mode precision with the adjustment.
>    The bits size of vbool*_t will be adjusted to
>    [1, 2, 4, 8, 16, 32, 64] according to the rvv spec 1.0 isa. The
>    adjusted mode precison of vbool*_t will help underlying pass to
>    make the right decision for both the correctness and optimization.
> 
>    Given below sample code:
>    void test_1(int8_t * restrict in, int8_t * restrict out)
>    {
>      vbool8_t v2 = *(vbool8_t*)in;
>      vbool16_t v5 = *(vbool16_t*)in;
>      *(vbool16_t*)(out + 200) = v5;
>      *(vbool8_t*)(out + 100) = v2;
>    }
> 
>    Before the precision adjustment:
>    addi    a4,a1,100
>    vsetvli a5,zero,e8,m1,ta,ma
>    addi    a1,a1,200
>    vlm.v   v24,0(a0)
>    vsm.v   v24,0(a4)
>    // Need one vsetvli and vlm.v for correctness here.
>    vsm.v   v24,0(a1)
> 
>    After the precision adjustment:
>    csrr    t0,vlenb
>    slli    t1,t0,1
>    csrr    a3,vlenb
>    sub sp,sp,t1
>    slli    a4,a3,1
>    add a4,a4,sp
>    sub a3,a4,a3
>    vsetvli a5,zero,e8,m1,ta,ma
>    addi    a2,a1,200
>    vlm.v   v24,0(a0)
>    vsm.v   v24,0(a3)
>    addi    a1,a1,100
>    vsetvli a4,zero,e8,mf2,ta,ma
>    csrr    t0,vlenb
>    vlm.v   v25,0(a3)
>    vsm.v   v25,0(a2)
>    slli    t1,t0,1
>    vsetvli a5,zero,e8,m1,ta,ma
>    vsm.v   v24,0(a1)
>    add sp,sp,t1
>    jr  ra
> 
>    However, there may be some optimization opportunates after
>    the mode precision adjustment. It can be token care of in
>    the RISC-V backend in the underlying separted PR(s).
> 
>    PR 108185
>    PR 108654
> 
> gcc/ChangeLog:
> 
>    * config/riscv/riscv-modes.def (ADJUST_PRECISION):
>    * config/riscv/riscv.cc (riscv_v_adjust_precision):
>    * config/riscv/riscv.h (riscv_v_adjust_precision):
>    * genmodes.cc (ADJUST_PRECISION):
>    (emit_mode_adjustments):
> 
> gcc/testsuite/ChangeLog:
> 
>    * gcc.target/riscv/pr108185-1.c: New test.
>    * gcc.target/riscv/pr108185-2.c: New test.
>    * gcc.target/riscv/pr108185-3.c: New test.
>    * gcc.target/riscv/pr108185-4.c: New test.
>    * gcc.target/riscv/pr108185-5.c: New test.
>    * gcc.target/riscv/pr108185-6.c: New test.
>    * gcc.target/riscv/pr108185-7.c: New test.
>    * gcc.target/riscv/pr108185-8.c: New test.
> 
> Signed-off-by: Pan Li 
> ---
> gcc/config/riscv/riscv-modes.def    |  8 +++ 
> gcc/config/riscv/riscv.cc   | 12  
> gcc/config/riscv/riscv.h    |  1 + gcc/genmodes.cc
> | 25 ++- gcc/testsuite/gcc.target/riscv/pr108185-1.c | 68
> ++ gcc/testsuite/gcc.target/riscv/pr108185-2.c | 68 
> ++ gcc/testsuite/gcc.target/riscv/pr108185-3.c | 68 
> ++ gcc/testsuite/gcc.target/riscv/pr108185-4.c | 68 
> ++ gcc/testsuite/gcc.target/riscv/pr108185-5.c | 68 
> ++ gcc/testsuite/gcc.target/riscv/pr108185-6.c | 68 
> ++ gcc/testsuite/gcc.target/riscv/pr108185-7.c | 68 
> ++ gcc/testsuite/gcc.target/riscv/pr108185-8.c | 77
> +
> 12 files changed, 598 insertions(+), 1 deletion(-) create mode 100644 
> gcc/testsuite/gcc.target/riscv/pr108185-1.c
> create mode 100644 gcc/testsuite/gcc.target/riscv/pr108185-2.c
> create mode 

[PATCH] MIPS: Account for LWL/LWR in store_by_pieces_p.

[Xin Liu]

From: Matthew Fortune 

---
 gcc/config/mips/mips.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/gcc/config/mips/mips.cc b/gcc/config/mips/mips.cc
index 590c311e98c..bb9f4e19c22 100644
--- a/gcc/config/mips/mips.cc
+++ b/gcc/config/mips/mips.cc
@@ -8853,7 +8853,7 @@ mips_store_by_pieces_p (unsigned HOST_WIDE_INT size, 
unsigned int align)
  LW/SWL/SWR sequence.  This is often better than the 4 LIs and
  4 SBs that we would generate when storing by pieces.  */
   if (align <= BITS_PER_UNIT)
-return size < 4;
+return size < 4 || !ISA_HAS_LWL_LWR;
 
   /* If the data is 2-byte aligned, then:
 
@@ -,7 +,9 @@ mips_store_by_pieces_p (unsigned HOST_WIDE_INT size, 
unsigned int align)
  (c4) A block move of 8 bytes can use two LW/SW sequences or a single
  LD/SD sequence, and in these cases we've traditionally preferred
  the memory copy over the more bulky constant moves.  */
-  return size < 8;
+  return (size < 8
+ || (align < 4 * BITS_PER_UNIT
+ && !ISA_HAS_LWL_LWR));
 }
 
 /* Emit straight-line code to move LENGTH bytes from SRC to DEST.
-- 
2.30.2

[PATCH] Testsuite: Disable micromips for MSA tests

[Xin Liu]

From: Matthew Fortune 

---
 gcc/testsuite/gcc.target/mips/mips.exp | 1 +
 1 file changed, 1 insertion(+)

diff --git a/gcc/testsuite/gcc.target/mips/mips.exp 
b/gcc/testsuite/gcc.target/mips/mips.exp
index 81e19f39853..bf32fe0c93f 100644
--- a/gcc/testsuite/gcc.target/mips/mips.exp
+++ b/gcc/testsuite/gcc.target/mips/mips.exp
@@ -1463,6 +1463,7 @@ proc mips-dg-options { args } {
 mips_option_dependency options "-msoft-float" "-mno-paired-single"
 mips_option_dependency options "-mno-paired-single" "-mno-mips3d"
+mips_option_dependency options "-mmsa" "-mno-micromips"
 mips_option_dependency options "-mmsa" "-mno-mips16"
 
 # If the test requires an unsupported option, change run tests
 # to link tests.
-- 
2.30.2

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

[de34 at live dot cn via Gcc-bugs]

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

--- Comment #6 from Jiang An  ---
> For example, assuming both sizeof(B) and sizeof(D) are 8, which means the last
> 2 bytes of B are padding (true for common implementations on Itanium ABI):

Oh, I forgot the strange design caused by CWG43 - this requires some
non-C++98-POD mechanism for B (e.g. an explicitly default default
constructor)...

[Bug tree-optimization/108860] New (since gcc 12) false positive null-dereference in vector.resize

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Somehow GCC thinks __len can be 0 here, and so __new_start can be null:

  const size_type __len =
_M_check_len(__n, "vector::_M_default_append");
  pointer __new_start(this->_M_allocate(__len));

Re: MicroBlaze symver attribute support

[Michael Eager]

On 2/20/23 06:54, Joel Sherrill wrote:



On Mon, Feb 20, 2023 at 7:56 AM Vincent Fazio via Gcc > wrote:


Michael, all,

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

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


If I understand correctly, since the GCC MicroBlaze targets generate ELF
images, it would seem there's no technical reason why `__attribute__
((symver ...))` cannot be supported?

The issue seems to be that the MicroBlaze targets in config.gcc do not
include elfos.h
https://github.com/gcc-mirror/gcc/blob/master/gcc/config.gcc#L2369


Which defines `ASM_OUTPUT_SYMVER_DIRECTIVE`
https://github.com/gcc-mirror/gcc/blob/master/gcc/config/elfos.h#L259 


Which is necessary for
https://github.com/gcc-mirror/gcc/blob/master/gcc/varasm.cc#L6260


Changing the targets to include elfos.h leads to a number of
conflicts with
the target specific header (config/microblaze/microblaze.h).

Should `ASM_OUTPUT_SYMVER_DIRECTIVE` be copied into
config/microblaze/microblaze.h or should the MicroBlaze targets and
header
be reworked to support elfos.h?


IMO reworked to include elfos.h. During the RTEMS port, we noticed that
some quirks on the microblaze gcc because it isn't using elfos.h. This 
likely

will mean it will be updated as a side-effect of normal GCC maintenance
instead of being an odd singleton which doesn't share.


I'm asking because I've seen a number of projects run into this
issue (xz,
elfutils, libfuse, libkcapi, cryptsetup).


And RTEMS.

--joel



Joel -- do you have a patch to add elfos.h to MicroBlaze?

--
Michael Eager

[Bug libstdc++/98449] [DR 3343] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

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

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Vinícius dos Santos Oliveira from comment #3)
> LLVM's libcxx already applied this 1-line patchset:
> https://github.com/llvm/llvm-project/commit/
> 64fc3cd55d586498dd21c5b3cfaa755793913772
> 
> Can we have the same here on GCC side (I've already submitted the patch
> earlier).

As you can obviously see from the libcxx commit, it's not a one-line change
because there should really be a test for it. Your patch is missing that.

I'll try to get the committee to make progress on the issue, but if you'd
waited for a reply before opening a pointless duplicate then I would have said
what Andrew said: we're waiting for the committee to approve the change before
changing our code.

Re: [PATCH] xtensa: Enforce return address saving when -Og is specified

[Max Filippov via Gcc-patches]

On Fri, Feb 17, 2023 at 8:54 PM Takayuki 'January June' Suwa
 wrote:
>
> Leaf function often omits saving its return address to the stack slot,
> and this feature often makes debugging very confusing, especially for
> stack dump analysis.
>
> gcc/ChangeLog:
>
> * config/xtensa/xtensa.cc (xtensa_call_save_reg): Change to return
> true if register A0 (return address register) when -Og is specified.
> ---
>  gcc/config/xtensa/xtensa.cc | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)

Regtested for target=xtensa-linux-uclibc, no new regressions.
Committed to master.

-- 
Thanks.
-- Max

[Bug c++/108848] [10/11/12/13 Regression] template keyword incorreclty required to access template class static member of non-dependent expression using member syntax in dependent context

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
Summary|template keyword|[10/11/12/13 Regression]
   |incorreclty required to |template keyword
   |access template class   |incorreclty required to
   |static member of|access template class
   |non-dependent expression|static member of
   |using member syntax in  |non-dependent expression
   |dependent context   |using member syntax in
   ||dependent context
  Known to work||5.1.0
  Known to fail||10.4.0, 11.3.0, 12.2.0,
   ||13.0, 5.2.0
   Target Milestone|--- |10.5

--- Comment #2 from Patrick Palka  ---
Testcase exhibiting a regression relative to GCC 5.1:

template 
struct tag_t {
template 
static const Sig* smbr();
};

template 
constexpr tag_t tag {};

template
void f()
{
  auto t = tag.smbr();
}

Started with r226642.

Re: [PATCH] rs6000: mark tieable between INT and FLOAT

[Jiufu Guo via Gcc-patches]

Hi,

Gently Ping:
https://gcc.gnu.org/pipermail/gcc-patches/2023-January/609504.html

BR,
Jeff (Jiufu)


Jiufu Guo  writes:

> Hi,
>
> During discussing/review patches in maillist, we find more modes are
> tieable, e.g. DI<->DF.  With some discussion, I drafted this patch
> to mark more tieable modes.
>
> Bootstrap and regtest pass on ppc64{,le}.
> Is this ok for trunk?
>
> BR,
> Jeff (Jiufu)
>
> gcc/ChangeLog:
>
>   * config/rs6000/rs6000.cc (rs6000_modes_tieable_p): Mark more tieable
>   modes.
>
> gcc/testsuite/ChangeLog:
>
>   * g++.target/powerpc/pr102024.C: Updated.
>
> ---
>  gcc/config/rs6000/rs6000.cc | 9 +
>  gcc/testsuite/g++.target/powerpc/pr102024.C | 3 ++-
>  2 files changed, 11 insertions(+), 1 deletion(-)
>
> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
> index 6ac3adcec6b..3cb0186089e 100644
> --- a/gcc/config/rs6000/rs6000.cc
> +++ b/gcc/config/rs6000/rs6000.cc
> @@ -1968,6 +1968,15 @@ rs6000_modes_tieable_p (machine_mode mode1, 
> machine_mode mode2)
>if (ALTIVEC_OR_VSX_VECTOR_MODE (mode2))
>  return false;
>  
> +  /* SFmode format (IEEE DP) in register would not as required,
> + So SFmode is restrict here.  */
> +  if (GET_MODE_CLASS (mode1) == MODE_FLOAT
> +  && GET_MODE_CLASS (mode2) == MODE_INT)
> +return GET_MODE_SIZE (mode2) == UNITS_PER_FP_WORD && mode1 != SFmode;
> +  if (GET_MODE_CLASS (mode1) == MODE_INT
> +  && GET_MODE_CLASS (mode2) == MODE_FLOAT)
> +return GET_MODE_SIZE (mode1) == UNITS_PER_FP_WORD && mode2 != SFmode;
> +
>if (SCALAR_FLOAT_MODE_P (mode1))
>  return SCALAR_FLOAT_MODE_P (mode2);
>if (SCALAR_FLOAT_MODE_P (mode2))
> diff --git a/gcc/testsuite/g++.target/powerpc/pr102024.C 
> b/gcc/testsuite/g++.target/powerpc/pr102024.C
> index 769585052b5..27d2dc5e80b 100644
> --- a/gcc/testsuite/g++.target/powerpc/pr102024.C
> +++ b/gcc/testsuite/g++.target/powerpc/pr102024.C
> @@ -5,7 +5,8 @@
>  // Test that a zero-width bit field in an otherwise homogeneous aggregate
>  // generates a psabi warning and passes arguments in GPRs.
>  
> -// { dg-final { scan-assembler-times {\mstd\M} 4 } }
> +// { dg-final { scan-assembler-times {\mmtvsrd\M} 4 { target has_arch_pwr8 } 
> } }
> +// { dg-final { scan-assembler-times {\mstd\M} 4 { target { ! has_arch_pwr8 
> } } } }
>  
>  struct a_thing
>  {

[Bug libstdc++/108861] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Vinícius dos Santos Oliveira from comment #2)
> Nobody is going to fix 98449. The ONE-line patchset fixing the issue was
> there for YEARS. Why does it take so many years to review ONE line? It's
> obvious that it'll just hang there forever. Meanwhile I have a code base
> affected by this issue.

Opening a duplicate of it doesn't change anything.

[Bug target/108804] missed vectorization in presence of conversion from uint64_t to float

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
I think the point here is: although it's unit64_t -> float, but the range of x
and y can be represent as int32(k & 0x007F) |  0x3F80), so we can use
int32 -> float instructions which are supported by the backend.

So it looks to me a middle-end issue.

A simple testcase clang generates vcvtdq2ps but gcc doesn't vectorize.

#include

uint64_t d[512];
float f[1024];

void foo() {
for (int i=0; i<512; ++i) {
uint64_t k = d[i];
f[i]=(k & 0x3F30);
}
}

manually add convertion then gcc also can do vectorization.

#include

uint64_t d[512];
float f[1024];

void foo() {
for (int i=0; i<512; ++i) {
uint64_t k = d[i];
f[i]=(int)(k & 0x3F30);
}
}

[Bug libstdc++/108636] [10/11/12 Regression] C++20 undefined reference to `std::filesystem::__cxx11::path::_List::type(std::filesystem::__cxx11::path::_Type)' with -fkeep-inline-functions

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:0a2597477e482df4d67db6696431286df1ff4428

commit r12-9193-g0a2597477e482df4d67db6696431286df1ff4428
Author: Jonathan Wakely 
Date:   Thu Feb 2 14:06:40 2023 +

libstdc++: Fix std::filesystem errors with -fkeep-inline-functions
[PR108636]

With -fkeep-inline-functions there are linker errors when including
. This happens because there are some filesystem::path
constructors defined inline which call non-exported functions defined in
the library. That's usually not a problem, because those constructors
are only called by code that's also inside the library. But when the
header is compiled with -fkeep-inline-functions those inline functions
are emitted even though they aren't called. That then creates an
undefined reference to the other library internsl. The fix is to just
move the private constructors into the library where they are called.
That way they are never even seen by users, and so not compiled even if
-fkeep-inline-functions is used.

libstdc++-v3/ChangeLog:

PR libstdc++/108636
* include/bits/fs_path.h (path::path(string_view, _Type))
(path::_Cmpt::_Cmpt(string_view, _Type, size_t)): Move inline
definitions to ...
* src/c++17/fs_path.cc: ... here.
* testsuite/27_io/filesystem/path/108636.cc: New test.

(cherry picked from commit db8d6fc572ec316ccfcf70b1dffe3be0b1b37212)

[Bug libstdc++/108861] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Vinícius dos Santos Oliveira from comment #2)
> > Isn't this just Bug 98449? Why did you close that as FIXED?
> 
> Nobody is going to fix 98449. The ONE-line patchset fixing the issue was
> there for YEARS. Why does it take so many years to review ONE line? It's
> obvious that it'll just hang there forever. Meanwhile I have a code base
> affected by this issue.

Because there is an open defect report against the C++ standard about this.
Basically until that is resolved, GCC's behavior is considered correct.

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

[Bug libstdc++/98449] [DR 3343] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

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

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

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

[Bug libstdc++/98449] [DR 3343] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|RESOLVED|SUSPENDED
 Resolution|FIXED   |---

--- Comment #4 from Andrew Pinski  ---
Supending until the library defect report has been resolved.

[Bug tree-optimization/108868] [13 Regression] ocaml-dune miscompilation on i686 since r13-5965

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

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

--- Comment #4 from Jakub Jelinek  ---
I think the reason why it doesn't work is clear, call_can_make_abnormal_goto on
the vfork call is false, because it is leaf (and that is how glibc declares
vfork BTW) and ctrl_altering flag is initialized by
gimple_call_initialize_ctrl_altering based on that or if it is noreturn etc.
(nothing applies).
So, I think as discussed in another PR, I think we really should make if not
call_can_make_abnormal_goto at least gimple_call_initialize_ctrl_altering be
true for
RETURNS_TWICE calls.

[Bug libstdc++/108861] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

[vini.ipsmaker at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Vinícius dos Santos Oliveira  ---
> Isn't this just Bug 98449? Why did you close that as FIXED?

Nobody is going to fix 98449. The ONE-line patchset fixing the issue was there
for YEARS. Why does it take so many years to review ONE line? It's obvious that
it'll just hang there forever. Meanwhile I have a code base affected by this
issue.

[Bug tree-optimization/108868] [13 Regression] ocaml-dune miscompilation on i686 since r13-5965

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #2)
> That would be invalid, vfork can't return from the containing function.

I messed up the if (it should be the opposite way around, that is checking for
non-zero). That is "if (ret != 0) {" :).

[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses

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

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

--- Comment #8 from Jerry DeLisle  ---
FWIW : I think the typespec is being lost because the initial call into
gfc_match_array_constructor which finds and matches the typespec sets a local
variable seen_ts which is used later in that function to do the type conversion
steps. However, before that happens a call from gfc_match_array_constructor
into match_array_cons_element then results in a subsequent call to
gfc_match_array_constructor where there is no typespec left to match. The local
seen_ts is set to false so the conversion code does not get called.

Killing parens does not fix any of this.  I think what is needed is the seen_ts
needs to be passed down the call chain to preserve it during the
match_array_cons_element process. My intuition tells me it would be better if
portions of this code are refactored little to avoid some of these recursive
calls.

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

[dangelog at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Giuseppe D'Angelo  ---
> In the case of copy family algorithms, I believe it's OK to specially handle 
> cases where last - first == 1.

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? I've just tried locally, and it seems to work. It also doesn't seem that
libstdc++ uses memcpy/memmove elsewhere (e.g. in std::fill).

[Bug middle-end/108854] tbb-2021.8.0 fails on i686-linux (32-bit), internal compiler error: in expand_expr_real_1, at expr.c:10281

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

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

--- Comment #5 from Andrew Pinski  ---
_ZThn20_N3tbb6detail2d114broadcast_nodeINS1_12continue_msgEE18register_successorERNS1_8receiverIS3_EE

demangles to:
non-virtual thunk to
tbb::detail::d1::broadcast_node::register_successor(tbb::detail::d1::receiver&)

[Bug tree-optimization/108868] [13 Regression] ocaml-dune miscompilation on i686 since r13-5965

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

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

--- Comment #2 from Jakub Jelinek  ---
That would be invalid, vfork can't return from the containing function.

Anyway, reduced testcase which shows the .ABNORMAL_DISPATCHER call in r13-5964
and none in r13-5965 in optimized is e.g. with just -O2:
int x;
int vfork (void) __attribute__((__leaf__, __returns_twice__));
int fork (void);
void bar (int, int, int *);

void
foo (void)
{
  int b = 0;
  int r = x ? vfork () : fork ();
  bar (r, x, );
}

This could be valid, as bar could e.g. for the first argument equal to 0 execve
or _exit.  It doesn't show the spill slot clobbering though.

[Bug middle-end/108854] tbb-2021.8.0 fails on i686-linux (32-bit), internal compiler error: in expand_expr_real_1, at expr.c:10281

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

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

--- Comment #4 from Andrew Pinski  ---
This is the ICE:

tbb-i686-linux> during RTL pass: expand
tbb-i686-linux> In file included from
/build/source/src/tbb/../../include/tbb/flow_graph.h:17,
tbb-i686-linux>  from
/build/source/test/tbb/test_continue_node.cpp:19:
tbb-i686-linux>
/build/source/src/tbb/../../include/tbb/../oneapi/tbb/flow_graph.h: In member
function 'bool
tbb::detail::d1::broadcast_node::_ZThn20_N3tbb6detail2d114broadcast_nodeINS1_12continue_msgEE18register_successorERNS1_8receiverIS3_EE.artificial_thunk.0(tbb::detail::d1::broadcast_node::successor_type&)':
tbb-i686-linux>
/build/source/src/tbb/../../include/tbb/../oneapi/tbb/flow_graph.h:1117:10:
internal compiler error: in expand_expr_real_1, at expr.c:10281
tbb-i686-linux>  1117 | bool register_successor( successor_type  )
override {
tbb-i686-linux>   |  ^~
tbb-i686-linux> 0x9301fc9 diagnostic_impl(rich_location*, diagnostic_metadata
const*, int, char const*, char**, diagnostic_t)
tbb-i686-linux> ???:0
tbb-i686-linux> 0x930218b internal_error(char const*, ...)
tbb-i686-linux> ???:0
tbb-i686-linux> 0x82791d5 fancy_abort(char const*, int, char const*)
tbb-i686-linux> ???:0
tbb-i686-linux> 0x82461f7 expand_expr_real_1(tree_node*, rtx_def*,
machine_mode, expand_modifier, rtx_def**, bool) [clone .cold]
tbb-i686-linux> ???:0
tbb-i686-linux> 0x84f4ce5 expand_gimple_stmt(gimple*)
tbb-i686-linux> ???:0
tbb-i686-linux> 0x84fb309 (anonymous
namespace)::pass_expand::execute(function*)
tbb-i686-linux> ???:0
tbb-i686-linux> Please submit a full bug report,
tbb-i686-linux> with preprocessed source if appropriate.
tbb-i686-linux> Please include the complete backtrace with any bug report.
tbb-i686-linux> See  for instructions.

[Bug tree-optimization/108868] [13 Regression] ocaml-dune miscompilation on i686 since r13-5965

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

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

--- Comment #1 from Andrew Pinski  ---
Here is a testcase which shows the removal of ABNORMAL_DISPATCHER though I am
not sure what is the best way to test if the removal makes a difference.

```
extern int vfork (void) __attribute__ ((__nothrow__ , __leaf__,
__returns_twice__));
extern int fork (void) __attribute__ ((__nothrow__ , __leaf__,
__returns_twice__));

void sink(int*) __attribute__((noipa));
void sink(int*) {}
int f(int a, int b) __attribute__((noipa));
int f(int a, int b)
{
sink();
int ret = a ? vfork() : fork();
if (ret == 0) {
sink();
b++;
sink();
return 0;
}
if(b) __builtin_abort();
__builtin_exit(0);
}
```

[Bug libstdc++/108859] Exception thrown by std::filesystem::copy() is wrong

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

[Bug libstdc++/108861] notify_all_at_thread_exit() should notify on cond while lock is held to avoid a race

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

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

--- Comment #1 from Jonathan Wakely  ---
Isn't this just Bug 98449? Why did you close that as FIXED?

[Bug tree-optimization/108868] [13 Regression] ocaml-dune miscompilation on i686 since r13-5965

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 CC||rguenth at gcc dot gnu.org
   Last reconfirmed||2023-02-20
 Status|UNCONFIRMED |NEW
   Priority|P3  |P1
 Ever confirmed|0   |1

[Bug tree-optimization/108868] New: [13 Regression] ocaml-dune miscompilation on i686 since r13-5965

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

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

Bug ID: 108868
   Summary: [13 Regression] ocaml-dune miscompilation on i686
since r13-5965
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54499
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54499=edit
spawn_stubs.i.xz

The following source from ocaml-dune seems to be miscompiled starting with
r13-5965 with
-mfpmath=sse -m32 -march=i686 -mtune=generic -msse2 -mfpmath=sse -mstackrealign
-O2 -fno-strict-aliasing -fwrapv -fstack-protector-strong -fcf-protection=full
-fPIC -fexceptions -fstack-protector-strong -fasynchronous-unwind-tables
-fstack-clash-protection -fcf-protection=full
The spawn_unix function uses (conditionally) vfork and the vfork child now
clobbers -672(%ebp) - 9 is stored in there.

The main problem I see is that .ABNORMAL_DISPATCHER (0) call disappears in
cddce1 pass.

[PATCH] i386: Introduce general_x64constmem_operand predicate

[Uros Bizjak via Gcc-patches]

Instructions that use high-part QImode registers can not be encoded
with REX prefix.  To avoid REX prefix, operand constraints allow
only legacy QImode registers, immediates and constant memory operands.
The patch introduces matching predicate, so invalid operands are not
combined into instruction RTX only to be later fixed up by reload pass.

2023-02-20  Uroš Bizjak  

gcc/ChangeLog:

* config/i386/predicates.md
(general_x64constmem_operand): New predicate.
* config/i386/i386.md (*cmpqi_ext_1):
Use nonimm_x64constmem_operand.
(*cmpqi_ext_3): Use general_x64constmem_operand.
(*addqi_ext_1): Ditto.
(*testqi_ext_1): Ditto.
(*andqi_ext_1): Ditto.
(*andqi_ext_1_cc): Ditto.
(*qi_ext_1): Ditto.
(*xorqi_ext_1_cc): Ditto.

Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.

Pushed to master.

Uros.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index 6382cfbce21..8ebb12be2c9 100644
--- a/gcc/config/i386/i386.md
+++ b/gcc/config/i386/i386.md
@@ -1456,7 +1456,7 @@ (define_insn "*cmp_minus_1"
 (define_insn "*cmpqi_ext_1"
   [(set (reg FLAGS_REG)
(compare
- (match_operand:QI 0 "nonimmediate_operand" "QBc,m")
+ (match_operand:QI 0 "nonimm_x64constmem_operand" "QBc,m")
  (subreg:QI
(zero_extract:SWI248
  (match_operand 1 "int248_register_operand" "Q,Q")
@@ -1501,7 +1501,7 @@ (define_insn "*cmpqi_ext_3"
  (match_operand 0 "int248_register_operand" "Q,Q")
  (const_int 8)
  (const_int 8)) 0)
- (match_operand:QI 1 "general_operand" "QnBc,m")))]
+ (match_operand:QI 1 "general_x64constmem_operand" "QnBc,m")))]
   "ix86_match_ccmode (insn, CCmode)"
   "cmp{b}\t{%1, %h0|%h0, %1}"
   [(set_attr "isa" "*,nox64")
@@ -6683,7 +6683,7 @@ (define_insn "*addqi_ext_1"
(match_operand 1 "int248_register_operand" "0,0")
(const_int 8)
(const_int 8)) 0)
-   (match_operand:QI 2 "general_operand" "QnBc,m")) 0))
+   (match_operand:QI 2 "general_x64constmem_operand" "QnBc,m")) 0))
(clobber (reg:CC FLAGS_REG))]
   "/* FIXME: without this LRA can't reload this pattern, see PR82524.  */
rtx_equal_p (operands[0], operands[1])"
@@ -9901,7 +9901,7 @@ (define_insn "*testqi_ext_1"
(match_operand 0 "int248_register_operand" "Q,Q")
(const_int 8)
(const_int 8)) 0)
-   (match_operand:QI 1 "general_operand" "QnBc,m"))
+   (match_operand:QI 1 "general_x64constmem_operand" "QnBc,m"))
  (const_int 0)))]
   "ix86_match_ccmode (insn, CCNOmode)"
   "test{b}\t{%1, %h0|%h0, %1}"
@@ -10602,7 +10602,7 @@ (define_insn "*andqi_ext_1"
(match_operand 1 "int248_register_operand" "0,0")
(const_int 8)
(const_int 8)) 0)
-   (match_operand:QI 2 "general_operand" "QnBc,m")) 0))
+   (match_operand:QI 2 "general_x64constmem_operand" "QnBc,m")) 0))
(clobber (reg:CC FLAGS_REG))]
   "/* FIXME: without this LRA can't reload this pattern, see PR82524.  */
rtx_equal_p (operands[0], operands[1])"
@@ -10622,7 +10622,7 @@ (define_insn "*andqi_ext_1_cc"
(match_operand 1 "int248_register_operand" "0,0")
(const_int 8)
(const_int 8)) 0)
-   (match_operand:QI 2 "general_operand" "QnBc,m"))
+   (match_operand:QI 2 "general_x64constmem_operand" "QnBc,m"))
  (const_int 0)))
(set (zero_extract:SWI248
  (match_operand 0 "int248_register_operand" "+Q,Q")
@@ -11345,7 +11345,7 @@ (define_insn "*qi_ext_1"
(match_operand 1 "int248_register_operand" "0,0")
(const_int 8)
(const_int 8)) 0)
-   (match_operand:QI 2 "general_operand" "QnBc,m")) 0))
+   (match_operand:QI 2 "general_x64constmem_operand" "QnBc,m")) 0))
(clobber (reg:CC FLAGS_REG))]
   "(!TARGET_PARTIAL_REG_STALL || optimize_function_for_size_p (cfun))
/* FIXME: without this LRA can't reload this pattern, see PR82524.  */
@@ -11473,7 +11473,7 @@ (define_insn "*xorqi_ext_1_cc"
(match_operand 1 "int248_register_operand" "0,0")
(const_int 8)
(const_int 8)) 0)
-   (match_operand:QI 2 "general_operand" "QnBc,m"))
+   (match_operand:QI 2 "general_x64constmem_operand" "QnBc,m"))
  (const_int 0)))
(set (zero_extract:SWI248
  (match_operand 0 "int248_register_operand" "+Q,Q")
diff --git a/gcc/config/i386/predicates.md b/gcc/config/i386/predicates.md
index 7b3db0cc851..b4d9ab40ab9 100644
--- a/gcc/config/i386/predicates.md
+++ b/gcc/config/i386/predicates.md
@@ -116,6 +116,13 @@ (define_predicate "nonimm_x64constmem_operand"
(ior (not (match_test "TARGET_64BIT"))
 (match_test "constant_address_p (XEXP (op, 0))")
 
+;; Match general operand, but exclude non-constant addresses for x86_64.

[Bug analyzer/108867] New: RFE: analyzer could suppress false positives by detecting functions that are likely missing __attribute__((noreturn))

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

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

Bug ID: 108867
   Summary: RFE: analyzer could suppress false positives by
detecting functions that are likely missing
__attribute__((noreturn))
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

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

The attached (from Doom) has 31 false positives from
-Wanalyzer-use-of-uninitialized-value, and a -Wanalyzer-null-dereference
diagnostic:
  https://godbolt.org/z/h4qadxfK9

I think all of the uninit warnings follow calls to I_Error, which is defined in
a different TU (i_system.c), and calls exit(-1).

If I manually add __attribute__((noreturn)) to I_Error, then all of the
-Wanalyzer-use-of-uninitialized-value go away:
  https://godbolt.org/z/Gb7P5hK11
leaving just the -Wanalyzer-null-dereference diagnostic.

RFE: try to detect likely candidates for __attribute__((noreturn)), and use
them to suppress such warnings (with a note informing the user when it's done,
and a fix-it hint).

That said, I think many of the uninit false +ves are follow-on warnings, where
we should only warn about the first use of an uninit value in an execution
path, and not on subsequent ones.

[Bug fortran/108850] SELECT CASE within BLOCK construct in one subroutine prevents compilation of another subroutine named "SELECT"

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to John Wingate from comment #2)
> I forgot to mention in the original description that the error does not
> occur if the SELECT CASE is removed.

Right.  The testcase case be slightly reduced to the almost bare minimum:

module m
  implicit none
  private
  public :: select
contains
  subroutine a
block
  select case (1)
  end select
end block
  end subroutine a
  !  compiles successfully if name is not 'select'
  subroutine select
  end subroutine select
end module m

Either interchanging the subroutines, commenting "public :: select",
commenting the "select case" block, or commenting "block" while keeping
its contents avoids the error.

Adding -fdump-fortran-original shows why gfortran hits some artifical
conflict:

Namespace: A-Z: (UNKNOWN 0)
procedure name = m
  symtree: 'a'   || symbol: 'a'
type spec : (UNKNOWN 0)
attributes: (PROCEDURE MODULE-PROC  SUBROUTINE IMPLICIT-PURE CONTAINED)
  symtree: 'm'   || symbol: 'm'
type spec : (UNKNOWN 0)
attributes: (MODULE )
  symtree: 'select'  || symbol: 'select'   
type spec : (UNKNOWN 0)
attributes: (VARIABLE PUBLIC )

[...]

I have no idea how the above code tricks gfortran into thinking there is
a variable 'select' ...

[Bug driver/108865] gcc on Windows fails with Unicode path to source file

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Costas Argyris from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Utf8 is the best generic solution really.
> > Using wmain is not very portable and the rest of gcc's sources can't use
> > wchar_t as that would break unix/Linux handling.
> 
> Yes, on that, I was thinking to only use wchar_t in wmain just to get the
> arguments properly (not destroyed), and immediately convert to UTF-8 char
> arrays to pass to the rest of the program (starting with the call to
> driver.main which main wraps).That way, all sources would stay the same
> working with char arrays, only this time it would be UTF-8 char arrays that
> properly carry the Unicode args.This would allow only selected parts of
> the Windows-specific code (possibly only in libiberty/pex-win32.c) to opt-in
> for the necessary conversion back to wchar_t UTF-16 arrays in order to call
> the Unicode versions of Win32 APIs like CreateProcessW etc., and get
> end-to-end Unicode support on Windows.

I think that is bad solution in general.
Just use utf8 like every other target would.

[Bug driver/108865] gcc on Windows fails with Unicode path to source file

[costas.argyris at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Costas Argyris  ---
(In reply to Andrew Pinski from comment #1)
> Utf8 is the best generic solution really.
> Using wmain is not very portable and the rest of gcc's sources can't use
> wchar_t as that would break unix/Linux handling.

Yes, on that, I was thinking to only use wchar_t in wmain just to get the
arguments properly (not destroyed), and immediately convert to UTF-8 char
arrays to pass to the rest of the program (starting with the call to
driver.main which main wraps).That way, all sources would stay the same
working with char arrays, only this time it would be UTF-8 char arrays that
properly carry the Unicode args.This would allow only selected parts of the
Windows-specific code (possibly only in libiberty/pex-win32.c) to opt-in for
the necessary conversion back to wchar_t UTF-16 arrays in order to call the
Unicode versions of Win32 APIs like CreateProcessW etc., and get end-to-end
Unicode support on Windows.

[Bug fortran/108850] SELECT CASE within BLOCK construct in one subroutine prevents compilation of another subroutine named "SELECT"

[johnww at tds dot net via Gcc-bugs]

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

--- Comment #2 from John Wingate  ---
I forgot to mention in the original description that the error does not occur
if the SELECT CASE is removed.

[Bug target/108866] Allow to pass Windows resource file (.rc) as input to gcc

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/108866] Allow to pass Windows resource file (.rc) as input to gcc

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c   |target

--- Comment #1 from Andrew Pinski  ---
The target code could add driver specs to let the gcc driver understand what
.rc is.

[Bug driver/108865] gcc on Windows fails with Unicode path to source file

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

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

--- Comment #1 from Andrew Pinski  ---
Utf8 is the best generic solution really.
Using wmain is not very portable and the rest of gcc's sources can't use
wchar_t as that would break unix/Linux handling.

[Bug c/108866] New: Allow to pass Windows resource file (.rc) as input to gcc

[pali at kernel dot org via Gcc-bugs]

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

Bug ID: 108866
   Summary: Allow to pass Windows resource file (.rc) as input to
gcc
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pali at kernel dot org
  Target Milestone: ---

Currently it is possible to pass source C file, source assembler file, object
file, library to gcc as an input argument and gcc calls needed tools to compile
and link all input files to one output binary.

But gcc currently is not able to recognize Windows resource text file .rc when
it is passed as input argument. See:

$ x86_64-w64-mingw32-gcc test-rsrc.rc
/usr/bin/x86_64-w64-mingw32-ld:test-rsrc.rc: file format not recognized;
treating as linker script
/usr/bin/x86_64-w64-mingw32-ld:test-rsrc.rc:1: syntax error
collect2: error: ld returned 1 exit status

Currently resource file first needs to be passed to windres compiler and then
output object file from windres can be specified as input argument to gcc:

$ x86_64-w64-mingw32-windres --input-format=rc --output-format=coff
--input=test-rsrc.rc --output=test-rsrc.o

It would be nice if gcc is able to call windres automatically for resource text
file, like for assembler source, for generating object file.

[Bug c++/108550] [10/11/12/13 Regression] the type 'const auto' of 'constexpr' variable is not literal

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

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

--- Comment #7 from Marek Polacek  ---
We get the bogus error because we failed to deduce the auto in
constexpr auto is_pointer_v = is_pointer::value;
to bool.

We call do_auto_deduction and type_unification_real correctly deduces targs to
, but the tsubst at the end of do_auto_deduction doesn't use the bool to
replace arg, which is

(gdb) pt
 

but levels = TMPL_ARGS_DEPTH (args); is 1, so the
  if (level <= levels
block isn't performed, so we don't fetch the bool from args.

It looks like another case where 'auto' has a level that we don't handle
correctly.  I think the level for placeholders is created + 1 than the normal
one (at least it used to be), so orig_level 2 is probably correct, but level
should probably have been reduced to 1.

I need to poke more...

[Bug target/108862] [13 Regression] CryptX miscompilation on power9 since r13-2107

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #7 from Jakub Jelinek  ---
Fixed.

[Bug driver/108865] New: gcc on Windows fails with Unicode path to source file

[costas.argyris at gmail dot com via Gcc-bugs]

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

Bug ID: 108865
   Summary: gcc on Windows fails with Unicode path to source file
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: costas.argyris at gmail dot com
  Target Milestone: ---

>From Windows Command Prompt, temp has a subfolder named ﹏
(https://www.compart.com/en/unicode/U+FE4F) with a source file in it.Try to
compile it:

C:\Users\cargyris\temp>gcc ﹏\src.c
gcc: error: ?\src.c: Invalid argument
gcc: fatal error: no input files
compilation terminated.

Note how ﹏ was destroyed into ?

The problem starts all the way from gcc's main function at gcc-main.cc

The main function is the normal one which takes char *argv[], that is, it takes
its command-line arguments as char-based strings.On Windows, this means
that the arguments will be interpreted using the local Windows ANSI codepage,
and, as a result, the ﹏ character gets destroyed right from the start - gcc
never sees it correctly.

The way to see the Unicode args properly would be to use wmain instead of main,
which takes wchar_t *argv[] and uses UTF-16.

Would it ever be considered to change main to wmain when compiling for Windows
+ mingw-w64 in order to achieve support for Unicode paths on Windows?

There is also another solution outside of gcc:Changing the ANSI code page
to UTF-8.This can be done either on a global system level (for the whole
Windows OS) or on a per-process level, specifically targeting gcc to use UTF-8
as it's ANSI code page.These approaches require user intervention though,
whereas if the Unicode main was used (wmain) things would just work with
Unicode paths without the user having to do anything special.

[committed] powerpc: Another umaddditi4 fix [PR108862]

[Jakub Jelinek via Gcc-patches]

Hi!

The following testcase is miscompiled on powerpc64le-linux with
-O2 -mcpu=power9.  The problem is that gen_umaddditi4 is called with
the same TImode register for both op0 and op3, and maddlddi4
overwrites the low half of op0 before the low half of op3 is read,
so when they are the same register it reads the result of maddlddi4.

The following patch fixes that by swapping maddlddi4 and
umadddi4_highpart{,_le} during expansion, as the latter writes into
a temporary pseudo and so can't change anything maddlddi4 depends on.

Bootstrapped/regtested on powerpc64-linux (power7, tested -m32/-m64),
powerpc64le-linux (power8 and another on power9 with
--with-cpu-64=power9 --with-tune-64=power9), preapproved by Segher on IRC,
committed to trunk.

2023-02-20  Jakub Jelinek  

PR target/108862
* config/rs6000/rs6000.md (umaddditi4): Swap gen_maddlddi4 with
gen_umadddi4_highpart{,_le}.

* gcc.dg/pr108862.c: New test.
* gcc.target/powerpc/pr108862.c: New test.

--- gcc/config/rs6000/rs6000.md.jj  2023-02-15 10:51:12.745802021 +0100
+++ gcc/config/rs6000/rs6000.md 2023-02-20 16:01:02.929027764 +0100
@@ -3249,8 +3249,6 @@
   rtx op3_hi = gen_rtx_SUBREG (DImode, operands[3], BYTES_BIG_ENDIAN ? 0 : 8);
   rtx hi_temp = gen_reg_rtx (DImode);
 
-  emit_insn (gen_maddlddi4 (op0_lo, operands[1], operands[2], op3_lo));
-
   if (BYTES_BIG_ENDIAN)
 emit_insn (gen_umadddi4_highpart (hi_temp, operands[1], operands[2],
  op3_lo));
@@ -3258,6 +3256,8 @@
 emit_insn (gen_umadddi4_highpart_le (hi_temp, operands[1], operands[2],
 op3_lo));
 
+  emit_insn (gen_maddlddi4 (op0_lo, operands[1], operands[2], op3_lo));
+
   emit_insn (gen_adddi3 (op0_hi, hi_temp, op3_hi));
 
   DONE;
--- gcc/testsuite/gcc.dg/pr108862.c.jj  2023-02-20 15:52:20.570619215 +0100
+++ gcc/testsuite/gcc.dg/pr108862.c 2023-02-20 15:51:52.363029125 +0100
@@ -0,0 +1,27 @@
+/* PR target/108862 */
+/* { dg-do run { target int128 } } */
+/* { dg-options "-O2" } */
+
+unsigned long long a[2] = { 0x04a13945d898c296ULL, 0x1fffULL };
+unsigned long long b[4] = { 0x04a13945d898c296ULL, 0, 0, 0x1fffULL 
};
+
+__attribute__((noipa)) unsigned __int128
+foo (int x, unsigned long long *y, unsigned long long *z)
+{
+  unsigned __int128 w = 0;
+  for (int i = 0; i < x; i++)
+w += (unsigned __int128)*y++ * (unsigned __int128)*z--;
+  return w;
+}
+
+int
+main ()
+{
+  unsigned __int128 x = foo (1, [0], [1]);
+  unsigned __int128 y = foo (2, [0], [3]);
+  if ((unsigned long long) (x >> 64) != 0x004a13945dd3ULL
+  || (unsigned long long) x != 0x9b1c8443b3909d6aULL
+  || x != y)
+__builtin_abort ();
+  return 0;
+}
--- gcc/testsuite/gcc.target/powerpc/pr108862.c.jj  2023-02-20 
15:52:51.374171586 +0100
+++ gcc/testsuite/gcc.target/powerpc/pr108862.c 2023-02-20 15:53:04.497980869 
+0100
@@ -0,0 +1,6 @@
+/* PR target/108862 */
+/* { dg-do run { target int128 } } */
+/* { dg-require-effective-target p9vector_hw } */
+/* { dg-options "-O2 -mdejagnu-cpu=power9" } */
+
+#include "../../gcc.dg/pr108862.c"

Jakub

[Bug rtl-optimization/108863] Unrolling could use range information

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Confirmed. Though maybe the tree level unroller could improve this situtation
such that it just does the unroll here 4 times.

[Bug target/108862] [13 Regression] CryptX miscompilation on power9 since r13-2107

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jakub Jelinek :

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

commit r13-6147-gcd8b4fae52d02541c2d8bd2200caad3812f37368
Author: Jakub Jelinek 
Date:   Mon Feb 20 22:07:57 2023 +0100

powerpc: Another umaddditi4 fix [PR108862]

The following testcase is miscompiled on powerpc64le-linux with
-O2 -mcpu=power9.  The problem is that gen_umaddditi4 is called with
the same TImode register for both op0 and op3, and maddlddi4
overwrites the low half of op0 before the low half of op3 is read,
so when they are the same register it reads the result of maddlddi4.

The following patch fixes that by swapping maddlddi4 and
umadddi4_highpart{,_le} during expansion, as the latter writes into
a temporary pseudo and so can't change anything maddlddi4 depends on.

2023-02-20  Jakub Jelinek  

PR target/108862
* config/rs6000/rs6000.md (umaddditi4): Swap gen_maddlddi4 with
gen_umadddi4_highpart{,_le}.

* gcc.dg/pr108862.c: New test.
* gcc.target/powerpc/pr108862.c: New test.

[Bug sanitizer/108864] Insufficient red zone in ASAN

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=105405
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andrew Pinski  ---
><== Memory access at offset 48 is inside this variable

Basically GCC's red zone is up to 16 bytes. 
See PR 105405 also.

[Bug sanitizer/108864] New: Insufficient red zone in ASAN

[shaohua.li at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 108864
   Summary: Insufficient red zone in ASAN
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: shaohua.li at inf dot ethz.ch
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

For the following code, I found ASAN since GCC-9 would emit an insufficient
stack red zone for the variable `k`, which leads to a missed buffer-overflow
report. At -O0, there is no report from ASAN, but at -O1, the ASAN reported a
stack-use-after-scope. After comparing with Clang's redzone allocation, I
believe that GCC's ASAN does not emit enough redzone for this case.

% cat a.c
struct a {
  long b;
};
struct c {
  int d;
} e[1];
int f;
static int *g() {
  struct c h;
  
  f = 0;
  for (; f < 1; f++)
;
  return [0].d;
}
void i() {
  struct a j[1] = {};
  g();
  {
struct c k={1};
int *l = 
*(l + 4) = 0;
  }
  j;
}
int main() { i(); }
%
% gcc-tk -fsanitize=address -O0 a.c && ./a.out
%
% gcc-tk -fsanitize=address -O1 a.c && ./a.out
=
==1==ERROR: AddressSanitizer: stack-use-after-scope on address 0x7f6f03700030
at pc 0x00401291 bp 0x7ffd3ed6a410 sp 0x7ffd3ed6a408
WRITE of size 4 at 0x7f6f03700030 thread T0
#0 0x401290 in i /app/example.c:22
#1 0x4012c9 in main /app/example.c:26
#2 0x7f6f0605c082 in __libc_start_main
(/lib/x86_64-linux-gnu/libc.so.6+0x24082) (BuildId:
1878e6b475720c7c51969e69ab2d276fae6d1dee)
#3 0x4010cd in _start (/app/output.s+0x4010cd) (BuildId:
6d3e84a6ea228e86a3fc8319089c26dcbbcd8fb6)

Address 0x7f6f03700030 is located in stack of thread T0 at offset 48 in frame
#0 0x401195 in i /app/example.c:16

  This frame has 3 object(s):
[32, 36) 'k' (line 20)
[48, 52) 'h' (line 9) <== Memory access at offset 48 is inside this
variable
[64, 72) 'j' (line 17)
HINT: this may be a false positive if your program uses some custom stack
unwind mechanism, swapcontext or vfork
  (longjmp and C++ exceptions *are* supported)
SUMMARY: AddressSanitizer: stack-use-after-scope /app/example.c:22 in i
Shadow bytes around the buggy address:
  0x7f6f036ffd80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f6f036ffe00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f6f036ffe80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f6f036fff00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f6f036fff80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
=>0x7f6f0370: f1 f1 f1 f1 04 f2[f8]f2 00 f3 f3 f3 00 00 00 00
  0x7f6f03700080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f6f03700100: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f6f03700180: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f6f03700200: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
  0x7f6f03700280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
...
%

[Bug fortran/96025] [10/11/12/13 Regression] ICE in expr_check_typed_help, at fortran/expr.c:5437

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #9 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2023-February/058942.html

[PATCH] Fortran: improve checking of character length specification [PR96025]

[Harald Anlauf via Gcc-patches]

Dear all,

the attached patch fixes an ICE on invalid (non-integer)
specification expressions for character length in function
declarations.  It appears that the error handling was
already in place (mostly) and we need to essentially
prevent run-on errors.

Regtested on x86_64-pc-linux-gnu.  OK for mainline?

The PR is marked as a 10/11/12/13 regression, so I would
like to backport this as far as it seems reasonable.

Thanks,
Harald

From f581f63e206b54278c27a5c888c2566cb5077f11 Mon Sep 17 00:00:00 2001
From: Harald Anlauf 
Date: Mon, 20 Feb 2023 21:28:09 +0100
Subject: [PATCH] Fortran: improve checking of character length specification
 [PR96025]

gcc/fortran/ChangeLog:

	PR fortran/96025
	* parse.cc (check_function_result_typed): Improve type check of
	specification expression for character length and return status.
	(parse_spec): Use status from above.
	* resolve.cc (resolve_fntype): Prevent use of invalid specification
	expression for character length.

gcc/testsuite/ChangeLog:

	PR fortran/96025
	* gfortran.dg/pr96025.f90: New test.
---
 gcc/fortran/parse.cc  | 23 ---
 gcc/fortran/resolve.cc|  4 +++-
 gcc/testsuite/gfortran.dg/pr96025.f90 | 11 +++
 3 files changed, 30 insertions(+), 8 deletions(-)
 create mode 100644 gcc/testsuite/gfortran.dg/pr96025.f90

diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index f5154d97ae8..47876a3833e 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -3974,21 +3974,30 @@ match_deferred_characteristics (gfc_typespec * ts)
For return types specified in a FUNCTION prefix, the IMPLICIT rules of the
scope are not yet parsed so this has to be delayed up to parse_spec.  */

-static void
+static bool
 check_function_result_typed (void)
 {
   gfc_typespec ts;

   gcc_assert (gfc_current_state () == COMP_FUNCTION);

-  if (!gfc_current_ns->proc_name->result) return;
+  if (!gfc_current_ns->proc_name->result)
+return true;

   ts = gfc_current_ns->proc_name->result->ts;

   /* Check type-parameters, at the moment only CHARACTER lengths possible.  */
   /* TODO:  Extend when KIND type parameters are implemented.  */
   if (ts.type == BT_CHARACTER && ts.u.cl && ts.u.cl->length)
-gfc_expr_check_typed (ts.u.cl->length, gfc_current_ns, true);
+{
+  /* Reject invalid type of specification expression for length.  */
+  if (ts.u.cl->length->ts.type != BT_INTEGER)
+	  return false;
+
+  gfc_expr_check_typed (ts.u.cl->length, gfc_current_ns, true);
+}
+
+  return true;
 }


@@ -4097,8 +4106,8 @@ loop:

   if (verify_now)
 	{
-	  check_function_result_typed ();
-	  function_result_typed = true;
+	  if (check_function_result_typed ())
+	function_result_typed = true;
 	}
 }

@@ -4111,8 +4120,8 @@ loop:
 case ST_IMPLICIT:
   if (!function_result_typed)
 	{
-	  check_function_result_typed ();
-	  function_result_typed = true;
+	  if (check_function_result_typed ())
+	function_result_typed = true;
 	}
   goto declSt;

diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index fb0745927ac..427f901a438 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -17419,7 +17419,9 @@ resolve_fntype (gfc_namespace *ns)
 	  }
   }

-  if (sym->ts.type == BT_CHARACTER)
+  if (sym->ts.type == BT_CHARACTER
+  && sym->ts.u.cl->length
+  && sym->ts.u.cl->length->ts.type == BT_INTEGER)
 gfc_traverse_expr (sym->ts.u.cl->length, sym, flag_fn_result_spec, 0);
 }

diff --git a/gcc/testsuite/gfortran.dg/pr96025.f90 b/gcc/testsuite/gfortran.dg/pr96025.f90
new file mode 100644
index 000..ce292bd9664
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr96025.f90
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! PR fortran/96025 - ICE in expr_check_typed_help
+! Contributed by G.Steinmetz
+
+program p
+  print *, f()
+contains
+  character(char(1)) function f() ! { dg-error "must be of INTEGER type" }
+f = 'f'
+  end
+end
--
2.35.3

[Bug rtl-optimization/108863] Unrolling could use range information

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|tree-optimization   |rtl-optimization

--- Comment #1 from Andrew Pinski  ---
(In reply to Thomas Koenig from comment #0)
> The range information about m does not appear to be propagated to
> the unroll passes.

Most likely because range information is not propagated at all to rtl level.
In this case even just non-zero bits might be enough...

[Bug tree-optimization/108863] Unrolling could use range information

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

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

Thomas Koenig  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization

[Bug tree-optimization/108863] New: Unrolling could use range information

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

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

Bug ID: 108863
   Summary: Unrolling could use range information
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tkoenig at gcc dot gnu.org
  Target Milestone: ---

Created attachment 54497
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54497=edit
Assembly code generated by test case

Looking a bit more at the code generated for the test code of PR108839.

For the test
$ cat u2.c
void foo(double *const restrict dx, double *dy, double da, long int n)
{
  long int m = n % 4;
  for (unsigned long i = 0; i < m; i++ )
dy[i] = dy[i] + da * dx[i];
}

a recently-ish trunk gives, with

$ gcc -S -O3  -funroll-all-loops -fno-tree-vectorize u2.c

far too much unrolling for a loop which can only be executed, at
most, four times (see attachment).

The range information about m does not appear to be propagated to
the unroll passes.

[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

--- Comment #10 from Martin Liška  ---
I've filed an upstream review request:
https://reviews.llvm.org/D144424

[PATCH] c++: constant non-copy-init is manifestly constant [PR108243]

[Patrick Palka via Gcc-patches]

According to [basic.start.static]/2 and [expr.const]/2, a variable
with static storage duration initialized with a constant initializer
has constant initialization, and such an initializer is manifestly
constant-evaluated.

We're already getting this right with copy initialization because in
that case check_initializer would consistently call store_init_value
(which for TREE_STATIC variables calls fold_non_dependent_init with
m_c_e=true).

But for direct (or default) initialization, we don't always call
store_init_value.  We instead however always call maybe_constant_init
from expand_default_init[1], albeit with m_c_e=false which means we
don't always get the "manifestly constant-evaluated" part right for
copy-init.

This patch fixes this by simply passing m_c_e=true to this call to
maybe_constant_init for static storage duration variables, mirroring
what store_init_value basically does.

[1]: this maybe_constant_init call isn't reached in the copy-init
case because there init is a CONSTRUCTOR rather than a TREE_LIST so
expand_default_init exits early returning an INIT_EXPR.  This INIT_EXPR
is ultimately what causes us to consistently hit the store_init_value
code path from check_initializer in the copy-init case.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?  Would it be suitable to backport this to the 12 branch since
it should only affect C++20 code?

PR c++/108243

gcc/cp/ChangeLog:

* init.cc (expand_default_init): Pass m_c_e=true instead of
=false to maybe_constant_init when initializing a variable
with static storage duration.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/is-constant-evaluated14.C: New test.
---
 gcc/cp/init.cc|   5 +-
 .../g++.dg/cpp2a/is-constant-evaluated14.C| 140 ++
 2 files changed, 144 insertions(+), 1 deletion(-)
 create mode 100644 gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated14.C

diff --git a/gcc/cp/init.cc b/gcc/cp/init.cc
index 52e96fbe590..705a5b3bdb6 100644
--- a/gcc/cp/init.cc
+++ b/gcc/cp/init.cc
@@ -2203,7 +2203,10 @@ expand_default_init (tree binfo, tree true_exp, tree 
exp, tree init, int flags,
   tree fn = get_callee_fndecl (rval);
   if (fn && DECL_DECLARED_CONSTEXPR_P (fn))
{
- tree e = maybe_constant_init (rval, exp);
+ bool manifestly_const_eval = false;
+ if (VAR_P (exp) && TREE_STATIC (exp))
+   manifestly_const_eval = true;
+ tree e = maybe_constant_init (rval, exp, manifestly_const_eval);
  if (TREE_CONSTANT (e))
rval = cp_build_init_expr (exp, e);
}
diff --git a/gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated14.C 
b/gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated14.C
new file mode 100644
index 000..365bca3fd9a
--- /dev/null
+++ b/gcc/testsuite/g++.dg/cpp2a/is-constant-evaluated14.C
@@ -0,0 +1,140 @@
+// PR c++/108243
+// Verify a variable with static storage duration initialized with a
+// constant initializer has constant initialization, and the initializer
+// is manifestly constant-evaluated.
+// { dg-do run { target c++11 } }
+// { dg-additional-options "-fdump-tree-original" }
+
+#include 
+
+struct A {
+  constexpr A(int n) : n(n), m(__builtin_is_constant_evaluated()) { }
+  constexpr A() : A(42) { }
+  void verify_mce() const {
+if (m != 1) __builtin_abort();
+  }
+  int n;
+  int m;
+};
+
+A a1 = {42};
+A a2{42};
+A a3(42);
+A a4;
+A a5{};
+
+void f() {
+  static A a1 = {42};
+  static A a2{42};
+  static A a3(42);
+  static A a4;
+  static A a5{};
+  for (auto& a : {a1, a2, a3, a4, a5})
+a.verify_mce();
+}
+
+template
+void g() {
+  static A a1 = {42};
+  static A a2{42};
+  static A a3(42);
+  static A a4;
+  static A a5{};
+  static A a6 = {N...};
+  static A a7{N...};
+  static A a8(N...);
+  for (auto& a : {a1, a2, a3, a4, a5, a6, a7, a8})
+a.verify_mce();
+}
+
+struct B {
+  static A a1;
+  static A a2;
+  static A a3;
+  static A a4;
+  static A a5;
+  static void verify_mce() {
+for (auto& a : {a1, a2, a3, a4, a5})
+  a.verify_mce();
+  }
+};
+
+A B::a1 = {42};
+A B::a2{42};
+A B::a3(42);
+A B::a4;
+A B::a5{};
+
+template
+struct BT {
+  static A a1;
+  static A a2;
+  static A a3;
+  static A a4;
+  static A a5;
+  static A a6;
+  static A a7;
+  static A a8;
+  static void verify_mce() {
+for (auto& a : {a1, a2, a3, a4, a5})
+  a.verify_mce();
+  }
+};
+
+template A BT::a1 = {42};
+template A BT::a2{42};
+template A BT::a3(42);
+template A BT::a4;
+template A BT::a5{};
+template A BT::a6 = {N...};
+template A BT::a7{N...};
+template A BT::a8(N...);
+
+#if __cpp_inline_variables
+struct BI {
+  static inline A a1 = {42};
+  static inline A a2{42};
+  static inline A a3;
+  static inline A a4{};
+  static void verify_mce() {
+for (auto& a : {a1, a2, a3, a4})
+  a.verify_mce();
+  }
+};
+
+template
+struct BIT {
+  static inline A a1 = {42};
+  static inline A a2{42};
+  static inline A 

[Bug fortran/108850] SELECT CASE within BLOCK construct in one subroutine prevents compilation of another subroutine named "SELECT"

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

The error also disappears if the order of the subroutines is interchanged.

[Bug c++/108848] template keyword incorreclty required to access template class static member of non-dependent expression using member syntax in dependent context

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-02-20
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=67965
 Ever confirmed|0   |1
Summary|Accessing class static  |template keyword
   |member of non-dependent |incorreclty required to
   |expression using member |access template class
   |syntax in dependent context |static member of
   |is rejected |non-dependent expression
   ||using member syntax in
   ||dependent context

--- Comment #1 from Andrew Pinski  ---
Reduced testcase to show it is not an issue with decltype:

template 
struct tag_t {
template 
static constexpr const Sig* smbr = nullptr; 
};

template 
inline constexpr tag_t tag {};
template
void f()
{
  auto t = tag.smbr;
}

[Bug middle-end/108847] unnecessary bitwise AND on boolean types

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords|ABI |
 Ever confirmed|0   |1
   Severity|normal  |enhancement
   Last reconfirmed||2023-02-20

--- Comment #1 from Andrew Pinski  ---
The workaround in this case is just to do:
((__INT32_TYPE__)value) < 0

instead of value>>31.

[Bug c++/108243] [10/11/12/13 Regression] Missed optimization for static const std::string_view(const char*)

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

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

--- Comment #9 from Patrick Palka  ---
(In reply to Jiang An from comment #8)
> This seems a bug, not merely missing of optimization. The string_view object
> should always be statically initialized, because it has static storage
> duration and its initializer is a constant iniitializer.

Good point.  It looks like we're inconsistent about static initialization here
--  we do it for suitable copy initialization but not for suitable direct
initialization:

static std::string_view foo1 = {"bar"}; // static initialization
static std::string_view foo2("bar");// dynamic initialization

[Bug c++/108550] [10/11/12/13 Regression] the type 'const auto' of 'constexpr' variable is not literal

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

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

--- Comment #6 from Marek Polacek  ---
Ah!

Started with

commit dc062b4986328bfeec3ebd744a9c116e28828bf0
Author: Jason Merrill 
Date:   Wed Aug 5 13:56:14 2015 -0400

re PR c++/66260 ([C++14] Failure to compile variable template with
recursively defined partial specialization)

PR c++/66260
PR c++/66596
PR c++/66649
PR c++/66923
* pt.c (lookup_template_variable): Use NULL_TREE for type.
(instantiate_template_1): Also set DECL_TI_ARGS based on
the immediate parent.
(tsubst_copy_and_build) [TEMPLATE_ID_EXPR]: Handle variable
templates.
(finish_template_variable): Add complain parm.
* cp-tree.h: Adjust.

From-SVN: r226642

[Bug c++/108550] [10/11/12/13 Regression] the type 'const auto' of 'constexpr' variable is not literal

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Marek Polacek from comment #4)
> Why is this a regression?  I'm not finding a released version that compiled
> this.

The testcase in comment #2 works both with GCC 5.1.0 and 5.2.0 at least as on
godbolt . GCC 5.3.0 fails though.

Re: Problems when building NT kernel drivers with GCC / LD

[Pali Rohár via Gcc]

On Tuesday 03 January 2023 11:06:26 Nick Clifton wrote:
> Hi Pali,
> 
> > Hello! I would like to remind this thread for gcc/binutils developers.
> > Most of these issues are still present and cause problems for compiling
> > native PE binary. If you have questions or you need any other information
> > please let me know.
> 
> Have bug reports been filed for the individual issues ?  If not, please
> could they be created.  The URLs for filing bugs are:
> 
>   https://sourceware.org/bugzilla/enter_bug.cgi?product=binutils
>   https://gcc.gnu.org/bugzilla/enter_bug.cgi
> 
> It would *really* help if the bug reports include a simple test case
> to reproduce the specific problems.
> 
> If it is not clear which tool is the source of the problem, then I would
> suggest choosing the binutils first.  If it turns out that specific issue
> is actually caused by a problem in gcc, the bug report can always be moved
> later on.
> 
> Cheers
>   Nick
> 

Hello! Just for a record, I filled individual issues to bugzilla:
https://sourceware.org/bugzilla/show_bug.cgi?id=30004
https://sourceware.org/bugzilla/show_bug.cgi?id=30139
https://sourceware.org/bugzilla/show_bug.cgi?id=30140
https://sourceware.org/bugzilla/show_bug.cgi?id=30141
https://sourceware.org/bugzilla/show_bug.cgi?id=30142
https://sourceware.org/bugzilla/show_bug.cgi?id=30143
https://sourceware.org/bugzilla/show_bug.cgi?id=30144
https://sourceware.org/bugzilla/show_bug.cgi?id=30145
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108849
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108851
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108852

[Bug c++/108550] [10/11/12/13 Regression] the type 'const auto' of 'constexpr' variable is not literal

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #4 from Marek Polacek  ---
Why is this a regression?  I'm not finding a released version that compiled
this.

[Bug c++/101073] [10/11/12/13 Regression] ICE in cxx_eval_constant_expression, at cp/constexpr.c:6941

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Fixed for GCC 13, not backporting.

Re: [PATCH] Fixing PR107411

[Qing Zhao via Gcc-patches]

> On Feb 20, 2023, at 10:17 AM, Jakub Jelinek  wrote:
> 
> On Mon, Feb 20, 2023 at 03:04:51PM +, Qing Zhao via Gcc-patches wrote:
>> 
>> 
>>> On Feb 17, 2023, at 5:35 PM, Jakub Jelinek  wrote:
>>> 
>>> On Fri, Feb 17, 2023 at 10:26:03PM +, Qing Zhao via Gcc-patches wrote:
 +else if (!DECL_NAME (lhs_var))
 +  {
 +char *lhs_var_name_str
 +  = xasprintf ("D.%u", DECL_UID (lhs_var));
>>> 
>>> Why xasprintf?
>> 
>> Just emulated the code in “gimple_add_init_for_auto_var” without thinking 
>> too much. -:)
>>> D.%u can be sprintfed into a fixed size automatic buffer,
>>> say 3 + (HOST_BITS_PER_INT + 2) / 3 would be a good upper bound for the size
>>> of the buffer.  Then you don't need to free it...
>> 
>> xasprintf is "like a sprintf but provided a pointer to malloc’d storage 
>> (without fail)”. If free the pointer properly, then it should be okay, right?
>> In addition to “no need to free”, what other benefit to use sprintf other 
>> than xasprintf?
> 
> xasprintf+free being significantly slower, exactly because it needs to
> malloc and free later, where both are fairly expensive functions.
> The glibc asprintf for short strings like the above uses a ~ 200 byte
> static buffer, stores in there, later mallocs the needed amount of memory
> and copies it there (so again, another waste because the string needs to be
> copied around), while for longer it can do perhaps many allocations and
> realloc at the end to the right size.
> The libiberty function actually performs the printing twice, once without
> writing result anywhere to compute size, then malloc, then again into the
> malloced buffer.

Okay, thanks a lot for the info.
I will replace xasprintf with sprintf for this patch.

Qing
> 
>   Jakub
> 

[Bug c++/101073] [10/11/12/13 Regression] ICE in cxx_eval_constant_expression, at cp/constexpr.c:6941

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

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

--- Comment #6 from CVS Commits  ---
The trunk branch has been updated by Marek Polacek :

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

commit r13-6145-gb2287a4d9a640fdc2caef6a067830ea65044deb7
Author: Marek Polacek 
Date:   Wed Feb 8 19:13:18 2023 -0500

c++: ICE with -fno-elide-constructors and trivial fn [PR101073]

In constexpr-nsdmi3.C, with -fno-elide-constructors, we don't elide
the Y::Y(const Y&) call used to initialize o.c.  So store_init_value
-> cxx_constant_init must constexpr-evaluate the call to Y::Y(const Y&)
in cxx_eval_call_expression.  It's a trivial function, so we do the
"Shortcut trivial constructor/op=" code and rather than evaluating
the function, we just create an assignment

  o.c = *(const struct Y &) (const struct Y *) &(&)->b

which is a MODIFY_EXPR, so the preeval code in cxx_eval_store_expression
clears .ctor and .object, therefore we can't replace the PLACEHOLDER_EXPR
whereupon we crash at

  /* A placeholder without a referent.  We can get here when
 checking whether NSDMIs are noexcept, or in massage_init_elt;
 just say it's non-constant for now.  */
  gcc_assert (ctx->quiet);

The PLACEHOLDER_EXPR can also be on the LHS as in constexpr-nsdmi10.C.
I don't think we can do much here, but I noticed that the whole
trivial_fn_p (fun) block is only entered when -fno-elide-constructors.
This is true since GCC 9; it wasn't easy to bisect what changes made it
so, but r240845 is probably one of them.  -fno-elide-constructors is an
option for experiments only so it's not clear to me why we'd still want
to shortcut trivial constructor/op=.  I propose to remove the code and
add a checking assert to make sure we're not getting a trivial_fn_p
unless -fno-elide-constructors.

PR c++/101073

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_call_expression): Replace shortcutting
trivial
constructor/op= with a checking assert.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-nsdmi3.C: New test.
* g++.dg/cpp1y/constexpr-nsdmi10.C: New test.

[Bug target/104921] aarch64: Assembler failure with vbfmlalbq_lane_f32 intrinsic

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

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #9 from Alex Coplan  ---
Fixed.

[Bug target/104921] aarch64: Assembler failure with vbfmlalbq_lane_f32 intrinsic

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Alex Coplan
:

https://gcc.gnu.org/g:617377cc1641e4f63617b192e224bc96dfbbd324

commit r10-11222-g617377cc1641e4f63617b192e224bc96dfbbd324
Author: Alex Coplan 
Date:   Mon Feb 6 14:32:21 2023 +

aarch64: Fix up bfmlal lane pattern [PR104921]

As the testcase shows, this pattern had an incorrect constraint leading
to GCC's output getting rejected by the assembler.

This patch fixes the constraint accordingly.

The test is split into two: one that can run without bf16 support from
the assembler and another that checks that the output actually assembles
when such support is available.

gcc/ChangeLog:

PR target/104921
* config/aarch64/aarch64-simd.md (aarch64_bfmlal_lanev4sf):
Use correct constraint for operand 3.

gcc/testsuite/ChangeLog:

PR target/104921
* gcc.target/aarch64/pr104921-1.c: New test.
* gcc.target/aarch64/pr104921-2.c: New test.
* gcc.target/aarch64/pr104921.x: Include file for new tests.

(cherry picked from commit 277e1f30a5e4e634304a7b8a532825119f0ea47f)

Re: [GSoC] Help needed for building on aarch64-apple-darwin22.1.0

[Iain Sandoe]

Hi Shengyu,

> On 20 Feb 2023, at 17:31, Shengyu Huang via Gcc  wrote:
> 

> After following the instructions here 
> (https://gcc.gnu.org/wiki/InstallingGCC) and here 
> (https://gcc.gnu.org/install/index.html), the `make` step simply fails with 
> “*** Configuration aarch64-apple-darwin22.1.0 not supported”. I found this 
> issue on Bugzilla (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168), but 
> the status says it’s suspended. Does it mean there is no way I can build from 
> source on my new laptop? My old MBP was unfortunately broken two months ago, 
> so the new laptop with Apple M2 is the only device I have at the moment.

I have a development branch for trunk here :
  https://github.com/iains/gcc-darwin-arm64
and for GCC-12 here:
 https://github.com/iains/gcc-12-branch

until I have some time to upstream the work (which could not be before GCC-14, 
I think) you can use these.

HTH,
Iain

[Bug target/96168] GCC support for Apple Silicon (Arm64) on macOS requested

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

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

--- Comment #14 from Iain Sandoe  ---
please see the Work In Progress here:

https://github.com/iains/gcc-darwin-arm64

this is a functional branch (although with known issues, since it is a
prototype)

[GSoC] Help needed for building on aarch64-apple-darwin22.1.0

[Shengyu Huang via Gcc]

Dear all,

After following the instructions here (https://gcc.gnu.org/wiki/InstallingGCC) 
and here (https://gcc.gnu.org/install/index.html), the `make` step simply fails 
with “*** Configuration aarch64-apple-darwin22.1.0 not supported”. I found this 
issue on Bugzilla (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96168), but the 
status says it’s suspended. Does it mean there is no way I can build from 
source on my new laptop? My old MBP was unfortunately broken two months ago, so 
the new laptop with Apple M2 is the only device I have at the moment.

Best,
Shengyu

[Bug c++/108829] [12 Regression] internal compiler error: in is_capture_proxy, at cp/lambda.cc:272

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #9 from Marek Polacek  ---
Fixed.

[Bug c++/108829] [12 Regression] internal compiler error: in is_capture_proxy, at cp/lambda.cc:272

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Marek Polacek
:

https://gcc.gnu.org/g:12cdc0e266f02c3ba4e80c3d971463ff507e049b

commit r12-9191-g12cdc0e266f02c3ba4e80c3d971463ff507e049b
Author: Marek Polacek 
Date:   Thu Feb 16 17:41:24 2023 -0500

c++: ICE with redundant capture [PR108829]

Here we crash in is_capture_proxy:

  /* Location wrappers should be stripped or otherwise handled by the
 caller before using this predicate.  */
  gcc_checking_assert (!location_wrapper_p (decl));

We only crash with the redundant capture:

  int abyPage = [=, abyPage] { ... }

because prune_lambda_captures is only called when there was a default
capture, and with [=] only abyPage won't be in LAMBDA_EXPR_CAPTURE_LIST.

The problem is that LAMBDA_CAPTURE_EXPLICIT_P wasn't propagated
correctly and so var_to_maybe_prune proceeded where it shouldn't.

Co-Authored by: Patrick Palka 

PR c++/108829

gcc/cp/ChangeLog:

* pt.cc (prepend_one_capture): Set LAMBDA_CAPTURE_EXPLICIT_P.
(tsubst_lambda_expr): Pass LAMBDA_CAPTURE_EXPLICIT_P to
prepend_one_capture.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/lambda/lambda-108829-2.C: New test.
* g++.dg/cpp0x/lambda/lambda-108829.C: New test.

(cherry picked from commit 02d8ab3e4e2f3d9dc12157a98c976d6698e71e29)

Re: [PATCH RFC 1/3] c++: add __is_deducible trait [PR105841]

[Patrick Palka via Gcc-patches]

On Sat, 18 Feb 2023, Jason Merrill via Gcc-patches wrote:

> Tested x86_64-pc-linux-gnu.  Since this is fixing experimental (C++20)
> functionality, I think it's reasonable to apply now; I'm interested in other
> opinions, and thoughts about the user-facing functionality.  I'm thinking to
> make it internal-only for GCC 13 at least by adding a space in the name, but
> does this look useful to the library?

IIUC this looks like a generalization of an __is_specialization_of trait
that returns whether a type is a specialization of a given class template,
which seems potentially useful for the library to me.  We already define
some ad-hoc predicates for testing this, e.g. __is_reverse_view,
__is_span etc in  as well as a more general __is_specialization_of
in  for templates that take only type arguments.  Using a built-in
trait should be more efficient.

> 
> -- 8< --
> 
> C++20 class template argument deduction for an alias template involves
> adding a constraint that the template arguments for the alias template can
> be deduced from the return type of the deduction guide for the underlying
> class template.  In the standard, this is modeled as defining a class
> template with a partial specialization, but it's much more efficient to
> implement with a trait that directly tries to perform the deduction.
> 
> The first argument to the trait is a template rather than a type, so various
> places needed to be adjusted to accommodate that.
> 
>   PR c++/105841
> 
> gcc/ChangeLog:
> 
>   * doc/extend.texi (Type Traits):: Document __is_deducible.
> 
> gcc/cp/ChangeLog:
> 
>   * cp-trait.def (IS_DEDUCIBLE): New.
>   * cxx-pretty-print.cc (pp_cxx_trait): Handle non-type.
>   * parser.cc (cp_parser_trait): Likewise.
>   * pt.cc (tsubst_copy_and_build): Likewise.
>   (type_targs_deducible_from): New.
>   (alias_ctad_tweaks): Use it.
>   * semantics.cc (trait_expr_value): Handle CPTK_IS_DEDUCIBLE.
>   (finish_trait_expr): Likewise.
>   * constraint.cc (diagnose_trait_expr): Likewise.
>   * cp-tree.h (type_targs_deducible_from): Declare.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/ext/is_deducible1.C: New test.
> ---
>  gcc/doc/extend.texi  |  4 +++
>  gcc/cp/cp-tree.h |  1 +
>  gcc/cp/constraint.cc |  3 ++
>  gcc/cp/cxx-pretty-print.cc   |  5 +++-
>  gcc/cp/parser.cc | 20 +++---
>  gcc/cp/pt.cc | 35 +---
>  gcc/cp/semantics.cc  | 11 
>  gcc/testsuite/g++.dg/ext/is_deducible1.C | 27 ++
>  gcc/cp/cp-trait.def  |  1 +
>  9 files changed, 92 insertions(+), 15 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/ext/is_deducible1.C
> 
> diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
> index 1ae68b0f20a..898701424ad 100644
> --- a/gcc/doc/extend.texi
> +++ b/gcc/doc/extend.texi
> @@ -25207,6 +25207,10 @@ type.  A diagnostic is produced if this requirement 
> is not met.
>  If @code{type} is a cv-qualified class type, and not a union type
>  ([basic.compound]) the trait is @code{true}, else it is @code{false}.
>  
> +@item __is_deducible (template, type)
> +If template arguments for @code{template} can be deduced from
> +@code{type} or obtained from default template arguments.
> +
>  @item __is_empty (type)
>  If @code{__is_class (type)} is @code{false} then the trait is @code{false}.
>  Otherwise @code{type} is considered empty if and only if: @code{type}
> diff --git a/gcc/cp/cp-tree.h b/gcc/cp/cp-tree.h
> index 5595335bbf7..e79150ca4d8 100644
> --- a/gcc/cp/cp-tree.h
> +++ b/gcc/cp/cp-tree.h
> @@ -7372,6 +7372,7 @@ extern tree fn_type_unification (tree, 
> tree, tree,
>bool, bool);
>  extern void mark_decl_instantiated   (tree, int);
>  extern int more_specialized_fn   (tree, tree, int);
> +extern bool type_targs_deducible_from(tree, tree);
>  extern void do_decl_instantiation(tree, tree);
>  extern void do_type_instantiation(tree, tree, tsubst_flags_t);
>  extern bool always_instantiate_p (tree);
> diff --git a/gcc/cp/constraint.cc b/gcc/cp/constraint.cc
> index 9374327008b..a28c85178fe 100644
> --- a/gcc/cp/constraint.cc
> +++ b/gcc/cp/constraint.cc
> @@ -3797,6 +3797,9 @@ diagnose_trait_expr (tree expr, tree args)
>inform (loc, "  %qT is not a reference that binds to a temporary "
> "object of type %qT (copy-initialization)", t1, t2);
>break;
> +case CPTK_IS_DEDUCIBLE:
> +  inform (loc, "  %qD is not deducible from %qT", t1, t2);
> +  break;
>  #define DEFTRAIT_TYPE(CODE, NAME, ARITY) \
>  case CPTK_##CODE:
>  #include "cp-trait.def"
> diff --git a/gcc/cp/cxx-pretty-print.cc b/gcc/cp/cxx-pretty-print.cc
> index bea52a608f1..4ebd957decd 100644
> --- 

Re: [committed] libstdc++: Fix uses of non-reserved names in simd header

[Jonathan Wakely via Gcc-patches]

On Mon, 20 Feb 2023 at 16:32, Matthias Kretz via Libstdc++
 wrote:
>
> Tested x86_64-pc-linux. Pushed to trunk.

OK for all relevant branches, thanks.

[committed] libstdc++: Fix uses of non-reserved names in simd header

[Matthias Kretz via Gcc-patches]

Tested x86_64-pc-linux. Pushed to trunk.

-- >8 --

Signed-off-by: Matthias Kretz 

libstdc++-v3/ChangeLog:

* include/experimental/bits/simd.h (__extract_part, split):
Use reserved name for template parameter.
---
 libstdc++-v3/include/experimental/bits/simd.h | 22 +--
 1 file changed, 11 insertions(+), 11 deletions(-)


--
──
 Dr. Matthias Kretz   https://mattkretz.github.io
 GSI Helmholtz Centre for Heavy Ion Research   https://gsi.de
 stdₓ::simd
──diff --git a/libstdc++-v3/include/experimental/bits/simd.h b/libstdc++-v3/include/experimental/bits/simd.h
index ffe72fa6ccf..2f615d13b73 100644
--- a/libstdc++-v3/include/experimental/bits/simd.h
+++ b/libstdc++-v3/include/experimental/bits/simd.h
@@ -3783,7 +3783,7 @@ template 
   _SimdWrapper<_Tp, _Np / _Total * _Combine>
   __extract_part(const _SimdWrapper<_Tp, _Np> __x);
 
-template 
   _GLIBCXX_SIMD_INTRINSIC auto
   __extract_part(const _SimdTuple<_Tp, _A0, _As...>& __x);
@@ -3896,19 +3896,19 @@ template 
 
 // split(simd) {{{
 template  / _V::size()>
-  enable_if_t == Parts * _V::size()
-	  && is_simd_v<_V>, array<_V, Parts>>
+	  size_t _Parts = simd_size_v / _V::size()>
+  enable_if_t == _Parts * _V::size()
+		&& is_simd_v<_V>, array<_V, _Parts>>
   split(const simd& __x)
   {
 using _Tp = typename _V::value_type;
-if constexpr (Parts == 1)
+if constexpr (_Parts == 1)
   {
 	return {simd_cast<_V>(__x)};
   }
 else if (__x._M_is_constprop())
   {
-	return __generate_from_n_evaluations>(
+	return __generate_from_n_evaluations<_Parts, array<_V, _Parts>>(
 		 [&](auto __i) constexpr _GLIBCXX_SIMD_ALWAYS_INLINE_LAMBDA {
 		   return _V([&](auto __j) constexpr _GLIBCXX_SIMD_ALWAYS_INLINE_LAMBDA
 			 { return __x[__i * _V::size() + __j]; });
@@ -3925,12 +3925,12 @@ template * const __element_ptr
 	= reinterpret_cast*>(&__data(__x));
-  return __generate_from_n_evaluations>(
+  return __generate_from_n_evaluations<_Parts, array<_V, _Parts>>(
 	   [&](auto __i) constexpr _GLIBCXX_SIMD_ALWAYS_INLINE_LAMBDA
 	   { return _V(__element_ptr + __i * _V::size(), vector_aligned); });
 #else
   const auto& __xx = __data(__x);
-  return __generate_from_n_evaluations>(
+  return __generate_from_n_evaluations<_Parts, array<_V, _Parts>>(
 	   [&](auto __i) constexpr _GLIBCXX_SIMD_ALWAYS_INLINE_LAMBDA {
 		 [[maybe_unused]] constexpr size_t __offset
 		   = decltype(__i)::value * _V::size();
@@ -3944,12 +3944,12 @@ template )
 {
   // normally memcpy should work here as well
-  return __generate_from_n_evaluations>(
+  return __generate_from_n_evaluations<_Parts, array<_V, _Parts>>(
 	   [&](auto __i) constexpr _GLIBCXX_SIMD_ALWAYS_INLINE_LAMBDA { return __x[__i]; });
 }
   else
 {
-  return __generate_from_n_evaluations>(
+  return __generate_from_n_evaluations<_Parts, array<_V, _Parts>>(
 	   [&](auto __i) constexpr _GLIBCXX_SIMD_ALWAYS_INLINE_LAMBDA {
 		 if constexpr (__is_fixed_size_abi_v)
 		   return _V([&](auto __j) constexpr _GLIBCXX_SIMD_ALWAYS_INLINE_LAMBDA {
@@ -3957,7 +3957,7 @@ template (__data(__x)));
+			 __extract_part(__data(__x)));
 	   });
 }
   }

Re: [Patch] Fortran: Avoid SAVE_EXPR for deferred-len char types

[Tobias Burnus]

Hi Richard, hi all,

On 20.02.23 13:46, Richard Biener wrote:

+  /* TODO: A more middle-end friendly alternative would be to use NULL_TREE
+as upper bound and store the value, e.g. as GFC_DECL_STRING_LEN.
+Caveat: this requires some cleanup throughout the code to consistently
+use some wrapper function.  */
+  gcc_assert (TREE_CODE (TYPE_SIZE_UNIT (type)) == SAVE_EXPR);
+  tree tmp = TREE_TYPE (TYPE_SIZE (eltype));

...

you are probably breaking type sharing here.  You could use
build_array_type_1 and pass false for 'shared' to get around that.  Note
that there's also canonical type building done in case 'eltype' is not
canonical itself.


My feeling is that this is already somewhat broken. Currently, there
is one type per decl as each has its own artificial length variable.
I have no idea how this will be handled in the ME in terms of alias
analysis. And whether shared=false makes sense here and what effect
is has. (Probably yes.)

In principle,
  integer(kind=8) .str., .str2;
  character(kind=1)[1:.str] * str;
  character(kind=1)[1:.str2] * str2;
have the same type and iff .str == .str at runtime, they can alias.
Example:
  str2 = str;
  .str2 = .str;

I have no idea how the type analysis currently works (with or without SAVE_EXPR)
nor what effect shared=false has in this case.


The solution to the actual problem is a hack - you are relying on
re-evaluation of TYPE_SIZE, and for that, only from within accesses
from inside the frontend?


I think this mostly helps with access inside the FE of the type 'size =
TYPE_SIZE_UNIT(type)', which is used surprisingly often and is often
directly evaluated (i.e. assigned to a temporary).


Since gimplification will produce the result into a single temporary again, re-storing 
the "breakage".
So, does it_really_  fix things?


It does seem to fix cases which do  'size = TYPE_SIZE_UNIT (type);' in
the front end and then uses this size expression. Thus, there are fixed.
However, there are many cases where things go wrong - with and without
the patch. I keep discovering more and more :-(

* * *

I still think that the proper way is to have NULL_TREE as upper value
would be better in several ways, except that there is (too) much code
which relies on TYPE_UNIT_SIZE to work. (There are 117 occurrences).
Additionally, there is more code doing assumptions in this area.

Thus, the question is whether it makes sense as hackish partial solution
or whether it should remain in the current broken stage until it is
fixed properly.

Tobias,

who would like to have more time for fixing such issues.

-
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

[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

--- Comment #9 from Martin Liška  ---
(In reply to Jakub Jelinek from comment #8)
> Sure, we want to keep using libbacktrace.  But libbacktrace can be extended
> if Ian is ok with it, or some extensions can be done on the
> libsanitizer/libbacktrace side of it.

I've got a quite small patch that partially reverts the LLVM commit and does a
fallback to Global::location if Symbolizer can't find a location. I'm going to
suggest it to upstream.

[Bug c++/108829] [12 Regression] internal compiler error: in is_capture_proxy, at cp/lambda.cc:272

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[12/13 Regression] internal |[12 Regression] internal
   |compiler error: in  |compiler error: in
   |is_capture_proxy, at|is_capture_proxy, at
   |cp/lambda.cc:272|cp/lambda.cc:272

--- Comment #7 from Marek Polacek  ---
Fixed on trunk so far.

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

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

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

--- Comment #8 from Jakub Jelinek  ---
Sure, we want to keep using libbacktrace.  But libbacktrace can be extended if
Ian is ok with it, or some extensions can be done on the
libsanitizer/libbacktrace side of it.

RE: [PATCH] [arm] disable aes-1742098 mitigation for a72 combine tests

[Kyrylo Tkachov via Gcc-patches]

Hi Alexandre,

> -Original Message-
> From: Alexandre Oliva 
> Sent: Friday, February 17, 2023 7:06 AM
> To: gcc-patches@gcc.gnu.org
> Cc: ni...@redhat.com; Richard Earnshaw ;
> ramana@gmail.com; Kyrylo Tkachov 
> Subject: [PATCH] [arm] disable aes-1742098 mitigation for a72 combine tests
> 
> 
> The expected asm output for aes-fuse-[12].c does not correspond to
> that which is generated when -mfix-cortex-a57-aes-1742098 is enabled.
> It was introduced after the test, and enabled by default for the
> selected processor.  Disabling the option restores the circumstance
> that was tested for.
> 
> Regstrapped on x86_64-linux-gnu.
> Tested on arm-vxworks7 (gcc-12) and arm-eabi (trunk).  Ok to install?
> 
> for  gcc/testsuite/ChangeLog
> 
>   * gcc.target/arm/aes-fuse-1.c: Add
>   -mno-fix-cortex-a57-aes-1742098.
>   * gcc.target/arm/aes-fuse-2.c: Likewise.
> ---
>  gcc/testsuite/gcc.target/arm/aes-fuse-1.c |4 
>  gcc/testsuite/gcc.target/arm/aes-fuse-2.c |4 
>  2 files changed, 8 insertions(+)
> 
> diff --git a/gcc/testsuite/gcc.target/arm/aes-fuse-1.c
> b/gcc/testsuite/gcc.target/arm/aes-fuse-1.c
> index 27b08aeef7ba7..6ffb4991cca69 100644
> --- a/gcc/testsuite/gcc.target/arm/aes-fuse-1.c
> +++ b/gcc/testsuite/gcc.target/arm/aes-fuse-1.c
> @@ -2,6 +2,10 @@
>  /* { dg-require-effective-target arm_crypto_ok } */
>  /* { dg-add-options arm_crypto } */
>  /* { dg-additional-options "-mcpu=cortex-a72 -O3 -dp" } */
> +/* The mitigation applies to a72 by default, and protects the CRYPTO_AES
> +   inputs, such as the explicit xor ops, from being combined like test used 
> to
> +   expect.  */
> +/* { dg-additional-options "-mno-fix-cortex-a57-aes-1742098" } */

Actually the -mcpu=cortex-a72 here is significant only in that it's one of the 
CPUs that enables AES/AESMC fusion.
So rather than overriding this awkward part with 
-mno-fix-cortex-a57-aes-1742098 I'd rather just select a different
CPU that enables that fusion and isn't afflicted by this workaround, such as 
-mcpu=cortex-a53.
More broadly, I think we should be enabling tune_params::FUSE_AES_AESMC for the 
generic target in A profile, but that would be a non-testsuite change.

Ok with changing the -mcpu option instead.
Thanks,
Kyrill

> 
>  #include 
> 
> diff --git a/gcc/testsuite/gcc.target/arm/aes-fuse-2.c
> b/gcc/testsuite/gcc.target/arm/aes-fuse-2.c
> index 1266a28753169..b72479c0e5726 100644
> --- a/gcc/testsuite/gcc.target/arm/aes-fuse-2.c
> +++ b/gcc/testsuite/gcc.target/arm/aes-fuse-2.c
> @@ -2,6 +2,10 @@
>  /* { dg-require-effective-target arm_crypto_ok } */
>  /* { dg-add-options arm_crypto } */
>  /* { dg-additional-options "-mcpu=cortex-a72 -O3 -dp" } */
> +/* The mitigation applies to a72 by default, and protects the CRYPTO_AES
> +   inputs, such as the explicit xor ops, from being combined like test used 
> to
> +   expect.  */
> +/* { dg-additional-options "-mno-fix-cortex-a57-aes-1742098" } */
> 
>  #include 
> 
> 
> --
> 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 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

--- Comment #7 from Martin Liška  ---
So clang uses __sanitizer::LLVMSymbolizer:

$ clang jhead.i -fsanitize=address -g && strace -f -s512 ./a.out 2>&1 | grep
execv
execve("./a.out", ["./a.out"], 0x7fffd520 /* 116 vars */) = 0
[pid  5529] execve("/usr/bin/llvm-symbolizer", ["/usr/bin/llvm-symbolizer",
"--demangle", "--inlines", "--default-arch=x86_64"], 0x7fffd528 /* 116 vars
*/) = 0

which is probably not something we want to use.

[committed] RISC-V: prefetch.* only take base register with zero-offset for the address

[Kito Cheng via Gcc-patches]

Catched by running gcc.c-torture/execute/builtin-prefetch-2.c with
-march=rv64gc_zicbop.

gcc/ChangeLog:

* config/riscv/riscv.md (prefetch): Use r instead of p for the
address operand.
(riscv_prefetchi_): Ditto.
---
 gcc/config/riscv/riscv.md | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/config/riscv/riscv.md b/gcc/config/riscv/riscv.md
index 487059ebe97..a5507fadc2d 100644
--- a/gcc/config/riscv/riscv.md
+++ b/gcc/config/riscv/riscv.md
@@ -3066,7 +3066,7 @@ (define_insn "riscv_zero_"
 )
 
 (define_insn "prefetch"
-  [(prefetch (match_operand 0 "address_operand" "p")
+  [(prefetch (match_operand 0 "address_operand" "r")
  (match_operand 1 "imm5_operand" "i")
  (match_operand 2 "const_int_operand" "n"))]
   "TARGET_ZICBOP"
@@ -3080,7 +3080,7 @@ (define_insn "prefetch"
 })
 
 (define_insn "riscv_prefetchi_"
-  [(unspec_volatile:X [(match_operand:X 0 "address_operand" "p")
+  [(unspec_volatile:X [(match_operand:X 0 "address_operand" "r")
   (match_operand:X 1 "imm5_operand" "i")]
   UNSPECV_PREI)]
   "TARGET_ZICBOP"
-- 
2.37.2

[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599

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

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

--- Comment #7 from Jakub Jelinek  ---
The patches (3 variants) have been posted and are awaiting review.  I've pinged
them twice.

[Bug c/106465] ICE for VLA in struct in parameter of nested function

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #3 from Martin Uecker  ---
Created attachment 54496
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54496=edit
patch for C FE


Here is a patch.

Re: [PATCH] Fixing PR107411

[Jakub Jelinek via Gcc-patches]

On Mon, Feb 20, 2023 at 03:04:51PM +, Qing Zhao via Gcc-patches wrote:
> 
> 
> > On Feb 17, 2023, at 5:35 PM, Jakub Jelinek  wrote:
> > 
> > On Fri, Feb 17, 2023 at 10:26:03PM +, Qing Zhao via Gcc-patches wrote:
> >> +else if (!DECL_NAME (lhs_var))
> >> +  {
> >> +char *lhs_var_name_str
> >> +  = xasprintf ("D.%u", DECL_UID (lhs_var));
> > 
> > Why xasprintf?
> 
> Just emulated the code in “gimple_add_init_for_auto_var” without thinking too 
> much. -:)
> >  D.%u can be sprintfed into a fixed size automatic buffer,
> > say 3 + (HOST_BITS_PER_INT + 2) / 3 would be a good upper bound for the size
> > of the buffer.  Then you don't need to free it...
> 
> xasprintf is "like a sprintf but provided a pointer to malloc’d storage 
> (without fail)”. If free the pointer properly, then it should be okay, right?
> In addition to “no need to free”, what other benefit to use sprintf other 
> than xasprintf?

xasprintf+free being significantly slower, exactly because it needs to
malloc and free later, where both are fairly expensive functions.
The glibc asprintf for short strings like the above uses a ~ 200 byte
static buffer, stores in there, later mallocs the needed amount of memory
and copies it there (so again, another waste because the string needs to be
copied around), while for longer it can do perhaps many allocations and
realloc at the end to the right size.
The libiberty function actually performs the printing twice, once without
writing result anywhere to compute size, then malloc, then again into the
malloced buffer.

Jakub

[Bug other/108464] [13 Regression] Broken -fdebug-prefix-map since r13-3599

[orion at cora dot nwra.com via Gcc-bugs]

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

--- Comment #6 from Orion Poplawski  ---
So, there was quite the initial flurry of activity here and then nothing.  Any
chance we could get some more movement here?  It's breaking a ccache test for
one.  Thank you.

[Bug target/108862] [13 Regression] CryptX miscompilation on power9 since r13-2107

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

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 54495
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54495=edit
gcc13-pr108862.patch

Variant patch, instead of creating another temporary and moving it we can just
do the highpart (which goes into temporary) first, then lowpart, then addition
which depends on the highpart.
Strangely, with this patch one gets the loop unrolled (2 handled iterations at
once), while with the earlier patch it is not.

Re: [PATCH] Fixing PR107411

[Qing Zhao via Gcc-patches]

> On Feb 17, 2023, at 5:35 PM, Jakub Jelinek  wrote:
> 
> On Fri, Feb 17, 2023 at 10:26:03PM +, Qing Zhao via Gcc-patches wrote:
>> +  else if (!DECL_NAME (lhs_var))
>> +{
>> +  char *lhs_var_name_str
>> += xasprintf ("D.%u", DECL_UID (lhs_var));
> 
> Why xasprintf?

Just emulated the code in “gimple_add_init_for_auto_var” without thinking too 
much. -:)
>  D.%u can be sprintfed into a fixed size automatic buffer,
> say 3 + (HOST_BITS_PER_INT + 2) / 3 would be a good upper bound for the size
> of the buffer.  Then you don't need to free it...

xasprintf is "like a sprintf but provided a pointer to malloc’d storage 
(without fail)”. If free the pointer properly, then it should be okay, right?
In addition to “no need to free”, what other benefit to use sprintf other than 
xasprintf?

Qing
> 
>> +  if (strcmp (lhs_var_name_str, var_name_str) == 0)
>> +{
>> +  free (lhs_var_name_str);
>> +  return;
>> +}
>> +  free (lhs_var_name_str);
>> +}
>> +}
>>gcc_assert (var_name_str && var_def_stmt);
>>  }
>> }
>> -- 
>> 2.31.1
> 
>   Jakub

Prototype 'GOMP_enable_pinned_mode' (was: [PATCH 08/17] openmp: -foffload-memory=pinned)

[Thomas Schwinge]

Hi!

On 2022-07-07T23:18:03+0100, Andrew Stubbs  wrote:
> On 07/07/2022 12:54, Tobias Burnus wrote:
>> On 07.07.22 12:34, Andrew Stubbs wrote:
>>> Implement the -foffload-memory=pinned option such that libgomp is
>>> instructed to enable fully-pinned memory at start-up.  The option is
>>> intended to provide a performance boost to certain offload programs
>>> without
>>> modifying the code.
>> ...
>>> gcc/ChangeLog:
>>>
>>> * omp-builtins.def (BUILT_IN_GOMP_ENABLE_PINNED_MODE): New.
>>> * omp-low.cc (omp_enable_pinned_mode): New function.
>>> (execute_lower_omp): Call omp_enable_pinned_mode.
>>>
>>> libgomp/ChangeLog:
>>>
>>> * config/linux/allocator.c (always_pinned_mode): New variable.
>>> (GOMP_enable_pinned_mode): New function.
>>> (linux_memspace_alloc): Disable pinning when always_pinned_mode set.
>>> (linux_memspace_calloc): Likewise.
>>> (linux_memspace_free): Likewise.
>>> (linux_memspace_realloc): Likewise.
>>> * libgomp.map: Add GOMP_enable_pinned_mode.
>>> * testsuite/libgomp.c/alloc-pinned-7.c: New test.
>>> ...
>> ...
>>> --- a/gcc/omp-low.cc
>>> +++ b/gcc/omp-low.cc
>>> @@ -14620,6 +14620,68 @@ lower_omp (gimple_seq *body, omp_context *ctx)
>>> input_location = saved_location;
>>>   }
>>> +/* Emit a constructor function to enable -foffload-memory=pinned
>>> +   at runtime.  Libgomp handles the OS mode setting, but we need to
>>> trigger
>>> +   it by calling GOMP_enable_pinned mode before the program proper
>>> runs.  */
>>> +
>>> +static void
>>> +omp_enable_pinned_mode ()
>>
>> Is there a reason not to use the mechanism of OpenMP's 'requires'
>> directive for this?

I agree.  (But I'm not working on that, for avoidance of doubt.)

>> (Okay, I have to admit that the final patch was only committed on
>> Monday. But still ...)
>
> Possibly, I had most of this done before then. I'll have a look next
> time I visit this patch.

Until then, let's at least document/verify 'GOMP_enable_pinned_mode';
I've pushed to devel/omp/gcc-12
commit 9657d906869e098340c23118c2eb8592d9e77ac5
"Prototype 'GOMP_enable_pinned_mode'", see attached.


Grüße
 Thomas


-
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
>From 9657d906869e098340c23118c2eb8592d9e77ac5 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Mon, 20 Feb 2023 15:29:44 +0100
Subject: [PATCH] Prototype 'GOMP_enable_pinned_mode'

Fix-up for og12 commit 842df187487f5b16ae29bbe7e9acd79661a9df48
"openmp: -foffload-memory=pinned".  No functional change.

	libgomp/
	* libgomp_g.h (GOMP_enable_pinned_mode): New.
---
 libgomp/ChangeLog.omp | 2 ++
 libgomp/libgomp_g.h   | 1 +
 2 files changed, 3 insertions(+)

diff --git a/libgomp/ChangeLog.omp b/libgomp/ChangeLog.omp
index c5a7860478e..e4475093055 100644
--- a/libgomp/ChangeLog.omp
+++ b/libgomp/ChangeLog.omp
@@ -1,5 +1,7 @@
 2023-02-20  Thomas Schwinge  
 
+	* libgomp_g.h (GOMP_enable_pinned_mode): New.
+
 	* config/linux/allocator.c (linux_memspace_alloc): Add 'init0'
 	formal parameter.  Adjust all users.
 	(linux_memspace_alloc, linux_memspace_free): Attempt to allocate
diff --git a/libgomp/libgomp_g.h b/libgomp/libgomp_g.h
index ece1f97a61f..fe66a53d94a 100644
--- a/libgomp/libgomp_g.h
+++ b/libgomp/libgomp_g.h
@@ -375,6 +375,7 @@ extern void GOMP_teams_reg (void (*) (void *), void *, unsigned, unsigned,
 
 extern void *GOMP_alloc (size_t, size_t, uintptr_t);
 extern void GOMP_free (void *, uintptr_t);
+extern void GOMP_enable_pinned_mode (void);
 
 /* error.c */
 
-- 
2.25.1

[Bug target/108862] [13 Regression] CryptX miscompilation on power9 since r13-2107

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

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 54494
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54494=edit
gcc13-pr108862.patch

Untested fix.

Re: MicroBlaze symver attribute support

[Joel Sherrill]

On Mon, Feb 20, 2023 at 7:56 AM Vincent Fazio via Gcc 
wrote:

> Michael, all,
>
> Regarding:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101766
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102110
>
> If I understand correctly, since the GCC MicroBlaze targets generate ELF
> images, it would seem there's no technical reason why `__attribute__
> ((symver ...))` cannot be supported?
>
> The issue seems to be that the MicroBlaze targets in config.gcc do not
> include elfos.h
> https://github.com/gcc-mirror/gcc/blob/master/gcc/config.gcc#L2369
>
> Which defines `ASM_OUTPUT_SYMVER_DIRECTIVE`
> https://github.com/gcc-mirror/gcc/blob/master/gcc/config/elfos.h#L259
>
> Which is necessary for
> https://github.com/gcc-mirror/gcc/blob/master/gcc/varasm.cc#L6260
>
> Changing the targets to include elfos.h leads to a number of conflicts with
> the target specific header (config/microblaze/microblaze.h).
>
> Should `ASM_OUTPUT_SYMVER_DIRECTIVE` be copied into
> config/microblaze/microblaze.h or should the MicroBlaze targets and header
> be reworked to support elfos.h?
>

IMO reworked to include elfos.h. During the RTEMS port, we noticed that
some quirks on the microblaze gcc because it isn't using elfos.h. This
likely
will mean it will be updated as a side-effect of normal GCC maintenance
instead of being an odd singleton which doesn't share.

>
> I'm asking because I've seen a number of projects run into this issue (xz,
> elfutils, libfuse, libkcapi, cryptsetup).
>

And RTEMS.

--joel

>
> Thanks,
> -Vincent
>