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

--- 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 *)] ={v} {CLOBBER};
  MEM[(struct _Vector_impl_data *)]._M_start = 0B;
  MEM[(struct _Vector_impl_data *)]._M_finish = 0B;
  MEM[(struct _Vector_impl_data *)]._M_end_of_storage = 0B;
  if (_3 != 0)
goto ; [71.00%]
  else
goto ; [29.00%]

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

   [local count: 158430559]:
  _33 = operator new (_3);
  MEM[(struct _Vector_base *)]._M_impl.D.49479._M_start = _33;
  MEM[(struct _Vector_base *)]._M_impl.D.49479._M_finish = _33;
  _28 = _33 + _3;
  MEM[(struct _Vector_base *)]._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 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([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 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 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 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 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] 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 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 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 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

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 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 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 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 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 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 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++/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 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++/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++/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++/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 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 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 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=edit
An updated patch

[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 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++/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 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  

[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=edit
A patch

[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=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 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++/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 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 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 rtl-optimization/102800] Incorrect UB warning with aggressive-loop-optimizations

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
  end_10 = begin_9(D) + _3;
  if (begin_9(D) != end_10)
goto ; [INV]
  else
goto ; [INV]
;;succ:   3 (TRUE_VALUE,EXECUTABLE)
;;5 (FALSE_VALUE,EXECUTABLE)

;;   basic block 3, loop depth 0, maybe hot
;;prev block 2, next block 4, flags: (NEW, VISITED)
;;pred:   2 (TRUE_VALUE,EXECUTABLE)
  # RANGE [0, 7] NONZERO 7
  _15 = (signed long) _3;

;;   basic block 4, loop depth 1, maybe hot
;;prev block 3, next block 5, flags: (NEW, VISITED)
;;pred:   3 (FALLTHRU,EXECUTABLE)
;;4 (TRUE_VALUE,EXECUTABLE)
  # RANGE [-9223372036854775808, 7]
  # x_6 = PHI <_15(3), x_14(4)>
  # .MEM_7 = PHI <.MEM_11(D)(3), .MEM_13(4)>
  _4 = (charD.7) x_6;
  # RANGE [-128, 127]
  _5 = (intD.6) _4;
  # .MEM_13 = VDEF <.MEM_7>
  # USE = nonlocal escaped 
  # CLB = nonlocal escaped 
  barD.1978 (_5);
  # RANGE [-9223372036854775808, 6]
  x_14 = x_6 + -1;
  if (x_14 != 0)
goto ; [INV]
  else
goto ; [INV]
;;succ:   4 (TRUE_VALUE,EXECUTABLE)
;;5 (FALSE_VALUE,EXECUTABLE)

this is from evrp.  Oh We miss that _15 cannot be 1.

even though later on we can detect it.

SO simple testcase:
void bar(char x);
void link_error(void);
void foo(char * begin)
{
// end = ALIGN(begin, 8);
__SIZE_TYPE__ t = 7 - unsigned long)begin) - 1) % 8);
char * end = begin + t;

if (begin != end) {
if (!t) link_error();
long long x = end - begin;
do bar(x);
while(--x != 0);
}
}

The call to should really be removed in evrp.

So forwprop1 does not change the first begin!=end to t!=0 but changes
end-begin.  to (long long)t. And then forwprop2 changes begin!=end to t!=0 and
vrp1 can then figure out the range of x inside the loop is [1,7].