[Bug libstdc++/98389] New: [11 regression] libstdc++-abi/abi_check fails after r11-6249 on powerpc64 big endian

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

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

Bug ID: 98389
   Summary: [11 regression] libstdc++-abi/abi_check fails after
r11-6249 on powerpc64 big endian
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:3c57e692357c79ee7623dfc1586652aee2aefb8f, r11-6249: 89 failures

FAIL: libstdc++-abi/abi_check

This only fails on BE.


The output from this is extensive and I am not positive that these are what
cause the failures but they sound like possible failures:


2 undesignated symbols
0
_ZSt11__once_call
std::__once_call
version status: compatible
GLIBCXX_3.4.11
type: tls
type size: 8
status: undesignated

1
_ZSt15__once_callable
std::__once_callable
version status: compatible
GLIBCXX_3.4.11
type: tls
type size: 8
status: undesignated


3 incompatible symbols
0
_ZSt8to_charsPcS_g
std::to_chars(char*, char*, __float128)
version status: incompatible
GLIBCXX_3.4.29
type: function
status: added


1
_ZSt8to_charsPcS_gSt12chars_format
std::to_chars(char*, char*, __float128, std::chars_format)
version status: incompatible
GLIBCXX_3.4.29
type: function
status: added


2
_ZSt8to_charsPcS_gSt12chars_formati
std::to_chars(char*, char*, __float128, std::chars_format, int)
version status: incompatible
GLIBCXX_3.4.29
type: function
status: added


 libstdc++-v3 check-abi Summary 

# of added symbols:  109
# of missing symbols:0
# of undesignated symbols:   2
# of incompatible symbols:   3

using: baseline_symbols.txt
FAIL: libstdc++-abi/abi_check

[Bug target/98387] GCC >= 6 cannot inline _mm_cmp_ps on SSE targets

[danielhanchen at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Daniel Han-Chen  ---
Oh I just noticed _mm_cmp_ps isn't actually supported for SSE targets even in
Intel's Intrinsics Guide: [_mm_cmp_ps first was supported in AVX]

https://software.intel.com/sites/landingpage/IntrinsicsGuide/#expand=5236,827,33,5224,447,456,4085,3864,5224,4179,4118,4115,4115,4121,3864,3870,5579,2030,3319,2809,4127,5156,4179,4201,3536,3539,3533,2184,3505,3533,3542,3505,3533,1606,4174,2809,5576,5578,2063,3895,3893,2484,3864,4076,3864,687,689,689,3544,771,1648,1647,5878,5903,743&techs=SSE,SSE2,SSE3,SSSE3,SSE4_1,SSE4_2&text=cmpps



error: inlining failed in call to always_inline '__m128 _mm_cmp_ps(__m128,
__m128, int)': target specific option mismatch
  390 | _mm_cmp_ps (__m128 __X, __m128 __Y, const int __P)


_mm_cmp[*]_ps ie _mm_cmpeq_ps and derivatives successfully inline.

[Bug c++/98388] New: Throwing move-only parameter results in hard error in SFINAE context

[ensadc at mailnesia dot com via Gcc-bugs]

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

Bug ID: 98388
   Summary: Throwing move-only parameter results in hard error in
SFINAE context
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ensadc at mailnesia dot com
  Target Milestone: ---

https://godbolt.org/z/xn8fYz


struct moveonly {
moveonly() = default;
moveonly(moveonly&&) = default;
};

template
constexpr auto is_throwable(T t) -> decltype(throw t, true) {
return true;
}
template
constexpr bool is_throwable(...) { return false; }

constexpr bool b = is_throwable(moveonly{});


