[Bug c++/107875] New: Deduction for class template specialization types seems to be broken with init-declarator-list

[8ygd87qg at gmail dot com via Gcc-bugs]

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

Bug ID: 107875
   Summary: Deduction for class template specialization types
seems to be broken with init-declarator-list
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: 8ygd87qg at gmail dot com
  Target Milestone: ---

Consider the following program (compiled with -std=c++20):

#include 
template 
struct X {};
X x1, x2;
static_assert(!std::is_same_v);
int main() {}

Relevant godbolt link: https://godbolt.org/z/h9Wd4K7sn

According to https://eel.is/c++draft/dcl.type.class.deduct#1, it seems that
type deduction should be done for x1 and x2 separately, and they should have
the same type (and if they don't, then the compilation should at least give a
diagnostic, perhaps an error). I am not well-versed with standardese, so please
bear with me if something is wrong (and please point out if the standard seems
to be ambiguous in this case).

When x1 and x2 are declared in separate statements (like X x1; X x2;), they
should have different types since the lambda in the template parameter
specialization always has a distinct type whenever it is called. So if type
deduction is carried out for x1 and x2 separately in the first example, they
should have different types (even if somehow they're assigned the same types,
the static_assert should fail).

In any case, the above program should not compile. However, GCC trunk and
12.2.1 both seem to allow this program to compile. Clang however seems to have
an expected behavior and gives the following error:

:4:1: error: template arguments deduced as 'X<(lambda at
:2:20){}>' in declaration of 'x1' and deduced as 'X<(lambda at
:2:20){}>' in declaration of 'x2'
X x1, x2;
^ ~~  ~~
1 error generated.
Compiler returned: 1

It'd be great if this is fixed in case it turns out to be a bug. Thanks!

Re: [PATCH 16/56] gcc: Re-add TYPE_METHODS.

[Xi Ruoyao via Gcc-patches]

On Sat, 2022-11-26 at 18:30 +1100, Zopolis0 via Gcc-patches wrote:
> > Re-adding a field to all types is a no-go
> 
> To be entirely honest, my current priority is simply to get this
> merged so I can spend less time keeping up with upstream changes
> breaking everything and spend more time actually improving things. The
> additional labour cost for the maintainer who is making the change and
> understands it deeply is much less than what it takes for me to bisect
> the issue, find the commit, understand it and fix the issue.

No.  Java was removed to reduce the maintenance burden, you can't just
reintroduce the burden and say "hey, I don't want to pay for the burden
so you please do it".

And we are in stage 3 now so it's not possible to merge 50+ patches
(completely not reviewed in stage 1) until GCC 14 stage 1 opens.

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

