[Bug target/97142] __builtin_fmod not optimized on POWER

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

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

--- Comment #10 from luoxhu at gcc dot gnu.org ---

If not built with fast-math, gimple_has_side_effects will return true and cause
the expand_call_stmt fail to expand the "_1 = fmod (x_2(D), y_3(D));" to
internal function. X86 also produces "bl fmod" for O3 build.


xlF expands the fmod to below ASM, no FMA generated?


1900 :
1900:   8c 03 01 10 vspltisw v0,1
1904:   00 00 24 c8 lfd f1,0(r4)
1908:   00 00 03 c8 lfd f0,0(r3)
190c:   e2 03 40 f0 xvcvsxwdp vs2,vs32
1910:   c0 09 62 f0 xsdivdp vs3,vs2,vs1
1914:   80 19 80 f0 xsmuldp vs4,vs0,vs3
1918:   64 21 a0 f0 xsrdpiz vs5,vs4
191c:   88 2d 01 f0 xsnmsubadp vs0,vs1,vs5
1920:   18 00 20 fc frspf1,f0
1924:   20 00 80 4e blr

[Bug libstdc++/100057] There are no freestanding C++

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #14 from cqwrteur  ---
there is another stuff mentioned in osdev. we need to disable red zone. we need
redzone multilib

https://wiki.osdev.org/Libgcc_without_red_zone

I suggest to add this into gcc itself

[Bug libstdc++/100057] There are no freestanding C++

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #13 from cqwrteur  ---
../gcc/configure --disable-nls --disable-bootstrap --disable-hosted-libstdcxx
--disable-werror --with-newlib --target=x86_64-elf
--prefix=/home/cqwrteur/elf_toolchain/x86_64-elf --without-headers
--with-newlib --disable-libstdcxx-verbose --enable-languages=c,c++
--disable-libquadmath --disable-libssp

Finally got the shit working. so frustrating.

Can we just disable those stuff by default if we put --disable-hosted-libstdcxx
here?

it will disable all languages besides c, c++. libgcc will be built with
-ffreestanding. quadmath, ssp whatever would get disabled. and
--without-headers and --with-newlib should work here?

And cstdint header file does not work either since it fails to detect stdint.h
for configure at build time.

Although manually remove the __HAVE_STDINT_H__ macro and include stdint.h would
work.

[Bug libstdc++/100057] There are no freestanding C++

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #12 from cqwrteur  ---
malloc, free, memset does not exist either.

Need to replace them with __builtin_malloc, __builtin_free, __builtin_memset if
that is available.

Then it is libquadmath's issue. no errno.h


In file included from ../../../gcc/libquadmath/math/llroundq.c:21:
../../../gcc/libquadmath/quadmath-imp.h:24:10: fatal error: errno.h: No such
file or directory
   24 | #include 

[Bug c++/97134] partial specialization not more specialized when using CNTTP

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick Palka  ---
Fixed for GCC 11, thanks for the bug reports.

[Bug c++/97134] partial specialization not more specialized when using CNTTP

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

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

commit r11-8145-gc755e1b3eadaf1c7e751a2c7ce1d418c6db8463a
Author: Patrick Palka 
Date:   Mon Apr 12 23:22:03 2021 -0400

c++: variadic class template placeholder deduction [PR97134]

do_class_deduction handles specially the case where we're deducing one
placeholder from another equivalent one, but here the initializer passed
to do_class_deduction is wrapped in an EXPR_PACK_EXPANSION (we're being
called from unify during get_partial_spec_bindings).  This patch makes
do_class_deduction look through EXPR_PACK_EXPANSIONs so that we detect
this case as well.

gcc/cp/ChangeLog:

PR c++/97134
* pt.c (do_class_deduction): Look through EXPR_PACK_EXPANSION
when checking if the initializer is an equivalent class
placeholder template parameter.

gcc/testsuite/ChangeLog:

PR c++/97134
* g++.dg/cpp2a/nontype-class43.C: New test.

[Bug middle-end/90323] powerpc should convert equivalent sequences to vec_sel()

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

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

