[Bug driver/102755] Built gcc cross compiler always tries to use "as" instead of cross assembler

[dr.duncan.p.simpson at gmx dot com via Gcc-bugs]

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

Duncan Simpson  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |WORKSFORME

--- Comment #5 from Duncan Simpson  ---
The find_a_program logic does seem to fix most versions of this issue. It might
be insufficient if default tool is "foo" but finding it requires path searching
which access(2) does not do. Attempying to build gcc with that problem dies
with a sane message quickly, so I don't think that is a major problem.

The version I was testing had a version of gcc,c which completely ignored
DEFUALT_ASEEMBLER and the built in specs lead to the assumption that running a
program called "as" with execvp(2) was the correct thing to do. The build did
use the compiler passed using --with-as.

[Bug c++/102642] [11/12 Regression] ICE in get, at cgraph.h:2776 since r12-4032-g701075864ac4d1c6

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |minor

[Bug c++/99141] Name of deduced type unchecked in deduction guide

[liarokapis.v at gmail dot com via Gcc-bugs]

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

Alexandros Liarokapis  changed:

   What|Removed |Added

 CC||liarokapis.v at gmail dot com

--- Comment #3 from Alexandros Liarokapis  ---
This also affects namespaced-identifiers:

```C++
namespace foo {
template 
struct bar { template  bar(X); };

template 
bar(X) -> foo::bar;
}
```

The above shouldn't compile since the trailing return entity must be a
`simple-template-id`. Passes on every version of GCC so far.

[Bug ada/100486] Ada build fails for 32bit Windows

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

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

--- Comment #54 from Eric Botcazou  ---
> "this" means the problem with C++ exceptions, which indeed is fixed by
> building gcc after reverting to grep 3.0.
> 
> The build failure with Ada, which predated the grep upgrade, persists.
> 
> Eric: I'm sorry for the time you wasted on this wild goose chase.

No problem, I already wasted more time in other circumstances...

So we're back to square one with the Ada-specific problem.  At this point a
backtrace would really be needed because our environments are quite different.

According to the initial report, the problem occurs during stage #2 compiling
ada/libgnat/a-except.adb, so one would need to go into the gcc/ subdirectory of
the build tree and replay the command line:

/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/xgcc
-B/C/_/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/
-B/mingw32/i686-w64-mingw32/bin/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib
-isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include
-B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem
/mingw32/i686-w64-mingw32/include -isystem
/mingw32/i686-w64-mingw32/sys-include   -fno-checking -c -g -O2
-D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -fno-checking -gtoggle  -gnatpg 
-W -Wall -g -O1 -fno-inline \
2021-05-08T11:34:54.9009139Z  -nostdinc -I- -I. -Iada/generated -Iada
-Iada/gcc-interface -I../../gcc-11.1.0/gcc/ada
-I../../gcc-11.1.0/gcc/ada/gcc-interface -Iada/libgnat
-I../../gcc-11.1.0/gcc/ada/libgnat
../../gcc-11.1.0/gcc/ada/libgnat/a-except.adb -o ada/libgnat/a-except.o

after appending -wrapper gdb,--args to it.  This should launch an interactive
GDB session for gcc/gnat1 with the above command line.  Then 'catch exception'
and 'run' might reveal what happens.

[Bug c++/102801] New: Incorrect -Wmaybe-uninitialized warning/interation for a std::optional only when a nested struct is also present.

[calin.culianu at bitcoincashnode dot org via Gcc-bugs]

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

Bug ID: 102801
   Summary: Incorrect -Wmaybe-uninitialized warning/interation for
a std::optional only when a nested struct is also
present.
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: calin.culianu at bitcoincashnode dot org
  Target Milestone: ---

Created attachment 51617
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51617&action=edit
Test case where a spurious/incorrect -Wmaybe-uninitialized warning is generated

