[Bug c++/107897] [13 Regression] ICE in verify_curr_properties, at passes.cc:2201

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

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

--- Comment #1 from Richard Biener  ---
(gdb) p fn->curr_properties
$4 = 92431

that looks like garbage.  We likely cut off processing one of the functions
because of the error (and failed to initialize ->curr_properties when
allocating struct function).  In particular we gate off build_ssa_passes
but not consistently all other small IPA passes and target_clone is the
only one requiring any SSA/CFG properties.

I'm testing a patch for the ICE-after-error, the error remains.

Re: [PATCH] [x86] Fix unrecognizable insn due to illegal immediate_operand (const_int 255) of QImode.

[Hongtao Liu via Gcc-patches]

On Mon, Nov 28, 2022 at 9:06 PM liuhongt  wrote:
>
> For __builtin_ia32_vec_set_v16qi (a, -1, 2) with
> !flag_signed_char. it's transformed to
> __builtin_ia32_vec_set_v16qi (_4, 255, 2) in the gimple,
> and expanded to (const_int 255) in the rtl. But for immediate_operand,
> it expects (const_int 255) to be signed extended to
> (const_int -1). The mismatch caused an unrecognizable insn error.
>
> expand_expr_real_1 generates (const_int 255) without considering the target 
> mode.
> I guess it's on purpose, so I'll leave that alone and only change the expander
> in the backend. After applying convert_modes to (const_int 255),
> it's transformed to (const_int -1) which fix the issue.
>
> Bootstrapped and regtested x86_64-pc-linux-gnu{-m32,}.
> Ok for trunk(and backport to GCC-10/11/12 release branches)?
Drop this patch since it's not a complete solution, there're also
other QI builtins which is not handled.
>
> gcc/ChangeLog:
>
> PR target/107863
> * config/i386/i386-expand.cc (ix86_expand_vec_set_builtin):
> Convert op1 to target mode whenever mode mismatch.
>
> gcc/testsuite/ChangeLog:
>
> * gcc.target/i386/pr107863.c: New test.
> ---
>  gcc/config/i386/i386-expand.cc   | 2 +-
>  gcc/testsuite/gcc.target/i386/pr107863.c | 8 
>  2 files changed, 9 insertions(+), 1 deletion(-)
>  create mode 100644 gcc/testsuite/gcc.target/i386/pr107863.c
>
> diff --git a/gcc/config/i386/i386-expand.cc b/gcc/config/i386/i386-expand.cc
> index 0373c3614a4..c639ee3a9f7 100644
> --- a/gcc/config/i386/i386-expand.cc
> +++ b/gcc/config/i386/i386-expand.cc
> @@ -12475,7 +12475,7 @@ ix86_expand_vec_set_builtin (tree exp)
>op1 = expand_expr (arg1, NULL_RTX, mode1, EXPAND_NORMAL);
>elt = get_element_number (TREE_TYPE (arg0), arg2);
>
> -  if (GET_MODE (op1) != mode1 && GET_MODE (op1) != VOIDmode)
> +  if (GET_MODE (op1) != mode1)
>  op1 = convert_modes (mode1, GET_MODE (op1), op1, true);
>
>op0 = force_reg (tmode, op0);
> diff --git a/gcc/testsuite/gcc.target/i386/pr107863.c 
> b/gcc/testsuite/gcc.target/i386/pr107863.c
> new file mode 100644
> index 000..99fd85d9765
> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/i386/pr107863.c
> @@ -0,0 +1,8 @@
> +/* { dg-do compile } */
> +/* { dg-options "-mavx2 -O" } */
> +
> +typedef char v16qi __attribute__((vector_size(16)));
> +
> +v16qi foo(v16qi a){
> +  return __builtin_ia32_vec_set_v16qi (a, -1, 2);
> +}
> --
> 2.27.0
>


-- 
BR,
Hongtao

[Bug c++/107906] New: Function template specialization given weak rather than local symbol

[herring at lanl dot gov via Gcc-bugs]

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

Bug ID: 107906
   Summary: Function template specialization given weak rather
than local symbol
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: herring at lanl dot gov
  Target Milestone: ---

Current trunk, given 

  template using X=int;
  namespace {
template using Y=int;
  }

  template class Q> void f() {}
  template void f();

  void (*fp)()=f;

emits weak symbols for both specializations of f, despite the fact that a
different "void f<(anonymous namespace)::Y>()" might be defined in another
translation unit (perhaps as an explicit specialization).

[Bug c++/66671] Failure to create a new family of templates for template alias

[herring at lanl dot gov via Gcc-bugs]

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

S. Davis Herring  changed:

   What|Removed |Added

 CC||herring at lanl dot gov

--- Comment #2 from S. Davis Herring  ---
CWG1286 suggests that perhaps such a trivial alias template as Z ought to
actually be interchangeable with Y.

[Bug target/107863] [10/11/12/13 Regression] ICE with unrecognizable insn when using -funsigned-char with some SSE/AVX builtins

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Hongtao.liu  ---
I notice there's TARGET_PROMOTE_PROTOTYPES which can prevent unsigend char 255
be extended to int 255 which is a more perfect solution to this problem. But we
can only get fntype in this hook, ideally we should check fndecl to make sure
it's target specific builtins since we don't want to prevent promotion for args
in other normal functions.

Re: [PATCH] RISC-V: Add attributes for VSETVL PASS

[Palmer Dabbelt]

On Mon, 28 Nov 2022 20:49:00 PST (-0800), jeffreya...@gmail.com wrote:



On 11/28/22 19:56, Palmer Dabbelt wrote:

On Mon, 28 Nov 2022 17:46:16 PST (-0800), juzhe.zh...@rivai.ai wrote:

Yeah, I personally want to support RVV intrinsics in GCC13. As RVV
intrinsic is going to release soon next week.


OK, that's fine with me -- I was leaning that way, and I think Jeff only
had a weak opposition.  Are there any more changes required outside the
RISC-V backend?  Those would be the most controversial and are already
late, but if it's only backend stuff at this point then I'm OK taking
the risk for a bit longer.

Jeff?

It's not ideal, but I can live with the bits going into gcc-13 as long
as they don't bleed out of the RISC-V port.


Ya, that's kind of what happens every release though (and not just in 
GCC, it's that way for everything).  Maybe for gcc-14 we can commit to 
taking the stage1/stage3 split seriously in RISC-V land?


It's early enough that nobody should be surprised, and even if we don't 
need to do it as per the GCC rules we're going to go crazy if we keep 
letting things go until the last minute like this.  I think the only 
real fallout we've had so far was the B stuff in binutils, but we've 
been exceedingly close to broken releases way too many times and it's 
going to bite us at some point.

[Bug middle-end/107905] 2x slowdown versus CLANG and ICL

[sanmayce at sanmayce dot com via Gcc-bugs]

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

--- Comment #2 from Georgi  ---
> I don't see that causing a 2x slow down though.

Same here, yet, the results prove that not only on Zen2, on top of that on
i5-7200U @2.5GHz and Windows 10, this function takes 203s, cannot figure it
out, could you run the wildtest_GCC executable (or compile to it) and see it is
so?

Re: [PATCH] RISC-V: Support the ins "rol" with immediate operand

[Jeff Law via Gcc-patches]

On 11/28/22 18:53, Feng Wang wrote:

on 2022-11-28 23:39  Jeff Law wrote:



On 11/27/22 19:14, Feng Wang wrote:

From: wangfeng 

There is no Immediate operand of ins "rol" accroding to the B-ext,
so the immediate operand should be loaded into register at first.
But we can convert it to the ins "rori" or "roriw", and then one
immediate load ins can be reduced.

Please refer to the following use cases:
unsigned long foo2(unsigned long rs1)
{
   return (rs1 << 10) | (rs1 >> 54);
}

The complier result is:
li  a1,10
rol a0,a0,a1

This patch will generate one ins
rori a0,a0,54

gcc/ChangeLog:

   * config/riscv/bitmanip.md: Add immediate_operand support in rotl 
RTL pattern

gcc/testsuite/ChangeLog:

   * gcc.target/riscv/zbb-rol-ror-04.c: New test.
   * gcc.target/riscv/zbb-rol-ror-05.c: New test.


So this arrived after stage1 close and I'm not aware of an existing BZ
around this issue, so I'd tend to think this should wait for stage1 to
re-open in the spring.


 From a technical standpoint, would it be better to hand this in a more
generic way?   ie, when converting from gimple into RTL, if we want to
generate a rotate left by immediate and don't have a suitable insn, then
change it to a rotate right by an adjusted immediate.    This could
probably be done in optabs.cc::expand_binop.


We might need similar code in combine.cc or simplify-rtx.cc since some
rotate cases (or exposure of the constant) may not show up until later
in the RTL pipeline.


Anyway, doing this in a more generic way seems like it's worth
investigating.


jeff


Hi jeff,

Thanks for your reply. In the currently it will judge the rotate shift number 
when converting from
gimple into RTL, if the shift number bigger than mode_size/2, then reverse the 
rotate direction.
I think the purpose of this process is to handle rotate shift quickly. I will 
think about your advice
and try to modify it in the expand pass.
Yea, in the past there were targets where the cost of a shift or rotate 
was proportional to the number of bits shifted.  So for a rotate in 
particular it was advantageous to reverse the rotation if the count was 
more than mode_size/2.


I suspect such processors are a lot less common now than in the past. 
But we can probably utilize some of that code to suit our needs.


Jeff

Re: [PATCH] RISC-V: Add attributes for VSETVL PASS

[Jeff Law via Gcc-patches]

On 11/28/22 19:56, Palmer Dabbelt wrote:

On Mon, 28 Nov 2022 17:46:16 PST (-0800), juzhe.zh...@rivai.ai wrote:
Yeah, I personally want to support RVV intrinsics in GCC13. As RVV 
intrinsic is going to release soon next week.


OK, that's fine with me -- I was leaning that way, and I think Jeff only 
had a weak opposition.  Are there any more changes required outside the 
RISC-V backend?  Those would be the most controversial and are already 
late, but if it's only backend stuff at this point then I'm OK taking 
the risk for a bit longer.


Jeff?
It's not ideal, but I can live with the bits going into gcc-13 as long 
as they don't bleed out of the RISC-V port.


Jeff

Division by zero on A53 which does not raise an exception

[Stephen Smith via Gcc]

I am working on a project which is using an A53 core.   The core does not 
raise an exception if there is a division by zero (for either integer or 
floating point division).

The designers chose to set status bits for the floating point case but not 
raise an exception.With the integer division no status bits are set.

Does the GCC  compilers or Binutils assembler and linker have a way to deal 
with this issue on the ARM A53 processor?  

For Linux, was special support added in the kernel to help Glibc with this 
issue?  If so, I will comb the linux source tree.

My project is using GCC 7.3.0

Re: [PATCH V2] Use subscalar mode to move struct block for parameter

[Jiufu Guo via Gcc-patches]

Hi Jeff,

Thanks a lot for your comments!

Jeff Law  writes:

> On 11/22/22 19:58, Jiufu Guo wrote:
>> Hi Jeff,
>>
>> Thanks a lot for your comments!
>>
>> Jeff Law  writes:
>>
>>> On 11/20/22 20:07, Jiufu Guo wrote:
 Jiufu Guo  writes:

> Hi,
>
> As mentioned in the previous version patch:
> https://gcc.gnu.org/pipermail/gcc-patches/2022-October/604646.html
> The suboptimal code is generated for "assigning from parameter" or
> "assigning to return value".
> This patch enhances the assignment from parameters like the below
> cases:
> /case1.c
> typedef struct SA {double a[3];long l; } A;
> A ret_arg (A a) {return a;}
> void st_arg (A a, A *p) {*p = a;}
>
> case2.c
> typedef struct SA {double a[3];} A;
> A ret_arg (A a) {return a;}
> void st_arg (A a, A *p) {*p = a;}
>
> For this patch, bootstrap and regtest pass on ppc64{,le}
> and x86_64.
cut...
 + : word_mode;
 +  int mode_size = GET_MODE_SIZE (mode).to_constant ();
 +  int size = INTVAL (expr_size (from));
 +
 +  /* If/How the parameter using submode, it dependes on the size and
 +   position of the parameter.  Here using heurisitic number.  */
 +  int hurstc_num = 8;
>>> Where did this come from and what does it mean?
>> Sorry for does not make this clear. We know that an aggregate arg may be
>> on registers partially or totally, as assign_parm_adjust_entry_rtl.
>> For an example, if a parameter with 12 words and the target/ABI only
>> allow 8 gprs for arguments, then the parameter could use 8 regs at most
>> and left part in stack.
>
> Right, but the number of registers is target dependent, so I don't see
> how using "8" or any number of that matter is correct here.
I understand.  And even for the same struct type, using how many
registers to pass a parameter, it also dependends on the size of the
parameter and how many leading parameters there is.
So, as you said, "8" or any numbers are not always accurate.

Because, the enhancement in this patch is just make "block move" to be
more friendly for follow optiomizations(cse/dse/dce...) by moving
through sub-mode.  So, I just selected one arbitrary number which may
not too large and also tolerable.
I also through to query the max number registers from targets for
param/ret passing, but it may not very accurate neither.

Any sugguestions are welcome! and thanks!

>
>
>>
>>>
>>> Note that BLKmode subword values passed in registers can be either
>>> right or left justified.  I think you also need to worry about
>>> endianness here.
>> Since the subword is used to move block(read from source mem and then
>> store to destination mem with register mode), and this would keep to use
>> the same endianness on reg like move_block_from_reg. So, the patch does
>> not check the endianness.
>
> Hmm, I was clear enough here, particularly using the endianness term. 
> Don't you need to query the ABI to ensure that you're not changing
> left vs right justification for a partially in register argument.
> On the PA we have:
>
> /* Specify padding for the last element of a block move between registers
>    and memory.
>
>    The 64-bit runtime specifies that objects need to be left justified
>    (i.e., the normal justification for a big endian target).  The 32-bit
>    runtime specifies right justification for objects smaller than 64 bits.
>    We use a DImode register in the parallel for 5 to 7 byte structures
>    so that there is only one element.  This allows the object to be
>    correctly padded.  */
> #define BLOCK_REG_PADDING(MODE, TYPE, FIRST) \
>   targetm.calls.function_arg_padding ((MODE), (TYPE))

Yes. We should be careful when store registers to stack
(assign_parms/assign_parm_setup_xx/block/reg), or load to returns.

For this patch, only simple stuffs are handled like "D.xxx = param_1",
where the source and dest of the assignment are all in memory which is
the DECL_RTL(of D.xx/param_xx) in MEM_P/BLK.
And to avoid complicate, this patch only handle the case where
"(size % mode_size) == 0".

If any misunderstandings, please point out, thanks.
And thanks for comments! 


BR,
Jeff (Jiufu)

>
>
> Jeff

[Bug rtl-optimization/107482] [10/11/12 Regression] out-of-bounds heap access in IRA since r6-3496-g86f0bef37378a0

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

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

jcmvbkbc at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #12 from jcmvbkbc at gcc dot gnu.org ---
Fix backported to gcc-12, gcc-11 and gcc-10.

[Bug other/86656] [meta-bug] Issues found with -fsanitize=address

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

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

