[PATCH] DSE: Use the constant source if possible

[H.J. Lu via Gcc-patches]

When recording store for RTL dead store elimination, check if the source
register is set only once to a constant.  If yes, record the constant
as the store source.  It eliminates unrolled zero stores after memset 0
in a loop where a vector register is used as the zero store source.

gcc/

PR rtl-optimization/105638
* dse.cc (record_store): Use the constant source if the source
register is set only once.

gcc/testsuite/

PR rtl-optimization/105638
* g++.target/i386/pr105638.C: New test.
---
 gcc/dse.cc   | 19 ++
 gcc/testsuite/g++.target/i386/pr105638.C | 44 
 2 files changed, 63 insertions(+)
 create mode 100644 gcc/testsuite/g++.target/i386/pr105638.C

diff --git a/gcc/dse.cc b/gcc/dse.cc
index 30c11cee034..0433dd3d846 100644
--- a/gcc/dse.cc
+++ b/gcc/dse.cc
@@ -1508,6 +1508,25 @@ record_store (rtx body, bb_info_t bb_info)
 
  if (tem && CONSTANT_P (tem))
const_rhs = tem;
+ else
+   {
+ /* If RHS is set only once to a constant, set CONST_RHS
+to the constant.  */
+ df_ref def = DF_REG_DEF_CHAIN (REGNO (rhs));
+ if (def != nullptr
+ && !DF_REF_IS_ARTIFICIAL (def)
+ && !DF_REF_NEXT_REG (def))
+   {
+ rtx_insn *def_insn = DF_REF_INSN (def);
+ rtx def_body = PATTERN (def_insn);
+ if (GET_CODE (def_body) == SET)
+   {
+ rtx def_src = SET_SRC (def_body);
+ if (CONSTANT_P (def_src))
+   const_rhs = def_src;
+   }
+   }
+   }
}
 }
 
diff --git a/gcc/testsuite/g++.target/i386/pr105638.C 
b/gcc/testsuite/g++.target/i386/pr105638.C
new file mode 100644
index 000..ff40a459de1
--- /dev/null
+++ b/gcc/testsuite/g++.target/i386/pr105638.C
@@ -0,0 +1,44 @@
+/* { dg-do compile { target { ! ia32 } } } */
+/* { dg-options "-std=gnu++20 -O2 -march=skylake" } */
+/* { dg-final { scan-assembler-not "vpxor" } } */
+
+#include 
+#include 
+#include 
+
+class FastBoard {
+public:
+typedef std::pair movescore_t;
+typedef std::tr1::array scoredlist_t;
+
+protected:
+std::vector m_critical;
+
+int m_boardsize;
+};
+
+class FastState {
+public:
+FastBoard board;
+
+int movenum;  
+protected:
+FastBoard::scoredlist_t scoredmoves;
+};
+
+class KoState : public FastState {
+private: 
+std::vector ko_hash_history;   
+std::vector hash_history; 
+};
+
+class GameState : public KoState {
+public:
+void foo ();  
+private:
+std::vector game_history;  
+};
+
+void GameState::foo() {
+game_history.resize(movenum);
+}
-- 
2.36.1

[Bug middle-end/105629] [13 Regression] g++.dg/opt/pr94589-2.C for cris, m68k, s390x

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

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

--- Comment #6 from Hans-Peter Nilsson  ---
Created attachment 53011
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53011=edit
Reduced fix on top of 93416de0cb; a fragmental revert

The attached patch, applied to 93416de0cb, re-introduces the one of the removed
#if GIMPLE clauses, but narrowed to the one (simplify ...) clause, that
mattered for the regression.  (Not regtested though, just pr94589-2.C
re-compiled.)

I have no idea how this pattern matched here, as there appears to be no
"bit_and" expressions in the affected functions.  I'd suspect some kind of
saddle-point/local-minimum false lead, except then there'd reasonably be some
half-way transformation left in the code.  But then again, reasoning around
bugs you don't fully understand is rarely useful.

Anyway, I hope this helped.

Re: [PATCH] Modula-2: merge proposal/review: 1/9 01.patch-set-01

[Gaius Mulley via Gcc-patches]

Hi,

Gaius wrote:

> the changes do raise questions.  The reason for the changes here are to
> allow easy linking for modula-2 users.

>  $ gm2 hello.mod

> for example will compile and link with all dependent modules (dependants
> are generated by analysing module source imports).  The gm2 driver will
> add objects and libraries to the link.

in more detail the gm2 driver does the following:

  $ gm2 -v hello.mod

full output below, but to summarise and annotate:

cc1gm2 generates an assembler file from hello.mod
 as --64 /tmp/cc8BoL3d.s -o hello.o
 
 # gm2l generates a list of all dependent modules from parsing all imports
 /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/gm2l -v \
 -I/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim -o \
 /tmp/ccSMojUb.l hello.mod

 # gm2lorder reorders the critical runtime modules
 /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/gm2lorder \
/tmp/ccSMojUb.l -o /tmp/ccHDRdde.lst

 # gm2lgen generates a C++ scaffold from the reordered module list
 /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/gm2lgen -fcpp \
/tmp/ccHDRdde.lst -o a-hello_m2.cpp

 # cc1plus compiles the scaffold
 /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/cc1plus -v \
 -mtune=generic -march=x86-64 \
 -I/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim \
 -quiet a-hello_m2.cpp -o a-hello_m2.s
 as --64 a-hello_m2.s -o a-hello_m2.o

 # gm2lcc creates an archive from the list of modules and the scaffold
/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/gm2lcc \
  -L/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim \
  -ftarget-ar=/usr/bin/ar -ftarget-ranlib=/usr/bin/ranlib \
-fobject-path=/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim \
  --exec --startup a-hello_m2.o --ar -o /tmp/ccNJ60fa.a --mainobject \
  a-hello_m2.o /tmp/ccHDRdde.lst

/usr/bin/ar rc /tmp/ccNJ60fa.a  hello.o a-hello_m2.o
/usr/bin/ranlib /tmp/ccNJ60fa.a

# finally collect2 performs the link from the archive and any default
  libraries

hope this helps

regards,
Gaius






$ ~/opt/bin/gm2 -v hello.mod
Using built-in specs.
COLLECT_GCC=/home/gaius/opt/bin/gm2
COLLECT_LTO_WRAPPER=/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/gaius/GM2/graft-combine/gcc-git-devel-modula2/configure 
--prefix=/home/gaius/opt --libexecdir=/home/gaius/opt/lib 
--enable-threads=posix --enable-clocale=gnu --enable-languages=m2 
--enable-multilib --enable-checking --enable-long-longx --enable-bootstrap 
--with-build-config=bootstrap-Og
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220519 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-I/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim'
 '-ftarget-ar=/usr/bin/ar' '-ftarget-ranlib=/usr/bin/ranlib' 
'-fobject-path=/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim' 
'-x' 'modula-2' '-fplugin=m2rte' 
'-L/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim' 
'-L/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim' 
'-shared-libgcc' '-v' '-mtune=generic' '-march=x86-64' '-dumpdir' 'a-'
 /home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/cc1gm2 
-iplugindir=/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/plugin -quiet 
-dumpdir a- -dumpbase hello.mod -dumpbase-ext .mod -mtune=generic -march=x86-64 
-version -ftarget-ar=/usr/bin/ar -ftarget-ranlib=/usr/bin/ranlib 
-fobject-path=/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim 
-fplugin=m2rte -ftarget-ar=/usr/bin/ar -ftarget-ranlib=/usr/bin/ranlib 
-fobject-path=/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim 
-fplugin=m2rte -I/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim -o 
/tmp/cc8BoL3d.s hello.mod
GNU Modula-2  1.9.5  (20220520)
  grafted onto GCC 13.0.0
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv2: GNU GPL version 2 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
GNU Modula-2 (GCC) version 13.0.0 20220519 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 13.0.0 20220519 (experimental), GMP version 
6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Versions of loaded plugins:
 m2rte: Unknown version.
GNU Modula-2 (GCC) version 13.0.0 20220519 (experimental) (x86_64-pc-linux-gnu)
compiled by GNU C version 13.0.0 20220519 (experimental), GMP version 
6.2.1, MPFR version 4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Versions of loaded plugins:
 m2rte: Unknown version.
COLLECT_GCC_OPTIONS='-I/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m2/m2pim'
 '-ftarget-ar=/usr/bin/ar' '-ftarget-ranlib=/usr/bin/ranlib' 
'-fobject-path=/home/gaius/opt/lib/gcc/x86_64-pc-linux-gnu/13.0.0/m

[Bug tree-optimization/105679] erroneous -Warray-bounds warning with sanitizer

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

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

--- Comment #2 from Andrew Pinski  ---
This is jump threading due to the fsanitize=shift option.
With the irq argument to work changed to int from unsigned, the work function
is inlined. 

And then the check:
if (irq < 0 || irq >= ELEMENTS)
return;

works.

So I don't know how to solve this really.

[Bug c/105679] erroneous -Warray-bounds warning with sanitizer

[kees at outflux dot net via Gcc-bugs]

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

--- Comment #1 from Kees Cook  ---
The Linux kernel has encountered at least two of these (seen as specifically
"array subscript 32", though the root cause may be causing many others:

../drivers/net/wireless/ath/ath9k/mac.c:373:22: warning: array subscript 32 is
above array bounds of 'struct ath9k_tx_queue_info[10]' [-Warray-bounds]
../arch/x86/kvm/ioapic.c:213:33: warning: array subscript 32 is above array
bounds of 'union kvm_ioapic_redirect_entry[24]' [-Warray-bounds]

[Bug c/105679] New: erroneous -Warray-bounds warning with sanitizer

[kees at outflux dot net via Gcc-bugs]

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

Bug ID: 105679
   Summary: erroneous -Warray-bounds warning with sanitizer
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kees at outflux dot net
  Target Milestone: ---

Created attachment 53010
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53010=edit
test case minimized as much as possible

Some combination of things (likely triggered by -fsanitize=shift and an array
index being used with "<<" operator) is causing erroneous warnings about array
bounds accesses:

$ gcc -O2 -Warray-bounds -fno-strict-aliasing -fno-strict-overflow
-fsanitize=shift  -fsanitize-coverage=trace-pc -c -o /dev/null test.c
test.c: In function 'work.isra':
test.c:31:32: warning: array subscript 32 is above array bounds of 'struct
object[2]' [-Warray-bounds]
   31 | entry = instance->array[irq];
  | ~~~^
test.c:19:23: note: while referencing 'array'
   19 | struct object array[ELEMENTS];
  |   ^

Re: [RFC Linux patch] powerpc: add documentation for HWCAPs

[Nicholas Piggin via Gcc]

Excerpts from Paul E Murphy's message of May 21, 2022 12:21 am:
> 
> 
> On 5/20/22 12:15 AM, Nicholas Piggin via Gcc wrote:
>> This takes the arm64 file and adjusts it for powerpc. Feature
>> descriptions are vaguely handwaved by me.
>> ---
>> 
>> Anybody care to expand on or correct the meaning of these entries or
>> bikeshed the wording of the intro? Many of them are no longer used
>> anywhere by upstream kernels and even where they are it's not always
>> quite clear what the exact intent was, a lot of them are old history
>> and I don't know what or where they are used.
>> 
>> I may try to get these descriptions pushed into the ABI doc after a
>> time, but for now they can live in the kernel tree.
>> 
>> Thanks,
>> Nick
> 
> Thanks, this is really helpful.  I've been caught off-guard by some of 
> the subtleties in the meanings of these bits at times.  I think it would 
> be helpful to share what is implied by the usage of the word "facility" 
> below.  It would resolve some of my questions below.

Yeah that's probably a good point. In the introduction we can explain
that the facility is a class of instructions, registers, and behaviour,
but that the specifics depend on the ISA version.

> 
> 
> 
>> +PPC_FEATURE_HAS_ALTIVEC
>> +Vector (aka Altivec, VSX) facility is available.
> 
> I think "(aka Altivec, VSX)" might be more accurately stated as "(aka 
> Altivec)"?

Yes VSX is a thinkso, should be VMX as pointed out.

>> +PPC_FEATURE_HAS_DFP
>> +DFP facility is available.
> 
> Maybe something like "Decimal floating point instructions are available 
> to userspace.  Individual instruction availability is dependent on the
> reported architecture version."?

Yep, we can cover all these with a note in the intro.

>> +PPC_FEATURE_HAS_VSX
>> +VSX facility is available.
> A small reminder the features are also dependent on architecture version 
> too might be helpful here too.
> 
> 
>> +PPC_FEATURE2_TAR
>> +VSX facility is available.
> 
> Was manipulating the tar spr was once a privileged instruction, is this 
> a hint userspace can use the related instructions?

It can be disabled with facility control, and I guess there was
some consideration for how it might be used, e.g., "system software"
could use it for its own purpose then clear the bit for the application.

In practice I don't really know what makes use of this or whether
anything sanely can, it's marked reserved in the ABI. Would be 
interesting to know whether there is much benefit to use it in the
compiler. The kernel could actually use it for something nifty if we
were able to prevent userspace from accessing it entirely...

>> +
>> +PPC_FEATURE2_HAS_IEEE128
>> +IEEE 128 is available? What instructions/data?
> 
> Maybe something like "IEEE 128 binary floating point instructions are 
> supported.  Individual instruction availability is dependent on the
> reported architecture version."?

Right, I just didn't know what architectural class of instructions
those are. Is it just VSX in general or are there some specific
things we can name?

>> +PPC_FEATURE2_SCV
>> +scv instruction is available.
> 
> I think it might be clearer to say "This kernel supports syscalls using 
> the scv instruction".

Yeah good point.

>> +PPC_FEATURE2_MMA
>> +MMA facility is available.
> 
> Maybe another note that specific instruction availability may depend on 
> the reported architecture version?

Thanks,
Nick

[Bug target/105556] RA assigns an MMA vector input operand to vs0-vs31 causing an MMA accumulator to be spilled

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

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #6 from Peter Bergner  ---
Fixed on trunk and GCC 12.  At the moment, no need for GCC 11 or later
backports.

[Bug target/105556] RA assigns an MMA vector input operand to vs0-vs31 causing an MMA accumulator to be spilled

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

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

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

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

commit r12-8406-gc83d78585078d6918853fbe0f74a3a78e88e3e32
Author: Peter Bergner 
Date:   Tue May 17 21:09:29 2022 -0500

rs6000: Prefer assigning the MMA vector operands to altivec registers
[PR105556]

When optimizing the DGEMM kernel in OpenBLAS to use MMA, the MMA code
uses all 8 accumulators, which overlap all vs0-vs31 vector registers.
Current trunk assigns one of the normal vector inputs to one of the MMA
instructions, which forces us to spill one of the accumulators to memory,
leading to poor performance.  The solution here is to replace the "wa"
constraints for the vector input operands in the MMA instruction patterns
with "v,?wa" so that we prefer using the altivec registers vs32-vs63
over the vs0-vs31 registers.

2022-05-17  Peter Bergner  
Segher Boessenkool  

gcc/
PR target/105556
* config/rs6000/mma.md (mma_, mma_, mma_, mma_,
mma_, mma_, mma_, mma_,
mma_, mma_, mma_, mma_,
mma_, mma_): Replace "wa" constraints with
"v,?wa".
Update other operands accordingly.

(cherry picked from commit c6e36f05fbb081abb068958d8900ad34b303a70b)

gcc-11-20220520 is now available

[GCC Administrator via Gcc]

Snapshot gcc-11-20220520 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/11-20220520/
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 a935332c33861182a94b08426675fce971e4c3a3

You'll find:

 gcc-11-20220520.tar.xz   Complete GCC

  SHA256=726f27736231fac79b4129876069c1f1f2de3b56e5ea75758193319946c3ee52
  SHA1=6f852e210434ec461fb3bb2cc31d908b31167ba7

Diffs from 11-20220513 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.

RE: [EXTERNAL] Re: [PATCH] Guard against applying scale with 0 denominator

[Eugene Rozenfeld via Gcc-patches]

Thank you for the feedback Richard. I attached a patch that saves/restores 
counts if the epilog doesn't use a scalar loop.

Eugene

-Original Message-
From: Richard Biener  
Sent: Thursday, May 12, 2022 12:34 AM
To: Eugene Rozenfeld 
Cc: Jan Hubicka ; gcc-patches@gcc.gnu.org
Subject: Re: [EXTERNAL] Re: [PATCH] Guard against applying scale with 0 
denominator

On Thu, May 12, 2022 at 3:37 AM Eugene Rozenfeld 
 wrote:
>
> In my case this is not exactly what the FIXME in the comment above 
> says. The count is 0 even before the initial scaling happens. I hit this case 
> with some changes I'm working on to enable per-instruction discriminators for 
> AutoFDO.
>
> I looked into saving/restoring the old counts but it would be awkward to do. 
> The initial scaling happens here:
>
> if (skip_vector)
> {
>   split_edge (loop_preheader_edge (loop));
>
>   /* Due to the order in which we peel prolog and epilog, we first
>  propagate probability to the whole loop.  The purpose is to
>  avoid adjusting probabilities of both prolog and vector loops
>  separately.  Note in this case, the probability of epilog loop
>  needs to be scaled back later.  */
>   basic_block bb_before_loop = loop_preheader_edge (loop)->src;
>   if (prob_vector.initialized_p ())
> {
>   scale_bbs_frequencies (_before_loop, 1, prob_vector);
>   scale_loop_profile (loop, prob_vector, 0);
> }
> }
>
> The scaling happens before we do the cloning for the epilog so to 
> save/restore the counts we would need to maintain a mapping between the 
> original basic blocks and the cloned basic blocks in the epilog.