: In substitution of 'template constexpr decltype
((, true)) is_throwable(T) [with T = moveonly]':
:13:43:   required from here
:7:46: error: use of deleted function 'constexpr
moveonly::moveonly(const moveonly&)'
7 | constexpr auto is_throwable(T t) -> decltype(throw t, true) {
  |  ^~~
:1:8: note: 'constexpr moveonly::moveonly(const moveonly&)' is
implicitly declared as deleted because 'moveonly' declares a move constructor
or move assignment operator
1 | struct moveonly {
  |^~~~
:7:52: note:   in thrown expression
7 | constexpr auto is_throwable(T t) -> decltype(throw t, true) {
  |^


I'm not sure what the value of `b` should be, but I believe that it should not
be a hard error. (Clang and MSVC initialize `b` to `true`.)

[Bug c++/98387] New: GCC >= 6 cannot inline _mm_cmp_ps on SSE targets

[danielhanchen at gmail dot com via Gcc-bugs]

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

Bug ID: 98387
   Summary: GCC >= 6 cannot inline _mm_cmp_ps on SSE targets
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danielhanchen at gmail dot com
  Target Milestone: ---

https://gcc.godbolt.org/z/493ead

GCC since version 6.1 cannot inline _mm_cmp_ps on targets supporting only SSE
(Nehalem, Tremont etc). From >= SandyBridge, everything inlines fine.

_mm_cmp_ps is called by using it as a function argument (ie auto function).

All SSE only machines use a jmp to _mm_cmp_ps, but it should be inlined.

O3 ffast-math is also used, and the function is declared inline.

[Bug c++/98386] C++20 module: file exists failure and success happen alternatively for windows.

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #2 from cqwrteur  ---
My build of GCC for Windows can be found here.

https://github.com/expnkx/mingw-gcc

[Bug c++/98386] C++20 module: file exists failure and success happen alternatively for windows.

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
Created attachment 49805
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49805&action=edit
bugged image

[Bug c++/98386] New: C++20 module: file exists failure and success happen alternatively for windows.

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 98386
   Summary: C++20 module: file exists failure and success happen
alternatively for windows.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

D:\Desktop\module>g++ -c main.cc -Ofast -std=c++20 -s -flto -fmodules-ts
-march=native

D:\Desktop\module>g++ -c hello.cc -Ofast -std=c++20 -s -flto -fmodules-ts
-march=native
hello.cc:4:8: error: failed to write compiled module: File exists
4 | export module hello;
  |^~
hello.cc:4:8: note: compiled module file is 'gcm.cache/hello.gcm'

D:\Desktop\module>g++ -c hello.cc -Ofast -std=c++20 -s -flto -fmodules-ts
-march=native

D:\Desktop\module>g++ -c hello.cc -Ofast -std=c++20 -s -flto -fmodules-ts
-march=native
hello.cc:4:8: error: failed to write compiled module: File exists
4 | export module hello;
  |^~
hello.cc:4:8: note: compiled module file is 'gcm.cache/hello.gcm'

D:\Desktop\module>g++ -c hello.cc -Ofast -std=c++20 -s -flto -fmodules-ts
-march=native

D:\Desktop\module>g++ -c hello.cc -Ofast -std=c++20 -s -flto -fmodules-ts
-march=native
hello.cc:4:8: error: failed to write compiled module: File exists
4 | export module hello;
  |^~
hello.cc:4:8: note: compiled module file is 'gcm.cache/hello.gcm'


You have a succ-error-succ-error loop. It must be something bugged here.

[Bug c++/98363] C++ 20 module ICE for fast_io library

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #6 from cqwrteur  ---
(In reply to Nathan Sidwell from comment #4)
> FWIW I think it premature to start agressively filing these kinds of
> defects.  We haven't added the module testsuite yet.

Same issue on Windows. Looks like modules have not yet worked very well with
concepts.

[Bug c++/98348] GCC 10.2 AVX512 Mask regression from GCC 9

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Hongtao.liu  ---
Created attachment 49804
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49804&action=edit
This patch can fix this issue

I'm testing the patch.

[Bug bootstrap/96378] ICE: Solaris/SPARCv9 bootstrap stage2 segfault compiling stdc++.h.gch/O2ggnu++0x.gch

[nicholas.h.briggs at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Nick Briggs  ---
Thanks! configuring with  --enable-checking=release  allowed it to compile.

The final configure that I used was:

../gcc-master/configure prefix=/opt/gcc --disable-werror
--enable-checking=release CC="gcc -m64" CXX="g++ -m64"
--build=sparcv9-sun-solaris2.11 --with-gnu-as --with-as=/opt/bin
utils/bin/as --without-gnu-ld --with-ld=/usr/bin/ld
build_alias=sparcv9-sun-solaris2.11 --enable-languages=c

There was one hiccup -- the install step wants to compile:

g++ -m64 -std=c++11  -fno-PIE -c  -DIN_GCC_FRONTEND -g -O2 -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H -I. -I. -I../../gcc-master/gcc
-I../../gcc-master/gcc/. -I../../gcc-master/gcc/../include
-I../../gcc-master/gcc/../libcpp/include -I../../gcc-master/gcc/../libcody
-I/export/home/briggs/gcc-master-objdir/./gmp
-I/export/home/briggs/gcc-master/gmp
-I/export/home/briggs/gcc-master-objdir/./mpfr/src
-I/export/home/briggs/gcc-master/mpfr/src
-I/export/home/briggs/gcc-master/mpc/src 
-I../../gcc-master/gcc/../libdecnumber
-I../../gcc-master/gcc/../libdecnumber/dpd -I../libdecnumber
-I../../gcc-master/gcc/../libbacktrace
-I/export/home/briggs/gcc-master-objdir/./isl/include
-I/export/home/briggs/gcc-master/isl/include  -o cc1-checksum.o -MT
cc1-checksum.o -MMD -MP -MF ./.deps/cc1-checksum.TPo cc1-checksum.c
cc1plus: error: -Werror=format-diag: no option -Wformat-diag


however it appears to be using whatever g++ was already installed, and that g++
(7.3.0) is too old to know "-Wno-error=format-diag".

The answer was to "gmake -i install" which managed to get a new g++ installed,
and then "gmake install" again with the new g++ on the path to get an
error-free install.

Final result is:

$ /opt/gcc/bin/gcc -v
Using built-in specs.
COLLECT_GCC=/opt/gcc/bin/gcc
COLLECT_LTO_WRAPPER=/opt/gcc/libexec/gcc/sparcv9-sun-solaris2.11/11.0.0/lto-wrapper
Target: sparcv9-sun-solaris2.11
Configured with: ../gcc-master/configure prefix=/opt/gcc --disable-werror
--enable-checking=release CC='gcc -m64' CXX='g++ -m64'
--build=sparcv9-sun-solaris2.11 --with-gnu-as --with-as=/opt/binutils/bin/as
--without-gnu-ld --with-ld=/usr/bin/ld build_alias=sparcv9-sun-solaris2.11
--enable-languages=c
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201217 (experimental) (GCC)

[Bug libstdc++/98377] bootstrapping failure on windows for floating_to_chars

[unlvsur at live dot com via Gcc-bugs]

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

cqwrteur  changed:

   What|Removed |Added

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

--- Comment #3 from cqwrteur  ---
(In reply to Patrick Palka from comment #2)
> Yikes, sorry about that.  Hopefully the build is clean for you now.  Thanks
> for the quick report.

fixed confirm.

[Bug libstdc++/98374] No #include on windows. Bootstrapping failure

[unlvsur at live dot com via Gcc-bugs]

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

cqwrteur  changed:

   What|Removed |Added

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

--- Comment #3 from cqwrteur  ---
(In reply to CVS Commits from comment #2)
> The master branch has been updated by Patrick Palka :
> 
> https://gcc.gnu.org/g:d7bab388b818fc21dbb9111311e114ae33e11fff
> 
> commit r11-6259-gd7bab388b818fc21dbb9111311e114ae33e11fff
> Author: Patrick Palka 
> Date:   Fri Dec 18 11:52:17 2020 -0500
> 
> libstdc++: Fix build failure due to missing  [PR98374]
> 
> This should fix a build failure on Windows which lacks ,
> from which we use nl_langinfo() to obtain the radix character of the
> current locale.  (We can't use the more portable localeconv() from
>  to obtain the radix character of the current locale here
> because it's not thread-safe, unfortunately.)
> 
> This change means that on Windows and other such platforms, we'll just
> always assume the radix character used by printf is '.' when formatting
> a long double through it.
> 
> libstdc++-v3/ChangeLog:
> 
> PR libstdc++/98374
> * src/c++17/floating_to_chars.cc: Guard include of 
> with __has_include.
> (__floating_to_chars_precision) [!defined(RADIXCHAR)]: Don't
> attempt to obtain the radix character of the current locale,
> just assume it's '.'.

Fixed

[Bug c++/98362] bad file data on Windows for C++ 20 module

[unlvsur at live dot com via Gcc-bugs]

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

cqwrteur  changed:

   What|Removed |Added

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

--- Comment #7 from cqwrteur  ---
(In reply to Nathan Sidwell from comment #6)
> * 785b49434d2 2020-12-18 | c++: Fix windows binary files [PR 98362]

Works on Windows Confirm. Thank you!

[Bug c++/98360] sizeof in template difference between g++/icc and clang++

[ensadc at mailnesia dot com via Gcc-bugs]

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

--- Comment #2 from ensadc at mailnesia dot com ---
Apparently clang++ rewrites `uintset::values` in question to
`this->uintset::values`, because it believes that `uintset::values` is valid
only if someone specializes `uintset::traits` to make it inherit from
`uintset`, but clang++ seems to fail at realizing that `uintset::values`
appears in an unevaluated operand.

[Bug libstdc++/98376] this_thread::sleep_for(short duration) can sleep forever on Linux

[paul.groke at dynatrace dot com via Gcc-bugs]

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

--- Comment #2 from Paul Groke  ---
I was able to reproduce the problem with the following program (see below). It
won't reproduce well on a loaded machine and you may have to fiddle with the
spin counts to get a successful repro.

I know this is a Linux bug, but since a lot of people are using Linux it might
be worth implementing a workaround in libstdc++.

Output from my machine:

Remaining: 0.02000 - signal count: 0
Remaining: 0.312026100 - signal count: 6322
Remaining: 0.610834500 - signal count: 12729
Remaining: 0.907113100 - signal count: 19096
Remaining: 1.202000100 - signal count: 25452
Remaining: 1.499204500 - signal count: 31842
Remaining: 1.799767600 - signal count: 38277
Remaining: 2.095204700 - signal count: 44636
(...snip...)
Remaining: 86.829101800 - signal count: 1865855
Remaining: 87.126722500 - signal count: 1872251
Remaining: 87.427912300 - signal count: 1878704
Remaining: 87.730148000 - signal count: 1885171
Remaining: 88.029529500 - signal count: 1891599
Remaining: 88.329424200 - signal count: 1898039
Remaining: 88.629499900 - signal count: 1904482
Remaining: 88.926003300 - signal count: 1910861
ERROR: timeout. sleep thread seems hung.

---

#include 
#include 
#include 
#include 
#include 
#include 
#include 

using namespace std::chrono_literals;

constexpr auto acq = std::memory_order_acquire;
constexpr auto rlx = std::memory_order_relaxed;

constexpr uint64_t sigHandlerSpin = 10'000;
constexpr uint64_t sigSenderSpin = 100;
constexpr int64_t sleepTimeNs = 20'000'000; // 20ms
constexpr int64_t reportIntervalNs = 200'000'000; // 200ms
constexpr auto timeout = 60s;

thread_local bool tls_isSleepThread{false};
std::atomic s_signalCount{0};
std::atomic s_signalPending{false};

struct timespec makeTs(time_t sec, int64_t nsec) {
struct timespec ts = {};
ts.tv_sec = sec;
ts.tv_nsec = nsec;
return ts;
}

void spinWait(uint64_t spinCount) {
[[maybe_unused]] volatile int32_t dummy = 0;
volatile int32_t divisor = 123456789;
volatile int32_t dividend = 33;
for (uint64_t i = 0; i < spinCount; i++)
dummy = divisor / dividend;
}

void signalHandler(int) {
if (tls_isSleepThread) {
s_signalCount++;
spinWait(sigHandlerSpin);
}
s_signalPending = false;
};

void spinBarrier(std::atomic& barrier) {
barrier--;
while (barrier.load(acq)) {
// wait...
}
}

struct State {
std::atomic startBarrier{3};
std::atomic stop{false};
std::atomic reportGen{0};
std::atomic reportSec{0};
std::atomic reportNsec{0};
};

[[maybe_unused]] void nanosleepThreadFn(State& state) {
tls_isSleepThread = true;
auto sleepTime = makeTs(0, sleepTimeNs);
state.reportSec.store(sleepTime.tv_sec, rlx);
state.reportNsec.store(sleepTime.tv_nsec, rlx);

spinBarrier(state.startBarrier);

while (!state.stop) {
if (::nanosleep(&sleepTime, &sleepTime) != -1)
break;
if (errno != EINTR)
break;

auto gen = state.reportGen.load(acq);
state.reportSec.store(sleepTime.tv_sec, rlx);
state.reportNsec.store(sleepTime.tv_nsec, rlx);
state.reportGen.store(gen + 1);
}

state.stop = true;
}

[[maybe_unused]] void stdSleepThreadFn(State& state) {
tls_isSleepThread = true;
auto sleepTime = 1ns * sleepTimeNs;

spinBarrier(state.startBarrier);
std::this_thread::sleep_for(sleepTime);

state.stop = true;
}

void reportThreadFn(State& state) {
auto const delay = makeTs(0, reportIntervalNs);

spinBarrier(state.startBarrier);
while (!state.stop) {
// try to get consistent snapshot...
int64_t sec;
int64_t nsec;
for (size_t i = 0; i < 10; i++) {
auto const gen = state.reportGen.load(acq);
spinWait(10);
sec = state.reportSec.load(rlx);
nsec = state.reportNsec.load(rlx);
spinWait(10);
auto const gen2 = state.reportGen.load(acq);
if (gen2 == gen)
break;
}

std::cout << "Remaining: " << sec << "."
  << std::setfill('0') << std::setw(9) << nsec
  << " - signal count: " << s_signalCount
  << std::endl;
nanosleep(&delay, nullptr);
}
}

int runTest() {
s_signalCount = 0;
s_signalPending = false;

// install SIGURG handler...
struct sigaction oldSigUrgAction = {};
struct sigaction sigUrgAction = {};
sigUrgAction.sa_handler = signalHandler;
sigaction(SIGURG, &sigUrgAction, &oldSigUrgAction);

auto* const state = new State{};

std::thread sleepThread{[state] { nanosleepThreadFn(*state); }};
std::thread reportThread{[state] { reportThreadFn(*state); }};

auto const sleepThreadHandle = sleepThread.native_handle();

spinBarrier(state->startBarrier);

using Clock = std::chrono::steady_clock;
auto const t0 = Clock::now();

// Ham

[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57

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

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #22 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562318.html

[Bug c++/98360] sizeof in template difference between g++/icc and clang++

[ensadc at mailnesia dot com via Gcc-bugs]

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

ensadc at mailnesia dot com changed:

   What|Removed |Added

 CC||ensadc at mailnesia dot com

--- Comment #1 from ensadc at mailnesia dot com ---
I think this is reject-valid in clang++.

[expr.prim.id.general]/2 ( http://eel.is/c++draft/expr.prim.id.general#2 ):

> An id-expression that denotes a non-static data member or non-static member 
> function of a class can only be used:
>
> - [...]
> - if that id-expression denotes a non-static data member and it appears in an 
> unevaluated operand.

[Bug libstdc++/98370] libstdc++-v3/src/c++17/floating_to_chars.cc fails to compile unless `int32_t' is `int'

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

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

--- Comment #7 from Hans-Peter Nilsson  ---
(In reply to Jonathan Wakely from comment #6)
> (In reply to Hans-Peter Nilsson from comment #4)
> > JFTR, likely all "32-bit targets".
> 
> Not x86, that uses int for int32_t.

So on closer inspection, all ILP32 newlib targets, by largest group.

(That is, plus assorted others that happen to set INT32_TYPE to "long int" by
other means than through newlib-stdint.h.)

Might be good to know the next time this happens.

[Bug middle-end/98373] [11 Repression] Bogus error: ‘symbuf’ may be used uninitialized at -O0 by r11-959

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

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Yes, but you still haven't explained why you think it's invalid.

The warning is by design as documented in the manual

Wmaybe-uninitialized
...
In addition, passing a pointer (or in C++, a reference) to an uninitialized
object to a const-qualified function argument is also diagnosed by this
warning. (-Wuninitialized is issued for built-in functions known to read the
object.) Annotating the function with attribute access (none) indicates that
the argument isn’t used to access the object and avoids the warning (see Common
Function Attributes).

[Bug middle-end/98373] [11 Repression] Bogus error: ‘symbuf’ may be used uninitialized at -O0 by r11-959

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

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

H.J. Lu  changed:

   What|Removed |Added

Summary|[11 Repression] Bogus   |[11 Repression] Bogus
   |error: ‘symbuf’ may be used |error: ‘symbuf’ may be used
   |uninitialized at -O0|uninitialized at -O0 by
   ||r11-959

--- Comment #3 from H.J. Lu  ---
It is caused by r11-959.

[Bug c++/98306] invalid use of incomplete type 'struct grammar'

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

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

--- Comment #2 from Sergei Trofimovich  ---
That makes sense. If it's a valid C++ I'm fine with closing the bug as
RESOLVED/INVALID.

[Bug testsuite/98385] new test case g++.dg/gomp/declare-target-3.C in r11-6257 has many fails

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

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from seurer at gcc dot gnu.org ---
Looks like as of r11-6265 this has been fixed.

[Bug testsuite/98385] New: new test case g++.dg/gomp/declare-target-3.C in r11-6257 has many fails

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

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

Bug ID: 98385
   Summary: new test case g++.dg/gomp/declare-target-3.C in
r11-6257 has many fails
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:3af02d32cce2ff1ff11d078cf8094305f57ca179, r11-6257
make  -k check-gcc RUNTESTFLAGS="gomp.exp=g++.dg/gomp/declare-target-3.C"
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++98  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+b
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++98  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+c
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++98  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+d
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++98  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+e
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++98  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+f
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++98  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+g
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++14  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+b
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++14  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+c
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++14  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+d
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++14  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+e
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++14  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+f
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++14  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+g
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+b
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+c
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+d
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+e
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+f
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+g
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++2a  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+b
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++2a  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+c
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++2a  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+d
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++2a  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+e
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++2a  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+f
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++2a  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+g
# of expected passes24
# of unexpected failures24


spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/gomp/declare-target-3.C
-fdiagnostics-plain-output -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-std=c++17 -fopenmp -fdump-tree-gimple -ffat-lto-objects -fno-ident -S -o
declare-target-3.s
PASS: g++.dg/gomp/declare-target-3.C  -std=c++17 (test for excess errors)
PASS: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-tree-dump-not gimple
"__attribute__\\(\\(omp declare target\\)\\)\\\nint foo \\(\\)"
PASS: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-tree-dump gimple
"__attribute__\\(\\(omp declare target\\)\\)\\\nint bar \\(\\)"
PASS: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-tree-dump gimple
"__attribute__\\(\\(omp declare target\\)\\)\\\nint baz \\(\\)"
PASS: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-tree-dump gimple
"__attribute__\\(\\(omp declare target\\)\\)\\\nint qux \\(\\)"
PASS: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-assembler-not
\\.offload_var_table:\\n.+\\.quad\\s+a
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+b
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+c
FAIL: g++.dg/gomp/declare-target-3.C  -std=c++17  scan-assembler
\\.offload_var_table:\\n.+\\.quad\\s+d
FAIL: g++.dg/gomp/declare-targ

[Bug bootstrap/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc

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

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

--- Comment #8 from Thomas Koenig  ---
(In reply to Andreas Tobler from comment #7)
> Any news on this? Or can we close this PR?

Neither. As far as I can determine, this still fails.

[Bug middle-end/98373] [11 Repression] Bogus error: ‘symbuf’ may be used uninitialized at -O0

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

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

H.J. Lu  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #2 from H.J. Lu  ---
[hjl@gnu-cfl-2 gold]$ cat /tmp/foo.cc 
template
struct Sym_data;

template<>
struct Sym_data<32>
{
  unsigned char st_info;
  unsigned char st_other;
};

template<>
struct Sym_data<64>
{
  unsigned char st_info;
  unsigned char st_other;
};

template
class Sym
{
 public:
  Sym(const unsigned char* p)
: p_(reinterpret_cast*>(p))
  { }

 private:
  const Sym_data* p_;
};

template
class Sized_relobj_incr
{
 private:
  void do_add_symbols();
  Sym *symbols_;
};

template
Sym *
foo(Sym *);

template
void
Sized_relobj_incr::do_add_symbols()
{
  unsigned char symbuf[100];
  Sym sym(symbuf);
  Sym* res = foo(&sym);
  this->symbols_ = res;
}

template
class Sized_relobj_incr<32, false>;
[hjl@gnu-cfl-2 gold]$ /usr/gcc-11.0.0-x32/bin/g++ -Wall -S /tmp/foo.cc
/tmp/foo.cc: In member function ‘void Sized_relobj_incr::do_add_symbols() [with int size = 32; bool big_endian = false]’:
/tmp/foo.cc:47:25: warning: ‘symbuf’ may be used uninitialized
[-Wmaybe-uninitialized]
   47 |   Sym sym(symbuf);
  | ^~~
/tmp/foo.cc:22:3: note: by argument 2 of type ‘const unsigned char*’ to
‘Sym::Sym(const unsigned char*) [with int size = 32; bool
big_endian = false]’ declared here
   22 |   Sym(const unsigned char* p)
  |   ^~~
/tmp/foo.cc:46:17: note: ‘symbuf’ declared here
   46 |   unsigned char symbuf[100];
  | ^~
[hjl@gnu-cfl-2 gold]$

[Bug bootstrap/97304] Boostrap failure on freebsd: ld: error: unable to find library -lc

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

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

--- Comment #7 from Andreas Tobler  ---
Any news on this? Or can we close this PR?
TIA,
Andreas

[Bug libstdc++/98384] New: new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

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

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

Bug ID: 98384
   Summary: new test case 20_util/to_chars/long_double.cc in
r11-6249 fails on powerpc64 BE
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:3c57e692357c79ee7623dfc1586652aee2aefb8f, r11-6249

make  -k check RUNTESTFLAGS="conformance.exp=20_util/to_chars/long_double.cc"
FAIL: 20_util/to_chars/long_double.cc (test for excess errors)
# of unexpected failures1
# of unresolved testcases   1

commit 3c57e692357c79ee7623dfc1586652aee2aefb8f
Author: Patrick Palka 
Date:   Thu Dec 17 23:11:34 2020 -0500

libstdc++: Add floating-point std::to_chars implementation

This new test case is failing on powerpc64 big endian machines.  It works fine
on LE machines.

/home/seurer/gcc/git/build/gcc-test/./gcc/xg++ -shared-libgcc
-B/home/seurer/gcc/git/build/gcc-test/./gcc -nostdinc++
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/bin/
-B/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/lib/
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/include
-isystem
/home/seurer/gcc/git/install/gcc-test/powerpc64-unknown-linux-gnu/sys-include
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-fmessage-length=0 -fno-show-column -ffunction-sections -fdata-sections -g -O2
-D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc
-include bits/stdc++.h -fdiagnostics-plain-output ./libtestc++.a
-Wl,--gc-sections
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/src/filesystem/.libs
-lm -o ./long_double.exe
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:
In function 'void test01()':
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:42:
error: 'nextdownl' was not declared in this scope; did you mean 'nexttowardl'?
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:43:
error: 'nextupl' was not declared in this scope; did you mean 'expl'?
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:
In function 'void test02()':
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:175:
error: 'nextdownl' was not declared in this scope; did you mean 'nexttowardl'?
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:184:
error: 'nextupl' was not declared in this scope; did you mean 'expl'?
compiler exited with status 1
FAIL: 20_util/to_chars/long_double.cc (test for excess errors)
Excess errors:
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:42:
error: 'nextdownl' was not declared in this scope; did you mean 'nexttowardl'?
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:43:
error: 'nextupl' was not declared in this scope; did you mean 'expl'?
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:175:
error: 'nextdownl' was not declared in this scope; did you mean 'nexttowardl'?
/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/20_util/to_chars/long_double.cc:184:
error: 'nextupl' was not declared in this scope; did you mean 'expl'?

[Bug c++/98383] New: internal compiler error: in make_decl_rtl, at varasm.c:1342

[cebtenzzre at gmail dot com via Gcc-bugs]

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

Bug ID: 98383
   Summary: internal compiler error: in make_decl_rtl, at
varasm.c:1342
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cebtenzzre at gmail dot com
  Target Milestone: ---

Created attachment 49803
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49803&action=edit
Preprocessed source that triggers the error

g++ crashes with an internal compiler error while compiling a version of oneDNN
used by ideep. Specifically, ref_shuffle.cpp at commit
7aed236906b1f7a05c0917e5257a1af05e9ff683
(https://github.com/oneapi-src/oneDNN/blob/7aed236906b1f7a05c0917e5257a1af05e9ff683/src/cpu/ref_shuffle.cpp).
I have not attempted to compile the latest version of this file. Preprocessed
source is gzipped and attached as ref_shuffle.ii.gz.

-fopenmp is necessary to reproduce the crash. It occurs with -O1 (but not -O0,
-O2, or -O3), with -fsanitize=address -O1 (same line in the error message), and
with -fsanitize=address and either -O2 or -O3 (different line in the error
message).

Output:
$ g++ -c ref_shuffle.ii -fopenmp -O1
during RTL pass: expand
../third_party/ideep/mkl-dnn/src/cpu/ref_shuffle.cpp: In function
‘_ZNK4dnnl4impl3cpu13ref_shuffle_tILi4EE8execute_IL17dnnl_format_tag_t112EEEvRKNS0_10exec_ctx_tE._omp_fn.0’:
../third_party/ideep/mkl-dnn/src/cpu/ref_shuffle.cpp:69:9: internal compiler
error: in make_decl_rtl, at varasm.c:1342
   69 | #pragma omp parallel for collapse(3) schedule(static)
  | ^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ g++ -c ref_shuffle.ii -fopenmp -fsanitize=address -O2
during RTL pass: expand
../third_party/ideep/mkl-dnn/src/cpu/ref_shuffle.cpp: In function
‘_ZNK4dnnl4impl3cpu13ref_shuffle_tILi4EE8execute_IL17dnnl_format_tag_t112EEEvRKNS0_10exec_ctx_tE._omp_fn.0’:
../third_party/ideep/mkl-dnn/src/cpu/ref_shuffle.cpp:76:56: internal compiler
error: in make_decl_rtl, at varasm.c:1342
   76 | for (int cc = 0; cc < nstl::min(blksize, C - cb); ++cc) {
  |  ~~^~~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC)

[Bug bootstrap/98380] bootstrapping failure on windows 32bits for libcc1

[unlvsur at live dot com via Gcc-bugs]

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

cqwrteur  changed:

   What|Removed |Added

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

--- Comment #7 from cqwrteur  ---
Thank you!

[Bug target/98382] [m68k] ICE: in output_move_qimode, at config/m68k/m68k.c:3284 when building webkit2gtk

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #1 from John Paul Adrian Glaubitz  ---
Created attachment 49802
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49802&action=edit
Preprocessed source.

[Bug target/98382] New: [m68k] ICE: in output_move_qimode, at config/m68k/m68k.c:3284 when building webkit2gtk

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

Bug ID: 98382
   Summary: [m68k] ICE: in output_move_qimode, at
config/m68k/m68k.c:3284 when building webkit2gtk
   Product: gcc
   Version: 10.2.1
   URL: https://buildd.debian.org/status/fetch.php?pkg=webkit2
gtk&arch=m68k&ver=2.30.4-1&stamp=1608068352&raw=0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glaubitz at physik dot fu-berlin.de
CC: jrtc27 at jrtc27 dot com, schwab at gcc dot gnu.org
  Target Milestone: ---
Target: m68k-*-*

Trying to build webkit2gtk on m68k with gcc-10 recently started to fail with:
[1053/4498] /usr/bin/c++ -DBUILDING_GTK__=1 -DBUILDING_JavaScriptCore
-DBUILDING_WITH_CMAKE=1 -DGETTEXT_PACKAGE=\"WebKit2GTK-4.0\" -DHAVE_CONFIG_H=1
-DJSC_COMPILATION -DJSC_GLIB_API_ENABLED -DJavaScriptCore_EXPORTS
-DSTATICALLY_LINKED_WITH_WTF -DSVN_REVISION=\"tarball\"
-DWEBKITGTK_API_VERSION_STRING=\"4.0\" -IDerivedSources/ForwardingHeaders -I.
-I../Source/JavaScriptCore -I../Source/JavaScriptCore/API
-I../Source/JavaScriptCore/assembler -I../Source/JavaScriptCore/b3
-I../Source/JavaScriptCore/b3/air -I../Source/JavaScriptCore/bindings
-I../Source/JavaScriptCore/builtins -I../Source/JavaScriptCore/bytecode
-I../Source/JavaScriptCore/bytecompiler -I../Source/JavaScriptCore/dfg
-I../Source/JavaScriptCore/disassembler
-I../Source/JavaScriptCore/disassembler/ARM64
-I../Source/JavaScriptCore/disassembler/udis86
-I../Source/JavaScriptCore/domjit -I../Source/JavaScriptCore/ftl
-I../Source/JavaScriptCore/heap -I../Source/JavaScriptCore/debugger
-I../Source/JavaScriptCore/inspector
-I../Source/JavaScriptCore/inspector/agents
-I../Source/JavaScriptCore/inspector/augmentable
-I../Source/JavaScriptCore/inspector/remote
-I../Source/JavaScriptCore/interpreter -I../Source/JavaScriptCore/jit
-I../Source/JavaScriptCore/llint -I../Source/JavaScriptCore/parser
-I../Source/JavaScriptCore/profiler -I../Source/JavaScriptCore/runtime
-I../Source/JavaScriptCore/tools -I../Source/JavaScriptCore/wasm
-I../Source/JavaScriptCore/wasm/js -I../Source/JavaScriptCore/yarr
-IDerivedSources/JavaScriptCore -IDerivedSources/JavaScriptCore/inspector
-IDerivedSources/JavaScriptCore/runtime -IDerivedSources/JavaScriptCore/yarr
-IDerivedSources/ForwardingHeaders/JavaScriptCore/glib
-IDerivedSources/JavaScriptCore/javascriptcoregtk/jsc
-I../Source/JavaScriptCore/API/glib
-IDerivedSources/JavaScriptCore/javascriptcoregtk
-I../Source/JavaScriptCore/inspector/remote/glib -isystem /usr/include/glib-2.0
-isystem /usr/lib/m68k-linux-gnu/glib-2.0/include -fdiagnostics-color=always
-Wextra -Wall -Wno-expansion-to-defined -Wno-noexcept-type -Wno-psabi
-Wno-maybe-uninitialized -Wwrite-strings -Wundef -Wpointer-arith
-Wmissing-format-attribute -Wformat-security -Wcast-align -g1 -O2
-fdebug-prefix-map=/<>=. -specs=/usr/share/dpkg/pie-compile.specs
-fstack-protector-strong -Wformat -Werror=format-security -Wdate-time
-D_FORTIFY_SOURCE=2 -DNDEBUG -DG_DISABLE_CAST_CHECKS -fno-strict-aliasing
-fno-exceptions -fno-rtti -fPIC -ffp-contract=off -pthread -std=c++17 -MD -MT
Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/DerivedSources/JavaScriptCore/unified-sources/UnifiedSource-3bec6ef2-1.cpp.o
-MF
Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/DerivedSources/JavaScriptCore/unified-sources/UnifiedSource-3bec6ef2-1.cpp.o.d
-o
Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/DerivedSources/JavaScriptCore/unified-sources/UnifiedSource-3bec6ef2-1.cpp.o
-c DerivedSources/JavaScriptCore/unified-sources/UnifiedSource-3bec6ef2-1.cpp
FAILED:
Source/JavaScriptCore/CMakeFiles/JavaScriptCore.dir/__/__/DerivedSources/JavaScriptCore/unified-sources/UnifiedSource-3bec6ef2-1.cpp.o
 
/usr/bin/c++ -DBUILDING_GTK__=1 -DBUILDING_JavaScriptCore
-DBUILDING_WITH_CMAKE=1 -DGETTEXT_PACKAGE=\"WebKit2GTK-4.0\" -DHAVE_CONFIG_H=1
-DJSC_COMPILATION -DJSC_GLIB_API_ENABLED -DJavaScriptCore_EXPORTS
-DSTATICALLY_LINKED_WITH_WTF -DSVN_REVISION=\"tarball\"
-DWEBKITGTK_API_VERSION_STRING=\"4.0\" -IDerivedSources/ForwardingHeaders -I.
-I../Source/JavaScriptCore -I../Source/JavaScriptCore/API
-I../Source/JavaScriptCore/assembler -I../Source/JavaScriptCore/b3
-I../Source/JavaScriptCore/b3/air -I../Source/JavaScriptCore/bindings
-I../Source/JavaScriptCore/builtins -I../Source/JavaScriptCore/bytecode
-I../Source/JavaScriptCore/bytecompiler -I../Source/JavaScriptCore/dfg
-I../Source/JavaScriptCore/disassembler
-I../Source/JavaScriptCore/disassembler/ARM64
-I../Source/JavaScriptCore/disassembler/udis86
-I../Source/JavaScriptCore/domjit -I../Source/JavaScriptCore/ftl
-I../Source/JavaScriptCore/heap -I../Source/JavaScriptCore/debugger
-I../Source/JavaScriptCore/inspector
-I../Source/JavaScriptCore/inspector/agents
-I../Source/JavaScriptCore/inspector/augmentable
-I../Source/

[Bug bootstrap/98380] bootstrapping failure on windows 32bits for libcc1

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #6 from cqwrteur  ---
Created attachment 49801
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49801&action=edit
stdout logs

[Bug bootstrap/98380] bootstrapping failure on windows 32bits for libcc1

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #5 from cqwrteur  ---
Created attachment 49800
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49800&action=edit
stderr logs

[Bug bootstrap/98380] bootstrapping failure on windows 32bits for libcc1

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #4 from cqwrteur  ---
D:/msys64/mingw32/lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe:
../build-i686-w64-mingw32/libcpp/libcpp.a(lex.o):lex.c:(.text+0x8): undefined
reference to `LC0'
D:/msys64/mingw32/lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe:
../build-i686-w64-mingw32/libcpp/libcpp.a(lex.o):lex.c:(.text+0xf): undefined
reference to `LC1'
D:/msys64/mingw32/lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe:
../build-i686-w64-mingw32/libcpp/libcpp.a(lex.o):lex.c:(.text+0x16): undefined
reference to `LC2'
D:/msys64/mingw32/lib/gcc/i686-w64-mingw32/11.0.0/../../../../i686-w64-mingw32/bin/ld.exe:
../build-i686-w64-mingw32/libcpp/libcpp.a(lex.o):lex.c:(.text+0x47): undefined
reference to `LC3'
collect2.exe: error: ld returned 1 exit status
make[2]: *** [Makefile:2987: build/genmatch.exe] Error 1
make[2]: *** Waiting for unfinished jobs
make[1]: *** [Makefile:4446: all-gcc] Error 2
make[1]: *** Waiting for unfinished jobs
make: *** [Makefile:973: all] Error 2
==> ERROR: A failure occurred in build().
Aborting...

undefined reference

[Bug tree-optimization/98381] New: Wrong code with -O3 -march=skylake-avx512

[vsevolod.livinskij at frtk dot ru via Gcc-bugs]

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

Bug ID: 98381
   Summary: Wrong code with -O3 -march=skylake-avx512
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vsevolod.livinskij at frtk dot ru
  Target Milestone: ---

Reproducer:
//func.cpp
extern bool var_22;
void test(long long a, unsigned b, unsigned long long c) {
  for (long i = 0; i < 16; i += 1ULL)
if (a)
  var_22 = 5023804122334ULL >= (char)c;
}

//driver.cpp 
#include 
long long int a = -2161098602020439353LL;
unsigned int b = 1621447385U;
unsigned long long int c = 16505450185101189749ULL;
bool var_22 = (bool)0;

void test(long long int a, unsigned int b, unsigned long long int c);

int main() {
test(a, b, c);
printf("%d\n", (int)var_22);
}

Error:
>$ g++ -O3 -march=skylake-avx512 func.cpp driver.cpp && sde -skx -- ./a.out
0
>$ g++ -O0 func.cpp driver.cpp && sde -skx -- ./a.out
1

gcc version 11.0.0 20201217 (6f8486523f61bf0aa476dfa4197d1e3b71a0a8f3) (GCC)

[Bug bootstrap/98380] bootstrapping failure on windows 32bits for libcc1

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #3 from cqwrteur  ---
Build again. still fails on 32 bits but succ on 64 bits. do not know why.


checking that generated files are newer than configure... done
configure: creating ./config.status
/bin/sh ../../gcc-git/gcc/../move-if-change tmp-attrtab.cinsn-attrtab.c
/bin/sh ../../gcc-git/gcc/../move-if-change tmp-dfatab.c insn-dfatab.c
/bin/sh ../../gcc-git/gcc/../move-if-change tmp-latencytab.c insn-latencytab.c
echo timestamp > s-attrtab
config.status: creating Makefile
config.status: creating cc1plugin-config.h
config.status: executing depfiles commands
config.status: executing libtool commands
/bin/sh ../../gcc-git/gcc/../move-if-change tmp-automata.c insn-automata.c
echo timestamp > s-automata
rm gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod
gcov.pod lto-dump.pod
make[2]: Leaving directory
'/home/unlvs/mingw-gcc-mcf-gthread/src/build-i686-w64-mingw32/gcc'
make[1]: *** [Makefile:4446: all-gcc] Error 2
make[1]: Leaving directory
'/home/unlvs/mingw-gcc-mcf-gthread/src/build-i686-w64-mingw32'
make: *** [Makefile:973: all] Error 2
==> ERROR: A failure occurred in build().
Aborting...

[Bug libstdc++/98370] libstdc++-v3/src/c++17/floating_to_chars.cc fails to compile unless `int32_t' is `int'

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

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

--- Comment #6 from Jonathan Wakely  ---
(In reply to Hans-Peter Nilsson from comment #4)
> JFTR, likely all "32-bit targets".

Not x86, that uses int for int32_t.

[Bug c++/93480] Defaulted <=> doesn't expand array elements

[wjwray at gmail dot com via Gcc-bugs]

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

Will Wray  changed:

   What|Removed |Added

 CC||wjwray at gmail dot com

--- Comment #1 from Will Wray  ---
I'm keen to see this fixed (and open to contribute)
(defaulted array comparison now works on Clang & MSVC).

Workaround for lack of compiler-generated array<=>array
is awkward and brittle: https://godbolt.org/z/xr668E

 * Preprocessor conditional compilation is required
   (at least there seems no way to detect array<=>array
support and dispatch to a user-defined comparison
only as needed - iff array members are present):

# if ! defined(__GNUC__) || defined(__clang__)
auto operator<=>(C const&) const = default;
# else
constexpr auto operator<=>(C const& r) const {
return three_way_compare(x,r.x);
}
#endif

Then:
 * A generic 3-way comparison for array should be recursive.
 * Achieving efficient/vector codegen is not straightforward.
 * Deducing the return type is subtle:

template 
constexpr auto three_way_compare(E const(&l)[N],
 E const(&r)[N]) {
auto c = l[0] <=> r[0];
for (int i = 0; ++i != N; c = l[i] <=> r[i])
if (c != 0)
return c;
return c;
}

So it'd be better for all if this were compiler-generated.

[Bug bootstrap/98380] bootstrapping failure on windows 32bits for libcc1

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

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

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

https://gcc.gnu.org/g:5dc998933e7aa737f4a45a8a2885d42d5288d51a

commit r11-6263-g5dc998933e7aa737f4a45a8a2885d42d5288d51a
Author: Jakub Jelinek 
Date:   Fri Dec 18 20:25:26 2020 +0100

libcc1: Fix up libcc1 configure [PR98330]

Either we should write test x$darwin_dynamic_lookup = xyes
or we should make sure the variable is always defined to non-empty string.

2020-12-18  Jakub Jelinek  

PR bootstrap/98380
* configure.ac: Set darwin_dynamic_lookup=no instead to empty
string.
* configure: Regenerated.

[Bug c/98378] new valgrind error for ./gcc.c-torture/execute/pr60960.c

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #6 from David Binderman  ---
Testsuite file ./gcc.c-torture/execute/simd-6.c, with flag -O2,
has similar problems with a valgrind version of gcc trunk.

[Bug c/98378] new valgrind error for ./gcc.c-torture/execute/pr60960.c

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

 CC||jakub at redhat dot com

--- Comment #5 from David Binderman  ---
I am struggling to make further progress with this one.

Commit cd676dfa57e643a4f7d8445e6ebad0f21cf3fd84 looks suspicious,
since it is the only one that changes anything in compiler source code
file gimple-ssa-store-merging.c in the good .. bad range.

Jakub, your best advice sought, please.

[Bug libgcc/98380] bootstrapping failure on windows 32bits for libcc1

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
It works for 64 bit windows but failed for 32 bit windows. I do not know why. I
could build this tomorrow but now it failed.

[Bug libgcc/98380] New: bootstrapping failure on windows 32bits for libcc1

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 98380
   Summary: bootstrapping failure on windows 32bits for libcc1
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libgcc
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

/home/unlvs/mingw-gcc-mcf-gthread/src/gcc-git/libcc1/configure: line 14981:
test: =: unary operator expected
checking for socketpair... no
checking for select... no
checking for fork... no
configure: updating cache ./config.cache
checking that generated files are newer than configure... done
configure: creating ./config.status
/bin/sh ../../gcc-git/gcc/../move-if-change tmp-attrtab.cinsn-attrtab.c
/bin/sh ../../gcc-git/gcc/../move-if-change tmp-dfatab.c insn-dfatab.c
/bin/sh ../../gcc-git/gcc/../move-if-change tmp-latencytab.c insn-latencytab.c
echo timestamp > s-attrtab
config.status: creating Makefile
config.status: creating cc1plugin-config.h
config.status: executing depfiles commands
config.status: executing libtool commands
/bin/sh ../../gcc-git/gcc/../move-if-change tmp-automata.c insn-automata.c
echo timestamp > s-automata
rm gfdl.pod gcc.pod gcov-dump.pod gcov-tool.pod fsf-funding.pod gpl.pod cpp.pod
gcov.pod lto-dump.pod
make[2]: Leaving directory
'/home/unlvs/mingw-gcc-mcf-gthread/src/build-i686-w64-mingw32/gcc'
make[1]: *** [Makefile:4446: all-gcc] Error 2
make[1]: Leaving directory
'/home/unlvs/mingw-gcc-mcf-gthread/src/build-i686-w64-mingw32'
make: *** [Makefile:973: all] Error 2
==> ERROR: A failure occurred in build().
Aborting...

[Bug c/98378] new valgrind error for ./gcc.c-torture/execute/pr60960.c

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #4 from David Binderman  ---
Looks bad. Trying 5137d1ae6a1fe4a3

[Bug c++/98368] Seg fault on template method missing required return statement

[kip at thevertigo dot com via Gcc-bugs]

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

--- Comment #5 from Kip Warner  ---
*face palm* Yes, you are right! I totally forgot about the invocation at the
end of the CLI! That's what happens when I don't get enough sleep.

[Bug c/98379] New: Unknown tree: c_maybe_const_expr in a warning

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

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

Bug ID: 98379
   Summary: Unknown tree: c_maybe_const_expr in a warning
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

The output of the warning below is garbled.  The pretty-printer that formats
the type doesn't know how to cope with the representation of the !*a
expression:

$ cat t.c && gcc -O2 -S -Wall t.c
int f (int n, int*, int[n]);
int f (int n, int *a, int[!*a]);
t.c:2:23: warning: argument 3 of type ‘int[(*a) == 0]’ declared with mismatched
bound ‘<<< Unknown tree: c_maybe_const_expr

  *a >>> == 0’ [-Wvla-parameter]
2 | int f (int n, int *a, int[!*a]);
  |   ^~~~
t.c:1:21: note: previously declared as ‘int[n]’ with bound argument 1
1 | int f (int n, int*, int[n]);
  |~^~

[Bug c/98378] new valgrind error for ./gcc.c-torture/execute/pr60960.c

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #3 from David Binderman  ---
Looks bad. Trying 571d3fb1f40fa85c

[Bug c++/98368] Seg fault on template method missing required return statement

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

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

--- Comment #4 from Jakub Jelinek  ---
Why do you think the compiler is crashing?  You are running the compiler and
then the program and the program is what is crashing.

[Bug c++/98368] Seg fault on template method missing required return statement

[kip at thevertigo dot com via Gcc-bugs]

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

--- Comment #3 from Kip Warner  ---
Sorry, the _compiler_ crashing is expected behaviour?

[Bug target/98177] [11 Regression] SVE: ICE in expand_direct_optab_fn, at internal-fn.c:3368

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Przemyslaw Wirkus :

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

commit r11-6262-gd44d47b49267b4265cee16d25b3f89dbf967cc0c
Author: Przemyslaw Wirkus 
Date:   Fri Dec 18 18:18:57 2020 +

aarch64: SVE: ICE in expand_direct_optab_fn [PR98177]

Problem comes from using the wrong interface to get the index type for a
COND_REDUCTION. For fixed-length SVE we get a V2SI (a 64-bit Advanced
SIMD vector) instead of a VNx2SI (an SVE vector that stores SI elements
in DI containers).

Credits to Richard Sandiford for pointing out the issue's root cause.

Original PR snippet proposed to reproduce issue was only causing ICE for
C++
compiler (see pr98177-1 test cases). I've slightly modified original
snippet in order to reproduce issue on both C and C++ compilers. These
are pr98177-2 test cases.

gcc/ChangeLog:

PR target/98177
* tree-vect-loop.c (vect_create_epilog_for_reduction): Use
get_same_sized_vectype to obtain index type.
(vectorizable_reduction): Likewise.

gcc/testsuite/ChangeLog:

PR target/98177
* g++.target/aarch64/sve/pr98177-1.C: New test.
* g++.target/aarch64/sve/pr98177-2.C: New test.
* gcc.target/aarch64/sve/pr98177-1.c: New test.
* gcc.target/aarch64/sve/pr98177-2.c: New test.

[Bug libstdc++/98377] bootstrapping failure on windows for floating_to_chars

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

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

Patrick Palka  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Last reconfirmed||2020-12-18

--- Comment #2 from Patrick Palka  ---
Yikes, sorry about that.  Hopefully the build is clean for you now.  Thanks for
the quick report.

[Bug libstdc++/98377] bootstrapping failure on windows for floating_to_chars

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

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

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

https://gcc.gnu.org/g:60cecb2b83ffcebac6e83076f5552df14b073248

commit r11-6261-g60cecb2b83ffcebac6e83076f5552df14b073248
Author: Patrick Palka 
Date:   Fri Dec 18 13:01:49 2020 -0500

libstdc++: Fix mistake in PR98374 change [PR98377]

The #ifdef RADIXCHAR directive should be moved one line up so that it
also guards the outer if statement, or else when RADIXCHAR is not
defined the outer if statement will end up nonsensically guarding the
declaration of output_length_upper_bound a few lines below it.

libstdc++-v3/ChangeLog:

PR libstdc++/98377
* src/c++17/floating_to_chars.cc (__floating_to_chars_precision):
Fix mistake.

[Bug middle-end/83174] -Wvla-larger-than reports wrong VLA size in some cases

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
  Known to work||11.0
 Resolution|--- |FIXED
 CC||msebor at gcc dot gnu.org
  Component|c   |middle-end
  Known to fail||10.2.0, 7.3.0, 8.3.0, 9.2.0
   Target Milestone|--- |11.0

--- Comment #1 from Martin Sebor  ---
Fixed in GCC 11 with the switch to the new Ranger engine in
g:495ec0b2aa808a6463b8c24288a1730cbae1cfca.

[Bug c/98378] new valgrind error for ./gcc.c-torture/execute/pr60960.c

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #2 from David Binderman  ---
Looks good. Trying 0dd48296433763ba

[Bug ada/98228] [11 Regression] ICE: Assert_Failure atree.adb:931: Error detected at s-gearop.adb:382:34 [a-ngrear.adb:313:7 [a-nllrar.ads:18:1]] on s390x-linux-gnu

[mhillen at linux dot ibm.com via Gcc-bugs]

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

--- Comment #7 from Marius Hillenbrand  ---
-flto alone is enough to cause the miscompile. make bootstrap with this config
fails in stage3, since the same commit that introduced ipa-modref. when
building the Ada runtime libraries with the stage3 gnat, which is the first
stage that was compiled with -flto, gnat fails with a segfault:

Program received signal SIGSEGV, Segmentation fault.
0x0186f062 in sem_type__get_next_interp (i=53941, it=...) at
../../gcc/ada/sem_type.adb:2425
2425  It := All_Interp.Table (I);
(gdb) bt
#0  0x0186f062 in sem_type__get_next_interp (i=53941, it=...) at
../../gcc/ada/sem_type.adb:2425
#1  0x01855966 in sem_res__resolve (n=, typ=) at ../../gcc/ada/atree.adb:1438
#2  0x0175c1a6 in sem_res__analyze_and_resolve__2 (typ=1454, n=40376)
at
../../gcc/ada/sem_res.adb:329
#3  sem_ch5__analyze_if_statement__analyze_cond_then (cnode=cnode@entry=40375)
at ../../gcc/ada/sem_ch5.adb:1801
#4  0x0175eaac in sem_ch5__analyze_if_statement (n=) at
../../gcc/ada/sem_ch5.adb:1776
#5  0x01668b3c in sem__analyze (n=) at
../../gcc/ada/sem.adb:306
#6  0x0175bddc in sem_ch5__analyze_statements (l=) at
../../gcc/ada/table.adb:155
#7  0x0169808e in sem_ch11__analyze_handled_statements (n=) at ../../gcc/ada/sem_ch11.adb:426
#8  0x01668e92 in sem__analyze (n=) at
../../gcc/ada/sem.adb:297
#9  0x0176833a in sem_ch6__analyze_subprogram_body_helper (n=) at ../../gcc/ada/sem_ch6.adb:5204
#10 sem_ch6__analyze_subprogram_body (n=) at
../../gcc/ada/sem_ch6.adb:2818
#11 0x0166911c in sem__analyze (n=) at
../../gcc/ada/sem.adb:547
#12 0x016f7fb4 in sem_ch3__analyze_declarations (l=) at
../../gcc/ada/table.adb:155
#13 0x017881fa in sem_ch7__analyze_package_body_helper (n=2348) at
../../gcc/ada/sem_ch7.adb:954
#14 sem_ch7__analyze_package_body (n=) at
../../gcc/ada/sem_ch7.adb:180
#15 0x0166910e in sem__analyze (n=) at
../../gcc/ada/sem.adb:444
#16 0x016931fc in sem_ch10__analyze_compilation_unit (n=)
at ../../gcc/ada/sem_ch10.adb:913
#17 0x01668abe in sem__analyze (n=n@entry=2326) at
../../gcc/ada/sem.adb:180
#18 0x01669c8c in sem__semantics__do_analyze () at
../../gcc/ada/sem.adb:1421
#19 sem__semantics (comp_unit=) at ../../gcc/ada/sem.adb:1615
#20 0x015881a4 in _ada_frontend () at ../../gcc/ada/frontend.adb:422
#21 0x0193cb1e in _ada_gnat1drv () at ../../gcc/ada/osint.adb:2130
#22 0x012a2be6 in gnat_parse_file () at
../../gcc/ada/gcc-interface/misc.c:118
#23 0x01ee0b2c in compile_file () at ../../gcc/toplev.c:457
#24 0x0128ac78 in do_compile () at ../../gcc/toplev.c:2193
#25 _ZN6toplev4mainEiPPc (this=0x3ffee5e, argc=,
argv=) at ../../gcc/toplev.c:2332
#26 0x0128b824 in main (argc=, argv=) at
../../gcc/main.c:39


backtrace from the failure in profiledbootstrap:

Breakpoint 2, system__assertions__raise_assert_failure (msg=...) at
../../gcc/ada/libgnat/s-assert.adb:43
43 procedure Raise_Assert_Failure (Msg : String) is
(gdb) bt
#0  system__assertions__raise_assert_failure (msg=...) at
../../gcc/ada/libgnat/s-assert.adb:43
#1  0x01284eba in atree__ekind (e=) at
../../gcc/ada/atree.adb:931
#2  0x019c5c28 in atree__ekind (e=, e=)
at
../../gcc/ada/atree.adb:1438
#3  0x022f0c50 in sem_type__disambiguate (n=,
i1=, i2=, typ=1409) at
../../gcc/ada/atree.adb:1438
#4  0x0226222e in sem_res__valid_conversion (n=,
target=, operand=, report_errs=)
at
../../gcc/ada/sem_type.ads:65
#5  0x01ae6bd0 in sem_res__resolve_type_conversion (typ=,
n=) at ../../gcc/ada/sem_res.adb:11617
#6  sem_res__resolve (n=, typ=typ@entry=100) at
../../gcc/ada/sem_res.adb:3319
#7  0x01ae707a in sem_res__resolve_op_expon (typ=,
n=) at ../../gcc/ada/atree.adb:1438
#8  sem_res__resolve (n=, typ=) at
../../gcc/ada/sem_res.adb:3266
#9  0x020b7c76 in sem_res__resolve_arithmetic_op (n=,
typ=) at ../../gcc/ada/sem_res.adb:5637
#10 0x01ae67d2 in sem_res__resolve (n=, typ=) at ../../gcc/ada/atree.adb:1438
#11 0x02269d54 in sem_ch5__analyze_assignment (n=) at
../../gcc/ada/atree.adb:1438
#12 0x01a6617a in sem__analyze (n=) at
../../gcc/ada/sem.adb:150
#13 0x01c3db40 in sem_ch5__analyze_statements (l=) at
../../gcc/ada/nlists.adb:953
#14 0x022ff2dc in sem_ch5__analyze_loop_statement (n=)
at
../../gcc/ada/sem_ch5.adb:3354
#15 0x01a662c0 in sem__analyze (n=) at
../../gcc/ada/sem.adb:336
#16 0x01c3db40 in sem_ch5__analyze_statements (l=) at
../../gcc/ada/nlists.adb:953
#17 0x022299c0 in sem_ch11__analyze_handled_statements (n=) at ../../gcc/ada/sem_ch11.adb:426
#18 0x01a66188 in sem__analyze (n=) at
../../gcc/ada/sem.adb:297
#19 0x021957ca in sem_ch6__analyze_subprogram_body_helper (n=) at ../../gcc/ada/sem_ch6.adb:5204
#20 sem_ch6__analyze_subprogram_body (n=) at
../../gcc/ada/sem_

[Bug c/98378] new valgrind error for ./gcc.c-torture/execute/pr60960.c

[dcb314 at hotmail dot com via Gcc-bugs]

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

--- Comment #1 from David Binderman  ---
git bisect in progress. Trying hash f23753c710d54fdf.

[Bug c/98378] New: new valgrind error for ./gcc.c-torture/execute/pr60960.c

[dcb314 at hotmail dot com via Gcc-bugs]

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

Bug ID: 98378
   Summary: new valgrind error for
./gcc.c-torture/execute/pr60960.c
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Last week's valgrind build of trunk gcc, hash 97b56dece7413839,
compiled ./gcc.c-torture/execute/pr60960.c fine.

This week's valgrind build of trunk gcc, hash dc00689332f023d9
doesn't. This is what it does:

==471616== Conditional jump or move depends on uninitialised value(s)
==471616==at 0x15CF3B5: (anonymous
namespace)::find_bswap_or_nop_finalize((anonymous namespace)::symbolic_number*,
unsigned long*, unsigned long*) (gimple-ssa-store-merging.c:807)

Source code gimple-ssa-store-merging.c:807 is

  if (n->base_addr)

Flag -O2 used on source code file gcc.c-torture/execute/pr60960.c

[Bug libstdc++/98377] New: bootstrapping failure on windows for floating_to_chars

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 98377
   Summary: bootstrapping failure on windows for floating_to_chars
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

../../../../../gcc-git/libstdc++-v3/src/c++17/floating_to_chars.cc: In function
'std::to_chars_result std::__floating_to_chars_precision(char*, char*, T,
std::chars_format, int)':
../../../../../gcc-git/libstdc++-v3/src/c++17/floating_to_chars.cc:1132:11:
error: 'output_length_upper_bound' was not declared in this scope
 1132 |   output_length_upper_bound = (strlen("-d") + sizeof(radix)
  |   ^
../../../../../gcc-git/libstdc++-v3/src/c++17/floating_to_chars.cc:1138:15:
error: 'output_length_upper_bound' was not declared in this scope
 1138 |   output_length_upper_bound = sign + approx_log10_value +
1;
  |   ^
../../../../../gcc-git/libstdc++-v3/src/c++17/floating_to_chars.cc:1140:15:
error: 'output_length_upper_bound' was not declared in this scope
 1140 |   output_length_upper_bound = sign + strlen("0");
  |   ^
../../../../../gcc-git/libstdc++-v3/src/c++17/floating_to_chars.cc:1141:13:
error: 'output_length_upper_bound' was not declared in this scope
 1141 | output_length_upper_bound += sizeof(radix) +
effective_precision;
  | ^
../../../../../gcc-git/libstdc++-v3/src/c++17/floating_to_chars.cc:1145:21:
error: 'output_length_upper_bound' was not declared in this scope
 1145 | char buffer[output_length_upper_bound+1];
  | ^
../../../../../gcc-git/libstdc++-v3/src/c++17/floating_to_chars.cc:1152:21:
error: 'buffer' was not declared in this scope
 1152 |   = sprintf(buffer, output_specifier, effective_precision,
value);
  | ^~
../../../../../gcc-git/libstdc++-v3/src/c++17/floating_to_chars.cc: In
instantiation of 'std::to_chars_result
std::__floating_to_chars_precision(char*, char*, T, std::chars_format, int)
[with T = long double]':
../../../../../gcc-git/libstdc++-v3/src/c++17/floating_to_chars.cc:1546:76:  
required from here
../../../../../gcc-git/libstdc++-v3/src/c++17/floating_to_chars.cc:1130:13:
warning: unused variable 'output_length_upper_bound' [-Wunused-variable]
 1130 | int output_length_upper_bound;
  | ^
../../../../../gcc-git/libstdc++-v3/src/c++17/floating_to_chars.cc:1163:33:
error: could not convert '{, ((std::size_t)output_length)}'
from '' to 'const string_view' {aka 'const
std::basic_string_view'}
 1163 |   const string_view buffer_sv = {buffer,
(size_t)output_length};
  | ^
  | |
  | 
make[5]: *** [Makefile:577: floating_to_chars.lo] Error 1
make[5]: *** Waiting for unfinished jobs
make[5]: Leaving directory
'/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/src/c++17'
make[4]: *** [Makefile:764: all-recursive] Error 1
make[4]: Leaving directory
'/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/src'
make[3]: *** [Makefile:568: all-recursive] Error 1
make[3]: Leaving directory
'/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3'
make[2]: *** [Makefile:493: all] Error 2
make[2]: Leaving directory
'/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3'
make[1]: *** [Makefile:12181: all-target-libstdc++-v3] Error 2
make[1]: Leaving directory
'/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32'
make: *** [Makefile:973: all] Error 2
==> ERROR: A failure occurred in build().
Aborting...

[Bug libstdc++/98370] libstdc++-v3/src/c++17/floating_to_chars.cc fails to compile unless `int32_t' is `int'

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

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

--- Comment #5 from Patrick Palka  ---
(In reply to Hans-Peter Nilsson from comment #4)
> JFTR, likely all "32-bit targets".

Thanks, and sorry about the build breakage.  I just committed the fix r11-6260
for this particular build failure.  Let me know if you're still seeing
problems.

[Bug c/98217] Prefer a warning for when VLAs declared on stack

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|WAITING |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |msebor at gcc dot 
gnu.org
   Last reconfirmed|2020-12-09 00:00:00 |2020-12-18

--- Comment #12 from Martin Sebor  ---
Okay then, let me try to handle this for GCC 12.

[Bug c/85997] Bogus -Wvla warning from function array argument with size expression

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

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed||2020-12-18
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=98217
 CC||msebor at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #5 from Martin Sebor  ---
I think the request to avoid the warning (except in pedantic -std=c90 mode) is
what we agreed to in pr98217, so confirmed.

[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57

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

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

Martin Sebor  changed:

   What|Removed |Added

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

[Bug libstdc++/98370] libstdc++-v3/src/c++17/floating_to_chars.cc fails to compile unless `int32_t' is `int'

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

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

--- Comment #4 from Hans-Peter Nilsson  ---
JFTR, likely all "32-bit targets".

[Bug libstdc++/98370] libstdc++-v3/src/c++17/floating_to_chars.cc fails to compile unless `int32_t' is `int'

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

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

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

https://gcc.gnu.org/g:22a7e82c200d01d12e34e757e86dc9796a9bf085

commit r11-6260-g22a7e82c200d01d12e34e757e86dc9796a9bf085
Author: Patrick Palka 
Date:   Fri Dec 18 11:52:24 2020 -0500

libstdc++: Fix build failure on AArch64 ILP32 [PR98370]

This should fix a build failure on AArch64 ILP32 due to int32_t mapping
to long int instead of int on this platform, which causes type deduction
to fail in the below call to std::max as reported in the PR.

libstdc++-v3/ChangeLog:

PR libstdc++/98370
* src/c++17/floating_to_chars.cc (__floating_to_chars_shortest):
Provide explicit template arguments to the call to std::max.

[Bug libstdc++/98374] No #include on windows. Bootstrapping failure

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

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

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

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

commit r11-6259-gd7bab388b818fc21dbb9111311e114ae33e11fff
Author: Patrick Palka 
Date:   Fri Dec 18 11:52:17 2020 -0500

libstdc++: Fix build failure due to missing  [PR98374]

This should fix a build failure on Windows which lacks ,
from which we use nl_langinfo() to obtain the radix character of the
current locale.  (We can't use the more portable localeconv() from
 to obtain the radix character of the current locale here
because it's not thread-safe, unfortunately.)

This change means that on Windows and other such platforms, we'll just
always assume the radix character used by printf is '.' when formatting
a long double through it.

libstdc++-v3/ChangeLog:

PR libstdc++/98374
* src/c++17/floating_to_chars.cc: Guard include of 
with __has_include.
(__floating_to_chars_precision) [!defined(RADIXCHAR)]: Don't
attempt to obtain the radix character of the current locale,
just assume it's '.'.

[Bug target/98321] [nvptx] 'atom.add.f32' for atomic add of 32-bit 'float'

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

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

--- Comment #5 from Tom de Vries  ---
(In reply to Thomas Schwinge from comment #4)
> I had been looking into how/when PTX 'atom' is used for reductions, and
> first had a look what the back end currently might emit at all, found SDIM
> 'atomic_fetch_add', and SF 'atomic_fetch_addsf'.

Ack.

> I tried to get these
> used via '(void) __atomic_fetch_add (&a, b, __ATOMIC_RELAXED);', which works
> fine for integer types, but 'error: operand type ‘float *’ is incompatible
> with argument 1 of ‘__atomic_fetch_add’' (didn't research the rationale
> behind that), so resorted to 'acc atomic'.
> Further analysis to be done. 
> (Can floating-point type atomic generally not be supported, given that
> '__atomic_fetch_add' rejects it?  Is OMP atomic handling doing something
> wrong for these even for nvptx target (real, not via offloading)?  Is
> something wrong in the nvptx back end?)
> 

I don't know the rationale either, but at least it looks like documented
behaviour, both for the builtin and the pattern.

I don't see the backend doing anything wrong.

> This isn't important right now; I just filed the issue as I'd found it.

Ack, understood.

[Bug libstdc++/98370] libstdc++-v3/src/c++17/floating_to_chars.cc fails to compile unless `int32_t' is `int'

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

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

--- Comment #2 from Patrick Palka  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562287.html

[Bug libstdc++/98374] No #include on windows. Bootstrapping failure

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

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

--- Comment #1 from Patrick Palka  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562283.html

[Bug middle-end/98366] [11 Regression] wrong-code with memcmp and -m32

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

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

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

Untested fix.

[Bug c++/98362] bad file data on Windows for C++ 20 module

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

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

--- Comment #6 from Nathan Sidwell  ---
* 785b49434d2 2020-12-18 | c++: Fix windows binary files [PR 98362]

[Bug libstdc++/98376] this_thread::sleep_for(short duration) can sleep forever on Linux

[paul.groke at dynatrace dot com via Gcc-bugs]

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

--- Comment #1 from Paul Groke  ---
Sorry, I only realized that using links to master doesn't make much sense after
I had already created the ticket.

Those links should be stable:

https://github.com/golang/proposal/blob/5b63da9579c3b19294be614dcad33e20a9a4ad22/design/24543-non-cooperative-preemption.md
https://github.com/golang/go/blob/go1.15.6/src/runtime/signal_unix.go#L347
https://github.com/golang/go/blob/go1.15.6/src/runtime/preempt.go#L223

[Bug middle-end/98373] [11 Repression] Bogus error: ‘symbuf’ may be used uninitialized at -O0

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1
   Last reconfirmed||2020-12-18
 CC||msebor at gcc dot gnu.org

--- Comment #1 from Martin Sebor  ---
The warning looks justified to me.  Would you mind explaining why you think
it's invalid?  (It seems like a basic expectation of any report.)

[Bug libstdc++/98376] New: this_thread::sleep_for(short duration) can sleep forever on Linux

[paul.groke at dynatrace dot com via Gcc-bugs]

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

Bug ID: 98376
   Summary: this_thread::sleep_for(short duration) can sleep
forever on Linux
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: paul.groke at dynatrace dot com
  Target Milestone: ---

If libstdc++ is configured with _GLIBCXX_USE_NANOSLEEP (which seems to be the
case on most systems), it will use nanosleep in this_thread::sleep_for like
this:

__gthread_time_t __ts =
  {
static_cast(__s.count()),
static_cast(__ns.count())
  };
while (::nanosleep(&__ts, &__ts) == -1 && errno == EINTR)
  { }

However on Linux, such a nanosleep loop can run forever because of a Linux bug
that's documented here:
https://man7.org/linux/man-pages/man2/nanosleep.2.html#BUGS

For this to happen the thread needs to receive signals at a high frequency
which seems to be rather uncommon.

However there's a Go feature called non-cooperative preemption that can trigger
this quite easily, see
https://github.com/golang/proposal/blob/master/design/24543-non-cooperative-preemption.md
https://github.com/golang/go/blob/master/src/runtime/signal_unix.go#L352
https://github.com/golang/go/blob/master/src/runtime/preempt.go#L223

This could lead to problems when on Linux, native code that uses libstdc++ is
called from a Go thread. The Go thread executing this_thread::sleep_for will
loop forever calling nanosleep and the other Go thread that tries to preempt it
will also loop forever, perpetually trying to preempt it.

[Bug target/98060] Failure to optimize cmp+setnb+add to cmp+sbb

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug other/98375] [meta bug] GCC 12 pending patches

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-12-18
   Target Milestone|--- |12.0
 Ever confirmed|0   |1

[Bug other/98375] New: [meta bug] GCC 12 pending patches

[ubizjak at gmail dot com via Gcc-bugs]

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

Bug ID: 98375
   Summary: [meta bug] GCC 12 pending patches
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ubizjak at gmail dot com
  Target Milestone: ---

This metabug is used to track all the patches which have been written during 
Stage 3 of GCC 11 but do not qualify for that stage, and are waiting for Stage 
1 of GCC 12 to be applied.

Please, do not attach patches to this bug. Open a new bug report, and mark 
it as "blocking" this metabug (this metabug will "depend" on the new bug 
report).

[Bug libstdc++/98374] No #include on windows. Bootstrapping failure

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

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

Patrick Palka  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ppalka at gcc dot 
gnu.org
   Last reconfirmed||2020-12-18
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

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

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

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

--- Comment #7 from Marek Polacek  ---
template 
struct ctad_t {
A a;
};

template 
struct myclass {
};

template 
constexpr auto myobject = ctad_t {Something::value};

template 
using thing = myclass>;

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

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||jbassett271 at gmail dot com

--- Comment #6 from Marek Polacek  ---
*** Bug 98367 has been marked as a duplicate of this bug. ***

[Bug c++/98367] ICE with CTAD non-type template parameter

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

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

Marek Polacek  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|UNCONFIRMED |RESOLVED
 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
Dup, I think.  This is a nice test, though.

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

[Bug c++/98363] C++ 20 module ICE for fast_io library

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #5 from cqwrteur  ---
(In reply to Nathan Sidwell from comment #4)
> FWIW I think it premature to start agressively filing these kinds of
> defects.  We haven't added the module testsuite yet.

No problem. I will keep helping you. I use GCC heavily on both windows and
linux and my library is built with full of C++20 features, including concepts,
coroutines, ranges, etc. I think I can help a lot on supporting modules on
Windows.

[Bug libstdc++/98370] libstdc++-v3/src/c++17/floating_to_chars.cc fails to compile unless `int32_t' is `int'

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

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

Patrick Palka  changed:

   What|Removed |Added

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

[Bug libstdc++/98374] New: No #include on windows. Bootstrapping failure

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 98374
   Summary: No #include  on windows. Bootstrapping
failure
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

libtool: compile: 
/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/xgcc
-shared-libgcc
-B/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc
-nostdinc++
-L/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/src
-L/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include
-I/home/unlvs/mingw-gcc-mcf-gthread/src/gcc-git/libstdc++-v3/../libgcc
-I/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32
-I/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/include
-I/home/unlvs/mingw-gcc-mcf-gthread/src/gcc-git/libstdc++-v3/libsupc++
-I/mingw64/include -I/mingw64/include -std=gnu++17 -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=cow-fs_dir.lo -fimplicit-templates -g -march=x86-64
-mtune=generic -O2 -pipe -c
../../../../../gcc-git/libstdc++-v3/src/c++17/cow-fs_dir.cc -o cow-fs_dir.o
../../../../../gcc-git/libstdc++-v3/src/c++17/floating_to_chars.cc:36:10: fatal
error: langinfo.h: No such file or directory
   36 | #include 
  |  ^~~~
libtool: compile: 
/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/xgcc
-shared-libgcc
-B/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc
-nostdinc++
-L/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/src
-L/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include
-I/home/unlvs/mingw-gcc-mcf-gthread/src/gcc-git/libstdc++-v3/../libgcc
-I/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32
-I/home/unlvs/mingw-gcc-mcf-gthrecompilation terminated.
ad/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/include
-I/home/unlvs/mingw-gcc-mcf-gthread/src/gcc-git/libstdc++-v3/libsupc++
-I/mingw64/include -I/mingw64/include -std=gnu++17 -D_GLIBCXX_SHARED
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=cow-fs_ops.lo -fimplicit-templates -g -march=x86-64
-mtune=generic -O2 -pipe -c
../../../../../gcc-git/libstdc++-v3/src/c++17/cow-fs_ops.cc -o cow-fs_ops.o
libtool: compile: 
/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc/xgcc
-shared-libgcc
-B/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/./gcc
-nostdinc++
-L/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/src
-L/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/libsupc++/.libs
-L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/lib -isystem
/mingw64/x86_64-w64-mingw32/include -isystem /mingw64/include
-B/mingw64/x86_64-w64-mingw32/bin/ -B/mingw64/x86_64-w64-mingw32/lib/ -isystem
/mingw64/x86_64-w64-mingw32/include -isystem
/mingw64/x86_64-w64-mingw32/sys-include
-I/home/unlvs/mingw-gcc-mcf-gthread/src/gcc-git/libstdc++-v3/../libgcc
-I/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32
-I/home/unlvs/mingw-gcc-mcf-gthread/src/build-x86_64-w64-mingw32/x86_64-w64-mingw32/libstdc++-v3/include
-I/home/unlvs/mingw-gcc-mcf-gthread/src/gcc-git/libstdc++-v3/libsupc++
-I/mingw64/include -I/mingw64/include -std=gnu++17 -D_GLIBCXX_SHARED
-fno-implicit-templates

[Bug c++/98362] bad file data on Windows for C++ 20 module

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #5 from cqwrteur  ---
Created attachment 49798
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49798&action=edit
Compilation Working patch. Tested on both x86_64-linux-gnu and
mingw-w64-x86_64-windows10

This also adds the support for O_CLOEXEC on Windows with the O_NOINHERIT flag.

No longer uses HOST_HAS_O_CLOEXEC macro generated by the autotool. Directly
checking O_CLOEXEC macro on that platform.

There is a new bug for libstdc++ before I could test whether module works on
windows, but this patch does not break compilation.

[Bug tree-optimization/94779] Bad optimization of simple switch

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #22 from Andrew Macleod  ---
(In reply to Martin Liška from comment #21)
> > See my comment above.  It isn't any integration of VRP, just asking the
> > ranger about the range, and it isn't useless because to be able to optimize
> > properly,
> > you need to figure out for each value one of the 3 possibilities (handled
> > explicitly by switch and well defined, handled by default and never
> > reachable or UB).
> 
> I've got the point that we have these 3 possibilities for each case.
> However, we also have it for "holes" which are removed and we can't
> distinguish
> them in between __builtin_unreachable and falling to the default case.
> 
> I believe a better place for Ranger is to improve:
> simplify_using_ranges::simplify_switch_using_ranges (gswitch *stmt)

Long term, my goal is to decentralize this sort of thing.  This routine a is
legacy approach from when VRP needed to be a mini-optimizer because it was the
only place reasonable range information was available. 

I would  to push virtually everything from VRP into more appropriate places.
folding, simplification, threading, switch rewriting, etc can all be done
either in a specialized pass of their own, or ongoing as other related things
are happening.  

Switch simplification/optimization in particular is a good candidate.  A self
contained pass that knows what best to do with a switch, and can utilize
accurate range info can take care of everything with a deep analysis. It could
be invoked in multiple places if required.  Then you don't need to worry about
a pass like VRP or some other pass messing up the structure of the switch.  

I would like to see the simplification routines completely moved into a switch
optimization  pass, and VRP would then just ignore switches.

[Bug target/98361] L1/L2 cache characteristics not recognized with -mtune=znver2

[sdack at gmx dot com via Gcc-bugs]

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

--- Comment #2 from Sven  ---
Thank you.

I did ask about the issue on gcc-help, but I never got a notice about a fix.
Some ninja appears to have cherry-picked it for 10.2.x a few days after my
initial mail.

[Bug fortran/83118] [8/9/10/11 Regression] Bad intrinsic assignment of class(*) array component of derived type

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

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

--- Comment #38 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r11-6253-gce8dcc9105cbd4043d575d8b2c91309a423951a9
Author: Paul Thomas 
Date:   Fri Dec 18 14:00:11 2020 +

As well as the PR this patch fixes problems in handling class objects

2020-12-18  Paul Thomas  

gcc/fortran
PR fortran/83118
PR fortran/96012
* resolve.c (resolve_ordinary_assign): Generate a vtable if
necessary for scalar non-polymorphic rhs's to unlimited lhs's.
* trans-array.c (get_class_info_from_ss): New function.
(gfc_trans_allocate_array_storage): Defer obtaining class
element type until all sources of class exprs are tried. Use
class API rather than TREE_OPERAND. Look for class expressions
in ss->info by calling get_class_info_from_ss. After, obtain
the element size for class descriptors. Where the element type
is unknown, cast the data as character(len=size) to overcome
unlimited polymorphic problems.
(gfc_conv_ss_descriptor): Do not fix class variable refs.
(build_class_array_ref, structure_alloc_comps): Replace code
replicating the new function gfc_resize_class_size_with_len.
(gfc_alloc_allocatable_for_assignment): Obtain element size
for lhs in cases of deferred characters and class enitities.
Move code for the element size of rhs to start of block. Clean
up extraction of class parameters throughout this function.
After the shape check test whether or not the lhs and rhs
element sizes are the same. Use earlier evaluation of
'cond_null'. Reallocation of lhs only to happen if size changes
or element size changes.
* trans-expr.c (gfc_resize_class_size_with_len): New function.
(gfc_get_class_from_expr): If a constant expression is
encountered, return NULL_TREE;
(trans_scalar_class_assign): New function.
(gfc_conv_procedure_call): Ensure the vtable is present for
passing a non-class actual to an unlimited formal.
(trans_class_vptr_len_assignment): For expressions of type
BT_CLASS, extract the class expression if necessary. Use a
statement block outside the loop body. Ensure that 'rhs' is
of the correct type. Obtain rhs vptr in all circumstances.
(gfc_trans_scalar_assign): Call trans_scalar_class_assign to
make maximum use of the vptr copy in place of assignment.
(trans_class_assignment): Actually do reallocation if needed.
(gfc_trans_assignment_1): Simplify some of the logic with
'realloc_flag'. Set 'vptr_copy' for all array assignments to
unlimited polymorphic lhs.
* trans.c (gfc_build_array_ref): Call gfc_resize_class_size_
with_len to correct span for unlimited polymorphic decls.
* trans.h : Add prototype for gfc_resize_class_size_with_len.

gcc/testsuite/
PR fortran/83118
PR fortran/96012
* gfortran.dg/dependency_60.f90: New test.
* gfortran.dg/class_allocate_25.f90: New test.
* gfortran.dg/class_assign_4.f90: New test.
* gfortran.dg/unlimited_polymorphic_32.f03: New test.

[Bug fortran/96012] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2558

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Paul Thomas :

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

commit r11-6253-gce8dcc9105cbd4043d575d8b2c91309a423951a9
Author: Paul Thomas 
Date:   Fri Dec 18 14:00:11 2020 +

As well as the PR this patch fixes problems in handling class objects

2020-12-18  Paul Thomas  

gcc/fortran
PR fortran/83118
PR fortran/96012
* resolve.c (resolve_ordinary_assign): Generate a vtable if
necessary for scalar non-polymorphic rhs's to unlimited lhs's.
* trans-array.c (get_class_info_from_ss): New function.
(gfc_trans_allocate_array_storage): Defer obtaining class
element type until all sources of class exprs are tried. Use
class API rather than TREE_OPERAND. Look for class expressions
in ss->info by calling get_class_info_from_ss. After, obtain
the element size for class descriptors. Where the element type
is unknown, cast the data as character(len=size) to overcome
unlimited polymorphic problems.
(gfc_conv_ss_descriptor): Do not fix class variable refs.
(build_class_array_ref, structure_alloc_comps): Replace code
replicating the new function gfc_resize_class_size_with_len.
(gfc_alloc_allocatable_for_assignment): Obtain element size
for lhs in cases of deferred characters and class enitities.
Move code for the element size of rhs to start of block. Clean
up extraction of class parameters throughout this function.
After the shape check test whether or not the lhs and rhs
element sizes are the same. Use earlier evaluation of
'cond_null'. Reallocation of lhs only to happen if size changes
or element size changes.
* trans-expr.c (gfc_resize_class_size_with_len): New function.
(gfc_get_class_from_expr): If a constant expression is
encountered, return NULL_TREE;
(trans_scalar_class_assign): New function.
(gfc_conv_procedure_call): Ensure the vtable is present for
passing a non-class actual to an unlimited formal.
(trans_class_vptr_len_assignment): For expressions of type
BT_CLASS, extract the class expression if necessary. Use a
statement block outside the loop body. Ensure that 'rhs' is
of the correct type. Obtain rhs vptr in all circumstances.
(gfc_trans_scalar_assign): Call trans_scalar_class_assign to
make maximum use of the vptr copy in place of assignment.
(trans_class_assignment): Actually do reallocation if needed.
(gfc_trans_assignment_1): Simplify some of the logic with
'realloc_flag'. Set 'vptr_copy' for all array assignments to
unlimited polymorphic lhs.
* trans.c (gfc_build_array_ref): Call gfc_resize_class_size_
with_len to correct span for unlimited polymorphic decls.
* trans.h : Add prototype for gfc_resize_class_size_with_len.

gcc/testsuite/
PR fortran/83118
PR fortran/96012
* gfortran.dg/dependency_60.f90: New test.
* gfortran.dg/class_allocate_25.f90: New test.
* gfortran.dg/class_assign_4.f90: New test.
* gfortran.dg/unlimited_polymorphic_32.f03: New test.

[Bug c++/98358] new test case g++.dg/template/pr98297.C in r8-10683 fails

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

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

Christophe Lyon  changed:

   What|Removed |Added

 Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu
   ||aarch64 arm
 CC||clyon at gcc dot gnu.org

--- Comment #2 from Christophe Lyon  ---
Seen on arm and aarch64 if that helps to reproduce it.

[Bug libstdc++/98370] libstdc++-v3/src/c++17/floating_to_chars.cc fails to compile unless `int32_t' is `int'

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

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

Alex Coplan  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
 CC||acoplan at gcc dot gnu.org,
   ||ppalka at gcc dot gnu.org
   Last reconfirmed||2020-12-18

--- Comment #1 from Alex Coplan  ---
Confirmed. Presumably started with g:3c57e692357c79ee7623dfc1586652aee2aefb8f?

[Bug c++/98362] bad file data on Windows for C++ 20 module

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #4 from cqwrteur  ---
(In reply to Nathan Sidwell from comment #2)
> Created attachment 49797 [details]
> test patch
> 
> care to try this?

I will modify your patch and try to support O_CLOSEXEC on Windows

[Bug c++/98362] bad file data on Windows for C++ 20 module

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #3 from cqwrteur  ---
(In reply to Nathan Sidwell from comment #2)
> Created attachment 49797 [details]
> test patch
> 
> care to try this?

Sure

BTW. Windows do provide a flag O_NOINHERIT which matches O_CLOSEXEC.

[Bug c++/98364] C++20 module global constructor emission

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-12-18
Summary|C++20 module binary bloat   |C++20 module global
   ||constructor emission

--- Comment #1 from Nathan Sidwell  ---
missed optimization/bad predicate

[Bug c++/98362] bad file data on Windows for C++ 20 module

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

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

--- Comment #2 from Nathan Sidwell  ---
Created attachment 49797
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49797&action=edit
test patch

care to try this?

[Bug target/98218] [TARGET_MMX_WITH_SSE] Miss vec_cmpmn/vcondmn expander for 64bit vector

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Target|x86_64-*-* i?86-*-* |x86
 Status|NEW |ASSIGNED
   Host|x86_64-pc-linux-gnu |
   Target Milestone|--- |12.0
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

[Bug target/98218] [TARGET_MMX_WITH_SSE] Miss vec_cmpmn/vcondmn expander for 64bit vector

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Uroš Bizjak  ---
Testcase 1:

--cut here--
typedef short vec __attribute__((vector_size(8)));
typedef unsigned short uvec __attribute__((vector_size(8)));

vec lt (vec a, vec b) { return a < b; }
vec le (vec a, vec b) { return a <= b; }
vec eq (vec a, vec b) { return a == b; }
vec ne (vec a, vec b) { return a != b; }
vec ge (vec a, vec b) { return a >= b; }
vec gt (vec a, vec b) { return a > b; }

vec ltu (uvec a, uvec b) { return a < b; }
vec leu (uvec a, uvec b) { return a <= b; }
vec geu (uvec a, uvec b) { return a >= b; }
vec gtu (uvec a, uvec b) { return a > b; }
--cut here--

Testcase 2:

--cut here--
typedef short T;

#define M 4

T a[M];
T b[M];
T s1[M];
T s2[M];
T r[M];

void foo (void)
{
  int j;

  for (j = 0; j < M; j++)
r[j] = (a[j] < b[j]) ? s1[j] : s2[j];
}
--cut here--

gcc -O3:

foo:
movqa(%rip), %xmm1
movqb(%rip), %xmm0
movqs2(%rip), %xmm2
pcmpgtw %xmm1, %xmm0
movqs1(%rip), %xmm1
pand%xmm0, %xmm1
pandn   %xmm2, %xmm0
por %xmm1, %xmm0
movq%xmm0, r(%rip)
ret

[Bug target/98218] [TARGET_MMX_WITH_SSE] Miss vec_cmpmn/vcondmn expander for 64bit vector

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Uroš Bizjak  ---
Created attachment 49796
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49796&action=edit
Proposed patch to implement integer vector compares

Attached patch implements integer vector compares.

[Bug middle-end/98373] New: [11 Repression] Bogus error: ‘symbuf’ may be used uninitialized at -O0

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

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

Bug ID: 98373
   Summary: [11 Repression] Bogus error: ‘symbuf’ may be used
uninitialized at -O0
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---

Created attachment 49795
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49795&action=edit
A testcase

[hjl@gnu-cfl-2 gold]$ /usr/gcc-11.0.0-x32/bin/g++ -S /tmp/plugin.ii -W -Wall
/export/linux/src/binutils/binutils/gold/plugin.cc: In member function ‘void
gold::Sized_pluginobj::do_add_symbols(gold::Symbol_table*,
gold::Read_symbols_data*, gold::Layout*) [with int size = 32; bool big_endian =
false]’:
/export/linux/src/binutils/binutils/gold/plugin.cc:1400:33: warning: ‘symbuf’
may be used uninitialized [-Wmaybe-uninitialized]
 1400 |   elfcpp::Sym sym(symbuf);
  | ^~~
In file included from /export/linux/src/binutils/binutils/gold/script.h:37,
 from /export/linux/src/binutils/binutils/gold/layout.h:33,
 from /export/linux/src/binutils/binutils/gold/plugin.cc:73:
/export/linux/src/binutils/binutils/gold/../elfcpp/elfcpp.h:1532:3: note: by
argument 2 of type ‘const unsigned char*’ to ‘elfcpp::Sym::Sym(const unsigned char*) [with int size = 32; bool big_endian =
false]’ declared here
 1532 |   Sym(const unsigned char* p)
  |   ^~~
/export/linux/src/binutils/binutils/gold/plugin.cc:1399:17: note: ‘symbuf’
declared here
 1399 |   unsigned char symbuf[sym_size];
  | ^~
/export/linux/src/binutils/binutils/gold/plugin.cc: In member function ‘void
gold::Sized_pluginobj::do_add_symbols(gold::Symbol_table*,
gold::Read_symbols_data*, gold::Layout*) [with int size = 64; bool big_endian =
false]’:
/export/linux/src/binutils/binutils/gold/plugin.cc:1400:33: warning: ‘symbuf’
may be used uninitialized [-Wmaybe-uninitialized]
 1400 |   elfcpp::Sym sym(symbuf);
  | ^~~
In file included from /export/linux/src/binutils/binutils/gold/script.h:37,
 from /export/linux/src/binutils/binutils/gold/layout.h:33,
 from /export/linux/src/binutils/binutils/gold/plugin.cc:73:
/export/linux/src/binutils/binutils/gold/../elfcpp/elfcpp.h:1532:3: note: by
argument 2 of type ‘const unsigned char*’ to ‘elfcpp::Sym::Sym(const unsigned char*) [with int size = 64; bool big_endian =
false]’ declared here
 1532 |   Sym(const unsigned char* p)
  |   ^~~
/export/linux/src/binutils/binutils/gold/plugin.cc:1399:17: note: ‘symbuf’
declared here
 1399 |   unsigned char symbuf[sym_size];
  | ^~
[hjl@gnu-cfl-2 gold]$ /usr/gcc-11.0.0-x32/bin/g++ -S /tmp/plugin.ii -W -Wall
-O2
[hjl@gnu-cfl-2 gold]$

[Bug c/97172] [11 Regression] ICE: tree code ‘ssa_name’ is not supported in LTO streams since r11-3303-g6450f07388f9fe57

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

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

--- Comment #21 from Martin Liška  ---
Just for the record, 'cava' package is also affected by this issue.

[Bug c++/98362] bad file data on Windows for C++ 20 module

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-12-18
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |nathan at gcc dot 
gnu.org

--- Comment #1 from Nathan Sidwell  ---
ah, I didn't know the binary/text distinction descended below the FILE level on
windows