Bug 107482 Summary: [10/11/12 Regression] out-of-bounds heap access in IRA 
since r6-3496-g86f0bef37378a0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107482

   What|Removed |Added

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

[Bug rtl-optimization/107482] [10/11/12 Regression] out-of-bounds heap access in IRA since r6-3496-g86f0bef37378a0

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

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Max Filippov
:

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

commit r10-11100-gbd6963543042ce713d290c23e098de84865a287f
Author: Max Filippov 
Date:   Mon Nov 7 13:58:49 2022 -0800

gcc: fix PR rtl-optimization/107482

gcc/
PR rtl-optimization/107482
* ira-color.c (assign_hard_reg): Only call
update_costs_from_copies when retry_p is false.

(cherry picked from commit e581490f0cfa80c58d2b648d71a44a597fbe3008)

[Bug rtl-optimization/107482] [10/11/12 Regression] out-of-bounds heap access in IRA since r6-3496-g86f0bef37378a0

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Max Filippov
:

https://gcc.gnu.org/g:01df02a881a0b6d7c5746e717a9d0355ee4e747a

commit r11-10399-g01df02a881a0b6d7c5746e717a9d0355ee4e747a
Author: Max Filippov 
Date:   Mon Nov 7 13:58:49 2022 -0800

gcc: fix PR rtl-optimization/107482

gcc/
PR rtl-optimization/107482
* ira-color.c (assign_hard_reg): Only call
update_costs_from_copies when retry_p is false.

(cherry picked from commit e581490f0cfa80c58d2b648d71a44a597fbe3008)

[Bug rtl-optimization/107482] [10/11/12 Regression] out-of-bounds heap access in IRA since r6-3496-g86f0bef37378a0

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Max Filippov
:

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

commit r12-8947-g1fb5287dfcf3bef8adea98a4bded441c95e43914
Author: Max Filippov 
Date:   Mon Nov 7 13:58:49 2022 -0800

gcc: fix PR rtl-optimization/107482

gcc/
PR rtl-optimization/107482
* ira-color.cc (assign_hard_reg): Only call
update_costs_from_copies when retry_p is false.

(cherry picked from commit e581490f0cfa80c58d2b648d71a44a597fbe3008)

[Bug c++/107904] __func__ is not properly treated as an array variable

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=70353,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=64266,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=70422,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=81277

--- Comment #1 from Andrew Pinski  ---
>But it's unclear to me whether this is an intentional design.
I think it is but it is a bit more complex though because we did try to
implement that Defect report, see bug 70353 comment #11.
Jason made the change to fix GCC to do what CWG 1962 says and then that had to
be reverted because it broken stuff so it was decided to go back to how GCC did
it.

[Bug middle-end/107905] 2x slowdown versus CLANG and ICL

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization, ra
  Component|target  |middle-end

--- Comment #1 from Andrew Pinski  ---
I looked at the code generation and there is not much difference between GCC
and LLVM really.

The only difference I see some register allocation difference when it comes to
mask and name. GCC uses two extra registers to store those.

I don't see that causing a 2x slow down though.

Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS

[Palmer Dabbelt]

On Mon, 28 Nov 2022 19:07:24 PST (-0800), juzhe.zh...@rivai.ai wrote:

In case of RVV intrinsic support, there is no changes outside RISC-V backend
since we don't do the autovectorization support for now.


OK, I'm fine with that.  Sounds like Kito is too?


I will postpone autovectorization until GCC14 is open.


We can still review that stuff and keep it on a branch, if that's eaiser 
on your end.





juzhe.zh...@rivai.ai
 
From: Palmer Dabbelt

Date: 2022-11-29 10:56
To: juzhe.zhong
CC: Kito Cheng; jeffreyalaw; gcc-patches
Subject: Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
On Mon, 28 Nov 2022 17:46:16 PST (-0800), juzhe.zh...@rivai.ai wrote:
Yeah, I personally want to support RVV intrinsics in GCC13. 
As RVV intrinsic is going to release soon next week.
 
OK, that's fine with me -- I was leaning that way, and I think Jeff only 
had a weak opposition.  Are there any more changes required outside the 
RISC-V backend?  Those would be the most controversial and are already 
late, but if it's only backend stuff at this point then I'm OK taking 
the risk for a bit longer.
 
Jeff?
 




juzhe.zh...@rivai.ai
 
From: Kito Cheng

Date: 2022-11-29 09:38
To: Jeff Law
CC: 钟居哲; gcc-patches; palmer
Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
Actually, I am strongly support those stuff keep merge to trunk until February, 
my goal is intrinsic support for vector, but not including any vectorization 
like SLP or Loop vectorization, the most critical part is the vsetvli which is 
the mode switching, and its almost done.

Those part is kind of infrastructure for future development (vectorization), so 
I want intrinsic support could merge at GCC 13.


and we've included few intrinsic support now, stop there is kind of awkward.

Jeff Law via Gcc-patches  於 2022年11月29日 週二 07:54 寫道：


On 11/28/22 15:52, 钟居哲 wrote:

 >> I'm tempted to push this into the next stage1 given its arrival after

stage1 close, but if the wider RISC-V maintainers want to see it move
forward, I don't object strongly.


Ok, let's save these patches and merge them when GCC14 stage1 is open.
Would you mind telling me when will stage 1 be open?
Typically it's April.  As was noted elsewhere, feel free to keep 
submitting patches in this space and you can certainly create a branch 
where y'all can put patches to make it easier to collaborate and 
ultimately merge with the trunk once stage1 is open again.




 >> I'm curious about the model you're using.  Is it going to be something

similar to mode switching?  That's the first mental model that comes to
mind.  Essentially we determine the VL needed for every chunk of code,
then we do an LCM like algorithm to find the optimal placement points
for VL sets to minimize the number of VL sets across all the paths
through the CFG.  Never in a million years would I have expected we'd be
considering reusing that code.


Yes, I implemented VSETVL PASS with LCM algorithm and RTL_SSA framework.
Yea,  layering on top of RTL-SSA is probably better than the existing 
mode-switching which is LCM without SSA.



Actually, me && kito have spent a month on VSETVL PASS and we have
made a progress. We have tested it with a lot of testcases, turns out 
our implementation

of VSETVL PASS in GCC has much better codegen than the VSETVL implemented
in LLVM side in many different situations because of LCM. I am working 
on cleaning up the codes

and hopefully you will see it soon in the next patch.
Good to hear.  I argued pretty loudly in the late 90s that LCM was the 
right framework for this problem.  We didn't have rtl-ssa, but we did 
have a pure RTL LCM module that Joern and Andrew were able to re-use to 
implement sh's mode switching.


I just never thought we'd see another processor where it'd be useful.

Jeff
 

Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS

[juzhe.zh...@rivai.ai]

In case of RVV intrinsic support, there is no changes outside RISC-V backend
since we don't do the autovectorization support for now.

I will postpone autovectorization until GCC14 is open.


juzhe.zh...@rivai.ai
 
From: Palmer Dabbelt
Date: 2022-11-29 10:56
To: juzhe.zhong
CC: Kito Cheng; jeffreyalaw; gcc-patches
Subject: Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
On Mon, 28 Nov 2022 17:46:16 PST (-0800), juzhe.zh...@rivai.ai wrote:
> Yeah, I personally want to support RVV intrinsics in GCC13. 
> As RVV intrinsic is going to release soon next week.
 
OK, that's fine with me -- I was leaning that way, and I think Jeff only 
had a weak opposition.  Are there any more changes required outside the 
RISC-V backend?  Those would be the most controversial and are already 
late, but if it's only backend stuff at this point then I'm OK taking 
the risk for a bit longer.
 
Jeff?
 
> 
> 
> 
> juzhe.zh...@rivai.ai
>  
> From: Kito Cheng
> Date: 2022-11-29 09:38
> To: Jeff Law
> CC: 钟居哲; gcc-patches; palmer
> Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
> Actually, I am strongly support those stuff keep merge to trunk until 
> February, my goal is intrinsic support for vector, but not including any 
> vectorization like SLP or Loop vectorization, the most critical part is the 
> vsetvli which is the mode switching, and its almost done.
> 
> Those part is kind of infrastructure for future development (vectorization), 
> so I want intrinsic support could merge at GCC 13.
> 
> 
> and we've included few intrinsic support now, stop there is kind of awkward.
> 
> Jeff Law via Gcc-patches  於 2022年11月29日 週二 07:54 寫道：
> 
> 
> On 11/28/22 15:52, 钟居哲 wrote:
>>  >> I'm tempted to push this into the next stage1 given its arrival after
stage1 close, but if the wider RISC-V maintainers want to see it move
forward, I don't object strongly.
>> 
>> Ok, let's save these patches and merge them when GCC14 stage1 is open.
>> Would you mind telling me when will stage 1 be open?
> Typically it's April.  As was noted elsewhere, feel free to keep 
> submitting patches in this space and you can certainly create a branch 
> where y'all can put patches to make it easier to collaborate and 
> ultimately merge with the trunk once stage1 is open again.
> 
>> 
>>  >> I'm curious about the model you're using.  Is it going to be something
similar to mode switching?  That's the first mental model that comes to
mind.  Essentially we determine the VL needed for every chunk of code,
then we do an LCM like algorithm to find the optimal placement points
for VL sets to minimize the number of VL sets across all the paths
through the CFG.  Never in a million years would I have expected we'd be
considering reusing that code.
>> 
>> Yes, I implemented VSETVL PASS with LCM algorithm and RTL_SSA framework.
> Yea,  layering on top of RTL-SSA is probably better than the existing 
> mode-switching which is LCM without SSA.
> 
>> Actually, me && kito have spent a month on VSETVL PASS and we have
>> made a progress. We have tested it with a lot of testcases, turns out 
>> our implementation
>> of VSETVL PASS in GCC has much better codegen than the VSETVL implemented
>> in LLVM side in many different situations because of LCM. I am working 
>> on cleaning up the codes
>> and hopefully you will see it soon in the next patch.
> Good to hear.  I argued pretty loudly in the late 90s that LCM was the 
> right framework for this problem.  We didn't have rtl-ssa, but we did 
> have a pure RTL LCM module that Joern and Andrew were able to re-use to 
> implement sh's mode switching.
> 
> I just never thought we'd see another processor where it'd be useful.
> 
> Jeff
 

Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS

[Palmer Dabbelt]

On Mon, 28 Nov 2022 17:46:16 PST (-0800), juzhe.zh...@rivai.ai wrote:
Yeah, I personally want to support RVV intrinsics in GCC13. 
As RVV intrinsic is going to release soon next week.


OK, that's fine with me -- I was leaning that way, and I think Jeff only 
had a weak opposition.  Are there any more changes required outside the 
RISC-V backend?  Those would be the most controversial and are already 
late, but if it's only backend stuff at this point then I'm OK taking 
the risk for a bit longer.


Jeff?





juzhe.zh...@rivai.ai
 
From: Kito Cheng

Date: 2022-11-29 09:38
To: Jeff Law
CC: 钟居哲; gcc-patches; palmer
Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
Actually, I am strongly support those stuff keep merge to trunk until February, 
my goal is intrinsic support for vector, but not including any vectorization 
like SLP or Loop vectorization, the most critical part is the vsetvli which is 
the mode switching, and its almost done.

Those part is kind of infrastructure for future development (vectorization), so 
I want intrinsic support could merge at GCC 13.


and we've included few intrinsic support now, stop there is kind of awkward.

Jeff Law via Gcc-patches  於 2022年11月29日 週二 07:54 寫道：


On 11/28/22 15:52, 钟居哲 wrote:

 >> I'm tempted to push this into the next stage1 given its arrival after

stage1 close, but if the wider RISC-V maintainers want to see it move
forward, I don't object strongly.


Ok, let's save these patches and merge them when GCC14 stage1 is open.
Would you mind telling me when will stage 1 be open?
Typically it's April.  As was noted elsewhere, feel free to keep 
submitting patches in this space and you can certainly create a branch 
where y'all can put patches to make it easier to collaborate and 
ultimately merge with the trunk once stage1 is open again.




 >> I'm curious about the model you're using.  Is it going to be something

similar to mode switching?  That's the first mental model that comes to
mind.  Essentially we determine the VL needed for every chunk of code,
then we do an LCM like algorithm to find the optimal placement points
for VL sets to minimize the number of VL sets across all the paths
through the CFG.  Never in a million years would I have expected we'd be
considering reusing that code.


Yes, I implemented VSETVL PASS with LCM algorithm and RTL_SSA framework.
Yea,  layering on top of RTL-SSA is probably better than the existing 
mode-switching which is LCM without SSA.



Actually, me && kito have spent a month on VSETVL PASS and we have
made a progress. We have tested it with a lot of testcases, turns out 
our implementation

of VSETVL PASS in GCC has much better codegen than the VSETVL implemented
in LLVM side in many different situations because of LCM. I am working 
on cleaning up the codes

and hopefully you will see it soon in the next patch.
Good to hear.  I argued pretty loudly in the late 90s that LCM was the 
right framework for this problem.  We didn't have rtl-ssa, but we did 
have a pure RTL LCM module that Joern and Andrew were able to re-use to 
implement sh's mode switching.


I just never thought we'd see another processor where it'd be useful.

Jeff

RE: Code generation: How to define file-scope static variables?

[Robert Dubner]

David, thank you very much.  That looks very much like what I was hoping 
for.

I'll dig into it tomorrow.

Heartfelt thanks,

Bob Dubner.

-Original Message-
From: David Malcolm 
Sent: Monday, November 28, 2022 18:01
To: Robert Dubner ; gcc@gcc.gnu.org
Cc: 'Bob Dubner' 
Subject: Re: Code generation: How to define file-scope static variables?

On Mon, 2022-11-28 at 15:28 -0600, Robert Dubner wrote:
> I am part of a team working on a COBOL front end for GCC.
>
> By reverse engineering other front ends, I learned, some months ago,
> how to create a function_decl GENERIC node that is the root of a
> GENERIC tree describing an entire function.
>
> By calling the routine cgraph_node::finalize_function() with that
> function_decl, the assembly language for that function is created, and
> all is well.
>
> But now I need to be able to create the equivalent of a file-scope
> static variable in C.
>
> This C program file:
>
> //
> static int dubner_at_work = 123454321; int main(int argc, char **argv)
>   {
>   }
> //
>
> produces, in part, this assembly language:
>
> ###
> .file   "ccc.c"
> .text
> .data
> .align 4
> .type   dubner_at_work, @object
> .size   dubner_at_work, 4
> dubner_at_work:
> .long   123454321
> .text
> .globl  main
> .type   main, @function
> [...]
> ###
>
> In my own GENERIC generation code, I believe that I am creating a
> proper translation_unit_decl that contains the block and the vars
> nodes for specifying "dubner_at_work".
>
> But I have been unable, after several days of looking, to figure out
> the equivalent of "cgraph_node::finalize_function" for a
> translation_unit_decl.  The resulting assembly language doesn't have a
> definition for "dubner_at_work".
>
> Can anybody describe how I can tell the downstream processing that I
> need the translation_unit_decl to actually define storage?

You might find libgccjit's gcc/jit/jit-playback.cc helpful for this, as it 
tends to contain minimal code to build trees (generally 
simplified/reverse-engineered from the C frontend).