There is one already - after the epilogue is copied you can use get_bb_original 
(epilouge_bb) to get at the block it was copied from.
It could also be that we can rely on the basic-block order to be preserved 
between the copies (I _think_ that would work ... but then assert () for this 
using get_bb_original ()).  That means the simplest fix would be to have an 
auto_vec and initialize that from the BB counts in loop body order (we 
also have exactly two BBs in all peeled loops ...

But note we only scaled the scalar if-converted loop but eventually used the 
not if-coverted copy for the epilogue (if not vectorizing the epilogue), so 
indiscriminate scaling back looks wrong in some cases (I'd have to double-check 
the details here).

> I'd like to get my simple fix in since it makes things better even if 
> it doesn't address the issue mentioned In the FIXME.

But don't you need to check that
bbs[i]->count.apply_probability (prob_vector) is not zero instead of checking 
that bbs[i].count is not zero?

Richard.

> -Original Message-
> From: Richard Biener 
> Sent: Monday, May 09, 2022 12:42 AM
> To: Eugene Rozenfeld ; Jan Hubicka 
> 
> Cc: gcc-patches@gcc.gnu.org
> Subject: [EXTERNAL] Re: [PATCH] Guard against applying scale with 0 
> denominator
>
> On Fri, May 6, 2022 at 10:32 PM Eugene Rozenfeld via Gcc-patches 
>  wrote:
> >
> > Calling count.apply_scale with a 0 denominator causes an assert.
> > This change guards against that.
> >
> > Tested on x86_64-pc-linux-gnu.
> >
> > gcc/ChangeLog:
> > * tree-loop-vect-manip.cc (vect_do_peeling): Guard against applying 
> > scale with 0 denominator.
> > ---
> >  gcc/tree-vect-loop-manip.cc | 9 +
> >  1 file changed, 5 insertions(+), 4 deletions(-)
> >
> > diff --git a/gcc/tree-vect-loop-manip.cc 
> > b/gcc/tree-vect-loop-manip.cc index 1d4337eb261..db54ae69e45 100644
> > --- a/gcc/tree-vect-loop-manip.cc
> > +++ b/gcc/tree-vect-loop-manip.cc
> > @@ -2989,10 +2989,11 @@ vect_do_peeling (loop_vec_info loop_vinfo, tree 
> > niters, tree nitersm1,
> >  get lost if we scale down to 0.  */
> >   basic_block *bbs = get_loop_body (epilog);
> >   for (unsigned int i = 0; i < epilog->num_nodes; i++)
> > -   bbs[i]->count = bbs[i]->count.apply_scale
> > -(bbs[i]->count,
> > - bbs[i]->count.apply_probability
> > -   (prob_vector));
> > +   if (bbs[i]->count.nonzero_p ())
> > + bbs[i]->count = bbs[i]->count.apply_scale
> > +  (bbs[i]->count,
> > +   bbs[i]->count.apply_probability
> > + (prob_vector));
>
> So exactly what the FIXME in the comment above says happens.   It
> might be better
> to save/restore the old counts if the intent is to get them back.  I'm not 
> exactly sure where the other scaling happens though.
>
> Richard.
>
>
>
> >   free (bbs);
> > }
> >
> > --
> > 2.25.1


0001-Fix-profile-count-maintenance-in-vectorizer-peeling.patch
Description: 0001-Fix-profile-count-maintenance-in-vectorizer-peeling.patch

Re: Question on cgraph_edge::call_stmt during LTO

[Martin Jambor]

Hello,

On Fri, May 20 2022, Erick Ochoa via Gcc wrote:
> Hi,
>
> I'm working on a pass that looks into the estimated values during ipa-cp
> and stores them for a later analyses/pass. I would like to store the real
> arguments' estimates in a cgraph_edge::call_stmt or somewhere else that
> makes similar sense. (Note, this is different from the formal parameters'
> estimates which can be found in the lattice print out of ipa-cp).

the statement is not the right place to store such pass-specific
information, for reasons you described and more (especially simple
memory use efficiency).

Instead they should be placed into an "edge summary" (also sometimes
called "call summary"), a structure similar to ipa_edge_args_sum (in
ipa-prop.h and ipa-prop.cc).  Unlike ipa_edge_args_sum, which is
allocated at analysis phase, then streamed out and in in case of LTO,
and used thrown away during the IPA analysis phase, your summary would
need to be allocated at IPA analysis time, then streamed out in
ipcp_write_transformation_summaries, streamed in in
ipcp_read_transformation_summaries so that they can be used in the
transformation phase.

Usually a simple implementation of the duplication hook of an edge
summary is enough for the data to survive cloning and inlining and the
like.

Martin

[Bug middle-end/105629] [13 Regression] g++.dg/opt/pr94589-2.C for cris, m68k, s390x

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

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

--- Comment #5 from Hans-Peter Nilsson  ---
Additional observation: the diff is local to functions f5 and f17 (in
g++.dg/opt/pr94589-2.C), i.e. "reduced" to (for reference only):

A bool f5 (double i, double j) { auto c = i <=> j; return c >= 0; }
A bool f17 (double i) { auto c = i <=> 5.0; return c >= 0; }

Re: problem with Makefile.in generation in lingomp

[Mohamed Atef via Gcc]

The problem is fixed now.
Thanks.
Should i push again with the first change log

في الجمعة، ٢٠ مايو، ٢٠٢٢ ٩:٢٠ م Mohamed Atef 
كتب:

> I cloned he repo again but there is a problem here.
> This line is not in the previous repo.
>
> https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29
>
> في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٨ م Mohamed Atef 
> كتب:
>
>> I am really sorry.
>>
>> في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٨ م Mohamed Atef 
>> كتب:
>>
>>> In fact that's why i downloaded the repo again i forget to modify the
>>> copyright and when i tried to repush but i got an error As my branch is not
>>> updated i wanted delete the branch and create new one and push again.
>>> If you have the authority to remove the last batch please do.
>>>
>>> في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٢ م Jakub Jelinek  كتب:
>>>
 On Fri, May 20, 2022 at 11:53:36AM +0200, Mohamed Atef wrote:
 > I use 1.15.1.
 > This is the link to the line I mentioned.
 >
 https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29

 You shouldn't be running autoreconf, just automake to regenerate
 Makefile.in, and when I run it, it certainly doesn't emit that error.

 Anyway, can you explain the
 https://gcc.gnu.org/g:c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
 commit?  That makes the branch quite useless.
 The point is that all commits pushed to gcc trunk have to have proper
 ChangeLog in the commit log to describe the actual changes in that
 commit.
 Commits aren't allowed to be pushed there unless they satisfy the
 checking.
 On development branches this isn't checked on commits, but if those
 branches are meant to be usable for commits to trunk later, they need to
 follow those rules (as I said, git gcc-verify should check it).
 I suppose the 8b5ad311eac66b0939a1e6473a46f68e31158bfe commit might have
 passed it, but I don't see how c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
 could, you've used the same ChangeLog entry but that doesn't describe
 the changes you've done in that commit, you've reverted some Makefile.am
 changes (why?), removed the FSF Copyright lines (that is ok but it
 should
 have been replaced by the Copyright The GNU Toolchain Authors. line in
 that
 case), but the ChangeLog then would need to describe those changes.

 Jakub

[Bug libgcc/105669] DFP to HF (_Float16) conversions use incorrect rounding

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

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

Joseph S. Myers  changed:

   What|Removed |Added

   Last reconfirmed||2022-05-20
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Joseph S. Myers  ---
Example test illustrating this bug, at least on x86_64 (the DFP input is very
close to half way between two consecutive _Float16 values):

extern void exit (int);
extern void abort (void);
#define DCONST 7.340312e-5DF
static const _Float16 f1 = DCONST;
volatile _Decimal32 d = DCONST;
int
main (void)
{
  volatile _Float16 f2;
  f2 = d;
  if (f1 == f2)
exit (0);
  else
abort ();
}

[Bug fortran/105674] Wrong bounds for assumed rank pointer

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||wrong-code
   Last reconfirmed||2022-05-20
 Ever confirmed|0   |1

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.  All versions accepting assumed-rank (10+) are affected.

The lower bounds of the temporary are reset to the wrong value (0 instead of
1).

[Bug libstdc++/105678] Undefined reference to stacktrace standard library

[fcolecumberri at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from Francisco  ---
just tried

```bash
 g++ -std=gnu++2b -static-libstdc++ cpp_file.cpp
```

but same result.

[Bug libstdc++/105678] Undefined reference to stacktrace standard library

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

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

--- Comment #1 from Andrew Pinski  ---
I suspect it is missing from the linker script for versioning.
Using -static-libstdc++ should be a workaround.

Re: problem with Makefile.in generation in lingomp

[Mohamed Atef via Gcc]

I cloned he repo again but there is a problem here.
This line is not in the previous repo.
https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29

في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٨ م Mohamed Atef 
كتب:

> I am really sorry.
>
> في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٨ م Mohamed Atef 
> كتب:
>
>> In fact that's why i downloaded the repo again i forget to modify the
>> copyright and when i tried to repush but i got an error As my branch is not
>> updated i wanted delete the branch and create new one and push again.
>> If you have the authority to remove the last batch please do.
>>
>> في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٢ م Jakub Jelinek  كتب:
>>
>>> On Fri, May 20, 2022 at 11:53:36AM +0200, Mohamed Atef wrote:
>>> > I use 1.15.1.
>>> > This is the link to the line I mentioned.
>>> >
>>> https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29
>>>
>>> You shouldn't be running autoreconf, just automake to regenerate
>>> Makefile.in, and when I run it, it certainly doesn't emit that error.
>>>
>>> Anyway, can you explain the
>>> https://gcc.gnu.org/g:c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
>>> commit?  That makes the branch quite useless.
>>> The point is that all commits pushed to gcc trunk have to have proper
>>> ChangeLog in the commit log to describe the actual changes in that
>>> commit.
>>> Commits aren't allowed to be pushed there unless they satisfy the
>>> checking.
>>> On development branches this isn't checked on commits, but if those
>>> branches are meant to be usable for commits to trunk later, they need to
>>> follow those rules (as I said, git gcc-verify should check it).
>>> I suppose the 8b5ad311eac66b0939a1e6473a46f68e31158bfe commit might have
>>> passed it, but I don't see how c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
>>> could, you've used the same ChangeLog entry but that doesn't describe
>>> the changes you've done in that commit, you've reverted some Makefile.am
>>> changes (why?), removed the FSF Copyright lines (that is ok but it should
>>> have been replaced by the Copyright The GNU Toolchain Authors. line in
>>> that
>>> case), but the ChangeLog then would need to describe those changes.
>>>
>>> Jakub
>>>
>>>

Re: [PATCH] Add divide by zero side effect.

[Bernhard Reutner-Fischer via Gcc-patches]

On 20 May 2022 16:39:20 CEST, Segher Boessenkool  
wrote:
>On Fri, May 20, 2022 at 10:11:32AM +0200, Eric Botcazou wrote:
>> > I suggest 'deduce', 'deduction', 'deducing a range'. What the code is
>> > actually doing is deducing that 'b' in 'a / b' cannot be zero. Function in
>> > GCC might be called like 'deduce_ranges_from_stmt'.
>> 
>> Or "infer", "inference", "inferring a range".
>
>"Infer" is great here, yes!
>
>infer (verb):
>  deduce or conclude (something) from evidence and reasoning rather than
>  from explicit statements
>
>It has exactly the connotation wanted here, I would say.

Infer, deduct, refine
Sound all plausible, a native speaker should probably help decide the bikeshed 
:-)
thanks,

[Bug libstdc++/105678] New: Undefined reference to stacktrace standard library

[fcolecumberri at hotmail dot com via Gcc-bugs]

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

Bug ID: 105678
   Summary: Undefined reference to stacktrace standard library
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fcolecumberri at hotmail dot com
  Target Milestone: ---

I'm trying to test the stacktrace C++23 feature by creating the next program:

```c++
#include 

int main(){
std::stacktrace::current();
return 0;
}
```

using the next g++:

```
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/12.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /home/franky/Descargas/gcc-libs/src/gcc/configure
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-bootstrap
--prefix=/usr --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-linker-build-id --enable-lto
--enable-multilib --enable-plugin --enable-shared --enable-threads=posix
--disable-libssp --disable-libstdcxx-pch --disable-werror
--with-build-config=bootstrap-lto --enable-link-serialization=1
--enable-libstdcxx-backtrace=yes
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 12.1.0 (GCC)
```

Notice I added the `--enable-libstdcxx-backtrace=yes`

with this command:

```bash
g++ -std=gnu++2b cpp_file.cpp
```

And I get the next output:

```
/usr/bin/ld: a-cpp_file.o: in function `std::stacktrace_entry::_S_init()':
cpp_file.cpp:(.text._ZNSt16stacktrace_entry7_S_initEv[_ZNSt16stacktrace_entry7_S_initEv]+0x4a):
undefined reference to `__glibcxx_backtrace_create_state'
/usr/bin/ld: a-cpp_file.o: in function
`std::basic_stacktrace
>::current(std::allocator const&)':
cpp_file.cpp:(.text._ZNSt16basic_stacktraceISaISt16stacktrace_entryEE7currentERKS1_[_ZNSt16basic_stacktraceISaISt16stacktrace_entryEE7currentERKS1_]+0x70):
undefined reference to `__glibcxx_backtrace_simple'
collect2: error: ld returned 1 exit status
```

Maybe I am missing something, maybe the documentation is missing something, or
maybe this is still very experimental.

[PATCH] Support multilib-aware target lib flags self-specs overriding

[Alexandre Oliva via Gcc-patches]

This patch introduces -multiflags, short for multilib TFLAGS, as an
option that does nothing by default, but that can be added to TFLAGS
and mapped to useful options by driver self-specs.

I realize -m is reserved for machine-specific flags, which this option
sort-of isn't, but its intended use is indeed to stand for
machine-specific flags, so it's kind of ok.  But that's just my
official excuse, the reason I couldn't help picking it up is that it
is a portmanteau of multi[lib] and TFLAGS.

Regstrapped on x86_64-linux-gnu.  Ok to install?




Also tested with cross compilers configured to fail when missing
-multiflags, as suggested in the last paragraph in the added docs.

Tests to flag uses of the just-built compiler without -multiflags
required various workarounds.  Self-tests in GCC are compiled without
TFLAGS, so they'd fail if it weren't for a separate patchlet I'm
undecided about.  TFLAGS aren't used by gnattools or gotools either,
even when they are built with *_FOR_TARGET compilers, namely in native
builds, so those fail the above.  Another issue comes up when
bootstrapping: stages other than 1 use a just-built compiler to compile
for the target, in a way, but they don't use TFLAGS.

This brings about the philosophical/practical question of whether TFLAGS
is to apply to target libraries only, or to all compilations using the
just-built compiler, even those for host=target.  I can think of
arguments to support either choice.

I have changes that add TFLAGS for GCC self-tests, gnattools and gotools
(but not for bootstrap stages), and I'd be happy to proceed with them,
but I'd like to hear about any concerns or potential use cases for the
alternatives before proceeding with these changes.

Other possibilities that occurred to me were add a THFLAGS to the
top-level for host components that, in native builds, build with a
for-the-target just-built compiler (gnattools and gotools), or even get
the top level to pass _FOR_TARGET along with TFLAGS or THFLAGS
down as  to such host tools (and that or the previous stage's
TFLAGS when using the previous stage's compiler during bootstraps), like
it adds TFLAGS to  for target libs.




for  gcc/ChangeLog

* common.opt (multiflags): New.
* doc/invoke.texi: Document it.
* gcc.cc (driver_self_specs): Discard it.
* opts.cc (common_handle_option): Ignore it in the driver.
---
 gcc/common.opt  |4 
 gcc/doc/invoke.texi |   30 +-
 gcc/gcc.cc  |6 +-
 gcc/opts.cc |4 
 4 files changed, 42 insertions(+), 2 deletions(-)

diff --git a/gcc/common.opt b/gcc/common.opt
index 8a0dafc522d12..73b69ba3118e4 100644
--- a/gcc/common.opt
+++ b/gcc/common.opt
@@ -1786,6 +1786,10 @@ fif-conversion2
 Common Var(flag_if_conversion2) Optimization
 Perform conversion of conditional jumps to conditional execution.
 
+multiflags
+Common Driver
+Building block for specs-based multilib-aware TFLAGS.
+
 fstack-reuse=
 Common Joined RejectNegative Enum(stack_reuse_level) Var(flag_stack_reuse) 
Init(SR_ALL) Optimization
 -fstack-reuse=[all|named_vars|none]Set stack reuse level for local 
variables.
diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi
index 98a543ae06fda..0bd8d7b129612 100644
--- a/gcc/doc/invoke.texi
+++ b/gcc/doc/invoke.texi
@@ -727,7 +727,7 @@ Objective-C and Objective-C++ Dialects}.
 -fsel-sched-verbose  -fsel-sched-dump-cfg  -fsel-sched-pipelining-verbose @gol
 -fstats  -fstack-usage  -ftime-report  -ftime-report-details @gol
 -fvar-tracking-assignments-toggle  -gtoggle @gol
--print-file-name=@var{library}  -print-libgcc-file-name @gol
+-multiflags  -print-file-name=@var{library}  -print-libgcc-file-name @gol
 -print-multi-directory  -print-multi-lib  -print-multi-os-directory @gol
 -print-prog-name=@var{program}  -print-search-dirs  -Q @gol
 -print-sysroot  -print-sysroot-headers-suffix @gol
@@ -18870,6 +18870,34 @@ For example, with 
@option{-fdbg-cnt=dce:2-4:10-11,tail_call:10},
 eleventh invocation.
 For @code{dbg_cnt(tail_call)} true is returned for first 10 invocations.
 
+@item -multiflags
+@opindex multiflags
+This option enables multilib-aware @code{TFLAGS} to be used to build
+target libraries with options different from those the compiler is
+configured to use by default, through the use of specs (@xref{Spec
+Files}) set up by compiler internals, by the target, or by builders at
+configure time.
+
+Like @code{TFLAGS}, this allows the target libraries to be built for
+portable baseline environments, while the compiler defaults to more
+demanding ones.  That's useful because users can easily override the
+defaults the compiler is configured to use to build their own programs,
+if the defaults are not ideal for their target environment, whereas
+rebuilding the runtime libraries is usually not as easy or desirable.
+
+Unlike @code{TFLAGS}, the use of specs enables different flags to be
+selected for different multilibs.  The way to accomplish that is to
+build 

[Bug tree-optimization/105668] [13 Regression] ICE: in gimple_expand_vec_cond_expr, at gimple-isel.cc:281 with -O -ftracer -fno-tree-fre since r13-458-gd75d4293dcc029a7

[roger at nextmovesoftware dot com via Gcc-bugs]

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

Roger Sayle  changed:

   What|Removed |Added

 CC||roger at nextmovesoftware dot 
com

--- Comment #3 from Roger Sayle  ---
I suspect that the middle-end could be a bit more forgiving whilst expanding
vcond_mask.  If a target doesn't provide V1TImode, GCC can fall back to using
V2DImode, and if that isn't supported V4SImode, then V8HImode then V16QImode.
On x86-64, these all use the same vblendvb instruction or pand,pandn,por logic
(also known as V128BImode :-).

Re: [PATCH] Modula-2: merge proposal/review: 1/9 01.patch-set-01

[Gaius Mulley via Gcc-patches]

Richard Biener  writes:

> On Wed, May 18, 2022 at 3:47 PM Gaius Mulley via Gcc-patches
>  wrote:
>>
>> hello,
>>
>> this file is part-01 of the patch set for the gm2 review.

Hi Richard,

> I think you did a better job last time splitting the patches.

ah many apologies I should have annotated the diff and not split across
strict diffs and new file contents boundaries.  I should have included
gm2spec.cc in this patch set (rather than in 07.patch-set-05).

> This one contains the driver changes for which I have a hard time
> remembering the reason they exist and whether we already discussed it
> to death or not.

the changes do raise questions.  The reason for the changes here are to
allow easy linking for modula-2 users.

  $ gm2 hello.mod

for example will compile and link with all dependent modules (dependants
are generated by analysing module source imports).  The gm2 driver will
add objects and libraries to the link.

> So - with the chance to re-open and old discussion - what's special
> about modula-2 so it needs so many changes here?

Sure, the difference with modula-2 is that upon link it will generate a
scaffold program, compile the application module, compile scaffold and
link both in with all application dependants producing the final
executable.  It also needs the ability to insert include paths and link
paths for the appropriate dialect of modula-2 (although this causes
fewer changes).

But I take your point.  Perhaps it is better that gm2 follows say the C
approach of just compile a module?  Linking could be done using normal
link tools - (plus a few gm2tools for generating scaffold and finding
libraries etc).  Or a different approach?

One option is for me to rewrite the linking if required - I see merit -
not least the changes would have significantly less impact on the code
base.

> Are all of them necessary or are most of them merely "cleanups" that
> could be done as followup?

A few cleanups occurred when wishing to provide external access to the
routines.  For example the handle_opt_b function tidied up the OPT_B
case clause and also allowed gm2 to call fe_handle_opt_b but this could
certainly be done as a followup.

> Thanks,
> Richard.

For clarity here is the gm2spec.cc file from (07.patch-set-05):

regards,
Gaius


/* gm2spec.cc specific flags and argument handling within GNU Modula-2.

Copyright (C) 2007-2022 Free Software Foundation, Inc.
Contributed by Gaius Mulley .

This file is part of GNU Modula-2.

GNU Modula-2 is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 3, or (at your option)
any later version.

GNU Modula-2 is distributed in the hope that it will be useful, but
WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
General Public License for more details.

You should have received a copy of the GNU General Public License
along with GNU Modula-2; see the file COPYING3.  If not see
.  */

#include "config.h"
#include "system.h"
#include "coretypes.h"
#include "tm.h"
#include "xregex.h"
#include "obstack.h"
#include "intl.h"
#include "prefix.h"
#include "opt-suggestions.h"
#include "gcc.h"
#include "opts.h"
#include "vec.h"

#include "m2/gm2version.h"
#include "m2/gm2config.h"

#ifdef HAVE_DIRENT_H
#include 
#else
#ifdef HAVE_SYS_NDIR_H
#include 
#endif
#ifdef HAVE_SYS_DIR_H
#include 
#endif
#ifdef HAVE_NDIR_H
#include 
#endif
#endif

#ifndef MATH_LIBRARY
#define MATH_LIBRARY "m"
#endif

#ifndef LIBSTDCXX
#define LIBSTDCXX "stdc++"
#endif

#ifndef DIR_SEPARATOR
#define DIR_SEPARATOR '/'
#endif

/* Most every one is fine with LIBRARY_PATH.  For some, it conflicts.  */
#ifndef LIBRARY_PATH_ENV
#define LIBRARY_PATH_ENV "LIBRARY_PATH"
#endif

#ifndef GM2_PREFIX_ENV
#define GM2_PREFIX_ENV "GM2_PREFIX"
#endif

#ifndef GM2_LIBEXEC_ENV
#define GM2_LIBEXEC_ENV "GM2_LIBEXEC"
#endif

#ifndef GM2IPATH_ENV
#define GM2IPATH_ENV "GM2IPATH"
#endif

#ifndef GM2OPATH_ENV
#define GM2OPATH_ENV "GM2OPATH"
#endif

int lang_specific_extra_outfiles = 0;

/* DEBUGGING will print all the options at various stages with their
   error code, full name etc.  */
#undef DEBUGGING

/* LOCAL_DEBUGGING allows the compiler driver to automatically set a -B
   prefix (assuming one it not user supplied).  It sets the -Bprefix with
   the given path to argv[0].  This allows subprograms to be found in the
   build tree (without having to be installed).  It is only meant as an
   aid to development, not a user feature :-).  It allows developers to
   lazily type:  ./gm2 -c hello.c rather than ./gm2 -B./ -c hello.c
   or /somedirectory/development/build/gcc/gm2 -c hello.c.  */
#undef LOCAL_DEBUGGING

#define DEFAULT_DIALECT "pim"

typedef enum { iso, pim, min, logitech, pimcoroutine, maxlib } libs;

/* These are the library names which are installed as part of gm2 and reflect
   -flibs=name.  

[Bug c/105675] Segmentation fault

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WONTFIX
   Keywords||ice-on-valid-code

--- Comment #3 from Andrew Pinski  ---
This is a won't fix stitutation. 

You have & on a type repeated 237,679 times. 

With a recusive decent compiler, you run out of stack space with that many
times.
#17 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
parenthesized_p=, member_p=false, friend_p=false,
static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
#18 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
parenthesized_p=, member_p=false, friend_p=false,
static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
#19 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
parenthesized_p=, member_p=false, friend_p=false,
static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
#20 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
parenthesized_p=, member_p=false, friend_p=false,
static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
#21 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
parenthesized_p=, member_p=false, friend_p=false,
static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
#22 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
parenthesized_p=, member_p=false, friend_p=false,
static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
#23 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
parenthesized_p=, member_p=false, friend_p=false,
static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
#24 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
parenthesized_p=, member_p=false, friend_p=false,
static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
#25 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
parenthesized_p=, member_p=false, friend_p=false,
static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
#26 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
parenthesized_p=, member_p=false, friend_p=false,
static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
#27 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
parenthesized_p=, member_p=false, friend_p=false,
static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
#28 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
parenthesized_p=, member_p=false, friend_p=false,
static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
#29 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
parenthesized_p=, member_p=false, friend_p=false,
static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
#30 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
parenthesized_p=, member_p=false, friend_p=false,
static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
#31 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
parenthesized_p=, member_p=false, friend_p=false,
static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
#32 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,
dcl_kind=CP_PARSER_DECLARATOR_NAMED, flags=0, ctor_dtor_or_conv_p=0x0,
parenthesized_p=, member_p=false, friend_p=false,
static_p=false) at /home/apinski/src/upstream-gcc/gcc/gcc/cp/parser.cc:22948
#33 0x00b7c653 in cp_parser_declarator (parser=0x772bd7b8,

RE: [x86 PATCH] Some additional ix86_rtx_costs clean-ups: NEG, AND and pandn.

[Roger Sayle]

Hi Uros,
Many thanks for the review.  As requested here is a revised version of the
patch that's slightly more aggressive in its clean-ups (duplicating 6 lines
of code allowed me to eliminate 9 lines of code), but most significantly
also includes support for the andn for TARGET_BMI, and allows the NOT
operand of andn/pandn to appear as either the first or second operand
(combine/reload/output will swap them as appropriate).

Once again this patch has been tested on x86_64-pc-linux-gnu with 
make bootstrap and make -k check, with and without -m32, with no
new failures.  Ok for mainline?

2022-05-20  Roger Sayle  

gcc/ChangeLog
* config/i386/i386.cc (ix86_rtx_costs): Split AND from XOR/IOR.
Multi-word binary logic operations require two instructions.
For vector integer modes, AND with a NOT operand requires only
a single instruction (pandn).  Likewise, integer andn with -mbmi.
[NOT]: Vector integer NOT requires more than 1 instruction (pxor).
[NEG]: Multi-word negation requires 3 instructions.


Thanks in advance,
Roger

> -Original Message-
> From: Uros Bizjak 
> Sent: 19 May 2022 07:29
> To: Roger Sayle 
> Cc: gcc-patches@gcc.gnu.org
> Subject: Re: [x86 PATCH] Some additional ix86_rtx_costs clean-ups: NEG, AND
> and pandn.
> 
> On Wed, May 18, 2022 at 7:30 PM Roger Sayle
>  wrote:
> >
> >
> > Hi Uros,
> > Very many thanks for the speedy review and approval of my
> > ix86_rtx_costs patch to correct the cost of multi-word
> > multiplications.  In the same spirit, this patch tidies up a few additional 
> > nits I
> noticed while there:
> > Multi-word NOT requires two operations, but multi-word NEG requires
> > three operations.  Using SSE, vector NOT requires a pxor with -1, but
> > AND of NOT is cheap thanks to the existence of pandn.  There's also
> > some legacy (aka incorrect) logic explicitly testing for DImode
> > [independently of TARGET_64BIT] in determining the cost of logic
> > operations that's not required.
> >
> > There should be no behavioural changes from this patch (as confirmed
> > by
> > testing) but hopefully vectorization and other middle-end passes can
> > now rely on more sensible "cost" estimates.
> >
> > This patch has been tested on x86_64-pc-linux-gnu with make bootstrap
> > and make -k check, both with and without --target_board=unix{-m32},
> > with no new failures.  Ok for mainline?
> >
> >
> > 2022-05-18  Roger Sayle  
> >
> > gcc/ChangeLog
> > * config/i386/i386.cc (ix86_rtx_costs): Split AND from XOR/IOR.
> > Multi-word binary logic operations require two instructions.
> > For vector integer modes, AND with a NOT operand requires only
> > a single instruction (pandn).
> > [NOT]: Vector integer NOT requires more than 1 instruction (pxor).
> > [NEG]: Multi-word negation requires 3 instructions.
> 
> -case AND:
>  case IOR:
>  case XOR:
>if (GET_MODE_CLASS (mode) == MODE_INT
>&& GET_MODE_SIZE (mode) > UNITS_PER_WORD)
>  {
> -  *total = (cost->add * 2
> -+ (rtx_cost (XEXP (x, 0), mode, outer_code, opno, speed)
> -   << (GET_MODE (XEXP (x, 0)) != DImode))
> -+ (rtx_cost (XEXP (x, 1), mode, outer_code, opno, speed)
> -   << (GET_MODE (XEXP (x, 1)) != DImode)));
> +  *total = cost->add * 2
> +   + rtx_cost (XEXP (x, 0), mode, outer_code, opno, speed)
> +   + rtx_cost (XEXP (x, 1), mode, outer_code, opno, speed);
> +  return true;
> +}
> +  else if (GET_MODE_CLASS (mode) == MODE_VECTOR_INT)
> +*total = ix86_vec_cost (mode, cost->sse_op);
> +  else if (GET_MODE_SIZE (mode) > UNITS_PER_WORD)
> +*total = cost->add * 2;
> +  else
> +*total = cost->add;
> +  return false;
> 
> Shouldn't this be just:
> 
> if (GET_MODE_CLASS (mode) == MODE_VECTOR_INT)
>   *total = ix86_vec_cost (mode, cost->sse_op); else if (GET_MODE_SIZE (mode)
> > UNITS_PER_WORD)
>   *total = cost->add * 2;
> else
>   *total = cost->add;
> return false;
> 
> When returning false, subexpressions will be scanned automatically.
> 
> +  else if (GET_MODE_CLASS (mode) == MODE_VECTOR_INT)
> +{
> +  /* pandn is a single instruction.  */
> +  if (GET_CODE (XEXP (x, 0)) == NOT)
> 
> pandn is also a single instruction with BMI.  IMO, this should be also 
> reflected in
> RTX costs.
> 
> Uros.
diff --git a/gcc/config/i386/i386.cc b/gcc/config/i386/i386.cc
index 30a9cd0..daa60ac 100644
--- a/gcc/config/i386/i386.cc
+++ b/gcc/config/i386/i386.cc
@@ -20738,70 +20738,125 @@ ix86_rtx_costs (rtx x, machine_mode mode, int 
outer_code_i, int opno,
}
 
   if (SSE_FLOAT_MODE_SSEMATH_OR_HF_P (mode))
-   {
- *total = cost->addss;
- return false;
-   }
+   *total = cost->addss;
   else if (X87_FLOAT_MODE_P (mode))
-   {
- *total = cost->fadd;
- return false;
-   }
+   *total = cost->fadd;
   else if 

[Bug c++/105675] Segmentation fault

[watarai775 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Ruslan Mkoyan  ---
Created attachment 53009
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53009=edit
Input file

[Bug tree-optimization/105677] Calling strlen on a string constant is optimized out, but calling wcslen on a string constant is not

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
GCC does not optimize any of the wide character functions ...

[Bug tree-optimization/105677] New: Calling strlen on a string constant is optimized out, but calling wcslen on a string constant is not

[alexhenrie24 at gmail dot com via Gcc-bugs]

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

Bug ID: 105677
   Summary: Calling strlen on a string constant is optimized out,
but calling wcslen on a string constant is not
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexhenrie24 at gmail dot com
  Target Milestone: ---

strlen example, source code:

#include 

int main()
{
return strlen("Hello world!");
}

strlen example, assembly code at -O3:

movl$12, %eax
ret

wcslen example, source code:

#include 

int main()
{
return wcslen(L"Hello world!");
}

wcslen example, assembly code at -O3:

subq$8, %rsp
.cfi_def_cfa_offset 16
leaq.LC0(%rip), %rdi
callwcslen@PLT
addq$8, %rsp
.cfi_def_cfa_offset 8
ret

Interestingly, Clang produces identical assembly code for both examples, which
is what I expected GCC to do.

[Bug target/61810] init-regs.c papers over issues elsewhere

[hjl.tools at gmail dot com via Gcc-bugs]

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

--- Comment #9 from H.J. Lu  ---
Created attachment 53008
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53008=edit
A patch for pr104441-1a.c

Does it help?

[Bug target/105670] [x86] suboptimal code for branch over two bools

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug target/105670] [x86] suboptimal code for branch over two bools

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-05-20
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Gimple level is good:
  _7 = a_2(D) & b_3(D);
  if (_7 != 0)
goto ; [50.00%]
  else
goto ; [50.00%]

But at expand it changes the above to:
(insn 11 10 12 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:QI 83 [ a ])
(const_int 0 [0]))) "/app/example.cpp":2:3 -1
 (nil))