Re: [PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[Andrew Pinski via Gcc-patches]

On Fri, Nov 25, 2022 at 11:37 PM Zopolis0 via Gcc-patches
 wrote:
>
> > How does the Java FE initialize void_list_node?
> https://github.com/Zopolis4/gcj/blob/master/gcc/java/builtins.cc#L503
> ```
> void_list_node = end_params_node;
> ```
>
> end_params_node is defined a couple times around the Java frontend,
> not sure which definition it is using.

What happens if you remove end_params_node from the Java front-end and
replace it with void_list_node?

Thanks,
Andrew

Re: [PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[Zopolis0 via Gcc-patches]

> How does the Java FE initialize void_list_node?
https://github.com/Zopolis4/gcj/blob/master/gcc/java/builtins.cc#L503
```
void_list_node = end_params_node;
```

end_params_node is defined a couple times around the Java frontend,
not sure which definition it is using.

Re: [PATCH 16/56] gcc: Re-add TYPE_METHODS.

[Zopolis0 via Gcc-patches]

> TYPE_METHODS uses the field used by TYPE_BINFO so the patches are related.

As the person who wrote the patches, I can confirm that they are not
in fact related. Or, at least, they fix different issues and have no
reliance upon each other. If you mean related as in they both contain
RECORD_OR_UNION_CHECK, sure, but even then they are two very different
patches, with one being a temporary stopgap and the other being a
thought-through change that solves a large issue with minimal addition
and leaves existing functionality intact.

> Re-adding a field to all types is a no-go

To be entirely honest, my current priority is simply to get this
merged so I can spend less time keeping up with upstream changes
breaking everything and spend more time actually improving things. The
additional labour cost for the maintainer who is making the change and
understands it deeply is much less than what it takes for me to bisect
the issue, find the commit, understand it and fix the issue.

>From my point of view, temporarily re-adding a grand total of two
lines is worth that goal.
If you consider this a large enough issue that you won't accept that,
then let me know so we don't dance around the issue and I can get on
with solving the issue.

Re: [PATCH 16/56] gcc: Re-add TYPE_METHODS.

[Richard Biener via Gcc-patches]

> Am 26.11.2022 um 02:55 schrieb Zopolis0 :
> 
> Oh wait wrong patch. You talking about binfo confused me.
> 
> Anyways, I re-added this because replacing Java's usage of
> TYPE_METHODS with TYPE_FIELDS even when I properly checked for
> different types of functions still broke things, so I added this as a
> stopgap.
> 
> No idea what you are talking about with binfo though, I added binfo
> for the reasons you can see in the email above, nothing to do with
> TYPE_METHODS.

TYPE_METHODS uses the field used by TYPE_BINFO so the patches are related.
I fear you have to understand what the java
Frontend does to fix your problem, I certainly don’t know what it does wrong 
here.  Re-adding a field to all types is a no-go

Richard 

> 
>> On Sat, Nov 26, 2022 at 11:16 AM Zopolis0  wrote:
>> 
>> Because the frontend uses TYPE_BINFO specifically. It expects a TYPE_BINFO 
>> that writes to this value, and will break with replacements. I have tried a 
>> number of alternatives, and this is what works.
>> 
>> I can't use lang_1 because other frontends use it in ways that java doesn't 
>> expect and I can't create a replacement for TYPE_BINFO because then it won't 
>> have the regular checks that TYPE_BINFO has.
>> 
>> I couldn't find a better solution because I'm not particularly versed with 
>> the internal workings of gcc, if you can think of a better idea feel free to 
>> let me know.
>> 
>>> On Sat, 26 Nov 2022 at 07:20, Richard Biener  
>>> wrote:
>>> 
>>> On Fri, Nov 25, 2022 at 9:55 AM Zopolis0 via Gcc-patches
>>>  wrote:
 
>>> 
>>> Why add this when nothing uses it and you need to re-add binfo because
>>> of this?  If the frontend uses
>>> it then add it to lang_type.

Re: [PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[Richard Biener via Gcc-patches]

> Am 26.11.2022 um 02:40 schrieb Zopolis0 :
> 
> Because if I don't, all java files break:
> 
> /bin/bash ./libtool  --tag=GCJ   --mode=compile
> /home/zopolis4/trustme/./gcc/gcj
> -B/home/zopolis4/trustme/x86_64-pc-linux-gnu/libjava/
> -B/home/zopolis4/trustme/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/
> -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
> /usr/local/x86_64-pc-linux-gnu/include -isystem
> /usr/local/x86_64-pc-linux-gnu/sys-include-fomit-frame-pointer
> -Usun -fclasspath=
> -fbootclasspath=/home/zopolis4/trustme/../gcj/libjava/classpath/lib
> --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -o
> java/lang/Object.lo
> -fsource-filename=/home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java
> /home/zopolis4/trustme/../gcj/libjava/classpath/lib/java/lang/Object.class
> libtool: compile:  /home/zopolis4/trustme/./gcc/gcj
> -B/home/zopolis4/trustme/x86_64-pc-linux-gnu/libjava/
> -B/home/zopolis4/trustme/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/
> -B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
> /usr/local/x86_64-pc-linux-gnu/include -isystem
> /usr/local/x86_64-pc-linux-gnu/sys-include -fomit-frame-pointer -Usun
> -fclasspath= 
> -fbootclasspath=/home/zopolis4/trustme/../gcj/libjava/classpath/lib
> --encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c
> -fsource-filename=/home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java
> /home/zopolis4/trustme/../gcj/libjava/classpath/lib/java/lang/Object.class
> -fPIC -o java/lang/.libs/Object.o
> /home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java: In class
> 'java.lang.Object':
> /home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java: In method
> 'java.lang.Object.finalize(void)':
> In file included from :63:
> /home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java:119:
> internal compiler error: in start_java_method, at java/decl.cc:1779
>  119 |   }
>  |
> 0x662bca start_java_method(tree_node*)
>/home/zopolis4/trustme/../gcj/gcc/java/decl.cc:1779
> 0x862829 parse_class_file
>/home/zopolis4/trustme/../gcj/gcc/java/jcf-parse.cc:1634
> 0x8630ed java_parse_file()
>/home/zopolis4/trustme/../gcj/gcc/java/jcf-parse.cc:1970
> Please submit a full bug report, with preprocessed source (by using
> -freport-bug).
> Please include the complete backtrace with any bug report.
> See  for instructions.
> make[3]: *** [Makefile:10643: java/lang/Object.lo] Error 1
> make[3]: Leaving directory 
> '/home/zopolis4/trustme/x86_64-pc-linux-gnu/libjava'
> make[2]: *** [Makefile:10265: all-recursive] Error 1
> make[2]: Leaving directory 
> '/home/zopolis4/trustme/x86_64-pc-linux-gnu/libjava'
> make[1]: *** [Makefile:15471: all-target-libjava] Error 2
> make[1]: Leaving directory '/home/zopolis4/trustme'
> make: *** [Makefile:1016: all] Error 2

Please debug the above and see why it ICEs.  How does the Java FE initialize 
void_list_node?

> I asked about this in
> https://gcc.gnu.org/pipermail/gcc-help/2022-November/141981.html, but
> got no response, so I reverted the commit.
> 
>> On Sat, Nov 26, 2022 at 7:17 AM Richard Biener
>>  wrote:
>> 
>>> On Fri, Nov 25, 2022 at 9:46 AM Zopolis0 via Gcc-patches
>>>  wrote:
>>> 
>> 
>> Why?!

[Bug tree-optimization/42195] missed xnor optimization.

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80588
 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |13.0
 Resolution|--- |FIXED

--- Comment #4 from Andrew Pinski  ---
Fixed for GCC 13 by r13-1779-g375668e0508 .

[Bug middle-end/68557] Missed x86 peephole optimization for multiplying by a bool

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Andrew Pinski  ---
Fixed for GCC 13 by r13-673-gd863ba23fb1612 (aka 98865 ).

[Bug tree-optimization/70547] Optimize multiplication of booleans to bit_and

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #9 from Andrew Pinski  ---
.

[Bug tree-optimization/70547] Optimize multiplication of booleans to bit_and

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

--- Comment #8 from Andrew Pinski  ---
Fixed for GCC 10 by the same patch which fixed PR 87954 .

[Bug fortran/107874] New: merge not using all its arguments

[john.harper at vuw dot ac.nz via Gcc-bugs]

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

Bug ID: 107874
   Summary: merge not using all its arguments
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: john.harper at vuw dot ac.nz
  Target Milestone: ---

The F2018 standard 15.5.3 requires all actual arguments in a function reference
to be evaluated.

In the program below, merge has three scalar arguments; ifort evaluates
all three, gfortran evaluates only the useful two, which violates 15.5.3.

program testmerge9
  implicit none
  integer i
  logical:: x(2)=(/.true., .false./), y ! avoiding [ ] allows f95 option
  do i = 1,2
 y = merge(tstuff(),fstuff(),x(i))
 print *,y
  end do
contains
  logical function tstuff()
print *,'tstuff'
tstuff = .true.
  end function tstuff

  logical function fstuff()
print *,'fstuff'
fstuff = .false.
  end function fstuff
end program testmerge9

Steve Kargl said "Looks like a bug. Feel free to send a bug report with this
patch."

diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index bb938026828..c5b63d356e1 100644
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans-intrinsic.cc
@@ -7538,9 +7538,9 @@ gfc_conv_intrinsic_merge (gfc_se * se, gfc_expr * expr)
   gfc_conv_intrinsic_function_args (se, expr, args, num_args);
   if (expr->ts.type != BT_CHARACTER)
 {
-  tsource = args[0];
-  fsource = args[1];
-  mask = args[2];
+  tsource = gfc_evaluate_now (args[0], >pre);
+  fsource = gfc_evaluate_now (args[1], >pre);
+  mask = gfc_evaluate_now (args[2], >pre);
 }
   else
 {

Re: [PATCH 16/56] gcc: Re-add TYPE_METHODS.

[Zopolis0 via Gcc-patches]

Oh wait wrong patch. You talking about binfo confused me.

Anyways, I re-added this because replacing Java's usage of
TYPE_METHODS with TYPE_FIELDS even when I properly checked for
different types of functions still broke things, so I added this as a
stopgap.

No idea what you are talking about with binfo though, I added binfo
for the reasons you can see in the email above, nothing to do with
TYPE_METHODS.

On Sat, Nov 26, 2022 at 11:16 AM Zopolis0  wrote:
>
> Because the frontend uses TYPE_BINFO specifically. It expects a TYPE_BINFO 
> that writes to this value, and will break with replacements. I have tried a 
> number of alternatives, and this is what works.
>
> I can't use lang_1 because other frontends use it in ways that java doesn't 
> expect and I can't create a replacement for TYPE_BINFO because then it won't 
> have the regular checks that TYPE_BINFO has.
>
> I couldn't find a better solution because I'm not particularly versed with 
> the internal workings of gcc, if you can think of a better idea feel free to 
> let me know.
>
> On Sat, 26 Nov 2022 at 07:20, Richard Biener  
> wrote:
>>
>> On Fri, Nov 25, 2022 at 9:55 AM Zopolis0 via Gcc-patches
>>  wrote:
>> >
>>
>> Why add this when nothing uses it and you need to re-add binfo because
>> of this?  If the frontend uses
>> it then add it to lang_type.

Re: [PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[Zopolis0 via Gcc-patches]

Because if I don't, all java files break:

/bin/bash ./libtool  --tag=GCJ   --mode=compile
/home/zopolis4/trustme/./gcc/gcj
-B/home/zopolis4/trustme/x86_64-pc-linux-gnu/libjava/
-B/home/zopolis4/trustme/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include-fomit-frame-pointer
-Usun -fclasspath=
-fbootclasspath=/home/zopolis4/trustme/../gcj/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c -o
java/lang/Object.lo
-fsource-filename=/home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java
/home/zopolis4/trustme/../gcj/libjava/classpath/lib/java/lang/Object.class
libtool: compile:  /home/zopolis4/trustme/./gcc/gcj
-B/home/zopolis4/trustme/x86_64-pc-linux-gnu/libjava/
-B/home/zopolis4/trustme/./gcc/ -B/usr/local/x86_64-pc-linux-gnu/bin/
-B/usr/local/x86_64-pc-linux-gnu/lib/ -isystem
/usr/local/x86_64-pc-linux-gnu/include -isystem
/usr/local/x86_64-pc-linux-gnu/sys-include -fomit-frame-pointer -Usun
-fclasspath= -fbootclasspath=/home/zopolis4/trustme/../gcj/libjava/classpath/lib
--encoding=UTF-8 -Wno-deprecated -fbootstrap-classes -g -O2 -c
-fsource-filename=/home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java
/home/zopolis4/trustme/../gcj/libjava/classpath/lib/java/lang/Object.class
 -fPIC -o java/lang/.libs/Object.o
/home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java: In class
'java.lang.Object':
/home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java: In method
'java.lang.Object.finalize(void)':
In file included from :63:
/home/zopolis4/trustme/../gcj/libjava/java/lang/Object.java:119:
internal compiler error: in start_java_method, at java/decl.cc:1779
  119 |   }
  |
0x662bca start_java_method(tree_node*)
/home/zopolis4/trustme/../gcj/gcc/java/decl.cc:1779
0x862829 parse_class_file
/home/zopolis4/trustme/../gcj/gcc/java/jcf-parse.cc:1634
0x8630ed java_parse_file()
/home/zopolis4/trustme/../gcj/gcc/java/jcf-parse.cc:1970
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
make[3]: *** [Makefile:10643: java/lang/Object.lo] Error 1
make[3]: Leaving directory '/home/zopolis4/trustme/x86_64-pc-linux-gnu/libjava'
make[2]: *** [Makefile:10265: all-recursive] Error 1
make[2]: Leaving directory '/home/zopolis4/trustme/x86_64-pc-linux-gnu/libjava'
make[1]: *** [Makefile:15471: all-target-libjava] Error 2
make[1]: Leaving directory '/home/zopolis4/trustme'
make: *** [Makefile:1016: all] Error 2

I asked about this in
https://gcc.gnu.org/pipermail/gcc-help/2022-November/141981.html, but
got no response, so I reverted the commit.

On Sat, Nov 26, 2022 at 7:17 AM Richard Biener
 wrote:
>
> On Fri, Nov 25, 2022 at 9:46 AM Zopolis0 via Gcc-patches
>  wrote:
> >
>
> Why?!

Re: Re: About -fasan-shadow-offset option

[tao.z...@amlogic.com]

Dear Martin Liška

Thanks for your research. I have resolved this problem by pass a ddrsize 
paramters when build and cacluate the offset used by -fasan-shadow-offset 
according that parameter. 



Thanks!
B.R.
tao.z...@amlogic.com
 
Address： Building E5, 2555 Xiupu Road, Pudong District, Shanghai, China
公司地址：上海市浦东新区秀浦路2555号漕河泾康桥商务绿洲E5栋

 
发件人： Martin Liška
发送时间： 2022-11-26 00:23
收件人： tao.z...@amlogic.com; gcc
抄送： Jakub Jelinek
主题： Re: About -fasan-shadow-offset option
 
[ EXTERNAL EMAIL ]
 
On 11/16/22 10:01, tao.z...@amlogic.com wrote:
> Dear gcc:
> 
 
Hello.
 
Based on quick discussion with Jakub, we believe fasan-shadow-symbol= would 
be a non-trivial amount of work
and we rather suggest doing a per-system build with investigated 
-fasan-shadow-offset.
 
Cheers,
Martin
 
> I am developing a address sanitiser tools for u-boot. Basically refers 
> compile options from kernel side. But there is a problem that I must set 
> -fasan-shadow-offset with a pre-calculated value. Otherwise GCC compiler will 
> use 0x10 as default value for shadow offset and caused boot failed 
> because this value is too large.
> The problem is uboot do not have a fixed memory layout as kernel. 
> Basically it will relocate to end of DDR size and running at that memory 
> space. Usually memory map for uboot is virt=phys and there are lots of 
> drivers do not do address translate for dma based on this mapping. But ddr 
> size are different on each platform. So it's hard to handle shadow offset at 
> this scenario.
> My point is that can gcc add an option like -fasan-shadow-symbol=, 
> here  is a global variable and implementors can configure it's value 
> based on platforms ddr size/malloc buffer size during initialize stage and 
> this variable can be used for shadow address calculation during runtime. This 
> may be more fitable compared than a fixed value during compile stage.  And is 
> there any other options to help my problem?
> Waiting for your response asap.
>  Thanks.
> 
> 
> 
> Thanks!
> B.R.
> tao.z...@amlogic.com
>  
> Address： Building E5, 2555 Xiupu Road, Pudong District, Shanghai, China
> 公司地址：上海市浦东新区秀浦路2555号漕河泾康桥商务绿洲E5栋
> 
 

Re: [PATCH 14/56] middle-end: Set TREE_ADDRESSABLE in folding debug stmts.

[Zopolis0 via Gcc-patches]

I was reverting a076632e274abe344ca7648b7c7f299273d4cbe0 as it removed code
for Java, but I may have misunderstood the change and made the incorrect
edits.

On Sat, 26 Nov 2022 at 07:16, Richard Biener 
wrote:

> On Fri, Nov 25, 2022 at 9:43 AM Zopolis0 via Gcc-patches
>  wrote:
> >
>
> That's wrong and the comment you remove explains why.
>

Re: [PATCH 16/56] gcc: Re-add TYPE_METHODS.

[Zopolis0 via Gcc-patches]

Because the frontend uses TYPE_BINFO specifically. It expects a TYPE_BINFO
that writes to this value, and will break with replacements. I have tried a
number of alternatives, and this is what works.

I can't use lang_1 because other frontends use it in ways that java doesn't
expect and I can't create a replacement for TYPE_BINFO because then it
won't have the regular checks that TYPE_BINFO has.

I couldn't find a better solution because I'm not particularly versed with
the internal workings of gcc, if you can think of a better idea feel free
to let me know.

On Sat, 26 Nov 2022 at 07:20, Richard Biener 
wrote:

> On Fri, Nov 25, 2022 at 9:55 AM Zopolis0 via Gcc-patches
>  wrote:
> >
>
> Why add this when nothing uses it and you need to re-add binfo because
> of this?  If the frontend uses
> it then add it to lang_type.
>

[Bug target/107627] [13 Regression] int128_t shift generates extra xor/or.

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #4 from Roger Sayle  ---
I believe that tweaking i386.md's *concat3_? patterns, that call
i386-expand.cc's split_double_concat, should resolve/improve the issue. 
Specifically in this case *concatditi3_[1234].  Currently, these patterns
expect the source operands (specifically the zero_extend operand) to be
registers, hence combine reports:

Trying 10, 9 -> 11:
   10: r96:TI=zero_extend([r92:DI+0x8])
  REG_DEAD r92:DI
9: {r95:TI=r94:TI<<0x40;clobber flags:CC;}
  REG_DEAD r94:TI
  REG_UNUSED flags:CC
   11: {r97:TI=r95:TI|r96:TI;clobber flags:CC;}
  REG_DEAD r96:TI
  REG_DEAD r95:TI
  REG_UNUSED flags:CC
...
Failed to match this instruction:
(set (reg:TI 97)
(ior:TI (ashift:TI (reg:TI 94 [ *y_3(D) ])
(const_int 64 [0x40]))
(zero_extend:TI (mem:DI (plus:DI (reg/v/f:DI 92 [ yD.1994 ])
(const_int 8 [0x8])) [1 MEM[(const long long unsigned
intD.1
6 *)y_3(D) + 8B]+0 S8 A64]

If *concatditi3_1 allowed a memory_operand for operand 3, it would match.
The oversight is that the zero_extendditi2 pattern (in insn #10) accepts memory
operands.  I suspect changing the predicates for operands 0, 1 and 3 to be
nonimmediate_operand, but then providing constraints for each permissible
variation should work.

Using the  expansion of these splitters should also fix the (pre-existing)
-m32 code generation issue, as pointed out by Jakub in comment #3.

Perhaps:
(define_insn_and_split "*concat3_1"
  [(set (match_operand: 0 "nonimmediate_operand" "=ro,r,r")
(any_or_plus:
  (ashift: (match_operand: 1 "nonimmediate_operand" "r,o,r")
(match_operand: 2 "const_int_operand"))
  (zero_extend: (match_operand:DWIH 3 "nonimmediate_operand"
"r,r,o"]

I hope this helps.

[Bug c++/107873] C++ without SUPPORTS_ONE_ONLY

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Alexandre Oliva from comment #0)
> Without SUPPORTS_ONE_ONLY, the GNU/Linux bootstrap fails because
> pthread_once is not weakref'ed in libstdc++: flag_weak is set to false, so
> we define __GXX_WEAK__=0.  

N.B. for recent glibc no pthreads symbols should be weakrefs.

[Bug c/105134] tree-vectorize produces error code

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

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

--- Comment #9 from Andrew Pinski  ---
https://git.kernel.org/pub/scm/utils/kernel/kexec/kexec-tools.git/commit/purgatory/Makefile?id=1b03cf7adc3c156ecab2618acb1ec585336a3f75
was the commit to "fix" this but as I think I mentioned here it is just a
workaround for expecting SSE code to work and GCC might emit SSE code in other
places without the autovectorizer enabled so 

[Bug c/105134] tree-vectorize produces error code

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

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

--- Comment #8 from Andrew Pinski  ---
Looks like only ppc64 does:

ppc64_PURGATORY_EXTRA_CFLAGS += -m64 -msoft-float \
-fno-exceptions

Most likely purgatory/arch/x86_64/Makefile needs the following added the end of
the file instead:
x86_64_PURGATORY_EXTRA_CFLAGS += -mno-sse

(-mgeneral-regs-only might work these days too)


purgatory/arch/arm64/Makefile needs the following added too:
arm64_PURGATORY_EXTRA_CFLAGS += -mgeneral-regs-only

Other targets might need other CFLAGS set here for the same reason.

[Bug c/105134] tree-vectorize produces error code

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

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

--- Comment #7 from Andrew Pinski  ---
I am trying to understand this. Is it ok to use the SSE registers inside
purgatory or not?

Now that the vectorizer is used turned on at -O2 and above, without -mno-sse,
on x86_64 target, the vector instructions are generated. and since this is
inside a tiny bootloader, I am suspecting you can't use SSE instructions here.

So the real fix is to use -mno-sse for x86_64 while compiling files under
purgatory .

gcc-11-20221125 is now available

[GCC Administrator via Gcc]

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

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

You'll find:

 gcc-11-20221125.tar.xz   Complete GCC

  SHA256=43fb62fe69ef9bb65e7910ef6103c6b1c1f3953dec0ff5b6bff9476806dd6c3c
  SHA1=c0e8b397b6d3a22c70422bec1d9c0ea84bc33590

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

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

[Bug fortran/107576] [10/11/12/13 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.cc:6193

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #15 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

Thanks for the report!

[Bug fortran/107576] [10/11/12/13 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.cc:6193

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-11095-gb3b48f883d31910f2672640de2f5ff59e765488c
Author: Harald Anlauf 
Date:   Thu Nov 17 21:36:49 2022 +0100

Fortran: reject NULL actual argument without explicit interface [PR107576]

gcc/fortran/ChangeLog:

PR fortran/107576
* interface.c (gfc_procedure_use): Reject NULL as actual argument
when there is no explicit procedure interface.

gcc/testsuite/ChangeLog:

PR fortran/107576
* gfortran.dg/null_actual_3.f90: New test.

(cherry picked from commit 820c25c83561085f54268bd536f9d216d03c3e18)

[Bug fortran/107576] [10/11/12/13 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.cc:6193

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:55e5ef55a0eee1cb329754f30889d93567daae18

commit r11-10394-g55e5ef55a0eee1cb329754f30889d93567daae18
Author: Harald Anlauf 
Date:   Thu Nov 17 21:36:49 2022 +0100

Fortran: reject NULL actual argument without explicit interface [PR107576]

gcc/fortran/ChangeLog:

PR fortran/107576
* interface.c (gfc_procedure_use): Reject NULL as actual argument
when there is no explicit procedure interface.

gcc/testsuite/ChangeLog:

PR fortran/107576
* gfortran.dg/null_actual_3.f90: New test.

(cherry picked from commit 820c25c83561085f54268bd536f9d216d03c3e18)

[Bug libstdc++/107871] _Iter_sink:: _M_overflow missing some difference type casting

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

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

--- Comment #1 from Jonathan Wakely  ---
This isn't valid code, you can't use max diff type for your own types. It can
only be used by the library for iota_view, but that doesn't have output
iterators.

[Bug fortran/107576] [10/11/12/13 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.cc:6193

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:2a7a103dd46cc079252302be69cfef188caee74d

commit r12-8942-g2a7a103dd46cc079252302be69cfef188caee74d
Author: Harald Anlauf 
Date:   Thu Nov 17 21:36:49 2022 +0100

Fortran: reject NULL actual argument without explicit interface [PR107576]

gcc/fortran/ChangeLog:

PR fortran/107576
* interface.cc (gfc_procedure_use): Reject NULL as actual argument
when there is no explicit procedure interface.

gcc/testsuite/ChangeLog:

PR fortran/107576
* gfortran.dg/null_actual_3.f90: New test.

(cherry picked from commit 820c25c83561085f54268bd536f9d216d03c3e18)

[Bug fortran/107819] ICE in gfc_check_argument_var_dependency, at fortran/dependency.cc:978

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

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

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

(In reply to Mikael Morin from comment #9)
> It seems the semantics when an argument has the value attribute is the same
> as the case ELEM_CHECK_VARIABLE in my previous comment.
> So forcing the value of the elemental argument to ELEM_CHECK_VARIABLE at
> some appropriate place could possibly work.

Many thanks for the explanations!

Looking at the involved code, the most simple solution I came up with is
attached.  It scans over the actual arguments associated with the dummies,
and when we find one with the VALUE attribute, we enforce the dependency
check.  It fixes the testcase and regtests fine.

I was struggling with the actual generated code, which is rather a temporary
for the arguments with INTENT(INOUT/OUT), but that should be functionally
equivalent.

[Bug c++/107873] New: C++ without SUPPORTS_ONE_ONLY

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

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

Bug ID: 107873
   Summary: C++ without SUPPORTS_ONE_ONLY
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: aoliva at gcc dot gnu.org
  Target Milestone: ---

Created attachment 53967
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53967=edit
working patch with SUPPORTS_ONE_ONLY, incomplete fix for !SUPPORTS_ONE_ONLY

I've attempted disabling SUPPORTS_ONE_ONLY to use a linker that supported weak
symbols but had some issues with comdat, and that didn't go well.

Several symbols with vague linkage, and that thus should be output as weak
definitions, were issued as strong definitions instead.  The scenarios involved
make_decl_one_only's checking of DECL_INITIAL before it was set, such as when
deciding between .common or .weak for typeinfo objects and for static variables
in inlined functions.  The attached patch fixes that, and bootstraps on
x86_64-linux-gnu with SUPPORTS_ONE_ONLY, and also on another non-pthreads
target without SUPPORTS_ONE_ONLY.

Without SUPPORTS_ONE_ONLY, the GNU/Linux bootstrap fails because pthread_once
is not weakref'ed in libstdc++: flag_weak is set to false, so we define
__GXX_WEAK__=0.  According to my reading of the documentation, __GXX_WEAK__
means whether symbols with vague linkage can be output as unifiable definitions
in multiple translation units (so SUPPORTS_ONE_ONLY could have it enabled
through comdat even with -fno-weak), so I tried this patchlet:

diff --git a/gcc/c-family/c-cppbuiltin.cc b/gcc/c-family/c-cppbuiltin.cc
index 333f3e138d611..15ef47c0c04f5 100644
--- a/gcc/c-family/c-cppbuiltin.cc
+++ b/gcc/c-family/c-cppbuiltin.cc
@@ -939,7 +939,15 @@ c_cpp_builtins (cpp_reader *pfile)

   if (c_dialect_cxx ())
 {
-  if (flag_weak && SUPPORTS_ONE_ONLY)
+  /* __GXX_WEAK__'s name is misleading, the documentation says it
+tests for one-only spuport, but SUPPORTS_ONE_ONLY is also
+slightly misleading, because weak symbols can be used for
+one-only support even if !SUPPORtS_ONE_ONLY.  Here we
+approximate the supprots_one_only() test that may clear
+flag_weak, but we use the flag_weak result instead of
+TARGET_SUPPORTS_WEAK, because the user may have disabled weak
+symbols with -fno-weak.  */
+  if (flag_weak || SUPPORTS_ONE_ONLY)
cpp_define (pfile, "__GXX_WEAK__=1");
   else
cpp_define (pfile, "__GXX_WEAK__=0");


However, libstdc++ also uses it as telling whether weak undef / weakref is
available at all, a significant latent ambiguity that seems tricky and risky to
resolve without introducing two new macros, one for each independent meaning. 
(there are tests in g++.dg and libstdc++ testsuites that use it in one meaning
or the other)

Without SUPPORTS_ONE_ONLY, despite the availability of weak symbols, and
regardless of arranging for flag_weak to remain enabled, some symbols with
vague linkage fail to be output.  I have not investigated further, but one
example of simple test that fails in this configuration is g++.dg/abi/vtt1.C.

So the attached patch, though fixing some latent problems and not introducing
any to comdat-enabled C++, doesn't go all the way in making a comdat-less C++
compiler possible, so I'm not planning on submitting it for inclusion at this
point.  However, since I don't have plans to pursue this further, I hereby
contribute it as a starting point for anyone who might be interested in taking
it towards completion.

[Bug tree-optimization/97832] AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #18 from Alexander Monakov  ---
The apparent 'bias' is introduced by instruction scheduling: haifa-sched lifts
a +64 increment over memory accesses, transforming +0 and +32 displacements to
-64 and -32. Sometimes this helps a little bit even on modern x86 CPUs.

Also note that 'vfnmadd231pd 32(%rdx,%rax), %ymm3, %ymm0' would be
'unlaminated' (turned to 2 uops before renaming), so selecting independent IVs
for the two arrays actually helps on this testcase.

[Bug fortran/107872] New: ICE on recursive DT with DTIO

[jwmwalrus at gmail dot com via Gcc-bugs]

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

Bug ID: 107872
   Summary: ICE on recursive DT with DTIO
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwmwalrus at gmail dot com
  Target Milestone: ---

Hi.

The code below throws the following ICE:

$ gfortran -c -fbacktrace test2.f90 
gfortran: internal compiler error: Segmentation fault signal terminated program
f951
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

--8<--
module mod1
type t
integer :: data
type(t), allocatable :: next
contains
procedure, private :: write_t
generic :: write(formatted) => write_t
end type
contains
recursive subroutine write_t(this, unit, iotype, v_list, iostat, iomsg)
class(t), intent(in) :: this
integer, intent(in) :: unit
character(*), intent(in) :: iotype
integer, intent(in) :: v_list(:)
integer, intent(out) :: iostat
character(*), intent(inout) :: iomsg
if (ALLOCATED(this%next)) &
write (unit, '(dt)') this%next
end subroutine
end module
-->8--


$ gfortran --version
GNU Fortran (Debian 12.2.0-9) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug tree-optimization/97832] AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3

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

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

--- Comment #17 from Richard Biener  ---
(In reply to Michael_S from comment #16)
> On unrelated note, why loop overhead uses so many instructions?
> Assuming that I am as misguided as gcc about load-op combining, I would
> write it as:
>   sub %rax, %rdx
> .L3:
>   vmovupd   (%rdx,%rax), %ymm1
>   vmovupd 32(%rdx,%rax), %ymm0
>   vfmadd213pd32(%rax), %ymm3, %ymm1
>   vfnmadd213pd (%rax), %ymm2, %ymm0
>   vfnmadd231pd   32(%rdx,%rax), %ymm3, %ymm0
>   vfnmadd231pd (%rdx,%rax), %ymm2, %ymm1
>   vmovupd %ymm0,   (%rax)
>   vmovupd %ymm1, 32(%rax)
>   addq$64, %rax
>   decl%esi
>   jb  .L3
>   
> The loop overhead in my variant is 3 x86 instructions==2 macro-ops,
> vs 5 x86 instructions==4 macro-ops in gcc variant.
> Also, in gcc variant all memory accesses have displacement that makes them
> 1 byte longer. In my variant only half of accesses have displacement.
> 
> I think, in the past I had seen cases where gcc generates optimal or
> near-optimal
> code sequences for loop overhead. I wonder why it can not do it here.

I don't think we currently consider IVs based on the difference of two
addresses.  The cost benefit of no displacement is only size, otherwise
I have no idea why we have biased the %rax accesses by -32.  Why we
fail to consider decrement-to-zero for the counter IV is probably because
IVCANON would add such IV but the vectorizer replaces that and IVOPTs
doesn't consider re-adding that.

Re: Can't build Ada

[Iain Sandoe]

Hi Paul,

> On 25 Nov 2022, at 20:13, Andrew Pinski via Gcc  wrote:
> 
> On Fri, Nov 25, 2022 at 12:08 PM Paul Koning  wrote:
>> 
>>> On Nov 25, 2022, at 3:03 PM, Andrew Pinski  wrote:
>>> 
>>> On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc  
>>> wrote:
 
 I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be 
 precise) to build Ada, starting with the latest (2020) release of Gnat 
 from Adacore.
>>> 
>>> Are you building a cross compiler or a native compiler?
>>> If you are building a cross, you need to bootstrap a native compiler first.
>> 
>> I'm not sure.  The installed Gnat is x86_64-darwin; I want to build 
>> aarch64-darwin.
> 
> You have to build a x86_64-darwin compiler first with the same sources
> as you are building for aarch64-darwin.

So .. 
1/ if you are on arm64 Darwin, 
  - the first step is to bootstrap the compiler using Rosetta 2 and the 
available x86_64 gnat.

2/ if you are on x86_64 Darwin…
  - the first step is to bootstrap the compiler using the available x86-64 gnat.

then...
  - then you can build a cross to aarch64 using that just-build compiler.
  - then you can do a native cross (target==host!=build) using that, which will 
give you a usable native compiler for arm64 ..

(2 is what I was doing all the way through the development - until I recently 
got an arm64 machine)..

I know that Rosetta 2 bootstrap worked a few days ago …

BTW: the final step “native cross” can be a bit tricky in terms of configure 
line - since some configure steps cannot (in general) run the tools on the 
“foreign” host - so that you might need to specify the linker version (we don’t 
have the option to do —with-ld64=NN.MM yet, but there is code that cares about 
the version of ld64.. so)

>> But in any case, how does that relate to the error messages I got?  They 
>> don't seem to have anything to do with missing compilers, but rather with 
>> the use of language features too new for the available (downloadable) Gnat.
> 
> From https://gcc.gnu.org/install/prerequisites.html:
> "In order to build a cross compiler, it is strongly recommended to
> install the new compiler as native first, and then use it to build the
> cross compiler. Other native compiler versions may work but this is
> not guaranteed and *will typically fail with hard to understand
> compilation errors during the build."
> 
> I added the emphasis but yes this is all documented correctly.

thanks for the reminder!

cheers
Iain

Re: Can't build Ada

[Alexandre Oliva via Gcc]

On Nov 25, 2022, Paul Koning via Gcc  wrote:

> They don't seem to have anything to do with missing compilers, but
> rather with the use of language features too new for the available
> (downloadable) Gnat.

The gnat1 front-end requires some of the Ada runtime (libgnat)
components.  They get built as part of cross builds, so that the
compiler itself uses the features present in the runtime.

For bootstrapping purposes, stage1's gnat builds in a
less-runtime-demanding mode, that gets linked with the runtime of the
compiler used to build stage1, and that is then used to build the
runtime and later stages.

With this arrangement, the runtime components used by the compiler
itself may rely on language features that the build compiler doesn't
offer, at the cost of requiring cross builds to use a compiler that
supports those features.

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

Re: Can't build Ada

[NightStrike via Gcc]

On Fri, Nov 25, 2022 at 3:09 PM Paul Koning via Gcc  wrote:
> But in any case, how does that relate to the error messages I got?  They 
> don't seem to have anything to do with missing compilers, but rather with the 
> use of language features too new for the available (downloadable) Gnat.

Generally speaking, the reason is that with a normal compiler build,
where build = host = target, gcc can build itself and then run the
newly built self to build the language runtimes.  So if you're using
gcc 5 to build gcc 12, you're actually not using gcc 5 for all that
much.  The new gcc 12 is used to build for instance libX.  With a
cross compiler, it's possible that the build != host, and so you can't
use the newly built GCC in your build environment to build the
language runtimes.  For instance, say your cross compiler is hosted on
Windows, but you are building it on Linux.  You can't run the newly
built gcc 12, so you have to use the original gcc 5 instead.  That's
why you have to start with a new native compiler, and then use that to
build the cross compiler.

Re: [PATCH] tree-optimization/106912 - IPA profile and pure/const

[Richard Biener via Gcc-patches]

On Fri, 25 Nov 2022, Jan Hubicka wrote:


On Fri, 25 Nov 2022, Jan Hubicka wrote:





Am 25.11.2022 um 11:05 schrieb Jan Hubicka via Gcc-patches 
:




IPA profile instrumentation tries to clear the pure and const
flags of functions but that's quite hopeless in particular for
const since that attribute prevails on the type and thus on each
call to the function leading to inconsistencies in the IL and
eventual checking ICEs.  There's no good reason to do this and
it wouldn't fixup any indirect calls so just don't.  No other
instrumentation GCC does bothers about this.


This was mostly meant to deadl with situation where we auto-detect
function to be const and then partially inline it to a loop.
Then both caller and callee accesses same counters in the memory and if
you move load/stores out of the loop in caller you lose counters and get
inconsistencies at profile read-in time.


Don?t we Instrument after partial inlining now?  As said, since we have the 
fntype on the call this doesn?t work anymore for const functions via attributes.


Full inlining can cause problem already.  So for code like

do
{
  if (__builtin_expect (test,1))
a+=foo (a);
  else
a+=foo (b);
} while ();
we may end up inlining one of the two invocation. Then caller and callee
will modify the same counter.  If we handle the remaining call as const,
we can hoist the counter modifications out of the loop and mix them up.

I remember I run into an actual example of this problem during GCC
bootstrap. There the function was auto-detected to be const by
early pure-const pass so type was not an problem. You are right we ought
to do something about types since the scenario above can happen with foo
being declared with an attribute as well.


Or by doing the first call as

volatile int __attribute__((const)) (*foop)(int) = foo;

  a += (*foop) (a);

you'd need to get all calls that might possibly call an instrumented
function adjusted.

I think if we're taking this issue serious we'd have to simply
ignore const/pure attributes at parsing time and refrain from
auto-detecting as well, at least for address-taken functions?


I think that is also not a good idea, since we would have to do that
with -fprofile-use, too (so the CFG at the instrumentation time
matches) and it would lead to poor perofrmance with FDO.


Hmm, possibly, yes.


The idea was to honor pure/const during early opt and undo the
attributes when profiling is inserted.
We have fixup_cfg to compensate for attribute changes.


Which works for pure (it's not an attribute on types) but fails for
const (which is).  That's a bug btw.


We could
probably keep tract if any instrumented code was ever inlined into a
given function and perhaps just start ignoring attributes set on types?


But ignoring attributes on types makes all indirect calls not
const/pure annotatable (OK, they are not pure annotatable because of
the above bug).  I really don't see how to conservatively solve this
issue?  Maybe we can ignore all pure/const when the cgraph state is
in profile-instrumented state?  Of course we have multiple "APIs"
to query that.

Richard.


Honza


That said, this adjustment in the "wrong" direction causes problems
downstream, which is what the fixed PR is about (simd cloning picks
up the wrong things, or rather possibly fails to clone the attributes?).

Richard.


Honza


Richard

Honza


Bootstrap and regtest pending on x86_64-unknown-linux-gnu, OK?

Thanks,
Richard.

   PR tree-optimization/106912
   * tree-profile.cc (tree_profiling): Do not clear pure/const
   flags.

   * gcc.dg/pr106912.c: New testcase.
---
gcc/testsuite/gcc.dg/pr106912.c | 16 
gcc/tree-profile.cc |  3 ---
2 files changed, 16 insertions(+), 3 deletions(-)
create mode 100644 gcc/testsuite/gcc.dg/pr106912.c

diff --git a/gcc/testsuite/gcc.dg/pr106912.c b/gcc/testsuite/gcc.dg/pr106912.c
new file mode 100644
index 000..8faa877d8b3
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr106912.c
@@ -0,0 +1,16 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fPIC -ftree-vectorize -fprofile-generate" } */
+
+__attribute__ ((__simd__))
+__attribute__ ((__nothrow__ , __leaf__ , __const__))
+double foo (double x);
+void bar(double *f, int n)
+{
+  int i;
+  for (i = 0; i < n; i++)
+f[i] = foo(f[i]);
+}
+double foo(double x)
+{
+  return x * x / 3.0;
+}
diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
index 2beb49241f2..5491b398870 100644
--- a/gcc/tree-profile.cc
+++ b/gcc/tree-profile.cc
@@ -814,9 +814,6 @@ tree_profiling (void)
   /* Don't profile functions produced for builtin stuff.  */
   if (DECL_SOURCE_LOCATION (node->decl) == BUILTINS_LOCATION)
 continue;
-
-node->set_const_flag (false, false);
-node->set_pure_flag (false, false);
  }

  /* Update call statements and rebuild the cgraph.  */
--
2.35.3




--
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew 

Re: [PATCH 16/56] gcc: Re-add TYPE_METHODS.

[Richard Biener via Gcc-patches]

On Fri, Nov 25, 2022 at 9:55 AM Zopolis0 via Gcc-patches
 wrote:
>

Why add this when nothing uses it and you need to re-add binfo because
of this?  If the frontend uses
it then add it to lang_type.

Re: Can't build Ada

[Iain Sandoe]

Hi Paul,

> On 25 Nov 2022, at 20:08, Paul Koning via Gcc  wrote:
> 
>> On Nov 25, 2022, at 3:03 PM, Andrew Pinski  wrote:
>> 
>> On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc  wrote:
>>> 
>>> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be 
>>> precise) to build Ada, starting with the latest (2020) release of Gnat from 
>>> Adacore.
>> 
>> Are you building a cross compiler or a native compiler?
>> If you are building a cross, you need to bootstrap a native compiler first.
> 
> I'm not sure.  The installed Gnat is x86_64-darwin; I want to build 
> aarch64-darwin.

you are building a cross then.

> But in any case, how does that relate to the error messages I got?  They 
> don't seem to have anything to do with missing compilers, but rather with the 
> use of language features too new for the available (downloadable) Gnat.

Building a cross GNAT requires that the build compiler is from the same sources 
as the cross - so, as Andrew says, you need to bootstrap the current sources on 
x86_64 and then use that compiler to build the cross to aarch64.  I’m not sure 
exactly where this constraint is mentioned .. but, nevertheless, it is a 
constraint.

FWIW: I have not done this for a few weeks (using my arm64 prototype branch) 
but it was working fine then.

Iain

Re: [PATCH 19/56] Revert "Move void_list_node init to common code". (8ff2a92a0450243e52d3299a13b30f208bafa7e0)

[Richard Biener via Gcc-patches]

On Fri, Nov 25, 2022 at 9:46 AM Zopolis0 via Gcc-patches
 wrote:
>

Why?!

Re: [PATCH 14/56] middle-end: Set TREE_ADDRESSABLE in folding debug stmts.

[Richard Biener via Gcc-patches]

On Fri, Nov 25, 2022 at 9:43 AM Zopolis0 via Gcc-patches
 wrote:
>

That's wrong and the comment you remove explains why.

Re: Can't build Ada

[Andrew Pinski via Gcc]

On Fri, Nov 25, 2022 at 12:08 PM Paul Koning  wrote:
>
>
>
> > On Nov 25, 2022, at 3:03 PM, Andrew Pinski  wrote:
> >
> > On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc  
> > wrote:
> >>
> >> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be 
> >> precise) to build Ada, starting with the latest (2020) release of Gnat 
> >> from Adacore.
> >
> > Are you building a cross compiler or a native compiler?
> > If you are building a cross, you need to bootstrap a native compiler first.
>
> I'm not sure.  The installed Gnat is x86_64-darwin; I want to build 
> aarch64-darwin.

You have to build a x86_64-darwin compiler first with the same sources
as you are building for aarch64-darwin.

>
> But in any case, how does that relate to the error messages I got?  They 
> don't seem to have anything to do with missing compilers, but rather with the 
> use of language features too new for the available (downloadable) Gnat.

>From https://gcc.gnu.org/install/prerequisites.html:
"In order to build a cross compiler, it is strongly recommended to
install the new compiler as native first, and then use it to build the
cross compiler. Other native compiler versions may work but this is
not guaranteed and *will typically fail with hard to understand
compilation errors during the build."

I added the emphasis but yes this is all documented correctly.

Thanks,
Andrew Pinski

>
> paul
>
>

Re: Can't build Ada

[Paul Koning via Gcc]

> On Nov 25, 2022, at 3:03 PM, Andrew Pinski  wrote:
> 
> On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc  wrote:
>> 
>> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be 
>> precise) to build Ada, starting with the latest (2020) release of Gnat from 
>> Adacore.
> 
> Are you building a cross compiler or a native compiler?
> If you are building a cross, you need to bootstrap a native compiler first.

I'm not sure.  The installed Gnat is x86_64-darwin; I want to build 
aarch64-darwin.

But in any case, how does that relate to the error messages I got?  They don't 
seem to have anything to do with missing compilers, but rather with the use of 
language features too new for the available (downloadable) Gnat.

paul

Re: [PATCH] tree-optimization/107672 - avoid vector mode type_for_mode call

[Richard Biener via Gcc-patches]

On Fri, 25 Nov 2022, Vaseeharan Vinayagamoorthy wrote:


Hi,

I am seeing an internal compiler error, related to this patch:


Can you please open a bugzilla for this and attach preprocessed
source so I can reproduce the ICE with a cc1 cross compiler?

Thanks,
Richard.



during GIMPLE pass: slp

options-save.cc: In function 'void cl_optimization_restore(gcc_options*,
gcc_options*, cl_optimization*)':

options-save.cc:1292:1: internal compiler error: in
supportable_widening_operation, at tree-vect-stmts.cc:12199

 

 1292 | cl_optimization_restore (struct gcc_options *opts, struct
gcc_options *opts_set,

 | ^~~

/…/src/gcc/gcc/profile-count.cc: In member function 'int
profile_count::to_cgraph_frequency(profile_count) const':

/…/src/gcc/gcc/profile-count.cc:308:1: note: parameter passing for argument
of type 'profile_count' changed in GCC 9.1

 308 | profile_count::to_cgraph_frequency (profile_count entry_bb_count)
const

 | ^

/…/src/gcc/gcc/profile-count.cc: In member function 'sreal
profile_count::to_sreal_scale(profile_count, bool*) const':

/…/src/gcc/gcc/profile-count.cc:326:1: note: parameter passing for argument
of type 'profile_count' changed in GCC 9.1

 326 | profile_count::to_sreal_scale (profile_count in, bool *known) const

 | ^

0x2195bdd supportable_widening_operation(vec_info*, tree_code,
_stmt_vec_info*, tree_node*, tree_node*, tree_code*, tree_code*, int*,
vec*)

 /…/src/gcc/gcc/tree-vect-stmts.cc:12199

0x2180493 vectorizable_conversion

 /…/src/gcc/gcc/tree-vect-stmts.cc:5064

0x2192fdd vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*,
_slp_instance*, vec*)

 /…/src/gcc/gcc/tree-vect-stmts.cc:11256

 

/…/src/gcc/gcc/profile-count.cc: In member function 'profile_count
profile_count::combine_with_ipa_count(profile_count)':

/…/src/gcc/gcc/profile-count.cc:398:1: note: parameter passing for argument
of type 'profile_count' changed in GCC 9.1

 398 | profile_count::combine_with_ipa_count (profile_count ipa)

 | ^

0x14f95d1 vect_slp_analyze_node_operations_1

 /…/src/gcc/gcc/tree-vect-slp.cc:5958

0x14f9c19 vect_slp_analyze_node_operations

 /…/src/gcc/gcc/tree-vect-slp.cc:6147

0x14f9b4d vect_slp_analyze_node_operations

 /…/src/gcc/gcc/tree-vect-slp.cc:6126

0x14fa439 vect_slp_analyze_operations(vec_info*)

 /…/src/gcc/gcc/tree-vect-slp.cc:6387

0x14fd423 vect_slp_analyze_bb_1

 /…/src/gcc/gcc/tree-vect-slp.cc:7372

0x14fd599 vect_slp_region

 /…/src/gcc/gcc/tree-vect-slp.cc:7419

0x14fe0d1 vect_slp_bbs

 /…/src/gcc/gcc/tree-vect-slp.cc:7610

0x14fe46f vect_slp_function(function*)

 /…/src/gcc/gcc/tree-vect-slp.cc:7698

0x151a109 execute

 /…/src/gcc/gcc/tree-vectorizer.cc:1532

Please submit a full bug report, with preprocessed source (by using
-freport-bug).

Please include the complete backtrace with any bug report.

See  for instructions.

Makefile:1146: recipe for target 'options-save.o' failed

make[3]: *** [options-save.o] Error 1



That happens when building the arm-none-linux-gnueabihf toolchain natively
with glibc bootstrap:
Build:arm-none-linux-gnueabihf
Host:arm-none-linux-gnueabihf
Target: arm-none-linux-gnueabihf

The compiler being used to build the toolchain is gcc 7.5.0.


Kind regards
Vasee


From: Gcc-patches  on
behalf of Richard Biener via Gcc-patches 
Sent: 22 November 2022 08:48
To: gcc-patches@gcc.gnu.org 
Subject: [PATCH] tree-optimization/107672 - avoid vector mode type_for_mode
call  
The following avoids using type_for_mode on vector modes which might
not work for all frontends.  Instead we look for the inner mode
type and use build_vector_type_for_mode instead.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

    PR tree-optimization/107672
    * tree-vect-stmts.cc (supportable_widening_operation): Avoid
    type_for_mode on vector modes.
---
 gcc/tree-vect-stmts.cc | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index bc0ef136f19..b35b986889d 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -12195,9 +12195,15 @@ supportable_widening_operation (vec_info *vinfo,
 intermediate_type
   = vect_halve_mask_nunits (prev_type, intermediate_mode);
   else
-   intermediate_type
- = lang_hooks.types.type_for_mode (intermediate_mode,
-   TYPE_UNSIGNED (prev_type));
+   {
+ gcc_assert (VECTOR_MODE_P (intermediate_mode));
+ tree intermediate_element_type
+   = lang_hooks.types.type_for_mode (GET_MODE_INNER
(intermediate_mode),
+ TYPE_UNSIGNED (prev_type));
+ intermediate_type
+   = build_vector_type_for_mode (intermediate_element_type,
+ intermediate_mode);
+   }
 
   

Re: Can't build Ada

[Andrew Pinski via Gcc]

On Fri, Nov 25, 2022 at 11:59 AM Paul Koning via Gcc  wrote:
>
> I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be 
> precise) to build Ada, starting with the latest (2020) release of Gnat from 
> Adacore.

Are you building a cross compiler or a native compiler?
If you are building a cross, you need to bootstrap a native compiler first.

Thanks,
Andrew Pinski

>
> It fails for several reasons.  One is that two source files use [ ] for array 
> initializer brackets when ( ) is apparently supposed to be used instead.  
> Once I fix that, I get a pile of messages I don't know what to do about:
>
> s-imagei.ads:95:11: declare_expression is an Ada 2020 feature
> s-valueu.ads:152:09: declare_expression is an Ada 2020 feature
> s-valueu.ads:160:09: declare_expression is an Ada 2020 feature
> s-valueu.ads:184:06: "Subprogram_Variant" is not a valid aspect identifier
> s-valuei.ads:80:11: declare_expression is an Ada 2020 feature
> s-valuei.ads:95:08: declare_expression is an Ada 2020 feature
> s-valuei.ads:141:06: "Subprogram_Variant" is not a valid aspect identifier
> s-widthu.ads:84:09: declare_expression is an Ada 2020 feature
> s-widthu.ads:93:11: run-time library configuration error
> s-widthu.ads:93:11: file s-imgint.ads had parser errors
> s-widthu.ads:93:11: entity "System.Img_Int.Image_Integer" not available
> compilation abandoned
> make[2]: *** [ada/contracts.o] Error 1
>
> Given that the current open source Gnat is from 2020, so (apparently) it 
> doesn't support Ada 2020 features, how is someone supposed to build the 
> current GCC?  I looked in the prerequisites listing on the webpage, but it 
> says that the Gnat that is built on GCC 5.1 is sufficient.  That seems to be 
> wrong; the GCC in Gnat 2020 is 8.4.1 and it is apparently too old to work.
>
> paul
>

Can't build Ada

[Paul Koning via Gcc]

I'm trying to use fairly recent GCC sources (the gcc-darwin branch to be 
precise) to build Ada, starting with the latest (2020) release of Gnat from 
Adacore.

It fails for several reasons.  One is that two source files use [ ] for array 
initializer brackets when ( ) is apparently supposed to be used instead.  Once 
I fix that, I get a pile of messages I don't know what to do about:

s-imagei.ads:95:11: declare_expression is an Ada 2020 feature
s-valueu.ads:152:09: declare_expression is an Ada 2020 feature
s-valueu.ads:160:09: declare_expression is an Ada 2020 feature
s-valueu.ads:184:06: "Subprogram_Variant" is not a valid aspect identifier
s-valuei.ads:80:11: declare_expression is an Ada 2020 feature
s-valuei.ads:95:08: declare_expression is an Ada 2020 feature
s-valuei.ads:141:06: "Subprogram_Variant" is not a valid aspect identifier
s-widthu.ads:84:09: declare_expression is an Ada 2020 feature
s-widthu.ads:93:11: run-time library configuration error
s-widthu.ads:93:11: file s-imgint.ads had parser errors
s-widthu.ads:93:11: entity "System.Img_Int.Image_Integer" not available
compilation abandoned
make[2]: *** [ada/contracts.o] Error 1

Given that the current open source Gnat is from 2020, so (apparently) it 
doesn't support Ada 2020 features, how is someone supposed to build the current 
GCC?  I looked in the prerequisites listing on the webpage, but it says that 
the Gnat that is built on GCC 5.1 is sufficient.  That seems to be wrong; the 
GCC in Gnat 2020 is 8.4.1 and it is apparently too old to work.

paul

PING [PATCH v3] c++: Allow module name to be a single letter on Windows

[Torbjorn SVENSSON via Gcc-patches]

Hi,

Ping, https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606528.html

Kind regards,
Torbjörn

On 2022-11-17 14:20, Torbjörn SVENSSON wrote:

v1 -> v2:
Paths without "C:" part can still be absolute if they start with / or
\ on Windows.

v2 -> v3:
Use alternative approach by having platform specific code in module.cc.

Truth table for the new expression:
c:\foo -> true
c:/foo -> true
/foo   -> true
\foo   -> true
c:foo  -> false
foo-> false
./foo  -> true
.\foo  -> true


Ok for trunk?

---

On Windows, the ':' character is special and when the module name is
a single character, like 'A', then the flatname would be (for
example) 'A:Foo'. On Windows, 'A:Foo' is treated as an absolute
path by the module loader and is likely not found.

Without this patch, the test case pr98944_c.C fails with:

In module imported at /src/gcc/testsuite/g++.dg/modules/pr98944_b.C:7:1,
of module A:Foo, imported at /src/gcc/testsuite/g++.dg/modules/pr98944_c.C:7:
A:Internals: error: header module expected, module 'A:Internals' found
A:Internals: error: failed to read compiled module: Bad file data
A:Internals: note: compiled module file is 'gcm.cache/A-Internals.gcm'
In module imported at /src/gcc/testsuite/g++.dg/modules/pr98944_c.C:7:8:
A:Foo: error: failed to read compiled module: Bad import dependency
A:Foo: note: compiled module file is 'gcm.cache/A-Foo.gcm'
A:Foo: fatal error: returning to the gate for a mechanical issue
compilation terminated.

gcc/cp/ChangeLog:

* module.cc: On Windows, 'A:Foo' is supposed to be a module
and not a path.

Tested on Windows with arm-none-eabi for Cortex-M3 in gcc-11 tree.

Co-Authored-By: Yvan ROUX 
Signed-off-by: Torbjörn SVENSSON 
---
  gcc/cp/module.cc | 10 +-
  1 file changed, 9 insertions(+), 1 deletion(-)

diff --git a/gcc/cp/module.cc b/gcc/cp/module.cc
index 0e9af318ba4..fa41a86213f 100644
--- a/gcc/cp/module.cc
+++ b/gcc/cp/module.cc
@@ -13960,7 +13960,15 @@ get_module (tree name, module_state *parent, bool 
partition)
  static module_state *
  get_module (const char *ptr)
  {
-  if (ptr[0] == '.' ? IS_DIR_SEPARATOR (ptr[1]) : IS_ABSOLUTE_PATH (ptr))
+  /* On DOS based file systems, there is an ambiguity with A:B which can be
+ interpreted as a module Module:Partition or Drive:PATH.  Interpret strings
+ which clearly starts as pathnames as header-names and everything else is
+ treated as a (possibly malformed) named moduled.  */
+  if (IS_DIR_SEPARATOR (ptr[ptr[0] == '.']) // ./FOO or /FOO
+#if HAVE_DOS_BASED_FILE_SYSTEM
+  || (HAS_DRIVE_SPEC (ptr) && IS_DIR_SEPARATOR (ptr[2])) // A:/FOO
+#endif
+  || false)
  /* A header name.  */
  return get_module (build_string (strlen (ptr), ptr));
  

[Bug libstdc++/107871] New: _Iter_sink:: _M_overflow missing some difference type casting

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 107871
   Summary: _Iter_sink:: _M_overflow missing some difference type
casting
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

#include 

struct O {
  using difference_type = std::ranges::__detail::__max_diff_type;
  O& operator=(const char&);
  O& operator*();
  O& operator++();
  O& operator++(int);
};

int main() {
  std::format_to_n(O{}, 4, "{}", " ");
}

https://godbolt.org/z/x78qjfse6

Re: -fanalyzer: Questions on C vs CPP + use of GCC attr's like malloc()/access()

[Gavin Ray via Gcc]

> Unfortunately not: even fairly simple-looking C++ code can generate extra CFG
edges relating to exception-handling ... making the output essentially useless.

Ahh, I had figured the answer might be something like this. Thanks for
confirming. At least from the small codebase I have, swapping from C -> C++ when
compiling preserves all -fanalyzer warnings except for the ones from custom
malloc() attributes, so that's nice.

I won't count on the analyzer being able to do a stellar job though, so I'll
take what I can get =)

> I'm hoping to spend a good chunk of the GCC 14 development cycle working on
> adding C++ support

That's awesome! I hope you'll write some on these changes again -- I really
enjoyed reading your article on the state of Static Analysis in GCC 12 and your
LPC presentation.

I believe that's where I learned about the SARIF exporter, which with the VS
Code extension is just beyond cool!

> The analyzer makes use of the "malloc", "nonnull" and "const" function
attributes. It does make use of the "access" attribute, but only within
-Wanalyzer- tainted-size, for the case where the size param of the access is
attacker-controlled.

Ahh okay, thanks. I currently don't run the taint analysis, as this app is a
database a-la Postgres/SQLite built as a learning exercise/hobby so it's not so
much of a concern.

> the first [[gnu::malloc]] here is redundant, as it's implied by
> [[gnu::malloc(HeapPage_free, 1)]].

Good to know, ty -- it may be useful to modify the 'attribute' docs for these,
because currently it shows combined usage and phrases it as:

"Independently, the form of the attribute with one or two arguments associates
deallocator as a suitable deallocation function..."

__attribute__ ((malloc, malloc (fclose, 1))) FILE* fdopen (int, const char*);

On a related note, the "fd" analyzers warn: "fd may not be valid" but don't
clarify what "valid" means.

I found the DOT diagrams in the analyzer source and it turns out that the key is
to check "if (fd >= 0)". Maybe this could be added to the "fd" analyzer
warnings/info, too?



Anyways, sorry to drone on. I think that the GCC Static Analyzer and the LLVM
Dataflow Analysis Framework are vital for the the evolution of safety and
developer experience in authoring C/C++

Big thanks to all involved and it's exciting to watch the shortlog & follow the
progress from the sidelines =)

[Bug fortran/107870] A possible typo in the documentation of 'FLOOR'

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2022-11-25
   Keywords||documentation
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.  The standard uses A, so let's use that.

The standard nowadays also says about the KIND argument:

KIND (optional) shall be a scalar integer constant expression.

(instead of "initialization expression".)

We might adjust that for all affected intrinsics.

[Bug fortran/107870] New: A possible typo in the documentation of 'FLOOR'

[ninorpereira at gmail dot com via Gcc-bugs]

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

Bug ID: 107870
   Summary: A possible typo in the documentation of 'FLOOR'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ninorpereira at gmail dot com
  Target Milestone: ---

the documentation says: FLOOR(A) returns the greatest integer less than or
equal to X.
better is: FLOOR(A) returns the greatest integer less than or equal to A.
(and then the example must be changed from x to a, or
FLOOR(X) returns the greatest integer less than or equal to X (and then
the example can stay the same).

Re: -fanalyzer: Questions on C vs CPP + use of GCC attr's like malloc()/access()

[David Malcolm via Gcc]

On Wed, 2022-11-23 at 20:49 -0500, Gavin Ray via Gcc wrote:
> Hey all, just a few questions about the fantastic GCC Static
> Analyzer:

Hi!

> 
> - It's stated that support for C++ vs C is very limited. Does this
> apply if
>   you're writing C++ that is very similar-looking to C and uses few
> of C++'s
>   advanced features?

Unfortunately not: even fairly simple-looking C++ code can generate
extra CFG edges relating to exception-handling, which -fanalyzer
currently doesn't understand at all, making the output essentially
useless.  And that's just one issue...

Strictly speaking I have added some *very* minimal regression tests in
C++ to our test suite, but on anything beyond the most trivial example
it's likely to run into a known issue.  I'm tracking some of these
known issues here:
  https://gcc.gnu.org/bugzilla/showdependencytree.cgi?id=97110
but the C++ support is currently so minimal that it's probably not yet
worth filing extra bugs against that tracker :-/

I'm hoping to spend a good chunk of the GCC 14 development cycle
working on adding C++ support, with the aim of being able to analyze
GCC itself ("eating my own dog food"), so I hope this situation will
improve greatly then.

> 
> - I noticed that in C++, the "gnu::malloc" attributes don't seem to
> report
>   "warning: leak of 'xxx_alloc()' [CWE-401] [-Wanalyzer-malloc-
> leak]", is
> this
>   normal?

In theory they should; but you could be running into issues with the
analyzer not fully understanding the control flow graph.

> 
> - Is it worthwhile to spend time annotating your method signatures
> with
>   attributes like "malloc" and "access"? Do these aid the -fanalyzer
> passes?

The analyzer makes use of the "malloc", "nonnull" and "const" function
attributes.

It does make use of the "access" attribute, but only within -Wanalyzer-
tainted-size, for the case where the size param of the access is
attacker-controlled (and the taint checker is currently off by default,
even with -fanalyzer).

But like I said, don't expect these to work on C++ code yet.

> 
> For instance:
> 
> [[gnu::malloc]] [[gnu::malloc(HeapPage_free, 1)]]

IIRC, the first [[gnu::malloc]] here is redundant, as it's implied by
[[gnu::malloc(HeapPage_free, 1)]].

> [[gnu::returns_nonnull]]
> struct HeapPage* HeapPage_alloc();
> 
> [[gnu::access(read_write, 1, 3)]]
> struct RecordID
> HeapPage_insert_record(struct HeapPage* page, const char* record,
>    uint32_t record_length);
> 
> That's quite a significant bit of annotation-noise tacked on to the
> function, so
> I wanted to be sure it's worth the investment!

Maybe in GCC 14 onwards, but it definitely won't be worth it at the
moment.

Hope this is helpful
Dave

> 
> Thank you =)
> Gavin Ray
> 

Re: [PATCH v2 16/19] modula2 front end: bootstrap and documentation tools

[David Malcolm via Gcc-patches]

On Thu, 2022-11-24 at 14:30 +, Gaius Mulley via Gcc-patches wrote:
> Martin Liška  writes:
> 
> > On 11/8/22 14:22, Gaius Mulley wrote:
> > > Martin Liška  writes:
> > > 
> > > should be good - I'll complete the rst output in the scripts,
> > 
> > Hi.
> > 
> 
> Hi Martin,
> 
> > As you probably noticed, the Sphinx migration didn't go well.
> 
> Yes, sorry to see this didn't happen.  Thank you for your hard work
> and
> I hope it can occur in the future.

Likewise, thanks for all your work on this.

> 
> > However, it's still up to you if you want to use it or not for
> > Modula
> > 2.
> 
> Once modula-2 is in master I'd like to revisit rst in devel/modula-2
> along with analyzer patches and m2 generics.  If successful then
> submit
> patches in early stage 1.

Am I right in thinking the analyzer stuff would be an updated version
of the work you posted here:
 https://gcc.gnu.org/pipermail/gcc-patches/2021-April/567953.html
?

Thanks
Dave

[Bug target/83670] [10/11/12/13 Regression] m32c ICE in leaf_function_p, at final.c:4368

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

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

Andre Vehreschild  changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org

--- Comment #9 from Andre Vehreschild  ---
Created attachment 53966
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53966=edit
Prevent the ICE

I have no clue whether the attached patch is any good. It makes compile of
libgcc continue somewhat further, but then it fails when assigning registers
for a jump_ins.

[Bug target/106875] [11/12/13 Regression] ICE in ix86_emit_outlined_ms2sysv_save with -mabi=ms -mcall-ms2sysv-xlogues and "#pragma GCC target" since r11-3183-gba948b37768c99cd

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

Re: [PATCH v2 16/19] modula2 front end: bootstrap and documentation tools

[Martin Liška]

On 11/24/22 15:30, Gaius Mulley wrote:
> Martin Liška  writes:
> 
>> On 11/8/22 14:22, Gaius Mulley wrote:
>>> Martin Liška  writes:
>>>
>>> should be good - I'll complete the rst output in the scripts,
>>
>> Hi.
>>
> 
> Hi Martin,
> 
>> As you probably noticed, the Sphinx migration didn't go well.
> 
> Yes, sorry to see this didn't happen.  Thank you for your hard work and
> I hope it can occur in the future.

Hi.

We'll see, it's not in my plans for near future.

> 
>> However, it's still up to you if you want to use it or not for Modula
>> 2.
> 
> Once modula-2 is in master I'd like to revisit rst in devel/modula-2
> along with analyzer patches and m2 generics.  If successful then submit
> patches in early stage 1.

Sounds good.

> 
>> We have manuals like libgccjit, or Ada manuals
>> that use RST natively and provide exported .texi files.
> 
> Ok thanks for the pointers, I will experiment with these build rhunes.
> 
>> Cheers and sorry for the troubles I caused.
> 
> No problem at all - the modula-2 scripts are now improved and cleaner
> due to the port.  Hopefully rst will happen sometime in the future,

Regards,
Martin

> 
> regards,
> Gaius

Re: About -fasan-shadow-offset option

[Martin Liška]

On 11/16/22 10:01, tao.z...@amlogic.com wrote:
> Dear gcc:
> 

Hello.

Based on quick discussion with Jakub, we believe fasan-shadow-symbol= would 
be a non-trivial amount of work
and we rather suggest doing a per-system build with investigated 
-fasan-shadow-offset.

Cheers,
Martin

> I am developing a address sanitiser tools for u-boot. Basically refers 
> compile options from kernel side. But there is a problem that I must set 
> -fasan-shadow-offset with a pre-calculated value. Otherwise GCC compiler will 
> use 0x10 as default value for shadow offset and caused boot failed 
> because this value is too large.
> The problem is uboot do not have a fixed memory layout as kernel. 
> Basically it will relocate to end of DDR size and running at that memory 
> space. Usually memory map for uboot is virt=phys and there are lots of 
> drivers do not do address translate for dma based on this mapping. But ddr 
> size are different on each platform. So it's hard to handle shadow offset at 
> this scenario.
> My point is that can gcc add an option like -fasan-shadow-symbol=, 
> here  is a global variable and implementors can configure it's value 
> based on platforms ddr size/malloc buffer size during initialize stage and 
> this variable can be used for shadow address calculation during runtime. This 
> may be more fitable compared than a fixed value during compile stage.  And is 
> there any other options to help my problem?
> Waiting for your response asap.
>  Thanks.
> 
> 
> 
> Thanks!
> B.R.
> tao.z...@amlogic.com
>  
> Address： Building E5, 2555 Xiupu Road, Pudong District, Shanghai, China
> 公司地址：上海市浦东新区秀浦路2555号漕河泾康桥商务绿洲E5栋
> 

Re: [PATCH][PING][sanitizer/106558] asan: fix unsafe optimization of Asan checks.

[Martin Liška]

On 11/21/22 11:02, Jakub Jelinek wrote:
> Otherwise LGTM.  Thanks and sorry for the review delay.

Yuri, do you want to commit the patch soon?

If not, I can help if you want?

Cheers,
Martin

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

[juzhe . zhong]

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.

---
 gcc/config/riscv/constraints.md   |   5 +
 gcc/config/riscv/predicates.md|   5 +
 gcc/config/riscv/riscv-protos.h   |   2 +
 gcc/config/riscv/riscv-selftests.cc   | 127 +
 gcc/config/riscv/riscv-v.cc   |  86 ++-
 gcc/config/riscv/riscv.cc |  13 +
 gcc/config/riscv/riscv.h  |   3 +
 gcc/config/riscv/vector-iterators.md  |   9 +
 gcc/config/riscv/vector.md|  53 +-
 .../gcc.target/riscv/rvv/base/dup-1.c | 521 ++
 .../gcc.target/riscv/rvv/base/dup-2.c |  75 +++
 11 files changed, 881 insertions(+), 18 deletions(-)
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/dup-1.c
 create mode 100644 gcc/testsuite/gcc.target/riscv/rvv/base/dup-2.c

diff --git a/gcc/config/riscv/constraints.md b/gcc/config/riscv/constraints.md
index 4088c48150a..51cffb2bcb6 100644
--- a/gcc/config/riscv/constraints.md
+++ b/gcc/config/riscv/constraints.md
@@ -151,3 +151,8 @@
  A constraint that matches a vector of immediate all ones."
  (and (match_code "const_vector")
   (match_test "op == CONSTM1_RTX (GET_MODE (op))")))
+
+(define_constraint "Wdm"
+  "Vector duplicate memory operand"
+  (and (match_operand 0 "memory_operand")
+   (match_code "reg" "0")))
diff --git a/gcc/config/riscv/predicates.md b/gcc/config/riscv/predicates.md
index dfd98761b8b..5a5a49bf7c0 100644
--- a/gcc/config/riscv/predicates.md
+++ b/gcc/config/riscv/predicates.md
@@ -286,6 +286,11 @@
(match_test "GET_CODE (op) == UNSPEC
 && (XINT (op, 1) == UNSPEC_VUNDEF)"
 
+;; The scalar operand can be directly broadcast by RVV instructions.
+(define_predicate "direct_broadcast_operand"
+  (ior (match_operand 0 "register_operand")
+   (match_test "satisfies_constraint_Wdm (op)")))
+
 ;; A CONST_INT operand that has exactly two bits cleared.
 (define_predicate "const_nottwobits_operand"
   (and (match_code "const_int")
diff --git a/gcc/config/riscv/riscv-protos.h b/gcc/config/riscv/riscv-protos.h
index 2ec3af05aa4..27692ffb210 100644
--- a/gcc/config/riscv/riscv-protos.h
+++ b/gcc/config/riscv/riscv-protos.h
@@ -119,6 +119,7 @@ extern void riscv_run_selftests (void);
 #endif
 
 namespace riscv_vector {
+#define RVV_VLMAX gen_rtx_REG (Pmode, X0_REGNUM)
 /* Routines implemented in riscv-vector-builtins.cc.  */
 extern void init_builtins (void);
 extern const char *mangle_builtin_type (const_tree);
@@ -130,6 +131,7 @@ extern tree builtin_decl (unsigned, bool);
 extern rtx expand_builtin (unsigned int, tree, rtx);
 extern bool const_vec_all_same_in_range_p (rtx, HOST_WIDE_INT, HOST_WIDE_INT);
 extern bool legitimize_move (rtx, rtx, machine_mode);
+extern void emit_pred_op (unsigned, rtx, rtx, machine_mode);
 enum tail_policy
 {
   TAIL_UNDISTURBED = 0,
diff --git a/gcc/config/riscv/riscv-selftests.cc 
b/gcc/config/riscv/riscv-selftests.cc
index 636874ebc0f..1bf1a648fa1 100644
--- a/gcc/config/riscv/riscv-selftests.cc
+++ b/gcc/config/riscv/riscv-selftests.cc
@@ -33,6 +33,9 @@ along with GCC; see the file COPYING3.  If not see
 #include "expr.h"
 #include "selftest.h"
 #include "selftest-rtl.h"
+#include "insn-attr.h"
+#include "target.h"
+#include "optabs.h"
 
 #if CHECKING_P
 using namespace selftest;
@@ -230,12 +233,136 @@ run_poly_int_selftests (void)
   run_poly_int_selftest ("rv32imafd_zve32x1p0", ABI_ILP32D, POLY_TEST_DIMODE,
 worklist);
 }
+
+static void
+run_const_vector_selftests (void)
+{
+  /* We dont't need to do the redundant tests in different march && mabi.
+ Just pick up the march && mabi which fully support all RVV modes.  */
+  riscv_selftest_arch_abi_setter rv ("rv64imafdcv", ABI_LP64D);
+  rtl_dump_test t (SELFTEST_LOCATION, locate_file 

Re: [PATCH] sync libsframe toplevel from binutils-gdb

[Richard Sandiford via Gcc-patches]

Richard Earnshaw via Gcc-patches  writes:
> This pulls in the toplevel portion of this binutils-gdb commit:
>19e559f1c91bfaedbd2f91d85ee161f3f03fda3c libsframe: add the SFrame library
>
> ChangeLog:
>   * Makefile.def: Add libsframe as new module with its dependencies.
>   * Makefile.in: Regenerated.
>   * configure.ac: Add libsframe to host_libs.
>   * configure: Regenerated.

OK, thanks.

Richard

> ---
>  Makefile.def |2 +
>  Makefile.in  | 1288 +-
>  configure|2 +-
>  configure.ac |2 +-
>  4 files changed, 1287 insertions(+), 7 deletions(-)
>
> diff --git a/Makefile.def b/Makefile.def
> index 02e63c57177..83ae77586ad 100644
> --- a/Makefile.def
> +++ b/Makefile.def
> @@ -145,6 +145,7 @@ host_modules= { module= lto-plugin; bootstrap=true;
>  host_modules= { module= libcc1; extra_configure_flags=--enable-shared; };
>  host_modules= { module= gotools; };
>  host_modules= { module= libctf; bootstrap=true; };
> +host_modules= { module= libsframe; bootstrap=true; };
>  
>  target_modules = { module= libstdc++-v3;
>  bootstrap=true;
> @@ -470,6 +471,7 @@ dependencies = { module=all-binutils; on=all-intl; };
>  dependencies = { module=all-binutils; on=all-gas; };
>  dependencies = { module=all-binutils; on=all-libctf; };
>  dependencies = { module=all-ld; on=all-libctf; };
> +dependencies = { module=all-binutils; on=all-libsframe; };
>  
>  // We put install-opcodes before install-binutils because the installed
>  // binutils might be on PATH, and they might need the shared opcodes
> diff --git a/Makefile.in b/Makefile.in
> index 6ffa9660c25..e5bed1bea3a 100644
> --- a/Makefile.in
> +++ b/Makefile.in
> @@ -1097,7 +1097,8 @@ configure-host:  \
>  maybe-configure-lto-plugin \
>  maybe-configure-libcc1 \
>  maybe-configure-gotools \
> -maybe-configure-libctf
> +maybe-configure-libctf \
> +maybe-configure-libsframe
>  .PHONY: configure-target
>  configure-target:  \
>  maybe-configure-target-libstdc++-v3 \
> @@ -1273,6 +1274,9 @@ all-host: maybe-all-gotools
>  @if libctf-no-bootstrap
>  all-host: maybe-all-libctf
>  @endif libctf-no-bootstrap
> +@if libsframe-no-bootstrap
> +all-host: maybe-all-libsframe
> +@endif libsframe-no-bootstrap
>  
>  .PHONY: all-target
>  
> @@ -1384,6 +1388,7 @@ info-host: maybe-info-lto-plugin
>  info-host: maybe-info-libcc1
>  info-host: maybe-info-gotools
>  info-host: maybe-info-libctf
> +info-host: maybe-info-libsframe
>  
>  .PHONY: info-target
>  
> @@ -1472,6 +1477,7 @@ dvi-host: maybe-dvi-lto-plugin
>  dvi-host: maybe-dvi-libcc1
>  dvi-host: maybe-dvi-gotools
>  dvi-host: maybe-dvi-libctf
> +dvi-host: maybe-dvi-libsframe
>  
>  .PHONY: dvi-target
>  
> @@ -1560,6 +1566,7 @@ pdf-host: maybe-pdf-lto-plugin
>  pdf-host: maybe-pdf-libcc1
>  pdf-host: maybe-pdf-gotools
>  pdf-host: maybe-pdf-libctf
> +pdf-host: maybe-pdf-libsframe
>  
>  .PHONY: pdf-target
>  
> @@ -1648,6 +1655,7 @@ html-host: maybe-html-lto-plugin
>  html-host: maybe-html-libcc1
>  html-host: maybe-html-gotools
>  html-host: maybe-html-libctf
> +html-host: maybe-html-libsframe
>  
>  .PHONY: html-target
>  
> @@ -1736,6 +1744,7 @@ TAGS-host: maybe-TAGS-lto-plugin
>  TAGS-host: maybe-TAGS-libcc1
>  TAGS-host: maybe-TAGS-gotools
>  TAGS-host: maybe-TAGS-libctf
> +TAGS-host: maybe-TAGS-libsframe
>  
>  .PHONY: TAGS-target
>  
> @@ -1824,6 +1833,7 @@ install-info-host: maybe-install-info-lto-plugin
>  install-info-host: maybe-install-info-libcc1
>  install-info-host: maybe-install-info-gotools
>  install-info-host: maybe-install-info-libctf
> +install-info-host: maybe-install-info-libsframe
>  
>  .PHONY: install-info-target
>  
> @@ -1912,6 +1922,7 @@ install-dvi-host: maybe-install-dvi-lto-plugin
>  install-dvi-host: maybe-install-dvi-libcc1
>  install-dvi-host: maybe-install-dvi-gotools
>  install-dvi-host: maybe-install-dvi-libctf
> +install-dvi-host: maybe-install-dvi-libsframe
>  
>  .PHONY: install-dvi-target
>  
> @@ -2000,6 +2011,7 @@ install-pdf-host: maybe-install-pdf-lto-plugin
>  install-pdf-host: maybe-install-pdf-libcc1
>  install-pdf-host: maybe-install-pdf-gotools
>  install-pdf-host: maybe-install-pdf-libctf
> +install-pdf-host: maybe-install-pdf-libsframe
>  
>  .PHONY: install-pdf-target
>  
> @@ -2088,6 +2100,7 @@ install-html-host: maybe-install-html-lto-plugin
>  install-html-host: maybe-install-html-libcc1
>  install-html-host: maybe-install-html-gotools
>  install-html-host: maybe-install-html-libctf
> +install-html-host: maybe-install-html-libsframe
>  
>  .PHONY: install-html-target
>  
> @@ -2176,6 +2189,7 @@ installcheck-host: maybe-installcheck-lto-plugin
>  installcheck-host: maybe-installcheck-libcc1
>  installcheck-host: maybe-installcheck-gotools
>  installcheck-host: maybe-installcheck-libctf
> +installcheck-host: maybe-installcheck-libsframe
>  
>  .PHONY: installcheck-target
>  
> @@ -2264,6 +2278,7 @@ mostlyclean-host: maybe-mostlyclean-lto-plugin
>  

Re: [PATCH]rs6000: Load high and low part of 64bit constant independently

[Segher Boessenkool]

Hi!

On Fri, Nov 25, 2022 at 09:21:21PM +0800, Jiufu Guo wrote:
> "Kewen.Lin"  writes:
> > on 2022/9/15 16:30, Jiufu Guo wrote:
> >> For a complicate 64bit constant, blow is one instruction-sequence to
> >> build:
> >>lis 9,0x800a
> >>ori 9,9,0xabcd
> >>sldi 9,9,32
> >>oris 9,9,0xc167
> >>ori 9,9,0xfa16
> >> 
> >> while we can also use below sequence to build:
> >>lis 9,0xc167
> >>lis 10,0x800a
> >>ori 9,9,0xfa16
> >>ori 10,10,0xabcd
> >>rldimi 9,10,32,0
> >> This sequence is using 2 registers to build high and low part firstly,
> >> and then merge them.
> >> In parallel aspect, this sequence would be faster. (Ofcause, using 1 more
> >> register with potential register pressure).

And crucially this patch only uses two registers if can_create_pseudo_p.
Please mention that.

> >>* config/rs6000/rs6000.cc (rs6000_emit_set_long_const): Update 64bit
> >>constant build.

If you don't give details of what this does, just say "Update." please.
But update to what?

"Generate more parallel code if can_create_pseudo_p." maybe?

> >> +rtx H = gen_reg_rtx (DImode);
> >> +rtx L = gen_reg_rtx (DImode);

Please don't use all-uppercase variable names, those are for macros.  In
fact, don't use uppercase in variable (and function etc.) names at all,
unless there is a really good reason to.

Just call it "high" and "low", or "hi" and "lo", or something?

> >> --- /dev/null
> >> +++ b/gcc/testsuite/gcc.target/powerpc/parall_5insn_const.c
> >> @@ -0,0 +1,27 @@
> >> +/* { dg-do run } */
> >> +/* { dg-options "-O2 -mdejagnu-cpu=power7  -save-temps" } */
> >
> > Why do we need power7 here?
> power8/9 are also ok for this case.  Actually, O just want to
> avoid to use new p10 instruction, like "pli", and then selected
> an old arch option.

Why does it need _at least_ p7, is the question (as I understand it).

To prohibit pli etc. you can do -mno-prefixed (which works on all older
CPUs just as well), or skip the test if prefixed insns are enabled, or
scan for the then generated code as well.  The first option is by far
the simplest.

> --- /dev/null
> +++ b/gcc/testsuite/gcc.target/powerpc/parall_5insn_const.c
> @@ -0,1 +1,27 @@
> +/* { dg-do run } */
> +/* { dg-options "-O2 -mdejagnu-cpu=power8  -save-temps" } */
> +/* { dg-require-effective-target has_arch_ppc64 } */

p8 here makes no sense, we also want good and correct code generated for
older CPUs, so we should not preevent testing on those.  For that reason
you shouldn't use -mcpu= when not needed.  Like here :-)

[Bug tree-optimization/106878] [11/12 Regression] ICE: verify_gimple failed at -O2 with pointers and bitwise calculation

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[11/12/13 Regression] ICE:  |[11/12 Regression] ICE:
   |verify_gimple failed at -O2 |verify_gimple failed at -O2
   |with pointers and bitwise   |with pointers and bitwise
   |caluclation |calculation

--- Comment #11 from Jakub Jelinek  ---
Fixed on the trunk I believe.

[Bug c++/84469] structured binding inside for all loop thinks it is type depedent when it is not (inside a template)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug c++/99576] [coroutines] destructor of a temporary called too early within co_await expression

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

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

--- Comment #6 from Iain Sandoe  ---
(In reply to Adrian Perl from comment #5)
> Created attachment 53963 [details]

thanks for the analysis and the patch.

> Patch:
> diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
> index 01a3e831ee5..349b68ea239 100644
> --- a/gcc/cp/coroutines.cc
> +++ b/gcc/cp/coroutines.cc
> @@ -2684,6 +2684,10 @@ find_interesting_subtree (tree *expr_p, int *dosub,
> void *d)
> return expr;
>   }
>  }
> +  else if (TREE_CODE(expr) == CONSTRUCTOR)
> +{
> +  *dosub = 0; /* We don't need to consider this any further.  */
> +}

small nit - the { } are not needed here ^

>else if (tmp_target_expr_p (expr)
>  && !p->temps_used->contains (expr))
>  {
> -- 
> 2.34.1

Your reasoning (I know that several of the outstanding issues are related to
'promotion' of temporaries to the frame) and the patch seem reasonable.  

Have you bootstrapped the compiler with the changes and run the whole of the
testsuite? (I do agree that this change should only affect coroutines, but we
still do the full check too).

The test-cases would need to be added to the gcc/testsuite/g++.dg/coroutines
(with names that reflect the PRs that they test).

once you have things to that stage, then please post the patch to
gcc-patc...@gcc.gnu.org (along with the test cases added), and we can go from
there.

[committed] libstdc++: Fix orphaned/nested output of configure checks

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux. Pushed to trunk.

-- >8 --

This moves two AC_MSG_RESULT lines for  features so that they
are only printed when the corresponding AC_MSG_CHECKING actually
happened. This fixes configure output like:

checking for uchar.h... no
no
checking for int64_t... yes

Also move the AC_MSG_CHECKING for libbacktrace support so it doesn't
come after AC_CHECK_HEADERS output. This fixes:

checking whether to build libbacktrace support... checking for sys/mman.h... 
(cached) yes
yes

libstdc++-v3/ChangeLog:

* acinclude.m4 (GLIBCXX_CHECK_UCHAR_H): Don't use AC_MSG_RESULT
unless the AC_MSG_CHECKING happened.
* configure: Regenerate.
---
 libstdc++-v3/acinclude.m4 |  6 +++---
 libstdc++-v3/configure| 12 ++--
 2 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/libstdc++-v3/acinclude.m4 b/libstdc++-v3/acinclude.m4
index baf01913a90..b957c728ba1 100644
--- a/libstdc++-v3/acinclude.m4
+++ b/libstdc++-v3/acinclude.m4
@@ -2060,10 +2060,10 @@ AC_DEFUN([GLIBCXX_CHECK_UCHAR_H], [
   ],
   [], [ac_uchar_c8rtomb_mbrtoc8_fchar8_t=yes],
   [ac_uchar_c8rtomb_mbrtoc8_fchar8_t=no])
+AC_MSG_RESULT($ac_uchar_c8rtomb_mbrtoc8_fchar8_t)
   else
 ac_uchar_c8rtomb_mbrtoc8_fchar8_t=no
   fi
-  AC_MSG_RESULT($ac_uchar_c8rtomb_mbrtoc8_fchar8_t)
   if test x"$ac_uchar_c8rtomb_mbrtoc8_fchar8_t" = x"yes"; then
 AC_DEFINE(_GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_FCHAR8_T, 1,
  [Define if c8rtomb and mbrtoc8 functions in  should be
@@ -2082,10 +2082,10 @@ AC_DEFUN([GLIBCXX_CHECK_UCHAR_H], [
   ],
   [], [ac_uchar_c8rtomb_mbrtoc8_cxx20=yes],
   [ac_uchar_c8rtomb_mbrtoc8_cxx20=no])
+AC_MSG_RESULT($ac_uchar_c8rtomb_mbrtoc8_cxx20)
   else
 ac_uchar_c8rtomb_mbrtoc8_cxx20=no
   fi
-  AC_MSG_RESULT($ac_uchar_c8rtomb_mbrtoc8_cxx20)
   if test x"$ac_uchar_c8rtomb_mbrtoc8_cxx20" = x"yes"; then
 AC_DEFINE(_GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_CXX20, 1,
  [Define if c8rtomb and mbrtoc8 functions in  should be
@@ -5045,6 +5045,7 @@ BACKTRACE_CPPFLAGS="$BACKTRACE_CPPFLAGS 
-DBACKTRACE_ELF_SIZE=$elfsize"
   if test "$enable_libstdcxx_backtrace" = "auto"; then
 enable_libstdcxx_backtrace=no
   fi
+  AC_MSG_RESULT($enable_libstdcxx_backtrace)
   if test "$enable_libstdcxx_backtrace" = "yes"; then
 BACKTRACE_SUPPORTED=1
 
@@ -5091,7 +5092,6 @@ BACKTRACE_CPPFLAGS="$BACKTRACE_CPPFLAGS 
-DBACKTRACE_ELF_SIZE=$elfsize"
 BACKTRACE_USES_MALLOC=0
 BACKTRACE_SUPPORTS_THREADS=0
   fi
-  AC_MSG_RESULT($enable_libstdcxx_backtrace)
   GLIBCXX_CONDITIONAL(ENABLE_BACKTRACE, [test "$enable_libstdcxx_backtrace" = 
yes])
 ])
 
diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure
index 31ccff5da0d..1f7017c08a4 100755
--- a/libstdc++-v3/configure
+++ b/libstdc++-v3/configure
@@ -19215,11 +19215,11 @@ else
   ac_uchar_c8rtomb_mbrtoc8_fchar8_t=no
 fi
 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: 
$ac_uchar_c8rtomb_mbrtoc8_fchar8_t" >&5
+$as_echo "$ac_uchar_c8rtomb_mbrtoc8_fchar8_t" >&6; }
   else
 ac_uchar_c8rtomb_mbrtoc8_fchar8_t=no
   fi
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: 
$ac_uchar_c8rtomb_mbrtoc8_fchar8_t" >&5
-$as_echo "$ac_uchar_c8rtomb_mbrtoc8_fchar8_t" >&6; }
   if test x"$ac_uchar_c8rtomb_mbrtoc8_fchar8_t" = x"yes"; then
 
 $as_echo "#define _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_FCHAR8_T 1" >>confdefs.h
@@ -19253,11 +19253,11 @@ else
   ac_uchar_c8rtomb_mbrtoc8_cxx20=no
 fi
 rm -f core conftest.err conftest.$ac_objext conftest.$ac_ext
+{ $as_echo "$as_me:${as_lineno-$LINENO}: result: 
$ac_uchar_c8rtomb_mbrtoc8_cxx20" >&5
+$as_echo "$ac_uchar_c8rtomb_mbrtoc8_cxx20" >&6; }
   else
 ac_uchar_c8rtomb_mbrtoc8_cxx20=no
   fi
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: 
$ac_uchar_c8rtomb_mbrtoc8_cxx20" >&5
-$as_echo "$ac_uchar_c8rtomb_mbrtoc8_cxx20" >&6; }
   if test x"$ac_uchar_c8rtomb_mbrtoc8_cxx20" = x"yes"; then
 
 $as_echo "#define _GLIBCXX_USE_UCHAR_C8RTOMB_MBRTOC8_CXX20 1" >>confdefs.h
@@ -71212,6 +71212,8 @@ $as_echo_n "checking whether to build libbacktrace 
support... " >&6; }
   if test "$enable_libstdcxx_backtrace" = "auto"; then
 enable_libstdcxx_backtrace=no
   fi
+  { $as_echo "$as_me:${as_lineno-$LINENO}: result: 
$enable_libstdcxx_backtrace" >&5
+$as_echo "$enable_libstdcxx_backtrace" >&6; }
   if test "$enable_libstdcxx_backtrace" = "yes"; then
 BACKTRACE_SUPPORTED=1
 
@@ -71280,8 +71282,6 @@ $as_echo "#define HAVE_STACKTRACE 1" >>confdefs.h
 BACKTRACE_USES_MALLOC=0
 BACKTRACE_SUPPORTS_THREADS=0
   fi
-  { $as_echo "$as_me:${as_lineno-$LINENO}: result: 
$enable_libstdcxx_backtrace" >&5
-$as_echo "$enable_libstdcxx_backtrace" >&6; }
 
 
 
-- 
2.38.1

[committed] libstdc++: Call predicate with non-const values in std::erase_if [PR107850]

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux. Pushed to trunk. Backport to gcc-12 needed too.

-- >8 --

As specified in the standard, the predicate for std::erase_if has to be
invocable as non-const with a non-const lvalues argument. Restore
support for predicates that only accept non-const arguments.

It's not strictly nevessary to change it for the set and unordered_set
overloads, because they only give const access to the elements anyway.
I've done it for them too just to keep them all consistent.

libstdc++-v3/ChangeLog:

PR libstdc++/107850
* include/bits/erase_if.h (__erase_nodes_if): Use non-const
reference to the container.
* include/experimental/map (erase_if): Likewise.
* include/experimental/set (erase_if): Likewise.
* include/experimental/unordered_map (erase_if): Likewise.
* include/experimental/unordered_set (erase_if): Likewise.
* include/std/map (erase_if): Likewise.
* include/std/set (erase_if): Likewise.
* include/std/unordered_map (erase_if): Likewise.
* include/std/unordered_set (erase_if): Likewise.
* testsuite/23_containers/map/erasure.cc: Check with
const-incorrect predicate.
* testsuite/23_containers/set/erasure.cc: Likewise.
* testsuite/23_containers/unordered_map/erasure.cc: Likewise.
* testsuite/23_containers/unordered_set/erasure.cc: Likewise.
* testsuite/experimental/map/erasure.cc: Likewise.
* testsuite/experimental/set/erasure.cc: Likewise.
* testsuite/experimental/unordered_map/erasure.cc: Likewise.
* testsuite/experimental/unordered_set/erasure.cc: Likewise.
---
 libstdc++-v3/include/bits/erase_if.h|  2 +-
 libstdc++-v3/include/experimental/map   |  6 ++
 libstdc++-v3/include/experimental/set   |  4 ++--
 libstdc++-v3/include/experimental/unordered_map |  4 ++--
 libstdc++-v3/include/experimental/unordered_set |  4 ++--
 libstdc++-v3/include/std/map|  6 ++
 libstdc++-v3/include/std/set|  4 ++--
 libstdc++-v3/include/std/unordered_map  |  4 ++--
 libstdc++-v3/include/std/unordered_set  |  4 ++--
 libstdc++-v3/testsuite/23_containers/map/erasure.cc | 13 +
 libstdc++-v3/testsuite/23_containers/set/erasure.cc | 13 +
 .../23_containers/unordered_map/erasure.cc  | 13 +
 .../23_containers/unordered_set/erasure.cc  | 13 +
 libstdc++-v3/testsuite/experimental/map/erasure.cc  | 13 +
 libstdc++-v3/testsuite/experimental/set/erasure.cc  | 13 +
 .../testsuite/experimental/unordered_map/erasure.cc | 13 +
 .../testsuite/experimental/unordered_set/erasure.cc | 13 +
 17 files changed, 121 insertions(+), 21 deletions(-)

diff --git a/libstdc++-v3/include/bits/erase_if.h 
b/libstdc++-v3/include/bits/erase_if.h
index 397207f4b56..b336e263d2d 100644
--- a/libstdc++-v3/include/bits/erase_if.h
+++ b/libstdc++-v3/include/bits/erase_if.h
@@ -49,7 +49,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 template
   typename _Container::size_type
-  __erase_nodes_if(_Container& __cont, const _UnsafeContainer& __ucont,
+  __erase_nodes_if(_Container& __cont, _UnsafeContainer& __ucont,
   _Predicate __pred)
   {
typename _Container::size_type __num = 0;
diff --git a/libstdc++-v3/include/experimental/map 
b/libstdc++-v3/include/experimental/map
index 525252b83c1..9557a2aec1c 100644
--- a/libstdc++-v3/include/experimental/map
+++ b/libstdc++-v3/include/experimental/map
@@ -53,8 +53,7 @@ inline namespace fundamentals_v2
 inline void
 erase_if(map<_Key, _Tp, _Compare, _Alloc>& __cont, _Predicate __pred)
 {
-  const _GLIBCXX_STD_C::map<_Key, _Tp, _Compare, _Alloc>&
-   __ucont = __cont;
+  _GLIBCXX_STD_C::map<_Key, _Tp, _Compare, _Alloc>& __ucont = __cont;
   std::__detail::__erase_nodes_if(__cont, __ucont, __pred);
 }
 
@@ -63,8 +62,7 @@ inline namespace fundamentals_v2
 inline void
 erase_if(multimap<_Key, _Tp, _Compare, _Alloc>& __cont, _Predicate __pred)
 {
-  const _GLIBCXX_STD_C::multimap<_Key, _Tp, _Compare, _Alloc>&
-   __ucont = __cont;
+  _GLIBCXX_STD_C::multimap<_Key, _Tp, _Compare, _Alloc>& __ucont = __cont;
   std::__detail::__erase_nodes_if(__cont, __ucont, __pred);
 }
 
diff --git a/libstdc++-v3/include/experimental/set 
b/libstdc++-v3/include/experimental/set
index b42a3cdcf1a..7d142e081d9 100644
--- a/libstdc++-v3/include/experimental/set
+++ b/libstdc++-v3/include/experimental/set
@@ -53,7 +53,7 @@ inline namespace fundamentals_v2
 inline void
 erase_if(set<_Key, _Compare, _Alloc>& __cont, _Predicate __pred)
 {
-  const _GLIBCXX_STD_C::set<_Key, _Compare, _Alloc>& __ucont = __cont;
+  _GLIBCXX_STD_C::set<_Key, _Compare, _Alloc>& __ucont = __cont;
   std::__detail::__erase_nodes_if(__cont, __ucont, 

[committed] libstdc++: Do not define operator!= in for C++20

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux. Pushed to trunk.

-- >8 --

These overloads are not needed in C++20 as they can be synthesized by
the compiler. Removing them means less code to compile when including
these headers.

libstdc++-v3/ChangeLog:

* include/bits/random.h [three_way_comparison] (operator!=):
Do not define inequality operators when C++20 three way
comparisons are supported.
* include/ext/random [three_way_comparison] (operator!=):
Likewise.
---
 libstdc++-v3/include/bits/random.h | 106 -
 libstdc++-v3/include/ext/random|  72 
 2 files changed, 148 insertions(+), 30 deletions(-)

diff --git a/libstdc++-v3/include/bits/random.h 
b/libstdc++-v3/include/bits/random.h
index 28b37a9e5a5..3b4e7d42bb5 100644
--- a/libstdc++-v3/include/bits/random.h
+++ b/libstdc++-v3/include/bits/random.h
@@ -423,6 +423,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _UIntType _M_x;
 };
 
+#if __cpp_impl_three_way_comparison < 201907L
   /**
* @brief Compares two linear congruential random number generator
* objects of the same type for inequality.
@@ -441,7 +442,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   const std::linear_congruential_engine<_UIntType, __a,
   __c, __m>& __rhs)
 { return !(__lhs == __rhs); }
-
+#endif
 
   /**
* A generalized feedback shift register discrete random number generator.
@@ -656,6 +657,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   size_t_M_p;
 };
 
+#if __cpp_impl_three_way_comparison < 201907L
   /**
* @brief Compares two % mersenne_twister_engine random number generator
*objects of the same type for inequality.
@@ -679,7 +681,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   const std::mersenne_twister_engine<_UIntType, __w, __n, __m,
   __r, __a, __u, __d, __s, __b, __t, __c, __l, __f>& __rhs)
 { return !(__lhs == __rhs); }
-
+#endif
 
   /**
* @brief The Marsaglia-Zaman generator.
@@ -862,6 +864,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   size_t _M_p; ///< Current index of x(i - r).
 };
 
+#if __cpp_impl_three_way_comparison < 201907L
   /**
* @brief Compares two % subtract_with_carry_engine random number
*generator objects of the same type for inequality.
@@ -881,7 +884,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   const std::subtract_with_carry_engine<_UIntType, __w,
   __s, __r>& __rhs)
 { return !(__lhs == __rhs); }
-
+#endif
 
   /**
* Produces random numbers from some base engine by discarding blocks of
@@ -1087,6 +1090,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   size_t _M_n;
 };
 
+#if __cpp_impl_three_way_comparison < 201907L
   /**
* @brief Compares two %discard_block_engine random number generator
*objects of the same type for inequality.
@@ -1105,7 +1109,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   const std::discard_block_engine<_RandomNumberEngine, __p,
   __r>& __rhs)
 { return !(__lhs == __rhs); }
-
+#endif
 
   /**
* Produces random numbers by combining random numbers from some base
@@ -1284,6 +1288,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   _RandomNumberEngine _M_b;
 };
 
+#if __cpp_impl_three_way_comparison < 201907L
   /**
* @brief Compares two %independent_bits_engine random number generator
* objects of the same type for inequality.
@@ -1303,6 +1308,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   const std::independent_bits_engine<_RandomNumberEngine, __w,
   _UIntType>& __rhs)
 { return !(__lhs == __rhs); }
+#endif
 
   /**
* @brief Inserts the current state of a %independent_bits_engine random
@@ -1541,6 +1547,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   result_type _M_y;
 };
 
+#if __cpp_impl_three_way_comparison < 201907L
   /**
* Compares two %shuffle_order_engine random number generator objects
* of the same type for inequality.
@@ -1559,7 +1566,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
   const std::shuffle_order_engine<_RandomNumberEngine,
   __k>& __rhs)
 { return !(__lhs == __rhs); }
-
+#endif
 
   /**
* The classic Minimum Standard rand0 of Lewis, Goodman, and Miller.
@@ -1703,6 +1710,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 
   // std::uniform_int_distribution is defined in 
 
+#if __cpp_impl_three_way_comparison < 201907L
   /**
* @brief Return true if two uniform integer distributions have
*different parameters.
@@ -1712,6 +1720,7 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
 operator!=(const std::uniform_int_distribution<_IntType>& __d1,
   const std::uniform_int_distribution<_IntType>& __d2)
 { return !(__d1 == __d2); }
+#endif
 
   /**
* @brief Inserts a %uniform_int_distribution random number
@@ -1786,9 +1795,11 @@ _GLIBCXX_BEGIN_NAMESPACE_VERSION
operator==(const param_type& __p1, const param_type& __p2)
{ return __p1._M_a == __p2._M_a && __p1._M_b 

[committed] libstdc++: Add always_inline to trivial iterator operations

[Jonathan Wakely via Gcc-patches]

Tested x86_64-linux. Pushed to trunk.

-- >8 --

libstdc++-v3/ChangeLog:

* include/bits/stl_iterator_base_funcs.h (__distance):
Add always_inline attribute to overload for random
access iterators.
(advance, distance, next, prev): Add always_inline attribute to
inline functions that just forward to another function.
---
 libstdc++-v3/include/bits/stl_iterator_base_funcs.h | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/libstdc++-v3/include/bits/stl_iterator_base_funcs.h 
b/libstdc++-v3/include/bits/stl_iterator_base_funcs.h
index 1551b226ff4..25dddb3e7e8 100644
--- a/libstdc++-v3/include/bits/stl_iterator_base_funcs.h
+++ b/libstdc++-v3/include/bits/stl_iterator_base_funcs.h
@@ -94,6 +94,7 @@ _GLIBCXX_END_NAMESPACE_CONTAINER
 }
 
   template
+__attribute__((__always_inline__))
 inline _GLIBCXX14_CONSTEXPR
 typename iterator_traits<_RandomAccessIterator>::difference_type
 __distance(_RandomAccessIterator __first, _RandomAccessIterator __last,
@@ -141,7 +142,7 @@ _GLIBCXX_END_NAMESPACE_CONTAINER
*  and are constant time.  For other %iterator classes they are linear time.
   */
   template
-_GLIBCXX_NODISCARD
+_GLIBCXX_NODISCARD __attribute__((__always_inline__))
 inline _GLIBCXX17_CONSTEXPR
 typename iterator_traits<_InputIterator>::difference_type
 distance(_InputIterator __first, _InputIterator __last)
@@ -214,6 +215,7 @@ _GLIBCXX_END_NAMESPACE_CONTAINER
*  and are constant time.  For other %iterator classes they are linear time.
   */
   template
+__attribute__((__always_inline__))
 inline _GLIBCXX17_CONSTEXPR void
 advance(_InputIterator& __i, _Distance __n)
 {
@@ -225,7 +227,7 @@ _GLIBCXX_END_NAMESPACE_CONTAINER
 #if __cplusplus >= 201103L
 
   template
-_GLIBCXX_NODISCARD
+_GLIBCXX_NODISCARD [[__gnu__::__always_inline__]]
 inline _GLIBCXX17_CONSTEXPR _InputIterator
 next(_InputIterator __x, typename
 iterator_traits<_InputIterator>::difference_type __n = 1)
@@ -237,7 +239,7 @@ _GLIBCXX_END_NAMESPACE_CONTAINER
 }
 
   template
-_GLIBCXX_NODISCARD
+_GLIBCXX_NODISCARD [[__gnu__::__always_inline__]]
 inline _GLIBCXX17_CONSTEXPR _BidirectionalIterator
 prev(_BidirectionalIterator __x, typename
 iterator_traits<_BidirectionalIterator>::difference_type __n = 1) 
-- 
2.38.1

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

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r13-4306-gf54ceb2062c7fef294f85ae093914fa6c7ca35b8
Author: Jonathan Wakely 
Date:   Thu Nov 24 21:09:03 2022 +

libstdc++: Call predicate with non-const values in std::erase_if [PR107850]

As specified in the standard, the predicate for std::erase_if has to be
invocable as non-const with a non-const lvalues argument. Restore
support for predicates that only accept non-const arguments.

It's not strictly nevessary to change it for the set and unordered_set
overloads, because they only give const access to the elements anyway.
I've done it for them too just to keep them all consistent.

libstdc++-v3/ChangeLog:

PR libstdc++/107850
* include/bits/erase_if.h (__erase_nodes_if): Use non-const
reference to the container.
* include/experimental/map (erase_if): Likewise.
* include/experimental/set (erase_if): Likewise.
* include/experimental/unordered_map (erase_if): Likewise.
* include/experimental/unordered_set (erase_if): Likewise.
* include/std/map (erase_if): Likewise.
* include/std/set (erase_if): Likewise.
* include/std/unordered_map (erase_if): Likewise.
* include/std/unordered_set (erase_if): Likewise.
* testsuite/23_containers/map/erasure.cc: Check with
const-incorrect predicate.
* testsuite/23_containers/set/erasure.cc: Likewise.
* testsuite/23_containers/unordered_map/erasure.cc: Likewise.
* testsuite/23_containers/unordered_set/erasure.cc: Likewise.
* testsuite/experimental/map/erasure.cc: Likewise.
* testsuite/experimental/set/erasure.cc: Likewise.
* testsuite/experimental/unordered_map/erasure.cc: Likewise.
* testsuite/experimental/unordered_set/erasure.cc: Likewise.

Re: Configuring GCC 10.3 on PPC Mac OS X 10.4.11/Tiger for build reveals problems when removing relics

[Iain Sandoe]

Hi Pete,

> On 25 Nov 2022, at 10:36, Peter Dyballa via Gcc  wrote:

> On Mac OS X/macOS configure scripts leave conftest.dSYM subdirectories 
> behind, created by dsymutil:
> 
>   checking for build system preprocessor... rm: conftest.dSYM: is a 
> directory
>   checking for build system executable suffix... rm: conftest.dSYM: is a 
> directory
>   checking whether build system compiler is ANSI... rm: conftest.dSYM: is 
> a directory
>   checking for build system compiler math library... rm: conftest.dSYM: 
> is a directory
> 
> Building GCC 10.3 with MacPorts the configure scripts produce 178 such 
> reports (and more than 11,000 checking lines without complaint). (The 
> relation is worse when building smaller software packages.)

I agree it’s an irritation (although not a show-stopper, so other things are 
higher priority right now on my list).

> Is it possible to replace the simple "rm" with "rm -r", at least on darwin, 
> the macOS/Mac OS X? Or create a special macro to be used when dsymutil gets 
> involved?

It is likely to be possible, where the configure tests can be modified in the 
GCC sources.

The best course of action is to take them one by one and see where the 
configure source comes from, go to that source and modify the rm (hopefully, 
conditionally on *-*-darwin*) to deal with this.  If the source of the problems 
is primarily libtool.m4 … then we do make local modifications, but now that 
(libtool) is maintained again we should look into how much we can sync with 
upstream.

I’m happy to review patches (if they are macOS/darwin-specific, then I can even 
approve them).

Iain

> 
> --
> 
> Greetings
> 
>  Pete
> 
> Every instructor assumes that you have nothing else to do except study for 
> that instructor's course. 
>   – Fourth Law of Applied Terror
> 

Re: [PATCH V2] rs6000: Support to build constants by li/lis+oris/xoris

[Segher Boessenkool]

Hi guys,

On Fri, Nov 25, 2022 at 04:11:49PM +0800, Kewen.Lin wrote:
> on 2022/10/26 19:40, Jiufu Guo wrote:
> for "li/lis + oris/xoris", I interpreted it into four combinations:
> 
>li + oris, lis + oris, li + xoris, lis + xoris.
> 
> not sure just me interpreting like that, but the actual combinations
> which this patch adopts are:
> 
>li + oris, li + xoris, lis + xoris.
> 
> It's a bit off, but not a big deal, up to you to reword it or not.  :)

The first two are obvious, but the last one is almost never a good idea,
there usually are better ways to do the same.  I cannot even think of
any case where this is best?  A lis;rl* is always prefered (it can
optimise better, be combined with other insns).

> > +  HOST_WIDE_INT orig_c = c;

If you ever feel you need a variable to hold an "orig" value, that is a
good hint that you should restructure the code a bit, perhaps even
factor it.  That often is overdue (like here), not caused by you, but
you could help solve it ;-)

(This is what made this patch hard to review, btw).

> > gen_rtx_IOR (DImode, copy_rtx (temp),
> >  GEN_INT (ud1)));
> >  }
> > +  else if ((ud4 == 0x && ud3 == 0x)
> > +  && ((ud1 & 0x8000) || (ud1 == 0 && !(ud2 & 0x8000
> > +{
> > +  temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode);
> > +
> > +  HOST_WIDE_INT imm = (ud1 & 0x8000) ? ((ud1 ^ 0x8000) - 0x8000)
> > +: ((ud2 << 16) - 0x8000);

We really should have some "hwi::sign_extend (ud1, 16)" helper function,
heh.  Maybe there already is?  Ah, "sext_hwi".  Fixing that up
everywhere in this function is preapproved.

> > +  else
> > +   {
> > + emit_move_insn (temp,
> > + GEN_INT (((ud2 << 16) ^ 0x8000) - 0x8000));
> > + if (ud1 != 0)
> > +   emit_move_insn (temp, gen_rtx_IOR (DImode, temp, GEN_INT (ud1)));
> > + emit_move_insn (dest,
> > + gen_rtx_ZERO_EXTEND (DImode,
> > +  gen_lowpart (SImode, temp)));
> > +   }

Why this?  Please just write it in DImode, do not go via SImode?

> > --- /dev/null
> > +++ b/gcc/testsuite/gcc.target/powerpc/pr106708.h
> > @@ -0,0 +1,9 @@
> > +/* Test constants which can be built by li/lis + oris/xoris */
> > +void  __attribute__ ((__noinline__, __noclone__)) foo (long long *arg)
> > +{
> > +  *arg++ = 0x98765432ULL;
> > +  *arg++ = 0x7cdeab55ULL;
> > +  *arg++ = 0x6543ULL;
> > +}

Use noipa please (it is shorter, simpler, and covers more :-) )

Could you comment what exact instructions are expected?
li;xoris and li;xoris and lis;xoris I guess?  It helps if you just tell
the reader here.

The li;oris and li;xoris parts look good.


Segher

[PATCH] sync libsframe toplevel from binutils-gdb

[Richard Earnshaw via Gcc-patches]

This pulls in the toplevel portion of this binutils-gdb commit:
   19e559f1c91bfaedbd2f91d85ee161f3f03fda3c libsframe: add the SFrame library

ChangeLog:
* Makefile.def: Add libsframe as new module with its dependencies.
* Makefile.in: Regenerated.
* configure.ac: Add libsframe to host_libs.
* configure: Regenerated.
---
 Makefile.def |2 +
 Makefile.in  | 1288 +-
 configure|2 +-
 configure.ac |2 +-
 4 files changed, 1287 insertions(+), 7 deletions(-)

diff --git a/Makefile.def b/Makefile.def
index 02e63c57177..83ae77586ad 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -145,6 +145,7 @@ host_modules= { module= lto-plugin; bootstrap=true;
 host_modules= { module= libcc1; extra_configure_flags=--enable-shared; };
 host_modules= { module= gotools; };
 host_modules= { module= libctf; bootstrap=true; };
+host_modules= { module= libsframe; bootstrap=true; };
 
 target_modules = { module= libstdc++-v3;
 		   bootstrap=true;
@@ -470,6 +471,7 @@ dependencies = { module=all-binutils; on=all-intl; };
 dependencies = { module=all-binutils; on=all-gas; };
 dependencies = { module=all-binutils; on=all-libctf; };
 dependencies = { module=all-ld; on=all-libctf; };
+dependencies = { module=all-binutils; on=all-libsframe; };
 
 // We put install-opcodes before install-binutils because the installed
 // binutils might be on PATH, and they might need the shared opcodes
diff --git a/Makefile.in b/Makefile.in
index 6ffa9660c25..e5bed1bea3a 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -1097,7 +1097,8 @@ configure-host:  \
 maybe-configure-lto-plugin \
 maybe-configure-libcc1 \
 maybe-configure-gotools \
-maybe-configure-libctf
+maybe-configure-libctf \
+maybe-configure-libsframe
 .PHONY: configure-target
 configure-target:  \
 maybe-configure-target-libstdc++-v3 \
@@ -1273,6 +1274,9 @@ all-host: maybe-all-gotools
 @if libctf-no-bootstrap
 all-host: maybe-all-libctf
 @endif libctf-no-bootstrap
+@if libsframe-no-bootstrap
+all-host: maybe-all-libsframe
+@endif libsframe-no-bootstrap
 
 .PHONY: all-target
 
@@ -1384,6 +1388,7 @@ info-host: maybe-info-lto-plugin
 info-host: maybe-info-libcc1
 info-host: maybe-info-gotools
 info-host: maybe-info-libctf
+info-host: maybe-info-libsframe
 
 .PHONY: info-target
 
@@ -1472,6 +1477,7 @@ dvi-host: maybe-dvi-lto-plugin
 dvi-host: maybe-dvi-libcc1
 dvi-host: maybe-dvi-gotools
 dvi-host: maybe-dvi-libctf
+dvi-host: maybe-dvi-libsframe
 
 .PHONY: dvi-target
 
@@ -1560,6 +1566,7 @@ pdf-host: maybe-pdf-lto-plugin
 pdf-host: maybe-pdf-libcc1
 pdf-host: maybe-pdf-gotools
 pdf-host: maybe-pdf-libctf
+pdf-host: maybe-pdf-libsframe
 
 .PHONY: pdf-target
 
@@ -1648,6 +1655,7 @@ html-host: maybe-html-lto-plugin
 html-host: maybe-html-libcc1
 html-host: maybe-html-gotools
 html-host: maybe-html-libctf
+html-host: maybe-html-libsframe
 
 .PHONY: html-target
 
@@ -1736,6 +1744,7 @@ TAGS-host: maybe-TAGS-lto-plugin
 TAGS-host: maybe-TAGS-libcc1
 TAGS-host: maybe-TAGS-gotools
 TAGS-host: maybe-TAGS-libctf
+TAGS-host: maybe-TAGS-libsframe
 
 .PHONY: TAGS-target
 
@@ -1824,6 +1833,7 @@ install-info-host: maybe-install-info-lto-plugin
 install-info-host: maybe-install-info-libcc1
 install-info-host: maybe-install-info-gotools
 install-info-host: maybe-install-info-libctf
+install-info-host: maybe-install-info-libsframe
 
 .PHONY: install-info-target
 
@@ -1912,6 +1922,7 @@ install-dvi-host: maybe-install-dvi-lto-plugin
 install-dvi-host: maybe-install-dvi-libcc1
 install-dvi-host: maybe-install-dvi-gotools
 install-dvi-host: maybe-install-dvi-libctf
+install-dvi-host: maybe-install-dvi-libsframe
 
 .PHONY: install-dvi-target
 
@@ -2000,6 +2011,7 @@ install-pdf-host: maybe-install-pdf-lto-plugin
 install-pdf-host: maybe-install-pdf-libcc1
 install-pdf-host: maybe-install-pdf-gotools
 install-pdf-host: maybe-install-pdf-libctf
+install-pdf-host: maybe-install-pdf-libsframe
 
 .PHONY: install-pdf-target
 
@@ -2088,6 +2100,7 @@ install-html-host: maybe-install-html-lto-plugin
 install-html-host: maybe-install-html-libcc1
 install-html-host: maybe-install-html-gotools
 install-html-host: maybe-install-html-libctf
+install-html-host: maybe-install-html-libsframe
 
 .PHONY: install-html-target
 
@@ -2176,6 +2189,7 @@ installcheck-host: maybe-installcheck-lto-plugin
 installcheck-host: maybe-installcheck-libcc1
 installcheck-host: maybe-installcheck-gotools
 installcheck-host: maybe-installcheck-libctf
+installcheck-host: maybe-installcheck-libsframe
 
 .PHONY: installcheck-target
 
@@ -2264,6 +2278,7 @@ mostlyclean-host: maybe-mostlyclean-lto-plugin
 mostlyclean-host: maybe-mostlyclean-libcc1
 mostlyclean-host: maybe-mostlyclean-gotools
 mostlyclean-host: maybe-mostlyclean-libctf
+mostlyclean-host: maybe-mostlyclean-libsframe
 
 .PHONY: mostlyclean-target
 
@@ -2352,6 +2367,7 @@ clean-host: maybe-clean-lto-plugin
 clean-host: maybe-clean-libcc1
 clean-host: maybe-clean-gotools
 clean-host: 

Fix resolution streaming with incremental linking

[Jan Hubicka via Gcc-patches]

Hi,
this patch fixes streaming of resolution info when flag_incremental_link
== INCREMENTAL_LINK_NOLTO.  Here we want to stream the info from WPA to
ltrans as usual.

Bootstrapped/regtested x86_64-linux, tested with kernel LTO builds.
Plan to commit it later today.

Honza

* gcc/lto-cgraph.cc (lto_output_node): Only drop resolution info when
flag_incremental_link === INCREMENTAL_LINK_LTO.
diff --git a/gcc/lto-cgraph.cc b/gcc/lto-cgraph.cc
index 350195d86db..ff7669d0c4b 100644
--- a/gcc/lto-cgraph.cc
+++ b/gcc/lto-cgraph.cc
@@ -563,7 +563,7 @@ lto_output_node (struct lto_simple_output_block *ob, struct 
cgraph_node *node,
LDPR_NUM_KNOWN,
/* When doing incremental link, we will get new resolution
   info next time we process the file.  */
-   flag_incremental_link ? LDPR_UNKNOWN : node->resolution);
+   flag_incremental_link == INCREMENTAL_LINK_LTO ? LDPR_UNKNOWN : 
node->resolution);
   bp_pack_value (, node->split_part, 1);
   streamer_write_bitpack ();
   streamer_write_data_stream (ob->main_stream, section, strlen (section) + 1);

[Bug target/107860] Compilation failure, ambiguous fisttp

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

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

--- Comment #7 from Andrew Pinski  ---
The same issue you would run into even on Linux with qemu and gnu as (though
gcc does not add the right target options to as as it assumes you have one that
targets your target by default.

[PING][PATCH] RISC-V: Avoid redundant sign-extension for SImode SGE, SGEU, SLE, SLEU

[Maciej W. Rozycki]

Hi Kito,

On Fri, 12 Aug 2022, Maciej W. Rozycki wrote:

> > LGTM, but with a nit, I don't get set.w but get an andi like below, so
> > maybe we should also scan-assembler-not andi? feel free to commit that
> > directly with that fix
> > 
> > ```asm
> > sleu:
> >sgtua0,a0,a1# 9 [c=4 l=4]  *sgtu_disi
> >xoria0,a0,1 # 10[c=4 l=4]  *xorsi3_internal/1
> >andia0,a0,1 # 16[c=4 l=4]  anddi3/1
> >ret # 25[c=0 l=4]  simple_return
> > ```
> 
>  Interesting.  I can do that, but can you please share the compilation 
> options, given or defaulted (from `--with...' configuration options), this 
> happens with?

 I have noticed it went nowhere.  Can you please check what compilation 
options lead to this discrepancy so that we can have the fix included in 
GCC 13?  I'd like to understand what's going on here.

  Maciej

[Bug target/107860] Compilation failure, ambiguous fisttp

[simon at pushface dot org via Gcc-bugs]

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

--- Comment #6 from simon at pushface dot org ---
The situation with aarch64-apple-darwin vs x86_64-apple-darwin isn't I think
quite like the standard cross-compilation scenario, because of Apple's Rosetta
x86_64 emulation and the fact that all the low-level tools (as, ld, ...)
support both architectures.

If I take an x86_64-apple-darwin compiler and run it on aarch64-apple-darwin it
will generate x86_64 assembler and invoke as, ld with the right switches to
create x86_84 binaries and executables; the executables will run on aarch64
under Rosetta or on x86_64 natively.

So I'm not sure what --build, --host should have been set to (given I don't
want a cross-compiler; the cross- facilities are provided by macOS under the
hood).

In what I was trying to do, the host machine was aarch64-apple-darwin22, but
notably aarch64 running Rosetta. The boot compiler was x86_64-apple-darwin21.

Anyway, the issue here was the way that configure invoked the assembler;
/usr/bin/as will assume it's targeting aarch64 (aka arm64) unless told
different.

These are the results of compiling the test case:

   $ cat conftest-filds-fists.s
   // $gcc_cv_as $gcc_cv_as_flags  -o conftest.o conftest.s
   filds (%ebp)
   fists (%ebp)

with /usr/bin/as -c -b conftest-filds-fists.s -o conftest-filds-fists.o

(a) on x86_64

Apple clang version 14.0.0 (clang-1400.0.29.201)
Target: x86_64-apple-darwin21.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
 "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1as -triple
x86_64-apple-macosx12.0.0 -filetype obj -main-file-name conftest-filds-fists.s
-target-cpu penryn -fdebug-compilation-dir=/Users/simon/tmp
-dwarf-debug-producer "Apple clang version 14.0.0 (clang-1400.0.29.201)"
-dwarf-version=4 -mrelocation-model pic --mrelax-relocations -mllvm
-disable-aligned-alloc-awareness=1 -o conftest-filds-fists.o
conftest-filds-fists.s

(b) on aarch64

$ /usr/bin/as -c -v conftest-filds-fists.s -o conftest-filds-fists.o
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: arm64-apple-darwin22.1.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
 "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1as -triple
arm64-apple-macosx13.0.0 -filetype obj -main-file-name conftest-filds-fists.s
-target-cpu apple-m1 -target-feature +v8.5a -target-feature +fp-armv8
-target-feature +neon -target-feature +crc -target-feature +crypto
-target-feature +dotprod -target-feature +fp16fml -target-feature +ras
-target-feature +lse -target-feature +rdm -target-feature +rcpc -target-feature
+zcm -target-feature +zcz -target-feature +fullfp16 -target-feature +sm4
-target-feature +sha3 -target-feature +sha2 -target-feature +aes
-fdebug-compilation-dir=/Volumes/Miscellaneous1/x86_64/gcc-13-20221120/gcc
-dwarf-debug-producer "Apple clang version 14.0.0 (clang-1400.0.29.202)"
-dwarf-version=4 -mrelocation-model pic --mrelax-relocations -mllvm
-disable-aligned-alloc-awareness=1 -o conftest-filds-fists.o
conftest-filds-fists.s
conftest-filds-fists.s:2:16: error: unknown token in expression
filds (%ebp)
   ^
conftest-filds-fists.s:2:15: error: invalid operand
filds (%ebp)
  ^
conftest-filds-fists.s:3:16: error: unknown token in expression
fists (%ebp)
   ^
conftest-filds-fists.s:3:15: error: invalid operand
fists (%ebp)
  ^
(c) on aarch64, with -arch x86_64

$ /usr/bin/as -c -v conftest-filds-fists.s -o conftest-filds-fists.o -arch
x86_64
Apple clang version 14.0.0 (clang-1400.0.29.202)
Target: x86_64-apple-darwin22.1.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
 "/Library/Developer/CommandLineTools/usr/bin/clang" -cc1as -triple
x86_64-apple-macosx13.0.0 -filetype obj -main-file-name conftest-filds-fists.s
-target-cpu penryn
-fdebug-compilation-dir=/Volumes/Miscellaneous1/x86_64/gcc-13-20221120/gcc
-dwarf-debug-producer "Apple clang version 14.0.0 (clang-1400.0.29.202)"
-dwarf-version=4 -mrelocation-model pic --mrelax-relocations -mllvm
-disable-aligned-alloc-awareness=1 -o conftest-filds-fists.o
conftest-filds-fists.s



I think the solution to this PR might be to set it as INVALID or WONTFIX? up to
you.

Re: Please, really, make `-masm=intel` the default for x86

[David Brown]

On 25/11/2022 07:39, LIU Hao via Gcc wrote:
I am a Windows developer and I have been writing x86 and amd64 assembly 
for more than ten years. One annoying thing about GCC is that, for x86 
if I need to write I piece of inline assembly then I have to do it 
twice: one in AT syntax and one in Intel syntax.



The AT syntax is an awkward foreign dialect, designed originally for 
PDP-11 and spoken by bumpkins that knew little about x86 or ARM. No 
official Intel or AMD documentation ever adopts it. The syntax is 
terrible. Consider:


    movl $1, %eax  ; k; moves $1 into EAX
   ; but in high-level languages we expect '%eax = $1',
   ; so it goes awkwardly backwards.

If this looks fine to you, please re-consider:

   cmpl $1, %eax
   jg .L1  ; does this mean 'jump if $1 is greater than %eax'
   ; or something stupidly reversed?

If CMP still looks fine to you, please consider how to write VFMADD231PD 
in AT syntax, really.



I have been tired of such inconsistency. For God's sake, please 
deprecate it.





You can have all the personal preferences or prejudices you want, but 
that won't change the fact that AT syntax was the standard x86 
assembly from long before Intel thought of making their own syntax, and 
it is here to stay.  No one is going to deprecate it, remove it, or 
change any defaults.



#include 

int main(void)
{
int temp=0;

asm
(   ".intel_syntax noprefix"
"mov %0, 1"
".att_syntax"
: "=r"(temp)
:   /* no input*/
);
printf("temp=%d\n", temp);
}


A use feature that could be added to gcc, perhaps, would be a way to let 
the user specify the assembler dialect as part of the "asm" statement:


asm __attribute__((masm = "intel")) ( ... )

The idea with this is that it would issue the requested ".intel_syntax 
noprefix" or ".att_syntax" at the start of the assembly, and the 
appropriate directive to return to normal syntax at the end - adjusting 
according to the "-masm" setting for the compilation.  This would, I 
think, let people write the assembly once in the syntax they choose, and 
have it work smoothly regardless of which syntax is chosen for compilation.

Re: [PATCH]rs6000: Load high and low part of 64bit constant independently

[Jiufu Guo via Gcc-patches]

Jiufu Guo via Gcc-patches  writes:

> Hi Kewen,
>
> Thanks for your review on this patch!
>
> "Kewen.Lin"  writes:
>
>> Hi Jeff,
>>
>> Sorry for the late review.
>>
>> on 2022/9/15 16:30, Jiufu Guo wrote:
>>> Hi,
>>> 
>>> For a complicate 64bit constant, blow is one instruction-sequence to
>>> build:
>>> lis 9,0x800a
>>> ori 9,9,0xabcd
>>> sldi 9,9,32
>>> oris 9,9,0xc167
>>> ori 9,9,0xfa16
>>> 
>>> while we can also use below sequence to build:
>>> lis 9,0xc167
>>> lis 10,0x800a
>>> ori 9,9,0xfa16
>>> ori 10,10,0xabcd
>>> rldimi 9,10,32,0
>>> This sequence is using 2 registers to build high and low part firstly,
>>> and then merge them.
>>> In parallel aspect, this sequence would be faster. (Ofcause, using 1 more
>>> register with potential register pressure).
>>> 
>>> Bootstrap and regtest pass on ppc64le.
>>> Is this ok for trunk?
>>> 
>>> 
>>> BR,
>>> Jeff(Jiufu)
>>> 
>>> 
>>> gcc/ChangeLog:
>>> 
>>> * config/rs6000/rs6000.cc (rs6000_emit_set_long_const): Update 64bit
>>> constant build.
>>> 
>>> gcc/testsuite/ChangeLog:
>>> 
>>> * gcc.target/powerpc/parall_5insn_const.c: New test.
>>> 
>>> ---
cut...
> @@ -0,1 +1,27 @@
> +/* { dg-do run } */
> +/* { dg-options "-O2 -mdejagnu-cpu=power8  -save-temps" } */
maybe, I could use power7.  Any comments?
> +/* { dg-require-effective-target has_arch_ppc64 } */
> +
> +/* { dg-final { scan-assembler-times {\mlis\M} 4 } } */
> +/* { dg-final { scan-assembler-times {\mori\M} 4 } } */
> +/* { dg-final { scan-assembler-times {\mrldimi\M} 2 } } */
> +
> +void __attribute__ ((noinline)) foo (unsigned long long *a)
> +{
> +  /* 2 lis + 2 ori + 1 rldimi for each constant.  */
> +  *a++ = 0x800aabcdc167fa16ULL;
> +  *a++ = 0x7543a876867f616ULL;
> +}
> +
> +long long A[] = {0x800aabcdc167fa16ULL, 0x7543a876867f616ULL};
> +int
> +main ()
> +{
> +  long long res[2];
> +
> +  foo (res);
> +  if (__builtin_memcmp (res, A, sizeof (res)) != 0)
> +__builtin_abort ();
> +
> +  return 0;
> +}

Re: [PATCH] tree-optimization/107672 - avoid vector mode type_for_mode call

[Vaseeharan Vinayagamoorthy via Gcc-patches]

Hi,


I am seeing an internal compiler error, related to this patch:



during GIMPLE pass: slp

options-save.cc: In function 'void cl_optimization_restore(gcc_options*, 
gcc_options*, cl_optimization*)':

options-save.cc:1292:1: internal compiler error: in 
supportable_widening_operation, at tree-vect-stmts.cc:12199


 1292 | cl_optimization_restore (struct gcc_options *opts, struct gcc_options 
*opts_set,

 | ^~~

/…/src/gcc/gcc/profile-count.cc: In member function 'int 
profile_count::to_cgraph_frequency(profile_count) const':

/…/src/gcc/gcc/profile-count.cc:308:1: note: parameter passing for argument of 
type 'profile_count' changed in GCC 9.1

 308 | profile_count::to_cgraph_frequency (profile_count entry_bb_count) const

 | ^

/…/src/gcc/gcc/profile-count.cc: In member function 'sreal 
profile_count::to_sreal_scale(profile_count, bool*) const':

/…/src/gcc/gcc/profile-count.cc:326:1: note: parameter passing for argument of 
type 'profile_count' changed in GCC 9.1

 326 | profile_count::to_sreal_scale (profile_count in, bool *known) const

 | ^

0x2195bdd supportable_widening_operation(vec_info*, tree_code, _stmt_vec_info*, 
tree_node*, tree_node*, tree_code*, tree_code*, int*, vec*)

 /…/src/gcc/gcc/tree-vect-stmts.cc:12199

0x2180493 vectorizable_conversion

 /…/src/gcc/gcc/tree-vect-stmts.cc:5064

0x2192fdd vect_analyze_stmt(vec_info*, _stmt_vec_info*, bool*, _slp_tree*, 
_slp_instance*, vec*)

 /…/src/gcc/gcc/tree-vect-stmts.cc:11256


/…/src/gcc/gcc/profile-count.cc: In member function 'profile_count 
profile_count::combine_with_ipa_count(profile_count)':

/…/src/gcc/gcc/profile-count.cc:398:1: note: parameter passing for argument of 
type 'profile_count' changed in GCC 9.1

 398 | profile_count::combine_with_ipa_count (profile_count ipa)

 | ^

0x14f95d1 vect_slp_analyze_node_operations_1

 /…/src/gcc/gcc/tree-vect-slp.cc:5958

0x14f9c19 vect_slp_analyze_node_operations

 /…/src/gcc/gcc/tree-vect-slp.cc:6147

0x14f9b4d vect_slp_analyze_node_operations

 /…/src/gcc/gcc/tree-vect-slp.cc:6126

0x14fa439 vect_slp_analyze_operations(vec_info*)

 /…/src/gcc/gcc/tree-vect-slp.cc:6387

0x14fd423 vect_slp_analyze_bb_1

 /…/src/gcc/gcc/tree-vect-slp.cc:7372

0x14fd599 vect_slp_region

 /…/src/gcc/gcc/tree-vect-slp.cc:7419

0x14fe0d1 vect_slp_bbs

 /…/src/gcc/gcc/tree-vect-slp.cc:7610

0x14fe46f vect_slp_function(function*)

 /…/src/gcc/gcc/tree-vect-slp.cc:7698

0x151a109 execute

 /…/src/gcc/gcc/tree-vectorizer.cc:1532

Please submit a full bug report, with preprocessed source (by using 
-freport-bug).

Please include the complete backtrace with any bug report.

See  for instructions.

Makefile:1146: recipe for target 'options-save.o' failed

make[3]: *** [options-save.o] Error 1


That happens when building the arm-none-linux-gnueabihf toolchain natively with 
glibc bootstrap:
Build:arm-none-linux-gnueabihf
Host:arm-none-linux-gnueabihf
Target: arm-none-linux-gnueabihf

The compiler being used to build the toolchain is gcc 7.5.0.


Kind regards
Vasee

From: Gcc-patches  on behalf 
of Richard Biener via Gcc-patches 
Sent: 22 November 2022 08:48
To: gcc-patches@gcc.gnu.org 
Subject: [PATCH] tree-optimization/107672 - avoid vector mode type_for_mode call

The following avoids using type_for_mode on vector modes which might
not work for all frontends.  Instead we look for the inner mode
type and use build_vector_type_for_mode instead.

Bootstrapped and tested on x86_64-unknown-linux-gnu, pushed.

PR tree-optimization/107672
* tree-vect-stmts.cc (supportable_widening_operation): Avoid
type_for_mode on vector modes.
---
 gcc/tree-vect-stmts.cc | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/gcc/tree-vect-stmts.cc b/gcc/tree-vect-stmts.cc
index bc0ef136f19..b35b986889d 100644
--- a/gcc/tree-vect-stmts.cc
+++ b/gcc/tree-vect-stmts.cc
@@ -12195,9 +12195,15 @@ supportable_widening_operation (vec_info *vinfo,
 intermediate_type
   = vect_halve_mask_nunits (prev_type, intermediate_mode);
   else
-   intermediate_type
- = lang_hooks.types.type_for_mode (intermediate_mode,
-   TYPE_UNSIGNED (prev_type));
+   {
+ gcc_assert (VECTOR_MODE_P (intermediate_mode));
+ tree intermediate_element_type
+   = lang_hooks.types.type_for_mode (GET_MODE_INNER 
(intermediate_mode),
+ TYPE_UNSIGNED (prev_type));
+ intermediate_type
+   = build_vector_type_for_mode (intermediate_element_type,
+ intermediate_mode);
+   }

   if (VECTOR_BOOLEAN_TYPE_P (intermediate_type)
   && VECTOR_BOOLEAN_TYPE_P (prev_type)
--
2.35.3

Re: [PATCH v2 06/11] OpenMP: lvalue parsing for map clauses (C++)

[Jakub Jelinek via Gcc-patches]

On Tue, Nov 08, 2022 at 02:36:17PM +, Julian Brown wrote:
> @@ -3258,6 +3273,7 @@ c_omp_address_inspector::get_origin (tree t)
>  || TREE_CODE (t) == SAVE_EXPR)
>   t = TREE_OPERAND (t, 0);
>else if (TREE_CODE (t) == INDIRECT_REF
> +&& TREE_TYPE (TREE_OPERAND (t, 0))
>  && TREE_CODE (TREE_TYPE (TREE_OPERAND (t, 0))) == REFERENCE_TYPE)
>   t = TREE_OPERAND (t, 0);
>else
> @@ -3274,7 +3290,9 @@ c_omp_address_inspector::get_origin (tree t)
>  tree
>  c_omp_address_inspector::maybe_unconvert_ref (tree t)
>  {
> +  /* The TREE_TYPE can be null if we had an earlier error.  */
>if (TREE_CODE (t) == INDIRECT_REF
> +  && TREE_TYPE (TREE_OPERAND (t, 0))
>&& TREE_CODE (TREE_TYPE (TREE_OPERAND (t, 0))) == REFERENCE_TYPE)
>  return TREE_OPERAND (t, 0);
>  

I'd prefer avoiding changes like the above.
If we had an earlier error, it should be error_mark_node or have
error_mark_node type, not NULL.
NULL type means something different in the C++ FE, in particular that
something is type dependent and the type will be only figured out after
instantiation.

Other than that LGTM.

Jakub

Re: [PATCH]rs6000: Load high and low part of 64bit constant independently

[Jiufu Guo via Gcc-patches]

Hi Kewen,

Thanks for your review on this patch!

"Kewen.Lin"  writes:

> Hi Jeff,
>
> Sorry for the late review.
>
> on 2022/9/15 16:30, Jiufu Guo wrote:
>> Hi,
>> 
>> For a complicate 64bit constant, blow is one instruction-sequence to
>> build:
>>  lis 9,0x800a
>>  ori 9,9,0xabcd
>>  sldi 9,9,32
>>  oris 9,9,0xc167
>>  ori 9,9,0xfa16
>> 
>> while we can also use below sequence to build:
>>  lis 9,0xc167
>>  lis 10,0x800a
>>  ori 9,9,0xfa16
>>  ori 10,10,0xabcd
>>  rldimi 9,10,32,0
>> This sequence is using 2 registers to build high and low part firstly,
>> and then merge them.
>> In parallel aspect, this sequence would be faster. (Ofcause, using 1 more
>> register with potential register pressure).
>> 
>> Bootstrap and regtest pass on ppc64le.
>> Is this ok for trunk?
>> 
>> 
>> BR,
>> Jeff(Jiufu)
>> 
>> 
>> gcc/ChangeLog:
>> 
>>  * config/rs6000/rs6000.cc (rs6000_emit_set_long_const): Update 64bit
>>  constant build.
>> 
>> gcc/testsuite/ChangeLog:
>> 
>>  * gcc.target/powerpc/parall_5insn_const.c: New test.
>> 
>> ---
>>  gcc/config/rs6000/rs6000.cc   | 45 +++
>>  .../gcc.target/powerpc/parall_5insn_const.c   | 27 +++
>>  2 files changed, 53 insertions(+), 19 deletions(-)
>>  create mode 100644 gcc/testsuite/gcc.target/powerpc/parall_5insn_const.c
>> 
>> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
>> index a656cb32a47..759c6309677 100644
>> --- a/gcc/config/rs6000/rs6000.cc
>> +++ b/gcc/config/rs6000/rs6000.cc
>> @@ -10180,26 +10180,33 @@ rs6000_emit_set_long_const (rtx dest, 
>> HOST_WIDE_INT c)
>>  }
>>else
>>  {
>> -  temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode);
>> -
>> -  emit_move_insn (copy_rtx (temp),
>> -  GEN_INT (((ud4 << 16) ^ 0x8000) - 0x8000));
>> -  if (ud3 != 0)
>> -emit_move_insn (copy_rtx (temp),
>> -gen_rtx_IOR (DImode, copy_rtx (temp),
>> - GEN_INT (ud3)));
>> +  if (can_create_pseudo_p ())
>> +{
>> +  /* lis A,U4; ori A,U3; lis B,U2; ori B,U1; rldimi A,B,32,0.  */
>
> Nit: A, B are supposed to be H, L?
Yes, thanks for this catch! It should be
/* lis H,U4; ori H,U3; lis L,U2; ori L,U1; rldimi L,H,32,0.  */
>
>> +  rtx H = gen_reg_rtx (DImode);
>> +  rtx L = gen_reg_rtx (DImode);
>> +  HOST_WIDE_INT num = (ud2 << 16) | ud1;
>> +  rs6000_emit_set_long_const (L, (num ^ 0x8000) - 0x8000);
>> +  num = (ud4 << 16) | ud3;
>> +  rs6000_emit_set_long_const (H, (num ^ 0x8000) - 0x8000);
>> +  emit_insn (gen_rotldi3_insert_3 (dest, H, GEN_INT (32), L,
>> +   GEN_INT (0x)));
>> +}
>> +  else
>> +{
>> +  /* lis A, U4; ori A,U3; rotl A,32; oris A,U2; ori A,U1.  */
>~~~ unexpected space?
Thanks for the catch!
>
>> +  emit_move_insn (dest,
>> +  GEN_INT (((ud4 << 16) ^ 0x8000) - 0x8000));
>> +  if (ud3 != 0)
>> +emit_move_insn (dest, gen_rtx_IOR (DImode, dest, GEN_INT (ud3)));
>> 
>> -  emit_move_insn (ud2 != 0 || ud1 != 0 ? copy_rtx (temp) : dest,
>> -  gen_rtx_ASHIFT (DImode, copy_rtx (temp),
>> -  GEN_INT (32)));
>> -  if (ud2 != 0)
>> -emit_move_insn (ud1 != 0 ? copy_rtx (temp) : dest,
>> -gen_rtx_IOR (DImode, copy_rtx (temp),
>> - GEN_INT (ud2 << 16)));
>> -  if (ud1 != 0)
>> -emit_move_insn (dest,
>> -gen_rtx_IOR (DImode, copy_rtx (temp),
>> - GEN_INT (ud1)));
>> +  emit_move_insn (dest, gen_rtx_ASHIFT (DImode, dest, GEN_INT (32)));
>> +  if (ud2 != 0)
>> +emit_move_insn (dest,
>> +gen_rtx_IOR (DImode, dest, GEN_INT (ud2 << 16)));
>> +  if (ud1 != 0)
>> +emit_move_insn (dest, gen_rtx_IOR (DImode, dest, GEN_INT (ud1)));
>> +}
>>  }
>>  }
>> 
>> diff --git a/gcc/testsuite/gcc.target/powerpc/parall_5insn_const.c 
>> b/gcc/testsuite/gcc.target/powerpc/parall_5insn_const.c
>> new file mode 100644
>> index 000..ed8ccc73378
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.target/powerpc/parall_5insn_const.c
>> @@ -0,0 +1,27 @@
>> +/* { dg-do run } */
>> +/* { dg-options "-O2 -mdejagnu-cpu=power7  -save-temps" } */
>
> Why do we need power7 here?
power8/9 are also ok for this case.  Actually, O just want to
avoid to use new p10 instruction, like "pli", and then selected
an old arch option.

>
>> +/* { dg-require-effective-target has_arch_ppc64 } */
>> +
>> +/* { dg-final { scan-assembler-times {\mlis\M} 4 } } */
>> +/* { dg-final { scan-assembler-times {\mori\M} 4 } } */
>> +/* { dg-final { scan-assembler-times {\mrldimi\M} 2 } } */
>> +
>> +void __attribute__ ((noinline)) foo (unsigned long long *a)
>> +{
>> +  /* 2lis+2ori+1rldimi for each constant.  */
>

[Bug tree-optimization/97832] AoSoA complex caxpy-like loops: AVX2+FMA -Ofast 7 times slower than -O3

[already5chosen at yahoo dot com via Gcc-bugs]

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

--- Comment #16 from Michael_S  ---
On unrelated note, why loop overhead uses so many instructions?
Assuming that I am as misguided as gcc about load-op combining, I would write
it as:
  sub %rax, %rdx
.L3:
  vmovupd   (%rdx,%rax), %ymm1
  vmovupd 32(%rdx,%rax), %ymm0
  vfmadd213pd32(%rax), %ymm3, %ymm1
  vfnmadd213pd (%rax), %ymm2, %ymm0
  vfnmadd231pd   32(%rdx,%rax), %ymm3, %ymm0
  vfnmadd231pd (%rdx,%rax), %ymm2, %ymm1
  vmovupd %ymm0,   (%rax)
  vmovupd %ymm1, 32(%rax)
  addq$64, %rax
  decl%esi
  jb  .L3

The loop overhead in my variant is 3 x86 instructions==2 macro-ops,
vs 5 x86 instructions==4 macro-ops in gcc variant.
Also, in gcc variant all memory accesses have displacement that makes them
1 byte longer. In my variant only half of accesses have displacement.

I think, in the past I had seen cases where gcc generates optimal or
near-optimal
code sequences for loop overhead. I wonder why it can not do it here.

Re: [PATCH] tree-optimization/106912 - IPA profile and pure/const

[Jan Hubicka via Gcc-patches]

> On Fri, 25 Nov 2022, Jan Hubicka wrote:
> 
> > > 
> > > 
> > > > Am 25.11.2022 um 11:05 schrieb Jan Hubicka via Gcc-patches 
> > > > :
> > > > 
> > > > 
> > > >> 
> > > >> IPA profile instrumentation tries to clear the pure and const
> > > >> flags of functions but that's quite hopeless in particular for
> > > >> const since that attribute prevails on the type and thus on each
> > > >> call to the function leading to inconsistencies in the IL and
> > > >> eventual checking ICEs.  There's no good reason to do this and
> > > >> it wouldn't fixup any indirect calls so just don't.  No other
> > > >> instrumentation GCC does bothers about this.
> > > > 
> > > > This was mostly meant to deadl with situation where we auto-detect
> > > > function to be const and then partially inline it to a loop.
> > > > Then both caller and callee accesses same counters in the memory and if
> > > > you move load/stores out of the loop in caller you lose counters and get
> > > > inconsistencies at profile read-in time.
> > > 
> > > Don?t we Instrument after partial inlining now?  As said, since we have 
> > > the fntype on the call this doesn?t work anymore for const functions via 
> > > attributes.
> > 
> > Full inlining can cause problem already.  So for code like
> > 
> > do
> > {
> >   if (__builtin_expect (test,1))
> > a+=foo (a);
> >   else
> > a+=foo (b);
> > } while ();
> > we may end up inlining one of the two invocation. Then caller and callee
> > will modify the same counter.  If we handle the remaining call as const,
> > we can hoist the counter modifications out of the loop and mix them up.
> >
> > I remember I run into an actual example of this problem during GCC
> > bootstrap. There the function was auto-detected to be const by
> > early pure-const pass so type was not an problem. You are right we ought
> > to do something about types since the scenario above can happen with foo
> > being declared with an attribute as well.
> 
> Or by doing the first call as
> 
> volatile int __attribute__((const)) (*foop)(int) = foo;
> 
>   a += (*foop) (a);
> 
> you'd need to get all calls that might possibly call an instrumented
> function adjusted.
> 
> I think if we're taking this issue serious we'd have to simply
> ignore const/pure attributes at parsing time and refrain from
> auto-detecting as well, at least for address-taken functions?

I think that is also not a good idea, since we would have to do that
with -fprofile-use, too (so the CFG at the instrumentation time
matches) and it would lead to poor perofrmance with FDO.
The idea was to honor pure/const during early opt and undo the
attributes when profiling is inserted.
We have fixup_cfg to compensate for attribute changes.  We could
probably keep tract if any instrumented code was ever inlined into a
given function and perhaps just start ignoring attributes set on types?

Honza
> 
> That said, this adjustment in the "wrong" direction causes problems
> downstream, which is what the fixed PR is about (simd cloning picks
> up the wrong things, or rather possibly fails to clone the attributes?).
> 
> Richard.
> 
> > Honza
> > > 
> > > Richard 
> > > > Honza
> > > >> 
> > > >> Bootstrap and regtest pending on x86_64-unknown-linux-gnu, OK?
> > > >> 
> > > >> Thanks,
> > > >> Richard.
> > > >> 
> > > >>PR tree-optimization/106912
> > > >>* tree-profile.cc (tree_profiling): Do not clear pure/const
> > > >>flags.
> > > >> 
> > > >>* gcc.dg/pr106912.c: New testcase.
> > > >> ---
> > > >> gcc/testsuite/gcc.dg/pr106912.c | 16 
> > > >> gcc/tree-profile.cc |  3 ---
> > > >> 2 files changed, 16 insertions(+), 3 deletions(-)
> > > >> create mode 100644 gcc/testsuite/gcc.dg/pr106912.c
> > > >> 
> > > >> diff --git a/gcc/testsuite/gcc.dg/pr106912.c 
> > > >> b/gcc/testsuite/gcc.dg/pr106912.c
> > > >> new file mode 100644
> > > >> index 000..8faa877d8b3
> > > >> --- /dev/null
> > > >> +++ b/gcc/testsuite/gcc.dg/pr106912.c
> > > >> @@ -0,0 +1,16 @@
> > > >> +/* { dg-do compile } */
> > > >> +/* { dg-options "-O2 -fPIC -ftree-vectorize -fprofile-generate" } */
> > > >> +
> > > >> +__attribute__ ((__simd__))
> > > >> +__attribute__ ((__nothrow__ , __leaf__ , __const__))
> > > >> +double foo (double x);
> > > >> +void bar(double *f, int n)
> > > >> +{
> > > >> +  int i;
> > > >> +  for (i = 0; i < n; i++)
> > > >> +f[i] = foo(f[i]);
> > > >> +}
> > > >> +double foo(double x)
> > > >> +{
> > > >> +  return x * x / 3.0;
> > > >> +}
> > > >> diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
> > > >> index 2beb49241f2..5491b398870 100644
> > > >> --- a/gcc/tree-profile.cc
> > > >> +++ b/gcc/tree-profile.cc
> > > >> @@ -814,9 +814,6 @@ tree_profiling (void)
> > > >>/* Don't profile functions produced for builtin stuff.  */
> > > >>if (DECL_SOURCE_LOCATION (node->decl) == BUILTINS_LOCATION)
> > > >>  continue;
> > > >> -
> > > >> -node->set_const_flag (false, false);
> > > >> -node->set_pure_flag 

Re: [PATCH] tree-optimization/106912 - IPA profile and pure/const

[Richard Biener via Gcc-patches]

On Fri, 25 Nov 2022, Jan Hubicka wrote:

> > 
> > 
> > > Am 25.11.2022 um 11:05 schrieb Jan Hubicka via Gcc-patches 
> > > :
> > > 
> > > 
> > >> 
> > >> IPA profile instrumentation tries to clear the pure and const
> > >> flags of functions but that's quite hopeless in particular for
> > >> const since that attribute prevails on the type and thus on each
> > >> call to the function leading to inconsistencies in the IL and
> > >> eventual checking ICEs.  There's no good reason to do this and
> > >> it wouldn't fixup any indirect calls so just don't.  No other
> > >> instrumentation GCC does bothers about this.
> > > 
> > > This was mostly meant to deadl with situation where we auto-detect
> > > function to be const and then partially inline it to a loop.
> > > Then both caller and callee accesses same counters in the memory and if
> > > you move load/stores out of the loop in caller you lose counters and get
> > > inconsistencies at profile read-in time.
> > 
> > Don?t we Instrument after partial inlining now?  As said, since we have the 
> > fntype on the call this doesn?t work anymore for const functions via 
> > attributes.
> 
> Full inlining can cause problem already.  So for code like
> 
> do
> {
>   if (__builtin_expect (test,1))
> a+=foo (a);
>   else
> a+=foo (b);
> } while ();
> we may end up inlining one of the two invocation. Then caller and callee
> will modify the same counter.  If we handle the remaining call as const,
> we can hoist the counter modifications out of the loop and mix them up.
>
> I remember I run into an actual example of this problem during GCC
> bootstrap. There the function was auto-detected to be const by
> early pure-const pass so type was not an problem. You are right we ought
> to do something about types since the scenario above can happen with foo
> being declared with an attribute as well.

Or by doing the first call as

volatile int __attribute__((const)) (*foop)(int) = foo;

  a += (*foop) (a);

you'd need to get all calls that might possibly call an instrumented
function adjusted.

I think if we're taking this issue serious we'd have to simply
ignore const/pure attributes at parsing time and refrain from
auto-detecting as well, at least for address-taken functions?

That said, this adjustment in the "wrong" direction causes problems
downstream, which is what the fixed PR is about (simd cloning picks
up the wrong things, or rather possibly fails to clone the attributes?).

Richard.

> Honza
> > 
> > Richard 
> > > Honza
> > >> 
> > >> Bootstrap and regtest pending on x86_64-unknown-linux-gnu, OK?
> > >> 
> > >> Thanks,
> > >> Richard.
> > >> 
> > >>PR tree-optimization/106912
> > >>* tree-profile.cc (tree_profiling): Do not clear pure/const
> > >>flags.
> > >> 
> > >>* gcc.dg/pr106912.c: New testcase.
> > >> ---
> > >> gcc/testsuite/gcc.dg/pr106912.c | 16 
> > >> gcc/tree-profile.cc |  3 ---
> > >> 2 files changed, 16 insertions(+), 3 deletions(-)
> > >> create mode 100644 gcc/testsuite/gcc.dg/pr106912.c
> > >> 
> > >> diff --git a/gcc/testsuite/gcc.dg/pr106912.c 
> > >> b/gcc/testsuite/gcc.dg/pr106912.c
> > >> new file mode 100644
> > >> index 000..8faa877d8b3
> > >> --- /dev/null
> > >> +++ b/gcc/testsuite/gcc.dg/pr106912.c
> > >> @@ -0,0 +1,16 @@
> > >> +/* { dg-do compile } */
> > >> +/* { dg-options "-O2 -fPIC -ftree-vectorize -fprofile-generate" } */
> > >> +
> > >> +__attribute__ ((__simd__))
> > >> +__attribute__ ((__nothrow__ , __leaf__ , __const__))
> > >> +double foo (double x);
> > >> +void bar(double *f, int n)
> > >> +{
> > >> +  int i;
> > >> +  for (i = 0; i < n; i++)
> > >> +f[i] = foo(f[i]);
> > >> +}
> > >> +double foo(double x)
> > >> +{
> > >> +  return x * x / 3.0;
> > >> +}
> > >> diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
> > >> index 2beb49241f2..5491b398870 100644
> > >> --- a/gcc/tree-profile.cc
> > >> +++ b/gcc/tree-profile.cc
> > >> @@ -814,9 +814,6 @@ tree_profiling (void)
> > >>/* Don't profile functions produced for builtin stuff.  */
> > >>if (DECL_SOURCE_LOCATION (node->decl) == BUILTINS_LOCATION)
> > >>  continue;
> > >> -
> > >> -node->set_const_flag (false, false);
> > >> -node->set_pure_flag (false, false);
> > >>   }
> > >> 
> > >>   /* Update call statements and rebuild the cgraph.  */
> > >> -- 
> > >> 2.35.3
> 

-- 
Richard Biener 
SUSE Software Solutions Germany GmbH, Frankenstrasse 146, 90461 Nuernberg,
Germany; GF: Ivo Totev, Andrew Myers, Andrew McDonald, Boudien Moerman;
HRB 36809 (AG Nuernberg)

[Bug target/107830] [13 Regression] ICE in gen_aarch64_bitmask_udiv3, at ./insn-opinit.h:813

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Tamar Christina :

https://gcc.gnu.org/g:71f3036b8a83da7fb559923bc80687ea1dabe14a

commit r13-4303-g71f3036b8a83da7fb559923bc80687ea1dabe14a
Author: Tamar Christina 
Date:   Fri Nov 25 12:57:24 2022 +

sve2: Fix expansion of division [PR107830]

SVE has an actual division optab, and when using -Os we don't
optimize the division away.  This means that we need to distinguish
between a div which we can optimize and one we cannot even during
expansion.

gcc/ChangeLog:

PR target/107830
* config/aarch64/aarch64.cc
(aarch64_vectorize_can_special_div_by_constant): Check validity
during
codegen phase as well.

gcc/testsuite/ChangeLog:

PR target/107830
* gcc.target/aarch64/sve2/pr107830-1.c: New test.
* gcc.target/aarch64/sve2/pr107830-2.c: New test.

Re: Please, really, make `-masm=intel` the default for x86

[Richard Biener via Gcc]

On Fri, Nov 25, 2022 at 1:03 PM LIU Hao via Gcc  wrote:
>
> 在 2022/11/25 17:32, Jakub Jelinek 写道:
> > So just use -masm=intel yourself and don't force it on others.
> >
> > Other people are familiar with AT syntax rather than Intel syntax,
> > in fact, as history shows, Intel syntax is a second class citizen that often
> > takes years to fix up for new instructions.  The memory size prefixes for
> > certain vector instructions are complete lottery and has been changed by the
> > assembler over time.
> >
> > And more importantly, various valid sources aren't really compilable at all
> > with Intel syntax, see https://gcc.gnu.org/PR53929 and dups for some 
> > details.
> >
>
> Well, if that's your decision, fair enough. I can maintain my own 
> distribution.
>
> Patch attached [1]; bootstrapped on {x86_64,1686}-w64-mingw32 without any 
> issues so far.

it would be also possible to at a configure time choice, or one driven
by config.gcc (thus
*mingw* could default to intel syntax if they like).

Richard.

>
> [1]
> https://github.com/lhmouse/MINGW-packages/blob/gcc-13/mingw-w64-gcc/9000-Deprecate-the-nonsense-AT-T-synax.patch
>
>
> --
> Best regards,
> LIU Hao
>

[Bug target/107830] [13 Regression] ICE in gen_aarch64_bitmask_udiv3, at ./insn-opinit.h:813

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #5 from Tamar Christina  ---
Fixed, thanks for the report.

[PATCH] i386: fix assert (__builtin_cpu_supports ("x86-64") >= 0)

[Martin Liška]

Similar story as PR103661, we again return a negative number
for __builtin_cpu_supports:

Documentation says:

int __builtin_cpu_supports(const char *feature)
This function returns a positive integer if the run-time CPU supports feature 
and returns 0 otherwise.
while we return -2147483648.

Moreover, I noticed "x86-64" is not a valid option for __builtin_cpu_is,
but for __builtin_cpu_supports.

Patch can bootstrap on x86_64-linux-gnu and survives regression tests.

Ready to be installed?
Thanks,
Martin

PR target/107551

gcc/ChangeLog:

* config/i386/i386-builtins.cc (fold_builtin_cpu): Use same path
as for PR103661.
* doc/extend.texi: Fix "x86-64" use.

gcc/testsuite/ChangeLog:

* gcc.target/i386/builtin_target.c: Add more checks.
---
 gcc/config/i386/i386-builtins.cc  | 25 ---
 gcc/doc/extend.texi   | 22 
 .../gcc.target/i386/builtin_target.c  |  5 
 3 files changed, 26 insertions(+), 26 deletions(-)

diff --git a/gcc/config/i386/i386-builtins.cc b/gcc/config/i386/i386-builtins.cc
index eacdf072244..c57c1380298 100644
--- a/gcc/config/i386/i386-builtins.cc
+++ b/gcc/config/i386/i386-builtins.cc
@@ -2181,18 +2181,14 @@ fold_builtin_cpu (tree fndecl, tree *args)
  varpool_node::add (ix86_cpu_features2_var);
}
 
+ /* Skip __cpu_features[0].  */
  feature -= INT_TYPE_SIZE;
- field_val = 1U << (feature % INT_TYPE_SIZE);
  tree index = size_int (feature / INT_TYPE_SIZE);
+ feature = feature % INT_TYPE_SIZE;
  array_elt = build4 (ARRAY_REF, unsigned_type_node,
  ix86_cpu_features2_var,
  index, NULL_TREE, NULL_TREE);
  /* Return __cpu_features2[index] & field_val  */
- final = build2 (BIT_AND_EXPR, unsigned_type_node,
- array_elt,
- build_int_cstu (unsigned_type_node,
- field_val));
- return build1 (NOP_EXPR, integer_type_node, final);
}
   else
{
@@ -2209,16 +2205,17 @@ fold_builtin_cpu (tree fndecl, tree *args)
  array_elt = build4 (ARRAY_REF, unsigned_type_node, ref,
  integer_zero_node, NULL_TREE, NULL_TREE);
 
- field_val = (1U << feature);
  /* Return __cpu_model.__cpu_features[0] & field_val  */
- final = build2 (BIT_AND_EXPR, unsigned_type_node, array_elt,
- build_int_cstu (unsigned_type_node, field_val));
- if (feature == (INT_TYPE_SIZE - 1))
-   return build2 (NE_EXPR, integer_type_node, final,
-  build_int_cst (unsigned_type_node, 0));
- else
-   return build1 (NOP_EXPR, integer_type_node, final);
}
+
+  field_val = (1U << feature);
+  final = build2 (BIT_AND_EXPR, unsigned_type_node, array_elt,
+ build_int_cstu (unsigned_type_node, field_val));
+  if (feature == (INT_TYPE_SIZE - 1))
+   return build2 (NE_EXPR, integer_type_node, final,
+  build_int_cst (unsigned_type_node, 0));
+  else
+   return build1 (NOP_EXPR, integer_type_node, final);
 }
   gcc_unreachable ();
 }
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index b1dd39e64b8..d3812fa55b0 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -21897,18 +21897,6 @@ AMD Family 19h Zen version 3.
 
 @item znver4
 AMD Family 19h Zen version 4.
-
-@item x86-64
-Baseline x86-64 microarchitecture level (as defined in x86-64 psABI).
-
-@item x86-64-v2
-x86-64-v2 microarchitecture level.
-
-@item x86-64-v3
-x86-64-v3 microarchitecture level.
-
-@item x86-64-v4
-x86-64-v4 microarchitecture level.
 @end table
 
 Here is an example:
@@ -22002,6 +21990,16 @@ VPCLMULQDQ instructions.
 AVX512VNNI instructions.
 @item avx512bitalg
 AVX512BITALG instructions.
+@item x86-64
+Baseline x86-64 microarchitecture level (as defined in x86-64 psABI).
+@item x86-64-v2
+x86-64-v2 microarchitecture level.
+@item x86-64-v3
+x86-64-v3 microarchitecture level.
+@item x86-64-v4
+x86-64-v4 microarchitecture level.
+
+
 @end table
 
 Here is an example:
diff --git a/gcc/testsuite/gcc.target/i386/builtin_target.c 
b/gcc/testsuite/gcc.target/i386/builtin_target.c
index 3e7505a8c3a..fff643c13b0 100644
--- a/gcc/testsuite/gcc.target/i386/builtin_target.c
+++ b/gcc/testsuite/gcc.target/i386/builtin_target.c
@@ -95,6 +95,11 @@ quick_check ()
 
   assert (__builtin_cpu_supports ("avx512vpopcntdq") >= 0);
 
+  assert (__builtin_cpu_supports ("x86-64") >= 0);
+  assert (__builtin_cpu_supports ("x86-64-v2") >= 0);
+  assert (__builtin_cpu_supports ("x86-64-v3") >= 0);
+  assert (__builtin_cpu_supports ("x86-64-v4") >= 0);
+
   /* Check CPU type.  */
   assert (__builtin_cpu_is ("amd") >= 0);
 
-- 
2.38.1

Re: [PATCH V2] rs6000: Support to build constants by li/lis+oris/xoris

[Jiufu Guo via Gcc-patches]

Hi Kewen,

Thanks a lot for your insight comments!

"Kewen.Lin"  writes:

> Hi Jeff,
>
> Sorry for the late reply.
>
> on 2022/10/26 19:40, Jiufu Guo wrote:
>> Hi,
>> 
>> PR106708 constaint some constants which can be support by li/lis + 
>> oris/xoris.
> typo?
Oh, typo!
>
> for "li/lis + oris/xoris", I interpreted it into four combinations:
>
>li + oris, lis + oris, li + xoris, lis + xoris.
>
> not sure just me interpreting like that, but the actual combinations
> which this patch adopts are:
>
>li + oris, li + xoris, lis + xoris.
>
> It's a bit off, but not a big deal, up to you to reword it or not.  :)
Oh, thanks! I will update to use "li/lis + xoris" or "li + oris" to
avoid confuse.
>
>> 
>> For constant C:
>> if '(c & 0x80008000ULL) == 0x8000ULL' or say:
>> 32(0) || 1(1) || 15(x) || 1(0) || 15(x), we could use li+oris to
>> build constant 'C'.
>> Here N(M) means N continuous bit M, x for M means it is ok for either
>> 1 or 0; '||' means concatenation.
>> 
>> if '(c & 0x8000ULL) == 0x8000ULL' or say:
>> 32(1) || 16(x) || 1(1) || 15(x), using li+xoris would be ok.
>> 
>> if '(c & 0xULL) == 0x' or say:
>> 32(1) || 1(0) || 15(x) || 16(0), using lis+xoris would be ok.
>> 
>> This patch update rs6000_emit_set_long_const to support these forms.
>> Bootstrap and regtest pass on ppc64 and ppc64le.
>> 
>> Is this ok for trunk?
>
> This updated version looks good to me, but I'd leave it to Segher for the
> final say.  Thanks!

Thanks!

BR,
Jeff (Jiufu)
>
> BR,
> Kewen
>
>> 
>> BR,
>> Jeff(Jiufu)
>> 
>> 
>>  PR target/106708
>> 
>> gcc/ChangeLog:
>> 
>>  * config/rs6000/rs6000.cc (rs6000_emit_set_long_const): Support
>>  constants which can be built with li + oris or li/lis + xoris.
>> 
>> gcc/testsuite/ChangeLog:
>> 
>>  * gcc.target/powerpc/pr106708-run.c: New test.
>>  * gcc.target/powerpc/pr106708.c: New test.
>>  * gcc.target/powerpc/pr106708.h: New file.
>> 
>> ---
>>  gcc/config/rs6000/rs6000.cc   | 41 ++-
>>  .../gcc.target/powerpc/pr106708-run.c | 17 
>>  gcc/testsuite/gcc.target/powerpc/pr106708.c   | 12 ++
>>  gcc/testsuite/gcc.target/powerpc/pr106708.h   |  9 
>>  4 files changed, 69 insertions(+), 10 deletions(-)
>>  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr106708-run.c
>>  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr106708.c
>>  create mode 100644 gcc/testsuite/gcc.target/powerpc/pr106708.h
>> 
>> diff --git a/gcc/config/rs6000/rs6000.cc b/gcc/config/rs6000/rs6000.cc
>> index d2743f7bce6..9b7a51f052d 100644
>> --- a/gcc/config/rs6000/rs6000.cc
>> +++ b/gcc/config/rs6000/rs6000.cc
>> @@ -10228,6 +10228,7 @@ rs6000_emit_set_long_const (rtx dest, HOST_WIDE_INT 
>> c)
>>  {
>>rtx temp;
>>HOST_WIDE_INT ud1, ud2, ud3, ud4;
>> +  HOST_WIDE_INT orig_c = c;
>> 
>>ud1 = c & 0x;
>>c = c >> 16;
>> @@ -10253,21 +10254,41 @@ rs6000_emit_set_long_const (rtx dest, 
>> HOST_WIDE_INT c)
>>  gen_rtx_IOR (DImode, copy_rtx (temp),
>>   GEN_INT (ud1)));
>>  }
>> +  else if ((ud4 == 0x && ud3 == 0x)
>> +   && ((ud1 & 0x8000) || (ud1 == 0 && !(ud2 & 0x8000
>> +{
>> +  temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode);
>> +
>> +  HOST_WIDE_INT imm = (ud1 & 0x8000) ? ((ud1 ^ 0x8000) - 0x8000)
>> + : ((ud2 << 16) - 0x8000);
>> +  /* li/lis + xoris */
>> +  emit_move_insn (temp, GEN_INT (imm));
>> +  emit_move_insn (dest, gen_rtx_XOR (DImode, temp,
>> + GEN_INT (orig_c ^ imm)));
>> +}
>>else if (ud3 == 0 && ud4 == 0)
>>  {
>>temp = !can_create_pseudo_p () ? dest : gen_reg_rtx (DImode);
>> 
>>gcc_assert (ud2 & 0x8000);
>> -  emit_move_insn (copy_rtx (temp),
>> -  GEN_INT (((ud2 << 16) ^ 0x8000) - 0x8000));
>> -  if (ud1 != 0)
>> -emit_move_insn (copy_rtx (temp),
>> -gen_rtx_IOR (DImode, copy_rtx (temp),
>> - GEN_INT (ud1)));
>> -  emit_move_insn (dest,
>> -  gen_rtx_ZERO_EXTEND (DImode,
>> -   gen_lowpart (SImode,
>> -copy_rtx (temp;
>> +
>> +  if (!(ud1 & 0x8000))
>> +{
>> +  /* li+oris */
>> +  emit_move_insn (temp, GEN_INT (ud1));
>> +  emit_move_insn (dest,
>> +  gen_rtx_IOR (DImode, temp, GEN_INT (ud2 << 16)));
>> +}
>> +  else
>> +{
>> +  emit_move_insn (temp,
>> +  GEN_INT (((ud2 << 16) ^ 0x8000) - 0x8000));
>> +  if (ud1 != 0)
>> +emit_move_insn (temp, gen_rtx_IOR (DImode, temp, GEN_INT (ud1)));
>> +  emit_move_insn (dest,
>> +  gen_rtx_ZERO_EXTEND (DImode,
>> + 

[Bug tree-optimization/107867] [13 Regression] ICE in init_from_control_deps, at gimple-predicate-analysis.cc:1699 since r13-2314-ga8ebd27d0ab69b08

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
forwprop has the same issue.

[Bug sanitizer/107866] [12/13 Regression] gcc trunk's UBSan misses a Null-pointer-dereference at -O3.

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

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

--- Comment #3 from Richard Biener  ---
For some reason we think that the .UBSAN_NULL call doesn't clobber the load
from nullptr:

[local count: 118111600]:
+  # VUSE <.MEM_3(D)>
+  pretmp_7 = MEM[(int *)0B];

[local count: 1073741824]:
-  # .MEM_2 = PHI <.MEM_3(D)(2), .MEM_6(5)>
+  # .MEM_2 = PHI <.MEM_3(D)(2), .MEM_6(3)>
   # .MEM_4 = VDEF <.MEM_2>
   a = 0B;
   # .MEM_6 = VDEF <.MEM_4>
   # USE = nonlocal escaped 
   # CLB = nonlocal escaped 
   .UBSAN_NULL (0B, 0B, 4);
-  # VUSE <.MEM_6>
-  _1 = MEM[(int *)0B];
-  if (_1 != 0)
+  if (pretmp_7 != 0)

that's because

DEF_INTERNAL_FN (UBSAN_NULL, ECF_LEAF | ECF_NOTHROW, ". R . ")

and thus .UBSAN_NULL only _reads_ from the first argument passed (but also
possibly constant NULL(?) valued operands are considered special).  The
same happens at -O2 btw.  At -O1 we eliminate the load.

Ah, and call_may_clobber_ref_p_1 has

  if (gimple_call_internal_p (call))
switch (auto fn = gimple_call_internal_fn (call))
  {
/* Treat these internal calls like ECF_PURE for aliasing,
   they don't write to any memory the program should care about.
   They have important other side-effects, and read memory,
   so can't be ECF_NOVOPS.  */
  case IFN_UBSAN_NULL:
  case IFN_UBSAN_BOUNDS:
  case IFN_UBSAN_VPTR:
  case IFN_UBSAN_OBJECT_SIZE:
  case IFN_UBSAN_PTR:
  case IFN_ASAN_CHECK:
return false;

so they are not a barrier for the motion of loads which is what happens
here.

Note that only at -O3 we keep the trapping load because we fail to eliminate
the conditional there and have

   [local count: 118111600]:
  # VUSE <.MEM_3(D)>
  pretmp_7 = MEM[(int *)0B];
  if (pretmp_7 != 0)
goto ; [11.00%]
  else
goto ; [89.00%]

   [local count: 955630224]:
  # .MEM_1 = PHI <.MEM_3(D)(2)>
  # .MEM_8 = VDEF <.MEM_1>
  a = 0B;
  # .MEM_11 = VDEF <.MEM_8>
  # USE = anything
  # CLB = anything
  __builtin___ubsan_handle_type_mismatch_v1_abort (&*.Lubsan_data0, 0);

   [local count: 118111600]:
  # .MEM_4 = VDEF <.MEM_3(D)>
  a = 0B;
  # .MEM_10 = VDEF <.MEM_4>
  # USE = anything
  # CLB = anything
  __builtin___ubsan_handle_type_mismatch_v1_abort (&*.Lubsan_data1, 0);

in the end.

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

[Jiufu Guo via Gcc-patches]

Jiufu Guo via Gcc-patches  writes:

> Hi Richard,
>
> Thanks a lot for your comments!
>
> Richard Biener  writes:
>
>> On Wed, 23 Nov 2022, Jiufu Guo wrote:
>>
>>> Hi Jeff,
>>> 
>>> Thanks a lot for your comments!
>>
>> Sorry for the late response ...
>>
>>> 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
cut...
>>> >> +  FOR_EACH_EDGE (e, ei, EXIT_BLOCK_PTR_FOR_FN (cfun)->preds)
>>> >> +if (greturn *ret = safe_dyn_cast (last_stmt 
>>> >> (e->src)))
>>> >> +  {
>>> >> +tree val = gimple_return_retval (ret);
>>> >> +if (val && VAR_P (val))
>>> >> +  DECL_USEDBY_RETURN_P (val) = 1;
>>
>> you probably want to check && auto_var_in_fn (val, ...) since val
>> might be global?
> Since we are collecting the return vals, it would be built in function
> gimplify_return_expr.  In this function, create_tmp_reg is used and
> a local temp.  So it would not be a global var here.
>
> code piece in gimplify_return_expr:
>   if (!result_decl)
> result = NULL_TREE;
>   else if (aggregate_value_p (result_decl, TREE_TYPE (current_function_decl)))
> {
> 
>   result = result_decl;
> }
>   else if (gimplify_ctxp->return_temp)
> result = gimplify_ctxp->return_temp;
>   else
> {
>   result = create_tmp_reg (TREE_TYPE (result_decl));
>
> Here, for "typedef struct SA {double a[3];}", aggregate_value_p returns
> false for target like ppc64le, because result of "hard_function_value"
> is a "rtx with PARALLELL code".
> And then a DECL_VAR is built via "create_tmp_reg" (actually it is not a
> reg here. it built a DECL_VAR with RECORD type and BLK mode).
>
> I also tried the way to use RESULT_DECL for this kind of type, or
> let aggregate_value_p accept this kind of type.  But it seems not easy,
> because " (RESULT_DECL with PARALLEL)" is not ok for address
> operations.
>
>
>>
>>> >> +  }
>>> >> +}
>>> >> +
>>> >> /* Set TREE_USED on all variables in the local_decls.  */
>>> >> FOR_EACH_LOCAL_DECL (cfun, i, var)
>>> >>   TREE_USED (var) = 1;
>>> >> diff --git a/gcc/expr.cc b/gcc/expr.cc
>>> >> index d9407432ea5..20973649963 100644
>>> >> --- a/gcc/expr.cc
>>> >> +++ b/gcc/expr.cc
>>> >> @@ -6045,6 +6045,52 @@ expand_assignment (tree to, tree from, bool 
>>> >> nontemporal)
>>> >> return;
>>> >>   }
>>
>> I miss an explanatory comment here on that the following is heuristics
>> and its reasoning.
>>
>>> >>   +  if ((TREE_CODE (from) == PARM_DECL && DECL_INCOMING_RTL (from)
>>> >> +   && TYPE_MODE (TREE_TYPE (from)) == BLKmode
>>
>> Why check TYPE_MODE here?  Do you want AGGREGATE_TYPE_P on the type
>> instead?
> Checking BLK, because I want make sure the param should occur on
> register and stack (saved from register).
> Actualy, my intention is checking:
> GET_MODE (DECL_INCOMING_RTL (from)) == BLKmode
>
> For code:
> GET_MODE (DECL_INCOMING_RTL (from)) == BLKmode
> && (GET_CODE (DECL_INCOMING_RTL (from)) == PARALLEL
> || REG_P (DECL_INCOMING_RTL (from)))
> This checking indicates if the param may be passing via 2 or more
> registers.
>
> Using "AGGREGATE_TYPE_P && (PARALLEL || REG_P)" may be ok and more
> readable. I would have a test.
Oh, AGGREGATE_TYPE_P seems not the intention of this patch, since if
struct size can be represented by an INT size, the mode would be that
INT mode, and no need to use block move for the assignment.

BR,
Jeff (Jiufu)
>
>>
>>> >> +   && (GET_CODE (DECL_INCOMING_RTL (from)) == PARALLEL
>>> >> +   || REG_P (DECL_INCOMING_RTL (from
>>> >> +  || (VAR_P (to) && DECL_USEDBY_RETURN_P (to)
>>> >> +  && TYPE_MODE (TREE_TYPE (to)) == BLKmode
>>
>> Likewise.
>>
>>> >> +  && GET_CODE (DECL_RTL (DECL_RESULT (current_function_decl)))
>>> >> +   == PARALLEL))
>>
>> Not REG_P here?
> REG_P with BLK on return would means return in memory, instead return
> through registers, so, REG_P was not added here, and let it use
> orignal behavior.
>>
>>> >> +{
>>> >> +  push_temp_slots ();
>>> >> +  rtx par_ret;
>>> >> +  machine_mode mode;
>>> >> +  par_ret = TREE_CODE (from) == PARM_DECL
>>> >> +  ? DECL_INCOMING_RTL (from)
>>> >> +  : DECL_RTL (DECL_RESULT (current_function_decl));
>>> >> +  mode = GET_CODE (par_ret) == PARALLEL
>>> >> +   ? GET_MODE (XEXP (XVECEXP (par_ret, 0, 0), 0))
>>> >> +   : word_mode;
>>> >> +  int mode_size = GET_MODE_SIZE (mode).to_constant ();
>>> >> +  int size = INTVAL (expr_size (from));
>>> >> +
>>> >> +  /* If/How 

[Bug ada/107810] [13 regression] gnat.dg/unchecked_convert9.adb FAILs

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

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

Eric Botcazou  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-25
 Ever confirmed|0   |1
 CC||ebotcazou at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Eric Botcazou  ---
Confirmed.  The test is still OK in 32-bit mode.

[Bug tree-optimization/107868] [10 regression] Wrong code on AArch64 at -O1 with new/delete

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
   Target Milestone|--- |10.5
   Last reconfirmed|2022-11-25 00:00:00 |
 Status|NEW |ASSIGNED
 Target||aarch64
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org

--- Comment #2 from Richard Biener  ---
Possibly yes.  Let me see if it can be backported.

[Bug tree-optimization/107868] [10 regression] Wrong code on AArch64 at -O1 with new/delete

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

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||marxin at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2022-11-25

--- Comment #1 from Martin Liška  ---
@Richi: What do you think?

[Bug sanitizer/107866] [12/13 Regression] gcc trunk's UBSan misses a Null-pointer-dereference at -O3.

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

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2022-11-25
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

Re: [PATCH] tree-optimization/106912 - IPA profile and pure/const

[Jan Hubicka via Gcc-patches]

> 
> 
> > Am 25.11.2022 um 11:05 schrieb Jan Hubicka via Gcc-patches 
> > :
> > 
> > 
> >> 
> >> IPA profile instrumentation tries to clear the pure and const
> >> flags of functions but that's quite hopeless in particular for
> >> const since that attribute prevails on the type and thus on each
> >> call to the function leading to inconsistencies in the IL and
> >> eventual checking ICEs.  There's no good reason to do this and
> >> it wouldn't fixup any indirect calls so just don't.  No other
> >> instrumentation GCC does bothers about this.
> > 
> > This was mostly meant to deadl with situation where we auto-detect
> > function to be const and then partially inline it to a loop.
> > Then both caller and callee accesses same counters in the memory and if
> > you move load/stores out of the loop in caller you lose counters and get
> > inconsistencies at profile read-in time.
> 
> Don’t we Instrument after partial inlining now?  As said, since we have the 
> fntype on the call this doesn’t work anymore for const functions via 
> attributes.

Full inlining can cause problem already.  So for code like

do
{
  if (__builtin_expect (test,1))
a+=foo (a);
  else
a+=foo (b);
} while ();
we may end up inlining one of the two invocation. Then caller and callee
will modify the same counter.  If we handle the remaining call as const,
we can hoist the counter modifications out of the loop and mix them up.

I remember I run into an actual example of this problem during GCC
bootstrap. There the function was auto-detected to be const by
early pure-const pass so type was not an problem. You are right we ought
to do something about types since the scenario above can happen with foo
being declared with an attribute as well.

Honza
> 
> Richard 
> > Honza
> >> 
> >> Bootstrap and regtest pending on x86_64-unknown-linux-gnu, OK?
> >> 
> >> Thanks,
> >> Richard.
> >> 
> >>PR tree-optimization/106912
> >>* tree-profile.cc (tree_profiling): Do not clear pure/const
> >>flags.
> >> 
> >>* gcc.dg/pr106912.c: New testcase.
> >> ---
> >> gcc/testsuite/gcc.dg/pr106912.c | 16 
> >> gcc/tree-profile.cc |  3 ---
> >> 2 files changed, 16 insertions(+), 3 deletions(-)
> >> create mode 100644 gcc/testsuite/gcc.dg/pr106912.c
> >> 
> >> diff --git a/gcc/testsuite/gcc.dg/pr106912.c 
> >> b/gcc/testsuite/gcc.dg/pr106912.c
> >> new file mode 100644
> >> index 000..8faa877d8b3
> >> --- /dev/null
> >> +++ b/gcc/testsuite/gcc.dg/pr106912.c
> >> @@ -0,0 +1,16 @@
> >> +/* { dg-do compile } */
> >> +/* { dg-options "-O2 -fPIC -ftree-vectorize -fprofile-generate" } */
> >> +
> >> +__attribute__ ((__simd__))
> >> +__attribute__ ((__nothrow__ , __leaf__ , __const__))
> >> +double foo (double x);
> >> +void bar(double *f, int n)
> >> +{
> >> +  int i;
> >> +  for (i = 0; i < n; i++)
> >> +f[i] = foo(f[i]);
> >> +}
> >> +double foo(double x)
> >> +{
> >> +  return x * x / 3.0;
> >> +}
> >> diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
> >> index 2beb49241f2..5491b398870 100644
> >> --- a/gcc/tree-profile.cc
> >> +++ b/gcc/tree-profile.cc
> >> @@ -814,9 +814,6 @@ tree_profiling (void)
> >>/* Don't profile functions produced for builtin stuff.  */
> >>if (DECL_SOURCE_LOCATION (node->decl) == BUILTINS_LOCATION)
> >>  continue;
> >> -
> >> -node->set_const_flag (false, false);
> >> -node->set_pure_flag (false, false);
> >>   }
> >> 
> >>   /* Update call statements and rebuild the cgraph.  */
> >> -- 
> >> 2.35.3

Re: [PATCH] tree-optimization/106912 - IPA profile and pure/const

[Richard Biener via Gcc-patches]

> Am 25.11.2022 um 11:05 schrieb Jan Hubicka via Gcc-patches 
> :
> 
> 
>> 
>> IPA profile instrumentation tries to clear the pure and const
>> flags of functions but that's quite hopeless in particular for
>> const since that attribute prevails on the type and thus on each
>> call to the function leading to inconsistencies in the IL and
>> eventual checking ICEs.  There's no good reason to do this and
>> it wouldn't fixup any indirect calls so just don't.  No other
>> instrumentation GCC does bothers about this.
> 
> This was mostly meant to deadl with situation where we auto-detect
> function to be const and then partially inline it to a loop.
> Then both caller and callee accesses same counters in the memory and if
> you move load/stores out of the loop in caller you lose counters and get
> inconsistencies at profile read-in time.

Don’t we Instrument after partial inlining now?  As said, since we have the 
fntype on the call this doesn’t work anymore for const functions via attributes.

Richard 
> Honza
>> 
>> Bootstrap and regtest pending on x86_64-unknown-linux-gnu, OK?
>> 
>> Thanks,
>> Richard.
>> 
>>PR tree-optimization/106912
>>* tree-profile.cc (tree_profiling): Do not clear pure/const
>>flags.
>> 
>>* gcc.dg/pr106912.c: New testcase.
>> ---
>> gcc/testsuite/gcc.dg/pr106912.c | 16 
>> gcc/tree-profile.cc |  3 ---
>> 2 files changed, 16 insertions(+), 3 deletions(-)
>> create mode 100644 gcc/testsuite/gcc.dg/pr106912.c
>> 
>> diff --git a/gcc/testsuite/gcc.dg/pr106912.c 
>> b/gcc/testsuite/gcc.dg/pr106912.c
>> new file mode 100644
>> index 000..8faa877d8b3
>> --- /dev/null
>> +++ b/gcc/testsuite/gcc.dg/pr106912.c
>> @@ -0,0 +1,16 @@
>> +/* { dg-do compile } */
>> +/* { dg-options "-O2 -fPIC -ftree-vectorize -fprofile-generate" } */
>> +
>> +__attribute__ ((__simd__))
>> +__attribute__ ((__nothrow__ , __leaf__ , __const__))
>> +double foo (double x);
>> +void bar(double *f, int n)
>> +{
>> +  int i;
>> +  for (i = 0; i < n; i++)
>> +f[i] = foo(f[i]);
>> +}
>> +double foo(double x)
>> +{
>> +  return x * x / 3.0;
>> +}
>> diff --git a/gcc/tree-profile.cc b/gcc/tree-profile.cc
>> index 2beb49241f2..5491b398870 100644
>> --- a/gcc/tree-profile.cc
>> +++ b/gcc/tree-profile.cc
>> @@ -814,9 +814,6 @@ tree_profiling (void)
>>/* Don't profile functions produced for builtin stuff.  */
>>if (DECL_SOURCE_LOCATION (node->decl) == BUILTINS_LOCATION)
>>  continue;
>> -
>> -node->set_const_flag (false, false);
>> -node->set_pure_flag (false, false);
>>   }
>> 
>>   /* Update call statements and rebuild the cgraph.  */
>> -- 
>> 2.35.3

Re: Please, really, make `-masm=intel` the default for x86

[LIU Hao via Gcc]

在 2022/11/25 17:32, Jakub Jelinek 写道:

So just use -masm=intel yourself and don't force it on others.

Other people are familiar with AT syntax rather than Intel syntax,
in fact, as history shows, Intel syntax is a second class citizen that often
takes years to fix up for new instructions.  The memory size prefixes for
certain vector instructions are complete lottery and has been changed by the
assembler over time.

And more importantly, various valid sources aren't really compilable at all
with Intel syntax, see https://gcc.gnu.org/PR53929 and dups for some details.



Well, if that's your decision, fair enough. I can maintain my own distribution.

Patch attached [1]; bootstrapped on {x86_64,1686}-w64-mingw32 without any 
issues so far.


[1] 
https://github.com/lhmouse/MINGW-packages/blob/gcc-13/mingw-w64-gcc/9000-Deprecate-the-nonsense-AT-T-synax.patch



--
Best regards,
LIU Hao



OpenPGP_signature
Description: OpenPGP digital signature

[Bug c++/99576] [coroutines] destructor of a temporary called too early within co_await expression

[adrian.perl at web dot de via Gcc-bugs]

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

Adrian Perl  changed:

   What|Removed |Added

 CC||adrian.perl at web dot de

--- Comment #5 from Adrian Perl  ---
Created attachment 53963
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53963=edit
Test applications

I also noticed this behaviour in gcc 11.2 and could reproduce it in all version
since 10.2 (even in the current trunk).

Since this issues has existed for some time now, I had a look at the code
myself and possibly found a fix. Please be aware that I am a complete novice in
regards to the gcc-sourcecode.

As the example posted by David Ledger (https://godbolt.org/z/8r8oGG4z5) was the
simplest one I could find, I used it to debug the issue.

Having a look at the generated tree using -fdump-tree-all-graph I found out
that the destructor of A gets indeed called twice, first by the destructor of
class Awaitable and then once more in a finally-clause.
...
 resume.4:;
  <;
}
  finally
{
  Awaitable::~Awaitable ();
}
}
  finally
{
  A::~A ();
}
...
The finally clauses are generated by the maybe_promote_temps-function in
coroutines.cc, which modifies the lifetime-management of temporaries in
co_await statements in order to keep them alive across a suspension point. For
this purpose it recursivly searches all initializers to the right of the
co_await expression, using the helper functions flatten_await_stmt and
find_interesting_subtree.
In this recursion it finds the initialization of the Awaitable and also the
initialization of its member. So both the temporary Awaitable-instance and its
member get promoted, which leads to the generation of a (correct) destructor
call for the Awaitable and the (incorrect) call for its member.

So the error seems to be in the recursion, which also finds and promotes
initializations in sub-scopes like the constructor. 

Therefore I modified the check for relevant subexpressions to exclude trees
below constructor calls, as can be seen in this patch:

Patch:
diff --git a/gcc/cp/coroutines.cc b/gcc/cp/coroutines.cc
index 01a3e831ee5..349b68ea239 100644
--- a/gcc/cp/coroutines.cc
+++ b/gcc/cp/coroutines.cc
@@ -2684,6 +2684,10 @@ find_interesting_subtree (tree *expr_p, int *dosub, void
*d)
  return expr;
}
 }
+  else if (TREE_CODE(expr) == CONSTRUCTOR)
+{
+  *dosub = 0; /* We don't need to consider this any further.  */
+}
   else if (tmp_target_expr_p (expr)
   && !p->temps_used->contains (expr))
 {
-- 
2.34.1

I checked the results of the patched compiler using most of the examples posted
in this and related bug reports (99576, 100611, 102217, 101244, 101976) and
always got the correct results, also matching the output of clang. I have
attached these test applications.

I also noticed that the incorrect behaviour is gone as soon as the Awaitable
has a user defined constructor. This likely moves the initalization of the
Awaitable to a seperate tree which does not get evaluated by
find_interesting_subtree. I checked the .dot-files and there was indeed an
additional tree for the constructor when it is defined by the user.

It would be great if someone could have a look at the patch, as I am unsure if
it could have any unforseen sideeffects.
Another (better?) fix for this issue could be to always generate the
constructor-tree.