Hi -- I noticed a regression in GCC 10 and GCC 11 related to `std::optional`. 
The attached file, if compiled with `-O2 -Wall -std=c++17 -c` as options, will
warn incorrectly about uninitialized members on both GCC 10 and GCC 11 (I
haven't tried 9 yet but I think 8 & 9 are ok).

Note that the key element in the below code is the nested `struct Shared`. If
that is omitted, no warnings occur.

Attached code warns erroneously (GCC 10 & 11):

g++ -O2 -Wall -std=c++17 -c warn3.cpp


Attached code does not warn (nested struct omitted):

g++ -DNO_WARN -O2 -Wall -std=c++17 -c warn3.cpp

[Bug tree-optimization/102798] [9/10/11/12 Regression] wrong code with -O3 -fno-tree-pta by r9-2475

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

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

--- Comment #9 from H.J. Lu  ---
Created attachment 51618
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51618&action=edit
A patch

[Bug ada/100486] Ada build fails for 32bit Windows

[gcc_bugzilla at axeitado dot com via Gcc-bugs]

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

--- Comment #55 from Óscar Fuentes  ---
Here we go (this is a debug build):

$
/d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/xgcc
-B/d/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/./prev-gcc/
-B/mingw32/i686-w64-mingw32/bin/ -L/mingw32/i686-w64-mingw32/lib -L/mingw32/lib
-isystem /mingw32/i686-w64-mingw32/include -isystem /mingw32/include
-B/mingw32/i686-w64-mingw32/bin/ -B/mingw32/i686-w64-mingw32/lib/ -isystem
/mingw32/i686-w64-mingw32/include -isystem
/mingw32/i686-w64-mingw32/sys-include   -fno-checking -c -g -O2
-D__USE_MINGW_ACCESS -Wno-pedantic-ms-format -fno-checking -gtoggle  -gnatpg 
-W -Wall -g -O1 -fno-inline  -nostdinc -I- -I. -Iada/generated -Iada
-Iada/gcc-interface -I../../gcc-11.2.0/gcc/ada
-I../../gcc-11.2.0/gcc/ada/gcc-interface -Iada/libgnat
-I../../gcc-11.2.0/gcc/ada/libgnat
../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb -o ada/libgnat/a-except.o
-wrapper gdb,--args
GNU gdb (GDB) 10.2
Copyright (C) 2021 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
Type "show copying" and "show warranty" for details.
This GDB was configured as "i686-w64-mingw32".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.

For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from
D:/dev/other/MINGW-packages/mingw-w64-gcc/src/build-i686-w64-mingw32/prev-gcc/gnat1.exe...
Breakpoint 1 at 0x1b9b938: file ../../gcc-11.2.0/gcc/diagnostic.c, line 1884.
Breakpoint 2 at 0x1b9b79f: file ../../gcc-11.2.0/gcc/diagnostic.c, line 1804.
Breakpoint 3 at 0x1e3b618
Breakpoint 4 at 0x1e3b5e8
File tree.h will be skipped when stepping.
File is-a.h will be skipped when stepping.
File line-map.h will be skipped when stepping.
File timevar.h will be skipped when stepping.
Function rtx_expr_list::next will be skipped when stepping.
Function rtx_expr_list::element will be skipped when stepping.
Function rtx_insn_list::next will be skipped when stepping.
Function rtx_insn_list::insn will be skipped when stepping.
Function rtx_sequence::len will be skipped when stepping.
Function rtx_sequence::element will be skipped when stepping.
Function rtx_sequence::insn will be skipped when stepping.
Function INSN_UID will be skipped when stepping.
Function PREV_INSN will be skipped when stepping.
Function SET_PREV_INSN will be skipped when stepping.
Function NEXT_INSN will be skipped when stepping.
Function SET_NEXT_INSN will be skipped when stepping.
Function BLOCK_FOR_INSN will be skipped when stepping.
Function PATTERN will be skipped when stepping.
Function INSN_LOCATION will be skipped when stepping.
Function INSN_HAS_LOCATION will be skipped when stepping.
Function JUMP_LABEL_AS_INSN will be skipped when stepping.
Successfully loaded GDB hooks for GCC
(gdb) catch exception
Catchpoint 5: all Ada exceptions
(gdb) run
Starting program:
D:\dev\other\MINGW-packages\mingw-w64-gcc\src\build-i686-w64-mingw32\prev-gcc\gnat1.exe
-I - -I . -I ada/generated -I ada -I ada/gcc-interface -I
../../gcc-11.2.0/gcc/ada -I ../../gcc-11.2.0/gcc/ada/gcc-interface -I
ada/libgnat -I ../../gcc-11.2.0/gcc/ada/libgnat -gnatwa -quiet -nostdinc -O2
-O1 -Wno-pedantic-ms-format -Wextra -Wall -dumpdir ada/libgnat/ -dumpbase
a-except.adb -dumpbase-ext .adb -g -fno-checking -gtoggle -gnatpg -g
-fno-inline "-mtune=generic" "-march=i686" -gnatO ada/libgnat/a-except.o
../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb -o C:\apps\msys64\tmp\ccyhgK0H.s
[New Thread 4320.0x1d80]
[New Thread 4320.0x1d04]
[New Thread 4320.0x2010]
gnat1.exe: warning: command-line option '-Wno-pedantic-ms-format' is valid for
C/C++/ObjC/ObjC++ but not for Ada

Catchpoint 5, SEM_PRAG.ANALYZE_PRAGMA.PRAGMA_EXIT (sem_prag.adb:6605) at
0x007e816c in sem_prag.analyze_pragma.check_valid_library_unit_pragma ()
at ../../gcc-11.2.0/gcc/ada/sem_prag.adb:6605
6605  raise Pragma_Exit;
(gdb) bt
#0  <__gnat_debug_raise_exception> (
e=0x207a990 , message=...)
at ../../gcc-11.2.0/gcc/ada/libgnat/s-excdeb.adb:40
#1  0x0048e862 in ada.exceptions.complete_occurrence (x=x@entry=0x132d8ac0)
at ../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb:912
#2  0x0048e878 in ada.exceptions.complete_and_propagate_occurrence (
x=x@entry=0x132d8ac0) at ../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb:923
#3  0x0048e8b3 in <__gnat_raise_exception> (
e=0x207a990 , message=...)
at ../../gcc-11.2.0/gcc/ada/libgnat/a-except.adb:960
#4  0x007e816c in sem_prag.analyze_pragma.check_valid_library_unit_pragma ()
at ../../gcc-11.2.0/gcc/ada/sem_prag.adb:6605
#5  0x007deae

[Bug c++/102802] New: Selection of inherited operator contrary to `using` clause in C++

[fchelnokov at gmail dot com via Gcc-bugs]

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

Bug ID: 102802
   Summary: Selection of inherited operator contrary to `using`
clause in C++
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fchelnokov at gmail dot com
  Target Milestone: ---

This program is invalid:
```
using A = decltype([](int){ return 1; });
using B = decltype([](){ return 2; });

struct S : A, B {
using A::operator();
};

int main() {
S s;
static_assert( s() == 2 ); // erroneously passes in GCC and Clang
}
```
It must be rejected because A::operator(int) takes 1 argument and B::operator()
shall not be considered. Only MSVC correctly rejects it now:
https://gcc.godbolt.org/z/x6x3aWzoq