(jump_insn 12 11 13 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 0)
(pc))) "/app/example.cpp":2:3 -1
 (int_list:REG_BR_PROB 268435460 (nil)))

(insn 13 12 14 (set (reg:CCZ 17 flags)
(compare:CCZ (reg/v:QI 85 [ b ])
(const_int 0 [0]))) "/app/example.cpp":2:3 -1
 (nil))

(jump_insn 14 13 0 (set (pc)
(if_then_else (eq (reg:CCZ 17 flags)
(const_int 0 [0]))
(label_ref 0)
(pc))) "/app/example.cpp":2:3 -1
 (int_list:REG_BR_PROB 357913948 (nil)))


I noticed LLVM does the same as GCC here ...
While ICC does the one test.

[Bug c/105675] Segmentation fault

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2022-05-20

--- Comment #1 from Andrew Pinski  ---
>Running gcc on input file from an attachment resulting in segmentation fault

The file didn't attach, maybe it was too big. Can you try to compress it and
attach that?

[Bug target/105493] [12/13 Regression] x86_64 538.imagick_r 6% regressions and 2% 525.x264_r regressions on Alder Lake after r12-7319-g90d693bdc9d718

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

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

--- Comment #5 from Martin Jambor  ---
I can confirm that an Intel Cascade Lake Xeon, using -Ofast -flto
-march=native, 538.imagick_r produced by GCC 12.1 is almost 20% slower
than the benchmark built with GCC 11.2 and the same options (on Zen2
or 3 I can see only smaller regressios at -O2 and with PGO)

I do not see the 525.x264_r regression using the same compilers and
options on this machine.

[Bug ipa/105676] [12/13 Regression] Bogus `-Wsuggest-attribute=pure` on function marked `__attribute__((const))`

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-05-20
 Status|UNCONFIRMED |NEW
  Known to fail||12.1.0
  Known to work||11.2.0, 11.3.0
 Ever confirmed|0   |1
   Target Milestone|--- |12.2
Summary|Bogus   |[12/13 Regression] Bogus
   |`-Wsuggest-attribute=pure`  |`-Wsuggest-attribute=pure`
   |on function marked  |on function marked
   |`__attribute__((const))`|`__attribute__((const))`

--- Comment #1 from Andrew Pinski  ---
Confirmed.

[Bug target/105275] 525.x264_r and 538.imagick_r regressed on x86_64 at -O2 with PGO after r12-7319-g90d693bdc9d718

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

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

--- Comment #1 from Martin Jambor  ---
Confirmed with GCC 12.1 numbers.

[Bug c/105676] New: Bogus `-Wsuggest-attribute=pure` on function marked `__attribute__((const))`

[sagebar at web dot de via Gcc-bugs]

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

Bug ID: 105676
   Summary: Bogus `-Wsuggest-attribute=pure` on function marked
`__attribute__((const))`
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sagebar at web dot de
  Target Milestone: ---

When compiling with `-Wsuggest-attribute=pure`, gcc warns about missing
`__attribute__((pure))` on functions declared as `__attribute__((const))`.

It is common knowledge that any function marked as `__attribute__((const))`
also implicitly has the behavior of a function marked as
`__attribute__((pure))` (const implies pure).

Therefor, it stands to reason that such a warning is bogus (also: earlier
version of gcc didn't emit a warning in this case; know: gcc-9 already
supported these warnings, but didn't emit `-Wsuggest-attribute=pure` on a
`__attribute__((const))` function).

Example (`gcc -Wsuggest-attribute=pure -c -O2 input.c`):

```
__attribute__((const))
extern int do_expensive_calculation(void);

__attribute__((const))
int getval(void) {
static int cache = -1;
if (cache == -1)
cache = do_expensive_calculation();
return cache;
}
```