playback::context::global_new_decl makes the VAR_DECL node, and such trees 
are added to the jit playback::context's m_globals.  In 
playback::context::replay, we have:

  /* Finalize globals. See how FORTRAN 95 does it in gfc_be_parse_file()
 for a simple reference. */
  FOR_EACH_VEC_ELT (m_globals, i, global)
rest_of_decl_compilation (global, true, true);

  wrapup_global_declarations (m_globals.address(), m_globals.length());

So you'll probably want to do something similar for your globals.

Caveat: this is all reverse-engineered by me/others from the C frontend (and 
I haven't touched this code in a while), so I may be missing things here.

Dave

Re: [PATCH 0/2] Support HWASAN with Intel LAM

[Hongtao Liu via Gcc-patches]

On Mon, Nov 28, 2022 at 10:40 PM Martin Liška  wrote:
>
> On 11/11/22 02:26, liuhongt via Gcc-patches wrote:
> >2 years ago, ARM folks support HWASAN[1] in GCC[2], and introduced 
> > several
> > target hooks(Many thanks to their work) so other backends can do similar
> > things if they have similar feature.
> >Intel LAM(linear Address Masking)[3 Charpter 14] supports similar 
> > feature with
> > the upper bits of pointers can be used as metadata, LAM support two modes:
> >LAM_U48:bits 48-62 can be used as metadata
> >LAM_U57:bits 57-62 can be used as metedata.
> >
> > These 2 patches mainly support those target hooks, but HWASAN is not really
> > enabled until the final decision for the LAM kernel interface which may take
> > quite a long time. We have verified our patches with a "fake" interface 
> > locally[4], and
> > decided to push the backend patches to the GCC13 to make other HWASAN 
> > developper's work
> > easy.
>
> Hello.
>
> A few random comments I noticed:
>
> 1) please document the new target -mlam in extend.texi
I will.
> 2) the description speaks about bits [48-62] or [57-62], can explain why the 
> patch contains:
>
Kernel will use bit 63 for special purposes, and here we want to
extract the tag by shifting right the pointer 57 bits, and need to
manually mask off bit63.
> +  /* Mask off bit63 when LAM_U57.  */
> +  if (ix86_lam_type == lam_u57)
> ?
>
> 3) Shouldn't the -lman option emit GNU_PROPERTY_X86_FEATURE_1_LAM_U57 or 
> GNU_PROPERTY_X86_FEATURE_1_LAM_U48
> .gnu.property note?
>
> 4) Can you please explain Florian's comment here:
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/13#note_1181396487
>
> Thanks,
> Martin
>
> >
> > [1] https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
> > [2] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557857.html
> > [3] 
> > https://www.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf
> > [4] https://gitlab.com/x86-gcc/gcc/-/tree/users/intel/lam/master
> >
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> > Ok for trunk?
> >
> > liuhongt (2):
> >Implement hwasan target_hook.
> >Enable hwasan for x86-64.
> >
> >   gcc/config/i386/i386-expand.cc  |  12 
> >   gcc/config/i386/i386-options.cc |   3 +
> >   gcc/config/i386/i386-opts.h |   6 ++
> >   gcc/config/i386/i386-protos.h   |   2 +
> >   gcc/config/i386/i386.cc | 123 
> >   gcc/config/i386/i386.opt|  16 +
> >   libsanitizer/configure.tgt  |   1 +
> >   7 files changed, 163 insertions(+)
> >
>


-- 
BR,
Hongtao

[Bug c/107905] New: 2x slowdown versus CLANG and ICL

[sanmayce at sanmayce dot com via Gcc-bugs]

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

Bug ID: 107905
   Summary: 2x slowdown versus CLANG and ICL
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sanmayce at sanmayce dot com
  Target Milestone: ---

Hi,
I have encountered performance problem with MinGW GCC 11.3.0, nearly 2x
slowdown with a simple C function (being the 3rd fastest wildcard matching
function).

```
int Tcheburaschka_Wildcard_Iterative_Kaze_CaseSensitive (const char* mask,
const char* name) {
const char* maskSTACK;
const char* nameSTACK;
#pragma nounroll
for (name, mask; *name; ++name, ++mask) {
if (*mask == '*') {
goto Backtrack;
//} else if ((*mask != '?') && (*name != *mask)) {
/*
} else if ((*mask - '?') * (*name - *mask)) {
return 0;
} 
*/
}
if ((*mask - '?') * (*name - *mask)) {
return 0;
} 
}
Backtrack:
#pragma nounroll
for (nameSTACK = name, maskSTACK = mask; *nameSTACK; ++nameSTACK,
++maskSTACK) {
if (*maskSTACK == '*') {
mask = maskSTACK+1;
if (!*mask) return 1;
name = nameSTACK;
goto Backtrack;
//} else if ((*maskSTACK != '?') && (*nameSTACK != *maskSTACK))
{
/*
} else if ((*maskSTACK - '?') * (*nameSTACK - *maskSTACK)) {
name++;
goto Backtrack;
} 
*/
}
if ((*maskSTACK - '?') * (*nameSTACK - *maskSTACK)) {
name++;
goto Backtrack;
} 
}
while (*maskSTACK == '*') ++maskSTACK;
return (!*maskSTACK);
}
```

```
[CPU: AMD Zen2 Ryzen7 4800H, @2.9GHz, Max. Boost Clock Up to 4.2GHz]
+---+---+-+---+
| Function \ Compiler  
| CLANG 14.0.1, -O3 | Intel's ICL 19.0.0, /O3 | MinGW gcc 11.3.0, -O3 |
+---+---+-+---+
| Dogan Kurt's 'Antimalware', 2016, Iterative (wild_iterative) 
|   70.605000 s |102.61 s |   83.398000 s |
| Dogan Kurt's 'Antimalware', 2016, Iterative Optimised (wild_iterative_opt)   
|   61.322000 s | 74.243000 s |   66.538000 s |
| Tcheburaschka_r3, 2022, (Tcheburaschka_Wildcard_Iterative_Kaze_CaseSensitive)
|   72.99 s | 76.161000 s |  127.717000 s |
| JackHandy_Iterative, 2005, (IterativeWildcards)  
|   80.053000 s | 90.872000 s |   70.156000 s |
| Kirk J. Krauss, 2014, DrDobbs (FastWildCompare)  
|   44.113000 s | 48.109000 s |   51.018000 s |
| Alessandro Cantatore, 2003, (szWildMatch7)   
|   98.729000 s | 85.986000 s |  121.965000 s |
| Nondeterministic Finite Automaton (wild_nfa) 
|  162.561000 s |200.022000 s |  176.44 s |
+---+---+-+---+
[Note1: All functions returned 1,075,000,000 Matches - that is TRUEs, kinda
means they passed the quality test, no, really, I printed all the 1's and 0's
after each run - the sequences matched.]
[Note2: It is well-known that Maximum Turbo Modes are maintained for some 15-30
seconds, so it is good that each function takes 30+ seconds, to emulate some 8
billion real-world searches.]
```

For more info:
https://github.com/kirkjkrauss/MatchingWildcards/issues/1#issue-1467311771

Help for a GCC school assignment

[throw away via Gcc]

 Hello,

For class, *I need to come up with a way to improve GCC* and then make a
quick presentation (no implementation required). Ideally, this idea isn't
being worked on already. *I'd appreciate help with coming up with an idea.*

I've thought about this and I'm having trouble coming up with anything. I'm
really stuck, so I thought I'd reach out here. (Reddit sent me here)

The best I could come up with was something along the lines of "makefile"
or *adding support for a new language. *For the new language, I was thinking*
something** like Swift.* The only reason I chose Swift was that there was a
lot of information online and it uses the Clang/LLVM framework, a sort of
competitor to GCC.

I see that Swift has its own compiler which uses a custom version of
Clang/LLVM. To add Swift to GCC, I imagine you'd have to add a new front
end for Swift. This front end would have a bunch of code (most adapted from
the open-source Swift compiler) to convert Swift code to generic. From
there, the middle end and back end can do the rest.

Welp, that's where I am at right now, if anyone has better ideas, I'd
really appreciate some help.

[Bug c++/107904] New: __func__ is not properly treated as an array variable

[de34 at live dot cn via Gcc-bugs]

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

Bug ID: 107904
   Summary: __func__ is not properly treated as an array variable
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Keywords: accepts-invalid, rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: de34 at live dot cn
  Target Milestone: ---

The following code is accepted by gcc from 4.7 to 12:

Godbolt link: https://godbolt.org/z/EYqh1f3oa

#include 

void f()
{
using T = decltype(__func__);
T x = __func__;
static_assert(std::is_lvalue_reference::value, ""); // incorrectly
passes
// static_assert(std::is_array::value, ""); // incorrectly fails
}

It seems that gcc only treats __func__ as "an lvalue denoting an array object",
but not exactly "the array variable itself" specified in
[dcl.fct.def.general]/8.

Given there is an unresolved CWG issue 1962, this is possibly not a bug at this
moment. But it's unclear to me whether this is an intentional design.

Re: [PATCH 0/2] Support HWASAN with Intel LAM

[H.J. Lu via Gcc-patches]

On Mon, Nov 28, 2022 at 6:40 AM Martin Liška  wrote:
>
> On 11/11/22 02:26, liuhongt via Gcc-patches wrote:
> >2 years ago, ARM folks support HWASAN[1] in GCC[2], and introduced 
> > several
> > target hooks(Many thanks to their work) so other backends can do similar
> > things if they have similar feature.
> >Intel LAM(linear Address Masking)[3 Charpter 14] supports similar 
> > feature with
> > the upper bits of pointers can be used as metadata, LAM support two modes:
> >LAM_U48:bits 48-62 can be used as metadata
> >LAM_U57:bits 57-62 can be used as metedata.
> >
> > These 2 patches mainly support those target hooks, but HWASAN is not really
> > enabled until the final decision for the LAM kernel interface which may take
> > quite a long time. We have verified our patches with a "fake" interface 
> > locally[4], and
> > decided to push the backend patches to the GCC13 to make other HWASAN 
> > developper's work
> > easy.
>
> Hello.
>
> A few random comments I noticed:
>
> 1) please document the new target -mlam in extend.texi
> 2) the description speaks about bits [48-62] or [57-62], can explain why the 
> patch contains:
>
> +  /* Mask off bit63 when LAM_U57.  */
> +  if (ix86_lam_type == lam_u57)
> ?
>
> 3) Shouldn't the -lman option emit GNU_PROPERTY_X86_FEATURE_1_LAM_U57 or 
> GNU_PROPERTY_X86_FEATURE_1_LAM_U48
> .gnu.property note?

Since there are no clear usages for these LAM bits, we can
leave them out for now.

> 4) Can you please explain Florian's comment here:
> https://gitlab.com/x86-psABIs/x86-64-ABI/-/merge_requests/13#note_1181396487
>
> Thanks,
> Martin
>
> >
> > [1] https://clang.llvm.org/docs/HardwareAssistedAddressSanitizerDesign.html
> > [2] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/557857.html
> > [3] 
> > https://www.intel.com/content/dam/develop/external/us/en/documents/architecture-instruction-set-extensions-programming-reference.pdf
> > [4] https://gitlab.com/x86-gcc/gcc/-/tree/users/intel/lam/master
> >
> >
> > Bootstrapped and regtested on x86_64-pc-linux-gnu{-m32,}.
> > Ok for trunk?
> >
> > liuhongt (2):
> >Implement hwasan target_hook.
> >Enable hwasan for x86-64.
> >
> >   gcc/config/i386/i386-expand.cc  |  12 
> >   gcc/config/i386/i386-options.cc |   3 +
> >   gcc/config/i386/i386-opts.h |   6 ++
> >   gcc/config/i386/i386-protos.h   |   2 +
> >   gcc/config/i386/i386.cc | 123 
> >   gcc/config/i386/i386.opt|  16 +
> >   libsanitizer/configure.tgt  |   1 +
> >   7 files changed, 163 insertions(+)
> >
>


-- 
H.J.

Re: Re: [PATCH] RISC-V: Support the ins "rol" with immediate operand

[Feng Wang]

on 2022-11-28 23:39  Jeff Law wrote:
>
>
>On 11/27/22 19:14, Feng Wang wrote:
>> From: wangfeng 
>>
>> There is no Immediate operand of ins "rol" accroding to the B-ext,
>> so the immediate operand should be loaded into register at first.
>> But we can convert it to the ins "rori" or "roriw", and then one
>> immediate load ins can be reduced.
>>
>> Please refer to the following use cases:
>> unsigned long foo2(unsigned long rs1)
>> {
>>  return (rs1 << 10) | (rs1 >> 54);
>> }
>>
>> The complier result is:
>> li   a1,10
>> rol  a0,a0,a1
>>
>> This patch will generate one ins
>> rori a0,a0,54
>>
>> gcc/ChangeLog:
>>
>>  * config/riscv/bitmanip.md: Add immediate_operand support in rotl 
>>RTL pattern
>>
>> gcc/testsuite/ChangeLog:
>>
>>  * gcc.target/riscv/zbb-rol-ror-04.c: New test.
>>  * gcc.target/riscv/zbb-rol-ror-05.c: New test.
>
>So this arrived after stage1 close and I'm not aware of an existing BZ
>around this issue, so I'd tend to think this should wait for stage1 to
>re-open in the spring.
>
>
> From a technical standpoint, would it be better to hand this in a more
>generic way?   ie, when converting from gimple into RTL, if we want to
>generate a rotate left by immediate and don't have a suitable insn, then
>change it to a rotate right by an adjusted immediate.    This could
>probably be done in optabs.cc::expand_binop.
>
>
>We might need similar code in combine.cc or simplify-rtx.cc since some
>rotate cases (or exposure of the constant) may not show up until later
>in the RTL pipeline.
>
>
>Anyway, doing this in a more generic way seems like it's worth
>investigating.
>
>
>jeff
> 
Hi jeff,

Thanks for your reply. In the currently it will judge the rotate shift number 
when converting from
gimple into RTL, if the shift number bigger than mode_size/2, then reverse the 
rotate direction. 
I think the purpose of this process is to handle rotate shift quickly. I will 
think about your advice
and try to modify it in the expand pass.

Wang Feng
Best regards

Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS

[juzhe.zh...@rivai.ai]

Yeah, I personally want to support RVV intrinsics in GCC13. 
As RVV intrinsic is going to release soon next week.



juzhe.zh...@rivai.ai
 
From: Kito Cheng
Date: 2022-11-29 09:38
To: Jeff Law
CC: 钟居哲; gcc-patches; palmer
Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
Actually, I am strongly support those stuff keep merge to trunk until February, 
my goal is intrinsic support for vector, but not including any vectorization 
like SLP or Loop vectorization, the most critical part is the vsetvli which is 
the mode switching, and its almost done.

Those part is kind of infrastructure for future development (vectorization), so 
I want intrinsic support could merge at GCC 13.


and we've included few intrinsic support now, stop there is kind of awkward.

Jeff Law via Gcc-patches  於 2022年11月29日 週二 07:54 寫道：


On 11/28/22 15:52, 钟居哲 wrote:
>  >> I'm tempted to push this into the next stage1 given its arrival after
>>>stage1 close, but if the wider RISC-V maintainers want to see it move
>>>forward, I don't object strongly.
> 
> Ok, let's save these patches and merge them when GCC14 stage1 is open.
> Would you mind telling me when will stage 1 be open?
Typically it's April.  As was noted elsewhere, feel free to keep 
submitting patches in this space and you can certainly create a branch 
where y'all can put patches to make it easier to collaborate and 
ultimately merge with the trunk once stage1 is open again.