Related discussion: https://stackoverflow.com/q/69601650/7325599

[Bug driver/102803] New: Bug: -no-canonical-prefixes not working

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

Bug ID: 102803
   Summary: Bug: -no-canonical-prefixes not working
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carlosgalvezp at gmail dot com
  Target Milestone: ---

Hi,

GCC has the option "-no-canonical-prefixes" to avoid calling "realpath" on
default include search paths. This is needed when one wants to use GCC in
Bazel:

https://github.com/bazelbuild/bazel/issues/4605#issuecomment-364174051

Now, GCC as downloaded from here:

http://ppa.launchpad.net/ubuntu-toolchain-r/test/ubuntu/pool/main/g/gcc-11/g++-11_11.1.0-1ubuntu1~18.04.1_amd64.deb

does *not* honor the -no-canonical-prefixes flag.

If one unpacks the above .deb file into e.g. /path/to/gcc, and runs gcc from
there like ./usr/bin/gcc-11 with the -no-canonical-prefixes option, then the
default search paths resolve all symlinks and "../", leading to a realpath:

/path/to/gcc# ./usr/bin/gcc-11 -no-canonical-prefixes
-fno-canonical-system-headers -xc++ -E -v -

ignoring nonexistent directory
"./usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../include/x86_64-linux-gnu/c++/11/x86_64-linux-gnu"
ignoring nonexistent directory
"./usr/bin/../lib/gcc/x86_64-linux-gnu/11/include"
ignoring nonexistent directory
"./usr/bin/../lib/gcc/x86_64-linux-gnu/11/include-fixed"
ignoring nonexistent directory
"./usr/bin/../lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include"
ignoring duplicate directory "/path/to/gcc/usr/include/c++/11"
ignoring duplicate directory "/path/to/gcc/usr/include/x86_64-linux-gnu/c++/11"
ignoring duplicate directory "/path/to/gcc/usr/include/x86_64-linux-gnu/c++/11"
ignoring duplicate directory "/path/to/gcc/usr/include/c++/11/backward"
ignoring nonexistent directory
"./usr/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11/include"
ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu"
ignoring nonexistent directory
"./usr/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11/include-fixed"
ignoring nonexistent directory
"./usr/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/11/../../../../x86_64-linux-gnu/include"
ignoring nonexistent directory "/usr/include/x86_64-linux-gnu"
#include "..." search starts here:
#include <...> search starts here:
 /path/to/gcc/usr/include/c++/11
 /path/to/gcc/usr/include/x86_64-linux-gnu/c++/11
 /path/to/gcc/usr/include/c++/11/backward
 /usr/local/include
 /usr/include

I.e. the default search paths are:

 /path/to/gcc/usr/include/c++/11
 /path/to/gcc/usr/include/x86_64-linux-gnu/c++/11
 /path/to/gcc/usr/include/c++/11/backward

Instead of:

./usr/bin/../include/c++/11

This happens also on GCC 7.

Why is this happening? Can it be solved? This prevents GCC from being used in
Bazel in a sandboxed way (i.e. without having GCC installed in the system).

[Bug c++/102801] Incorrect -Wmaybe-uninitialized warning/interaction for a std::optional only when a nested struct is also present.

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

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

--- Comment #1 from Jonathan Wakely  ---
7, 8, 9 and 10 all warn:

mozilla_jwakely0/warn3.cpp: In function 'void foo(Q&, std::vector&)':
mozilla_jwakely0/warn3.cpp:8:7: warning: '.C::b' may be used
uninitialized in this function [-Wmaybe-uninitialized]
8 | class C {
  |   ^

11 and trunk warn about that and also:

/home/jwakely/gcc/12/include/c++/12.0.0/bits/shared_ptr_base.h:709:19: warning:
'((const std::__shared_count<__gnu_cxx::_S_atomic>*)((char*)& +
offsetof(C2, C2::c.std::optional::.std::_Optional_base::_M_payload.std::_Optional_payload::.std::_Optional_payload::.std::_Optional_payload_base::_M_payload)))[2].std::__shared_count<>::_M_pi'
may be used uninitialized [-Wmaybe-uninitialized]
  709 |   : _M_pi(__r._M_pi)
  |   ^

[Bug tree-optimization/102798] [9/10/11/12 Regression] wrong code with -O3 -fno-tree-pta by r9-2475

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

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

H.J. Lu  changed:

   What|Removed |Added

  Attachment #51618|0   |1
is obsolete||

--- Comment #10 from H.J. Lu  ---
Created attachment 51619
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51619&action=edit
An updated patch

[Bug fortran/102716] ICE in gfc_validate_kind(): Got bad kind

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

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

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

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

commit r11-9159-gd97dbf60dda22e0668dc33ca3a536adcb0963a65
Author: Harald Anlauf 
Date:   Thu Oct 14 20:18:14 2021 +0200

Fortran: fix order of checks for the SHAPE intrinsic

gcc/fortran/ChangeLog:

PR fortran/102716
* check.c (gfc_check_shape): Reorder checks so that invalid KIND
arguments can be detected.

gcc/testsuite/ChangeLog:

PR fortran/102716
* gfortran.dg/shape_10.f90: New test.

(cherry picked from commit 1b115daf62d94337b3d0b2962b0bbbf005a450e0)

[Bug driver/102803] Bug: -no-canonical-prefixes not working

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

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

--- Comment #1 from Andrew Pinski  ---
Sounds like Bazel is broken 