>test.c: In function 'getval':
>test.c:5:5: warning: function might be candidate for attribute 'pure' 
>>[-Wsuggest-attribute=pure]
>5 | int getval(void) {
>  | ^~

When trying to declare as both pure+const:
>test.c:5:1: warning: ignoring attribute 'const' because it conflicts with 
>attribute 'pure' [-Wattributes]
>5 | int getval(void) {
>  | ^~~


 Explaination of why using `__attribute__((const))` is valid here 

I see why gcc might think that `getval()` is *only* `pure`, but there is
nothing wrong with the `__attribute__((const))` annotation since we don't "read
global memory" (emphasis on the "global"), and thus don't depend on the global
state (also: what counts as "global" vs. "non-global" isn't something that can
be quantified. - It depends on the application and how memory is used).

As such, the use of `__attribute__((const))` is very much valid (and gcc might
even consider suggesting `__attribute__((const))` instead of
`__attribute__((pure))`, since because `cache` is scoped-static, it not being
used outside of `getval()` can actually be proven, though that isn't what this
bug report is about...). However, so-long as it believes that the function is
pure, there is no reason to ever emit a about that fact so-long as `getval()`
remains annotated as `__attribute__((const))`.

 End of Explaination 

Re: [RFC Linux patch] powerpc: add documentation for HWCAPs

[Segher Boessenkool]

On Fri, May 20, 2022 at 09:21:43AM -0500, Paul E Murphy wrote:
> >+PPC_FEATURE_HAS_ALTIVEC
> >+Vector (aka Altivec, VSX) facility is available.
> 
> I think "(aka Altivec, VSX)" might be more accurately stated as "(aka 
> Altivec)"?

"Also known as AltiVec or VMX", yes.

> >+PPC_FEATURE_HAS_DFP
> >+DFP facility is available.
> 
> Maybe something like "Decimal floating point instructions are available 
> to userspace.  Individual instruction availability is dependent on the
> reported architecture version."?

That is true for *all* facilities, and even the base architecture!  This
is not only hypothetical, either.


Segher

Re: [RFC Linux patch] powerpc: add documentation for HWCAPs

[Peter Bergner via Gcc]

On 5/20/22 12:15 AM, Nicholas Piggin via Gcc wrote:
> +PPC_FEATURE_HAS_ALTIVEC
> +Vector (aka Altivec, VSX) facility is available.

Slight typo.  s/VSX/VMX/


Peter

[Bug c/105675] New: Segmentation fault

[watarai775 at gmail dot com via Gcc-bugs]

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

Bug ID: 105675
   Summary: Segmentation fault
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: watarai775 at gmail dot com
  Target Milestone: ---

Running gcc on input file from an attachment resulting in segmentation fault

gcc-12 1.cpp

gcc-12: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

[Bug libstdc++/105673] _M_futex_wait_until_steady() always falls back to old syscall with FUTEX_WAIT operation even after successful FUTEX_WAIT_BITSET

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-05-20

--- Comment #1 from Jonathan Wakely  ---
Good catch, thanks.

Re: problem with Makefile.in generation in lingomp

[Mohamed Atef via Gcc]

I am really sorry.

في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٨ م Mohamed Atef 
كتب:

> In fact that's why i downloaded the repo again i forget to modify the
> copyright and when i tried to repush but i got an error As my branch is not
> updated i wanted delete the branch and create new one and push again.
> If you have the authority to remove the last batch please do.
>
> في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٢ م Jakub Jelinek  كتب:
>
>> On Fri, May 20, 2022 at 11:53:36AM +0200, Mohamed Atef wrote:
>> > I use 1.15.1.
>> > This is the link to the line I mentioned.
>> >
>> https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29
>>
>> You shouldn't be running autoreconf, just automake to regenerate
>> Makefile.in, and when I run it, it certainly doesn't emit that error.
>>
>> Anyway, can you explain the
>> https://gcc.gnu.org/g:c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
>> commit?  That makes the branch quite useless.
>> The point is that all commits pushed to gcc trunk have to have proper
>> ChangeLog in the commit log to describe the actual changes in that commit.
>> Commits aren't allowed to be pushed there unless they satisfy the
>> checking.
>> On development branches this isn't checked on commits, but if those
>> branches are meant to be usable for commits to trunk later, they need to
>> follow those rules (as I said, git gcc-verify should check it).
>> I suppose the 8b5ad311eac66b0939a1e6473a46f68e31158bfe commit might have
>> passed it, but I don't see how c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
>> could, you've used the same ChangeLog entry but that doesn't describe
>> the changes you've done in that commit, you've reverted some Makefile.am
>> changes (why?), removed the FSF Copyright lines (that is ok but it should
>> have been replaced by the Copyright The GNU Toolchain Authors. line in
>> that
>> case), but the ChangeLog then would need to describe those changes.
>>
>> Jakub
>>
>>

Re: problem with Makefile.in generation in lingomp

[Mohamed Atef via Gcc]

In fact that's why i downloaded the repo again i forget to modify the
copyright and when i tried to repush but i got an error As my branch is not
updated i wanted delete the branch and create new one and push again.
If you have the authority to remove the last batch please do.

في الجمعة، ٢٠ مايو، ٢٠٢٢ ٥:٥٢ م Jakub Jelinek  كتب:

> On Fri, May 20, 2022 at 11:53:36AM +0200, Mohamed Atef wrote:
> > I use 1.15.1.
> > This is the link to the line I mentioned.
> >
> https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29
>
> You shouldn't be running autoreconf, just automake to regenerate
> Makefile.in, and when I run it, it certainly doesn't emit that error.
>
> Anyway, can you explain the
> https://gcc.gnu.org/g:c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
> commit?  That makes the branch quite useless.
> The point is that all commits pushed to gcc trunk have to have proper
> ChangeLog in the commit log to describe the actual changes in that commit.
> Commits aren't allowed to be pushed there unless they satisfy the checking.
> On development branches this isn't checked on commits, but if those
> branches are meant to be usable for commits to trunk later, they need to
> follow those rules (as I said, git gcc-verify should check it).
> I suppose the 8b5ad311eac66b0939a1e6473a46f68e31158bfe commit might have
> passed it, but I don't see how c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
> could, you've used the same ChangeLog entry but that doesn't describe
> the changes you've done in that commit, you've reverted some Makefile.am
> changes (why?), removed the FSF Copyright lines (that is ok but it should
> have been replaced by the Copyright The GNU Toolchain Authors. line in that
> case), but the ChangeLog then would need to describe those changes.
>
> Jakub
>
>

[Bug fortran/105674] New: Wrong bounds for assumed rank pointer

[martin.diehl at kuleuven dot be via Gcc-bugs]

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

Bug ID: 105674
   Summary: Wrong bounds for assumed rank pointer
   Product: gcc
   Version: 12.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: martin.diehl at kuleuven dot be
  Target Milestone: ---

Created attachment 53007
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53007=edit
small reproducer

When using a pointer with striding, the ranks in a rank selector are wrong
(0-based instead of 1-based).
In the following program, lbound/lbound differ between 'strided' '(strided)'.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89364 and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94070 seem to be related.



The example is also attached as a file.


program test


  integer, dimension(2,2), target :: dim_2  
  integer, dimension(product(shape(dim_2))), target :: dim_1
  integer, dimension(:,:), pointer :: strided   
  integer :: i  

  dim_1 = [(i,i=1,size(dim_1,1))]   
  dim_2 = reshape(dim_1,shape(dim_2))   

  strided => dim_2(1:1,:)   
  print*, 'lbound', lbound(strided) 
  print*, 'ubound', ubound(strided) 

  call assumed_rank(dim_1)  
  call assumed_rank(dim_2)  
  call assumed_rank(strided)
  call assumed_rank((strided))  

  contains  

  subroutine assumed_rank(dataset)  

integer,  intent(in), dimension(..) :: dataset  

select rank(dataset)
  rank(1)   
print*, 'rank 1'
print*, 'lbound', lbound(dataset), 'ubound', ubound(dataset)
print*, dataset 
  rank(2)   
print*, 'rank 2', dataset   
print*, 'lbound', lbound(dataset), 'ubound', ubound(dataset)
end select  

print*, ''  

  end subroutine assumed_rank   

end program test

Re: problem with Makefile.in generation in lingomp

[Jakub Jelinek via Gcc]

On Fri, May 20, 2022 at 11:53:36AM +0200, Mohamed Atef wrote:
> I use 1.15.1.
> This is the link to the line I mentioned.
> https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29

You shouldn't be running autoreconf, just automake to regenerate
Makefile.in, and when I run it, it certainly doesn't emit that error.

Anyway, can you explain the
https://gcc.gnu.org/g:c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
commit?  That makes the branch quite useless.
The point is that all commits pushed to gcc trunk have to have proper
ChangeLog in the commit log to describe the actual changes in that commit.
Commits aren't allowed to be pushed there unless they satisfy the checking.
On development branches this isn't checked on commits, but if those
branches are meant to be usable for commits to trunk later, they need to
follow those rules (as I said, git gcc-verify should check it).
I suppose the 8b5ad311eac66b0939a1e6473a46f68e31158bfe commit might have
passed it, but I don't see how c7a99c5953487c4dd6cdce1b01126ac2b06f16cd
could, you've used the same ChangeLog entry but that doesn't describe
the changes you've done in that commit, you've reverted some Makefile.am
changes (why?), removed the FSF Copyright lines (that is ok but it should
have been replaced by the Copyright The GNU Toolchain Authors. line in that
case), but the ChangeLog then would need to describe those changes.

Jakub

[Bug tree-optimization/102844] [9/10/11/12/13 Regression] DOM jump threading not copying block that became non-empty

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

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

--- Comment #28 from Aldy Hernandez  ---
(In reply to Jeffrey A. Law from comment #27)
> We're not using the backward threader to replace DOM's threader yet.  I've
> got a TODO to push on Aldy's patch, but haven't been able to get to it over
> the last couple weeks.  It's an, umm, busy time for us right now.
> 
> There's really only one issue we need to hash out in Aldy's work and there's
> a couple proposed workarounds/interm solutions on our way to removing both
> the forward threader and DOM itself.

And even that patch does not replace the forward threader.  It is a hybrid
approach using the forward threader, but the ranger path solver (instead of
evrp).  The forward threader should be with us until ranger can do floats and
pointers later this season.

[Bug libstdc++/105673] New: _M_futex_wait_until_steady() always falls back to old syscall with FUTEX_WAIT operation even after successful FUTEX_WAIT_BITSET

[vlad at solidsands dot nl via Gcc-bugs]

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

Bug ID: 105673
   Summary: _M_futex_wait_until_steady() always falls back to old
syscall with FUTEX_WAIT operation even after
successful FUTEX_WAIT_BITSET
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vlad at solidsands dot nl
  Target Milestone: ---

We were doing coverage analysis of GNU libstdc++ library and noticed that in
the function _M_futex_wait_until_steady() (src/c++11/futex.cc) the second part
of the function is always executed even though the FUTEX_WAIT_BITSET syscall is
available on the system.

How to reproduce:
auto f = std::async(std::launch::async, foo);
const auto start{std::chrono::steady_clock::now()};
auto status = f.wait_until(start + std::chrono::seconds{5});

We suspect the reason might be because the if statement on line 217 is missing
an else branch.
(https://gcc.gnu.org/git?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/src/c%2B%2B11/futex.cc;h=4d56c286ec597c19e4dc20bfb0c82d03ee93da8d;hb=HEAD#l217)
The sibling function _M_futex_wait_until() does have an else branch for similar
if statement. Without the else branch if futex syscall was successful the
function still falls back to the alternative version and performs another futex
syscall.

[Bug tree-optimization/102844] [9/10/11/12/13 Regression] DOM jump threading not copying block that became non-empty

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

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

--- Comment #27 from Jeffrey A. Law  ---
We're not using the backward threader to replace DOM's threader yet.  I've got
a TODO to push on Aldy's patch, but haven't been able to get to it over the
last couple weeks.  It's an, umm, busy time for us right now.

There's really only one issue we need to hash out in Aldy's work and there's a
couple proposed workarounds/interm solutions on our way to removing both the
forward threader and DOM itself.

Re: [PATCH] libstdc++-v3: Set 26_numerics/random/n.b.d./op./values.cc timeout-factor to 3

[Jonathan Wakely via Gcc-patches]

On Fri, 20 May 2022 at 15:31, Hans-Peter Nilsson wrote:
>
> > From: Jonathan Wakely 
> > Date: Fri, 20 May 2022 11:03:40 +0200
>
> > > Ok to commit (without renaming)?
> >
> > I'm OK with the timeout factor, but we could also solve it differently
> > so that it doesn't take nearly 5 minutes, as in the attached patch.
> > The testDiscreteDist function can be parametrized with the number of
> > iterations to perform. Would you rather do that?
>
> Yes thanks, down from 4m39s to 2.7 seconds, so very much
> preferable!

Nice, thanks for testing it.

> (To the skeptics: the coverage intended with the test, is
> IMHO reached with all non-simulator targets also running
> this.  Nothing target-dependent here.)

Indeed.

> Also in line with many other depth-level-cousin test-files
> named value.cc.  Still many more others seem to be
> candidates for such pruning, judging by the time it takes
> for a 'RUNTESTFLAGS=--target_board=cris-sim\
> conformance.exp=values.cc' to get to *that* values.cc.
>
> Though, some -DSIMULATOR_TEST-adjusted files use dg-options,
> others dg-additional-options.  It seems the difference is
> that by using dg-options, you lose "-include bits/stdc++.h".
> Likely not intended.  If so, should Someone fix that by
> preapproval but regtested?

Ah good point. I've pushed the attached patch now. This adjusts the
values.cc files for some other distributions, and does so using
dg-additional-options not dg-options. Feel free to change existing
(mis)uses of dg-options to be dg-additional-options.

I've tested it on x86_64-linux, normally and also with
-DSIMULATOR_TEST in the test flags, just to ensure I didn't introduce
a silly syntax error for that case. I haven't tested it on a real sim
though.
commit e3b8b4f7814c54543d9b7ea3ee8cf2cb9cff351d
Author: Jonathan Wakely 
Date:   Fri May 20 15:44:25 2022

libstdc++: Reduce  test iterations for simulators

Some of these tests take several minutes on a simulator like cris-elf,
so we can conditionally run fewer iterations. The testDiscreteDist
helper already supports custom sizes so we just need to make use of that
when { target simulator } matches.

The relevant code is sufficiently tested on other targets, so we're not
losing anything by only running a small number of iterators for sims.

libstdc++-v3/ChangeLog:

* 
testsuite/26_numerics/random/bernoulli_distribution/operators/values.cc:
Run fewer iterations for simulator targets.
* 
testsuite/26_numerics/random/binomial_distribution/operators/values.cc:
Likewise.
* 
testsuite/26_numerics/random/discrete_distribution/operators/values.cc:
Likewise.
* 
testsuite/26_numerics/random/geometric_distribution/operators/values.cc:
Likewise.
* 
testsuite/26_numerics/random/negative_binomial_distribution/operators/values.cc:
Likewise.
* 
testsuite/26_numerics/random/poisson_distribution/operators/values.cc:
Likewise.
* 
testsuite/26_numerics/random/uniform_int_distribution/operators/values.cc:
Likewise.

diff --git 
a/libstdc++-v3/testsuite/26_numerics/random/bernoulli_distribution/operators/values.cc
 
b/libstdc++-v3/testsuite/26_numerics/random/bernoulli_distribution/operators/values.cc
index 4100692981c..b2cb86f976b 100644
--- 
a/libstdc++-v3/testsuite/26_numerics/random/bernoulli_distribution/operators/values.cc
+++ 
b/libstdc++-v3/testsuite/26_numerics/random/bernoulli_distribution/operators/values.cc
@@ -24,6 +24,14 @@
 #include 
 #include 
 
+// { dg-additional-options "-DSIMULATOR_TEST" { target simulator } }
+
+#ifdef SIMULATOR_TEST
+# define ARGS 100, 1000
+#else
+# define ARGS
+#endif
+
 void test01()
 {
   using namespace __gnu_test;
@@ -32,15 +40,15 @@ void test01()
 
   std::bernoulli_distribution bd1(0.25);
   auto bbd1 = std::bind(bd1, eng);
-  testDiscreteDist(bbd1, [](int n) { return bernoulli_pdf(n, 0.25); } );
+  testDiscreteDist(bbd1, [](int n) { return bernoulli_pdf(n, 0.25); } );
 
   std::bernoulli_distribution bd2(0.5);
   auto bbd2 = std::bind(bd2, eng);
-  testDiscreteDist(bbd2, [](int n) { return bernoulli_pdf(n, 0.5); } );
+  testDiscreteDist(bbd2, [](int n) { return bernoulli_pdf(n, 0.5); } );
 
   std::bernoulli_distribution bd3(0.75);
   auto bbd3 = std::bind(bd3, eng);
-  testDiscreteDist(bbd3, [](int n) { return bernoulli_pdf(n, 0.75); } );
+  testDiscreteDist(bbd3, [](int n) { return bernoulli_pdf(n, 0.75); } );
 }
 
 int main()
diff --git 
a/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc
 
b/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc
index 96570d59fb3..efa259b7e03 100644
--- 
a/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc
+++ 
b/libstdc++-v3/testsuite/26_numerics/random/binomial_distribution/operators/values.cc
@@ -25,6 +25,14 @@
 #include 
 #include 
 

Re: [PATCH] Add divide by zero side effect.

[Segher Boessenkool]

On Fri, May 20, 2022 at 10:11:32AM +0200, Eric Botcazou wrote:
> > I suggest 'deduce', 'deduction', 'deducing a range'. What the code is
> > actually doing is deducing that 'b' in 'a / b' cannot be zero. Function in
> > GCC might be called like 'deduce_ranges_from_stmt'.
> 
> Or "infer", "inference", "inferring a range".

"Infer" is great here, yes!

infer (verb):
  deduce or conclude (something) from evidence and reasoning rather than
  from explicit statements

It has exactly the connotation wanted here, I would say.


Segher

Re: [PATCH] libstdc++-v3: Set 26_numerics/random/n.b.d./op./values.cc timeout-factor to 3

[Hans-Peter Nilsson via Gcc-patches]

> From: Jonathan Wakely 
> Date: Fri, 20 May 2022 11:03:40 +0200

> > Ok to commit (without renaming)?
> 
> I'm OK with the timeout factor, but we could also solve it differently
> so that it doesn't take nearly 5 minutes, as in the attached patch.
> The testDiscreteDist function can be parametrized with the number of
> iterations to perform. Would you rather do that?

Yes thanks, down from 4m39s to 2.7 seconds, so very much
preferable!

(To the skeptics: the coverage intended with the test, is
IMHO reached with all non-simulator targets also running
this.  Nothing target-dependent here.)

Also in line with many other depth-level-cousin test-files
named value.cc.  Still many more others seem to be
candidates for such pruning, judging by the time it takes
for a 'RUNTESTFLAGS=--target_board=cris-sim\
conformance.exp=values.cc' to get to *that* values.cc.

Though, some -DSIMULATOR_TEST-adjusted files use dg-options,
others dg-additional-options.  It seems the difference is
that by using dg-options, you lose "-include bits/stdc++.h".
Likely not intended.  If so, should Someone fix that by
preapproval but regtested?

brgds, H-P

Re: [RFC Linux patch] powerpc: add documentation for HWCAPs

[Paul E Murphy via Gcc]

On 5/20/22 12:15 AM, Nicholas Piggin via Gcc wrote:

This takes the arm64 file and adjusts it for powerpc. Feature
descriptions are vaguely handwaved by me.
---

Anybody care to expand on or correct the meaning of these entries or
bikeshed the wording of the intro? Many of them are no longer used
anywhere by upstream kernels and even where they are it's not always
quite clear what the exact intent was, a lot of them are old history
and I don't know what or where they are used.

I may try to get these descriptions pushed into the ABI doc after a
time, but for now they can live in the kernel tree.

Thanks,
Nick


Thanks, this is really helpful.  I've been caught off-guard by some of 
the subtleties in the meanings of these bits at times.  I think it would 
be helpful to share what is implied by the usage of the word "facility" 
below.  It would resolve some of my questions below.





+PPC_FEATURE_HAS_ALTIVEC
+Vector (aka Altivec, VSX) facility is available.


I think "(aka Altivec, VSX)" might be more accurately stated as "(aka 
Altivec)"?




+PPC_FEATURE_HAS_DFP
+DFP facility is available.


Maybe something like "Decimal floating point instructions are available 
to userspace.  Individual instruction availability is dependent on the

reported architecture version."?



+PPC_FEATURE_HAS_VSX
+VSX facility is available.
A small reminder the features are also dependent on architecture version 
too might be helpful here too.




+PPC_FEATURE2_TAR
+VSX facility is available.


Was manipulating the tar spr was once a privileged instruction, is this 
a hint userspace can use the related instructions?




+
+PPC_FEATURE2_HAS_IEEE128
+IEEE 128 is available? What instructions/data?


Maybe something like "IEEE 128 binary floating point instructions are 
supported.  Individual instruction availability is dependent on the

reported architecture version."?



+PPC_FEATURE2_SCV
+scv instruction is available.


I think it might be clearer to say "This kernel supports syscalls using 
the scv instruction".




+PPC_FEATURE2_MMA
+MMA facility is available.


Maybe another note that specific instruction availability may depend on 
the reported architecture version?

Re: [PATCH 1/8] Move FINAL and OVERRIDE from ansidecl.h to gcc-plugin.h

[David Malcolm via Gcc-patches]

On Thu, 2022-05-19 at 14:45 +0200, Richard Biener wrote:
> On Thu, May 19, 2022 at 2:43 PM David Malcolm via Gcc-patches
>  wrote:
> > 
> > On Thu, 2022-05-19 at 08:32 -0400, David Malcolm wrote:
> > > As of GCC 11 onwards we have required a C++11 compiler, such as
> > > GCC
> > > 4.8
> > > or later.  On the assumption that any such compiler correctly
> > > implements
> > > "final" and "override", this patch removes the FINAL and OVERRIDE
> > > macros
> > > from ansidecl.h.  It adds them back to gcc-plugins.h in case any
> > > plugins
> > > make use of them.
> > > 
> > > Followup patches within this kit replace all uses of the macros
> > > in
> > > the
> > > tree with the lower-case versions; I've split them up for ease of
> > > review, but would apply them as one combined commit if approved.
> > 
> > I forgot to say:
> > I've successfully bootstrapped & regrtested the combined patches on
> > x86_64-pc-linux-gnu, and (very) lightly tested them on aarch64-
> > linux-
> > gnu.
> 
> And I forgot to say - the patches doing the replacement are fine en-
> bloc

Thanks.  I merged those parts of the kit (patches 2-8, replacing the
macros uses with the lower-case specifiers directly) into one patch,
retested with just that, and have pushed it to trunk as r13-690-
gff171cb13df671.  I plan to look at the libiberty discussion early next
week.

Dave

> 
> Thanks,
> Richard.
> 
> > Dave
> > 
> > > 
> > > gcc/ChangeLog:
> > >     * gcc-plugin.h: Add macros OVERRIDE and FINAL.
> > > 
> > > include/ChangeLog:
> > >     * ansidecl.h: Drop macros OVERRIDE and FINAL.
> > > 
> > > Signed-off-by: David Malcolm 
> > > ---
> > >  gcc/gcc-plugin.h   |  7 +++
> > >  include/ansidecl.h | 41 
> > > -
> > >  2 files changed, 7 insertions(+), 41 deletions(-)
> > > 
> > > diff --git a/gcc/gcc-plugin.h b/gcc/gcc-plugin.h
> > > index ee9aa865114..f0f3049d0ce 100644
> > > --- a/gcc/gcc-plugin.h
> > > +++ b/gcc/gcc-plugin.h
> > > @@ -44,4 +44,11 @@ along with GCC; see the file COPYING3.  If not
> > > see
> > >  #include "tree-check.h"
> > >  #include "plugin.h"
> > > 
> > > +/* Versions of GCC prior to GCC 13 defined these macros in
> > > ansidecl.h
> > > +   for C++98 compatibility.  Given that we require C++11 from
> > > GCC 11
> > > onwards,
> > > +   keep definitions here in case plugins made use of them.  */
> > > +
> > > +#define OVERRIDE override
> > > +#define FINAL    final
> > > +
> > >  #endif /* GCC_PLUGIN_H */
> > > diff --git a/include/ansidecl.h b/include/ansidecl.h
> > > index efee5b6904b..119748deb68 100644
> > > --- a/include/ansidecl.h
> > > +++ b/include/ansidecl.h
> > > @@ -345,47 +345,6 @@ So instead we use the macro below and test
> > > it
> > > against specific values.  */
> > >  #define CONSTEXPR
> > >  #endif
> > > 
> > > -/* C++11 adds the ability to add "override" after an
> > > implementation
> > > of a
> > > -   virtual function in a subclass, to:
> > > - (A) document that this is an override of a virtual function
> > > - (B) allow the compiler to issue a warning if it isn't (e.g.
> > > a
> > > mismatch
> > > - of the type signature).
> > > -
> > > -   Similarly, it allows us to add a "final" to indicate that no
> > > subclass
> > > -   may subsequently override the vfunc.
> > > -
> > > -   Provide OVERRIDE and FINAL as macros, allowing us to get
> > > these
> > > benefits
> > > -   when compiling with C++11 support, but without requiring
> > > C++11.
> > > -
> > > -   For gcc, use "-std=c++11" to enable C++11 support; gcc 6
> > > onwards
> > > enables
> > > -   this by default (actually GNU++14).  */
> > > -
> > > -#if defined __cplusplus
> > > -# if __cplusplus >= 201103
> > > -   /* C++11 claims to be available: use it.  Final/override were
> > > only
> > > -  implemented in 4.7, though.  */
> > > -#  if GCC_VERSION < 4007
> > > -#   define OVERRIDE
> > > -#   define FINAL
> > > -#  else
> > > -#   define OVERRIDE override
> > > -#   define FINAL final
> > > -#  endif
> > > -# elif GCC_VERSION >= 4007
> > > -   /* G++ 4.7 supports __final in C++98.  */
> > > -#  define OVERRIDE
> > > -#  define FINAL __final
> > > -# else
> > > -   /* No C++11 support; leave the macros empty.  */
> > > -#  define OVERRIDE
> > > -#  define FINAL
> > > -# endif
> > > -#else
> > > -  /* No C++11 support; leave the macros empty.  */
> > > -# define OVERRIDE
> > > -# define FINAL
> > > -#endif
> > > -
> > >  /* A macro to disable the copy constructor and assignment
> > > operator.
> > >     When building with C++11 and above, the methods are
> > > explicitly
> > >     deleted, causing a compile-time error if something tries to
> > > copy.
> > 
> > 
> 

[Bug c++/105672] Print note when unable to convert between types with the same name but different scopes

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> :: note: tuple and std::tuple are not the same type

And just to be clear, it was very intentional that this suggestion *doesn't*
show the template argument lists. That's just clutter in this context (and
those arg lists are already shown in the "error:" line). The template arg lists
are irrelevant here, *no* argument list is going to make them the same type, so
showing it doesn't help.

What matters here is the nested-name-specifier and the name after it.

[Bug c++/105672] Print note when unable to convert between types with the same name but different scopes

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

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

--- Comment #4 from Jonathan Wakely  ---
(In reply to Barry Revzin from comment #2)
> And drop the "non-scalar type" part - does it add anything meaningful to the
> diagnostic?

Good point. I assume the intention of that wording is to say "I tried to find
constructors and conversion operators to make this work, but there aren't any"
but that's a very compiler-centric error. The user doesn't care where we
looked, only that it didn't compile. They can figure out (or probably already
know) whether that type is a class, and whether that means no constructor
exists for the conversion.

[Bug c++/105672] Print note when unable to convert between types with the same name but different scopes

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

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

--- Comment #3 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #0)
> Could we add a note for ill-formed conversions between two types that have
> the same name, to make it more obvious that they're defined in different
> scopes?
> 
> Maybe:
> 
> :: note: tuple and std::tuple are not the same type
> :: note: tuple define here
> :: note: std::tuple define here

I *don't* want the locations printed for two different specializations of the
same temploid, so e.g. don't show where foo::bar and foo::bar are
declared. It will almost certainly be the same line, which won't help the
confused user. I don't even think it's worth adding the first note that they're
not the same type for two specializations of the same template. That's not the
confusing case.

I'm only suggesting this for two unrelated types that just happen to have the
same name but are actually defined in totally different scopes, so a::foo and
b::foo, or c::bar and ::bar.


This would probably be useful for enumeration types as well as classes:

namespace a { enum foo { } }
namespace b { enum foo { B } }
a::foo e = b::B;

[Bug c++/105672] Print note when unable to convert between types with the same name but different scopes

[barry.revzin at gmail dot com via Gcc-bugs]

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

Barry Revzin  changed:

   What|Removed |Added

 CC||barry.revzin at gmail dot com

--- Comment #2 from Barry Revzin  ---
My suggestion is more to line up the fronts of the types:

vt.C:276:15: error: conversion requested
from: std::tuple
  to: tuple

And drop the "non-scalar type" part - does it add anything meaningful to the
diagnostic? I already know tuple<...> isn't a scalar (and if I didn't, would it
help?)

But what Mr. Wakely indicated also works - basically any presentation where the
'from' and 'to' types are on separate lines and similarly formatted makes it
easier to see what's up.

[Bug c++/89370] Output std::string in diagnostics instead of std::__cxx11::basic_string<_CharT, _Traits, _Alloc>

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Attachment #50880|0   |1
is obsolete||

--- Comment #4 from Jonathan Wakely  ---
Created attachment 53006
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53006=edit
patch to make candidate printing less verbose (rebased)

I've rebased Jason's patch, but it doesn't affect the printing of
std::__cxx11::basic_string in the previous comment.

[Bug c++/89370] Output std::string in diagnostics instead of std::__cxx11::basic_string<_CharT, _Traits, _Alloc>

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed|2019-02-18 00:00:00 |2022-5-20

--- Comment #3 from Jonathan Wakely  ---
I lost two hours of my life last night because of this error:

vt.C:276:15: error: conversion from 'std::tuple, std::allocator >
>' to non-scalar type 'tuple, std::allocator > >' requested
  276 | make_tuple(17, 2.718281828, std::string("Fun"));
  | ~~^


I might have notice sooner that it's "std::tuple" vs "tuple" if I hadn't been
double- and triple-checking the std::__cxx11::basic_string noise :-(

Without default template args:

vt.C:276:15: error: conversion from 'std::tuple >' to non-scalar type 'tuple >' requested
  276 | make_tuple(17, 2.718281828, std::string("Fun"));
  | ~~^

And with std::__cxx11::basic_string replaced with just std::string:

vt.C:276:15: error: conversion from 'std::tuple' to
non-scalar type 'tuple' requested
  276 | make_tuple(17, 2.718281828, std::string("Fun"));
  | ~~^

(I've reported PR 105672 to improve this specific case, as the real problem is
orthogonal to the request for improving std::__cxx11::basic_string output.)

[Bug c++/105672] Print note when unable to convert between types with the same name but different scopes

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

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

--- Comment #1 from Jonathan Wakely  ---
Another option suggested by Barry Revzin is to line up the types, so that the
type's name is in the same column so the different nested-name-qualifier is
more obvious:

vt.C:276:15: error: conversion from
  'std::tuple'
to non-scalar type 
   'tuple' requested

Although this breaks the current convention that the error is on a single line. 

This also seems kinda related to the -fdiagnostics-show-template-tree option,
but that doesn't help here (and that option is only helpful if you remember it
exists and use it).

[Bug c++/105672] New: Print note when unable to convert between types with the same name but different scopes

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

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

Bug ID: 105672
   Summary: Print note when unable to convert between types with
the same name but different scopes
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

I spent far too long confused by this error:

vt.C:276:15: error: conversion from 'std::tuple, std::allocator >
>' to non-scalar type 'tuple, std::allocator > >' requested
  276 | make_tuple(17, 2.718281828, std::string("Fun"));
  | ~~^


The problem is that one type is std::tuple<...> and the other is ::tuple<...>
but the distinction is not very obvious in the error.

Could we add a note for ill-formed conversions between two types that have the
same name, to make it more obvious that they're defined in different scopes?

Maybe:

:: note: tuple and std::tuple are not the same type
:: note: tuple define here
:: note: std::tuple define here

[Bug d/105659] error: #error You must define PREFERRED_DEBUGGING_TYPE if DWARF is not supported

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #2 from Iain Buclaw  ---
(In reply to Iain Buclaw from comment #1)
> If I recall the conversation correctly, either the CPU-specific D language
> hooks should be moved to macros - equivalent to TARGET_CPU_CPP_BUILTINS and
> others.  Or the tm_d file should be packed with a lot more headers within -
> possibly tricky as it would mean handling it in every possible path in
> config.gcc.
Or I do away with tm_d.h and just include tm.h and tm_p.h in all D-specific
target files, so that the CPU version macros will always be picked up by
default-d.cc and others.

I note that there's also a similar hack done for darwin-d.cc, where tm-dwarf2.h
is explicitly added to the tm_d.h file in order to get around this.

Re: [PATCH] gdc 9, 10 and 11 bug fix

[Iain Buclaw via Gcc-patches]

Excerpts from Marc Aurèle La France's message of Mai 20, 2022 6:56 am:
> On Tue, 17 May 2022, Marc Aurèle La France wrote:
>> On Tue, 17 May 2022, Iain Buclaw wrote:
>>> Excerpts from Marc Aurèle La France's message of Mai 17, 2022 5:31 pm:
 On Tue, 17 May 2022, Iain Buclaw wrote:
> Excerpts from Marc Aurèle La France's message of Mai 16, 2022 11:34 pm:
>> On Sun, 15 May 2022, Iain Buclaw wrote:
>>> Excerpts from Marc Aurèle La France's message of Mai 12, 2022 10:29 pm:
> 
 No compiler has any business rejecting files for the sole crime of
 being symlinked to.  The following applies, modulo patch fuzz, to the
 9, 10 and 11 series of compilers.
> 
 Given my use of shadow trees, this bug attempted to prevent me from
 building 12.1.0.  The D-based gdc in 12.1.0 and up does not exhibit
 this quirky behaviour.
> 
>>> Thanks, I've checked upstream and see the following change:
> 
>>> https://github.com/dlang/dmd/pull/11836/commits/ebda81e44fd0ca4b247a1860d9bef411c41c16cb
> 
>>> It should be fine to just backport that.
> 
>> Thanks for the pointer.
> 
>> I ended up with the three slightly different diffs below, one each for
>> the 9, 10 and 11 branches.  Each was rebuilt using 8.5.0, then used to
>> rebuild 12.1.0.  All of this ran smoothly without complaint, although I
>> wouldn't want to do this on a 486...
> 
>> Signed-off-by: Marc Aurèle La France 
> 
>> For GCC 9   --  8< --
>> 
>> diff -aNpRruz -X /etc/diff.excludes gcc-9.4.0/gcc/d/dmd/root/filename.c 
>> devel-9.4.0/gcc/d/dmd/root/filename.c
>> --- gcc-9.4.0/gcc/d/dmd/root/filename.c  2021-06-01 01:53:04.716474774 
>> -0600
>> +++ devel-9.4.0/gcc/d/dmd/root/filename.c2022-05-15 
>> 15:02:49.995441507 
>> -0600
>> @@ -475,53 +475,7 @@ const char *FileName::safeSearchPath(Strings *path, 
>> const char *name)
>>
>>  return FileName::searchPath(path, name, false);
>>  #elif POSIX
>> -/* Even with realpath(), we must check for // and disallow it
>> - */
>> -for (const char *p = name; *p; p++)
>> -{
>> -char c = *p;
>> -if (c == '/' && p[1] == '/')
>> -{
>> -return NULL;
>> -}
>> -}
> 
> I'd keep this check in, otherwise removing/replacing only the `if
> (path)` branch looks OK to me.
> 
 The corresponding D code doesn't care about double slashes and neither
 should this.  Also, the comment is misleading as realpath() would no
 longer be used here.
> 
>>> True, but the D front-end does check the path in other places now:
> 
>>> https://github.com/dlang/dmd/blob/e9ba29d71b557fe079e95ee6554f116b24159bab/src/dmd/root/filename.d#L787-L803
> 
>>> https://github.com/dlang/dmd/blob/e9ba29d71b557fe079e95ee6554f116b24159bab/src/dmd/expressionsem.d#L5984-L6007
> 
>>> If we remove all checks, then there'd be nothing to prevent either
>>> import("/file") or import("../file") from being used.
> 
>> There is still no check for double slashes.  All I want here is to fix a C++ 
>> -> D migration bug without leaving any detritus behind.
> 
> Anything more on this?
> 

My concern is that given:

pragma(msg, import("/etc/fstab"));
pragma(msg, import("../../../../../../etc/fstab"));

This will result in errors with both `gdc-11 -J.` and `gdc-12 -J.`

gdc-11:
---
error: file "/etc/fstab" cannot be found or not in a path specified with -J
1 | pragma(msg, import("/etc/fstab"));
  | ^
error: file "../../../../../../etc/fstab" cannot be found or not in a path 
specified with -J
2 | pragma(msg, import("../../../../../../etc/fstab"));
  | ^
---

gdc-12:
---
error: absolute path is not allowed in import expression: ‘"/etc/fstab"’
1 | pragma(msg, import("/etc/fstab"));
  | ^
error: path refers to parent (‘..’) directory: ‘"../../../../../../etc/fstab"’
2 | pragma(msg, import("../../../../../../etc/fstab"));
  | ^
absimport.d:2:1: note: while evaluat
---

With just this change alone, that means both forms will be permitted.
If we're going to fix how searchPath checks imports, might as well move
in the direction of the v2.100 behaviour in gdc-12, and include a couple
checks for absolute paths and `..` in the string.

Regards,
Iain.

[Bug middle-end/105654] transparent_union, function pointer and different types arguments causes null pointer to be passed

[tobias at strongswan dot org via Gcc-bugs]

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

Tobias Brunner  changed:

   What|Removed |Added

 CC||tobias at strongswan dot org

--- Comment #4 from Tobias Brunner  ---
Note that changing the macro so that instead of

  static typeof(_cb_parse)* parse = _cb_parse;

it declares the function like this

  static _Bool (*parse)(void*, char* in) = _cb_parse;

seems to fix the issue (see my update here:
https://github.com/strongswan/strongswan/issues/1053#issuecomment-1131356912).

[Bug target/61810] init-regs.c papers over issues elsewhere

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #8 from Alexander Monakov  ---
(In reply to Richard Biener from comment #7)
> But it looks like the testcase is broken:
> 
> __attribute__((always_inline, target("avx2")))
> static __m256i
> load8bit_4x4_avx2(const uint8_t *const src, const uint32_t stride)
> { 
>   __m128i src01, src23;
>   src01 = _mm_cvtsi32_si128(*(int32_t*)(src + 0 * stride));
>   src23 = _mm_insert_epi32(src23, *(int32_t *)(src + 3 * stride), 1);
>   return _mm256_setr_m128i(src01, src23);
> }
> 
> it seems to expect that src23 is zero before inserting the data?

If you look in the original PR 104441 testcase, it has sensible code:

static __m256i __attribute__((always_inline))
load8bit_4x4_avx2(const uint8_t *const src, const uint32_t stride)
{
  __m128i src01, src23;
  src01 = _mm_cvtsi32_si128(*(int32_t*)(src + 0 * stride));
  src01 = _mm_insert_epi32(src01, *(int32_t *)(src + 1 * stride), 1);
  src23 = _mm_cvtsi32_si128(*(int32_t*)(src + 2 * stride));
  src23 = _mm_insert_epi32(src23, *(int32_t *)(src + 3 * stride), 1);
  return _mm256_setr_m128i(src01, src23);
}

Question on cgraph_edge::call_stmt during LTO

[Erick Ochoa via Gcc]

Hi,

I'm working on a pass that looks into the estimated values during ipa-cp
and stores them for a later analyses/pass. I would like to store the real
arguments' estimates in a cgraph_edge::call_stmt or somewhere else that
makes similar sense. (Note, this is different from the formal parameters'
estimates which can be found in the lattice print out of ipa-cp).

I have already added a new field in the definition of gimple_call, made
sure that this field is streamed-out, streamed-in, and set the values
during ipa-cp. However, I am having problems with what I believe is the
inlining and cloning of cgraph_nodes. Whenever a cgraph_node is inlined or
cloned, I would need to copy this information and update if necessary. At
the moment, when I am trying to read the information during a late
SIMPLE_IPA_PASS, the information is simply not there. I believe that the
cgraph_edge is not the same since during ipa-cp the callee has been
specialized and during ipa-inline the caller has been inlined to a
different caller.

Also, for some cgraph_edge's the call_stmt is NULL. I believe this can also
be due to inlining, but I am not sure.

Can someone point out a good way to keep this information in sync with the
creation and deletion of cgraph_edges? Maybe an alternative to
cgraph_edge::call_stmt?

Thanks!

-Erick

Re: [PATCH] configure: add --disable-fix-includes

[Alexandre Oliva via Gcc-patches]

On May 11, 2022, Martin Liška  wrote:

> Ready to be installed?

Hmm...  I don't like that --disable-fixincludes would still configure,
build and even install fixincludes.  This would be surprising, given
that the semantics of disabling a component is to not even configure it.

How about leaving the top-level alone, and changing gcc/configure.ac to
clear STMP_FIXINC when --disable-fixincludes is given?

-- 
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 

☺ Buildbot (GNU Toolchain): gccrust - build successful (master)

[builder--- via Gcc-rust]

A restored build has been detected on builder gccrust-debian-ppc64 while 
building gccrust.

Full details are available at:
https://builder.sourceware.org/buildbot/#builders/3/builds/120

Build state: build successful
Revision: 64a41cce91795561c2b007cb25ad4e43b53d126a
Worker: debian-ppc64
Build Reason: (unknown)
Blamelist: Arthur Cohen , bors[bot] 
<26634292+bors[bot]@users.noreply.github.com>

Steps:

- 0: worker_preparation ( success )

- 1: git checkout ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/3/builds/120/steps/1/logs/stdio

- 2: rm -rf gccrs-build ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/3/builds/120/steps/2/logs/stdio

- 3: configure ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/3/builds/120/steps/3/logs/stdio

- 4: make ( warnings )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/3/builds/120/steps/4/logs/stdio
- warnings (32): 
https://builder.sourceware.org/buildbot/#builders/3/builds/120/steps/4/logs/warnings__32_

- 5: make check ( warnings )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/3/builds/120/steps/5/logs/stdio
- rust.sum: 
https://builder.sourceware.org/buildbot/#builders/3/builds/120/steps/5/logs/rust_sum
- rust.log: 
https://builder.sourceware.org/buildbot/#builders/3/builds/120/steps/5/logs/rust_log
- warnings (1): 
https://builder.sourceware.org/buildbot/#builders/3/builds/120/steps/5/logs/warnings__1_

- 6: grep unexpected rust.sum ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/3/builds/120/steps/6/logs/stdio

- 7: prep ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/3/builds/120/steps/7/logs/stdio

- 8: fetch ['../gccrs-build/gcc/testsuite/rust/rust.sum ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/3/builds/120/steps/8/logs/stdio

- 9: fetch ['../gccrs-build/gcc/config.log'] ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/3/builds/120/steps/9/logs/stdio

- 10: pass .bunsen.source.gitname ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/3/builds/120/steps/10/logs/stdio

- 11: pass .bunsen.source.gitrepo ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/3/builds/120/steps/11/logs/stdio

- 12: upload to bunsen ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/3/builds/120/steps/12/logs/stdio

- 13: clean up ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/3/builds/120/steps/13/logs/stdio

A restored build has been detected on builder gccrust-fedora-s390x while 
building gccrust.

Full details are available at:
https://builder.sourceware.org/buildbot/#builders/37/builds/120

Build state: build successful
Revision: 64a41cce91795561c2b007cb25ad4e43b53d126a
Worker: fedora-s390x
Build Reason: (unknown)
Blamelist: Arthur Cohen , bors[bot] 
<26634292+bors[bot]@users.noreply.github.com>

Steps:

- 0: worker_preparation ( success )

- 1: git checkout ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/37/builds/120/steps/1/logs/stdio

- 2: rm -rf gccrs-build ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/37/builds/120/steps/2/logs/stdio

- 3: configure ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/37/builds/120/steps/3/logs/stdio

- 4: make ( warnings )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/37/builds/120/steps/4/logs/stdio
- warnings (54): 
https://builder.sourceware.org/buildbot/#builders/37/builds/120/steps/4/logs/warnings__54_

- 5: make check ( warnings )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/37/builds/120/steps/5/logs/stdio
- rust.sum: 
https://builder.sourceware.org/buildbot/#builders/37/builds/120/steps/5/logs/rust_sum
- rust.log: 
https://builder.sourceware.org/buildbot/#builders/37/builds/120/steps/5/logs/rust_log
- warnings (4): 
https://builder.sourceware.org/buildbot/#builders/37/builds/120/steps/5/logs/warnings__4_

- 6: grep unexpected rust.sum ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/37/builds/120/steps/6/logs/stdio

- 7: prep ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/37/builds/120/steps/7/logs/stdio

- 8: fetch ['../gccrs-build/gcc/testsuite/rust/rust.sum ( success )
Logs:
- stdio: 
https://builder.sourceware.org/buildbot/#builders/37/builds/120/steps/8/logs/stdio

- 9: fetch ['../gccrs-build/gcc/config.log'] ( success )
Logs:
- stdio: 

[PATCH] Modula-2: merge proposal/review: 8/9 08.patch-set-06 v2

[Gaius Mulley via Gcc-patches]

Hello,

for completeness here is v2 of the patch set:

   (m2pp.c has been renamed m2pp.cc and a missing dependency added to
   m2rte).

6.  gcc/m2/Make-lang.in
==

-
New file: gcc/m2/Make-lang.in
-
# Top level -*- makefile -*- fragment for GNU M2.

# Copyright (C) 2000-2022 Free Software Foundation, Inc.

#This file is part of GCC.

#GCC is free software; you can redistribute it and/or modify
#it under the terms of the GNU General Public License as published by
#the Free Software Foundation; either version 3, or (at your option)
#any later version.

#GCC is distributed in the hope that it will be useful,
#but WITHOUT ANY WARRANTY; without even the implied warranty of
#MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
#GNU General Public License for more details.

#You should have received a copy of the GNU General Public License
#along with GCC; see the file COPYING3.  If not see
#.

# QUIAT=@
GM2_MAKE_DEBUG=

# Actual names to use when installing a native compiler.
GM2_INSTALL_NAME = $(shell echo gm2|sed '$(program_transform_name)')
GM2_TARGET_INSTALL_NAME = $(target_noncanonical)-$(shell echo gm2|sed 
'$(program_transform_name)')

# Actual names to use when installing a cross-compiler.
GM2_CROSS_NAME = `echo gm2|sed '$(program_transform_cross_name)'`

GM2_1 = ./gm2 -B./stage1/m2 -g -fm2-g
XGCC = ./xgcc -B./
GM2_2 = ./gm2 -B./stage2/m2 -g -fm2-g
CFLAGS=-g   ## remove this
LDLAGS=-g   ## remove this

# Define the name of target independent tools to be installed in $(bindir)
# Names are subject to change

# The tools directly available to the user are built in gm2tools, gm2m is
# an internal tool and therefore built here.

GM2_LINK_TOOLS_INSTALL =
# GM2_LINK_TOOLS_INSTALL = gm2m$(exeext) #  gm2m is not installed as it is 
under development.

GM2_LINK_TOOLS = gm2m$(exeext) gm2l$(exeext) gm2lcc$(exeext) \
 gm2lgen$(exeext) gm2lorder$(exeext)

GM2_LINK_TOOLS_BOOT = stage1/m2/gm2lcc$(exeext) stage1/m2/gm2l$(exeext) \
  stage1/m2/gm2lgen$(exeext) stage1/m2/gm2lorder$(exeext)

ifeq ($(CC1ONLY),yes)
GCC_TOOLS_FOR_GM2 = \
$(GCC_PASSES) $(GCC_PARTS) \
stage1/m2/gcc$(exeext) \
stage1/m2/cc1$(exeext) \
stage1/m2/cpp$(exeext)
else
GCC_TOOLS_FOR_GM2 = \
$(GCC_PASSES) $(GCC_PARTS) \
stage1/m2/gcc$(exeext) \
stage1/m2/cc1$(exeext) \
stage1/m2/cc1plus$(exeext) \
stage1/m2/cpp$(exeext)
endif

CPP_GM2=-fpermissive -DIN_GCC -g

TEXISRC = $(objdir)/m2/images/gnu.eps \
  $(srcdir)/doc/gm2.texi \
  m2/gm2-libs.texi \
  m2/gm2-ebnf.texi \
  m2/SYSTEM-pim.texi \
  m2/SYSTEM-iso.texi \
  m2/Builtins.texi \
  m2/version.texi


# Define the names for selecting GNU Modula-2 in LANGUAGES.
m2 modula-2 modula2: gm2$(exeext) xgcc$(exeext) cc1gm2$(exeext) \
 $(GCC_TOOLS_FOR_GM2)
m2.serial = cc1gm2$(exeext)

# Tell GNU make to ignore these if they exist.
.PHONY: m2 modula-2 modula2

GM2_PROG_DEP=gm2$(exeext) xgcc$(exeext) cc1gm2$(exeext)

TEXI2HTML=python3 $(srcdir)/m2/www/tools/texi2tr/src/texi2tr.py

include m2/config-make
LIBSTDCXX=../$(TARGET_SUBDIR)/libstdc++-v3/src/.libs/libstdc++.a

SRC_PREFIX=G

m2/gm2spec.o: $(srcdir)/m2/gm2spec.cc $(SYSTEM_H) $(GCC_H) $(CONFIG_H) \
   m2/gm2config.h $(TARGET_H) $(PLUGIN_HEADERS) \
   $(generated_files) $(C_TREE_H)
(SHLIB_LINK='$(SHLIB_LINK)' \
SHLIB_MULTILIB='$(SHLIB_MULTILIB)'; \
$(COMPILER) $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(INCLUDES) \
 $(DRIVER_DEFINES) \
-DLIBSUBDIR=\"$(libsubdir)\" \
-DPREFIX=\"$(prefix)\" \
-c $(srcdir)/m2/gm2spec.cc $(OUTPUT_OPTION))

m2/gm2version.c: gm2version-check; @true

gm2version-check:
$(SHELL) $(srcdir)/m2/tools-src/makeversion -p $(srcdir) m2
$(STAMP) gm2version-check

gm2version.o: m2/gm2version.c
(SHLIB_LINK='$(SHLIB_LINK)' \
SHLIB_MULTILIB='$(SHLIB_MULTILIB)'; \
$(COMPILER) -c $(ALL_COMPILERFLAGS) $(ALL_CPPFLAGS) $(DRIVER_DEFINES) \
-DLIBSUBDIR=\"$(libsubdir)\" \
$(INCLUDES) m2/gm2version.c $(OUTPUT_OPTION))

# Create the compiler driver for M2.
CFLAGS-m2/m2/gm2spec.o += $(DRIVER_DEFINES)

GM2_OBJS = $(GCC_OBJS) m2/gm2version.o \
prefix.o intl.o m2/gm2spec.o

# Create the compiler driver for gm2.
gm2$(exeext): $(GM2_OBJS) $(EXTRA_GCC_OBJS) libcommon-target.a $(LIBDEPS) \
m2/gm2config.h
+$(LINKER) $(ALL_LINKERFLAGS) $(LDFLAGS) -o $@ \
  $(GM2_OBJS) $(EXTRA_GCC_OBJS) libcommon-target.a \
  $(EXTRA_GCC_LIBS) $(LIBS)

# Create a version of the gm2 driver which calls the cross-compiler.
gm2-cross$(exeext): gm2$(exeext)
-rm -f gm2-cross$(exeext)
cp gm2$(exeext) gm2-cross$(exeext)

Re: [PATCH] Add divide by zero side effect.

[Alexandre Oliva via Gcc-patches]

On May 18, 2022, Andrew MacLeod via Gcc-patches  wrote:

> I'm open to suggestions for a better term!

How about inference?

-- 
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: [RFC Linux patch] powerpc: add documentation for HWCAPs

[Nicholas Piggin via Gcc]

Excerpts from Michael Ellerman's message of May 20, 2022 7:21 pm:
> Nicholas Piggin via Libc-alpha  writes:
>> This takes the arm64 file and adjusts it for powerpc. Feature
>> descriptions are vaguely handwaved by me.
>> ---
> 
> Thanks for attempting to document this.

It was mainly copy and paste from two existing files :)

>> +1. Introduction
>> +---
>> +
>> +Some hardware or software features are only available on some CPU
>> +implementations, and/or with certain kernel configurations, but have no
>> +architected discovery mechanism available to userspace code. The kernel
> 
> By "no architected discovery mechanism" you mean nothing in the ISA, but
> I think a reader might not understand that. After all HWCAP is an
> "architected discovery mechanism", architected by the kernel and libc.
> 
> Maybe just say "no other discovery mechanism".

Good point I reworded that.

>> +Features cannot be probed reliably through other means. When a feature
>> +is not available, attempting to use it may result in unpredictable
>> +behaviour, and is not guaranteed to result in any reliable indication
>> +that the feature is unavailable, such as a SIGILL.
> 
> I'd just drop the "such as a SIGILL", don't give people ideas :)

Yep.

>> +2. hwcap allocation
>> +---
>> +
>> +HWCAPs are allocated as described in Power Architecture 64-Bit ELF V2 ABI
> 
> Are we calling them hwcaps or HWCAPs?

arm64 was mixed. We'll go with HWCAP.

>> +Specification (which will be reflected in the kernel's uapi headers).
>> +
>> +3. The hwcaps exposed in AT_HWCAP
>> +-
>> +
>> +PPC_FEATURE_32
>> +32-bit CPU
>> +
>> +PPC_FEATURE_64
>> +64-bit CPU (userspace may be running in 32-bit mode).
>> +
>> +PPC_FEATURE_601_INSTR
>> +The processor is PowerPC 601
> 
> Unused in the kernel since:
>   f0ed73f3fa2c ("powerpc: Remove PowerPC 601")
> 
>> +PPC_FEATURE_HAS_ALTIVEC
>> +Vector (aka Altivec, VSX) facility is available.
>> +
>> +PPC_FEATURE_HAS_FPU
>> +Floating point facility is available.
>> +
>> +PPC_FEATURE_HAS_MMU
>> +Memory management unit is present.
>> +
>> +PPC_FEATURE_HAS_4xxMAC
>> +?
> 
> First appeared in v2.4.9.2, as part of "Paul Mackerras: PPC update (big 
> re-org)":
> 
>   
> https://github.com/mpe/linux-fullhistory/commit/dccd38599dad0588f4fb254c0a188b7c70af02e1
> 
> No extra context I can see.
> 
> I think all our 4xx (40x or 44x) CPUs have that set, so seems like it
> just means "is a 40x or 44x".
> 
>> +PPC_FEATURE_UNIFIED_CACHE
>> +?
> 
> Unused in the kernel since:
>   39c8bf2b3cc1 ("powerpc: Retire e200 core (mpc555x processor)")
> 
>> +PPC_FEATURE_HAS_SPE
>> +?
> 
> AFAIK means the CPU supports SPE (Signal Processing Engine) instructions.
> 
> They were documented in ISA v2.07 Book I chapter 8.
> 
> Not to be confused with the Cell SPEs.

Okay.

> 
> I think GCC has dropped support for SPE, so at some point we may want to
> drop the kernel support also, as it will be increasingly untested.
> 
>> +PPC_FEATURE_HAS_EFP_SINGLE
>> +?
> 
> Seems to be SPE related, only set on CPUs that also have SPE.

Maybe found some docs on it. It was some ops additional to the SPE
facility by the looks.

> 
>> +PPC_FEATURE_HAS_EFP_DOUBLE
>> +?
> 
> As above.
> 
>> +PPC_FEATURE_NO_TB
>> +The timebase facility (mftb instruction) is not available.
>> +
> 
> Unused in the kernel since:
>   f0ed73f3fa2c ("powerpc: Remove PowerPC 601")
> 
>> +PPC_FEATURE_POWER4
>> +The processor is POWER4.
> 
> We dropped Power4 support in:
> 
>   471d7ff8b51b ("powerpc/64s: Remove POWER4 support")
> 
> But that bit is still set for PPC970/FX/MP.

Ah good catch.

> 
>> +PPC_FEATURE_POWER5
>> +The processor is POWER5.
>> +
>> +PPC_FEATURE_POWER5_PLUS
>> +The processor is POWER5+.
>> +
>> +PPC_FEATURE_CELL
>> +The processor is Cell.
>> +
>> +PPC_FEATURE_BOOKE
>> +The processor implements the BookE architecture.
>> +
>> +PPC_FEATURE_SMT
>> +The processor implements SMT.
>> +
>> +PPC_FEATURE_ICACHE_SNOOP
>> +The processor icache is coherent with the dcache, and instruction 
>> storage
>> +can be made consistent with data storage for the purpose of executing
>> +instructions with the instruction sequence:
>> +sync
>> +icbi (to any address)
>> +isync
> 
> Where did you get that from, the ISA?

User manuals. I can't find it in the ISA but arguably I'd say it should
have some note or reference to coherent implementation seeing as all 
POWER CPUs for years have had it.

>> +PPC_FEATURE_ARCH_2_05
>> +The processor supports the v2.05 userlevel architecture. Processors
>> +supporting later architectures also set this feature.
>> +
>> +PPC_FEATURE_PA6T
>> +The processor is PA6T.
>> +
>> +PPC_FEATURE_HAS_DFP
>> +DFP facility is available.
>> +
>> +PPC_FEATURE_POWER6_EXT
>> +The processor is POWER6.
>> +
>> +PPC_FEATURE_ARCH_2_06
>> +The processor supports the v2.06 userlevel architecture. 

[Bug tree-optimization/102844] [9/10/11/12/13 Regression] DOM jump threading not copying block that became non-empty

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

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

--- Comment #26 from Aldy Hernandez  ---
(In reply to Richard Biener from comment #25)
> I'm not sure about the state of this bug - the issue reproduces on the GCC
> 10 branch with checking enabled and -O[2s] -fdisable-tree-fre4
> -fno-strict-overflow
> 
> It might be that using the backward threader from DOM (are we now doing
> that?)
> makes this truly fixed but I'm not sure the backward threader is resilent
> to the issue analyzed in comments #13 to #15.  Eventually the NOCOPY

No.  DOM is the only remaining use of the forward threader.  It does not use
the backward threader, nor the ranger path solver.

Re: [PATCH] Add divide by zero side effect.

[Richard Biener via Gcc-patches]

On Fri, May 20, 2022 at 10:17 AM Alexander Monakov  wrote:
>
> On Fri, 20 May 2022, Richard Biener wrote:
>
> > On Fri, May 20, 2022 at 8:38 AM Alexander Monakov  
> > wrote:
> > >
> > > On Fri, 20 May 2022, Richard Biener via Gcc-patches wrote:
> > >
> > > > > Still waiting for a suggestion, since "side effect" is the description
> > > > > that made sense to me :-)
> > > >
> > > > I think side-effect captures it quite well even if it overlaps with a 
> > > > term
> > > > used in language standards.  Doing c = a << b has the side-effect on
> > > > imposing a range on 'b' rather than just affecting 'c' (and its range).
> > > > You could call it 'alternate effect' but that sounds just awkward ;)
> > >
> > > I suggest 'deduce', 'deduction', 'deducing a range'. What the code is 
> > > actually
> > > doing is deducing that 'b' in 'a / b' cannot be zero. Function in GCC 
> > > might be
> > > called like 'deduce_ranges_from_stmt'.
> >
> > So how would you call determining the range of 'c' from the ranges of
> > 'a' and 'b', isn't that 'deduction' as well?
>
> Kind of, yes, but for this sort of forward inference I imagine you're already
> using 'propagate [ranges through a stmt]', like in 'value range propagation'.
>
> If you'd like to avoid 'propagate'/'deduce' asymmetry, I could suggest
> 'forward inference' / 'backward inference', but I like it a bit less.

Hmm, maybe "guarantees" - if the stmt executed (without traps) then
it's guaranteed that the divisor isn't zero.  I've almost said 'assertions'
but then asserts also have separate meanings, not to mention ASSERT_EXPR
as currently used by the old-style VRP.

Richard.

>
> Alexander

[Bug middle-end/105629] [13 Regression] g++.dg/opt/pr94589-2.C for cris, m68k, s390x

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #4 from rguenther at suse dot de  ---
On Fri, 20 May 2022, hp at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105629
> 
> --- Comment #3 from Hans-Peter Nilsson  ---
> (In reply to rguent...@suse.de from comment #2)
> > On Thu, 19 May 2022, hp at gcc dot gnu.org wrote:
> > I wonder if you can help and "bisect" the actual pattern that is now
> > enabled for GENERIC folding?  The testcase is about spaceship optimization
> > and the matching done in forwprop might be quite specific and in the need
> > of a slight adjustment.
> 
> I'm going to interpret that as "if each pattern had its own #if
> GIMPLE-wrapping, which hunk in the diff caused the regression".  I'll try and
> see if it's as simple as it sounds.

Yes - thanks.

Re: [PATCH] Modula-2: merge proposal/review: 1/9 01.patch-set-01

[Richard Biener via Gcc-patches]

On Wed, May 18, 2022 at 3:47 PM Gaius Mulley via Gcc-patches
 wrote:
>
> hello,
>
> this file is part-01 of the patch set for the gm2 review.

I think you did a better job last time splitting the patches.  This
one contains the
driver changes for which I have a hard time remembering the reason they exist
and whether we already discussed it to death or not.

So - with the chance to re-open and old discussion - what's special about
modula-2 so it needs so many changes here?  Are all of them necessary
or are most of them merely "cleanups" that could be done as followup?

Thanks,
Richard.

>
> 1.  all GCC files which have been patched.
> ==
>
> The 'Only in' diff output was:
>
> Only in gcc-git-devel-modula2/gcc: m2
> Only in gcc-git-devel-modula2/gcc/testsuite: gm2
> Only in gcc-git-devel-modula2/gcc/testsuite/lib: gm2-dg.exp
> Only in gcc-git-devel-modula2/gcc/testsuite/lib: gm2.exp
> Only in gcc-git-devel-modula2/gcc/testsuite/lib: gm2-simple.exp
> Only in gcc-git-devel-modula2/gcc/testsuite/lib: gm2-torture.exp
> Only in gcc-git-devel-modula2/gcc/doc: gm2.texi
> Only in gcc-git-devel-modula2: libgm2
> Only in gcc-git-devel-modula2: gm2tools
>
> and the recursive diffs:
>
>
> diff -x '*autom4te*' -rwu gcc/configure.ac gcc-git-devel-modula2/configure.ac
> --- gcc/configure.ac2022-05-17 11:20:57.487964366 +0100
> +++ gcc-git-devel-modula2/configure.ac  2022-05-17 14:41:05.480881101 +0100
> @@ -140,7 +140,7 @@
>  # binutils, gas and ld appear in that order because it makes sense to run
>  # "make check" in that particular order.
>  # If --enable-gold is used, "gold" may replace "ld".
> -host_tools="texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim 
> gdb gdbserver gprof etc expect dejagnu m4 utils guile fastjar gnattools 
> libcc1 gotools c++tools"
> +host_tools="texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim 
> gdb gdbserver gprof etc expect dejagnu m4 utils guile fastjar gnattools 
> libcc1 gm2tools gotools c++tools"
>
>  # these libraries are built for the target environment, and are built after
>  # the host libraries and the host tools (which may be a cross compiler)
> @@ -162,6 +162,7 @@
> target-libffi \
> target-libobjc \
> target-libada \
> +   target-libgm2 \
> target-libgo \
> target-libphobos \
> target-zlib"
> @@ -459,6 +460,14 @@
>noconfigdirs="$noconfigdirs gnattools"
>  fi
>
> +AC_ARG_ENABLE(libgm2,
> +[AS_HELP_STRING([--enable-libgm2], [build libgm2 directory])],
> +ENABLE_LIBGM2=$enableval,
> +ENABLE_LIBGM2=no)
> +if test "${ENABLE_LIBGM2}" != "yes" ; then
> +  noconfigdirs="$noconfigdirs gm2tools"
> +fi
> +
>  AC_ARG_ENABLE(libssp,
>  [AS_HELP_STRING([--enable-libssp], [build libssp directory])],
>  ENABLE_LIBSSP=$enableval,
> @@ -3617,6 +3626,7 @@
>  NCN_STRICT_CHECK_TARGET_TOOLS(GFORTRAN_FOR_TARGET, gfortran)
>  NCN_STRICT_CHECK_TARGET_TOOLS(GOC_FOR_TARGET, gccgo)
>  NCN_STRICT_CHECK_TARGET_TOOLS(GDC_FOR_TARGET, gdc)
> +NCN_STRICT_CHECK_TARGET_TOOLS(GM2_FOR_TARGET, gm2)
>
>  ACX_CHECK_INSTALLED_TARGET_TOOL(AR_FOR_TARGET, ar)
>  ACX_CHECK_INSTALLED_TARGET_TOOL(AS_FOR_TARGET, as)
> @@ -3655,6 +3665,8 @@
> [gcc/gccgo -B$$r/$(HOST_SUBDIR)/gcc/], go)
>  GCC_TARGET_TOOL(gdc, GDC_FOR_TARGET, GDC,
> [gcc/gdc -B$$r/$(HOST_SUBDIR)/gcc/], d)
> +GCC_TARGET_TOOL(gm2, GM2_FOR_TARGET, GM2,
> +   [gcc/gm2 -B$$r/$(HOST_SUBDIR)/gcc/], m2)
>  GCC_TARGET_TOOL(ld, LD_FOR_TARGET, LD, [ld/ld-new])
>  GCC_TARGET_TOOL(lipo, LIPO_FOR_TARGET, LIPO)
>  GCC_TARGET_TOOL(nm, NM_FOR_TARGET, NM, [binutils/nm-new])
> @@ -3781,6 +3793,9 @@
>  # Specify what files to not compare during bootstrap.
>
>  compare_exclusions="gcc/cc*-checksum\$(objext) | gcc/ada/*tools/*"
> +compare_exclusions="$compare_exclusions | 
> gcc/m2/gm2-compiler-boot/M2Version*"
> +compare_exclusions="$compare_exclusions | gcc/m2/gm2-compiler-boot/SYSTEM*"
> +compare_exclusions="$compare_exclusions | gcc/m2/gm2version*"
>  case "$target" in
>hppa*64*-*-hpux*) ;;
>hppa*-*-hpux*) compare_exclusions="$compare_exclusions | 
> */libgcc/lib2funcs* | gcc/function-tests.o" ;;
> diff -x '*autom4te*' -rwu gcc/gcc/c/gccspec.cc 
> gcc-git-devel-modula2/gcc/c/gccspec.cc
> --- gcc/gcc/c/gccspec.cc2022-05-17 11:20:57.919969752 +0100
> +++ gcc-git-devel-modula2/gcc/c/gccspec.cc  2022-05-17 14:41:05.552881117 
> +0100
> @@ -105,3 +105,9 @@
>
>  /* Number of extra output files that lang_specific_pre_link may generate.  */
>  int lang_specific_extra_outfiles = 0;  /* Not used for C.  */
> +
> +/* lang_register_spec_functions.  Not used for C.  */
> +void
> +lang_register_spec_functions (void)
> +{
> +}
> diff -x '*autom4te*' -rwu gcc/gcc/c-family/cppspec.cc 
> gcc-git-devel-modula2/gcc/c-family/cppspec.cc
> --- gcc/gcc/c-family/cppspec.cc 2022-05-17 11:20:57.911969653 +0100
> +++ gcc-git-devel-modula2/gcc/c-family/cppspec.cc 

[Bug ipa/105600] [9/10/11/12/13 Regression] ICE with LTO when building Mumble

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

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

--- Comment #14 from Martin Liška  ---
(In reply to Alex Coplan from comment #13)
> FWIW, we started ICEing somewhere between
> r9-856-g7ce4ce10cd0a6f332dd473bd4726f1a1adefda0e and
> r9-870-ge062dc808950801a089ee6acd969393da2f39406, the build was broken
> between these revisions.

Sure, I've sent a fix that I'll backport later then.

[Bug middle-end/105629] [13 Regression] g++.dg/opt/pr94589-2.C for cris, m68k, s390x

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

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

--- Comment #3 from Hans-Peter Nilsson  ---
(In reply to rguent...@suse.de from comment #2)
> On Thu, 19 May 2022, hp at gcc dot gnu.org wrote:
> I wonder if you can help and "bisect" the actual pattern that is now
> enabled for GENERIC folding?  The testcase is about spaceship optimization
> and the matching done in forwprop might be quite specific and in the need
> of a slight adjustment.

I'm going to interpret that as "if each pattern had its own #if
GIMPLE-wrapping, which hunk in the diff caused the regression".  I'll try and
see if it's as simple as it sounds.

[Bug tree-optimization/105663] [11/12/13 Regression] ICE (segfault) in operator_bitwise_not::fold_range with O1/O2/O3/Os

[gcc-hbfypl at hansdejong dot eu via Gcc-bugs]

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

--- Comment #8 from Hans de Jong  ---
The reduced testcase of comment #1 also fails on optimization levels O1 and Os.

I added the compiler versions which I have seen break on godbolt.org.

[Bug c++/105671] Unexplained "undefined reference" error

[christian.morales.vega at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Cristian Morales Vega  ---
It's in the full verbose build log, but failed to include it here. These are
the contents of the files:

$ cat user-config.jam 
using gcc : : g++ : "-flto" ;
$ cat test.cpp
#include 
#include 
#include 

int
main()
{
auto generic = boost::program_options::options_description{};
std::cout << generic;
}

[Bug libstdc++/104019] Testsuite 17_intro/headers/c++2020/stdc++_multiple_inclusion.cc failures

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

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

--- Comment #14 from Jonathan Wakely  ---
Apart from the bogus warnings caused by PR 61596, I think only the std::latch
problem remains. Comment 11 has a suggestion for that.

[Bug c++/105671] New: Unexplained "undefined reference" error

[christian.morales.vega at gmail dot com via Gcc-bugs]

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

Bug ID: 105671
   Summary: Unexplained "undefined reference" error
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christian.morales.vega at gmail dot com
  Target Milestone: ---

Created attachment 53005
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53005=edit
Full verbose build log

I have found a strange issue in my project build that reproduces is Ubuntu
22.04 (gcc 11.2) and Fedora 36 (gcc 12.1.1). This is the most I have been able
to reduce it:

$ tar xf boost_1_79_0.tar.bz2 
$ cd boost_1_79_0/
$ ./bootstrap.sh
$ ./b2 --with-program_options link=static --user-config=$PWD/../user-config.jam
$ cd ..
$ g++ -o /dev/null test.cpp -Iboost_1_79_0
boost_1_79_0/stage/lib/libboost_program_options.a -Os -flto
/usr/bin/ld: /tmp/cccbpRrv.ltrans0.ltrans.o: in function
`boost::program_options::options_description::get_option_column_width() const':
:(.text+0x28cd): undefined reference to
`std::__cxx11::basic_stringbuf,
std::allocator >::_M_high_mark() const'
/usr/bin/ld: /tmp/cccbpRrv.ltrans0.ltrans.o: in function
`boost::program_options::(anonymous namespace)::format_one(std::ostream&,
boost::program_options::option_description const&, unsigned int, unsigned int)
[clone .constprop.0]':
:(.text+0x2d80): undefined reference to
`std::__cxx11::basic_stringbuf,
std::allocator >::_M_high_mark() const'
/usr/bin/ld: :(.text+0x2e13): undefined reference to
`std::__cxx11::basic_stringbuf,
std::allocator >::_M_high_mark() const'
/usr/bin/ld: :(.text+0x3d40): undefined reference to
`std::__cxx11::basic_stringbuf,
std::allocator >::_M_high_mark() const'
collect2: error: ld returned 1 exit status
$

I'm attaching a log showing the whole Boost.Program_options verbose build log.

- Change "-Os" for "-O1" and it works
- Remove the -supposedly unused- "#include " line and it
works.

[Bug target/61810] init-regs.c papers over issues elsewhere

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #7 from Richard Biener  ---
(In reply to Andrew Pinski from comment #6)
> https://gcc.gnu.org/pipermail/gcc-patches/2021-August/577192.html

On current trunk x86_64 that gets

FAIL: gcc.target/i386/extract-insert-combining.c scan-assembler-times
(?:vmovd|movd)[ t]+[^{\\n]*%xmm[0-9] 3
FAIL: gcc.target/i386/extract-insert-combining.c scan-assembler-times
(?:vpinsrd|pinsrd)[ t]+[^{\\n]*%xmm[0-9] 1
FAIL: gcc.target/i386/pr104441-1b.c execution test
FAIL: gcc.target/i386/pr98335.c scan-assembler movzbl
FAIL: gcc.target/i386/pr98335.c scan-assembler-not movb

FAIL: gnat.dg/sso8.adb execution test

FAIL: libgomp.c/loop-19.c execution test


FAILs can be reproduced in an unpatched tree with specifying
-fdisable-rtl-init-regs

Assembly difference for gcc.target/i386/pr104441-1b.c is (besides RA):

-   vpxor   %xmm1, %xmm1, %xmm1
+   vpinsrd $1, (%rax,%r10), %xmm5, %xmm1
+   vpinsrd $1, (%rdx,%r9), %xmm4, %xmm3
vmovd   (%rax), %xmm0
-   vpxor   %xmm2, %xmm2, %xmm2
addl$4, %ecx
-   vpinsrd $1, (%rax,%r10), %xmm1, %xmm1
-   vpinsrd $1, (%rdx,%r9), %xmm2, %xmm2

adding initialization in compute4x_m_sad_avx2_intrin of reg 109 at in block 4
for insn 33.
adding initialization in compute4x_m_sad_avx2_intrin of reg 99 at in block 4
for insn 48.

where we have for example

-(insn 97 31 98 4 (clobber (reg/v:V2DI 109 [ src23 ]))
"/home/rguenther/obj-gcc4-g/gcc/include/smmintrin.h":408:20 -1
- (nil))
-(insn 98 97 33 4 (set (reg/v:V2DI 109 [ src23 ])
-(const_vector:V2DI [
-(const_int 0 [0]) repeated x2
-])) "/home/rguenther/obj-gcc4-g/gcc/include/smmintrin.h":408:20 -1
- (nil))
-(insn 33 98 36 4 (set (reg:V4SI 138 [ src23 ])
+(insn 33 31 36 4 (set (reg:V4SI 138 [ src23 ])
 (vec_merge:V4SI (vec_duplicate:V4SI (reg:SI 137 [ MEM[(int32_t
*)src_62 + _41 * 1] ]))
 (subreg:V4SI (reg/v:V2DI 109 [ src23 ]) 0)
 (const_int 2 [0x2])))
"/home/rguenther/obj-gcc4-g/gcc/include/smmintrin.h":408:20 6925
{sse4_1_pinsrd}

where this produces { undef, MEM, undef, undef } without init-regs

But it looks like the testcase is broken:

__attribute__((always_inline, target("avx2")))
static __m256i
load8bit_4x4_avx2(const uint8_t *const src, const uint32_t stride)
{ 
  __m128i src01, src23;
  src01 = _mm_cvtsi32_si128(*(int32_t*)(src + 0 * stride));
  src23 = _mm_insert_epi32(src23, *(int32_t *)(src + 3 * stride), 1);
  return _mm256_setr_m128i(src01, src23);
}

it seems to expect that src23 is zero before inserting the data?

Re: problem with Makefile.in generation in lingomp

[Mohamed Atef via Gcc]

I use 1.15.1.
This is the link to the line I mentioned.
https://github.com/gcc-mirror/gcc/blob/master/libgomp/plugin/Makefrag.am#L29


On Fri, May 20, 2022 at 11:40 AM Jakub Jelinek  wrote:

> On Fri, May 20, 2022 at 11:25:59AM +0200, Mohamed Atef wrote:
> >I downloaded the last version of the repo, but when I try to
> > autoreconf
> > in libgomp/
> > i get this error "plugin/Makefrag.am:29: error: libgomp_la_LIBADD must be
> > set with '=' before using '+='"
> > line 29 in libgomp/plugin/Makefrag.am has
> > "libgomp_la_LIBADD += $(DL_LIBS)"
> > I removed this line and "autoreconf" worked fine.
> > Do I miss some packages?
>
> Are you using automake 1.15.1 that should be used?
>
> Anyway, the error seems to be incorrect,
> libgomp_la_LIBADD is set in libgomp/Makefile as
> libgomp_la_LIBADD =
> before
> include $(top_srcdir)/plugin/Makefrag.am
> a few lines later.
>
> Jakub
>
>

[Bug target/105670] New: [x86] suboptimal code for branch over two bools

[fent at in dot tum.de via Gcc-bugs]

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

Bug ID: 105670
   Summary: [x86] suboptimal code for branch over two bools
   Product: gcc
   Version: 12.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fent at in dot tum.de
  Target Milestone: ---

void test(bool a, bool b, int* t) {
  if (a & b)
*t = 42;
}

With -O1, -O2, -O3, and -Os this produces:

test(bool, bool, int*):
testdil, dil
je  .L1
testsil, sil
je  .L1
mov DWORD PTR [rdx], 42
.L1:
ret

The following would be 5B shorter and also faster, since it minimizes branch
misses:

test(bool, bool, int*):
testsil, dil
je  .L1
mov DWORD PTR [rdx], 42
.L1:
ret

Note that this is (somewhat) ABI dependent, but works on x86-64 System V,
since:
> bit 0 contains the truth value and bits 1 to 7 shall be zero

Re: problem with Makefile.in generation in lingomp

[Jakub Jelinek via Gcc]

On Fri, May 20, 2022 at 11:25:59AM +0200, Mohamed Atef wrote:
>I downloaded the last version of the repo, but when I try to
> autoreconf
> in libgomp/
> i get this error "plugin/Makefrag.am:29: error: libgomp_la_LIBADD must be
> set with '=' before using '+='"
> line 29 in libgomp/plugin/Makefrag.am has
> "libgomp_la_LIBADD += $(DL_LIBS)"
> I removed this line and "autoreconf" worked fine.
> Do I miss some packages?

Are you using automake 1.15.1 that should be used?

Anyway, the error seems to be incorrect,
libgomp_la_LIBADD is set in libgomp/Makefile as
libgomp_la_LIBADD =
before
include $(top_srcdir)/plugin/Makefrag.am
a few lines later.

Jakub

problem with Makefile.in generation in lingomp

[Mohamed Atef via Gcc]

Hello,
   I downloaded the last version of the repo, but when I try to
autoreconf
in libgomp/
i get this error "plugin/Makefrag.am:29: error: libgomp_la_LIBADD must be
set with '=' before using '+='"
line 29 in libgomp/plugin/Makefrag.am has
"libgomp_la_LIBADD += $(DL_LIBS)"
I removed this line and "autoreconf" worked fine.
Do I miss some packages?

Mohamed

[Bug tree-optimization/101668] BB vectorizer doesn't handle lowpart of existing vector

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

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

--- Comment #5 from Richard Biener  ---
(In reply to Hongtao.liu from comment #4)
> Guess we need to extend backend hook to handle different input and output
> modes.

Yes, alternatively as said, some special cases could be directly handled.
For example v16si -> v8si could be handled by VEC_PERM 
without any extra magic (but IIRC we don't have a way to query target support
for specific BIT_FIELD_REFs which we'd use for getting at the lowpart
or highpart and if not available those would fall back to memory).
And contiguous permutes could be directly emitted as BIT_FIELD_REFs
(in some cases).

I have a half-way patch that does the preparatory work but leaves
vectorizable_slp_permutation unchanged so we immediately fail there
due to

  FOR_EACH_VEC_ELT (SLP_TREE_CHILDREN (node), i, child)
{
  if (!vect_maybe_update_slp_op_vectype (child, vectype)
  || !types_compatible_p (SLP_TREE_VECTYPE (child), vectype))
{
  if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
 "Unsupported lane permutation\n");
  return false;

the comment above that says

  /* ???  We currently only support all same vector input and output types
 while the SLP IL should really do a concat + select and thus accept
 arbitrary mismatches.  */

so it was designed to handle more, it wasn't just necessary to implement it ...

[Bug ipa/105600] [9/10/11/12/13 Regression] ICE with LTO when building Mumble

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

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

Alex Coplan  changed:

   What|Removed |Added

Summary|[9/10/11/12/13 Regression]  |[9/10/11/12/13 Regression]
   |ICE with LTO when building  |ICE with LTO when building
   |Mumble since|Mumble
   |r12-5696-g53caa4723d8de73f  |

--- Comment #13 from Alex Coplan  ---
FWIW, we started ICEing somewhere between
r9-856-g7ce4ce10cd0a6f332dd473bd4726f1a1adefda0e and
r9-870-ge062dc808950801a089ee6acd969393da2f39406, the build was broken between
these revisions.

Re: [PATCH] libstdc++-v3: Set 26_numerics/random/n.b.d./op./values.cc timeout-factor to 3

[Jonathan Wakely via Gcc-patches]

On Fri, 20 May 2022 at 10:03, Jonathan Wakely  wrote:
>
> On Fri, 20 May 2022 at 03:20, Hans-Peter Nilsson via Libstdc++
>  wrote:
> >
> > Also, how about shortening those test-suite file-paths?
> > They're path sort-of overlong for any git (and ChangeLog)
> > commit-line limit. 1/2 :-)
>
> Yes, they're silly. I like what libc++ does, i.e. name the testsuite
> directories after the [stable.name] tags in the standard. They have
> std/rand/rand.dis/rand.dist.bern/rand.dist.bern.negbin (for some
> reason they use "rand.dis" instead of "rand.dist" for the third
> component there, which is not what the standard has,
> https://eel.is/c++draft/rand.dist.bern.negbin shows the subclause
> hierarchy).
>
> That's still quite unwieldy, so we could remove the repetition and use
> 26_numerics/rand/dist/bernoulli/negbin/. The problem now is that it
> gets quite cryptic, so finding the tests for the
> negative_binomial_distribution is a bit harder if you don't know where
> to look (but git grep solves that in less than a second).

Or we could forget about mirroring the nesting in the standard and
just use 26_numerics/random/dist/negative_binomial

That's still too long for ChangeLogs though.

Re: [RFC Linux patch] powerpc: add documentation for HWCAPs

[Michael Ellerman]

Nicholas Piggin via Libc-alpha  writes:
> This takes the arm64 file and adjusts it for powerpc. Feature
> descriptions are vaguely handwaved by me.
> ---

Thanks for attempting to document this.

> Anybody care to expand on or correct the meaning of these entries or
> bikeshed the wording of the intro? Many of them are no longer used
> anywhere by upstream kernels and even where they are it's not always
> quite clear what the exact intent was, a lot of them are old history
> and I don't know what or where they are used.
>
> I may try to get these descriptions pushed into the ABI doc after a
> time, but for now they can live in the kernel tree.
>
> Thanks,
> Nick
>
>  Documentation/powerpc/elf_hwcaps.rst | 192 +++
>  1 file changed, 192 insertions(+)
>  create mode 100644 Documentation/powerpc/elf_hwcaps.rst
>
> diff --git a/Documentation/powerpc/elf_hwcaps.rst 
> b/Documentation/powerpc/elf_hwcaps.rst
> new file mode 100644
> index ..d712aae8b867
> --- /dev/null
> +++ b/Documentation/powerpc/elf_hwcaps.rst
> @@ -0,0 +1,192 @@
> +.. _elf_hwcaps_index:
> +
> +==
> +POWERPC ELF hwcaps
> +==
> +
> +This document describes the usage and semantics of the powerpc ELF hwcaps.
> +
> +
> +1. Introduction
> +---
> +
> +Some hardware or software features are only available on some CPU
> +implementations, and/or with certain kernel configurations, but have no
> +architected discovery mechanism available to userspace code. The kernel

By "no architected discovery mechanism" you mean nothing in the ISA, but
I think a reader might not understand that. After all HWCAP is an
"architected discovery mechanism", architected by the kernel and libc.

Maybe just say "no other discovery mechanism".

> +exposes the presence of these features to userspace through a set
> +of flags called hwcaps, exposed in the auxilliary vector.
>
> +
> +Userspace software can test for features by acquiring the AT_HWCAP or
> +AT_HWCAP2 entry of the auxiliary vector, and testing whether the relevant
> +flags are set, e.g.::
> +
> + bool floating_point_is_present(void)
> + {
> + unsigned long hwcaps = getauxval(AT_HWCAP);
> + if (hwcaps & PPC_FEATURE_HAS_FPU)
> + return true;
> +
> + return false;
> + }
> +
> +Where software relies on a feature described by a hwcap, it should check
> +the relevant hwcap flag to verify that the feature is present before
> +attempting to make use of the feature.
> +
> +Features cannot be probed reliably through other means. When a feature
> +is not available, attempting to use it may result in unpredictable
> +behaviour, and is not guaranteed to result in any reliable indication
> +that the feature is unavailable, such as a SIGILL.

I'd just drop the "such as a SIGILL", don't give people ideas :)

> +2. hwcap allocation
> +---
> +
> +HWCAPs are allocated as described in Power Architecture 64-Bit ELF V2 ABI

Are we calling them hwcaps or HWCAPs?

> +Specification (which will be reflected in the kernel's uapi headers).
> +
> +3. The hwcaps exposed in AT_HWCAP
> +-
> +
> +PPC_FEATURE_32
> +32-bit CPU
> +
> +PPC_FEATURE_64
> +64-bit CPU (userspace may be running in 32-bit mode).
> +
> +PPC_FEATURE_601_INSTR
> +The processor is PowerPC 601

Unused in the kernel since:
  f0ed73f3fa2c ("powerpc: Remove PowerPC 601")

> +PPC_FEATURE_HAS_ALTIVEC
> +Vector (aka Altivec, VSX) facility is available.
> +
> +PPC_FEATURE_HAS_FPU
> +Floating point facility is available.
> +
> +PPC_FEATURE_HAS_MMU
> +Memory management unit is present.
> +
> +PPC_FEATURE_HAS_4xxMAC
> +?

First appeared in v2.4.9.2, as part of "Paul Mackerras: PPC update (big 
re-org)":

  
https://github.com/mpe/linux-fullhistory/commit/dccd38599dad0588f4fb254c0a188b7c70af02e1

No extra context I can see.

I think all our 4xx (40x or 44x) CPUs have that set, so seems like it
just means "is a 40x or 44x".

> +PPC_FEATURE_UNIFIED_CACHE
> +?

Unused in the kernel since:
  39c8bf2b3cc1 ("powerpc: Retire e200 core (mpc555x processor)")

> +PPC_FEATURE_HAS_SPE
> +?

AFAIK means the CPU supports SPE (Signal Processing Engine) instructions.

They were documented in ISA v2.07 Book I chapter 8.

Not to be confused with the Cell SPEs.

I think GCC has dropped support for SPE, so at some point we may want to
drop the kernel support also, as it will be increasingly untested.

> +PPC_FEATURE_HAS_EFP_SINGLE
> +?

Seems to be SPE related, only set on CPUs that also have SPE.

> +PPC_FEATURE_HAS_EFP_DOUBLE
> +?

As above.

> +PPC_FEATURE_NO_TB
> +The timebase facility (mftb instruction) is not available.
> +

Unused in the kernel since:
  f0ed73f3fa2c ("powerpc: Remove PowerPC 601")

> +PPC_FEATURE_POWER4
> +The processor is POWER4.

We dropped Power4 support in:

  471d7ff8b51b ("powerpc/64s: Remove POWER4 support")

But that bit is still set 

[Bug tree-optimization/101668] BB vectorizer doesn't handle lowpart of existing vector

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
Guess we need to extend backend hook to handle different input and output
modes.

[Bug target/105513] [9/10/11/12/13 Regression] Unnecessary SSE spill since r9-5748-g1d4b4f4979171ef0

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Hongtao.liu  ---
(In reply to Alexander Monakov from comment #7)
> The second sequence is 3 uops vs 1/2 (issued/executed) uops in first, and on
> Haswell and Skylake it ties up port 5 for two cycles.
> 
> Unclear if you're microbenchmarking latency or throughput, but in any case
> on Haswell and Skylake you should see a close to 2x difference.

I'm counting clocksticks, and thought a load may take more latency.

#include 
#include 
#include 

#define LOOP 10
typedef long v2di __attribute__((vector_size(16)));
typedef int v4si __attribute__((vector_size(16)));

v2di
__attribute__ ((noipa))
foo (v2di a)
{
a[1] = 13;
return a;
}

void
__attribute__ ((noipa))
foo1 (v2di a)
{
}

int
main ()
{
  int i;
  unsigned long long start, end;
  unsigned long long diff;
  unsigned int aux;

  start = __rdtscp ();
  v2di b = __extension__ (v2di){111, 222};
  for (i = 0; i < LOOP; i++)
{
  v2di a = foo (b);
  foo1 (a);
}
  end = __rdtscp ();
  diff = end - start;
  printf ("alterna: %lld\n", diff);

  return 0;
}

Re: [PATCH] libstdc++-v3: Set 26_numerics/random/n.b.d./op./values.cc timeout-factor to 3

[Jonathan Wakely via Gcc-patches]

On Fri, 20 May 2022 at 03:20, Hans-Peter Nilsson via Libstdc++
 wrote:
>
> Also, how about shortening those test-suite file-paths?
> They're path sort-of overlong for any git (and ChangeLog)
> commit-line limit. 1/2 :-)

Yes, they're silly. I like what libc++ does, i.e. name the testsuite
directories after the [stable.name] tags in the standard. They have
std/rand/rand.dis/rand.dist.bern/rand.dist.bern.negbin (for some
reason they use "rand.dis" instead of "rand.dist" for the third
component there, which is not what the standard has,
https://eel.is/c++draft/rand.dist.bern.negbin shows the subclause
hierarchy).

That's still quite unwieldy, so we could remove the repetition and use
26_numerics/rand/dist/bernoulli/negbin/. The problem now is that it
gets quite cryptic, so finding the tests for the
negative_binomial_distribution is a bit harder if you don't know where
to look (but git grep solves that in less than a second).



>
> Ok to commit (without renaming)?

I'm OK with the timeout factor, but we could also solve it differently
so that it doesn't take nearly 5 minutes, as in the attached patch.
The testDiscreteDist function can be parametrized with the number of
iterations to perform. Would you rather do that?
diff --git 
a/libstdc++-v3/testsuite/26_numerics/random/negative_binomial_distribution/operators/values.cc
 
b/libstdc++-v3/testsuite/26_numerics/random/negative_binomial_distribution/operators/values.cc
index dda6f43b254..a3120401d09 100644
--- 
a/libstdc++-v3/testsuite/26_numerics/random/negative_binomial_distribution/operators/values.cc
+++ 
b/libstdc++-v3/testsuite/26_numerics/random/negative_binomial_distribution/operators/values.cc
@@ -26,6 +26,14 @@
 #include 
 #include 
 
+// { dg-options "-DSIMULATOR_TEST" { target simulator } }
+
+#ifdef SIMULATOR_TEST
+# define ARGS 100, 1000
+#else
+# define ARGS
+#endif
+
 void test01()
 {
   using namespace __gnu_test;
@@ -34,18 +42,18 @@ void test01()
 
   std::negative_binomial_distribution<> nbd1(5, 0.3);
   auto bnbd1 = std::bind(nbd1, eng);
-  testDiscreteDist(bnbd1, [](int n)
-  { return negative_binomial_pdf(n, 5, 0.3); } );
+  testDiscreteDist(bnbd1, [](int n)
+{ return negative_binomial_pdf(n, 5, 0.3); } );
 
   std::negative_binomial_distribution<> nbd2(55, 0.3);
   auto bnbd2 = std::bind(nbd2, eng);
-  testDiscreteDist(bnbd2, [](int n)
-  { return negative_binomial_pdf(n, 55, 0.3); } );
+  testDiscreteDist(bnbd2, [](int n)
+{ return negative_binomial_pdf(n, 55, 0.3); } );
 
   std::negative_binomial_distribution<> nbd3(10, 0.75);
   auto bnbd3 = std::bind(nbd3, eng);
-  testDiscreteDist(bnbd3, [](int n)
-  { return negative_binomial_pdf(n, 10, 0.75); } );
+  testDiscreteDist(bnbd3, [](int n)
+{ return negative_binomial_pdf(n, 10, 0.75); } );
 }
 
 int main()

[Bug tree-optimization/101668] BB vectorizer doesn't handle lowpart of existing vector

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Some pending enhancements would allow us to use VEC_PERM_EXPR with different
input modes from output mode and thus make implementation of this easier.
vectorizable_slp_permutation doesn't yet support that though.

For the special case of a contiguous permutation we can also vectorize it
as BIT_FIELD_REF of course.

[Bug target/105513] [9/10/11/12/13 Regression] Unnecessary SSE spill since r9-5748-g1d4b4f4979171ef0

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

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

--- Comment #7 from Alexander Monakov  ---
The second sequence is 3 uops vs 1/2 (issued/executed) uops in first, and on
Haswell and Skylake it ties up port 5 for two cycles.

Unclear if you're microbenchmarking latency or throughput, but in any case on
Haswell and Skylake you should see a close to 2x difference.

[Bug target/105513] [9/10/11/12/13 Regression] Unnecessary SSE spill since r9-5748-g1d4b4f4979171ef0

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Hongtao.liu  ---
Also notice a intersting case impacted by a separate m alternatvie.

typedef long v2di __attribute__((vector_size(16)));

v2di
foo (v2di a)
{
  a[1] = 1113;
  return a;
}

with -O2 gcc generates

foo(long __vector(2)):
movhps  .LC0(%rip), %xmm0
ret
.LC0:
.quad   1113

llvm has

foo(long __vector(2)):# @foo(long __vector(2))
movl$1113, %eax # imm = 0x459
movq%rax, %xmm1
punpcklqdq  %xmm1, %xmm0# xmm0 = xmm0[0],xmm1[0]
retq

Microbenchmark show both both sequences are almost as fast, really don't know
which is better.

[Bug tree-optimization/102844] [9/10/11/12/13 Regression] DOM jump threading not copying block that became non-empty

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

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

--- Comment #25 from Richard Biener  ---
I'm not sure about the state of this bug - the issue reproduces on the GCC 10
branch with checking enabled and -O[2s] -fdisable-tree-fre4
-fno-strict-overflow

It might be that using the backward threader from DOM (are we now doing that?)
makes this truly fixed but I'm not sure the backward threader is resilent
to the issue analyzed in comments #13 to #15.  Eventually the NOCOPY
special-casing could be removed as premature optimization (CFG cleanup will
remove any copied forwarders), but then IIRC we have a hard limit on the
number of blocks the threader handles.

Re: [PATCH] Add divide by zero side effect.

[Alexander Monakov via Gcc-patches]

On Fri, 20 May 2022, Richard Biener wrote:

> On Fri, May 20, 2022 at 8:38 AM Alexander Monakov  wrote:
> >
> > On Fri, 20 May 2022, Richard Biener via Gcc-patches wrote:
> >
> > > > Still waiting for a suggestion, since "side effect" is the description
> > > > that made sense to me :-)
> > >
> > > I think side-effect captures it quite well even if it overlaps with a term
> > > used in language standards.  Doing c = a << b has the side-effect on
> > > imposing a range on 'b' rather than just affecting 'c' (and its range).
> > > You could call it 'alternate effect' but that sounds just awkward ;)
> >
> > I suggest 'deduce', 'deduction', 'deducing a range'. What the code is 
> > actually
> > doing is deducing that 'b' in 'a / b' cannot be zero. Function in GCC might 
> > be
> > called like 'deduce_ranges_from_stmt'.
> 
> So how would you call determining the range of 'c' from the ranges of
> 'a' and 'b', isn't that 'deduction' as well?

Kind of, yes, but for this sort of forward inference I imagine you're already
using 'propagate [ranges through a stmt]', like in 'value range propagation'.

If you'd like to avoid 'propagate'/'deduce' asymmetry, I could suggest
'forward inference' / 'backward inference', but I like it a bit less.

Alexander

Re: [PATCH] Add divide by zero side effect.

[Eric Botcazou via Gcc-patches]

> I think side-effect captures it quite well even if it overlaps with a term
> used in language standards.

IMO it's very confusing, see the subject: "Add divide by zero side effect".
The only side effect of dividing by zero is (possibly) raising a trap.

-- 
Eric Botcazou

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

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

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2