> 
>  >> I'm curious about the model you're using.  Is it going to be something
>>>similar to mode switching?  That's the first mental model that comes to
>>>mind.  Essentially we determine the VL needed for every chunk of code,
>>>then we do an LCM like algorithm to find the optimal placement points
>>>for VL sets to minimize the number of VL sets across all the paths
>>>through the CFG.  Never in a million years would I have expected we'd be
>>>considering reusing that code.
> 
> Yes, I implemented VSETVL PASS with LCM algorithm and RTL_SSA framework.
Yea,  layering on top of RTL-SSA is probably better than the existing 
mode-switching which is LCM without SSA.

> Actually, me && kito have spent a month on VSETVL PASS and we have
> made a progress. We have tested it with a lot of testcases, turns out 
> our implementation
> of VSETVL PASS in GCC has much better codegen than the VSETVL implemented
> in LLVM side in many different situations because of LCM. I am working 
> on cleaning up the codes
> and hopefully you will see it soon in the next patch.
Good to hear.  I argued pretty loudly in the late 90s that LCM was the 
right framework for this problem.  We didn't have rtl-ssa, but we did 
have a pure RTL LCM module that Joern and Andrew were able to re-use to 
implement sh's mode switching.

I just never thought we'd see another processor where it'd be useful.

Jeff

Re: [PATCH] RISC-V: Add attributes for VSETVL PASS

[Kito Cheng via Gcc-patches]

Actually, I am strongly support those stuff keep merge to trunk until
February, my goal is intrinsic support for vector, but not including any
vectorization like SLP or Loop vectorization, the most critical part is the
vsetvli which is the mode switching, and its almost done.

Those part is kind of infrastructure for future development
(vectorization), so I want intrinsic support could merge at GCC 13.


and we've included few intrinsic support now, stop there is kind of awkward.

Jeff Law via Gcc-patches  於 2022年11月29日 週二 07:54
寫道：

>
>
> On 11/28/22 15:52, 钟居哲 wrote:
> >  >> I'm tempted to push this into the next stage1 given its arrival after
> >>>stage1 close, but if the wider RISC-V maintainers want to see it move
> >>>forward, I don't object strongly.
> >
> > Ok, let's save these patches and merge them when GCC14 stage1 is open.
> > Would you mind telling me when will stage 1 be open?
> Typically it's April.  As was noted elsewhere, feel free to keep
> submitting patches in this space and you can certainly create a branch
> where y'all can put patches to make it easier to collaborate and
> ultimately merge with the trunk once stage1 is open again.
>
> >
> >  >> I'm curious about the model you're using.  Is it going to be
> something
> >>>similar to mode switching?  That's the first mental model that comes to
> >>>mind.  Essentially we determine the VL needed for every chunk of code,
> >>>then we do an LCM like algorithm to find the optimal placement points
> >>>for VL sets to minimize the number of VL sets across all the paths
> >>>through the CFG.  Never in a million years would I have expected we'd be
> >>>considering reusing that code.
> >
> > Yes, I implemented VSETVL PASS with LCM algorithm and RTL_SSA framework.
> Yea,  layering on top of RTL-SSA is probably better than the existing
> mode-switching which is LCM without SSA.
>
> > Actually, me && kito have spent a month on VSETVL PASS and we have
> > made a progress. We have tested it with a lot of testcases, turns out
> > our implementation
> > of VSETVL PASS in GCC has much better codegen than the VSETVL implemented
> > in LLVM side in many different situations because of LCM. I am working
> > on cleaning up the codes
> > and hopefully you will see it soon in the next patch.
> Good to hear.  I argued pretty loudly in the late 90s that LCM was the
> right framework for this problem.  We didn't have rtl-ssa, but we did
> have a pure RTL LCM module that Joern and Andrew were able to re-use to
> implement sh's mode switching.
>
> I just never thought we'd see another processor where it'd be useful.
>
> Jeff
>

[PATCH] RISC-V: Remove tail && mask policy operand for vmclr, vmset, vmld, vmst

[juzhe . zhong]

From: Ju-Zhe Zhong 

Sorry for resend this patch, I found I miss commit a file.
1. vector.md: remove tail && mask policy operand for mask mode operations since
   we don't need them according to RVV ISA.
2. riscv-v.cc: adapt emit_pred_op for mask mode predicated mov since all RVV 
modes
   including vector integer mode && vector float mode  && vector bool mode are
   all use emit_pred_op function. For vector integer mode && vector float mode,
   we have instruction like vle.v/vse.v that we need tail && mask policy.
   However, for vector bool mode, the instruction is vlm/vsm that we don't need
   tail && mask policy. So we add a condition here to add tail && mask policy 
operand
   during expand if it is not a vector bool modes.

This patch is to cleanup the code and make it be consistent with RVV ISA.

gcc/ChangeLog:

* config/riscv/riscv-v.cc (emit_pred_op): Adapt for mask mode.
* config/riscv/vector.md: Remove Tail && make policy operand for mask 
mode mov.

---
 gcc/config/riscv/riscv-v.cc | 3 ++-
 gcc/config/riscv/vector.md  | 2 --
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/gcc/config/riscv/riscv-v.cc b/gcc/config/riscv/riscv-v.cc
index d54795694f1..4992ff2470c 100644
--- a/gcc/config/riscv/riscv-v.cc
+++ b/gcc/config/riscv/riscv-v.cc
@@ -136,7 +136,8 @@ emit_pred_op (unsigned icode, rtx dest, rtx src, 
machine_mode mask_mode)
   rtx vlmax = emit_vlmax_vsetvl (mode);
   e.add_input_operand (vlmax, Pmode);
 
-  e.add_policy_operand (TAIL_AGNOSTIC, MASK_AGNOSTIC);
+  if (GET_MODE_CLASS (mode) != MODE_VECTOR_BOOL)
+e.add_policy_operand (TAIL_AGNOSTIC, MASK_AGNOSTIC);
 
   e.expand ((enum insn_code) icode, MEM_P (dest) || MEM_P (src));
 }