[Bug c++/102802] Selection of inherited operator contrary to `using` clause in C++ when using lambda type

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-10-17
Summary|Selection of inherited  |Selection of inherited
   |operator contrary to|operator contrary to
   |`using` clause in C++   |`using` clause in C++ when
   ||using lambda type

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

[Bug c++/102802] Selection of inherited operator contrary to `using` clause in C++ when using lambda type

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

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

--- Comment #2 from Andrew Pinski  ---
ICC also rejects it.

[Bug c++/102799] decltype with lambda without body error cause ICE

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Dup of bug 99505.

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

[Bug c++/99505] ICE Segmentation fault when decltype lambda in parameter list

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||nickhuang99 at hotmail dot com

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

[Bug c++/102594] ICE in decay_conversion, at cp/typeck.c:2311 since r8-7514-ge278212eeea4f57d

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

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

--- Comment #2 from Andrew Pinski  ---
Clang, MSVC and ICC all accept this code.

[Bug fortran/102787] ICE in new test case gfortran.dg/reshape_shape_2.f90

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

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

--- Comment #5 from anlauf at gcc dot gnu.org ---
Looks like an issue with simplification of array within array constructor:

  print *, -   a
  print *, -  [a]
  print *, - [[a]]
end

-fdump-fortran-original produces:

  code:
  WRITE UNIT=6 FMT=-1
  TRANSFER (/ -2 /)
  DT_END
  WRITE UNIT=6 FMT=-1
  TRANSFER (/ (/ -2 /) /)
  DT_END
  WRITE UNIT=6 FMT=-1
  TRANSFER (/ -2 /)
  DT_END

-fdump-tree-original confirms this.

[Bug c++/102629] [10/11/12 Regression] ICE: tree check in lookup_base, at cp/search.c:233 since r10-2194-g10acaf4db9f8b54b

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE: tree check: expected   |[10/11/12 Regression] ICE:
   |record_type or union_type   |tree check in lookup_base,
   |or qual_union_type, have|at cp/search.c:233 since
   |decltype_type in|r10-2194-g10acaf4db9f8b54b
   |lookup_base, at |
   |cp/search.c:233 since   |
   |r10-2194-g10acaf4db9f8b54b  |
   Target Milestone|--- |10.4

[Bug bootstrap/102665] ELF-specific configure flags should be rejected on non-ELF platforms

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

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

Eric Gallager  changed:

   What|Removed |Added

 CC||iains at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
(this is something discussion with Iain Sandoe prompted me to file, btw, so I'm
cc-ing him on this)

[Bug target/102602] 32bit mips: Error: branch out of range

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|[10/11/12 Regression] 32bit |32bit mips: Error: branch
   |mips: Error: branch out of  |out of range
   |range   |
   Target Milestone|10.4|---

--- Comment #2 from Andrew Pinski  ---
> /tmp/ccecXwRM.s:4908: Error: branch out of range

The function is huge so I really doubt that this is a regression either.

[Bug target/102602] 32bit mips: Error: branch out of range

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

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

--- Comment #3 from Andrew Pinski  ---
Most likley exposed by r10-9646 which introduced more inlining or rather fixing
an inlining issue which was broken in the GCC 10 series.
This most likely was broken in GCC 9 too.

The function is really just huge.  I really doubt there is much to be done.

[Bug c++/102801] Incorrect -Wmaybe-uninitialized warning/interaction for a std::optional only when a nested struct is also present.

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

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

Eric Gallager  changed:

   What|Removed |Added

 Blocks||24639
   Keywords||diagnostic
 CC||egallager at gcc dot gnu.org

--- Comment #2 from Eric Gallager  ---
Is this related to and/or a dup of bug 80635?


Referenced Bugs:

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

[Bug middle-end/102580] Failure to optimize signed division to unsigned division when dividend can't be negative

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-10-17

--- Comment #2 from Andrew Pinski  ---
Confirmed, It might be easy to do in the middle-end as we have a range.

[Bug middle-end/102580] Failure to optimize signed division to unsigned division when dividend can't be negative

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

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

--- Comment #3 from Andrew Pinski  ---
We can do it for:
int f(int x) {
  if (x < 0) 
__builtin_abort();
  x+=1;
  return x/3;
}

expand_expr_divmod has the code already to handle this, just needs a range. 
Expand would do querry to get better ranges really.

[Bug middle-end/102580] Failure to optimize signed division to unsigned division when dividend can't be negative

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

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

--- Comment #4 from Andrew Pinski  ---
For an example GCC does optimize the following too:
int f(int x) {
  if (x < 0) 
__builtin_unreachable();
  return x/3;
}

[Bug c++/102801] Incorrect -Wmaybe-uninitialized warning/interaction for a std::optional only when a nested struct is also present.

[calin.culianu at bitcoincashnode dot org via Gcc-bugs]

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

--- Comment #3 from Calin Culianu  ---
@Eric Gallager : Initially I came across that bug and it looked eerily similar
to this one. I am not a gcc dev, just a user of gcc. No idea.. but yeah looks
like in some situations certainly gcc has trouble with this uninitialized
warning when std::optional enters the picture...

[Bug c++/102804] New: template matching fails w/ false ambiguity on ternary expressions with enums

[rudick at gmail dot com via Gcc-bugs]

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

Bug ID: 102804
   Summary: template matching fails w/ false ambiguity on ternary
expressions with enums
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rudick at gmail dot com
  Target Milestone: ---

E.g. w/ -std=c++11

#include 
int main() {
  enum: unsigned int32_t { FOO, BAR } foobar = FOO;
  std::cout << ((time(nullptr) % 2) ? foobar : 13) << std::endl;
}

The initial error is:

error: ambiguous overload for ‘operator<<’ (operand types are ‘std::ostream’
{aka ‘std::basic_ostream’} and ‘unsigned int’)

in gcc9.2 & gcc 11.2.0

gcc7 happily compiles the code.

with -Wextra, all 3 versions warn:

error: enumerated and non-enumerated type in conditional expression

Version: 11.2.0

system: CentOS Linux 7.7.1908 on Intel Xeon

command: g++ -Wall -Wextra -std=c++11 20211017-bug.cpp

[Bug driver/102803] Bug: -no-canonical-prefixes not working

[carlosgalvezp at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Carlos Galvez  ---
Did you read my detailed explanation and reproducible example? I took great
care and time to make the problem easy to investigate. GCC is not doing what is
supposed to do. Other compilers, like Clang, do actually apply the flag
-no-canonical-prefixes.

Putting the blame on Bazel doesn't sound like a good way to solve the problem.

[Bug c++/102804] template matching fails w/ false ambiguity on ternary expressions with enums class defined with unsigned int32_t

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|template matching fails w/  |template matching fails w/
   |false ambiguity on ternary  |false ambiguity on ternary
   |expressions with enums  |expressions with enums
   ||class defined with unsigned
   ||int32_t

--- Comment #1 from Andrew Pinski  ---
Hmm:
:4:9: error: 'unsigned' specified with 'int32_t' {aka 'int'}
[-Wpedantic]
4 |   enum: unsigned int32_t { FOO, BAR } foobar = FOO;
  | ^~~~


Looks like this is the cause of the problem, Changing it to unsigned or
uint32_t and the error goes away ...

[Bug tree-optimization/98950] jump threading memory leak

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org
 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #6 from Jeffrey A. Law  ---
Aldy's work on the jump threaders seems to have fixed this on the trunk.  I
don't think it's really worth the effort to chase down the precise commit as it
likely wouldn't be back-portable anyway.

[Bug d/102618] d-demangle: anonymous symbols are not being properly skipped

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Jeff Law :

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

commit r12-4462-gfb5b0778586674c31f69d866038a5b5bd9a151ee
Author: Luís Ferreira 
Date:   Sun Oct 17 18:34:25 2021 -0400

[PATCH] d-demangle: properly skip anonymous symbols

libiberty/
PR d/102618
* d-demangle.c (dlang_parse_qualified): Handle anonymous
symbols correctly.

* testsuite/d-demangle-expected: New tests to cover anonymous
symbols.

[Bug c++/102805] New: at -O2, spurious stringop-overflow warning writing to std::vector::back()

[rudick at gmail dot com via Gcc-bugs]

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

Bug ID: 102805
   Summary: at -O2, spurious stringop-overflow warning writing to
std::vector::back()
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rudick at gmail dot com
  Target Milestone: ---

g++ -O2 -Wextra -Wall -Werror -Wextra vectorBackWrite.cpp

#include 
#include 
#include 

extern FILE* f;
void triggerBug(uint64_t start, uint64_t end) {
  if (f && end > start) {
std::vector data(end - start + 1);
auto res = fread(&data[0], end-start, 1, f);
if (res == 1) {
  data.back() = 0;
}
  }
}

error is:

vectorBackWrite.cpp: In function ‘void triggerBug(uint64_t, uint64_t)’:
vectorBackWrite.cpp:11:19: error: writing 1 byte into a region of size 0
[-Werror=stringop-overflow=]
   11 |   data.back() = 0;
  |   ^~~
In file included from
/opt/gcc-11.2.0/include/c++/11.2.0/x86_64-linux-gnu/bits/c++allocator.h:33,
 from /opt/gcc-11.2.0/include/c++/11.2.0/bits/allocator.h:46,
 from /opt/gcc-11.2.0/include/c++/11.2.0/vector:64,
 from vectorBackWrite.cpp:1:
/opt/gcc-11.2.0/include/c++/11.2.0/ext/new_allocator.h:127:48: note: at offset
[0, 9223372036854775806] into destination object of size [2,
9223372036854775807] allocated by ‘operator new’
  127 | return static_cast<_Tp*>(::operator new(__n * sizeof(_Tp)));
  |  ~~^~~
cc1plus: all warnings being treated as errors


Interestingly, this also fails w/ the same error:
*(data.rbegin()) = 0;

but this is accepted:
data[data.size()-1] = 0;

code works in gcc7 & gcc9 on the same platform, & works on gcc11 with -O1
It also seems to require the fread to be present

Version: 11.2.0

system: CentOS Linux 7.7.1908 on Intel Xeon

[Bug tree-optimization/102805] at -O2, spurious stringop-overflow warning writing to std::vector::back()

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

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

--- Comment #1 from Andrew Pinski  ---
Hmm:
   [local count: 751619281]:
  if (end_8(D) > start_9(D))
goto ; [33.00%]
  else
goto ; [67.00%]

   [local count: 248034361]:
  _2 = end_8(D) - start_9(D);
  _3 = _2 + 1;
  data ={v} {CLOBBER};
  _23 = (signed long) _3;
  if (_23 < 0)
goto ; [0.04%]
  else
goto ; [99.96%]

   [local count: 99214]:
  std::__throw_length_error ("cannot create std::vector larger than
max_size()");

   [local count: 247935148]:
  MEM[(struct _Vector_impl_data *)&data] ={v} {CLOBBER};
  MEM[(struct _Vector_impl_data *)&data]._M_start = 0B;
  MEM[(struct _Vector_impl_data *)&data]._M_finish = 0B;
  MEM[(struct _Vector_impl_data *)&data]._M_end_of_storage = 0B;
  if (_3 != 0)
goto ; [71.00%]
  else
goto ; [29.00%]

   [local count: 71901193]:
  MEM[(struct _Vector_base *)&data]._M_impl.D.49479._M_start = 0B;
  MEM[(struct _Vector_base *)&data]._M_impl.D.49479._M_finish = 0B;
  MEM[(struct _Vector_base *)&data]._M_impl.D.49479._M_end_of_storage = 0B;
  goto ; [100.00%]

   [local count: 158430559]:
  _33 = operator new (_3);
  MEM[(struct _Vector_base *)&data]._M_impl.D.49479._M_start = _33;
  MEM[(struct _Vector_base *)&data]._M_impl.D.49479._M_finish = _33;
  _28 = _33 + _3;
  MEM[(struct _Vector_base *)&data]._M_impl.D.49479._M_end_of_storage = _28;
  *_33 = 0;
  __first_35 = _33 + 1;
  _41 = (long int) _2;
  __builtin_memset (__first_35, 0, _2);


if end is UINT64_MAX and start is 0, then _2 would be UINT64_MAX and _3 would
be 0. And _23 < 0 would be false and then _3!=0 would be false..

So I think the warning is correct, just you don't have an wrapping check
defined in the code for (end - start + 1) ...

[Bug tree-optimization/102805] at -O2, spurious stringop-overflow warning writing to std::vector::back()

[rudick at gmail dot com via Gcc-bugs]

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

--- Comment #2 from rudick at gmail dot com ---
Interesting.

if (f && end > start && start < 100 && end < 100) {

& I still get the warning though

[Bug tree-optimization/102805] at -O2, spurious stringop-overflow warning writing to std::vector::back()

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-10-17
 Ever confirmed|0   |1
   Keywords||missed-optimization

--- Comment #3 from Andrew Pinski  ---
(In reply to rudick from comment #2)
> Interesting.
> 
> if (f && end > start && start < 100 && end < 100) {
> 
> & I still get the warning though

There is a missed VRP for that case:
Testcase for the above case:
void f1(uint64_t start, uint64_t end)
{
  if (end > start && start < 100 && end < 100)
{
uint64_t t = end - start + 1;
if (t != 0)
  __builtin_abort();
}
}

[Bug c++/102804] template matching fails w/ false ambiguity on ternary expressions with enums class defined with unsigned typdef

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

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

--- Comment #2 from Jonathan Wakely  ---
unsigned int32_t is invalid. You cannot use unsigned (or short or long) with a
typedef, only with 'int'.

GCC was changed to diagnose that fairly recently, which is probably why the
behaviour changed since GCC 7.

[Bug c++/102804] template matching fails w/ false ambiguity on ternary expressions with enums class defined with unsigned typdef

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

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

--- Comment #3 from Jonathan Wakely  ---
I think it was pr 84701

[Bug libstdc++/100427] canadian compile for mingw-w64 copies the wrong dlls for mingw-w64 multilibs

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #7 from cqwrteur  ---
This is incorrect when we canadian build multilib. unfortunately.

I find this is an issue for not just libstdc++, but libaotmic, libssp etc too.
This script is clearly just not right. It should only copy DLLs from lib not
from lib32. and copy DLLs of 32bit to /lib32

  yes,cygwin* | yes,mingw* | yes,pw32* | yes,cegcc*)
library_names_spec='$libname.dll.a'
# DLL is installed to $(libdir)/../bin by postinstall_cmds
postinstall_cmds='base_file=`basename \${file}`~
  dlpath=`$SHELL 2>&1 -c '\''. $dir/'\''\${base_file}'\''i; echo
\$dlname'\''`~
  dldir=$destdir/`dirname \$dlpath`~
  test -d \$dldir || mkdir -p \$dldir~
  $install_prog $dir/$dlname \$dldir/$dlname~
  chmod a+x \$dldir/$dlname~
  if test -n '\''$stripme'\'' && test -n '\''$striplib'\''; then
eval '\''$striplib \$dldir/$dlname'\'' || exit \$?;
  fi'
postuninstall_cmds='dldll=`$SHELL 2>&1 -c '\''. $file; echo \$dlname'\''`~
  dlpath=$dir/\$dldll~
   $RM \$dlpath'
shlibpath_overrides_runpath=yes

[Bug target/102806] New: [x86] Suboptimal codegen for v4hi vector concat under -mavx512bw and -mavx512vl

[wwwhhhyyy333 at gmail dot com via Gcc-bugs]

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

Bug ID: 102806
   Summary: [x86] Suboptimal codegen for v4hi vector concat under
-mavx512bw and -mavx512vl
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wwwhhhyyy333 at gmail dot com
  Target Milestone: ---

For

typedef short v8hi __attribute__((vector_size (16)));
typedef short v4hi __attribute__((vector_size (8))); 

v8hi foov (v4hi a, v4hi b)   
{   
 return __builtin_shufflevector (a, b, 0, 1, 2, 3, 4, 5, 6, 7);
}

gcc -O2 -mavx512vl -mavx512bw:

vmovq   %xmm0, %xmm2
vmovq   %xmm1, %xmm1
vmovdqa .LC0(%rip), %xmm0
vpermi2w%xmm1, %xmm2, %xmm0
ret

While clang with same option:

vmovlhps%xmm1, %xmm0, %xmm0 # xmm0 =
xmm0[0],xmm1[0]
retq

It looks like expand order of permutation should be adjusted

[Bug tree-optimization/102806] [x86] Suboptimal codegen for v4hi vector concat under -mavx512bw and -mavx512vl

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-10-18
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Severity|normal  |enhancement
  Component|target  |tree-optimization

--- Comment #1 from Andrew Pinski  ---
It is because we don't optimize:

  _1 = {a_3(D), { 0, 0, 0, 0 }};
  _2 = {b_4(D), { 0, 0, 0, 0 }};
  _5 = VEC_PERM_EXPR <_1, _2, { 0, 1, 2, 3, 8, 9, 10, 11 }>;

To just
_5 = {a_3(D), b_4(D)};

[Bug middle-end/102781] -ftrivial-auto-var-init might not clear paddings for long double/_Complex long double variables that have explicit initializer

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

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

Richard Biener  changed:

   What|Removed |Added

   Last reconfirmed||2021-10-18
 Target||x86_64-*-* i?86-*-*
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Confirmed.

[Bug target/102783] [powerpc] FPSCR manipulations cannot be relied upon

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

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

--- Comment #5 from Richard Biener  ---
Even out-of-line does not help if there are visible CSE/association
opportunities across such call.  A workaround is to make the out-of-line
function __attribute__((returns_twice)) which should insert artificial control
flow
preventing such transforms.

[Bug tree-optimization/102788] [12 Regression] Wrong code with -O3

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
I will have a look.

[Bug libgomp/102789] [12 regression] libgomp.c++/simd-3.C fails after r12-4340 for 32 bits

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug tree-optimization/102793] AArch64: sequential comparisons with equal conditional blocks don't use ccmp

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||aarch64

--- Comment #3 from Richard Biener  ---
I wonder why tail-merging doesn't do it's job here.  It does (on x86_64-linux):

find_duplicates:  duplicate of 
Removing basic block 5
;; basic block 5, loop depth 0
;;  pred:
_12 = foo_10(D) ();
;;  succ:   6

and .optimized:


int noccmp (uint64_t * s1, uint64_t * s2, int (*) (void) foo)
{
  uint64_t bar;
  uint64_t d2;
  uint64_t d1;
  long unsigned int _1;
  int _2;
  int _14;

   [local count: 1073741824]:
  d1_6 = *s1_4(D);
  d2_8 = *s2_7(D);
  _1 = d1_6 ^ d2_8;
  bar_9 = _1 & 43981;
  if (bar_9 == 0)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 719407024]:
  _14 = foo_10(D) (); [tail call]
  goto ; [100.00%]

   [local count: 708669601]:
  if (d1_6 != d2_8)
goto ; [50.00%]
  else
goto ; [50.00%]

   [local count: 1073741824]:
  # _2 = PHI <_14(3), 0(4)>
  return _2;

}

but what's missing is possibly some if-combine?

IMHO ccmp expansion should be re-written to a pre RTL expansion GIMPLE
transform.

[Bug tree-optimization/102798] [9/10/11/12 Regression] wrong code with -O3 -fno-tree-pta by r9-2475

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

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug target/102767] [12 Regression] ICE in rs6000_builtin_vectorization_cost, at config/rs6000/rs6000.c:5216

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

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

--- Comment #7 from Kewen Lin  ---
(In reply to Segher Boessenkool from comment #6)
> (In reply to Richard Earnshaw from comment #5)
> > We have the type 
> >  > type  > size 
> > unit-size 
> > and movmisalign pattern is enabled for this.
> > 
> > but the vectorization cost doesn't handle the case of elements=1, which is
> > the case when mode is TImode.
> > 
> > So I think this is an inconsistency in the rs6000 backend - either add
> > costing support for single elements or disable the movmisalign code in this
> > case.
> 
> But TImode is a scalar type, not a vector type, so it should hit one of the
> early-outs at the top of rs6000_builtin_vectorization_cost?

for rs6000, the scalar type is uint128_t, the vectorized type is vector(1)
uint128_t

 
unit-size 
align:128 warn_if_not_align:0 symtab:0 alias-set 13 canonical-type
0x751b0bd0 precision:128 min  max >
unsigned V1TI size  unit-size 
align:128 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x751b5dd8 nunits:1>

We have the movmisalign support for V1TI

#define HAVE_movmisalignv4si (VECTOR_MEM_VSX_P (V4SImode) &&
TARGET_ALLOW_MOVMISALIGN)
#define HAVE_movmisalignv4sf (VECTOR_MEM_VSX_P (V4SFmode) &&
TARGET_ALLOW_MOVMISALIGN)
#define HAVE_movmisalignv2di (VECTOR_MEM_VSX_P (V2DImode) &&
TARGET_ALLOW_MOVMISALIGN)
#define HAVE_movmisalignv2df (VECTOR_MEM_VSX_P (V2DFmode) &&
TARGET_ALLOW_MOVMISALIGN)
#define HAVE_movmisalignv1ti (VECTOR_MEM_VSX_P (V1TImode) &&
TARGET_ALLOW_MOVMISALIGN)

The misalign in the failure is 8, it makes the hook
rs6000_builtin_support_vector_misalignment return true. The loop vectorization
fails to vectorize for V1TI due to the resulted vectorization factor is 1. But
for this failure it's BB slp, it looks allowable to query the cost with V1TI. I
think Richard E. is right, it's a rs6000 specific issue.

[Bug tree-optimization/102793] AArch64: sequential comparisons with equal conditional blocks don't use ccmp

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Richard Biener from comment #3)
> I wonder why tail-merging doesn't do it's job here.  It does (on
> x86_64-linux):

Oh I missed that.

> but what's missing is possibly some if-combine?

Yes because ifcombine happens way way too early. I wonder if we should not have
another one or move the currently one to be after the loop optimizations are
done.

> IMHO ccmp expansion should be re-written to a pre RTL expansion GIMPLE
> transform.

basically ccmp expension is just ifcombine really.
That is:
cc = bar cmp 0
cc = cc.eq ? ne : d1 cmp d2
cset cc.ne
So this is why doing a late pass ifcombine might be good for aarch64; I don't
know if how much compile time it would cost though.

[Bug driver/102803] Bug: -no-canonical-prefixes not working

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |11.2.0
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2021-10-18

--- Comment #3 from Richard Biener  ---
I get

~/install/gcc-11> ./usr/local/bin/gcc /tmp/t.c -no-canonical-prefixes
-fno-canonical-system-headers -xc++ -E -v -
Using built-in specs.
COLLECT_GCC=./usr/local/bin/gcc
Target: x86_64-pc-linux-gnu
Configured with: /home/rguenther/src/gcc-11-branch/configure
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.2.1 20210729 (GCC) 
COLLECT_GCC_OPTIONS='-fno-canonical-system-headers' '-E' '-v' '-mtune=generic'
'-march=x86-64'
 ./usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.1/cc1 -E -quiet -v
-iprefix ./usr/local/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/ /tmp/t.c
-mtune=generic -march=x86-64 -fno-canonical-system-headers -dumpbase t.c
-dumpbase-ext .c
ignoring nonexistent directory
"./usr/local/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory
"./usr/local/bin/../lib64/gcc/../../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/include"
ignoring duplicate directory
"./usr/local/bin/../lib64/gcc/../../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/include-fixed"
ignoring nonexistent directory
"./usr/local/bin/../lib64/gcc/../../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 ./usr/local/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/include
 ./usr/local/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/include-fixed
 /usr/local/include
 /usr/include
End of search list.
# 0 "/tmp/t.c"
# 0 ""
# 0 ""
# 1 "/usr/include/stdc-predef.h" 1 3 4
# 0 "" 2
# 1 "/tmp/t.c"
int main(){}
COLLECT_GCC_OPTIONS='-fno-canonical-system-headers' '-E' '-v' '-mtune=generic'
'-march=x86-64'
 ./usr/local/bin/../lib/gcc/x86_64-pc-linux-gnu/11.2.1/cc1plus -E -quiet -v
-iprefix ./usr/local/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/ -D_GNU_SOURCE
- -mtune=generic -march=x86-64 -fno-canonical-system-headers -dumpbase -
ignoring nonexistent directory
"./usr/local/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../x86_64-pc-linux-gnu/include"
ignoring duplicate directory
"./usr/local/bin/../lib64/gcc/../../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../include/c++/11.2.1"
ignoring duplicate directory
"./usr/local/bin/../lib64/gcc/../../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../include/c++/11.2.1/x86_64-pc-linux-gnu"
ignoring duplicate directory
"./usr/local/bin/../lib64/gcc/../../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../include/c++/11.2.1/backward"
ignoring duplicate directory
"./usr/local/bin/../lib64/gcc/../../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/include"
ignoring duplicate directory
"./usr/local/bin/../lib64/gcc/../../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/include-fixed"
ignoring nonexistent directory
"./usr/local/bin/../lib64/gcc/../../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:

./usr/local/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../include/c++/11.2.1

./usr/local/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../include/c++/11.2.1/x86_64-pc-linux-gnu

./usr/local/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/../../../../include/c++/11.2.1/backward
 ./usr/local/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/include
 ./usr/local/bin/../lib64/gcc/x86_64-pc-linux-gnu/11.2.1/include-fixed
 /usr/local/include
 /usr/include
End of search list.

which is nearly OK(?), there are hard-coded /usr/local/include and
/usr/include,
not sure why.

The behavior possibly depends on the configuration, mine is just all defaults.

Even the standard openSUSE packages work the same, with the exception of
/usr/local/include and /usr/include again:

/usr/bin> ./gcc-10 -no-canonical-prefixes -fno-canonical-system-headers -xc++
-E -v -
Using built-in specs.
COLLECT_GCC=./gcc-10
OFFLOAD_TARGET_NAMES=nvptx-none
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,d
--enable-offload-targets=nvptx-none, --without-cuda-driver
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/10 --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --disable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstd

[Bug c++/102804] template matching fails w/ false ambiguity on ternary expressions with enums class defined with unsigned typdef

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #4 from Richard Biener  ---
Thus invalid.

[Bug tree-optimization/102806] [x86] Suboptimal codegen for v4hi vector concat under -mavx512bw and -mavx512vl

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

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

--- Comment #2 from Richard Biener  ---
Yes, on the GIMPLE / Frontend level __builtin_shufflevector is implemented
mostly on the functional level and I don't remember doing any additional
specific optimizations (though it worked surprisingly well without those).

[Bug libstdc++/102807] New: Simple code using ranges::views::keys does not compile with clang

[zeratul976 at hotmail dot com via Gcc-bugs]

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

Bug ID: 102807
   Summary: Simple code using ranges::views::keys does not compile
with clang
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zeratul976 at hotmail dot com
  Target Milestone: ---

Created attachment 51620
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51620&action=edit
Output of `clang++ -c -std=c++20 -ftemplate-backtrace-limit=0 `

The following simple code using ranges::views::keys compiles with gcc 11.1, but
not with clang (tested with clang trunk, and libstdc++ from 11.1).


#include 
#include 

int main()
{
std::unordered_map m;
m | std::ranges::views::keys;
}


I've attached the complete error output. I'm not sure if this is a bug in clang
or libstdc++, but I thought I'd start here.