[Bug rust/113056] [14 regression] Build failure in libgrust

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

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

--- Comment #9 from Andrew Pinski  ---
I am testing out using an absolute path for configure right now. Seeing if that
changes things ...

[Bug rust/113056] [14 regression] Build failure in libgrust

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

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

--- Comment #8 from Sam James  ---
for the pkg build (original report): no
for the quick test I did earlier: yes because I was rushing, oops

[Bug rust/113056] [14 regression] Build failure in libgrust

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2023-12-18
 Status|UNCONFIRMED |WAITING

--- Comment #7 from Andrew Pinski  ---
Wait are you building in the src directory?

[Bug rust/113056] [14 regression] Build failure in libgrust

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

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

--- Comment #6 from Andrew Pinski  ---
I just did:
```
mkdir objdir
cd objdir
../configure --enable-languages=rust
make -j24
```

And it work ...

[Bug c/88737] RFE: Track ownership moves

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

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

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

I would say it is rather likely that C will get something like this at some
point. 

BTW: Any use of the pointer value after free as in comment #2 is UB.

[Bug debug/113057] New: Segmentation fault in dwarf2out.cc:941 with -O -fno-dwarf2-cfi-asm

[iamanonymous.cs at gmail dot com via Gcc-bugs]

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

Bug ID: 113057
   Summary: Segmentation fault in dwarf2out.cc:941 with -O
-fno-dwarf2-cfi-asm
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---

Compiler Explorer: https://godbolt.org/z/4ndYafjnT

***
OS and Platform:
$ uname -a:
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
gcc version:
$ gcc -v
Using built-in specs.
COLLECT_GCC=/root/gcc_set/202311291030/bin/gcc
COLLECT_LTO_WRAPPER=/root/gcc_set/202311291030/libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gcc_set/202311291030
--with-gmp=/root/build_essential --with-mpfr=/root/build_essential
--with-mpc=/root/build_essential --enable-languages=c,c++ --disable-multilib
--with-sanitizer=address,undefined,thread,leak
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20231129 (experimental) (GCC) 

git version: 99fa0bfd63d97825c4221dcd3123940f1d0e6291
***
Program:
$ cat mutant.c
int __RTL (startwith ("final")) a () {
(function "" ) 
}

***
Command Lines:
$ gcc -O -fno-dwarf2-cfi-asm mutant.c
mutant.c:3:1: internal compiler error: Segmentation fault
3 | }
  | ^
0x101491f crash_signal
../../gcc/gcc/toplev.cc:316
0xb6efb7 vec::iterate(unsigned int,
dw_cfi_node**) const
../../gcc/gcc/vec.h:951
0xb6efb7 output_call_frame_info
../../gcc/gcc/dwarf2out.cc:941
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/88737] RFE: Track ownership moves

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

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

--- Comment #9 from Richard Biener  ---
We do now have the analyzer and -Wuse-after-free.  I don't think a rust-like
borrow checking feature will ever work or is sensible to implement in C.  Use
rust if you need such a feature.

I'm also not sure a "weaker" form of borrow checking is actually useful.

That would leave "custom" alloc-free like attributes using the -Wuse-after-free
or the corresponding analyzer diagnostics without any other semantic
side-effects.  Is that what you actually want?

[Bug tree-optimization/113026] Bogus -Wstringop-overflow warning on simple memcpy type loop

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #5 from rguenther at suse dot de  ---
On Fri, 15 Dec 2023, avieira at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113026
> 
> --- Comment #4 from avieira at gcc dot gnu.org ---
> Drive by comments as it's been a while since I looked at this. I'm also
> surprised we didn't adjust the bounds. But why do we only subtract VF? Like 
> you
> say, if there's no loop around edge, can't we guarantee the epilogue will only
> need to iterate at most VF-1?  This is assuming we didn't take an early exit,
> if we do then we can't assume anything as the iterations 'reset'.

Subtracting can bring down epilogue iterations max to 1 while yes,
we should also apply a max of VF-1 but in addition to the subtraction.

[Bug fortran/87448] ICE at trans-expr:3417 in allocate statement with type signature using an associated variable

[paul.richard.thomas at gmail dot com via Gcc-bugs]

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

--- Comment #6 from paul.richard.thomas at gmail dot com  ---
Hi Harald,

I had forgotten about this PR because the fix became incorporated in the
patch for PR89645. In consequence, pr87448.f90 disappeared from the pr87477
failures :-)

One of the last tasks before submitting the fix-up patch for PR89645 was to
remove this chunk because I couldn't understand why it was there.

Thanks for the reminder.

Paul


On Sun, 17 Dec 2023 at 17:49, anlauf at gcc dot gnu.org <
gcc-bugzi...@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87448
>
> --- Comment #5 from anlauf at gcc dot gnu.org ---
> (In reply to Paul Thomas from comment #4)
> > Created attachment 56484 [details]
> > Fix for this PR
> >
> > Somehow this missed being a blocker for the ASSOCIATE meta-bug.
> >
> > The patch is so unbelievably simple that I am going to think about it
> for 24
> > hours, even though it regtests just fine :-)
>
> And it is so simple that you seem to have forgotten about it...
>
> Are you going to pursue it?
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug rust/113056] [14 regression] Build failure in libgrust

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

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

--- Comment #5 from Sam James  ---
ftr (given I only gave a packaged build log) repro'd with ./configure
--prefix=/tmp/gcc --enable-languages=c,c++,rust --enable-multilib
--with-multilib-list=m32,m64 --with-checking=yes,extra,rtl --disable-analyzer
--disable-cet --disable-default-pie --disable-default-ssp --disable-gcov
--disable-libada --disable-libatomic --disable-libgomp --disable-libitm
--disable-libquadmath --disable-libsanitizer --disable-libssp
--disable-libstdcxx-pch --disable-libvtv --disable-lto --disable-nls
--disable-objc-gc --disable-systemtap --disable-werror && make