diff --git a/gcc/config/riscv/vector.md b/gcc/config/riscv/vector.md
index 3bb87232d3f..38da2f7f095 100644
--- a/gcc/config/riscv/vector.md
+++ b/gcc/config/riscv/vector.md
@@ -593,8 +593,6 @@
  (unspec:VB
[(match_operand:VB 1 "vector_mask_operand"   "Wc1, Wc1, Wc1, Wc1, 
Wc1")
 (match_operand 4 "vector_length_operand"" rK,  rK,  rK,  rK,  
rK")
-(match_operand 5 "const_int_operand""  i,   i,   i,   i,   
i")
-(match_operand 6 "const_int_operand""  i,   i,   i,   i,   
i")
 (reg:SI VL_REGNUM)
 (reg:SI VTYPE_REGNUM)] UNSPEC_VPREDICATE)
  (match_operand:VB 3 "vector_move_operand"  "  m,  vr,  vr, Wc0, 
Wc1")
-- 
2.36.1

Re: Ping [PATCH] Change the behavior of predicate check failure on cbranchcc4 operand0 in prepare_cmp_insn

[HAO CHEN GUI via Gcc-patches]

Hi Richard,

在 2022/11/29 2:46, Richard Biener 写道:
> Anyhow - my question still stands - what's the fallback for the callers
> that do not check for failure?  How are we sure we're not running into
> these when relaxing the requirement that a MODE_CC prepare_cmp_insn
> must not fail?

I examed the code and found that currently callers should be fine with
returning a NULL_RTX for MODE_CC processing. The prepare_cmp_insn is called
by following callers.

1 gen_cond_trap which doesn't uses MODE_CC
2 prepare_cmp_insn itself where is after MODE_CC processing, so it never
hits MODE_CC
3 emit_cmp_and_jump_insns which doesn't uses MODE_CC
4 emit_conditional_move which checks the output is null or not
5 emit_conditional_add which checks the output is null or not

Not sure if I missed something. Looking forward to your advice.

Thanks a lot
Gui Haochen

[Bug middle-end/105125] Bogus and Misleading Warning: Packed attribute is unnecessary.

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

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

--- Comment #3 from Andrew Pinski  ---
The code has been wrong since the warning was added back in 1999:
r0-25196-g3c12fcc27809a2 

[Bug middle-end/105125] Bogus and Misleading Warning: Packed attribute is unnecessary.

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |middle-end

--- Comment #2 from Andrew Pinski  ---
C testcase (moved over the GNU style attributes from C23 attributes though):
```
#include 

#define static_assert _Static_assert 
#define alignof _Alignof

struct A
{
uint32_t i;
};

struct B
{
uint64_t i;
};

struct C
{
struct A a;
struct B b;
};

struct D
{
struct A a __attribute__((packed));
struct B b;
};

struct E
{
struct A a;
struct B b __attribute__((packed));
};

struct F
{
struct B b __attribute__((packed));
struct A a;
};
static_assert((sizeof(struct A) ==  4) && (alignof(struct A) == 4));
static_assert((sizeof(struct B) ==  8) && (alignof(struct B) == 8));
static_assert((sizeof(struct C) == 16) && (alignof(struct C) == 8));
static_assert((sizeof(struct D) == 16) && (alignof(struct D) == 8));
static_assert((sizeof(struct E) == 12) && (alignof(struct E) == 4));
static_assert((sizeof(struct F) == 12) && (alignof(struct F) == 4));
```

[PATCH v2 1/2] gcc: xtensa: allow dynamic configuration

[Max Filippov via Gcc-patches]

Import include/xtensa-dynconfig.h that defines XCHAL_* macros as fields
of a structure returned from the xtensa_get_config_v function call.
Define that structure and fill it with default parameter values
specified in the include/xtensa-config.h.
Define reusable function xtensa_load_config that tries to load
configuration and return an address of an exported object from it.
Define the function xtensa_get_config_v1 that uses xtensa_load_config
to get structure xtensa_config_v1, either dynamically configured or the
default.

Provide essential XCHAL_* configuration parameters as __XCHAL_* built-in
macros. This way it will be possible to use them in libgcc and libc
without need to patch libgcc or libc source for the specific xtensa core
configuration.

gcc/
* config.gcc (xtensa*-*-*): Add xtensa-dynconfig.o to extra_objs.
* config/xtensa/t-xtensa (TM_H): Add xtensa-dynconfig.h.
(xtensa-dynconfig.o): New rule.
* config/xtensa/xtensa-dynconfig.c: New file.
* config/xtensa/xtensa-protos.h (xtensa_get_config_strings): New
declaration.
* config/xtensa/xtensa.h (xtensa-config.h): Replace #include
with xtensa-dynconfig.h
(XCHAL_HAVE_MUL32_HIGH, XCHAL_HAVE_RELEASE_SYNC,
 XCHAL_HAVE_S32C1I, XCHAL_HAVE_THREADPTR,
 XCHAL_HAVE_FP_POSTINC): Drop definitions.
(TARGET_DIV32): Replace with __XCHAL_HAVE_DIV32.
(TARGET_CPU_CPP_BUILTINS): Add new 'builtin' variable and loop
through string array returned by the xtensa_get_config_strings
function call.

include/
* xtensa-dynconfig.h: New file.
---
 gcc/config.gcc   |   1 +
 gcc/config/xtensa/t-xtensa   |   8 +-
 gcc/config/xtensa/xtensa-dynconfig.c | 170 +++
 gcc/config/xtensa/xtensa-protos.h|   1 +
 gcc/config/xtensa/xtensa.h   |  22 +-
 include/xtensa-dynconfig.h   | 442 +++
 6 files changed, 626 insertions(+), 18 deletions(-)
 create mode 100644 gcc/config/xtensa/xtensa-dynconfig.c
 create mode 100644 include/xtensa-dynconfig.h

diff --git a/gcc/config.gcc b/gcc/config.gcc
index b5eda0460331..951902338205 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -561,6 +561,7 @@ tic6x-*-*)
;;
 xtensa*-*-*)
extra_options="${extra_options} fused-madd.opt"
+   extra_objs="xtensa-dynconfig.o"
;;
 esac
 
diff --git a/gcc/config/xtensa/t-xtensa b/gcc/config/xtensa/t-xtensa
index 6d43b370e5a8..4e5b7dec1bce 100644
--- a/gcc/config/xtensa/t-xtensa
+++ b/gcc/config/xtensa/t-xtensa
@@ -16,5 +16,11 @@
 # along with GCC; see the file COPYING3.  If not see
 # .
 
-TM_H += $(srcdir)/../include/xtensa-config.h
+TM_H += $(srcdir)/../include/xtensa-config.h \
+   $(srcdir)/../include/xtensa-dynconfig.h
 $(out_object_file): gt-xtensa.h
+
+xtensa-dynconfig.o: $(srcdir)/config/xtensa/xtensa-dynconfig.c \
+  $(CONFIG_H) $(SYSTEM_H) $(srcdir)/../include/xtensa-dynconfig.h \
+  $(srcdir)/../include/xtensa-config.h
+   $(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $<
diff --git a/gcc/config/xtensa/xtensa-dynconfig.c 
b/gcc/config/xtensa/xtensa-dynconfig.c
new file mode 100644
index ..056204ae9463
--- /dev/null
+++ b/gcc/config/xtensa/xtensa-dynconfig.c
@@ -0,0 +1,170 @@
+/* Xtensa configuration settings loader.
+   Copyright (C) 2022 Free Software Foundation, Inc.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it under
+   the terms of the GNU General Public License as published by the Free
+   Software Foundation; either version 3, or (at your option) any later
+   version.
+
+   GCC is distributed in the hope that it will be useful, but WITHOUT ANY
+   WARRANTY; without even the implied warranty of MERCHANTABILITY or
+   FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License
+   for more details.
+
+   You should have received a copy of the GNU General Public License
+   along with GCC; see the file COPYING3.  If not see
+   .  */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#define XTENSA_CONFIG_DEFINITION
+#include "xtensa-config.h"
+#include "xtensa-dynconfig.h"
+
+#if defined (HAVE_DLFCN_H)
+#include 
+#elif defined (_WIN32)
+#include 
+#define ENABLE_PLUGIN
+#endif
+
+#if !defined (HAVE_DLFCN_H) && defined (_WIN32)
+
+#define RTLD_LAZY 0  /* Dummy value.  */
+
+static void *
+dlopen (const char *file, int mode ATTRIBUTE_UNUSED)
+{
+  return LoadLibrary (file);
+}
+
+static void *
+dlsym (void *handle, const char *name)
+{
+  return (void *) GetProcAddress ((HMODULE) handle, name);
+}
+
+static int ATTRIBUTE_UNUSED
+dlclose (void *handle)
+{
+  FreeLibrary ((HMODULE) handle);
+  return 0;
+}
+
+static const char *
+dlerror (void)
+{
+  return _("Unable to load DLL.");
+}
+
+#endif /* !defined (HAVE_DLFCN_H) && defined (_WIN32)  */
+
+#define CONFIG_ENV_NAME "XTENSA_GNU_CONFIG"
+
+const void 

[PATCH v2 2/2] libgcc: xtensa: use built-in configuration

[Max Filippov via Gcc-patches]

Now that gcc provides __XCHAL_* definitions use them instead of XCHAL_*
definitions from the include/xtensa-config.h. That makes libgcc
dynamically configurable for the target xtensa core.

libgcc/
* config/xtensa/crti.S (xtensa-config.h): Replace #inlcude with
xtensa-config-builtin.h.
* config/xtensa/crtn.S: Likewise.
* config/xtensa/lib1funcs.S: Likewise.
* config/xtensa/lib2funcs.S: Likewise.
* config/xtensa/xtensa-config-builtin.h: New File.
---
 libgcc/config/xtensa/crti.S  |   2 +-
 libgcc/config/xtensa/crtn.S  |   2 +-
 libgcc/config/xtensa/lib1funcs.S |   2 +-
 libgcc/config/xtensa/lib2funcs.S |   2 +-
 libgcc/config/xtensa/xtensa-config-builtin.h | 198 +++
 5 files changed, 202 insertions(+), 4 deletions(-)
 create mode 100644 libgcc/config/xtensa/xtensa-config-builtin.h

diff --git a/libgcc/config/xtensa/crti.S b/libgcc/config/xtensa/crti.S
index 3de7bc101f4d..2452a88a0351 100644
--- a/libgcc/config/xtensa/crti.S
+++ b/libgcc/config/xtensa/crti.S
@@ -24,7 +24,7 @@
 # .init sections.  Users may put any desired instructions in those
 # sections.
 
-#include "xtensa-config.h"
+#include "xtensa-config-builtin.h"
 
.section .init
.globl _init
diff --git a/libgcc/config/xtensa/crtn.S b/libgcc/config/xtensa/crtn.S
index 06b932edb14d..8520945fbd7c 100644
--- a/libgcc/config/xtensa/crtn.S
+++ b/libgcc/config/xtensa/crtn.S
@@ -25,7 +25,7 @@
 # fact return.  Users may put any desired instructions in those sections.
 # This file is the last thing linked into any executable.
 
-#include "xtensa-config.h"
+#include "xtensa-config-builtin.h"
 
.section .init
 #if XCHAL_HAVE_WINDOWED && !__XTENSA_CALL0_ABI__
diff --git a/libgcc/config/xtensa/lib1funcs.S b/libgcc/config/xtensa/lib1funcs.S
index 3932d206256f..e5a35aa7dcc8 100644
--- a/libgcc/config/xtensa/lib1funcs.S
+++ b/libgcc/config/xtensa/lib1funcs.S
@@ -23,7 +23,7 @@ a copy of the GCC Runtime Library Exception along with this 
program;
 see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 .  */
 
-#include "xtensa-config.h"
+#include "xtensa-config-builtin.h"
 
 /* Define macros for the ABS and ADDX* instructions to handle cases
where they are not included in the Xtensa processor configuration.  */
diff --git a/libgcc/config/xtensa/lib2funcs.S b/libgcc/config/xtensa/lib2funcs.S
index 681bac1be8cf..ef2a83251352 100644
--- a/libgcc/config/xtensa/lib2funcs.S
+++ b/libgcc/config/xtensa/lib2funcs.S
@@ -23,7 +23,7 @@ a copy of the GCC Runtime Library Exception along with this 
program;
 see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
 .  */
 
-#include "xtensa-config.h"
+#include "xtensa-config-builtin.h"
 
 /* __xtensa_libgcc_window_spill: This function flushes out all but the
current register window.  This is used to set up the stack so that
diff --git a/libgcc/config/xtensa/xtensa-config-builtin.h 
b/libgcc/config/xtensa/xtensa-config-builtin.h
new file mode 100644
index ..36d4d9db330b
--- /dev/null
+++ b/libgcc/config/xtensa/xtensa-config-builtin.h
@@ -0,0 +1,198 @@
+/* Xtensa configuration settings.
+   Copyright (C) 2022 Free Software Foundation, Inc.
+
+   This file is part of GCC.
+
+   GCC is free software; you can redistribute it and/or modify it
+   under the terms of the GNU General Public License as published by
+   the Free Software Foundation; either version 3, or (at your option)
+   any later version.
+
+   GCC is distributed in the hope that it will be useful, but WITHOUT
+   ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
+   or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public
+   License for more details.
+
+   Under Section 7 of GPL version 3, you are granted additional
+   permissions described in the GCC Runtime Library Exception, version
+   3.1, as published by the Free Software Foundation.
+
+   You should have received a copy of the GNU General Public License and
+   a copy of the GCC Runtime Library Exception along with this program;
+   see the files COPYING3 and COPYING.RUNTIME respectively.  If not, see
+   .  */
+
+#ifndef XTENSA_CONFIG_BUILTIN_H
+#define XTENSA_CONFIG_BUILTIN_H
+
+/* The macros defined here match those with the same names in the Xtensa
+   compile-time HAL (Hardware Abstraction Layer).  Please refer to the
+   Xtensa System Software Reference Manual for documentation of these
+   macros.  */
+
+#undef XCHAL_HAVE_BE
+#define XCHAL_HAVE_BE  __XCHAL_HAVE_BE
+
+#undef XCHAL_HAVE_DENSITY
+#define XCHAL_HAVE_DENSITY __XCHAL_HAVE_DENSITY
+
+#undef XCHAL_HAVE_CONST16
+#define XCHAL_HAVE_CONST16 __XCHAL_HAVE_CONST16
+
+#undef XCHAL_HAVE_ABS
+#define XCHAL_HAVE_ABS __XCHAL_HAVE_ABS
+
+#undef XCHAL_HAVE_ADDX
+#define XCHAL_HAVE_ADDX   

[PATCH v2 0/2] gcc: xtensa: allow dynamic configuration

[Max Filippov via Gcc-patches]

Hello,

this series addresses the long standing issue with xtensa configuration
support by adding a way to configure toolchain for a specific xtensa
core at runtime using the xtensa-dynconfig [1] library as a plugin.
On a platform with shared library support single toolchain binary
becomes capable of building code for arbitrary xtensa configuration.
At the same time it fully preserves the traditional way of configuring
the toolchain using the xtensa configuration overlay.

Currently xtensa toolchain needs to be patched and rebuilt for every
new xtensa processor configuration. This has a number of downsides:
- toolchain builders need to change the toolchain source code, and
  because xtensa configuration overlay is not a patch, this change is
  special, embedding it into the toolchain build process gets
  backpressure.
- toolchain built for one configuration is usually not usable for any
  other configuration. It's not possible for a distribution to provide
  reusable prebuilt xtensa toolchain.

This series allows building the toolchain (including target libraries)
without its source code modification. Built toolchain takes configuration
parameters from the shared object specified in the environment variable.
That shared object may be built by the xtensa-dynconfig project [1].

The same shared object is used for gcc, all binutils and for gdb.
Xtensa core specific information needed to build that shared object is
taken from the configuration overlay.

Both gcc and binutils-gdb get new shared header file
include/xtensa-dynconfig.h that provides definition of configuration
data structure, initialization macros, redefines XCHAL_* macros to
access this structure and declares function for loading configuration
dynamically.

This is not the first submission of this series, it was first
submitted in 2017 [2]. This version has improved configuration
versioning and GPL-compatibility check that was suggested in comments
for the v1.

[1] https://github.com/jcmvbkbc/xtensa-dynconfig
[2] https://gcc.gnu.org/pipermail/gcc-patches/2017-May/475109.html

Max Filippov (2):
  gcc: xtensa: allow dynamic configuration
  libgcc: xtensa: use built-in configuration

 gcc/config.gcc   |   1 +
 gcc/config/xtensa/t-xtensa   |   8 +-
 gcc/config/xtensa/xtensa-dynconfig.c | 170 +++
 gcc/config/xtensa/xtensa-protos.h|   1 +
 gcc/config/xtensa/xtensa.h   |  22 +-
 include/xtensa-dynconfig.h   | 442 +++
 libgcc/config/xtensa/crti.S  |   2 +-
 libgcc/config/xtensa/crtn.S  |   2 +-
 libgcc/config/xtensa/lib1funcs.S |   2 +-
 libgcc/config/xtensa/lib2funcs.S |   2 +-
 libgcc/config/xtensa/xtensa-config-builtin.h | 198 +
 11 files changed, 828 insertions(+), 22 deletions(-)
 create mode 100644 gcc/config/xtensa/xtensa-dynconfig.c
 create mode 100644 include/xtensa-dynconfig.h
 create mode 100644 libgcc/config/xtensa/xtensa-config-builtin.h

-- 
2.30.2

[Bug target/106773] libbpf: failed to find BTF info for global/extern symbol 'bpf_link_fops'

[david.faust at oracle dot com via Gcc-bugs]

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

--- Comment #3 from David Faust  ---
There are two remaining issues:

1. We are missing support for 'linkage=extern' encoding for variables,
   so 'bpf_link_fops' and others are incorrectly marked with 'linkage=global'
   instead.

2. 'bpf_link_fops' variable is encoded as 'void' type not 'const void'.
   This is a result of the BTF being generated from internal DWARF
   representation. The distinction seems to be intentionally removed in
   dwarf2out.cc:add_type_attribute(), with the later side-effect that
   looking up the type DIE for the variable when generating BTF actually
   fails and falls back to the default 'void'.

I have an implementation for (1) in progress. For (2) I need to understand
why the 'void'/'const void' distinction is removed in DWARF and how to work 
around it.

Re: [PATCH] rtl: add predicates for addition, subtraction & multiplication

[Segher Boessenkool]

On Sun, Nov 27, 2022 at 09:21:00AM -0500, David Malcolm via Gcc-patches wrote:
> We're currently in "stage 3" of GCC 13 development, which means that
> we're focusing on bug-fixing, rather than cleanups and feature work. 
> Though exceptions can be made for low-risk work, at the discretion of
> the release managers; I've taken the liberty of CCing them.

Such global changes are incomnvenient for people who have touched any
of that code in their own patches.  If we really want to do that it
should be done early in stage 1 (when everything is broken for everyone
anyway), and should be agreed on beforehand, or really, should only be
done for obvious improvements.

This is not an obvious improvement.

> > All existings tests did pass.

I have never seen a single target where all existing tests passed.  What
we usually do is "same failures before and after the patch" :-)

> RTL is an aspect of the compiler that tends to have the most per-target
> differences, so it's especially important to be precise about which
> target(s) you built and tested on.

Not that that should matter at all for patches that do not actually
change anything, like this one should be: it should only change
notation.  That is in the nature of helper functions and helper macros.

> > Like I said, this is my first patch. 
> 
> We're sometimes not as welcoming to newcomers as we could be, so please
> bear with us.  Let me know if anything in this email is unclear.

x2 from me!

> As noted in another reply, there are lots of places in the code where
> the patch touches lines that it doesn't need to: generally formatting
> and whitespace changes.
> 
> We have over 30 years of source history which we sometimes need to look
> back on, and RTL is some of the oldest code in the compiler, so we want
> to minimize "churn" to keep tools like "git blame" useful.

Not to mention that many of those changes violated our coding style, or
even look like an automated formatter going haywire.  And, of course,
such changes should be separate patches, if done at all!


Segher

Re: [PATCH] rtl: add predicates for addition, subtraction & multiplication

[Segher Boessenkool]

Hi!

On Sat, Nov 26, 2022 at 09:16:13PM -0500, Charlie Sale via Gcc-patches wrote:
> This is my first contribution to GCC :) one of the beginner projects
> suggested on the website was to add and use RTL type predicates.

It says "See which ones are worth having a predicate for, and add them."

None of the operations should get a predicate, imnsho, only more
structural things.  Code using PLUS_P is way *less* readable than that
using GET_CODE directly!  It is good if important things are more
explicit, it is bad to have many names, etc.

> + * rtl.h (PLUS_P): RTL addition predicate
> + (MINUS_P): RTL subtraction predicate
> + (MULT_P): RTL multiplication predicate

* rtl.h (PLUS_P): New.

> + * alias.cc: use RTL predicates

* alias.cc: Use new predicates.

Send the changelog as plain text btw, not as patch; if nothing else,
such patches will never apply cleanly :-)

> set_reg_known_value (regno, XEXP (note, 0));
> -   set_reg_known_equiv_p (regno,
> -  REG_NOTE_KIND (note) == 
> REG_EQUIV);
> +   set_reg_known_equiv_p (regno, REG_NOTE_KIND (note)
> +   == REG_EQUIV);

Don't reformat unrelated code.  And certainly not to something that
violates our coding standards :-)

