Re: avx512erintrin.h: uninitialized variable warning (optimized build)
Thanks, Sam, Yep, that does seem closely related. The problems mentioned there look similar enough that it may be possible to resolve an entire class of these problems in the same area of the code in a single pass. I'll add some more details there soon. On Thu, 12 Jan 2023 at 06:51, Sam James wrote: > > > > > On 12 Jan 2023, at 00:26, James Addison via Gcc wrote: > > > > Hi, > > > > During GCC 12.2.0 compilation of a file that includes[1] immintrin.h > > with both code-optimization and uninitialized-variable-warnings > > enabled, a warning is emitted: > > > >/usr/lib/gcc/x86_64-linux-gnu/12/include/avx512erintrin.h:55:20: > > warning: ‘__W’ is used uninitialized [-Wuninitialized] > > > > The minimal repro compilation command appears to be: > > > >gcc -O -Wuninitialized -mavx512er -mavx512pf > > ./numpy/distutils/checks/cpu_avx512_knl.c > > > > My question is: does the warning indicate a possible bug that should > > be reported, or is there a reason that the relevant code[2] does not > > initialize the variable (for example, for performance reasons)? > > See also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105593, might > be the same thing?
LTO apparently does not support _FloatNx types
Hi, I was investigating an ICE (in our yet to be upstreamed back-end which has native support for float16), on "gcc.dg/torture/float16-complex.c" when compiled with lto: ./gcc/build/gcc/xgcc -B./gcc/build/gcc/ ./gcc/gcc/testsuite/gcc.dg/torture/float16-complex.c \ -O2 -flto -fno-use-linker-plugin -flto-partition=none -lm -o ./float16-complex.exe I narrowed it down to the fact that lto-lang does not support _FloatNx types, the function "lto_type_for_mode" (in gcc/lto/lto-lang.c) and "c_common_type_for_mode" (in gcc/c-family/c-common.c) are exactly the same except that "lto_type_for_mode" does not support _FloatNx. Is this intentional or an oversight? Cheers, Paul
Re: LRA produces RTL not meeting constraint
On Wed, Jan 11, 2023 at 07:38:44PM -0500, Paul Koning wrote:
> > On Jan 11, 2023, at 2:52 PM, Segher Boessenkool
> > wrote:
> > On Tue, Jan 10, 2023 at 02:39:34PM -0500, Paul Koning via Gcc wrote:
> > Before reload it did not have operands[0] and operands[1] the same,
> > already?
>
> No, and given that it's an addhi3 pattern that is fine before reload. It's
> reload that has to make them match because the machine instruction is two
> operand.
Sure. And one here is a pseudo, so it actually *can* reasonably be
tied.
> Indeed. So does that mean the discussion about insn 48 is the interesting
> one? That goes on for a while:
No, the insns 49 one is the useful one.
2 Non-pseudo reload: reject+=2
2 Non input pseudo reload: reject++
alt=0,overall=9,losers=1,rld_nregs=1
alt=1,overall=0,losers=0,rld_nregs=0
1 Matching alt: reject+=2
1 Non-pseudo reload: reject+=2
1 Non input pseudo reload: reject++
alt=0,overall=11,losers=1 -- refuse
1 Matching alt: reject+=2
1 Non-pseudo reload: reject+=2
1 Non input pseudo reload: reject++
alt=1,overall=11,losers=1 -- refuse
0 Spill pseudo into memory: reject+=3
Using memory insn operand 0: reject+=3
0 Non input pseudo reload: reject++
alt=2,overall=13,losers=1 -- refuse
0 Spill pseudo into memory: reject+=3
Using memory insn operand 0: reject+=3
0 Non input pseudo reload: reject++
alt=3,overall=13,losers=1 -- refuse
Choosing alt 1 in insn 49: (0) rR (1) 0 (2) Qi {addhi3}
For all four constraints it could tie operands[1] to it got "refuse".
This can't be good.
> > Please show *all* relevant things in the reload dump file? Everything
> > about insn 49 or any insn added to reload it, for example.
>
> I didn't see anything added to 49, but I'm not sure if I would necessarily
> recognize it. One observation is that the previous and next insns numbers
> are 48 and 53 in the IRA and Reload dumps both.
It would look like e.g.
Inserting insn reload before:
413: r179:SI=r25:SI
or
Inserting insn reload after:
414: r45:SI=r179:SI
> Attached is a .i file produced from the failing compile, with unneeded parts
> removed. It's not really tiny but not all that large. It consistently shows
> the failure using a pdp11-aout targeted GCC built from yesterday's code, when
> using -O2 or -Os and -mlra. It doesn't fail with -O1 or if -mlra is omitted
> (defaulting, in the currently committed code, to old reload).
It helped, I can reproduce the problem. Thanks!
Open a PR for the problem? So that people can cooperate on it easier,
and to battle the "attention span of a goldfish" problem?
Segher
Re: LTO apparently does not support _FloatNx types
> Am 12.01.2023 um 17:18 schrieb Paul Iannetta via Gcc : > > Hi, > > I was investigating an ICE (in our yet to be upstreamed back-end which > has native support for float16), on "gcc.dg/torture/float16-complex.c" > when compiled with lto: > > ./gcc/build/gcc/xgcc -B./gcc/build/gcc/ > ./gcc/gcc/testsuite/gcc.dg/torture/float16-complex.c \ > -O2 -flto -fno-use-linker-plugin -flto-partition=none -lm -o > ./float16-complex.exe > > I narrowed it down to the fact that lto-lang does not support _FloatNx > types, the function "lto_type_for_mode" (in gcc/lto/lto-lang.c) and > "c_common_type_for_mode" (in gcc/c-family/c-common.c) are exactly the > same except that "lto_type_for_mode" does not support _FloatNx. > > Is this intentional or an oversight? It’s probably an oversight. > Cheers, > Paul > > > >
Re: Default initialization of poly-ints
Jeff Law via Gcc writes: > On 1/3/23 04:16, Florian Weimer via Gcc wrote: >> It seems that the default constructor of the non-POD poly-ints does >> nothing. Is this intentional? I expected zero initialization, to match >> regular ints. > I think it was intentional. Richard Sandiford would know for sure. But > Martin Sebor might know as well since I think they discussed it at > length a little while back. Yeah, it was intentional, to try to get -Wunitialized warnings. But it predates C++11 being required, so = default would probably be a better choice now. Thanks, Richard
gcc-10-20230112 is now available
Snapshot gcc-10-20230112 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20230112/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-10 revision b9d05556774dfc29b091d426e69c9171d9e0fc1f You'll find: gcc-10-20230112.tar.xz Complete GCC SHA256=6beb7da398021a61dffe489dc9ae21c8a55c76fce0714094045780f832be67b1 SHA1=4638b51a52dffeab280318b26c98c88f6e0db007 Diffs from 10-20230105 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 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: LTO apparently does not support _FloatNx types
On Thu, Jan 12, 2023 at 5:35 PM Richard Biener wrote: > > > > > Am 12.01.2023 um 17:18 schrieb Paul Iannetta via Gcc : > > > > Hi, > > > > I was investigating an ICE (in our yet to be upstreamed back-end which > > has native support for float16), on "gcc.dg/torture/float16-complex.c" > > when compiled with lto: > > > > ./gcc/build/gcc/xgcc -B./gcc/build/gcc/ > > ./gcc/gcc/testsuite/gcc.dg/torture/float16-complex.c \ > > -O2 -flto -fno-use-linker-plugin -flto-partition=none -lm -o > > ./float16-complex.exe > > > > I narrowed it down to the fact that lto-lang does not support _FloatNx > > types, the function "lto_type_for_mode" (in gcc/lto/lto-lang.c) and > > "c_common_type_for_mode" (in gcc/c-family/c-common.c) are exactly the > > same except that "lto_type_for_mode" does not support _FloatNx. > > > > Is this intentional or an oversight? > > It’s probably an oversight. I'm testing a patch to sync them up. Richard. > > > Cheers, > > Paul > > > > > > > >