--- Comment #15 from luoxhu at gcc dot gnu.org ---
(In reply to Segher Boessenkool from comment #14)
> (In reply to luoxhu from comment #12)
> > That code was called by combine pass but fail to match. 
> 
> > 
> > pr newpat
> > (set (reg:DI 125 [ l ])
> > (xor:DI (and:DI (xor:DI (reg/v:DI 120 [ l ])
> > (reg:DI 127))
> > (const_int 267390975 [0xff00fff]))
> > (reg/v:DI 120 [ l ])))
> 
> Note this is 0x0ff00fff, and this is not a valid mask for rlwimi.

OK, it also fails to combine for 0x0100.


.cfi_startproc
xor 4,3,4
rlwinm 4,4,0,7,7
xor 3,4,3
blr

[Bug c++/99994] internal compiler error: trying to capture 'f' in instantiation of generic lambda within constraints_satisfied_p

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||ppalka at gcc dot gnu.org
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Patrick Palka  ---
Fixed for GCC 11, thanks for the bug report.

[Bug c++/99961] requires clause rejects mentioning of function parameters too early

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick Palka  ---
Fixed for GCC 11, thanks for the bug report.

[Bug c++/99961] requires clause rejects mentioning of function parameters too early

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:59d9aa6d2efe7c52b6a986eb3e1977c1fb3c5753

commit r11-8144-g59d9aa6d2efe7c52b6a986eb3e1977c1fb3c5753
Author: Patrick Palka 
Date:   Mon Apr 12 22:54:55 2021 -0400

c++: constraints are unevaluated operands [PR99961]

According to [temp.concept]/6 and [temp.pre]/9, a concept definition and
a requires clause are both unevaluated contexts, and hence satisfaction
deals only with unevaluated operands, so we should set cp_unevaluated in
these three situations.

gcc/cp/ChangeLog:

PR c++/99961
PR c++/4
* constraint.cc (satisfy_normalized_constraints): Set
cp_unevaluated.
* parser.c (cp_parser_concept_definition): Likewise.
(cp_parser_requires_clause_opt): Likewise.

gcc/testsuite/ChangeLog:

PR c++/99961
PR c++/4
* g++.dg/cpp2a/concepts-uneval1.C: New test.
* g++.dg/cpp2a/concepts-uneval2.C: New test.

[Bug c++/99994] internal compiler error: trying to capture 'f' in instantiation of generic lambda within constraints_satisfied_p

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Patrick Palka :

https://gcc.gnu.org/g:59d9aa6d2efe7c52b6a986eb3e1977c1fb3c5753

commit r11-8144-g59d9aa6d2efe7c52b6a986eb3e1977c1fb3c5753
Author: Patrick Palka 
Date:   Mon Apr 12 22:54:55 2021 -0400

c++: constraints are unevaluated operands [PR99961]

According to [temp.concept]/6 and [temp.pre]/9, a concept definition and
a requires clause are both unevaluated contexts, and hence satisfaction
deals only with unevaluated operands, so we should set cp_unevaluated in
these three situations.

gcc/cp/ChangeLog:

PR c++/99961
PR c++/4
* constraint.cc (satisfy_normalized_constraints): Set
cp_unevaluated.
* parser.c (cp_parser_concept_definition): Likewise.
(cp_parser_requires_clause_opt): Likewise.

gcc/testsuite/ChangeLog:

PR c++/99961
PR c++/4
* g++.dg/cpp2a/concepts-uneval1.C: New test.
* g++.dg/cpp2a/concepts-uneval2.C: New test.

[Bug libstdc++/100057] There are no freestanding C++

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #11 from cqwrteur  ---
  if test x$gcc_no_link = xyes; then
  as_fn_error $? "Link tests are not allowed after GCC_NO_EXECUTABLES."
"$LINENO" 5


These tests are very wrong tbh. freestanding environment of course, does not
have those stuffs.

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

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

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Hans-Peter Nilsson :

https://gcc.gnu.org/g:07b27384de56ce2f6a93007d018743ef9d5c8cc4

commit r11-8143-g07b27384de56ce2f6a93007d018743ef9d5c8cc4
Author: Hans-Peter Nilsson 
Date:   Tue Apr 13 04:08:08 2021 +0200

gcc.dg/analyzer/data-model-1.c: Inverse xfail for cris-*-*, PR99212

See PR99212.  Now, cris-elf isn't the only target for which this line
shows a failure; pru-unknown-elf and m68k-unknown-linux-gnu are two
others.  I'll leave adjustments to the respective maintainers, but
trivially appending more triplets should work: no extra bracketing needed.
A specific effective_target specifier would as always be perferable, but I
couldn't without accountable effort find out what was the common factor.

Besides cris-elf, sanity-checked for native x86_64-*-linux*.

gcc/testsuite:
PR analyzer/99212
* gcc.dg/analyzer/data-model-1.c (test_45): Inverse xfail at
line 971 for cris-*-*.

[Bug analyzer/99212] [11 Regression] gcc.dg/analyzer/data-model-1.c line 971

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

   Keywords||xfail

--- Comment #12 from Hans-Peter Nilsson  ---
(In reply to David Malcolm from comment #11)
> I experimented with fixing this properly so that it works for all targets,
> but the fix involves adding a new region subclass to handle bitfields, and
> so feels far too risky for GCC 11.
> 
> Hence this should be XFAILed for GCC 11; I'm not yet sure exactly what the
> target selector should be.

Me fix.  Thanks for looking.

[Bug libstdc++/100057] There are no freestanding C++

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #10 from cqwrteur  ---
I guess nobody ever tries to build freestanding before. It just does not work
tbh.

[Bug libstdc++/100057] There are no freestanding C++

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #9 from cqwrteur  ---
looking for a compliant stdint.h in stdint.h, checking for uintmax_t... no
looking for a compliant stdint.h in inttypes.h, checking for uintmax_t... no
looking for a compliant stdint.h in sys/inttypes.h, checking for uintmax_t...
no
looking for an incomplete stdint.h in stdint.h, checking for uint32_t... no
looking for an incomplete stdint.h in inttypes.h, checking for uint32_t... no
looking for an incomplete stdint.h in sys/inttypes.h, checking for uint32_t...
no
looking for u_intXX_t types in sys/types.h, checking for u_int32_t... no
looking for u_intXX_t types in inttypes.h, checking for u_int32_t... no
looking for u_intXX_t types in sys/inttypes.h, checking for u_int32_t... no
checking what to include in include/gstdint.h... stddef.h (using manual
detection)
checking size of void *... 0
checking size of long... 0
checking size of int... 0
checking size of short... 0
checking size of char... 0
checking for type equivalent to int8_t... configure: error: no 8-bit type,
please report a bug
make[1]: *** [Makefile:13313: configure-target-libstdc++-v3] Error 1
make[1]: Leaving directory '/home/cqwrteur/myhome/gcc2_elf_build'
make: *** [Makefile:965: all] Error 2

The issue is that there is no such header called stdint.h. What we have is
stdint-gcc.h which is automatically generated by the compiler.

We have two options.
1. just redefine them in cstdint with freestanding.
2. use autotool to include stdint-gcc.h when stdint.h does not exist.

[Bug target/100009] [9 Regression] -march=native doesn't work on tigerlake

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---

> Oops,
> will backport r10-2664-ga9fcfec30f70c30883f53d4b1bd533fbea0e9fb2 (tigerlake
> part) to gcc9.

PTA_AVX512VP2INTERSECT is enabled in GCC10, don't plan to backport to gcc9, so
in GCC9 -march=native wouldn't enable -mavx512vp2intersect, also kl and widekl.

[Bug libstdc++/100057] There are no freestanding C++

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #8 from cqwrteur  ---
Created attachment 50576
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50576&action=edit
Disable checking these macros with freestanding settings

We predefine them if they do not exist in Freestanding.

[Bug libstdc++/100057] There are no freestanding C++

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #7 from cqwrteur  ---
I think the libstdc++'s scripting issue I can fix it.

[Bug libstdc++/100057] There are no freestanding C++

[phdofthehouse at gmail dot com via Gcc-bugs]

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

--- Comment #6 from JeanHeyd Meneide  ---
Oh, woops, my bad. This is for configuring and building GCC. I'm not sure which
option turns on -ffreestanding for building the compiler itself! But it seems
like that's missing, if __STDC_HOSTED__ is not 0.

[Bug analyzer/100042] ICE in gimple_call_set_fndecl with -Os -fsanitize=undefined -flto -fanalyzer

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

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

--- Comment #1 from David Malcolm  ---
I'm not able to reproduce this, but I just committed a fix for PR 98599; does
that fix this for you also?

[Bug libstdc++/100057] There are no freestanding C++

[phdofthehouse at gmail dot com via Gcc-bugs]

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

JeanHeyd Meneide  changed:

   What|Removed |Added

 CC||phdofthehouse at gmail dot com

--- Comment #5 from JeanHeyd Meneide  ---
Hey, so, I'm not much of a contributor anymore, but like. Are you sure you got
everything passed to the compiler correctly?

I was under the impression in order to turn of __STDC_HOSTED__, you need to
pass

-ffreestanding

? That defines __STDC_HOSTED__ to 0, which should make those definition checks
choose the non-__STDC_HOSTED__ branches for the #if (as shown in this basic
test: https://godbolt.org/z/7acoPT13M)

https://gcc.gnu.org/onlinedocs/gcc/Standards.html#Standards

[Bug analyzer/98599] [11 Regression] fatal error: Cgraph edge statement index out of range with -Os -flto -fanalyzer

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

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

David Malcolm  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|WAITING |RESOLVED

--- Comment #14 from David Malcolm  ---
Should be fixed by the above patch, though it's more of a workaround for now;
am still not sure about what's going on with clones.

[Bug analyzer/98599] [11 Regression] fatal error: Cgraph edge statement index out of range with -Os -flto -fanalyzer

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

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:17f3c2b8ac477b07ca0aafbc7d74ba305dc1ee33

commit r11-8142-g17f3c2b8ac477b07ca0aafbc7d74ba305dc1ee33
Author: David Malcolm 
Date:   Mon Apr 12 21:13:40 2021 -0400

gimple UIDs, LTO and -fanalyzer [PR98599]

gimple.h has this comment for gimple's uid field:

  /* UID of this statement.  This is used by passes that want to
 assign IDs to statements.  It must be assigned and used by each
 pass.  By default it should be assumed to contain garbage.  */
  unsigned uid;

and gimple_set_uid has:

   Please note that this UID property is supposed to be undefined at
   pass boundaries.  This means that a given pass should not assume it
   contains any useful value when the pass starts and thus can set it
   to any value it sees fit.

which suggests that any pass can use the uid field as an arbitrary
scratch space.

PR analyzer/98599 reports a case where this error occurs in LTO mode:
  fatal error: Cgraph edge statement index out of range
on certain inputs with -fanalyzer.

The error occurs in the LTRANS phase after -fanalyzer runs in the
WPA phase.  The analyzer pass writes to the uid fields of all stmts.

The error occurs when LTRANS is streaming callgraph edges back in.
The LTO format uses stmt uids to associate call stmts with callgraph
edges between WPA and LTRANS.
For example, in lto-cgraph.c, lto_output_edge writes out the
gimple_uid, and input_edge reads it back in.

lto_prepare_function_for_streaming has code to renumber the stmt UIDs
when the code is streamed back out, but for some reason this isn't
called for clones:
307   /* Do body modifications needed for streaming before we fork out
308  worker processes.  */
309   FOR_EACH_FUNCTION_WITH_GIMPLE_BODY (node)
310 if (!node->clone_of && gimple_has_body_p (node->decl))
311   lto_prepare_function_for_streaming (node);

Hence the combination of -fanalyzer and -flto will fail in LTRANS's
stream-in if any function clones are encountered.

It's not fully clear to me why this isn't done for clones, and what the
correct fix should be to allow arbitrary changes to uids within WPA
passes.

In the meantime, this patch works around the issue by updating the
analyzer to save and restore the UIDs, fixing the error.

gcc/analyzer/ChangeLog:
PR analyzer/98599
* supergraph.cc (saved_uids::make_uid_unique): New.
(saved_uids::restore_uids): New.
(supergraph::supergraph): Replace assignments to stmt->uid with
calls to m_stmt_uids.make_uid_unique.
(supergraph::~supergraph): New.
* supergraph.h (class saved_uids): New.
(supergraph::~supergraph): New decl.
(supergraph::m_stmt_uids): New field.

gcc/testsuite/ChangeLog:
PR analyzer/98599
* gcc.dg/analyzer/pr98599-a.c: New test.
* gcc.dg/analyzer/pr98599-b.c: New test.

[Bug libstdc++/100057] There are no freestanding C++

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #4 from cqwrteur  ---
Try that without --with-newlib.


checking how to hardcode library paths into programs... immediate
checking for shl_load... configure: error: Link tests are not allowed after
GCC_NO_EXECUTABLES.
make[1]: *** [Makefile:13313: configure-target-libstdc++-v3] Error 1

[Bug c++/100054] [11 Regression] internal compiler error: in get_nsdmi

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

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

--- Comment #2 from Barry Revzin  ---
In case it helps, here's a different example which on trunk ICEs in get_nsdmi,
but on gcc 10.2 and 10.3 ICEs on "unexpected expression '(F)()' of kind implicit_conv_expr" (and is accepted by 10.1)

struct F {
private:
  int cx;
};

template 
void find() {
struct H {
F o{};
};
using r = decltype([](auto) { return H{}; }(0));
}

void p() {
  find();
}

[Bug libstdc++/100057] There are no freestanding C++

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #3 from cqwrteur  ---
Created attachment 50575
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50575&action=edit
The log file shows it does check stdio.h

conftest.c:10:10: fatal error: stdio.h: No such file or directory
   10 | #include 

This is just incorrect tbh.

[Bug c/100058] New: -Wpadded is inconsistent using -mms-bitfields

[the4naves at gmail dot com via Gcc-bugs]

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

Bug ID: 100058
   Summary: -Wpadded is inconsistent using -mms-bitfields
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: the4naves at gmail dot com
  Target Milestone: ---

// ---
#include 
#include 

struct {
uint16_t a;
uint8_t b;
} test1;

struct {
uint8_t b;
uint16_t a;
} test2;

int main() {
printf("Size 1: %d\n", sizeof(test1));
printf("Size 2: %d", sizeof(test2));

return 0;
}
// ---

Compiling this code using `gcc test.cpp -Wpadded -mms-bitfields` only gives a
padding warning for the test1 struct. The printed sizes are both 4. Replacing
`-mms-bitfields` with `-mno-ms-bitfields` gives the expected warnings for
(test1) and (test2.a). The marked gcc version is 10.3, but I was able to
replicate this in every version back to 4.4. 4.1 does seem to work correctly.

Exact version is 10.3.0 under x86_64-linux-gnu. Other than the padding warnings
(1 for ms-bitfields, 2 for no-ms-bitfields), no warnings are printed.

`gcc -v` gives:
Configured with: ../gcc-10.3.0/configure
--prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap
--enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32
--enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran,ada,go,d --enable-ld=yes --enable-gold=yes
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id
--enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=Compiler-Explorer-Build

Someone else suggested that the line `!targetm.ms_bitfield_layout_p (rli->t)`
in https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52238 could be the issue, which
to me seems likely from a brief look.

[Bug libstdc++/100057] There are no freestanding C++

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #2 from cqwrteur  ---
Then #if 0 the header.

checking for stdalign.h... no
checking for the value of EOF... configure: error: computing EOF failed
make[1]: *** [Makefile:13313: configure-target-libstdc++-v3] Error 1
make[1]: Leaving directory '/home/cqwrteur/myhome/gcc2_elf_build'
make: *** [Makefile:965: all] Error 2

It cannot find EOF.

So yes, libstdc++ requires stdio, even in a freestanding environment lol. I
love this :)

[Bug libstdc++/100057] There are no freestanding C++

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
The funny stuff is that __STDC_HOSTED__ should not be set as true. I guess GCC
incorrectly mark __STDC_HOSTED__ as 1 for C++, even we live in freestanding
environment.

#ifndef _GCC_WRAP_STDINT_H
#if __STDC_HOSTED__
# if defined __cplusplus && __cplusplus >= 201103L
#  undef __STDC_LIMIT_MACROS
#  define __STDC_LIMIT_MACROS
#  undef __STDC_CONSTANT_MACROS
#  define __STDC_CONSTANT_MACROS
# endif
# include_next 
#else
# include "stdint-gcc.h"
#endif
#define _GCC_WRAP_STDINT_H
#endif

[Bug libstdc++/100057] New: There are no freestanding C++

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 100057
   Summary: There are no freestanding C++
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 50574
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50574&action=edit
Error message

It is such a joke.

Although building GCC with newlib is perfectly fine, without it, it just does
not work dude.

There are no freestanding C++ :)

I am perfectly correct.

No stdint.h

I tried all combinations:

../gcc/configure --disable-nls --disable-bootstrap --disable-hosted-libstdcxx
--disable-werror --without-headers --target=x86_64-elf
--prefix=/home/cqwrteur/elf_toolchain/x86_64-elf --disable-shared

../gcc/configure --disable-nls --disable-bootstrap --disable-hosted-libstdcxx
--disable-werror --without-headers --target=x86_64-elf
--prefix=/home/cqwrteur/elf_toolchain/x86_64-elf --disable-shared --with-newlib

None of them work. They all could not find stdint.h

[Bug target/100056] New: [9/10/11 Regression]

[luc.vanoostenryck at gmail dot com via Gcc-bugs]

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

Bug ID: 100056
   Summary: [9/10/11 Regression]
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luc.vanoostenryck at gmail dot com
  Target Milestone: ---
Target: aarch64

Created attachment 50573
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50573&action=edit
or-shift vs. [us]bfiz

On arm64, the following code:
unsigned or_shift(unsigned char i)
{
return i | (i << 11);
}

translate to the following assembly:
or_shift:
and w1, w0, 255
ubfiz   w0, w0, 11, 8
orr w0, w0, w1
ret

where the ubfiz instruction is a bit weird since the code
matches directly what was generated in gcc 8.x and before:
or_shift:
and w0, w0, 255
orr w0, w0, w0, lsl 11
ret

Same with a signed argument (see https://gcc.godbolt.org/z/af4zffMYa ).

[Bug c++/100055] New: ICE on invalid requires expression

[ldalessandro at gmail dot com via Gcc-bugs]

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

Bug ID: 100055
   Summary: ICE on invalid requires expression
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ldalessandro at gmail dot com
  Target Milestone: ---

The following invalid code triggers a segfault.

```
void foo(auto&& arg) requires({});


:1:30: error: statement-expressions are not allowed outside functions
nor in template-argument lists
1 | void foo(auto&& arg) requires({});
  |  ^
:1:33: internal compiler error: Segmentation fault
1 | void foo(auto&& arg) requires({});
  | ^
0x1d01009 internal_error(char const*, ...)
???:0
0x7a1b17 grokdeclarator(cp_declarator const*, cp_decl_specifier_seq*,
decl_context, int, tree_node**)
???:0
0x7a7a78 start_decl(cp_declarator const*, cp_decl_specifier_seq*, int,
tree_node*, tree_node*, tree_node**)
???:0
0x8e230d c_parse_file()
???:0
0xa615b2 c_common_parse_file()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
ASM generation compiler returned: 1
```

live example: https://godbolt.org/z/qjWWWchjo

[Bug rtl-optimization/99905] [8/9/10 Regression] wrong code with -mno-mmx -mno-sse since r7-4540-gb229ab2a712ccd44

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10/11 Regression]  |[8/9/10 Regression] wrong
   |wrong code with -mno-mmx|code with -mno-mmx -mno-sse
   |-mno-sse since  |since
   |r7-4540-gb229ab2a712ccd44   |r7-4540-gb229ab2a712ccd44

--- Comment #10 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug debug/99830] [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug rtl-optimization/99905] [8/9/10/11 Regression] wrong code with -mno-mmx -mno-sse since r7-4540-gb229ab2a712ccd44

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

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

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

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

commit r11-8140-gffc4155b6e45b8ab71d49a4b584f7cacb693e6b9
Author: Jakub Jelinek 
Date:   Tue Apr 13 01:01:45 2021 +0200

combine: Fix up expand_compound_operation [PR99905]

The following testcase is miscompiled on x86_64-linux.
expand_compound_operation is called on
(zero_extract:DI (mem/c:TI (reg/f:DI 16 argp) [3 i+0 S16 A128])
(const_int 16 [0x10])
(const_int 63 [0x3f]))
so mode is DImode, inner_mode is TImode, pos 63, len 16 and modewidth 64.

A couple of lines above the problematic spot we have:
  if (modewidth >= pos + len)
{
  tem = gen_lowpart (mode, XEXP (x, 0));
where the code uses gen_lowpart and then shift left/right to extract it
in mode.  But the guarding condition is false - 64 >= 63 + 16
and so we enter the next condition, where the code shifts XEXP (x, 0)
right by pos and then adds AND.  It does so incorrectly though.
Given the modewidth < pos + len, inner_mode must be necessarily larger
than mode and XEXP (x, 0) has the innermode, but it was calling
simplify_shift_const with mode rather than inner_mode, which meant
inconsistent arguments to simplify_shift_const and in this case made
a DImode MEM shift out of it.

The following patch fixes it, by doing the shift in inner_mode properly
and then after the shift doing the lowpart subreg and masking already
in mode.

2021-04-13  Jakub Jelinek  

PR rtl-optimization/99905
* combine.c (expand_compound_operation): If pos + len > modewidth,
perform the right shift by pos in inner_mode and then convert to
mode,
instead of trying to simplify a shift of rtx with inner_mode by pos
as if it was a shift in mode.

* gcc.target/i386/pr99905.c: New test.

[Bug debug/99830] [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g

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

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

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

https://gcc.gnu.org/g:9c1c8ad8339d551ac91a7af5614f29b9a687189a

commit r11-8139-g9c1c8ad8339d551ac91a7af5614f29b9a687189a
Author: Jakub Jelinek 
Date:   Tue Apr 13 01:00:48 2021 +0200

combine: Don't fold away side-effects in simplify_and_const_int_1 [PR99830]

Here is an alternate patch for the PR99830 bug.
As discussed on IRC and in the PR, the reason why a (clobber:TI (const_int
0))
has been propagated into the debug insns is that it got optimized away
during simplification from the i3 instruction pattern.

And that happened because
simplify_and_const_int_1 (SImode, varop, 255)
with varop of
(ashift:SI (subreg:SI (and:TI (clobber:TI (const_int 0 [0]))
  (const_int 255 [0xff])) 0)
   (const_int 16 [0x10]))
was called and through nonzero_bits determined that (whatever << 16) & 255
is const0_rtx.
It is, but if there are side-effects in varop and such clobbers are
considered as such, we shouldn't optimize those away.

2021-04-13  Jakub Jelinek  

PR debug/99830
* combine.c (simplify_and_const_int_1): Don't optimize varop
away if it has side-effects.

* gcc.dg/pr99830.c: New test.

[Bug tree-optimization/100053] tree-fre incorrectly delete a condition

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

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

--- Comment #1 from Andrew Pinski  ---
Removing unexecutable edge from if (init_101(D) == 0)
Merging blocks 25 and 26

[Bug c++/100054] [11 Regression] internal compiler error: in get_nsdmi

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

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

Patrick Palka  changed:

   What|Removed |Added

   Target Milestone|--- |11.0
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-04-12
   Keywords||ice-on-valid-code
 CC||jason at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
Summary|internal compiler error: in |[11 Regression] internal
   |get_nsdmi   |compiler error: in
   ||get_nsdmi

--- Comment #1 from Patrick Palka  ---
Confirmed, started with r11-17.

Slightly more reduced testcase:

template 
void f() {
  struct A { T m{}; };
  [](auto){ return A{}; };
}

template void f();

[Bug c++/100052] [11 regression] ICE in compiling g++.dg/modules/xtreme-header-3_b.C after r11-8118

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

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

--- Comment #1 from H.J. Lu  ---
This may be related to PR 12

[Bug middle-end/90323] powerpc should convert equivalent sequences to vec_sel()

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

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

--- Comment #14 from Segher Boessenkool  ---
(In reply to luoxhu from comment #12)
> That code was called by combine pass but fail to match. 

> 
> pr newpat
> (set (reg:DI 125 [ l ])
> (xor:DI (and:DI (xor:DI (reg/v:DI 120 [ l ])
> (reg:DI 127))
> (const_int 267390975 [0xff00fff]))
> (reg/v:DI 120 [ l ])))

Note this is 0x0ff00fff, and this is not a valid mask for rlwimi.

[Bug middle-end/90323] powerpc should convert equivalent sequences to vec_sel()

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

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

--- Comment #13 from Segher Boessenkool  ---
(In reply to luoxhu from comment #11)
> I noticed that you added the below optimization with commit
> a62436c0a505155fc8becac07a8c0abe2c265bfe. But it doesn't even handle this
> case, cse1 pass will call simplify_binary_operation_1, both op0 and op1 are
> REGs instead of AND operators, do you have a test case to cover that piece
> of code?

This worked at the time.  It broke some time ago in simple testcases,
triggered by the "don't combine hard registers" thing I did.  This is
PR98468.

[Bug c++/100054] New: internal compiler error: in get_nsdmi

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

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

Bug ID: 100054
   Summary: internal compiler error: in get_nsdmi
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

Reduced with creduce and then by hand:

template 
struct C {
  void find() {
struct H {
C c{};
};
(void)[](auto){ return H{}; };
  }
};

void f() {
  C().find();
}

This fails on gcc trunk -std=c++20 (but worked on gcc 10.3, 10.2, 10.1) with
(https://godbolt.org/z/heEKjMn91):

: In instantiation of 'void C::find() [with n = int]':
:12:16:   required from here
:5:14: internal compiler error: in get_nsdmi, at cp/init.c:598
5 | C c{};
  |  ^
0x1d01009 internal_error(char const*, ...)
???:0
0x6bb009 fancy_abort(char const*, int, char const*)
???:0
0x7fa161 get_nsdmi(tree_node*, bool, int)
???:0
0x97f2eb finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
???:0
0x94ae62 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x91699a tsubst_tree_list(tree_node*, tree_node*, int, tree_node*)
???:0
0x91d7ef instantiate_decl(tree_node*, bool, bool)
???:0
0x95f69b instantiate_pending_templates(int)
???:0
0x7cd039 c_parse_final_cleanups()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
ASM generation compiler returned: 1
: In instantiation of 'void C::find() [with n = int]':
:12:16:   required from here
:5:14: internal compiler error: in get_nsdmi, at cp/init.c:598
5 | C c{};
  |  ^
0x1d01009 internal_error(char const*, ...)
???:0
0x6bb009 fancy_abort(char const*, int, char const*)
???:0
0x7fa161 get_nsdmi(tree_node*, bool, int)
???:0
0x97f2eb finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
???:0
0x94ae62 tsubst_lambda_expr(tree_node*, tree_node*, int, tree_node*)
???:0
0x91699a tsubst_tree_list(tree_node*, tree_node*, int, tree_node*)
???:0
0x91d7ef instantiate_decl(tree_node*, bool, bool)
???:0
0x95f69b instantiate_pending_templates(int)
???:0
0x7cd039 c_parse_final_cleanups()
???:0
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
Execution build compiler returned: 1

RE: Invitation to Advanced Monitoring and Evaluation workshop

[Jackson via Gcc-bugs]

Advanced 
Monitoring and Evaluation for Development Results Course-May 31 to June 11,2021 
for 10


Click 
Here to Register  for online attendance course fee or Normal 
attendance as individual or group
  
FEE: All inclusive Normal Attendance $2,320.00 and 
Online $1400.00
 


Download 
PDF Calendar 2021



OFFICIAL EMAIL ADDRESS: train...@fdc-k.org
 
Office 
Telephone: +254712260031
 
 
Register 
as a group of   5  or more participants and get 40% discount on 
course fee. 
Send us 
email to train...@fdc-k.org or call +254712260031
 
TRAINING 
FOR ONLINE AND NORMAL ATTENDANCE AVAILABLE
 

INTRODUCTION
This 2 weeks training is design to impact job oriented 
skills for monitoring and evaluation that are highly demanded in the 
development 
industry. After following this course you will be capable of designing and 
managing Monitoring and Evaluation Systems which meet the standards of donor 
agencies.It is aimed at providing an overview of monitoring and evaluation 
methods for development results with practical applications of tools and 
methods. This course will provide participants with M&E tools, techniques 
and resources needed for planning, organizing, and/or managing programs and 
projects. Through exercises and group work, participants will learn the links 
between results-based measurement, monitoring and program evaluation. Time will 
be allocated for practical exercises and informal question and answer sessions 
around common M&E problem areas. Participants will also be provided with 
additional Resources for further study and research in the M&E 
field.
DURATION
2 Weeks
LEARNING OBJECTIVES
Learn 
  how to select data collection strategies and get acquainted with key issues 
  about measures such as credibility, reliability, validity and 
  precision
Benefit 
  from a hands-on-approach based on real life cases enabling you to immediately 
  apply the knowledge shared throughout course
Work 
  in groups together with professionals from around the world, in a 
  multicultural and diverse environment
Gain 
  insights on how multilateral agencies manage their 
  operations
Get 
  access to all the resources necessary to start your own training program on 
  Monitoring & Evaluation
Build 
  a Monitoring & Evaluation system throughout the course for a real 
  project
Use 
  data analysis software package (Stata).
Use 
  Geographic Information Systems (GIS) and GPS to gather data, collaborate and 
  share information.
Communicate 
  findings to stimulate learning and reflection.
WHO 
SHOULD ATTEND?
This course targets Project Management Officials from 
NGO’s, National Statistics Offices, Education Researchers, Government 
ministries, National Institutes and Planning Ministries, Central banks, and 
University Researchers among others.
TOPICS TO BE COVERED
M&E 
  fundamentals
Introduction 
  to M&E?
Key 
  components of M&E
Relating 
  Monitoring and evaluation to your project cycle
Identifying 
  the challenges facing Monitoring and evaluation 
  professionals
Steps 
  to implementing M&E in a project/programme
Type 
  of evaluations
Methods 
  and tools for M&E
Challenges 
  in M&E
Trends 
  towards result based M&E
Managing 
  for Development Results (MfDR)
MfDR 
  core principles
MfDR 
  and Result based management (RBM)
Defining 
  RBM
Emergence 
  of RBM and its development
Seven 
  phases of RBM
Performance 
  measurement, performance indicators and performance 
  monitoring
Logical 
  framework and results framework
Introduction 
to result based M&E
What 
  is RBM?
Results 
  based M&E outline
Result 
  based M&E cycle
Performance 
  measurement, performance indicators and performance 
  monitoring
Essential 
  actions to build result based M&E
The 
  power of measuring results
Situation 
analyses/Needs assessment
Formative 
  research
Situation 
  analysis
Needs 
  assessment
Tools 
  to conduct a needs assessment
Illustrative 
  examples of situation analysis and mappings
Baseline 
assessment
What 
  is baseline data and how is it collected?
Needs 
  assessment versus baseline study
Questions 
  to ask about a baseline plan
What 
  kind of baseline data is necessary, useful and practical to 
  coll

[Bug fortran/63797] Bogus ambiguous reference to 'sqrt'

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to chrisonian from comment #1)
> This bug is still present in versions 8.3.0, 9.3.0, 10.1.0 
> 
>

The bug likely does not effect anyone that contributes code
to GCC.  Someday someone might look at this bug.  Fortunately,
there is a trivial work around, e.g., change the generic-name
from 'sqrt' to 'root'.  If one does this and then looks at the
contents of mod2.mod, one see the only difference shown here.
Perhaps, module.c needs to be fixed to record the generic
interface.



 diff -u zxc1 zxc2
--- zxc12021-04-12 14:29:48.345332000 -0700
+++ zxc22021-04-12 14:30:04.774051000 -0700
@@ -4,7 +4,7 @@

 ()

-(('pair' 'mod2' 2) ('root' 'mod2' 3 4))
+(('pair' 'mod2' 2) ('sqrt' '(intrinsic)' 3 4))

 ()

[Bug c++/91933] [8/9/10/11 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in build_simple_base_path, at cp/class.c:541

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/93085] ICE in get_class_binding_direct and alias_ctad_tweaks, with C++20 NTTP + CTAD + alias template

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:84081e2c6bd43a6790f751755865cf4227adac7c

commit r11-8137-g84081e2c6bd43a6790f751755865cf4227adac7c
Author: Jason Merrill 
Date:   Sat Apr 10 02:10:32 2021 -0400

c++: premature overload resolution [PR93085]

We can't resolve the call to foo<42> before instantiation of G, because the
template parameter of #1 has dependent type.  But we were missing that in
our dependency check, because the tree walk of DECL_TEMPLATE_PARMS doesn't
look into the types of template parameters.  So look at them directly.

gcc/cp/ChangeLog:

PR c++/93085
* pt.c (uses_outer_template_parms): Handle non-type and template
template parameters specifically.

gcc/testsuite/ChangeLog:

PR c++/93085
* g++.dg/template/dependent-tmpl1.C: New test.

[Bug tree-optimization/100053] New: tree-fre incorrectly delete a condition

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

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

Bug ID: 100053
   Summary: tree-fre incorrectly delete a condition
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: qinzhao at gcc dot gnu.org
  Target Milestone: ---

hi, this is a bug with tree-fre optimization that caused run-time segmentation
fault. 
the original testing case cannot be posted.

the following is the reduced testing case through Creduce. 
ubuntu@qinzhao-ubuntu-x86:~/Bugs/32423691$ cat ksm.i
typedef a;
typedef struct b b;
struct {
  char c
} typedef d;
struct e {
  int f;
  char g
} typedef aa;
struct {
  int ad;
  char ae
} typedef ab;
struct {
  int ac;
  char ah;
  int ai;
  a *h;
  b *ag
} typedef af;
struct b {
  af i;
  struct e *j
} m;
k, o, q, r, s, t, u;
typedef l[];
l n;
*p;
ab al;
v(init) {
  d *aj;
  int ak;
  if (!init) {
w();
aj = q;
if (p[t])
  goto aq;
af am = (&m)->i;
if (_setjmp())
  if ((&m)->i.h) {
a an, ao;
aa *ap = am.h[(&m)->i.ai];
void *au;
if ((&m)->i.ai) {
  if (x())
an += (long)au % (&m)->i.ag->j->f;
  if ((a)__builtin_alloca)
ao = au = an;
  ap->g = "";
}
y(ao);
  }
ak |= z(n[k], ak, init ? 0 : ((int *)o)[t]);
(&al)->ad = (&m)->i.ac & (&m)->i.ah;
(&m)->i.ac = (&al)->ae = &al;
  }
  if (!init)
aj->c = s;
  ar(u, r, s);
aq:
  if (!init)
as(((int *)o)[t]);
}
ubuntu@qinzhao-ubuntu-x86:~/Bugs/32423691$ cat t
/home/ubuntu/Install/latest-debug/bin/gcc ksm.i -c -o ksm.o  -O2 
-fdump-tree-optimized 

ubuntu@qinzhao-ubuntu-x86:~/Bugs/32423691$ sh t


there are quite some warnings during compilation, please ignore them.

check the ksm.i.244t.optimized, you will find that the last "if (!init)" is
completely deleted;

if you add -fno-tree-fre to the compilation line, the last "if (!init)" will
not be deleted anymore.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 78141 Summary: Missing uninitialized warning about struct member after 
change another struct definition (without optimization)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78141

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

[Bug c++/78141] Missing uninitialized warning about struct member after change another struct definition (without optimization)

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Blocks||24639
   Keywords||diagnostic
 CC||msebor at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #1 from Martin Sebor  ---
GCC 11 reports the uninitialized reads either way, at all optimization levels
(including -O0).  It looks like r239785 was the first revision when GCC started
warning at -O0 although that revision just changed the xtensa target so I'm not
sure if that's relevant.  Similarly, bisection indicates r177670 started
warning with optimization, and that revision is again unrelated to this. 
Either way, GCC now warns so this can be resolved as fixed.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug target/100049] loop counter double increment with longjmp inside

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

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

--- Comment #3 from Christophe Lyon  ---
Thanks for the prompt answers!

I did notice that putting the code into a single source file made behave "as
expected". I did check the longjmp docs but unfortunately missed the section
describing this case near the end.

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 78044 Summary: -Wmaybe-uninitialized and -O2: false positive with 
boost::optional
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78044

   What|Removed |Added

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

[Bug middle-end/78044] -Wmaybe-uninitialized and -O2: false positive with boost::optional

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

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

Martin Sebor  changed:

   What|Removed |Added

   Target Milestone|--- |10.0
 Resolution|--- |FIXED
 Blocks||24639
 CC||msebor at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #8 from Martin Sebor  ---
The warning for the test case in comment 0 (attachment 39843) disappeared
between r275012 and r275022.  The one for the test case in comment 7
disappeared after r254495.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug libstdc++/71434] binomial_distribution operator(): using uninitialized variable

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to fail||10.2.0, 11.0, 5.5.0, 6.4.0,
   ||7.2.0, 8.3.0, 9.1.0
   Last reconfirmed||2021-04-12

--- Comment #1 from Martin Sebor  ---
The uninitialized read still seems possible in the latest sources (GCC 11). 
Thus confirming.

[Bug middle-end/70765] GCC fails to detect possibly uninitialized variable

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||diagnostic
 Resolution|--- |WONTFIX
 CC||msebor at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Martin Sebor  ---
-Wuninitialized, -Wmaybe-uninitialized, and all other flow-sensitive warnings
depend on optimization (including inlining) to avoid both false positives and
false negatives.  This is one of the many cases that's only detectable thanks
to optimization.  GCC's static analyzer might be able to do better in GCC 12
(if/when -Wanalyzer-use-of-uninitialized-value becomes supported).  Thus
resolving as WONTFIX.

[Bug c++/100052] New: [11 regression] ICE in compiling g++.dg/modules/xtreme-header-3_b.C after r11-8118

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

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

Bug ID: 100052
   Summary: [11 regression] ICE in compiling
g++.dg/modules/xtreme-header-3_b.C after r11-8118
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:82198676c80764ca7cf05f891afaee83b9179dd1, r11-8118

I only see this on power 9 and power 10.

FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2a (internal compiler error)
FAIL: g++.dg/modules/xtreme-header-3_b.C -std=c++2a (test for excess errors)

hash table checking failed: equal operator returns true for a pair of values
with a different hash value^M
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/modules/xtreme-header-3_b.C:4:30:
internal compiler error: in hashtab_chk_error, at hash-table.c:137^M
0x10291ddf hashtab_chk_error()^M
/home/seurer/gcc/git/gcc-test/gcc/hash-table.c:137^M
0x10633807 hash_table::verify(spec_entry*
const&, unsigned int)^M
/home/seurer/gcc/git/gcc-test/gcc/hash-table.h:1033^M
0x10633fcf hash_table::find_slot_with_hash(spec_entry* const&, unsigned int,
insert_option)^M
/home/seurer/gcc/git/gcc-test/gcc/hash-table.h:968^M
0x105b6567 match_mergeable_specialization(bool, spec_entry*)^M
/home/seurer/gcc/git/gcc-test/gcc/cp/pt.c:29974^M
0x104cf987 trees_in::key_mergeable(int, merge_kind, tree_node*, tree_node*,
tree_node*, tree_node*, bool)^M
/home/seurer/gcc/git/gcc-test/gcc/cp/module.cc:10670^M
0x104c6843 trees_in::decl_value()^M
/home/seurer/gcc/git/gcc-test/gcc/cp/module.cc:7903^M
0x104c9587 trees_in::tree_node(bool)^M
/home/seurer/gcc/git/gcc-test/gcc/cp/module.cc:9153^M
0x104d5e4b module_state::read_cluster(unsigned int)^M
/home/seurer/gcc/git/gcc-test/gcc/cp/module.cc:14811^M
0x104d6333 module_state::load_section(unsigned int, binding_slot*)^M
/home/seurer/gcc/git/gcc-test/gcc/cp/module.cc:18082^M
0x104d79ef module_state::read_language(bool)^M
/home/seurer/gcc/git/gcc-test/gcc/cp/module.cc:18011^M
0x104d7e6b direct_import^M
/home/seurer/gcc/git/gcc-test/gcc/cp/module.cc:18877^M
0x1055e917 cp_parser_import_declaration^M
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.c:13881^M
0x1058491b cp_parser_translation_unit^M
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.c:4907^M
0x1058491b c_parse_file()^M
/home/seurer/gcc/git/gcc-test/gcc/cp/parser.c:45267^M
0x10783e1b c_common_parse_file()^M
/home/seurer/gcc/git/gcc-test/gcc/c-family/c-opts.c:1218^M


commit 82198676c80764ca7cf05f891afaee83b9179dd1 (HEAD)
Author: Jason Merrill 
Date:   Sat Apr 10 10:55:58 2021 -0400

c++: ICE with invalid use of 'this' with static memfn [PR98800]

[Bug middle-end/70069] Uninitialized value default to zero, plus warning

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

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||24639
 CC||msebor at gcc dot gnu.org
   Keywords||patch

--- Comment #3 from Martin Sebor  ---
A POC patch along these lines was submitted here:
  https://gcc.gnu.org/pipermail/gcc-patches/2021-February/565514.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug tree-optimization/100051] New: missed optimization for dead code elimination at -Os, -O2 and -O3 (vs. -O1)

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 100051
   Summary: missed optimization for dead code elimination at -Os,
-O2 and -O3 (vs. -O1)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[719] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210412 (experimental) [master revision
46c47420a5f:66634f1d5eb:8f17d44ad986e0ae7e81c81179463000ee9d7f43] (GCC) 
[720] % 
[720] % gcctk -O1 -S -o O1.s small.c
[721] % gcctk -O3 -S -o O3.s small.c
[722] % 
[722] % wc O1.s O3.s
  56  121  784 O1.s
  68  148  996 O3.s
 124  269 1780 total
[723] % 
[723] % grep foo O1.s
[724] % grep foo O3.s
callfoo
[725] % 
[725] % cat small.c
extern void foo(void);
int a, c, *f, **d = &f;
char b;
static void e() {
  if ((2 ^ b) == 0)
foo();
}
int main() {
  if (a) {
b = 0;
int *g = &c;
*g = 0;
f = *d;
*d = f;
e();
  }
  return 0;
}

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 55644 Summary: maybe-uninitialized false positive due to incorrect flow 
analysis when gotos are present
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55644

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WORKSFORME

[Bug middle-end/55644] maybe-uninitialized false positive due to incorrect flow analysis when gotos are present

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

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||24639
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WORKSFORME
 Status|NEW |RESOLVED
   Keywords||diagnostic

--- Comment #14 from Martin Sebor  ---
Per comment 10 resolving as WORKSFORSOME (for lack of a better status).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug bootstrap/55371] [asan] False -Werror=uninitialized

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

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

Martin Sebor  changed:

   What|Removed |Added

  Component|sanitizer   |bootstrap
 CC||msebor at gcc dot gnu.org
 Resolution|--- |WONTFIX
 Status|NEW |RESOLVED

--- Comment #3 from Martin Sebor  ---
In a recent build of GCC 11 I count 69 instances of -Wmaybe-uninitialized
without sanitization but not one looking like the one in comment #0.  I don't
have a sanitized build handy but the instrumentation injected by the sanitizers
is known to induce false positives, so (I think) GCC builds with
-Wno-error=maybe-uniitialized when sanitization is enabled.  There are a lot of
bugs against the warning with small test cases and odds are that one of them
captures the essence of this ancient bug if it is, in fact, a bug and if it
hasn't disappeared by now.  Since there's been no activity on this bug in
almost a decade I'm going to resolve this report as WONTFIX.  If it's still
reproducible please reopen and attach a standalone test case to make it easy to
reproduce.

[Bug target/100028] [9/10/11 Regression] arm64 failure to generate bfxil

[luc.vanoostenryck at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Luc Van Oostenryck  ---
(In reply to Jakub Jelinek from comment #4)
> Created attachment 50571 [details]
> gcc11-pr100028.patch
> 
> Untested fix.

This solve the few cases I had.
Thanks.

[Bug c++/97974] [9/10 Regression] ICE tree check: expected overload, have function_decl in get_class_binding_direct, at cp/name-lookup.c:1332

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

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

Jason Merrill  changed:

   What|Removed |Added

  Known to work||11.0
Summary|[9/10/11 Regression] ICE|[9/10 Regression] ICE tree
   |tree check: expected|check: expected overload,
   |overload, have  |have function_decl in
   |function_decl in|get_class_binding_direct,
   |get_class_binding_direct,   |at cp/name-lookup.c:1332
   |at cp/name-lookup.c:1332|

--- Comment #3 from Jason Merrill  ---
Fixed for 11 so far.

[Bug c++/100032] [8/9/10/11 Regression] renaming alias template that also adds cv-qualifiers is deemed equivalent to underlying template

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

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

Jason Merrill  changed:

   What|Removed |Added

   Last reconfirmed||2021-04-12
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Jason Merrill  ---
(In reply to Patrick Palka from comment #1)
> but this also makes us (incorrectly?) reject
> 
> template  class> struct X { };
> template  struct Y { };
> template  using Z = const Y;
> template  using W = Z;
> using U = X;
> using U = X;
> 
> because the underlying type of W for some reason already has the const
> qualifier

Yes, because most alias templates are at least partly transparent, so W has
the const added by Z.  It should work to compare TYPE_QUALS to those of the
underlying template, rather than to TYPE_UNQUALIFIED.

[Bug middle-end/97353] -Wuninitialized should warn about reading condition in do-loop

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

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   Severity|normal  |enhancement
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=18501
   Last reconfirmed||2021-04-12
 Blocks||24639

--- Comment #2 from Martin Sebor  ---
With -O2 the function is optimized to a return statement before the late
warning runs so there's nothing to do there.

With -O1 the uninitialized variable is optimized out in CCP3 so there's nothing
to warn about either.

With -O0 the uninitialized read is unconditional in bb 3 in the IL below but
the warning doesn't analyze PHIs at that level so the bug isn't detected. 
Running the PHI analysis early (at -O0) would solve a whole class of false
negatives.  If done indiscriminately, it would also introduce a ton of false
positives unless perhaps the warning ran CCP first (without actually changing
the CFG).  A discussion of these problems is in pr18501.  Without the help of
CCP the early warning could also trigger for unconditionally reachable PHI
reads like the one in the test case.  So with that, let me confirm this
request. (The test case is too contrived to be worth worrying about on its own
since the loop doesn't do anything and can be optimized away regardless of
whether ok is initialized.  But it may be representative of similar but less
contrived cases where the early warning could expose a real bug).

int main ()
{
  int n;
  int ok;
  int D.1952;
  _Bool _1;
  int _9;

   :
  n_5 = 0;

   :
  # ok_2 = PHI 
  # n_4 = PHI 
  n_7 = n_4 + 1;
  if (n_7 == 1)
goto ; [INV]
  else
goto ; [INV]

   :
  // predicted unlikely by continue predictor.
  goto ; [INV]

   :
  _1 = n_7 > 1;
  ok_8 = (int) _1;

   :
  # ok_3 = PHI 
  if (ok_3 == 0)
goto ; [INV]
  else
goto ; [INV]

   :
  _9 = 0;

   :
:
  # VUSE <.MEM_10(D)>
  return _9;

}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug tree-optimization/100050] New: missed optimization for dead code elimination at -O3 (vs. -O1, -Os, -O2)

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 100050
   Summary: missed optimization for dead code elimination at -O3
(vs. -O1, -Os, -O2)
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

[598] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210412 (experimental) [master revision
46c47420a5f:66634f1d5eb:8f17d44ad986e0ae7e81c81179463000ee9d7f43] (GCC) 
[599] % 
[599] % gcctk -O1 -S -o O1.s small.c
[600] % gcctk -O3 -S -o O3.s small.c
[601] % 
[601] % wc O1.s O3.s
  19   44  412 O1.s
  35   77  683 O3.s
  54  121 1095 total
[602] % 
[602] % grep foo O1.s
[603] % grep foo O3.s
callfoo
[604] % 
[604] % cat small.c
extern void foo(void);
static int *a[2];
int main() {
  int c = 0;
  for (; c < 2; c++)
a[c] = &c;
  if (!a[0])
foo();
  return 0;
}

[Bug middle-end/24639] [meta-bug] bug to track all Wuninitialized issues

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

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

Bug 99340 Summary: -Werror=maybe-uninitialized warning with -fPIE, but not -fPIC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99340

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

[Bug c/99340] -Werror=maybe-uninitialized warning with -fPIE, but not -fPIC

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID
 CC||msebor at gcc dot gnu.org
   Keywords||diagnostic
 Blocks||24639

--- Comment #7 from Martin Sebor  ---
The IL with -fPIC shows a call to ags_midi_buffer_util_get_varlength() while
the IL with -fPIE has the call expanded inline, which is what less the warning
see current_delta_time is not initialized.   With that, resolving as invalid
per c6.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=24639
[Bug 24639] [meta-bug] bug to track all Wuninitialized issues

[Bug tree-optimization/99927] [11 Regression] Wrong code since r11-39-gf9e1ea10e657af9f

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

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

Segher Boessenkool  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |segher at gcc dot 
gnu.org

--- Comment #16 from Segher Boessenkool  ---
(In reply to Richard Biener from comment #15)
> So ... the conclusion is?

The conclusion is I have a patch and I will commit it after testing it
successfully on enough targets.  This takes time.

I see I forgot to self-assign the bug.  Fixed.

[Bug middle-end/100038] -Warray-bound triggers false positives

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=98465
 CC||msebor at gcc dot gnu.org

--- Comment #7 from Martin Sebor  ---
Confirmed with attachment 50560 and the output/IL below.  The problem is caused
by the test (presumably for self-insertion) in
SmallVectorImpl::insert(iterator, const T&):

const T *EltPtr = &Elt;
if (I <= EltPtr && EltPtr < this->end())
  ++EltPtr;

I don't see anything in the IL to avoid it without compromising it at the same
time.  We suppressed a similar false positive in std::string::insert() in
pr98465.  It was done by keeping the equivalent test from being inlined because
the usual suppression mechanism, #pragma GCC diagnostic, doesn't work reliably
with inlining (something that will hopefully be fixed in GCC 12).  Another
alternative to consider is inserting an optimization barrier after the block
above:

asm volatile("": : :"memory");

Another (future) alternative is to annotate the SmallVector::BeginX with some
new attribute telling the optimizer it doesn't alias unrelated objects (like
val).  This doesn't exist but it would help not just avoid warnings but also
emit more optimal code.

(As an aside, the pointer test above is strictly unspecified because it
compares the addresses of unrelated objects,  It should convert the pointers to
integers first but that wouldn't prevent the warning.)

In file included from mwe_smallvector.cpp:2:
SmallVector.h: In function ‘int main()’:
SmallVector.h:537:7: warning: array subscript 1 is outside array bounds of ‘int
[1]’ [-Warray-bounds]
mwe_smallvector.cpp:12:11: note: while referencing ‘’
In file included from mwe_smallvector.cpp:2:
SmallVector.h:566:7: warning: array subscript 1 is outside array bounds of ‘int
[1]’ [-Warray-bounds]
mwe_smallvector.cpp:13:6: note: while referencing ‘val’
...
int main ()
{
  ...
  int D.55243;
  ...
  
  _21 = VS.D.54770.BeginX;
  _1 = _21 + 4;
  ...

   [local count: 32183167]:
  _52 = MEM[(struct SmallVectorTemplateCommon *)&VS].D.54770.BeginX;
  I_54 = _52 + 4;

   [local count: 97524748]:
  # I_69 = PHI <_1(8), I_54(10)>
  ...

   [local count: 97524748]:
  _115 = (long unsigned int) _111;
  _116 = -_115;
  _117 = _66 + _116;
  _70 = MEM[(const struct SmallVectorBase *)&VS].Size;
  _71 = _70 + 1;
  MEM[(struct SmallVectorBase *)&VS].Size = _71;
  if (&D.55243 >= I_69)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 48762374]:
  _72 = MEM[(struct SmallVectorTemplateCommon *)&VS].D.54770.BeginX;
  _73 = (long unsigned int) _71;
  _74 = _73 * 4;
  _75 = _72 + _74;
  if (&D.55243 < _75)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 24381187]:
  _50 = MEM[(type &)&D.55243 + 4];   <<< -Warray-bounds

[Bug target/100049] loop counter double increment with longjmp inside

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The testcase would be
#include 
#include 

struct ctx { int cnt; struct S { jmp_buf env; } jmp_buf[4]; } ctx;

__attribute__((noipa)) void
do_jump (void)
{
  --ctx.cnt;
  longjmp (ctx.jmp_buf[ctx.cnt].env, 1);
}

static void
test (void)
{
  for (unsigned i = 0; i < 19; i++)
{
  printf ("Message %d\n", i);
  if (setjmp ((&ctx.jmp_buf[ctx.cnt])->env) == 0)
{
  ++ctx.cnt;
  do_jump ();
  --ctx.cnt;
}
}
}

int
main ()
{
  test ();
  return 0;
}

And gcc clearly warns about that with -O2 -W -Wall:
pr100049.c: In function ‘test’:
pr100049.c:16:17: warning: variable ‘i’ might be clobbered by ‘longjmp’ or
‘vfork’ [-Wclobbered]
   16 |   for (unsigned i = 0; i < 19; i++)
  | ^

[Bug target/100049] loop counter double increment with longjmp inside

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |INVALID

--- Comment #1 from Andreas Schwab  ---
The value of non-volatile qualified local variables is indeterminate after
longjmp.

[Bug c++/93383] ICE on accessing field of a structure which is non-type template parameter, -std=c++2a

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #12 from Patrick Palka  ---
We also incorrectly reject

template  struct A {};

template  struct B {
  template  using type = B;
};

It seems do_class_deduction needs to be made more forgiving about dependent
initializers.

[Bug target/100049] New: loop counter double increment with longjmp inside

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

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

Bug ID: 100049
   Summary: loop counter double increment with longjmp inside
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Created attachment 50572
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50572&action=edit
Example code

As described in https://bugs.linaro.org/show_bug.cgi?id=5755

the following loop:
for(i = 0; i < CNT; i++) {
printf("Message %d\n", i);
if (setjmp((&ctx.jmp_buf[ctx.cnt])->env) == 0) {
++ctx.cnt;
do_jump();
--ctx.cnt;
}
}
has the following output:
Message 0
Message 2

It's sufficient to use -O2, and the offending code sequence is:
bl  _setjmp
(*) ldr w1, [sp, 44]
add w1, w1, 1
str w1, [sp, 44]
cbnzw0, .L3
[]
bl do_jump (which calls longjmp)


where w1 contains "i", the line marked (*) is where longjmp jumps to.

So "i" is incremented before calling longjmp, and a second time when longjmp
gives control back to the test() function.

The attached archive contains:
helper.h, helper.c
example.c
Makefile

[Bug c++/89538] [8.3.0] GCC miscompiling LLVM because of wrong vectorization

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME
 CC||msebor at gcc dot gnu.org

--- Comment #11 from Martin Sebor  ---
(In reply to Taewook Oh from comment #10)
> Thanks, and sorry for the confusion. I'll find the exact version that causes
> this issue.

Sounds like the issue may have been caused by using an unsupported (internal ==
modified?) version of GCC.  Let me resolve  this as WORKSFORSOME due to the
absence of feedback in over two years.  If it's still an issue with a supported
GCC release, please reopen with an updated test case, version, and command
line.

[Bug debug/99830] [11 Regression] ICE: in lra_eliminate_regs_1, at lra-eliminations.c:659 with -O2 -fno-expensive-optimizations -fno-split-wide-types -g

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug tree-optimization/89579] -Wclobbered warning false positive when compiling with -Og

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

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=21161

--- Comment #5 from Martin Sebor  ---
See also pr21161.

[Bug tree-optimization/89579] -Wclobbered warning false positive when compiling with -Og

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords|rejects-valid   |
  Component|c++ |tree-optimization
 CC||msebor at gcc dot gnu.org
  Known to fail||10.2.0, 11.0, 9.2.0
   Last reconfirmed|2019-03-04 00:00:00 |2021-4-12

--- Comment #4 from Martin Sebor  ---
Reconfirmed with GCC 11 (and 10).

[Bug middle-end/100046] compare with itself

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
It is valid, but also both are the same number of GIMPLE operations.
So for canonicalization we should carefully pick one that looks better in some
way.

[Bug target/100028] [9/10/11 Regression] arm64 failure to generate bfxil

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

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 50571
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50571&action=edit
gcc11-pr100028.patch

Untested fix.

[Bug tree-optimization/100047] False -Wmaybe-uninitialized on one var depending on type of other var

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

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

Martin Sebor  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Component|c++ |tree-optimization
 CC||msebor at gcc dot gnu.org
 Blocks||78394, 82738
   Last reconfirmed||2021-04-12
  Known to fail||10.2.0, 11.0, 8.3.0, 9.3.0

--- Comment #2 from Martin Sebor  ---
Confirmed with GCC 11 and 10 and -Og only with the GCC 11 IL below.  The
warning depends on a number of optimizations only a few of which are enabled at
-Og so it has  a higher rate of false positives there.  For GCC 12 with -Og we
might consider removing -Wmaybe-uninitialized from -Wall.

   [local count: 1073741824]:
  # .MEM_10 = VDEF <.MEM_1(D)>
  D.56209 = D.55716;
  # .MEM_11 = VDEF <.MEM_10>
  D.51082 ={v} {CLOBBER};
  # .MEM_12 = VDEF <.MEM_11>
  MEM[(union _Storage *)&D.51082] ={v} {CLOBBER};
  # .MEM_13 = VDEF <.MEM_12>
  MEM[(struct _Optional_payload_base *)&D.51082]._M_engaged = 0;   <<< store
  # .MEM_14 = VDEF <.MEM_13>
  D.56209 ={v} {CLOBBER};
  # VUSE <.MEM_14>
  _34 = MEM[(const struct _Optional_base
*)&D.51082]._M_payload.D.50287.D.50137._M_engaged;   <<< read
  if (_34 != 0)<<< not
folded
goto ; [100.00%]
  else
goto ; [0.00%]

   [local count: 1073741824]:
  # VUSE <.MEM_14>
  _36 = get (&MEM[(const struct packet_buffer *)&D.51082].m_ptr);
  # VUSE <.MEM_14>
  _37 = MEM[(const struct packet_buffer *)&D.51082].m_size;<<<
-Wmaybe-uninitialized


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78394
[Bug 78394] False positives of maybe-uninitialized with -Og
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82738
[Bug 82738] [meta-bug] issues with the -Og optimization level

[Bug target/100005] undefined reference to `_rdrand64_step'

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

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

--- Comment #15 from Jakub Jelinek  ---
No, no way.
It is not an ODR violation, as it is an extension, it is perfectly fine if the
inline and out of line definitions differ and they quite often do, e.g. in
glibc.

[Bug target/100005] undefined reference to `_rdrand64_step'

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #14 from Thiago Macieira  ---
(In reply to Jakub Jelinek from comment #13)
> The same like in C.
> I.e.
> extern inline __attribute__((gnu_inline, always_inline, artificial)) int foo
> (int x) { return x; }
> // The above is typically from some header
> int foo (int x) { return x; }
> // The above is the out of line function definition

Thanks, Jakub. At first sight that's not valid C++, but then since it's an
extension it doesn't have to be. ICC even accepts the same syntax and generates
the same non-weak symbol.

Any way to do that without repeating the body, thus potentially causing an ODR
violation? I'm not likely to use this feature, but asking for a rainy day.

https://gcc.godbolt.org/z/96qW9ExcG

[Bug target/100005] undefined reference to `_rdrand64_step'

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

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

--- Comment #13 from Jakub Jelinek  ---
The same like in C.
I.e.
extern inline __attribute__((gnu_inline, always_inline, artificial)) int foo
(int x) { return x; }
// The above is typically from some header
int foo (int x) { return x; }
// The above is the out of line function definition

[Bug target/100005] undefined reference to `_rdrand64_step'

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #12 from Thiago Macieira  ---
(In reply to Richard Biener from comment #11)
> Invalid.  Note we can't really diagnose GNU extern inline address-taking
> since
> by definition that's allowed (just the definition needs to come from
> elsewhere).

Understood. Thanks for looking into the report.

Out of curiosity, how does one provide an extern inline's out-of-line copy in
C++?

[Bug libstdc++/100044] ranges::subrange CTAD for __iterator_sentinel_pair not work

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #6 from Jonathan Wakely  ---
The bogus deduction guides are gone now.

[Bug target/100048] [10/11 Regression] Wrongful CSE'ing of SVE predicates.

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

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

Tamar Christina  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-04-12
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |tnfchris at gcc dot 
gnu.org

[Bug libstdc++/100044] ranges::subrange CTAD for __iterator_sentinel_pair not work

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

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

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

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

commit r10-9699-gb6bef1cbc14080d5dd0a7ddbb81aa4b68ece84a3
Author: Jonathan Wakely 
Date:   Mon Apr 12 12:49:17 2021 +0100

libstdc++: Implement LWG 3404 for C++20 subrange [PR 100044]

These deduction guides became useless with LWG 3282 (implemented in
commit r10-6741) and so were removed by LWG 3404.

libstdc++-v3/ChangeLog:

PR libstdc++/100044
* include/std/ranges (__detail::__iterator_sentinel_pair):
Remove helper concept.
(subrange(_Pr), subrange(Pr, __make_unsigned_like<...>)): Remove
deduction guides, as per LWG 3404.
* testsuite/std/ranges/subrange/lwg3282_neg.cc: Check that class
template argument deduction fails.

(cherry picked from commit 7569ce583f540ae22c585cc5159e3b23deedd987)

[Bug target/100048] [10/11 Regression] Wrongful CSE'ing of SVE predicates.

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.4

[Bug target/100021] [9/10/11 Regression] std::clamp unprofitable vectorization on -march=nehalem/.../broadwell

[nok.raven at gmail dot com via Gcc-bugs]

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

Nikita Kniazev  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 Status|WAITING |RESOLVED

--- Comment #4 from Nikita Kniazev  ---
> Also, you are passing -march=sandybridge, but the profiler seems to show 
> Skylake (SKX) target.

I indeed missed that Compiler Explorer does not pass -march flag to MCA
automatically.

[Bug target/100048] [10/11 Regression] Wrongful CSE'ing of SVE predicates.

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

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

--- Comment #1 from Tamar Christina  ---
Correction, it's CSE'd into

foo:
pfalse  p1.b
ptrue   p0.d, all
trn1p0.d, p0.d, p1.d
faddv   h0, p0, z0.h
str h0, [x0]
str h0, [x0, 2]
ret

[Bug tree-optimization/99927] [11 Regression] Wrong code since r11-39-gf9e1ea10e657af9f

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

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

--- Comment #15 from Richard Biener  ---
So ... the conclusion is?

[Bug rtl-optimization/99596] [11 Regression] arm: internal error in single_pred_edge

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from Richard Biener  ---
Richard, any progress?

[Bug target/100048] New: [10/11 Regression] Wrongful CSE'ing of SVE predicates.

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

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

Bug ID: 100048
   Summary: [10/11 Regression] Wrongful CSE'ing of SVE predicates.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tnfchris at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64-*

The following testcase

#include "arm_sve.h"

void foo(svfloat16_t in, float16_t *dst) {
  const svbool_t pg_q0 = svdupq_n_b16(1, 0, 1, 0, 0, 0, 0, 0);
  const svbool_t pg_f0 = svdupq_n_b16(1, 0, 0, 0, 0, 0, 0, 0);
  dst[0] = svaddv_f16(pg_f0, in);
  dst[1] = svaddv_f16(pg_q0, in);
}

generates the right code at -O1 with -march=armv8-a+sve but generates wrong
code at -O2.

>From this these expands are created

(insn 22 21 23 2 (set (reg:VNx8BI 100)
(subreg:VNx8BI (reg:VNx2BI 103) 0))
 (expr_list:REG_EQUAL (const_vector:VNx8BI [
(const_int 1 [0x1])
(const_int 0 [0])
(const_int 1 [0x1])
(const_int 0 [0]) repeated x5
])
(nil)))

and

(insn 15 14 16 2 (set (reg:VNx8BI 96)
(subreg:VNx8BI (reg:VNx2BI 99) 0))
 (expr_list:REG_EQUAL (const_vector:VNx8BI [
(const_int 1 [0x1])
(const_int 0 [0]) repeated x7
])
(nil)))

where the subregs are paradoxical.  These incorrect paradoxical subregs cause
CSE to think these two predicates are the same.

As such it CSEs them away into

foo:
pfalse  p2.b
ptrue   p1.d, all
trn1p1.d, p1.d, p2.d
faddv   h1, p1, z0.h
str h1, [x0]
ptrue   p0.s, all
trn1p0.d, p0.d, p2.d
faddv   h0, p0, z0.h
str h0, [x0, 2]
ret

instead of the expected

foo:
pfalse  p2.b
ptrue   p1.d, all
ptrue   p0.s, all
trn1p1.s, p1.s, p2.s
trn1p0.s, p0.s, p2.s
faddv   h1, p1, z0.h
faddv   h0, p0, z0.h
str h1, [x0]
str h0, [x0, 2]
ret

[Bug preprocessor/99446] [11 Regression] ICE in linemap_position_for_loc_and_offset, at libcpp/line-map.c:1005 since r11-6325

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #10 from Nathan Sidwell  ---
I see the problem.  it's the logic in the earlier while loop.  testing a fix

[Bug target/100028] [9/10/11 Regression] arm64 failure to generate bfxil

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
I guess it is basically a dup of PR87763, except that it needs yet another
pattern.
Combiner tries to match here:
(ior:SI (and:SI (reg:SI 102)
(const_int -8 [0xfff8]))
(subreg:SI (zero_extract:DI (subreg:DI (reg:SI 103) 0)
(const_int 3 [0x3])
(const_int 11 [0xb])) 0)))
which is similar to:
(define_insn "*aarch64_bfi4_noand"
  [(set (match_operand:GPI 0 "register_operand" "=r")
(ior:GPI (and:GPI (match_operand:GPI 1 "register_operand" "0")
  (match_operand:GPI 2 "const_int_operand" "n"))
 (ashift:GPI
  (match_operand:GPI 3 "register_operand" "r")
  (match_operand:GPI 4 "aarch64_simd_shift_imm_"
n"]
  "aarch64_masks_and_shift_for_bfi_p (mode, UINTVAL (operands[2]),
 UINTVAL (operands[4]),
 HOST_WIDE_INT_M1U << UINTVAL (operands[4])
)"

[Bug c++/100047] False -Wmaybe-uninitialized on one var depending on type of other var

[gccbugbjorn at fahller dot se via Gcc-bugs]

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

--- Comment #1 from Björn Fahller  ---
Created attachment 50570
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50570&action=edit
Test program exposing the bug

bf@pteranodon /tmp> g++-10 -c -std=c++17 -Wmaybe-uninitialized ./t.cpp -Og # no
warning

bf@pteranodon /tmp> g++-10 -c -std=c++17 -DEXPOSE_BUG -Wmaybe-uninitialized
./t.cpp -Og
./t.cpp: In function ‘std::string func()’:
./t.cpp:30:34: warning: ‘.packet_buffer::m_size’ may be used
uninitialized in this function [-Wmaybe-uninitialized]
   30 | size_t size() const { return m_size; }// <- here
  |  ^~

[Bug preprocessor/99446] [11 Regression] ICE in linemap_position_for_loc_and_offset, at libcpp/line-map.c:1005 since r11-6325

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

--- Comment #9 from Bernd Edlinger  ---
The last token is a CPP_PRAGMA_EOL, and has a line number 2,
while the include file has only one line, so it is similar to an EOL position.
I guess therefore this fails to add a column?

1002  location_t r = 
1003linemap_position_for_line_and_column (set, map, line, column);
1004  if (linemap_assert_fails (r <= set->highest_location)
1005  || linemap_assert_fails (map == linemap_lookup (set, r)))
1006return loc;


(gdb) p tok[0]
$30 = {type = CPP_EOF, keyword = RID_MAX, flags = 64 '@', implicit_extern_c =
false, error_reported = false, 
  purged_p = false, tree_check_p = false, main_source_p = true, location =
255712, u = {tree_check_value = 0x0, 
value = 0x0}}
(gdb) p tok[-1]
$31 = {type = CPP_PRAGMA_EOL, keyword = RID_MAX, flags = 0 '\000',
implicit_extern_c = false, error_reported = false, 
  purged_p = false, tree_check_p = false, main_source_p = false, location =
251552, u = {tree_check_value = 0x0, 
value = 0x0}}

location_t r = 
1003linemap_position_for_line_and_column (set, map, line, column);
(gdb) p r
$68 = 252480
(gdb) p *map
$70 = { = {start_location = 251584}, reason = LC_LEAVE, sysp = 0
'\000', m_column_and_range_bits = 12, 
  m_range_bits = 5, to_file = 0x2ac9800 "pr99446-1.h", to_line = 2,
included_from = 238400}
(gdb) p *result
$74 = { = {start_location = 251616}, reason = LC_LEAVE, sysp = 0
'\000', m_column_and_range_bits = 12, 
  m_range_bits = 5, to_file = 0x2b0a2d0 "pr99446.c", to_line = 2, included_from
= 0}

but line 2 does not exist in both files.

[Bug middle-end/100046] compare with itself

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

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

Richard Biener  changed:

   What|Removed |Added

  Component|rtl-optimization|middle-end

--- Comment #1 from Richard Biener  ---
We miss the equality on GIMPLE which means there would be a missing
canonicalization rule of (x | z) ^ (y | z) to (x ^ y) & ~z - without
trying hard to think about its validity ;)

[Bug c++/100047] New: False -Wmaybe-uninitialized on one var depending on type of other var

[gccbugbjorn at fahller dot se via Gcc-bugs]

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

Bug ID: 100047
   Summary: False -Wmaybe-uninitialized on one var depending on
type of other var
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gccbugbjorn at fahller dot se
  Target Milestone: ---

With the following C++17 code, there's a warning that m_size can be used
uninitialized if m_ptr is a std::unique_ptr<>, but not if it is a raw pointer.
This only happens when some optimization is enabled. -Og is enough. The bug
also applies to gcc-10, gcc-9 and gcc-8 (have not checked older versions).

#include 
#include 
#include 
#include 
#include 

#if EXPOSE_BUG
using buffer_ptr = std::unique_ptr;
#else
using buffer_ptr = const uint8_t*;
#endif

const uint8_t* get(const std::unique_ptr& ptr)
{
return ptr.get();
}
const uint8_t* get(const uint8_t* ptr)
{
return ptr;
}

class packet_buffer
{
public:
using const_iterator = const uint8_t*;
packet_buffer() : m_ptr(nullptr), m_size(0) {}
packet_buffer(buffer_ptr ptr, uint16_t size)
: m_ptr(std::move(ptr)), m_size(size)
{
}
size_t size() const { return m_size; }   // <- here
const uint8_t* data() const { return get(m_ptr); }
const_iterator begin() const { return data(); }
const_iterator end() const { return data() + size(); }
private:
buffer_ptr m_ptr;
uint16_t m_size = 0;
};


std::string func()
{
auto f =
[](std::optional result) {
  auto&& b = result.value();
  return std::string(b.begin(), b.end());
};
return f(std::nullopt);
}

Godbolt link:
https://godbolt.org/z/63z8qzcxv