> -&& (t = get_reg_known_value (REGNO (XEXP (src, 
> 0
> +&& (t = get_reg_known_value (
> +  REGNO (XEXP (src, 0

Wow, this is even worse.  Why would you do this at all?  I guess you
used some automatic formatting thing that sets maximum line length to
79?  It is 80, and it is a bad idea to reformat any random code.

> -&& (REG_P (XEXP (SET_SRC (pat), 1)))
> -&& GET_CODE (SET_SRC (pat)) == PLUS)
> +&& (REG_P (XEXP (SET_SRC (pat), 1))) && PLUS_P (SET_SRC (pat)))

You could have removed the superfluous extra parentheses here :-)

>   case SUBREG:
> if ((SUBREG_PROMOTED_VAR_P (x)
>  || (REG_P (SUBREG_REG (x)) && REG_POINTER (SUBREG_REG (x)))
> -|| (GET_CODE (SUBREG_REG (x)) == PLUS
> -&& REG_P (XEXP (SUBREG_REG (x), 0))
> +|| (PLUS_P (SUBREG_REG (x)) && REG_P (XEXP (SUBREG_REG (x), 0))
>  && REG_POINTER (XEXP (SUBREG_REG (x), 0))
>  && CONST_INT_P (XEXP (SUBREG_REG (x), 1

There was only one && per line here on purpose.  It makes the code much
more readable.

> -  if (GET_CODE (x) == PLUS
> -  && XEXP (x, 0) == stack_pointer_rtx
> +  if (PLUS_P (x) && XEXP (x, 0) == stack_pointer_rtx
>&& CONST_INT_P (XEXP (x, 1)))

Similar here (but it is so simple here that either is easy to read of
course).

> --- a/gcc/combine.cc
> +++ b/gcc/combine.cc
> @@ -3016,19 +3016,17 @@ try_combine (rtx_insn *i3, rtx_insn *i2, rtx_insn 
> *i1, rtx_insn *i0,
>/* See if any of the insns is a MULT operation.  Unless one is, we will
>   reject a combination that is, since it must be slower.  Be conservative
>   here.  */
> -  if (GET_CODE (i2src) == MULT
> -  || (i1 != 0 && GET_CODE (i1src) == MULT)
> -  || (i0 != 0 && GET_CODE (i0src) == MULT)
> -  || (GET_CODE (PATTERN (i3)) == SET
> -   && GET_CODE (SET_SRC (PATTERN (i3))) == MULT))
> +  if (MULT_P (i2src) || (i1 != 0 && MULT_P (i1src))
> +  || (i0 != 0 && MULT_P (i0src))
> +  || (GET_CODE (PATTERN (i3)) == SET && MULT_P (SET_SRC (PATTERN (i3)
>  have_mult = 1;

No.  All || align here.  Please leave it that way.

> -  /* If I3 has an inc, then give up if I1 or I2 uses the reg that is inc'd.
> - We used to do this EXCEPT in one case: I3 has a post-inc in an
> - output operand.  However, that exception can give rise to insns like
> - mov r3,(r3)+
> - which is a famous insn on the PDP-11 where the value of r3 used as the
> - source was model-dependent.  Avoid this sort of thing.  */
> +/* If I3 has an inc, then give up if I1 or I2 uses the reg that is inc'd.
> +   We used to do this EXCEPT in one case: I3 has a post-inc in an
> +   output operand.  However, that exception can give rise to insns like
> +   mov r3,(r3)+
> +   which is a famous insn on the PDP-11 where the value of r3 used as the
> +   source was model-dependent.  Avoid this sort of thing.  */

The indentation was correct, it now isn't anymore.  There is absolutely
no reason to touch this at all anyway.  NAK.

> -  if ((FIND_REG_INC_NOTE (i2, NULL_RTX) != 0
> -   && i2_is_used + added_sets_2 > 1)
> +  if ((FIND_REG_INC_NOTE (i2, NULL_RTX) != 0 && i2_is_used + added_sets_2 > 
> 1)

Do not touch random other code please.  If there is a reason to reformat
it (there isn't here!) do that as a separate patch.

>|| (i1 != 0 && FIND_REG_INC_NOTE (i1, NULL_RTX) != 0
> -   && (i1_is_used + added_sets_1 + (added_sets_2 && i1_feeds_i2_n)
> -  

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Joseph Myers]

On Tue, 29 Nov 2022, Alex Colomar via Gcc wrote:

> I guess asking the compiler to do two passes on the param list isn't as bad as
> asking to do unbound lookahead.  In this case it's bound:  look ahead till the
> end of the param list; get as much info as possible, and then do it again to
> complete.  Anything not yet clear after two passes is not valid.

Unbounded here means an unbounded number of tokens, as opposed to e.g. 
looking one token ahead after seeing an identifier in statement context to 
determine if it's a label.

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

Re: [PATCH] c++: TYPENAME_TYPE lookup ignoring non-types [PR107773]

[Patrick Palka via Gcc-patches]

On Mon, 28 Nov 2022, Patrick Palka wrote:

> [temp.res.general]/3 says, in a note, "the usual qualified name lookup
> ([basic.lookup.qual]) applies even in the presence of typename".  Thus
> when resolving a TYPENAME_TYPE, it seems we shouldn't be looking past
> non-type members.
> 
> This patch fixes this by passing want_type=false instead of =true during
> the member lookup from make_typename_type.  An old nearby comment
> mentions that we want to continue to set want_type=true when resolving a
> nested typename type, but it appears that the nested case is handled by
> resolve_typename_type instead (which passes want_type=true appropriately).

Whoops, it seems this isn't true -- not all nested TYPENAME_TYPEs are
handled by resolve_typename_type, e.g. for T::b in

  struct a {
struct b { typedef void get; };
int b;
  };

  template
  void f() {
typedef typename T::b::get type;
  }

  template void f();

Passing want_type=false in make_typename_type causes us to incorrectly
reject the TYPENAME_TYPE for T::b here because qualified lookup now
finds the data member a::b instead of the nested class of the same name.
So it looks like we need a flag to control whether we're dealing with a
nested TYPENAME_TYPE or not and to pass want_type=true/false appropriately,
I'll poke more tomorrow.

> 
> In passing, use lookup_member instead of lookup_field so that we give a
> better diagnostic when a member function is found, and generalize the T
> format specifier to D in the diagnostic.
> 
> Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
> trunk?
> 
>   PR c++/107773
> 
> gcc/cp/ChangeLog:
> 
>   * decl.cc (make_typename_type): Use lookup_member instead of
>   lookup_field.  Pass want_type=false instead of =true.  Use D
>   instead of T format specifier.
>   * search.cc (lookup_member): Document default argument.
> 
> gcc/testsuite/ChangeLog:
> 
>   * g++.dg/template/typename24.C: New test.
>   * g++.dg/template/typename25.C: New test.
> ---
>  gcc/cp/decl.cc |  7 +++
>  gcc/cp/search.cc   |  2 +-
>  gcc/testsuite/g++.dg/template/typename24.C | 16 
>  gcc/testsuite/g++.dg/template/typename25.C | 20 
>  4 files changed, 40 insertions(+), 5 deletions(-)
>  create mode 100644 gcc/testsuite/g++.dg/template/typename24.C
>  create mode 100644 gcc/testsuite/g++.dg/template/typename25.C
> 
> diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
> index 238e72f90da..673e10801a6 100644
> --- a/gcc/cp/decl.cc
> +++ b/gcc/cp/decl.cc
> @@ -4303,9 +4303,8 @@ make_typename_type (tree context, tree name, enum 
> tag_types tag_type,
>   member of the current instantiation or a non-dependent base;
>   lookup will stop when we hit a dependent base.  */
>if (!dependent_scope_p (context))
> -/* We should only set WANT_TYPE when we're a nested typename type.
> -   Then we can give better diagnostics if we find a non-type.  */
> -t = lookup_field (context, name, 2, /*want_type=*/true);
> +t = lookup_member (context, name, /*protect=*/2, /*want_type=*/false,
> +complain);
>else
>  t = NULL_TREE;
>  
> @@ -4357,7 +4356,7 @@ make_typename_type (tree context, tree name, enum 
> tag_types tag_type,
>else
>   {
> if (complain & tf_error)
> - error ("% names %q#T, which is not a type",
> + error ("% names %q#D, which is not a type",
>  context, name, t);
> return error_mark_node;
>   }
> diff --git a/gcc/cp/search.cc b/gcc/cp/search.cc
> index 0dbb3be1ee7..e5848ebc620 100644
> --- a/gcc/cp/search.cc
> +++ b/gcc/cp/search.cc
> @@ -1109,7 +1109,7 @@ build_baselink (tree binfo, tree access_binfo, tree 
> functions, tree optype)
>  
>  tree
>  lookup_member (tree xbasetype, tree name, int protect, bool want_type,
> -tsubst_flags_t complain, access_failure_info *afi)
> +tsubst_flags_t complain, access_failure_info *afi /* = NULL */)
>  {
>tree rval, rval_binfo = NULL_TREE;
>tree type = NULL_TREE, basetype_path = NULL_TREE;
> diff --git a/gcc/testsuite/g++.dg/template/typename24.C 
> b/gcc/testsuite/g++.dg/template/typename24.C
> new file mode 100644
> index 000..4b1d5e5271b
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/template/typename24.C
> @@ -0,0 +1,16 @@
> +// PR c++/107773
> +
> +struct a {
> +  typedef void get;
> +};
> +
> +struct b : a {
> +  int get(int i) const;
> +};
> +
> +template
> +void f() {
> +  typedef typename T::get type; // { dg-error "'int b::get\\(int\\) const', 
> which is not a type" }
> +}
> +
> +template void f();
> diff --git a/gcc/testsuite/g++.dg/template/typename25.C 
> b/gcc/testsuite/g++.dg/template/typename25.C
> new file mode 100644
> index 000..4e6b764a97b
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/template/typename25.C
> @@ -0,0 +1,20 @@
> +// Example 4 from [temp.res.general]/3.
> +
> +struct A {
> +  

Re: [PATCH] RISC-V: Add attributes for VSETVL PASS

[Jeff Law via Gcc-patches]

On 11/28/22 15:52, 钟居哲 wrote:

 >> I'm tempted to push this into the next stage1 given its arrival after

stage1 close, but if the wider RISC-V maintainers want to see it move
forward, I don't object strongly.


Ok, let's save these patches and merge them when GCC14 stage1 is open.
Would you mind telling me when will stage 1 be open?
Typically it's April.  As was noted elsewhere, feel free to keep 
submitting patches in this space and you can certainly create a branch 
where y'all can put patches to make it easier to collaborate and 
ultimately merge with the trunk once stage1 is open again.




 >> I'm curious about the model you're using.  Is it going to be something

similar to mode switching?  That's the first mental model that comes to
mind.  Essentially we determine the VL needed for every chunk of code,
then we do an LCM like algorithm to find the optimal placement points
for VL sets to minimize the number of VL sets across all the paths
through the CFG.  Never in a million years would I have expected we'd be
considering reusing that code.


Yes, I implemented VSETVL PASS with LCM algorithm and RTL_SSA framework.
Yea,  layering on top of RTL-SSA is probably better than the existing 
mode-switching which is LCM without SSA.



Actually, me && kito have spent a month on VSETVL PASS and we have
made a progress. We have tested it with a lot of testcases, turns out 
our implementation

of VSETVL PASS in GCC has much better codegen than the VSETVL implemented
in LLVM side in many different situations because of LCM. I am working 
on cleaning up the codes

and hopefully you will see it soon in the next patch.
Good to hear.  I argued pretty loudly in the late 90s that LCM was the 
right framework for this problem.  We didn't have rtl-ssa, but we did 
have a pure RTL LCM module that Joern and Andrew were able to re-use to 
implement sh's mode switching.


I just never thought we'd see another processor where it'd be useful.

Jeff

[Bug libstdc++/107850] [12 Regression] std::erase_if (map) forces predicate to takes a const value_type

[chgros at synopsys dot com via Gcc-bugs]

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

--- Comment #4 from Charles-Henri Gros  ---
Looking into it further, there may be an implicit requirement that the
predicate does not modify its argument.
https://eel.is/c++draft/algorithms.requirements#6
"When not otherwise constrained, the Predicate parameter is used whenever an
algorithm expects a function object ([function.objects]) that, when applied to
the result of dereferencing the corresponding iterator, returns a value
testable as true.
In other words, if an algorithm takes Predicate pred as its argument and first
as its iterator argument with value type T, it should work correctly in the
construct pred(*first) contextually converted to bool ([conv]).
The function object pred shall not apply any non-constant function through the
dereferenced iterator.
Given a glvalue u of type (possibly const) T that designates the same object as
*first, pred(u) shall be a valid expression that is equal to pred(*first)."
I'm unfortunately not well-versed enough in C++ legalese to tell what "possibly
const" means in that context, nor "apply any non-constant function".
And while I understand that a "predicate" is generally meant to not do
modification, there are fairly frequent use cases for "apply this potentially
modifying operation, and depending on its result remove the element from the
container". And in practice, this works (e.g. std::remove_if, your own earlier
version of erase_if, other compilers' version...).
Maybe I should go to LEWG and lobby to remove that limitation. In the
meanwhile, I'll probably just keep my own, perhaps slightly less optimal
removal algorithms.

Re: [PATCH] c++: explicit specialization and trailing requirements [PR107864]

[Jason Merrill via Gcc-patches]

On 11/28/22 15:16, Patrick Palka wrote:

Here we're crashing when using an explicit specialization of a function
template with trailing requirements ultimately because decls_match
(called indirectly from register_specialization) returns false since the
template has trailing requirements whereas the specialization doesn't.

In r12-2230-gddd25bd1a7c8f4, we fixed a similar issue concerning
template requirements instead of trailing requirements.  We could just
extend this fix to ignore trailing requirement mismatches for
explicit specializations as well, but it seems cleaner to just propagate
constraints from the specialized template to the explicit specialization
so that decls_match will naturally return true.  And it looks like
determine_specialization already does this, albeit inconsistently (only
for non-template member functions of a class template as in
cpp2a/concepts-explicit-spec4.C).

So this patch makes determine_specialization consistently propagate
constraints from the specialized template to the specialization, which
obviates the function_requirements_equivalent_p special case added by
r12-2230.  In passing use add_outermost_template_args instead of open
coding it.

Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK for
trunk?  Also tested on range-v3 and cmcstl2.

PR c++/107864

gcc/cp/ChangeLog:

* decl.cc (function_requirements_equivalent_p): Don't check
DECL_TEMPLATE_SPECIALIZATION.
* pt.cc (determine_specialization): Propagate constraints when
specializing a function template too.  Simplify by using
add_outermost_template_args.

gcc/testsuite/ChangeLog:

* g++.dg/concepts/explicit-spec1a.C: New test.
---
  gcc/cp/decl.cc|  4 +---
  gcc/cp/pt.cc  | 21 +--
  .../g++.dg/concepts/explicit-spec1a.C | 11 ++
  3 files changed, 22 insertions(+), 14 deletions(-)
  create mode 100644 gcc/testsuite/g++.dg/concepts/explicit-spec1a.C

diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc
index 544efdc9914..238e72f90da 100644
--- a/gcc/cp/decl.cc
+++ b/gcc/cp/decl.cc
@@ -956,9 +956,7 @@ static bool
  function_requirements_equivalent_p (tree newfn, tree oldfn)
  {
/* In the concepts TS, the combined constraints are compared.  */
-  if (cxx_dialect < cxx20
-  && (DECL_TEMPLATE_SPECIALIZATION (newfn)
- <= DECL_TEMPLATE_SPECIALIZATION (oldfn)))
+  if (cxx_dialect < cxx20)


This should probably check flag_concepts_ts instead of cxx_dialect.

OK with that change.


  {
tree ci1 = get_constraints (oldfn);
tree ci2 = get_constraints (newfn);
diff --git a/gcc/cp/pt.cc b/gcc/cp/pt.cc
index fbf498ad16a..e677e9d1b38 100644
--- a/gcc/cp/pt.cc
+++ b/gcc/cp/pt.cc
@@ -2482,17 +2482,16 @@ determine_specialization (tree template_id,
  }
  
/* It was a specialization of a template.  */

-  targs = DECL_TI_ARGS (DECL_TEMPLATE_RESULT (TREE_VALUE (templates)));
-  if (TMPL_ARGS_HAVE_MULTIPLE_LEVELS (targs))
-{
-  *targs_out = copy_node (targs);
-  SET_TMPL_ARGS_LEVEL (*targs_out,
-  TMPL_ARGS_DEPTH (*targs_out),
-  TREE_PURPOSE (templates));
-}
-  else
-*targs_out = TREE_PURPOSE (templates);
-  return TREE_VALUE (templates);
+  tree tmpl = TREE_VALUE (templates);
+  targs = DECL_TI_ARGS (DECL_TEMPLATE_RESULT (tmpl));
+  targs = add_outermost_template_args (targs, TREE_PURPOSE (templates));
+  *targs_out = targs;
+
+  /* Propagate the template's constraints to the declaration.  */
+  if (tsk != tsk_template)
+set_constraints (decl, get_constraints (tmpl));
+
+  return tmpl;
  }
  
  /* Returns a chain of parameter types, exactly like the SPEC_TYPES,

diff --git a/gcc/testsuite/g++.dg/concepts/explicit-spec1a.C 
b/gcc/testsuite/g++.dg/concepts/explicit-spec1a.C
new file mode 100644
index 000..ec678740cb8
--- /dev/null
+++ b/gcc/testsuite/g++.dg/concepts/explicit-spec1a.C
@@ -0,0 +1,11 @@
+// A version of explicit-spec1.C where the template g has trailing instead of
+// template requirements.
+// PR c++/107864
+// { dg-do compile { target concepts } }
+
+template concept C = __is_class(T);
+struct Y { int n; } y;
+template void g(T) requires C { }
+int called;
+template<> void g(Y) { called = 3; }
+int main() { g(y); }

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Alex Colomar via Gcc]

Hi Martin,

On 11/13/22 15:58, Martin Uecker wrote:

Am Sonntag, den 13.11.2022, 15:02 +0100 schrieb Alejandro Colomar:


On 11/13/22 14:33, Alejandro Colomar wrote:

Hi Martin,

On 11/13/22 14:19, Alejandro Colomar wrote:

But there are not only syntactical problems, because
also the type of the parameter might become relevant
and then you can get circular dependencies:

void foo(char (*a)[sizeof *.b], char (*b)[sizeof *.a]);


This seems to be a difficult stone in the road.


But note that GNU forward declarations solve this nicely.


Okay, so GNU declarations basically work by duplicating (some of) the 
declarations.


How about the compiler parsing the parameter list twice?  One for 
getting the declarations and their types (but not resolving any 
sizeof(), _Lengthof(), or typeof(), when they contain .identifier (or 
expressions containing it; in those cases, leave the type incomplete, to 
be completed in the second pass).  As if the programmer had specified 
the firward declarations, but it's the compiler that gets them 
automatically.


I guess asking the compiler to do two passes on the param list isn't as 
bad as asking to do unbound lookahead.  In this case it's bound:  look 
ahead till the end of the param list; get as much info as possible, and 
then do it again to complete.  Anything not yet clear after two passes 
is not valid.


So, for

void foo(char (*a)[sizeof(*.b)], char (*b)[sizeof(*.a)]);

in the first pass, the compiler would read:

char (*a)[sizeof(*.b)];  // sizeof .identifier; incomplete type; 
continue parsing
char (*b)[sizeof(*.a)];  // sizeof .identifier; incomplete type; 
continue parsing


At the end of the first pass, the compiler only know:

char (*a)[];
char (*b)[];

At the second pass, when evaluating sizeof(), since the type of the 
arguments are yet incomplete, it can't be evaluated, and therefore, 
there's an error at the first sizeof(*.b): *.b has incomplete type.


---

Let's show a distinct case:

void foo(char (*a)[sizeof(*.b)], char (*b)[10]);

After the first pass, the compiler would know:

char (*a)[];
char (*b)[10];

At the second pass, sizeof(*.b) would be evaluated undoubtedly to 
sizeof(char[10]), and the parameter list would then be fine.


Does this 2-pass parsing make sense to you?  Did I miss any details?







I am not sure what would the best way to fix it. One
could specifiy that parameters referred to by
the .identifer syntax must of some integer type and
that the sub-expression .identifer is always
converted to a 'size_t'.


That makes sense, but then overnight some quite useful thing came to my mind
that would not be possible with this limitation:




char *
stpecpy(char dst[.end - .dst], char *src, char end[1])


Heh, I got an off-by-one error.  It should be dst[.end - .dst + 1], of course,
and then the result of the whole expression would be 0, which is fine as size_t.

So, never mind.


.end and .dst would have pointer size though.


{
  for (/* void */; dst <= end; dst++) {
  *dst = *src++;
  if (*dst == '\0')
  return dst;
  }
  /* Truncation detected */
  *end = '\0';

#if !defined(NDEBUG)
  /* Consume the rest of the input string. */
  while (*src++) {};
#endif

  return end + 1;
}

And I forgot to say it:  Default promotions rank high (probably the highest) in
my list of most hated features^Wbugs in C.


If you replaced them with explicit conversion you then have
to add by hand all the time, I am pretty sure most people
would hate this more. (and it could also hide bugs)


I wouldn't convert it to size_t, but
rather follow normal promotion rules.


The point of making it size_t is that you then
do need to know the type of the parameter to make
sense of the expression. If the type matters, then you get
mutual dependencies as in the example above.


Since you can use anything between INTMAX_MIN and UINTMAX_MAX for accessing an
array (which took me some time to understand), I'd also allow the same here. So,
the type of the expression between [] could perfectly be signed or unsigned.

So, you could use size_t for very high indices, or e.g. ptrdiff_t if you want to
allow negative numbers.  In the function above, since dst can be a pointer to
one-past-the-end (it represents a previous truncation; that's why the test
dst<=end), forcing a size_t conversion would disallow that syntax.


Yes, this then does not work.


Cheers,

Alex

--




OpenPGP_signature
Description: OpenPGP digital signature

Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS

[Palmer Dabbelt]

On Mon, 28 Nov 2022 15:10:15 PST (-0800), juzhe.zh...@rivai.ai wrote:
Thanks. 


I think we still can continue RVV feature reviewing process in github branch
that we have talked about. Such patches that have been reviewed I will still 
send
them to GCC mail list and not to merge right now, we can wait until stage1 is 
open.


That also works for me.  We can always stack them up on a vendor branch 
for a few months until things re-open.



Is it a good idea ? I don't want to make RVV support in GCC stop here since 
LLVM already has
all RVV support  and GCC is far behind LLVM for a long time in case of RVV.


Yes, please don't stop ;).  It's really important work!




juzhe.zh...@rivai.ai
 
From: Palmer Dabbelt

Date: 2022-11-29 02:02
To: jeffreyalaw
CC: juzhe.zhong; gcc-patches; Kito Cheng
Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
On Mon, 28 Nov 2022 08:44:16 PST (-0800), jeffreya...@gmail.com wrote:


On 11/28/22 07:14, juzhe.zh...@rivai.ai wrote:

From: Ju-Zhe Zhong 

gcc/ChangeLog:

 * config/riscv/riscv-protos.h (enum vlmul_type): New enum.
 (get_vlmul): New function.
 (get_ratio): Ditto.
 * config/riscv/riscv-v.cc (struct mode_vtype_group): New struct.
 (ENTRY): Adapt for attributes.
 (enum vlmul_type): New enum.
 (get_vlmul): New function.
 (get_ratio): New function.
 * config/riscv/riscv-vector-switch.def (ENTRY): Adapt for attributes.
 * config/riscv/riscv.cc (ENTRY): Ditto.
 * config/riscv/vector.md (false,true): Add attributes.


I'm tempted to push this into the next stage1 given its arrival after
stage1 close, but if the wider RISC-V maintainers want to see it move
forward, I don't object strongly.
 
I'm also on the fence here: the RISC-V V implementation is a huge 
feature so it's a bit awkward to land it this late in the release, but 
on the flip side it's a very important feature.  It's complicated enough 
that whatever our first release is will probably be a mess, so I'd 
prefer to just get that pain out of the way sooner rather than later.  
There's no V hardware availiable now and nothing concretely announced so 
any users are probably going to be pretty advanced, but having at least 
the basics of V in there will allow us to kick the tires on the rest of 
the stack a lot more easily.
 
There's obviously risk to taking something this late in the process.  We 
don't have anything else that triggers the vectorizer, so I think it 
should be seperable enough that risk is manageable.
 
Not sure if Kito wants to chim in, though.
 

I'm curious about the model you're using.  Is it going to be something
similar to mode switching?  That's the first mental model that comes to
mind.  Essentially we determine the VL needed for every chunk of code,
then we do an LCM like algorithm to find the optimal placement points
for VL sets to minimize the number of VL sets across all the paths
through the CFG.  Never in a million years would I have expected we'd be
considering reusing that code.


Jeff
 

Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS

[钟居哲]

Thanks. 

I think we still can continue RVV feature reviewing process in github branch
that we have talked about. Such patches that have been reviewed I will still 
send
them to GCC mail list and not to merge right now, we can wait until stage1 is 
open.

Is it a good idea ? I don't want to make RVV support in GCC stop here since 
LLVM already has
all RVV support  and GCC is far behind LLVM for a long time in case of RVV.


juzhe.zh...@rivai.ai
 
From: Palmer Dabbelt
Date: 2022-11-29 02:02
To: jeffreyalaw
CC: juzhe.zhong; gcc-patches; Kito Cheng
Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
On Mon, 28 Nov 2022 08:44:16 PST (-0800), jeffreya...@gmail.com wrote:
>
> On 11/28/22 07:14, juzhe.zh...@rivai.ai wrote:
>> From: Ju-Zhe Zhong 
>>
>> gcc/ChangeLog:
>>
>>  * config/riscv/riscv-protos.h (enum vlmul_type): New enum.
>>  (get_vlmul): New function.
>>  (get_ratio): Ditto.
>>  * config/riscv/riscv-v.cc (struct mode_vtype_group): New struct.
>>  (ENTRY): Adapt for attributes.
>>  (enum vlmul_type): New enum.
>>  (get_vlmul): New function.
>>  (get_ratio): New function.
>>  * config/riscv/riscv-vector-switch.def (ENTRY): Adapt for 
>> attributes.
>>  * config/riscv/riscv.cc (ENTRY): Ditto.
>>  * config/riscv/vector.md (false,true): Add attributes.
>
> I'm tempted to push this into the next stage1 given its arrival after
> stage1 close, but if the wider RISC-V maintainers want to see it move
> forward, I don't object strongly.
 
I'm also on the fence here: the RISC-V V implementation is a huge 
feature so it's a bit awkward to land it this late in the release, but 
on the flip side it's a very important feature.  It's complicated enough 
that whatever our first release is will probably be a mess, so I'd 
prefer to just get that pain out of the way sooner rather than later.  
There's no V hardware availiable now and nothing concretely announced so 
any users are probably going to be pretty advanced, but having at least 
the basics of V in there will allow us to kick the tires on the rest of 
the stack a lot more easily.
 
There's obviously risk to taking something this late in the process.  We 
don't have anything else that triggers the vectorizer, so I think it 
should be seperable enough that risk is manageable.
 
Not sure if Kito wants to chim in, though.
 
> I'm curious about the model you're using.  Is it going to be something
> similar to mode switching?  That's the first mental model that comes to
> mind.  Essentially we determine the VL needed for every chunk of code,
> then we do an LCM like algorithm to find the optimal placement points
> for VL sets to minimize the number of VL sets across all the paths
> through the CFG.  Never in a million years would I have expected we'd be
> considering reusing that code.
>
>
> Jeff
 

Re: Ping [PATCH] Change the behavior of predicate check failure on cbranchcc4 operand0 in prepare_cmp_insn

[Segher Boessenkool]

On Mon, Nov 28, 2022 at 07:46:07PM +0100, Richard Biener wrote:
> Anyhow - my question still stands - what's the fallback for the callers
> that do not check for failure?  How are we sure we're not running into
> these when relaxing the requirement that a MODE_CC prepare_cmp_insn
> must not fail?

This will work the same as with any other define_expand?  If the caller
of gen_blablabla does not check for failure, you end up with a NULL_RTX
in the instruction stream, which will ICE sooner or later.  Not pretty,
sure, but at least it is a reliable ICE :-)


Segher

Re: Code generation: How to define file-scope static variables?

[David Malcolm via Gcc]

On Mon, 2022-11-28 at 15:28 -0600, Robert Dubner wrote:
> I am part of a team working on a COBOL front end for GCC.
> 
> By reverse engineering other front ends, I learned, some months ago,
> how
> to create a function_decl GENERIC node that is the root of a GENERIC
> tree
> describing an entire function.   
> 
> By calling the routine cgraph_node::finalize_function() with that
> function_decl, the assembly language for that function is created,
> and all
> is well.
> 
> But now I need to be able to create the equivalent of a file-scope
> static
> variable in C.
> 
> This C program file:
> 
> //
> static int dubner_at_work = 123454321;
> int main(int argc, char **argv)
>   {
>   }
> //
> 
> produces, in part, this assembly language:
> 
> ###
> .file   "ccc.c"
> .text
> .data
> .align 4
> .type   dubner_at_work, @object
> .size   dubner_at_work, 4
> dubner_at_work:
> .long   123454321
> .text
> .globl  main
> .type   main, @function
> [...]
> ###
> 
> In my own GENERIC generation code, I believe that I am creating a
> proper
> translation_unit_decl that contains the block and the vars nodes for
> specifying "dubner_at_work".
> 
> But I have been unable, after several days of looking, to figure out
> the
> equivalent of "cgraph_node::finalize_function" for a
> translation_unit_decl.  The resulting assembly language doesn't have
> a
> definition for "dubner_at_work".
> 
> Can anybody describe how I can tell the downstream processing that I
> need
> the translation_unit_decl to actually define storage?

You might find libgccjit's gcc/jit/jit-playback.cc helpful for this, as
it tends to contain minimal code to build trees (generally
simplified/reverse-engineered from the C frontend).

playback::context::global_new_decl makes the VAR_DECL node, and such
trees are added to the jit playback::context's m_globals.  In
playback::context::replay, we have:

  /* Finalize globals. See how FORTRAN 95 does it in gfc_be_parse_file()
 for a simple reference. */
  FOR_EACH_VEC_ELT (m_globals, i, global)
rest_of_decl_compilation (global, true, true);

  wrapup_global_declarations (m_globals.address(), m_globals.length());

So you'll probably want to do something similar for your globals.

Caveat: this is all reverse-engineered by me/others from the C frontend
(and I haven't touched this code in a while), so I may be missing
things here.

Dave

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Alex Colomar via Gcc]

Hi Joseph,

On 11/14/22 19:26, Joseph Myers wrote:

On Mon, 14 Nov 2022, Alejandro Colomar via Gcc wrote:


To quote the convenor in WG14 reflector message 18575 (17 Nov
2020) when I asked about its status, "The author asked me not to put those
on the agenda.  He will supply updated versions later.".


Since his email is not in the paper, would you mind forwarding him this
suggestion of mine of renaming it to avoid confusion with string lengths?  Or
maybe point him to the mailing list discussion[1]?

[1]:



I don't have his email address (I don't see any emails from him on the
reflector since I joined it in 2001).


Meh; thanks.  Would you mind commenting this issue to whoever defends 
his document, whenever you talk about it?


Thanks,

Alex





--




OpenPGP_signature
Description: OpenPGP digital signature

[Bug tree-optimization/104547] std::vector::resize(v.size() - n) produces poor code

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug other/19089] Environment variable TMP may yield gcc: abort with internal error

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

Re: [PATCH] Various pages: SYNOPSIS: Use VLA syntax in function parameters

[Alex Colomar via Gcc]

Hi Joseph,

On 11/14/22 19:13, Joseph Myers wrote:

On Sun, 13 Nov 2022, Alejandro Colomar via Gcc wrote:


SYNOPSIS:

unary-operator:  . identifier


That's not what you mean.  See the standard syntax.


Yup; typo there.



unary-expression:
   [other alternatives]
   unary-operator cast-expression

unary-operator: one of
   & * + - ~ !


-  It is not an lvalue.

-  This means sizeof() and _Lengthof() cannot be applied to them.


sizeof can be applied to non-lvalues.


thinko there.  I fixed it in a subsequent email.




-  This prevents ambiguity with a designator in an initializer-list within
a nested braced-initializer.


No, it doesn't.  See my previous points about syntactic disambiguation
being a separate matter from "one parse would result in a constraint
violation, so choose another parse that doesn't" (necessarily, because the
constraint violation that results could in general be at an arbitrary
distance from the point where a choice of parse has to be made).  Or see
e.g. the disambiguation rule about enum type specifiers: there is an
explicit rule "If an enum type specifier is present, then the longest
possible sequence of tokens that can be interpreted as a specifier
qualifier list is interpreted as part of the enum type specifier." that
ensures that "enum e : long int;" interprets "long int" as the enum type
specifier, rather than "long" as the enum type specifier and "int" as
another type specifier in the sequence of declaration specifiers, even
though the latter parse would result in a constraint violation later.


I get it.  It's only unambiguous if there's lookahead.



Also, requiring unbounded lookahead to determine what kind of construct is
being parsed may be considered questionable for C.  (If you have an
initializer starting .a.b.c.d.e, possibly with array element access as
well, those could all be designators or .a might be a reference to a
parameter of struct or union type and .b.c.d.e a sequence of references to
members within it and disambiguation under your rule would depend on
whether an '=' follows such an unbounded sequence.)


I'm thinking of an idea for this.




-  The type of a .identifier is always an incomplete type.

-  This prevents circular dependencies involving sizeof() or _Lengthof().


We have typeof as well, which can be applied to expressions with
incomplete type.


Yes, but it would not be problematic in the two-pass parsing I have in mind.




-  Shadowing rules apply.

-  This prevents ambiguity.


"Shadowing rules apply" isn't much of a specification.  You need detailed
wording that would be added to 6.2.1 Scopes of identifiers (or equivalent
elsewhere) to make it clear exactly what scopes apply for identifiers
looked up using this construct.


Yeah, I guess.  I'm being easy for this draft.  I'll try to be more 
precise for future revisions.





-
void foo(struct bar { int x; char c[.x] } a, int x);

Explanation:
-  Because of shadowing rules, [.x] refers to the struct member.


I really don't think standardizing VLAs-in-structures would be a good
idea.  Certainly it would be a massive pain to specify meaningful
semantics for them and this outline doesn't even attempt to work through
the consequences of removing the rule that "If an identifier is declared
as having a variably modified type, it shall be an ordinary identifier (as
defined in 6.2.3), have no linkage, and have either block scope or
function prototype scope.".


Maybe.  I didn't have them in mind until Martin mentioned them.  Now 
that he mentioned them, I'd like at least to be careful so that any new 
syntax doesn't do something that impedes adding them in the future, if 
it is ever considered desirable.




The idea that .x as an expression might refer to either a member or a
parameter is also a massive change to the namespace rules, where at
present those are in completely different namespaces and so in any given
context a name only needs looking up as one or the other.

Again, proposals should be *minimal*.


Yes.  I only want to have a rough discussion about how the entire 
feature in an ideal future where everything is added would look like. 
Otherwise, adding a minimal feature without considering this future, 
might do something that prevents some part of it being implemented due 
to backwards compatibility.


So I'd like to discuss the whole idea before then going to a minimal 
proposal that will be *much* smaller than this idea that I'm discussing.


I'm happy with the Linux man-pages implementing the whole idea (even if 
it's impossible to implement it in C ever), and letting ISO C / GCC 
implement initially (and possibly ever) only the minimal stuff.




 And even when they are, many issues
may well arise in practice (see the long list of constexpr issues in my
commit message for that C2x feature, for example, which I expect to turn
into multiple NB comments and at least two accompanying documents).


Sure; I expect that.


Cheers,

Alex

[Bug testsuite/103469] [12 regression] c-c++-common/attr-retain-9.c fails after r12-5483

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug middle-end/103262] [12 Regression] Random FAIL: gcc.c-torture/execute/20061220-1.c by r12-5244

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug bootstrap/103160] [12 regression] typo in r12-5060 breaks bootstrap

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build
   Target Milestone|--- |12.0

Re: Re: [PATCH] RISC-V: Add duplicate vector support.

[钟居哲]

OK.



juzhe.zh...@rivai.ai
 
From: Jeff Law
Date: 2022-11-29 00:49
To: juzhe.zhong; gcc-patches
CC: kito.cheng
Subject: Re: [PATCH] RISC-V: Add duplicate vector support.
 
On 11/25/22 09:06, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong 
>
> gcc/ChangeLog:
>
>  * config/riscv/constraints.md (Wdm): New constraint.
>  * config/riscv/predicates.md (direct_broadcast_operand): New 
> predicate.
>  * config/riscv/riscv-protos.h (RVV_VLMAX): New macro.
>  (emit_pred_op): Refine function.
>  * config/riscv/riscv-selftests.cc (run_const_vector_selftests): New 
> function.
>  (run_broadcast_selftests): Ditto.
>  (BROADCAST_TEST): New tests.
>  (riscv_run_selftests): More tests.
>  * config/riscv/riscv-v.cc (emit_pred_move): Refine function.
>  (emit_vlmax_vsetvl): Ditto.
>  (emit_pred_op): Ditto.
>  (expand_const_vector): New function.
>  (legitimize_move): Add constant vector support.
>  * config/riscv/riscv.cc (riscv_print_operand): New asm print rule 
> for const vector.
>  * config/riscv/riscv.h (X0_REGNUM): New macro.
>  * config/riscv/vector-iterators.md: New attribute.
>  * config/riscv/vector.md (vec_duplicate): New pattern.
>  (@pred_broadcast): New pattern.
>
> gcc/testsuite/ChangeLog:
>
>  * gcc.target/riscv/rvv/base/dup-1.c: New test.
>  * gcc.target/riscv/rvv/base/dup-2.c: New test.
 
I think this should wait for the next stage1 cycle.
 
jeff
 
 
 

[Bug middle-end/102669] [12 Regression] FAIL: gnat.dg/unroll1.adb scan-rtl-dump-times loop2_unroll

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug testsuite/100412] [11/12 regression] PASS & FAIL for same test aarch64-qemu: gcc.dg/Wvla-parameter-[23].c pr?????

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||testsuite-fail
   Target Milestone|--- |12.0

--- Comment #6 from Andrew Pinski  ---
Fixed in GCC 12 by r12-443-g141cce5c2cc16b.

Re: Re: [PATCH] RISC-V: Remove tail && mask policy operand for vmclr, vmset, vmld, vmst

[钟居哲]

Yes, it's a cleanup.



juzhe.zh...@rivai.ai
 
From: Jeff Law
Date: 2022-11-29 00:48
To: juzhe.zhong; gcc-patches
CC: kito.cheng; palmer
Subject: Re: [PATCH] RISC-V: Remove tail && mask policy operand for vmclr, 
vmset, vmld, vmst
 
On 11/28/22 07:21, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong 
>
> Since mask instruction doesn't need policy, so remove it to make it look 
> reasonable.
> gcc/ChangeLog:
>
>  * config/riscv/vector.md: Remove TA && MA operands.
 
Does this fix a known bug or is it just a cleanup?   I think the latter, 
but I want to be sure.
 
 
 
Jeff
 
 
 

Re: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS

[钟居哲]

>> I'm tempted to push this into the next stage1 given its arrival after
>> stage1 close, but if the wider RISC-V maintainers want to see it move
>> forward, I don't object strongly.

Ok, let's save these patches and merge them when GCC14 stage1 is open.
Would you mind telling me when will stage 1 be open?

>> I'm curious about the model you're using.  Is it going to be something
>> similar to mode switching?  That's the first mental model that comes to
>> mind.  Essentially we determine the VL needed for every chunk of code,
>> then we do an LCM like algorithm to find the optimal placement points
>> for VL sets to minimize the number of VL sets across all the paths
>> through the CFG.  Never in a million years would I have expected we'd be
>> considering reusing that code.

Yes, I implemented VSETVL PASS with LCM algorithm and RTL_SSA framework.
Actually, me && kito have spent a month on VSETVL PASS and we have 
made a progress. We have tested it with a lot of testcases, turns out our 
implementation
of VSETVL PASS in GCC has much better codegen than the VSETVL implemented
in LLVM side in many different situations because of LCM. I am working on 
cleaning up the codes
and hopefully you will see it soon in the next patch.

Thanks



juzhe.zh...@rivai.ai
 
From: Jeff Law
Date: 2022-11-29 00:44
To: juzhe.zhong; gcc-patches
CC: kito.cheng; palmer
Subject: Re: [PATCH] RISC-V: Add attributes for VSETVL PASS
 
On 11/28/22 07:14, juzhe.zh...@rivai.ai wrote:
> From: Ju-Zhe Zhong 
>
> gcc/ChangeLog:
>
>  * config/riscv/riscv-protos.h (enum vlmul_type): New enum.
>  (get_vlmul): New function.
>  (get_ratio): Ditto.
>  * config/riscv/riscv-v.cc (struct mode_vtype_group): New struct.
>  (ENTRY): Adapt for attributes.
>  (enum vlmul_type): New enum.
>  (get_vlmul): New function.
>  (get_ratio): New function.
>  * config/riscv/riscv-vector-switch.def (ENTRY): Adapt for attributes.
>  * config/riscv/riscv.cc (ENTRY): Ditto.
>  * config/riscv/vector.md (false,true): Add attributes.
 
I'm tempted to push this into the next stage1 given its arrival after 
stage1 close, but if the wider RISC-V maintainers want to see it move 
forward, I don't object strongly.
 
 
I'm curious about the model you're using.  Is it going to be something 
similar to mode switching?  That's the first mental model that comes to 
mind.  Essentially we determine the VL needed for every chunk of code, 
then we do an LCM like algorithm to find the optimal placement points 
for VL sets to minimize the number of VL sets across all the paths 
through the CFG.  Never in a million years would I have expected we'd be 
considering reusing that code.
 
 
Jeff
 
 
 

[Bug tree-optimization/101741] [12 Regression] ICE in fold_stmt, at gimple-range-fold.cc:541 since r12-2517-g1ce0b26e6e1e6c34

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug testsuite/101520] [12 regression] gcc.target/powerpc/pr93658.c has excess errors after r12-2338

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Keywords||testsuite-fail

[Bug fortran/100642] [12 Regression] ICE in omp_code_to_statement, at fortran/openmp.c:6907 since r12-20-ga61c4964cd714462

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug testsuite/100569] [12 regression] gcc.dg/atomic/c11-atomic-exec-2.c has lto warnings after r12-742

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||testsuite-fail
   Target Milestone|--- |12.0

[Bug tree-optimization/100521] [12 Regression] ICE at -O2 and above: in verify_range, at value-range.cc:384 since r12-127-g694c956b6b877e48

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Keywords||ice-on-valid-code
  Component|c   |tree-optimization

[Bug analyzer/106473] [12/13 Regression] -Wanalyzer-malloc-leak false positive regression when returning heap-allocation through nested pointers

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
   Keywords||diagnostic

[Bug target/107506] [regression] cross-xtensa-esp32s2-elf/gcc-13.0.0_pre20221023: stack smashing detected during RTL pass: expand in function __absvdi2 (gen_movdi)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/107384] [13 Regression] ICE tree check: expected non_lvalue_expr or static_cast_expr, have error_mark in set_implicit_rvalue_p, at cp/cp-tree.h:8689

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/107879] [13 Regression] ffmpeg-4 test suite fails on FPU arithmetics

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

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

--- Comment #7 from Sergei Trofimovich  ---
(In reply to Jakub Jelinek from comment #6)
> Created attachment 53978 [details]
> gcc13-pr107879.patch
> 
> Untested fix.

The patch fixed real ffmpeg-4 tests for me (before the change there were about
10 failures in resampler). Thank you!

[Bug c/90885] GCC should warn about 2^16 and 2^32 and 2^64 [-Wxor-used-as-pow]

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug target/107316] [aarch64] Init big const value should be improved compare to llvm

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/96681] Failure to optimize xor of comparisons with specific constants to comparison of xor-ed of compared variables

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug tree-optimization/102872] If statement is always false but not figured out at gimple level

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug driver/106897] driver: support -gz=zstd

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/81159] New warning idea: -Wself-move

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/107826] [13 Regression] ice during GIMPLE pass: slp

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
Summary|ice during GIMPLE pass: slp |[13 Regression] ice during
   ||GIMPLE pass: slp

[Bug c++/107781] [13 Regression] strchrnul' was not declared in this scope; did you mean 'strchr'? For contracts for canadian compilation

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
Summary|strchrnul' was not declared |[13 Regression] strchrnul'
   |in this scope; did you mean |was not declared in this
   |'strchr'? For contracts for |scope; did you mean
   |canadian compilation|'strchr'? For contracts for
   ||canadian compilation

[Bug target/107604] FAIL: gcc.target/aarch64/aapcs64/test_dfp_17.c execution, -O0 fails on aarch64_be

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

--- Comment #6 from Andrew Pinski  ---
Thanks for the fix by the way.

[Bug tree-optimization/106754] compute_control_dep_chain over-estimates domain

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug analyzer/107777] [13 Regression] ICE in get_representative_path_var_1, at analyzer/region-model.cc:4750 since r13-3770-g3d2d04cda493fb55

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/101770] -Wmaybe-uninitialized false alarm with only locals in GNU diffutils

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug tree-optimization/85301] bitfield check causes maybe-uninitialized warning

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug middle-end/84078] false positive for -Wmaybe-uninitialized with __asm__

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

Re: Java front-end and library patches.

[Joseph Myers]

On Fri, 25 Nov 2022, Zopolis0 via Gcc-patches wrote:

> Firstly, to get feedback and reviews on the 56 already existing
> patches, even though most are just re-adding code or making idiomatic
> changes, so that when the final issue is solved everything has already
> been approved (hopefully) and the merge is good to go.

I think a lot more explanation is needed to get much useful feedback.

* Each patch should have its own explanation of what it is doing and why, 
in the message body (not in an attachment).  Just the commit summary line 
and ChangeLog entries aren't enough, we need the actual substantive commit 
message explaining the patch.

* An overall explanation is needed of what the patch series is doing and 
why.  Why is it now considered useful to add this front end back?  Which 
version is the basis of the one being added back - the version removed 
from GCC (that used ECJ for converting Java source to Java byte-code), or 
some other version?  How has the series been validated?  Would you propose 
to maintain the front end and libraries in future?  Would you re-open any 
bugs against the front end or libraries that were closed (as WONTFIX or 
otherwise) as a result of it being removed from the tree (maybe when it 
was removed, maybe later when the last release series with the front end 
ceased to be supported)?  And so on.

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

[Bug testsuite/83454] FAIL: gcc.dg/tree-ssa/cswtch-4.c and cswtch-5.c

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |8.0

[Bug target/87010] FAIL: gcc.dg/torture/20180712-1.c -O1 (test for excess errors)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |9.0

[Bug tree-optimization/91625] FAIL: gcc.dg/strlenopt-68.c execution test

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

--- Comment #4 from Andrew Pinski  ---
Fixed for GCC 10 by r10-6944-g9f6dd268194d10 .

[Bug other/104044] Useless empty statements (across projects)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug libstdc++/107649] New std::complex specializations are never used

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/107684] [C++23] P2589 - static operator[]

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/106654] [C++23] P1774 - Portable assumptions

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/106652] [C++23] P1467 - Extended floating-point types and standard names

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/107685] [C++23] P2647 - Permitting static constexpr variables in constexpr functions

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug target/107628] ICE: SIGSEGV in commutative_operand_precedence (rtlanal.cc:3770) with -fsignaling-nans

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug debug/99090] gsplit-dwarf broken on riscv64-linux

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug rtl-optimization/103296] Select satisfied register for deleting noop move instruction.

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

--- Comment #3 from Andrew Pinski  ---
Fixed for GCC 12 by r12-5978-ga888259a71fbbb .

[Bug fortran/107680] ICE in arith_power, at fortran/arith.cc:989 and :1006

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug c++/94147] mangling of lambdas in initializers is wrong

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.0