[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3

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

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

--- Comment #43 from Kewen Lin  ---
Created attachment 56899
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56899=edit
Previously reduced case for comment 10

[Bug target/111591] ppc64be: miscompilation with -mstrict-align / -O3

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

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

--- Comment #42 from Kewen Lin  ---
(In reply to Richard Biener from comment #41)
> What's the "other" testcase?  Do we know that doesn't suffer from the same
> uninitialized issue?

For "other" test cases, I guessed he referred to my comment #c31, these are
comment #c9 and #c10. Previously I further reduced #c10 and I didn't detect
obvious uninitialized issue (but I could be wrong).

[Bug rust/113056] [14 regression] Build failure in libgrust

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

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

--- Comment #4 from Andrew Pinski  ---
Looks like multilib support in libgrust is just broken. I suspect it would be
worse on other targets where there are many more multilibs.

[Bug rust/113056] [14 regression] Build failure in libgrust

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

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

--- Comment #3 from Andrew Pinski  ---
Well this is not right:
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/build/32/./gcc/xgcc: not

32 should not be there ...

[Bug rust/113056] [14 regression] Build failure in libgrust

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

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

--- Comment #2 from Sam James  ---
Created attachment 56898
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56898=edit
build.log.xz

[Bug rust/113056] [14 regression] Build failure in libgrust

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

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

--- Comment #1 from Sam James  ---
Created attachment 56897
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56897=edit
config.log (libgrust)

[Bug rust/113056] New: [14 regression] Build failure in libgrust

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

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

Bug ID: 113056
   Summary: [14 regression] Build failure in libgrust
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rust
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: dkm at gcc dot gnu.org, gcc-rust at gcc dot gnu.org
  Target Milestone: ---

This started on this week's snapshot (obviously). I've not analysed it at all
yet.

```
/bin/sh
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/gcc-14-20231217/configure
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --prefix=/usr
--bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/14
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/14/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/14/include/g++-v14
--disable-silent-rules --disable-dependency-tracking
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/14/python
--enable-languages=c,c++,fortran,rust --enable-obsolete --enable-secureplt
--disable-werror --with-system-zlib --enable-nls --without-included-gettext
--disable-libunwind-exceptions --enable-checking=yes,extra,rtl
--with-bugurl=https://bugs.gentoo.org/ --with-pkgversion=Gentoo Hardened
14.0.0_pre20231217 p11 --with-gcc-major-version-only --enable-libstdcxx-time
--enable-lto --disable-libstdcxx-pch --enable-shared --enable-threads=posix
--enable-__cxa_atexit --enable-clocale=gnu --enable-multilib
--with-multilib-list=m32,m64 --disable-fixed-point --enable-targets=all
--enable-libgomp --disable-libssp --disable-libada --enable-cet
--disable-systemtap --enable-valgrind-annotations --disable-vtable-verify
--disable-libvtv --with-zstd --with-isl --disable-isl-version-check
--enable-default-pie --enable-host-pie --enable-host-bind-now
--enable-default-ssp --with-build-config=bootstrap-O3 bootstrap-lto
bootstrap-cet
[...]
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for style of include used by make... GNU
checking for x86_64-pc-linux-gnu-gcc...
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/build/32/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/build/32/./gcc/
-B/usr/x86_64-pc-lin
ux-gnu/bin/ -B/usr/x86_64-pc-linux-gnu/lib/ -isystem
/usr/x86_64-pc-linux-gnu/include -isystem /usr/x86_64-pc-linux-gnu/sys-include 
-m32
checking for suffix of object files... configure: error: in
`/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/build/32/libgrust':
configure: error: cannot compute suffix of object files: cannot compile
See `config.log' for more details
make[1]: *** [Makefile:16176: configure-libgrust] Error 1
make[1]: Leaving directory
'/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/build'
make[1]: *** Waiting for unfinished jobs
[...]
```

and from libgrust's config.log:
```
[...]
configure:3271: checking for x86_64-pc-linux-gnu-gcc
configure:3298: result:
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/build/32/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/build/32/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/u
sr/x86_64-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem
/usr/x86_64-pc-linux-gnu/sys-include  -m32
configure:3567: checking for C compiler version
configure:3576:
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/build/32/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/build/32/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_6
4-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem
/usr/x86_64-pc-linux-gnu/sys-include  -m32 --version >&5
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/gcc-14-20231217/libgrust/configure:
1: eval:
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/build/32/./gcc/xgcc: not
found
configure:3587: $? = 127
configure:3576:
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/build/32/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/build/32/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_6
4-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem
/usr/x86_64-pc-linux-gnu/sys-include  -m32 -v >&5
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/gcc-14-20231217/libgrust/configure:
1: eval:
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/build/32/./gcc/xgcc: not
found
configure:3587: $? = 127
configure:3576:
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/build/32/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/build/32/./gcc/
-B/usr/x86_64-pc-linux-gnu/bin/ -B/usr/x86_6
4-pc-linux-gnu/lib/ -isystem /usr/x86_64-pc-linux-gnu/include -isystem
/usr/x86_64-pc-linux-gnu/sys-include  -m32 -

[Bug tree-optimization/113054] [14 regressions] ODR warnings when building new SCCP pass

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

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

--- Comment #4 from Andrew Pinski  ---
Created attachment 56896
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56896=edit
Patch which I am testing

[Bug tree-optimization/113054] [14 regressions] ODR warnings when building new SCCP pass

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Target Milestone|--- |14.0
   Last reconfirmed||2023-12-18
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
I have a patch.

[Bug tree-optimization/113054] [14 regressions] ODR warnings when building new SCCP pass

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

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

--- Comment #2 from Andrew Pinski  ---
Note I also don't like how dead_stmts is a static variable either but that
would be for another change.

[Bug preprocessor/80755] __has_include_next: internal compiler error: NULL directory in find_file

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

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

Sam James  changed:

   What|Removed |Added

 CC||sjames at gcc dot gnu.org
   See Also||https://bugs.gentoo.org/sho
   ||w_bug.cgi?id=920233

--- Comment #3 from Sam James  ---
We seem to have had another report of this downstream in Gentoo at
https://bugs.gentoo.org/920233 on musl systems.

[Bug driver/112759] [13/14 regression] mips -march=native detection broken with gcc 13+ since r13-3178-g66c48be23e0fa5

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

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

--- Comment #6 from YunQiang Su  ---
ohh, it should be concat(" ", NULL);

[Bug target/113039] [14 Regression] -fcf-protection -fcf-protection=branch doesn't work

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

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

Hongtao Liu  changed:

   What|Removed |Added

 CC||liuhongt at gcc dot gnu.org

--- Comment #3 from Hongtao Liu  ---
Currently it's defined as EnumSet and -fcf-protection=branch won't unset any
others bits since they're in different groups.

2000fcf-protection=
2001Common Joined RejectNegative Enum(cf_protection_level) EnumSet
Var(flag_cf_protection) Init(CF_NONE)
2002-fcf-protection=[full|branch|return|none|check] Instrument functions with
checks to verify jump/call/return control-flow transfer
2003instructions have valid targets.
2004
2005Enum
2006Name(cf_protection_level) Type(enum cf_protection_level)
UnknownError(unknown Control-Flow Protection Level %qs)
2007
2008EnumValue
2009Enum(cf_protection_level) String(full) Value(CF_FULL) Set(1)
2010
2011EnumValue
2012Enum(cf_protection_level) String(branch) Value(CF_BRANCH) Set(2)
2013
2014EnumValue
2015Enum(cf_protection_level) String(return) Value(CF_RETURN) Set(3)
2016
2017EnumValue
2018Enum(cf_protection_level) String(check) Value(CF_CHECK) Set(4)
2019
2020EnumValue
2021Enum(cf_protection_level) String(none) Value(CF_NONE) Set(1)

[Bug driver/112759] [13/14 regression] mips -march=native detection broken with gcc 13+ since r13-3178-g66c48be23e0fa5

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

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

--- Comment #5 from YunQiang Su  ---
It's my fault.
I misunderstanding `reconcat`:

if `optr` is NULL, it cannot work as the `s1` at the sametime.
If so, the return string will be empty.

So, let's define and initial ret like this:

char *ret = concat(" "); 

Any idea?

[Bug libstdc++/113055] New: possibly-const-range missing constraints

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 113055
   Summary: possibly-const-range missing constraints
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

ranges_base.h#L628:

template
  constexpr auto&
  __possibly_const_range(_Range& __r) noexcept
  {
if constexpr (constant_range && !constant_range<_Range>)
  return const_cast(__r);
else
  return __r;
  }

But according to the current wording, _Range must satisfy input_range, which
means the following should not be accepted:

  #include 
  #include 

  int main() {
std::vector v;
auto r = std::views::counted(std::back_inserter(v), 3);
auto ce = std::ranges::cend(r);
  }

https://godbolt.org/z/Wa4Y3fPa6

Although I tried to submit LWG 3768, but it was rejected.

[Bug tree-optimization/113054] [14 regressions] ODR warnings when building new SCCP pass

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

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

--- Comment #1 from Andrew Pinski  ---
My suggestion is to wrap most of the code in gimple-ssa-sccopy.cc inside an
anonymous namespace.

[Bug tree-optimization/113054] New: [14 regressions] ODR warnings when building new SCCP pass

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

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

Bug ID: 113054
   Summary: [14 regressions] ODR warnings when building new SCCP
pass
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: fkastl at suse dot cz
  Target Milestone: ---

The new SCCP pass introduces some new -Wodr warnings:
```
[...]
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/gcc-14-20231217/gcc/gimple-ssa-sccopy.cc:121:
note: a field with different name is defined in another translation unit
  121 |   bool active; /* scc_discovery::compute_sccs () only considers a
subgraph of
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/gcc-14-20231217/gcc/graphds.h:35:8:
warning: type ‘struct vertex’ violates the C++ One Definition Rule [-Wodr]
   35 | struct vertex
  |^
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/gcc-14-20231217/gcc/gimple-ssa-sccopy.cc:119:
note: a different type is defined in another translation unit
  119 | struct vertex
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/gcc-14-20231217/gcc/graphds.h:37:22:
note: the first difference of corresponding definitions is field ‘pred’
   37 |   struct graph_edge *pred, *succ;
  |  ^
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/gcc-14-20231217/gcc/gimple-ssa-sccopy.cc:121:
note: a field with different name is defined in another translation unit
  121 |   bool active; /* scc_discovery::compute_sccs () only considers a
subgraph of
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/gcc-14-20231217/gcc/graphds.h:35:
warning: type ‘struct vertex’ violates the C++ One Definition Rule [-Wodr]
   35 | struct vertex
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/gcc-14-20231217/gcc/gimple-ssa-sccopy.cc:119:
note: a different type is defined in another translation unit
  119 | struct vertex
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/gcc-14-20231217/gcc/graphds.h:37:
note: the first difference of corresponding definitions is field ‘pred’
   37 |   struct graph_edge *pred, *succ;
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20231217/work/gcc-14-20231217/gcc/gimple-ssa-sccopy.cc:121:
note: a field with different name is defined in another translation unit
  121 |   bool active; /* scc_discovery::compute_sccs () only considers a
subgraph of
[...]
```

[Bug middle-end/110115] [11/12/13/14 Regression] Wrong code at -O1 on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-18
  Known to fail||11.1.0
Summary|Wrong code at -O1 on|[11/12/13/14 Regression]
   |x86_64-linux-gnu|Wrong code at -O1 on
   ||x86_64-linux-gnu
   Target Milestone|--- |11.5
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to work||10.1.0

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

[Bug target/110027] Misaligned vector store on detect_stack_use_after_return

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pobrn at protonmail dot com

--- Comment #7 from Andrew Pinski  ---
*** Bug 113053 has been marked as a duplicate of this bug. ***

[Bug sanitizer/113053] local variable misaligned with AddressSanitizer

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Andrew Pinski  ---
Dup.

*** This bug has been marked as a duplicate of bug 110027 ***

[Bug sanitizer/113053] local variable misaligned with AddressSanitizer

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|RESOLVED|UNCONFIRMED
 Resolution|DUPLICATE   |---

--- Comment #2 from Andrew Pinski  ---
Wait wrong one.

[Bug sanitizer/84508] Load of misaligned address using _mm_load_sd

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pobrn at protonmail dot com

--- Comment #18 from Andrew Pinski  ---
*** Bug 113053 has been marked as a duplicate of this bug. ***

[Bug sanitizer/113053] local variable misaligned with AddressSanitizer

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

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

*** This bug has been marked as a duplicate of bug 84508 ***

[Bug sanitizer/113053] New: local variable misaligned with AddressSanitizer

[pobrn at protonmail dot com via Gcc-bugs]

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

Bug ID: 113053
   Summary: local variable misaligned with AddressSanitizer
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pobrn at protonmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Created attachment 56895
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56895=edit
source code and tree/rtl dumps

Consider the following code:

#include 
#include 

struct thing {
int x[5] __attribute__((aligned(64)));
};

__attribute__((noinline))
void f(void *x)
{
assert((uintptr_t) x % 64 == 0);
}

int main()
{
struct thing t;
static_assert(_Alignof(t) == 64);
assert((uintptr_t)  % 64 == 0);

f();
}


When compiled with `gcc -O2 -fsanitize=address`, the following assembly is
generated:


10d0 :
10d0:   55  push   rbp
10d1:   48 89 e5movrbp,rsp
10d4:   41 55   push   r13
10d6:   41 54   push   r12
10d8:   53  push   rbx
10d9:   48 83 e4 c0 andrsp,0xffc0
10dd:   48 81 ec c0 00 00 00subrsp,0xc0
10e4:   8b 05 56 30 00 00   moveax,DWORD PTR [rip+0x3056]  
 # 4140 <__asan_option_detect_stack_use_after_return@@Base>
10ea:   48 8d 5c 24 20  learbx,[rsp+0x20] # ?
10ef:   49 89 ddmovr13,rbx
10f2:   85 c0   test   eax,eax
10f4:   0f 85 95 00 00 00   jne118f 
10fa:   48 8d 05 df 0f 00 00learax,[rip+0xfdf]# 20e0
<__PRETTY_FUNCTION__.0+0x40>
1101:   49 89 dcmovr12,rbx
1104:   48 c7 03 b3 8a b5 41movQWORD PTR [rbx],0x41b58ab3
110b:   48 8d 7b 20 leardi,[rbx+0x20] # ?
...
114d:   e8 ae 01 00 00  call   1300 
...
118f:   bf 80 00 00 00  movedi,0x80
1194:   e8 a7 fe ff ff  call   1040 <__asan_stack_malloc_1@plt>
1199:   48 85 c0test   rax,rax
119c:   48 0f 45 d8 cmovne rbx,rax
11a0:   e9 55 ff ff ff  jmp10fa 


Assume that stack-user-after-return detection is enabled
(`ASAN_OPTIONS=detect_stack_use_after_return=1`). In that case the jump at
0x10f4 will be taken, if __asan_stack_malloc_1 returns a 64 byte aligned
address, then the lea at 0x110b will add 32 to the address, making it not 64
byte aligned anymore.

Now confusingly, the error cannot be reproduced on the Compiler Explorer or in
the GCC docker container because the assembly is different, for example they
call `__asan_stack_malloc_2`, and there is still a +64 to get the address of
the variable, but it is done as a single step, not split up into two parts.

But this code is generated on both current Arch Linux (GCC 13.2.1 20230801),
and Ubuntu 22.04 (GCC 11.4.0-1ubuntu1~22.04). One can easily trigger this error
for example in an Arch container:

$ docker run --rm -it archlinux
# pacman -Syu gcc nano --noconfirm
# nano x.c # etc...
# gcc -O2 -fsanitize=address x.c
# ASAN_OPTIONS=detect_stack_use_after_return=1 ./a.out
a.out: x.c:11: f: Assertion `(uintptr_t) x % 64 == 0' failed.
Aborted (core dumped)


GCC on Arch Linux is configured as follows:
https://gitlab.archlinux.org/archlinux/packaging/packages/gcc/-/blob/64b6b1ded75259ba7e9311d0e5b1ab44320b92d5/PKGBUILD#L111

[Bug middle-end/110141] [12/13/14 Regression] Wrong code at -O2 on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Wrong code at -O2 on|[12/13/14 Regression] Wrong
   |x86_64-linux-gnu|code at -O2 on
   ||x86_64-linux-gnu
 Ever confirmed|0   |1
   Last reconfirmed||2023-12-17
   Target Milestone|--- |12.4
 Status|UNCONFIRMED |NEW

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

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

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

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

--- Comment #12 from Jonathan Wakely  ---
Because otherwise I'm going to get blamed for every bug older than 2022-11-01!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111270#c1

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

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

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

--- Comment #11 from Jonathan Wakely  ---
(In reply to David Binderman from comment #5)
> I have the last 18 months or so history and that's a whopping
> 3.8 Gig on it's own.

I have a full clone with all history and it's only 3.3g, I'm not sure what you
have there.

(In reply to David Binderman from comment #6)
> I think it would be a reasonable git enhancement if it could
> handle the last (year, 3 years, 5 years, 10 years) of commits
> without having to download 30+ years of commits.

Git can already do that fine. You just told it to create a shallow clone with a
year of history, so of course it can't tell you about anything older than that.
If you increase the depth to 3 years, or 10 years, then it will be able to tell
you about that history.

Anyway, if you don't want a full clone that's fine - just realise the
limitations of that and use something different to find who wrote the code:
https://gcc.gnu.org/git/?p=gcc.git;a=blame;f=libcpp/lex.cc;h=273f6b263c8e0f061d643cae9d7f56a22379c773;hb=HEAD

[Bug fortran/96580] F2018 changes to date_and_time intrinsics

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

   Keywords||accepts-invalid, wrong-code
 Status|WAITING |ASSIGNED

[Bug fortran/96580] F2018 changes to date_and_time intrinsics

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

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

Untested patch.

Needs regtesting and documentation update.

[Bug target/113019] [NOT A BUG] Multi-architecture binaries for Linux

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org

--- Comment #7 from Eric Gallager  ---
Perhaps you're looking for something like cosmocc?
https://github.com/jart/cosmopolitan/blob/master/tool/cosmocc/bin/cosmocc
...or perhaps a port of driverdriver.c and lipo from the old Apple GCC to
Linux?
https://opensource.apple.com/source/gcc_42/gcc_42-5566/driverdriver.c.auto.html

[Bug target/112973] Documentation for __builtin_preserve_access_index is not wrapped in extend.texi

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   Severity|normal  |trivial
   Keywords||easyhack

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

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

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to David Binderman from comment #5)
> (In reply to Jonathan Wakely from comment #3)
> > I don't recognise that code, are you sure I wrote it?  d4ba3b369c did not
> > touch that code.
> 
> No idea. git blame is known to lie from time to time. I am no
> expert at it.

It never lies. Here it's telling you the lines in question are present in the
oldest commit in your repo. It's not git's fault that your history stops at
that commit.

You can use https://gcc.gnu.org/git or https://github.com/gcc-mirror/gcc to see
the full history (and check blame for that file).

[Bug bootstrap/86559] Build failure on AIX 5.3

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX
   Target Milestone|--- |9.0

--- Comment #5 from Andrew Pinski  ---
AIX 5.3 support was removed in GCC 9 by r9-2371-g116c7f320e45d6 .

[Bug c/55422] gcc does not diagnose change of linkage for a function.

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #8 from Andrew Pinski  ---
Dup of bug 111708 which is fixed on the trunk for GCC 14.

*** This bug has been marked as a duplicate of bug 111708 ***

[Bug c/111708] Calling external global function instead of local static function.

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||cookevillain at yahoo dot com

--- Comment #11 from Andrew Pinski  ---
*** Bug 55422 has been marked as a duplicate of this bug. ***

[Bug target/56676] unnecesary splitted load when using avx2

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #7 from Andrew Pinski  ---
Changed the generic tuning by r11-7115-gb80fefd626460f (PR 98172) so fixed.

[Bug target/56676] unnecesary splitted load when using avx2

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

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

--- Comment #6 from Andrew Pinski  ---
GCC 11 produces:
```
_Z3fooPiS_:
.LFB0:
.cfi_startproc
vmovdqu (%rdi), %ymm2
vmovdqu 32(%rdi), %ymm3
vpmulld (%rsi), %ymm2, %ymm1
vpmulld 32(%rsi), %ymm3, %ymm0
vpaddd  %ymm0, %ymm1, %ymm1
vmovdqu 64(%rdi), %ymm4
vpmulld 64(%rsi), %ymm4, %ymm0
vpaddd  %ymm1, %ymm0, %ymm0
vmovdqu 96(%rdi), %ymm1
vpmulld 96(%rsi), %ymm1, %ymm1
vpaddd  %ymm0, %ymm1, %ymm1
vextracti128$0x1, %ymm1, %xmm0
vpaddd  %xmm1, %xmm0, %xmm0
vpsrldq $8, %xmm0, %xmm1
vpaddd  %xmm1, %xmm0, %xmm0
vpsrldq $4, %xmm0, %xmm1
vpaddd  %xmm1, %xmm0, %xmm0
vmovd   %xmm0, %eax
vzeroupper
ret
```


While GCC 10 produces:
```
_Z3fooPiS_:
.LFB0:
.cfi_startproc
vmovdqu (%rdi), %xmm3
vmovdqu (%rsi), %xmm4
vinserti128 $0x1, 16(%rdi), %ymm3, %ymm1
vinserti128 $0x1, 16(%rsi), %ymm4, %ymm0
vmovdqu 32(%rdi), %xmm5
vmovdqu 32(%rsi), %xmm6
vpmulld %ymm1, %ymm0, %ymm0
vmovdqu 64(%rdi), %xmm7
vmovdqu 64(%rsi), %xmm3
vinserti128 $0x1, 48(%rdi), %ymm5, %ymm2
vinserti128 $0x1, 48(%rsi), %ymm6, %ymm1
vmovdqu 96(%rsi), %xmm4
vmovdqu 96(%rdi), %xmm5
vpmulld %ymm2, %ymm1, %ymm1
vinserti128 $0x1, 80(%rdi), %ymm7, %ymm2
vpaddd  %ymm1, %ymm0, %ymm0
vinserti128 $0x1, 80(%rsi), %ymm3, %ymm1
vpmulld %ymm2, %ymm1, %ymm1
vinserti128 $0x1, 112(%rsi), %ymm4, %ymm2
vpaddd  %ymm0, %ymm1, %ymm0
vinserti128 $0x1, 112(%rdi), %ymm5, %ymm1
vpmulld %ymm2, %ymm1, %ymm1
vpaddd  %ymm0, %ymm1, %ymm1
vmovdqa %xmm1, %xmm0
vextracti128$0x1, %ymm1, %xmm1
vpaddd  %xmm1, %xmm0, %xmm0
vpsrldq $8, %xmm0, %xmm1
vpaddd  %xmm1, %xmm0, %xmm0
vpsrldq $4, %xmm0, %xmm1
vpaddd  %xmm1, %xmm0, %xmm0
vmovd   %xmm0, %eax
vzeroupper
ret
```

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2023-12-17

--- Comment #9 from Andrew Pinski  ---
This is almost definitely a valgrind issue.
We start with:
  /* Align the source pointer.  */
  misalign = (uintptr_t)s & 15;
  p = (const uint8_t *)((uintptr_t)s & -16);
  data = vld1q_u8 (p);


Which all other targets do too.

Basically this is how you realign the pointer and if don't depend on the bytes
that is not in the original pointer, then this is valid.

Does it work correctly without valgrind?

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

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

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

--- Comment #8 from Andrew Pinski  ---
e75b54a2d932 libcpp/lex.c  (Richard Earnshaw 2012-03-22 17:54:55 + 
869)   /* Align the source pointer.  */

[Bug tree-optimization/102725] -fno-builtin leads to call of strlen since r12-4283-g6f966f06146be768

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

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

--- Comment #12 from Georg-Johann Lay  ---
(In reply to Andrew Pinski from comment #1)
> You need -fno-tree-loop-distribution -fno-tree-loop-distribute-patterns to
> turn it off.  There is another older bug about this for memcpy.

This is also a documentation issue.

Neither from the naming of that option nor from its documentation one can
concluse that it inhibits open-coded-foo -> foo transformations.

And IMO options that disable all builtin generations should be available on
single function basis, like -fno-auto-strlen or whatever.

Moreover, introducing a call to strlen in a function named "strlen" (or with
assembly name "strlen") is not very wise.

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #7 from David Binderman  ---
I tried:

$ git fetch --shallow-since=1/1/2021

and the blame still has ^ on the front of it.

^abca670596 libcpp/lex.c  (Ian Lance Taylor  2020-12-31 11:23:30 -0800  869)  
/* Align the source pointer.  */
^abca670596 libcpp/lex.c  (Ian Lance Taylor  2020-12-31 11:23:30 -0800  870)  
misalign = (uintptr_t)s & 15;
^abca670596 libcpp/lex.c  (Ian Lance Taylor  2020-12-31 11:23:30 -0800  871)  
p = (const uint8_t *)((uintptr_t)s & -16);
^abca670596 libcpp/lex.c  (Ian Lance Taylor  2020-12-31 11:23:30 -0800  872)  
data = vld1q_u8 (p);

IMHO, most ARM bugs seem to land in the in-tray of Richard Sandiford.
Maybe Richard might recognise the code ?

[Bug c/102939] Ridiculously long compilation times on (admittedly itself ridiculous) pointer declaration

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||uecker at gcc dot gnu.org
 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from uecker at gcc dot gnu.org ---
Fixed on trunk.

[Bug c/102558] missing warning comparing T[static N] to null

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #3 from uecker at gcc dot gnu.org ---
.

[Bug c/102558] missing warning comparing T[static N] to null

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||uecker at gcc dot gnu.org

--- Comment #2 from uecker at gcc dot gnu.org ---
Fixed on trunk.

[Bug c/112840] feature request: warn on incorrect tagged union value access

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

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||uecker at gcc dot gnu.org

--- Comment #2 from uecker at gcc dot gnu.org ---
I would go for a more generic feature where one can specify some invariant /
condition that needs be true when a member of a struct / union is accessed.



 struct S {
enum T t;
union U {
int i   [[gnu::guard(.t == I)]];
float f [[gnu::guard(.t == f)]];
} u;
};

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
(In reply to Jonathan Wakely from comment #4)
> That's what the ^ on the commit suggests is happening.

Righto.

> You can fix your history with:
> git fetch --unshallow

trunk.year $ git fetch --unshallow
remote: Enumerating objects: 1072084
^C
trunk.year $ 

It is not practical for me to download more than a million objects.

I think it would be a reasonable git enhancement if it could
handle the last (year, 3 years, 5 years, 10 years) of commits
without having to download 30+ years of commits.

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #5 from David Binderman  ---
(In reply to Jonathan Wakely from comment #3)
> I don't recognise that code, are you sure I wrote it?  d4ba3b369c did not
> touch that code.

No idea. git blame is known to lie from time to time. I am no
expert at it.

> Do you have a shallow clone, which happens to have my d4ba3b369c as the
> oldest commit?

No idea. I know the gcc project is over 30 years old and it is not
feasible for me to download the entire history, it is too large.

I have the last 18 months or so history and that's a whopping
3.8 Gig on it's own.

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

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

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

--- Comment #4 from Jonathan Wakely  ---
That's what the ^ on the commit suggests is happening.

You can fix your history with:
git fetch --unshallow

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

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

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

--- Comment #3 from Jonathan Wakely  ---
I don't recognise that code, are you sure I wrote it?  d4ba3b369c did not touch
that code.
Do you have a shallow clone, which happens to have my d4ba3b369c as the oldest
commit?

[Bug c++/113052] New: Templated conversion operator of templated class is not considered in argument to equality operator

[ers.trion at gmail dot com via Gcc-bugs]

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

Bug ID: 113052
   Summary: Templated conversion operator of templated class is
not considered in argument to equality operator
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ers.trion at gmail dot com
  Target Milestone: ---

See https://godbolt.org/z/fWKfEj7zb .

template 
struct accessor {
template 
operator T() const;
};

void foo() {
accessor acc;
(void) (acc == 10);
}

reports 

: In function 'void foo()':
:9:21: error: no match for 'operator==' (operand types are
'accessor' and 'int')
9 | (void) (acc == 10);
| ~~~ ^~ ~~
| |  |
| |  int
| accessor

, but the code should be accepted (as Clang does).

To trigger this bug it is necessary:

  - that the struct is templated
  - that the conversion operator return the template-argument type of the class
  - that the operator is templated as well (this was reduced from an enable_if)

Possibly related:
  - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89580
  - https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85250

[Bug tree-optimization/113049] Compiles to strlen even with -fno-builtin-strlen -fno-optimize-strlen

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #9 from Andrew Pinski  ---
dup

*** This bug has been marked as a duplicate of bug 102725 ***

[Bug tree-optimization/102725] -fno-builtin leads to call of strlen since r12-4283-g6f966f06146be768

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||gjl at gcc dot gnu.org

--- Comment #11 from Andrew Pinski  ---
*** Bug 113049 has been marked as a duplicate of this bug. ***

[Bug sanitizer/113043] ICE: in emit_move_insn, at expr.cc:4246 with interrupt attribute and x32

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

  Component|target  |sanitizer
   Last reconfirmed||2023-12-17
 Ever confirmed|0   |1
 CC||dodji at gcc dot gnu.org,
   ||dvyukov at gcc dot gnu.org,
   ||jakub at gcc dot gnu.org,
   ||kcc at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from Uroš Bizjak  ---
Middle-end is calling emit_move_insn from:

(gdb) f 3
#3  0x00aac95c in expand_gimple_stmt_1 (stmt=0x7fffe9fe70a0) at
../../git/gcc/gcc/cfgexpand.cc:4030
4030  emit_move_insn (target, temp);
(gdb) list
4026else
4027  {
4028temp = force_operand (temp, target);
4029if (temp != target)
4030  emit_move_insn (target, temp);
4031  }

target = 
(reg:SI 99 [ _5 ])

temp = 
(mem/f/c:DI (plus:DI (reg/f:DI 93 virtual-stack-vars)
(const_int -8 [0xfff8])) [8 d+0 S4 A32])

and triggeres gcc_assert in emit_move_insn due to mode mismatch.

This happens when expanding:

  unsigned int _5;

  __builtin___ubsan_handle_type_mismatch_v1 (&*.Lubsan_data0, _5);

where sanitizer builtin expects PTR.

DEF_SANITIZER_BUILTIN(BUILT_IN_UBSAN_HANDLE_TYPE_MISMATCH_V1,
  "__ubsan_handle_type_mismatch_v1",
  BT_FN_VOID_PTR_PTR,
  ATTR_COLD_NOTHROW_LEAF_LIST)

Confirmed as a sanitizer issue.

[Bug fortran/87448] ICE at trans-expr:3417 in allocate statement with type signature using an associated variable

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Paul Thomas from comment #4)
> Created attachment 56484 [details]
> Fix for this PR
> 
> Somehow this missed being a blocker for the ASSOCIATE meta-bug.
> 
> The patch is so unbelievably simple that I am going to think about it for 24
> hours, even though it regtests just fine :-)

And it is so simple that you seem to have forgotten about it...

Are you going to pursue it?

[Bug target/113045] armv7l-unknown-linux-gnueabihf: valgrind error during build of libcc1

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #2 from David Binderman  ---
The source code in lex.cc is

  /* Align the source pointer.  */
  misalign = (uintptr_t)s & 15;
  p = (const uint8_t *)((uintptr_t)s & -16);
  data = vld1q_u8 (p);

git blame has 

^d4ba3b369c (Jonathan Wakely   2022-11-01 09:48:41 +  869)   /* Align the
source pointer.  */
^d4ba3b369c (Jonathan Wakely   2022-11-01 09:48:41 +  870)   misalign =
(uintptr_t)s & 15;
^d4ba3b369c (Jonathan Wakely   2022-11-01 09:48:41 +  871)   p = (const
uint8_t *)((uintptr_t)s & -16);
^d4ba3b369c (Jonathan Wakely   2022-11-01 09:48:41 +  872)   data =
vld1q_u8 (p);

Adding author of code for their opinion.

[Bug fortran/97592] [11/12/13/14 Regression] Incorrectly set pointer remapping with array pointer argument to CONTIGUOUS dummy

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:5060825aa78b3da036df6437390fd42d094d8f15

commit r14-6644-g5060825aa78b3da036df6437390fd42d094d8f15
Author: Harald Anlauf 
Date:   Sat Dec 16 19:14:55 2023 +0100

Fortran: fix argument passing to CONTIGUOUS,TARGET dummy [PR97592]

gcc/fortran/ChangeLog:

PR fortran/97592
* trans-expr.cc (gfc_conv_procedure_call): For a contiguous dummy
with the TARGET attribute, the effective argument may still be
contiguous even if the actual argument is not simply-contiguous.
Allow packing to be decided at runtime by _gfortran_internal_pack.

gcc/testsuite/ChangeLog:

PR fortran/97592
* gfortran.dg/contiguous_15.f90: New test.

[Bug tree-optimization/113049] Compiles to strlen even with -fno-builtin-strlen -fno-optimize-strlen

[harald at gigawatt dot nl via Gcc-bugs]

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

Harald van Dijk  changed:

   What|Removed |Added

 CC||harald at gigawatt dot nl

--- Comment #8 from Harald van Dijk  ---
(In reply to Georg-Johann Lay from comment #5)
> So then -fno-builtin should also not work? GCC documentation of -fno-builtin
> is the same like for -fno-builtin-function.

-fno-builtin implies -fno-tree-loop-distribute-patterns
(https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=b15458becf4086c463cba0c42db1d8780351201b),
-fno-builtin-strlen does not, but I think you are right that that does not
match the documentation.

(In reply to Georg-Johann Lay from comment #7)
> The documentation of -ftree-loop-distribute-patterns does not relate in any
> way to that.  It's impossible to find this option from a problem description.

-ffreestanding also implies -fno-tree-loop-distribute-patterns, and that option
is documented in a way that would help here. Unless -ffreestanding is used, GCC
assumes the presence of a conforming standard library. It may expand calls to
library functions based on knowledge of what these functions do, and it may
replace code by calls to library functions as well for the same reason.

-fno-builtin and -fno-builtin-(function) are both documented as stopping the
former, but not documented as stopping the latter. The fact that one does, but
not both, is surprising.

[Bug tree-optimization/113049] Compiles to strlen even with -fno-builtin-strlen -fno-optimize-strlen

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

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

--- Comment #7 from Georg-Johann Lay  ---
(In reply to Andreas Schwab from comment #6)
> That's what -fno-tree-loop-distribute-patterns is for.

So you know the GCC sources and can draw that conclusion.

The documentation of -ftree-loop-distribute-patterns does not relate in any way
to that.  It's impossible to find this option from a problem description.

[Bug tree-optimization/113049] Compiles to strlen even with -fno-builtin-strlen -fno-optimize-strlen

[schwab--- via Gcc-bugs]

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

--- Comment #6 from Andreas Schwab  ---
That's what -fno-tree-loop-distribute-patterns is for.

[Bug c++/112899] odr-using constexpr static data member of class exported from module results in linker error

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-12-17

--- Comment #1 from Patrick Palka  ---
It works if we initialize the static data member out of line:

export module A;

export struct A
{
static const int blub;
};

constexpr int A::blub = 42;


Maybe relatedly, we also ICE streaming out a non-trivially initialized static
inline data member:

export module A;

export struct A
{
static int f() { return -1; }
static inline int blub = f();
};

[Bug c++/101463] [11/12/13/14 Regression]Using a constexpr variable template specialization as default argument for non-type template parameter of reference type leads gcc to reject function call

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
  Known to work||6.2.0
Summary|Using a constexpr variable  |[11/12/13/14
   |template specialization as  |Regression]Using a
   |default argument for|constexpr variable template
   |non-type template parameter |specialization as default
   |of reference type leads gcc |argument for non-type
   |to reject function call |template parameter of
   ||reference type leads gcc to
   ||reject function call
   Last reconfirmed||2023-12-17
   Target Milestone|--- |11.5

--- Comment #1 from Patrick Palka  ---
GCC 6.1/6.2 accepts (with -std=c++17), we started ICEing on this testcase after
r7-5370-gb4ba0852099ad2, and then rejecting it after r8-7014-ge8ef9fdfb9fd4b.

[Bug c/113050] __atomic_* builtins should use -Wdiscarded-qualifiers instead of -Wincompatible-pointer-types

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

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

Florian Weimer  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |fw at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-12-17
 Status|UNCONFIRMED |ASSIGNED

--- Comment #4 from Florian Weimer  ---
Patch submitted:

[PATCH] c-family: Use -Wdiscarded-qualifiers for ignored qualifiers in
__atomic_*

[Bug tree-optimization/113049] Compiles to strlen even with -fno-builtin-strlen -fno-optimize-strlen

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

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

--- Comment #5 from Georg-Johann Lay  ---
(In reply to Andreas Schwab from comment #4)
> -fno-builtin-strlen has a different purpose.

So then -fno-builtin should also not work? GCC documentation of -fno-builtin is
the same like for -fno-builtin-function.

At least there should be an option to disable this, e.g. you need it when
building libgcc / libc anyway, you you get silly non-functional libs.

[Bug target/113034] Miscompilation of __m128 ne comparison on LoongArch

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-Decembe
   ||r/640808.html

--- Comment #5 from Xi Ruoyao  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2023-December/640808.html

[Bug tree-optimization/113049] Compiles to strlen even with -fno-builtin-strlen -fno-optimize-strlen

[schwab--- via Gcc-bugs]

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

--- Comment #4 from Andreas Schwab  ---
-fno-builtin-strlen has a different purpose.

[Bug tree-optimization/113049] Compiles to strlen even with -fno-builtin-strlen -fno-optimize-strlen

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

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

--- Comment #3 from Georg-Johann Lay  ---
(In reply to Mikael Pettersson from comment #2)
> Does -fno-tree-loop-distribute-patterns work? That's been the go-to for
> disabling similar loop-to-call transformations people have been objecting to.

It works. But even if it does, that's not intuitive, and -fno-builtin-strlen
should work no matter what.

And also, when a function's assembly name is "funcxyz", then the compiler
should never issue a concocted call to "funcxyz", because the assumptions of
the compiler of what "funcxyz" is doing is obviously wrong.

[Bug sanitizer/112727] [11/12/13 Regression] UBSAN creates GIMPLE path with uninitialized variable

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

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

--- Comment #12 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:97d6683f6aeda4916a89889bde4c051e55aac984

commit r11-11156-g97d6683f6aeda4916a89889bde4c051e55aac984
Author: Jakub Jelinek 
Date:   Fri Dec 8 20:56:48 2023 +0100

c++: Unshare folded SAVE_EXPR arguments during cp_fold [PR112727]

The following testcase is miscompiled because two ubsan instrumentations
run into each other.
The first one is the shift instrumentation.  Before the C++ FE calls
it, it wraps the 2 shift arguments with cp_save_expr, so that side-effects
in them aren't evaluated multiple times.  And, ubsan_instrument_shift
itself uses unshare_expr on any uses of the operands to make sure further
modifications in them don't affect other copies of them (the only not
unshared ones are the one the caller then uses for the actual operation
after the instrumentation, which means there is no tree sharing).

Now, if there are side-effects in the first operand like say function
call, cp_save_expr wraps it into a SAVE_EXPR, and ubsan_instrument_shift
in this mode emits something like
if (..., SAVE_EXPR , SAVE_EXPR  > const)
 __ubsan_handle_shift_out_of_bounds (..., SAVE_EXPR , ...);
and caller adds
SAVE_EXPR  << SAVE_EXPR 
after it in a COMPOUND_EXPR.  So far so good.

If there are no side-effects and cp_save_expr doesn't create SAVE_EXPR,
everything is ok as well because of the unshare_expr.
We have
if (..., SAVE_EXPR  > const)
 __ubsan_handle_shift_out_of_bounds (..., ptr->something[i], ...);
and
ptr->something[i] << SAVE_EXPR 
where ptr->something[i] is unshared.

In the testcase below, the !x->s[j] ? 1 : 0 expression is wrapped initially
into a SAVE_EXPR though, and unshare_expr doesn't unshare SAVE_EXPRs nor
anything used in them for obvious reasons, so we end up with:
if (..., SAVE_EXPR (x)->s[j] ?
1 : 0>, SAVE_EXPR  > const)
 __ubsan_handle_shift_out_of_bounds (..., SAVE_EXPR (x)->s[j] ? 1 : 0>, ...);
and
SAVE_EXPR (x)->s[j] ? 1 : 0> <<
SAVE_EXPR 
So far good as well.  But later during cp_fold of the SAVE_EXPR we find
out that VIEW_CONVERT_EXPR(x)->s[j] ? 0 : 1 is actually
invariant (has TREE_READONLY set) and so cp_fold simplifies the above to
if (..., SAVE_EXPR  > const)
 __ubsan_handle_shift_out_of_bounds (..., (bool) VIEW_CONVERT_EXPR(x)->s[j] ? 0 : 1, ...);
and
((bool) VIEW_CONVERT_EXPR(x)->s[j] ? 0 : 1) << SAVE_EXPR

with the s[j] ARRAY_REFs and other expressions shared in between the two
uses (and obviously the expression optimized away from the COMPOUND_EXPR in
the if condition.

Then comes another ubsan instrumentation at genericization time,
this time to instrument the ARRAY_REFs with strict bounds checking,
and replaces the s[j] in there with s[.UBSAN_BOUNDS (0B, SAVE_EXPR, 8),
SAVE_EXPR]
As the trees are shared, it does that just once though.
And as the if body is gimplified first, the SAVE_EXPR is evaluated
inside
of the if body and when it is used again after the if, it uses a
potentially
uninitialized value of j.1 (always uninitialized if the shift count isn't
out of bounds).

The following patch fixes that by unshare_expr unsharing the folded
argument
of a SAVE_EXPR if we've folded the SAVE_EXPR into an invariant and it is
used more than once.

2023-12-08  Jakub Jelinek  

PR sanitizer/112727
* cp-gimplify.c (cp_fold): If SAVE_EXPR has been previously
folded, unshare_expr what is returned.

* c-c++-common/ubsan/pr112727.c: New test.

(cherry picked from commit 6ddaf06e375e1c15dcda338697ab6ea457e6f497)

[Bug middle-end/112733] [14 Regression] ICE: Segmentation fault in wide-int.cc during GIMPLE pass: sccp

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

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

--- Comment #18 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:124a2110a1f5bbfe7274251b25b3944910296887

commit r11-11155-g124a2110a1f5bbfe7274251b25b3944910296887
Author: Jakub Jelinek 
Date:   Wed Nov 29 12:26:50 2023 +0100

fold-const: Fix up multiple_of_p [PR112733]

We ICE on the following testcase when wi::multiple_of_p is called on
widest_int 1 and -128 with UNSIGNED.  I still need to work on the
actual wide-int.cc issue, the latest patch attached to the PR regressed
bitint-{38,39}.c, so will need to debug that, but there is a clear bug
on the fold-const.cc side as well - widest_int is a signed representation
by definition, using UNSIGNED with it certainly doesn't match what was
intended, because -128 as the second operand effectively means unsigned
131072 bit 0xf80 integer, not the signed char -128
that appeared in the source.

In the INTEGER_CST case a few lines above this we already use
case INTEGER_CST:
  if (TREE_CODE (bottom) != INTEGER_CST || integer_zerop (bottom))
return false;
  return wi::multiple_of_p (wi::to_widest (top), wi::to_widest
(bottom),
SIGNED);
so I think using SIGNED with widest_int is best there (compared to the
other choices in the PR).

2023-11-29  Jakub Jelinek  

PR middle-end/112733
* fold-const.c (multiple_of_p): Pass SIGNED rather than
UNSIGNED for wi::multiple_of_p on widest_int arguments.

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

(cherry picked from commit 5c95bf945c632925efba86dd5dceccdb9da8884c)

[Bug target/112845] [11/12 Regression] ICE: in extract_insn, at recog.cc:2804 with -Os -fcf-protection -c since r8-3504

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:6156cbb74dabb98899f8f481bda4ae969ac22d53

commit r11-11154-g6156cbb74dabb98899f8f481bda4ae969ac22d53
Author: Jakub Jelinek 
Date:   Tue Dec 5 13:17:57 2023 +0100

i386: Fix -fcf-protection -Os ICE due to movabsq peephole2 [PR112845]

The following testcase ICEs in the movabsq $(i32 << shift), r64 peephole2
I've added a while back to use smaller code than movabsq if possible.
If i32 is 0xfa1e0ff3 and shift is not divisible by 8, then it creates
an invalid insn (as 0xfa1e0ff3 CONST_INT is not allowed as
x86_64_immediate_operand nor x86_64_zext_immediate_operand), the peephole2
even triggers on it again and again (this time with shift 0) until it gives
up.

The following patch fixes that.  As ix86_endbr_immediate_operand needs a
CONST_INT and it is hopefully rare, I chose to use FAIL rather than
handling
it in the condition (where I'd probably need to call ctz_hwi again etc.).

2023-12-05  Jakub Jelinek  

PR target/112845
* config/i386/i386.md (movabsq $(i32 << shift), r64 peephole2):
FAIL
if the new immediate is ix86_endbr_immediate_operand.

(cherry picked from commit e0786ca9a18c50ad08c40936b228e325193664b8)

[Bug target/112837] [12 Regression] ICE: RTL check: expected elt 1 type 'i' or 'n', have 'e' (rtx plus) in ix86_elim_entry_set_got, at config/i386/i386.cc:8612 with -fcompare-elim -fpie -fprofile

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:05e3cff4e8b3b544afb1bbefddc342de42641cc1

commit r11-11153-g05e3cff4e8b3b544afb1bbefddc342de42641cc1
Author: Jakub Jelinek 
Date:   Mon Dec 4 09:01:09 2023 +0100

i386: Fix rtl checking ICE in ix86_elim_entry_set_got [PR112837]

The following testcase ICEs with RTL checking, because it sets if
XINT (SET_SRC (set), 1) is UNSPEC_SET_GOT without checking if SET_SRC (set)
is actually an UNSPEC, so any time we see any other insn with PARALLEL
and a SET in it which is not an UNSPEC we ICE during RTL checking or
access there some other union member as if it was an rt_int.
The rest is just small cleanup.

2023-12-04  Jakub Jelinek  

PR target/112837
* config/i386/i386.c (ix86_elim_entry_set_got): Before checking
for UNSPEC_SET_GOT check that SET_SRC is UNSPEC.  Use SET_SRC and
SET_DEST macros instead of XEXP, rename vec variable to set.

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

(cherry picked from commit 4586d7d0a92e9b60d0c01043e0ae262b1e06f337)

[Bug target/112816] [11/12 Regression] ICE unrecognizable_insn with __builtin_signbit and returning struct with int[4]

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

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

--- Comment #14 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:531d80228d85624c0e2eac40cd525dc75686ba95

commit r11-11152-g531d80228d85624c0e2eac40cd525dc75686ba95
Author: Jakub Jelinek 
Date:   Mon Dec 4 09:00:18 2023 +0100

i386: Fix up signbit2 expander [PR112816]

The following testcase ICEs, because the signbit2 expander uses an
explicit SUBREG in the pattern around match_operand with register_operand
predicate.  If we are unlucky enough that expansion tries to expand it
with some SUBREG as operands[1], we have two nested SUBREGs in the IL,
which is not valid and causes ICE later.

2023-12-04  Jakub Jelinek  

PR target/112816
* config/i386/sse.md (signbit2): Force operands[1] into a
REG.

* gcc.target/i386/sse2-pr112816.c: New test.

(cherry picked from commit 994d6dc64435d6b7c50accca9941ee7decd92a22)

[Bug c++/112795] [C++>=14] ICE pragma GCC unroll (n) cxx_eval_constant_expression

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

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

--- Comment #12 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:67762f3d76d42b2d9a436b6279fd111082f47c2b

commit r11-11151-g67762f3d76d42b2d9a436b6279fd111082f47c2b
Author: Jakub Jelinek 
Date:   Mon Dec 4 08:59:15 2023 +0100

c++: #pragma GCC unroll C++ fixes [PR112795]

foo in the unroll-5.C testcase ICEs because cp_parser_pragma_unroll
during parsing calls maybe_constant_value unconditionally, which is
fine if !processing_template_decl, but can ICE otherwise.

While just calling fold_non_dependent_expr there instead could be enough
to fix the ICE (and I guess the right thing to do for backports if any),
I don't see a reason why we couldn't handle a dependent #pragma GCC unroll
argument as well, the unrolling isn't done in the FE and all the middle-end
cares about is that ANNOTATE_EXPR has a 1..65534 last operand when it is
annot_expr_unroll_kind.

So, the following patch changes all the unsigned short unroll arguments
to tree unroll (and thus avoids the tree -> unsigned short -> tree
conversions), does the type and value checking during parsing only if
the argument isn't dependent and repeats it during instantiation.

2023-12-04  Jakub Jelinek  

PR c++/112795
gcc/cp/
* parser.c (cp_parser_pragma_unroll): Use fold_non_dependent_expr
instead of maybe_constant_value.
gcc/testsuite/
* g++.dg/ext/unroll-5.C: New test.

(cherry picked from commit b6c78feea08c36e5754818c6a3d7536b3f8913dc)

[Bug target/111408] [14 Regression] Wrong code at -O2/3 on x86_64-linux-gnu since r14-2866-ge68a31549d9

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

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

--- Comment #9 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

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

commit r11-11150-g1fdae54453d115d73d5a4bfa0257e88000ab18b8
Author: Jakub Jelinek 
Date:   Sat Nov 25 10:31:55 2023 +0100

i386: Fix up *jcc_bt*_mask{,_1} [PR111408]

The following testcase is miscompiled in GCC 14 because the
*jcc_bt_mask and *jcc_bt_mask_1 patterns have just
one argument in (match_operator 0 "bt_comparison_operator" [...])
but as bt_comparison_operator is eq,ne, we need two.
The md readers don't warn about it, after all, some checks can
be done in the predicate rather than specified explicitly, and the
behavior is that anything is accepted as the second argument.

I went through all other i386.md match_operator uses and all others
looked right (extract_operator using 3 operands, all others 2).

I think we'll want to fix this at different spots in older releases
because I think the bug was introduced already in 2008, though most
likely just latent.

2023-11-25  Jakub Jelinek  

PR target/111408
* config/i386/i386.md (*jcc_bt_mask): Add (const_int 0) as
expected second operand of bt_comparison_operator.

* gcc.c-torture/execute/pr111408.c: New test.

(cherry picked from commit 9866c98e1015d98b8fc346d7cf73a0070cce5f69)

[Bug tree-optimization/110731] [11/12 Regression] Wrong-code because of wide-int division since r5-424

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

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

--- Comment #7 from GCC Commits  ---
The releases/gcc-11 branch has been updated by Jakub Jelinek
:

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

commit r11-11148-g9e30ca09c01124333dc97e8c2cb704b74d3c7b60
Author: Jakub Jelinek 
Date:   Wed Jul 19 13:48:53 2023 +0200

wide-int: Fix up wi::divmod_internal [PR110731]

As the following testcase shows, wi::divmod_internal doesn't handle
correctly signed division with precision > 64 when the dividend (and likely
divisor as well) is the type's minimum and the precision isn't divisible
by 64.

A few lines above what the patch hunk changes is:
  /* Make the divisor and dividend positive and remember what we
 did.  */
  if (sgn == SIGNED)
{
  if (wi::neg_p (dividend))
{
  neg_dividend = -dividend;
  dividend = neg_dividend;
  dividend_neg = true;
}
  if (wi::neg_p (divisor))
{
  neg_divisor = -divisor;
  divisor = neg_divisor;
  divisor_neg = true;
}
}
i.e. we negate negative dividend or divisor and remember those.
But, after we do that, when unpacking those values into b_dividend and
b_divisor we need to always treat the wide_ints as UNSIGNED,
because divmod_internal_2 performs an unsigned division only.
Now, if precision <= 64, we don't reach here at all, earlier code
handles it.  If dividend or divisor aren't the most negative values,
the negation clears their most significant bit, so it doesn't really
matter if we unpack SIGNED or UNSIGNED.  And if precision is multiple
of HOST_BITS_PER_WIDE_INT, there is no difference in behavior, while
-0x8000 negates to
-0x8000 the unpacking of it as SIGNED
or UNSIGNED works the same.
In the testcase, we have signed precision 119 and the dividend is
val = { 0, 0xffc0 }, len = 2, precision = 119
both before and after negation.
Divisor is
val = { 2 }, len = 1, precision = 119
But we really want to divide 0x40 by 2
unsigned and then negate at the end.
If it is unsigned precision 119 division
0x40 by 2
dividend is
val = { 0, 0xffc0 }, len = 2, precision = 119
but as we unpack it UNSIGNED, it is unpacked into
0, 0, 0, 0x0040

The following patch fixes it by always using UNSIGNED unpacking
because we've already negated negative values at that point if
sgn == SIGNED and so most negative constants should be treated as
positive.

2023-07-19  Jakub Jelinek  

PR tree-optimization/110731
* wide-int.cc (wi::divmod_internal): Always unpack dividend and
divisor as UNSIGNED regardless of sgn.

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

(cherry picked from commit ece799607c841676f4e00c2fea98bbec6976da3f)

[Bug libstdc++/107367] All standard library algorithms should optimize to pointers internally when they are contiguous iterators after C++20

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2023-12-17
 Ever confirmed|0   |1
   Keywords||missed-optimization
 Resolution|MOVED   |---
 Status|RESOLVED|NEW
   Severity|normal  |enhancement

[Bug libstdc++/107367] All standard library algorithms should optimize to pointers internally when they are contiguous iterators after C++20

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

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

--- Comment #4 from Jonathan Wakely  ---
*** Bug 113046 has been marked as a duplicate of this bug. ***

[Bug libstdc++/113046] Standard algorithms should do de-iterator optimizations

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Jonathan Wakely  ---
dup, no need for a second PR

*** This bug has been marked as a duplicate of bug 107367 ***

[Bug c++/113051] New: -Wformat-signedness wrongly triggers for values from template arguments

[adam.f.badura at gmail dot com via Gcc-bugs]

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

Bug ID: 113051
   Summary: -Wformat-signedness wrongly triggers for values from
template arguments
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adam.f.badura at gmail dot com
  Target Milestone: ---

Consider sample code (https://godbolt.org/z/7T3vGefEq):
```
#include 
#include 

template
auto foo()
{
  return std::printf("%u\n", i);
}

auto bar(std::uint8_t i)
{
  return std::printf("%u\n", i);
}

void test()
{
  foo<11>();
  bar(11);
}
```

When compiled with
```
-std=c++17 -Wformat=1 -Wformat-signedness
```
on GCC 10.2 (where I detected it) and GCC trunk (as on Compiler Explorer from
the link) I'm getting the following warning:
```
: In instantiation of 'auto foo() [with unsigned char i = 11]':
:17:10:   required from here
   17 |   foo<11>();
  |   ~~~^~
:7:24: warning: format '%u' expects argument of type 'unsigned int',
but argument 2 has type 'int' [-Wformat=]
7 |   return std::printf("%u\n", i);
  |   ~^
  ||
  |unsigned int
  |   %u
```

The warning is not reported in `bar` but is reported in `foo` where the
argument comes from the template.

As an attempt to work around the problem I have tried to explicitly force the
type of `i` in `foo` to `std::uint8_t` (https://godbolt.org/z/eK5TTx93o) and
`std::uint16_t` (https://godbolt.org/z/rqY6n58n8), but it didn't help. Only
forcing `std::uint32_t` helped (https://godbolt.org/z/j7MY7YTeG).

[Bug target/112936] LoongArch: Wrong instruction costs

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

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #4 from Xi Ruoyao  ---
Fixed for 14.

[Bug target/112936] LoongArch: Wrong instruction costs

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Xi Ruoyao :

https://gcc.gnu.org/g:50b3f596bd943ec6110c1987f14e5497ce39622f

commit r14-6642-g50b3f596bd943ec6110c1987f14e5497ce39622f
Author: Xi Ruoyao 
Date:   Sat Dec 9 17:41:32 2023 +0800

LoongArch: Fix instruction costs [PR112936]

Replace the instruction costs in loongarch_rtx_cost_data constructor
based on micro-benchmark results on LA464 and LA664.

This allows optimizations like "x * 17" to alsl, and "x * 68" to alsl
and slli.

gcc/ChangeLog:

PR target/112936
* config/loongarch/loongarch-def.cc
(loongarch_rtx_cost_data::loongarch_rtx_cost_data): Update
instruction costs per micro-benchmark results.
(loongarch_rtx_cost_optimize_size): Set all instruction costs
to (COSTS_N_INSNS (1) + 1).
* config/loongarch/loongarch.cc (loongarch_rtx_costs): Remove
special case for multiplication when optimizing for size.
Adjust division cost when TARGET_64BIT && !TARGET_DIV32.
Account the extra cost when TARGET_CHECK_ZERO_DIV and
optimizing for speed.

gcc/testsuite/ChangeLog

PR target/112936
* gcc.target/loongarch/mul-const-reduction.c: New test.

[Bug target/52889] incorrect sign of _mm_nmsub_XX intrinsics in fma4intrin.h

[MathiasPuetz at gmx dot de via Gcc-bugs]

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

--- Comment #3 from MathiasPuetz at gmx dot de ---
Hi Andrew,
I only vaguely remember this after 11 (!) years.
The generated code looks ok on first sight.
However the reference doc (e.g.
https://www.cs.ucr.edu/~csong/cs153/refs/amd64-vol4-media.pdf 581) shows a
different operand order for the vfnmsubpd instruction than the output of the
GNU assembler (vfnmsubps dest,a,b,c vs. c,b,a,dest)
This could just be a peculiarity of GNU assembly mnemonics definitions.
You should check the results of the code though
A=1
B=2
c=3
Should return 3-1*2=1 according to AMD ref guide. Just looking at the code
won’t tell.
I remember that I checked with the Intel compiler as well, and got the expected
result using the same intrinsic code. When I tried with GNU, I didn’t, which
caused me to investigate.
I can’t tell, if the AMD ref guide document is actually correct. Maybe there
was an erratum, that I am not aware of, and Intel rectified this in their
intrinsic definitions.
If the code doesn’t produce the expected result, you would need to talk to AMD
to get to the bottom of this (the mistake might be in their docs).

Anyway, AMD still supports FMA4 code on their latest Epyc CPUs.
Most new binaries won’t run into the issue, as newer compilers would rather
generate AVX256/512 instructions, which are faster on newer hardware. So it’s
not 100% obsolete, but it’s indeed unlikely that someone would practically run
into this except for comparing some old benchmarks after so many years.

Mathias
ParTec AG

[Bug c/113050] -Wincompatible-pointer-types emitted as a warning, not an error, for __atomic_load

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

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

--- Comment #3 from Florian Weimer  ---
(In reply to Florian Weimer from comment #1)
> The warning should be -Wdiscared-qualifiers, which is not an error for C.
> 
> What confused me is that the volatile qualifier is already accepted for the
> first argument. I believe it's valid for the second argument.

Sorry, I wanted to say: “I believe [the warning is] valid for the second
argument.”

[Bug c/113050] -Wincompatible-pointer-types emitted as a warning, not an error, for __atomic_load

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

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

--- Comment #2 from Sam James  ---
Yeah, for every attempt I had to reconstruct it manually, I just got the
expected -Wdiscarded-qualifiers, and then realised it was atomic-specific.

[Bug c/113050] -Wincompatible-pointer-types emitted as a warning, not an error, for __atomic_load

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

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

--- Comment #1 from Florian Weimer  ---
The warning should be -Wdiscared-qualifiers, which is not an error for C.

What confused me is that the volatile qualifier is already accepted for the
first argument. I believe it's valid for the second argument.

[Bug c/113050] New: -Wincompatible-pointer-types emitted as a warning, not an error, for __atomic_load

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

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

Bug ID: 113050
   Summary: -Wincompatible-pointer-types emitted as a warning, not
an error, for __atomic_load
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: arsen at gcc dot gnu.org, fw at gcc dot gnu.org
  Target Milestone: ---

Noticed this when building udisks. I suspect this is actually a dupe of
PR69404, but I felt it was worth filing separately given it's interesting to
have it warn-but-not-error.

The expectation was that this would error (b/c of new 14 default), not just
warn:
```
$ gcc -c udisksenumtypes.i
udisksenumtypes.i: In function ‘udisks_get_type’:
udisksenumtypes.i:5:3: warning: argument 2 of ‘__atomic_load’ discards
‘volatile’ qualifier [-Wincompatible-pointer-types]
5 |   __atomic_load(in, , 5);
  |   ^
```

It does the right thing with explicit -Werror=:
```
$ gcc -c udisksenumtypes.i -Werror=incompatible-pointer-types
udisksenumtypes.i: In function ‘udisks_get_type’:
udisksenumtypes.i:5:3: error: argument 2 of ‘__atomic_load’ discards ‘volatile’
qualifier [-Werror=incompatible-pointer-types]
5 |   __atomic_load(in, , 5);
  |   ^
cc1: some warnings being treated as errors
```

udisksenumtypes.i:
```
volatile long out;
volatile long* in;

void udisks_get_type() {
  __atomic_load(in, , 5);
}
```

[Bug tree-optimization/113049] Compiles to strlen even with -fno-builtin-strlen -fno-optimize-strlen

[mikpelinux at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Mikael Pettersson  ---
Does -fno-tree-loop-distribute-patterns work? That's been the go-to for
disabling similar loop-to-call transformations people have been objecting to.

[Bug tree-optimization/113049] Compiles to strlen even with -fno-builtin-strlen -fno-optimize-strlen

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

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

--- Comment #1 from Georg-Johann Lay  ---
-fno-builtin works, but that seems too much. -fno-builtin-strlen should switch
it off IMO.

[Bug tree-optimization/113049] New: Compiles to strlen even with -fno-builtin-strlen -fno-optimize-strlen

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

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

Bug ID: 113049
   Summary: Compiles to strlen even with -fno-builtin-strlen
-fno-optimize-strlen
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gjl at gcc dot gnu.org
  Target Milestone: ---

Compile with -S -Os -fno-builtin-strlen -fno-optimize-strlen

typedef __SIZE_TYPE__ size_t;

size_t strlen (const char *text)
{
  size_t len = 0;

  while (*text)
  {
text++;
len++;
  }
  return len;

}

Generated code:

strlen:
b   strlen


Using built-in specs.
COLLECT_GCC=/opt/compiler-explorer/arm/gcc-12.2.0/arm-unknown-linux-gnueabihf/bin/arm-unknown-linux-gnueabihf-gcc
Target: arm-unknown-linux-gnueabihf
Configured with: /opt/.build/arm-unknown-linux-gnueabihf/src/gcc/configure
--build=x86_64-build_pc-linux-gnu --host=x86_64-build_pc-linux-gnu
--target=arm-unknown-linux-gnueabihf
--prefix=/opt/compiler-explorer/arm/gcc-12.2.0/arm-unknown-linux-gnueabihf
--exec_prefix=/opt/compiler-explorer/arm/gcc-12.2.0/arm-unknown-linux-gnueabihf
--with-sysroot=/opt/compiler-explorer/arm/gcc-12.2.0/arm-unknown-linux-gnueabihf/arm-unknown-linux-gnueabihf/sysroot
--enable-languages=c,c++,fortran,d,objc,obj-c++,go --with-arch=armv7-a
--with-fpu=neon --with-float=hard --enable-__cxa_atexit --disable-libmudflap
--enable-libgomp --enable-libssp --enable-libquadmath
--enable-libquadmath-support --enable-libsanitizer --disable-libmpx
--with-gmp=/opt/.build/arm-unknown-linux-gnueabihf/buildtools
--with-mpfr=/opt/.build/arm-unknown-linux-gnueabihf/buildtools
--with-mpc=/opt/.build/arm-unknown-linux-gnueabihf/buildtools
--with-isl=/opt/.build/arm-unknown-linux-gnueabihf/buildtools --enable-lto
--enable-threads=posix --enable-target-optspace --disable-plugin --disable-nls
--enable-tls --disable-multilib
--with-local-prefix=/opt/compiler-explorer/arm/gcc-12.2.0/arm-unknown-linux-gnueabihf/arm-unknown-linux-gnueabihf/sysroot
--enable-long-long --with-mode=thumb
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (GCC) 

https://godbolt.org/z/En3j6Gvda

Maybe this is same / similar to PR102725.