[Bug other/100174] Binary floating-point conversion under source-gcc/gcc/real.[c\h] test on x86-64

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-04-21
 Ever confirmed|0   |1
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Andrew Pinski  ---
>I don't know why gcc using clear_significand_below(real.c) function to clear 
>remaining bits in sig[SIGSZ-1]
>Why not just only truncated it by it need.

I don't understand your question. Are you asking why not just record the
significand bits that are non-zero instead of doing a clear?  Because it is
faster to clear them and then just them normally instead of special casing
through all of the code of every access to the sig array.

[Bug c/100150] ice in bp_unpack_string

[dcb314 at hotmail dot com via Gcc-bugs]

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

David Binderman  changed:

   What|Removed |Added

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

--- Comment #13 from David Binderman  ---
It would appear that object modules generated by an old fortran 95
compiler won't mix nicely with object modules generated by new gcc.

Happily, object modules generated by new fortran 95 compiler work
lovely with object modules generated by new gcc.

It looks like no further action to me.

[Bug middle-end/100130] R section flag handling doesn't cope with intervening decls

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

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

commit r12-17-gb67778b59932fdc64dc89a97550349e973ca0352
Author: Richard Sandiford 
Date:   Wed Apr 21 09:08:44 2021 +0100

varasm: Two SECTION_RETAIN fixes [PR100130]

switch_to_section warns if we try to output a retain decl in a
section without a retain flag, or if we try to output a non-retain
decl in a section with a retain flag.  However, the warning only
applied if we were trying to âswitchâ to the current section.
This works if all decls that use a section are generated consecutively,
but not if there is an unrelated decl in between.

This patch makes the check unconditional, but suppresses the warning
if we're writing the section's named.decl (i.e. the decl from which
the section name and original flags were derived).

Also, the warning didn't fire for -fsection-anchors, for two reasons:
we allowed retain and non-retain decls to be put into the same block,
and we didn't pass a decl to switch_to_section.

Although these are arguably separate bugs, it isn't easy to fix them
independently without temporarily regressing -fsection-anchor targets.

gcc/
PR middle-end/100130
* varasm.c (get_block_for_decl): Make sure that any use of the
retain attribute matches the section's retain flag.
(switch_to_section): Check for retain mismatches even when
changing sections, but do not warn if the given decl is the
section's named.decl.
(output_object_block): Pass the first decl in the block (if any)
to switch_to_section.

gcc/testsuite/
PR middle-end/100130
* c-c++-common/attr-retain-10.c: New test.
* c-c++-common/attr-retain-11.c: Likewise.

[Bug middle-end/100130] R section flag handling doesn't cope with intervening decls

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

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

 Resolution|--- |FIXED
Version|11.0|12.0
 Status|ASSIGNED|RESOLVED

--- Comment #3 from rsandifo at gcc dot gnu.org  
---
Fixed for GCC 12.

[Bug tree-optimization/100171] autovectorizer

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

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

--- Comment #3 from Richard Biener  ---
Compared to the non-self case where we see

   [local count: 357878152]:
  _19 = MEM  [(const value_type &)arg1_3(D)][0];
  _20 = MEM  [(const value_type &)arg2_4(D)][0];
  _21 = _19 + _20;
  _26 = MEM  [(const value_type &)arg1_3(D)][1];
  _27 = MEM  [(const value_type &)arg2_4(D)][1];
  _28 = _26 + _27;
  res ={v} {CLOBBER};
  MEM[(struct value_type *)out_2(D)][0].value._M_elems[0] = _21;
  MEM[(struct value_type *)out_2(D)][0].value._M_elems[1] = _28;
  return;

here intermediate optimizations have elided 'res'.

[Bug tree-optimization/100162] missed optimization for dead code elimination at -O3 (vs. -O2)

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

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

Richard Biener  changed:

   What|Removed |Added

Version|unknown |12.0
 CC||rguenth at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2021-04-21
 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
Optimized by DOM3 which sees the following difference:

-   [local count: 118111601]:
+   [local count: 955630225]:
   b.1_1 = b;
-  c[0][b.1_1] = 2;
-  c[1][b.1_1] = 2;
-  c[2][b.1_1] = 2;
-  c[3][b.1_1] = 2;
+  _27 = (sizetype) b.1_1;
+  _28 = _27 * 4;
+  vectp_c.13_26 = &c + _28;
+  MEM  [(int *)vectp_c.13_26] = { 2, 2, 2, 2 };
+  vectp_c.12_30 = vectp_c.13_26 + 16;
   c[4][b.1_1] = 2;
   a = 5;
   _5 = b.1_1 != 0;
   _6 = (int) _5;
-  _8 = _6 / 2;
+  _7 = c[0][0];
+  _8 = _6 / _7;
   if (_8 != 0)

here c[0][b.1_1] takes advantage of get_ref_base_and_extent honoring the known
array size of [1] while the pointer based access is not constrained this way
which makes matching c[0][0] to *(&c + _28) = { 2, 2, 2, 2 } difficult.

The realistic chance is to catch this by improving value-numbering done
on the not unrolled loop earlier:

   [local count: 955630225]:
  # a.3_19 = PHI <_2(3), 0(2)>
  c[a.3_19][b.1_1] = 2;
  _2 = a.3_19 + 1;
  if (_2 <= 4)
goto ; [89.00%]
  else
goto ; [11.00%]

   [local count: 118111600]:
  a = _2;
  _5 = b.1_1 != 0;
  _6 = (int) _5;
  _7 = c[0][0];

where we could use SCEV & friends to lookup c[0][0] at the c[a.3_19][b.1_1]
definition in vn_reference_lookup_3.

That might also help to look through loop abstraction earlier.

[Bug libstdc++/96416] to_address() is broken by static_assert in pointer_traits

[dangelog at gmail dot com via Gcc-bugs]

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

--- Comment #18 from Giuseppe D'Angelo  ---
Hello,

(In reply to Jonathan Wakely from comment #17)
> (In reply to Giuseppe D'Angelo from comment #14)
> > To summarize:
> > 
> > * should a wording defect be raised against std::to_address(Ptr), to state
> > that pointer_traits being well-formed is actually a prerequisite?
> 
> I'd prefer if pointer_traits was just SFINAE friendly.

I guess that's a reasonable thing to wish for, given I'm not the first falling
for it; I hope I'll be the last :)

> > * should LWG3446's resolution be amended?
> 
> See https://cplusplus.github.io/LWG/issue3541
> 
> > * if there's going to be a GCC 10.3, is the commit above solving LWG3446
> > going to be cherry-picked into it? Otherwise, either one blacklists GCC 10,
> > or has to specialize pointer_traits there as a workaround (?).
> 
> It missed the 10.3 release, but it's on the gcc-10 branch as r10-9698, which
> will be in GCC 10.4:
> https://gcc.gnu.org/g:32a859531e854382c18abf0b14a306d83f793eb5
> That also includes the fix for LWG 3541.

Thank you very much for the new issue and the cherry-pick of the fix.

[Bug fortran/100154] [9/10/11 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131

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

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

Tobias Burnus  changed:

   What|Removed |Added

 CC||burnus at gcc dot gnu.org

--- Comment #4 from Tobias Burnus  ---
(In reply to anlauf from comment #2)
> Untested patch:
...
> +  if (c->expr_type != EXPR_VARIABLE

Will this also work with:

  character, target :: c
  n = fget(ptr_returning_func())
contains
  function ptr_returning_func() result(res)
character, ptr :: res
res => c
  end
end

as ptr_returning_func() (a function reference with data pointer result) is a
variable in the sense of the Fortran standard (F2018:R902)?

  * * *

  add_sym_1_intent ("fget", GFC_ISYM_FGET, CLASS_IMPURE, ACTUAL_NO, BT_INTEGER,
 di, GFC_STD_GNU, gfc_check_fgetput, NULL, gfc_resolve_fget,
 c, BT_CHARACTER, dc, REQUIRED, INTENT_OUT);

Do we need some generic check for INTENT_OUT to get passed something definable?

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

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

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

--- Comment #15 from Iain Sandoe  ---
I have to try and figure out a way to be able to reproduce the run-time error.

Yes, the assembler output is different between 10.2 and 10.3 - but that insn is
not apparently in error (and I checked that the assembler gives the same bit
pattern for it with GAS and LLVM - it would probably have been astonishing if
that was wrong... but)

Is there a usable work-around while we try to figure this out?
- what happens if you remove "-fschedule-insns2" ?

You mentioned that "the way the program is called is not simple, it's a
Scheme->C compiler building a "module", so it's hidden behind a number of
scripts." 

I assume it is not some kind of JIT?

FWIW, I don't believe that there were Darwin-specific changes to scheduling and
insn output between 10.2 and 10.3, although it is possible that some other
change exposed a latent problem, of course.

Do you know if this failure persists with a trunk or 11 branch compiler?
(sorry for all the questions, but since I can't actually reproduce the runtime
fail yet)

[Bug target/94680] Missed optimization with __builtin_shuffle and zero vector

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
Let me do this.

[Bug libstdc++/100164] [11/12 Regression] semaphore_impl not declared on AIX

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

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

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

https://gcc.gnu.org/g:2d4c3af94f84c874cfddc753dc0f34ebf7fc11d9

commit r12-22-g2d4c3af94f84c874cfddc753dc0f34ebf7fc11d9
Author: Jakub Jelinek 
Date:   Wed Apr 21 11:09:25 2021 +0200

Fix AIX libstdc++ semaphore support [PR100164]

> > The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were
defined,
> > but it shows up in your error report.

> You now have pinpointed the problem.

> It's not that AIX doesn't have semaphore, but that the code previously
> had a fallback that hid a bug in the macros:

  // Use futex if available and didn't force use of POSIX
  using __fast_semaphore = __atomic_semaphore<__detail::__platform_wait_t>;
  using __fast_semaphore = __platform_semaphore;
  using __fast_semaphore = __atomic_semaphore;

> The problem is that libstdc++ configure defines
> _GLIBCXX_HAVE_POSIX_SEMAPHORE in config.h.  libstdc++ uses sed to
> rewrite config.h to c++config.h and prepends _GLIBCXX_, so c++config.h
> contains

> And bits/semaphore_base.h is not testing that corrupted macro.  Either
> semaphore_base.h needs to test for the corrupted macro, or libtsdc++
> configure needs to define HAVE_POSIX_SEMAPHORE without itself
> prepending _GLIBCXX_  so that the c++config.h rewriting works
> correctly and defines the correct macro for semaphore_base.h.

The include/Makefile.am sed is:
sed -e 's/HAVE_/_GLIBCXX_HAVE_/g' \
-e 's/PACKAGE/_GLIBCXX_PACKAGE/g' \
-e 's/VERSION/_GLIBCXX_VERSION/g' \
-e 's/WORDS_/_GLIBCXX_WORDS_/g' \
-e
's/_DARWIN_USE_64_BIT_INODE/_GLIBCXX_DARWIN_USE_64_BIT_INODE/g' \
-e 's/_FILE_OFFSET_BITS/_GLIBCXX_FILE_OFFSET_BITS/g' \
-e 's/_LARGE_FILES/_GLIBCXX_LARGE_FILES/g' \
-e 's/ICONV_CONST/_GLIBCXX_ICONV_CONST/g' \
-e '/[   ]_GLIBCXX_LONG_DOUBLE_COMPAT[   ]/d' \
-e '/[   ]_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT[]/d' \
< ${CONFIG_HEADER} >> $@ ;\
so for many macros one needs _GLIBCXX_ prefixes already in configure,
as can be seen in grep AC_DEFINE.*_GLIBCXX configure.ac acinclude.m4
But _GLIBCXX_HAVE_POSIX_SEMAPHORE is the only one that shouldn't have
that prefix because the sed is adding that.
E.g. on i686-linux, I see
grep _GLIBCXX__GLIBCXX c++config.h
that proves it is the only broken one.

So this change fixes the acinclude.m4 side.

2021-04-21  Jakub Jelinek  

PR libstdc++/100164
* acinclude.m4: For POSIX semaphores AC_DEFINE HAVE_POSIX_SEMAPHORE
rather than _GLIBCXX_HAVE_POSIX_SEMAPHORE.
* configure: Regenerated.
* config.h.in: Regenerated.

[Bug libstdc++/100164] [11/12 Regression] semaphore_impl not declared on AIX

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

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

--- Comment #12 from Jonathan Wakely  ---
(In reply to Jakub Jelinek from comment #5)
> The changelog said you want to use __thread_yield(); there instead...

Yes, that was fixed in r11-7293 (the patch attached in comment 3 was r11-7248).

[Bug libstdc++/100164] [11/12 Regression] semaphore_impl not declared on AIX

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

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

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

https://gcc.gnu.org/g:0857fc3820bee04771f60a86b9dd5627b3ea1904

commit r11-8270-g0857fc3820bee04771f60a86b9dd5627b3ea1904
Author: Jakub Jelinek 
Date:   Wed Apr 21 11:09:25 2021 +0200

Fix AIX libstdc++ semaphore support [PR100164]

> > The #error would not be hit if _GLIBCXX_HAVE_POSIX_SEMAPHORE were
defined,
> > but it shows up in your error report.

> You now have pinpointed the problem.

> It's not that AIX doesn't have semaphore, but that the code previously
> had a fallback that hid a bug in the macros:

  // Use futex if available and didn't force use of POSIX
  using __fast_semaphore = __atomic_semaphore<__detail::__platform_wait_t>;
  using __fast_semaphore = __platform_semaphore;
  using __fast_semaphore = __atomic_semaphore;

> The problem is that libstdc++ configure defines
> _GLIBCXX_HAVE_POSIX_SEMAPHORE in config.h.  libstdc++ uses sed to
> rewrite config.h to c++config.h and prepends _GLIBCXX_, so c++config.h
> contains

> And bits/semaphore_base.h is not testing that corrupted macro.  Either
> semaphore_base.h needs to test for the corrupted macro, or libtsdc++
> configure needs to define HAVE_POSIX_SEMAPHORE without itself
> prepending _GLIBCXX_  so that the c++config.h rewriting works
> correctly and defines the correct macro for semaphore_base.h.

The include/Makefile.am sed is:
sed -e 's/HAVE_/_GLIBCXX_HAVE_/g' \
-e 's/PACKAGE/_GLIBCXX_PACKAGE/g' \
-e 's/VERSION/_GLIBCXX_VERSION/g' \
-e 's/WORDS_/_GLIBCXX_WORDS_/g' \
-e
's/_DARWIN_USE_64_BIT_INODE/_GLIBCXX_DARWIN_USE_64_BIT_INODE/g' \
-e 's/_FILE_OFFSET_BITS/_GLIBCXX_FILE_OFFSET_BITS/g' \
-e 's/_LARGE_FILES/_GLIBCXX_LARGE_FILES/g' \
-e 's/ICONV_CONST/_GLIBCXX_ICONV_CONST/g' \
-e '/[   ]_GLIBCXX_LONG_DOUBLE_COMPAT[   ]/d' \
-e '/[   ]_GLIBCXX_LONG_DOUBLE_ALT128_COMPAT[]/d' \
< ${CONFIG_HEADER} >> $@ ;\
so for many macros one needs _GLIBCXX_ prefixes already in configure,
as can be seen in grep AC_DEFINE.*_GLIBCXX configure.ac acinclude.m4
But _GLIBCXX_HAVE_POSIX_SEMAPHORE is the only one that shouldn't have
that prefix because the sed is adding that.
E.g. on i686-linux, I see
grep _GLIBCXX__GLIBCXX c++config.h
that proves it is the only broken one.

So this change fixes the acinclude.m4 side.

2021-04-21  Jakub Jelinek  

PR libstdc++/100164
* acinclude.m4: For POSIX semaphores AC_DEFINE HAVE_POSIX_SEMAPHORE
rather than _GLIBCXX_HAVE_POSIX_SEMAPHORE.
* configure: Regenerated.
* config.h.in: Regenerated.

(cherry picked from commit 2d4c3af94f84c874cfddc753dc0f34ebf7fc11d9)

[Bug ada/99360] [11/12 regression] ICE in generalized iteration

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Eric Botcazou
:

https://gcc.gnu.org/g:53e85b38aaa10f5f8fe35eeea454a92c293cbc67

commit r11-8271-g53e85b38aaa10f5f8fe35eeea454a92c293cbc67
Author: Eric Botcazou 
Date:   Wed Apr 21 11:18:21 2021 +0200

Add stopgap fix for PR ada/99360

gcc/ada/
PR ada/99360
* exp_ch6.adb (Might_Have_Tasks): Return False when the type is the
class-wide type of a predefined iterator type.

[Bug ada/99360] [12 regression] ICE in generalized iteration

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

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|ASSIGNED|NEW
   Assignee|ebotcazou at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org
Summary|[11/12 regression] ICE in   |[12 regression] ICE in
   |generalized iteration   |generalized iteration

--- Comment #6 from Eric Botcazou  ---
To be properly fixed on the mainline.

[Bug other/100175] New: ICE in cp_parser_lookup_name, at cp/parser.c:28265

[mkaracsony81 at gmail dot com via Gcc-bugs]

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

Bug ID: 100175
   Summary: ICE in cp_parser_lookup_name, at cp/parser.c:28265
   Product: gcc
   Version: 10.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mkaracsony81 at gmail dot com
  Target Milestone: ---

I was unable to save the preprocessed source for this bug. I've tried but when
I re-run the command causing the error, the ICE was gone. I've hit this bug
twice so far, details are as follows:

command line which causes the error:
/sources/gcc-build/./prev-gcc/xg++ -B/sources/gcc-build/./prev-gcc/
-B/usr/x86_64-unknown-linux-gnu/bin/ -nostdinc++
-B/sources/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-B/sources/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs

-I/sources/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include/x86_64-unknown-linux-gnu
 -I/sources/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/include 
-I/sources/gcc-10.3.1-20210420/libstdc++-v3/libsupc++
-L/sources/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/sources/gcc-build/prev-x86_64-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-fno-PIE -c   -g0 -O2 -mtune=generic -flto=jobserver -frandom-seed=1
-flto=jobserver -frandom-seed=1 -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/sources/gcc-10.3.1-20210420/gcc -I/sources/gcc-10.3.1-20210420/gcc/.
-I/sources/gcc-10.3.1-20210420/gcc/../include
-I/sources/gcc-10.3.1-20210420/gcc/../libcpp/include 
-I/sources/gcc-10.3.1-20210420/gcc/../libdecnumber
-I/sources/gcc-10.3.1-20210420/gcc/../libdecnumber/bid -I../libdecnumber
-I/sources/gcc-10.3.1-20210420/gcc/../libbacktrace   -o lra-eliminations.o -MT
lra-eliminations.o -MMD -MP -MF ./.deps/lra-eliminations.TPo
/sources/gcc-10.3.1-20210420/gcc/lra-eliminations.c

error message:
In file included from /sources/gcc-10.3.1-20210420/gcc/lra-eliminations.c:59:
/sources/gcc-10.3.1-20210420/gcc/rtl.h:3448:33: internal compiler error: in
cp_parser_lookup_name, at cp/parser.c:28265
 3448 | extern int rtx_addr_can_trap_p (const_rtx);
  | ^
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
make[3]: *** [Makefile:1117: lra-eliminations.o] Error 1
make[3]: *** Waiting for unfinished jobs
make[2]: *** [Makefile:4946: all-stagetrain-gcc] Error 2
make[1]: *** [Makefile:22613: stagetrain-bubble] Error 2
make: *** [Makefile:22750: profiledbootstrap] Error 2

gcc was configured with:
./configure --prefix=/usr \
--libdir=/usr/lib \
--libexecdir=/usr/lib \
--mandir=/usr/share/man \
--infodir=/usr/share/info \
--enable-__cxa_atexit \
--enable-cet \
--enable-cld \
--enable-checking=release \
--enable-gnu-indirect-function \
--enable-gnu-unique-object \
--enable-initfini-array \
--enable-install-libiberty \
--enable-languages=c,c++,lto \
--enable-libgomp \
--enable-libstdcxx-time \
--enable-linker-build-id \
--enable-lto \
--enable-multilib \
--enable-plugin \
--enable-shared \
--enable-threads=posix \
--with-abi=m64 \
--with-arch=x86-64 \
--with-arch_32=x86-64 \
--with-build-config=bootstrap-lto \
--with-fpmath=sse \
--with-linker-hash-style=gnu \
--with-multilib-list=m64,m32 \
--with-system-zlib \
--with-tune=generic \
--with-zstd \
--without-isl \
--enable-libatomic \
--enable-libitm \
--enable-libquadmath \
--enable-libquadmath-support \
--enable-libsanitizer \
--disable-libada \
--disable-libmpx \
--

[Bug ipa/98815] Redundant free_dominance_info in cgraph_node::analyze()

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:021607e12cb9c40d0859b78490f44bb3f7da5812

commit r12-23-g021607e12cb9c40d0859b78490f44bb3f7da5812
Author: Martin Liska 
Date:   Tue Jan 26 12:55:52 2021 +0100

Test simlified call in cgraph_node::analyze().

gcc/ChangeLog:

PR ipa/98815
* cgraphunit.c (cgraph_node::analyze): Remove duplicate
free_dominance_info calls.

[Bug ipa/98815] Redundant free_dominance_info in cgraph_node::analyze()

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #6 from Martin Liška  ---
Fixed.

[Bug testsuite/100176] New: gcc.dg/compat/struct-layout-1_generate.c contains errors

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

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

Bug ID: 100176
   Summary: gcc.dg/compat/struct-layout-1_generate.c contains
errors
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

When GCC is configured with

CFLAGS='-O2 -D_FORTIFY_SOURCE=2 -funwind-tables -fasynchronous-unwind
-tables -fstack-clash-protection -Werror=return-type -g -U_FORTIFY_SOURCE'

then testing runs into

^[[01m^[[K/home/abuild/rpmbuild/BUILD/gcc-11.0.1+git10/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c:^[[m^[[K
In function '^[[01m^[[Ksubvalues^[[m^[[K':^M
^[[01m^[[K/home/abuild/rpmbuild/BUILD/gcc-11.0.1+git10/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c:1284:1:^[[m^[[K
^[[01;31m^[[Kerror: ^[[m^[[Kcontrol reaches end of non-void function
[^[[01;31m^[[K^[]8;;https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wreturn-type^G-Werror=return-type^[]8;;^G^[[m^[[K]^M
 1284 | ^[[01;31m^[[K}^[[m^[[K^M
  | ^[[01;31m^[[K^^[[m^[[K^M
cc1: some warnings being treated as errors^M
WARNING: Could not compile gcc.dg/compat/struct-layout-1 generator

a possible untested fix is

diff --git a/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c
b/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c
index 75e902cd1f4..4f7ab884287 100644
--- a/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c
+++ b/gcc/testsuite/gcc.dg/compat/struct-layout-1_generate.c
@@ -1281,6 +1281,7 @@ subvalues (struct entry *e, char *p, char *letter)
output_FNB ('B', e);
   return 1;
 }
+  return 0;
 }

 /* DERIVED FROM:

[Bug testsuite/100176] gcc.dg/compat/struct-layout-1_generate.c contains errors

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
I'd maybe instead add default: return 0; to the switch instead, but otherwise
LGTM.

[Bug fortran/100136] [11/12 Regression] ICE, regression, using flag -fcheck=pointer

[jrfsousa at gmail dot com via Gcc-bugs]

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

--- Comment #3 from José Rui Faustino de Sousa  ---
Only handles the ICE...

Patch posted:

https://gcc.gnu.org/pipermail/fortran/2021-April/055949.html

[Bug rtl-optimization/100148] [10/11/12 Regression] -fcompare-debug failure (length) with -O2 -fno-dce -fno-tree-dce -fno-tree-dominator-opts -fno-tree-sink

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

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

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

https://gcc.gnu.org/g:022f6ee3ad67ee30f62c8c2aeeb4156494f3284e

commit r12-24-g022f6ee3ad67ee30f62c8c2aeeb4156494f3284e
Author: Jakub Jelinek 
Date:   Wed Apr 21 12:31:45 2021 +0200

cprop: Fix -fcompare-debug bug in constprop_register [PR100148]

The following testcase shows different behavior between -g and -g0
in constprop_register, if a flags register setter is separated
from a conditional jump using those flags with -g by a DEBUG_INSN.
As it uses just NEXT_INSN, for -g it will look at the DEBUG_INSN which is
not a conditional jump, while otherwise it would look at the conditional
jump and call cprop_jump.

2021-04-21  Jakub Jelinek  

PR rtl-optimization/100148
* cprop.c (constprop_register): Use next_nondebug_insn instead of
NEXT_INSN.

* g++.dg/opt/pr100148.C: New test.

[Bug rtl-optimization/100148] [10/11/12 Regression] -fcompare-debug failure (length) with -O2 -fno-dce -fno-tree-dce -fno-tree-dominator-opts -fno-tree-sink

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

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

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

https://gcc.gnu.org/g:63353b2aebd2cf171ee8aa747b2dc84f5534de6b

commit r10-9741-g63353b2aebd2cf171ee8aa747b2dc84f5534de6b
Author: Jakub Jelinek 
Date:   Wed Apr 21 12:31:45 2021 +0200

cprop: Fix -fcompare-debug bug in constprop_register [PR100148]

The following testcase shows different behavior between -g and -g0
in constprop_register, if a flags register setter is separated
from a conditional jump using those flags with -g by a DEBUG_INSN.
As it uses just NEXT_INSN, for -g it will look at the DEBUG_INSN which is
not a conditional jump, while otherwise it would look at the conditional
jump and call cprop_jump.

2021-04-21  Jakub Jelinek  

PR rtl-optimization/100148
* cprop.c (constprop_register): Use next_nondebug_insn instead of
NEXT_INSN.

* g++.dg/opt/pr100148.C: New test.

(cherry picked from commit 022f6ee3ad67ee30f62c8c2aeeb4156494f3284e)

[Bug rtl-optimization/100148] [11 Regression] -fcompare-debug failure (length) with -O2 -fno-dce -fno-tree-dce -fno-tree-dominator-opts -fno-tree-sink

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

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[10/11/12 Regression]   |[11 Regression]
   |-fcompare-debug failure |-fcompare-debug failure
   |(length) with -O2 -fno-dce  |(length) with -O2 -fno-dce
   |-fno-tree-dce   |-fno-tree-dce
   |-fno-tree-dominator-opts|-fno-tree-dominator-opts
   |-fno-tree-sink  |-fno-tree-sink

--- Comment #6 from Jakub Jelinek  ---
Fixed on trunk and for 10.4 so far, queued for 11.2.

[Bug testsuite/100176] gcc.dg/compat/struct-layout-1_generate.c contains errors

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r12-25-gd8f953819e8f72e646f22c7803d79bd2b56d1e30
Author: Richard Biener 
Date:   Wed Apr 21 12:46:51 2021 +0200

testsuite/100176 - fix struct-layout-1_generate.c compile

With -Werror=return-type we run into compile fails complaining about
missing return stmts.

2021-04-21  Richard Biener  

PR testsuite/100176
* g++.dg/compat/struct-layout-1_generate.c: Add missing return.
* gcc.dg/compat/struct-layout-1_generate.c: Likewise.

[Bug testsuite/100176] gcc.dg/compat/struct-layout-1_generate.c contains errors

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:89ddb58cda7b4a54626170f9491fc2a0f82d85f5

commit r11-8272-g89ddb58cda7b4a54626170f9491fc2a0f82d85f5
Author: Richard Biener 
Date:   Wed Apr 21 12:46:51 2021 +0200

testsuite/100176 - fix struct-layout-1_generate.c compile

With -Werror=return-type we run into compile fails complaining about
missing return stmts.

2021-04-21  Richard Biener  

PR testsuite/100176
* g++.dg/compat/struct-layout-1_generate.c: Add missing return.
* gcc.dg/compat/struct-layout-1_generate.c: Likewise.

(cherry picked from commit d8f953819e8f72e646f22c7803d79bd2b56d1e30)

[Bug testsuite/100176] gcc.dg/compat/struct-layout-1_generate.c contains errors

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

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

--- Comment #4 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:525c2634c1f945072eaa14b6d264b1904b6f81ea

commit r10-9742-g525c2634c1f945072eaa14b6d264b1904b6f81ea
Author: Richard Biener 
Date:   Wed Apr 21 12:46:51 2021 +0200

testsuite/100176 - fix struct-layout-1_generate.c compile

With -Werror=return-type we run into compile fails complaining about
missing return stmts.

2021-04-21  Richard Biener  

PR testsuite/100176
* g++.dg/compat/struct-layout-1_generate.c: Add missing return.
* gcc.dg/compat/struct-layout-1_generate.c: Likewise.

(cherry picked from commit d8f953819e8f72e646f22c7803d79bd2b56d1e30)

[Bug testsuite/100176] gcc.dg/compat/struct-layout-1_generate.c contains errors

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

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

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Richard Biener
:

https://gcc.gnu.org/g:56e4a73c7fbe6d436f765fec7b0a6af76733c428

commit r9-9452-g56e4a73c7fbe6d436f765fec7b0a6af76733c428
Author: Richard Biener 
Date:   Wed Apr 21 12:46:51 2021 +0200

testsuite/100176 - fix struct-layout-1_generate.c compile

With -Werror=return-type we run into compile fails complaining about
missing return stmts.

2021-04-21  Richard Biener  

PR testsuite/100176
* g++.dg/compat/struct-layout-1_generate.c: Add missing return.
* gcc.dg/compat/struct-layout-1_generate.c: Likewise.

(cherry picked from commit d8f953819e8f72e646f22c7803d79bd2b56d1e30)

[Bug testsuite/100176] gcc.dg/compat/struct-layout-1_generate.c contains errors

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #7 from Richard Biener  ---
Fixed.

[Bug testsuite/100176] gcc.dg/compat/struct-layout-1_generate.c contains errors

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Richard Biener
:

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

commit r8-10854-ge4053fb7beb551794cfba43c7a9623c43eb3e808
Author: Richard Biener 
Date:   Wed Apr 21 12:46:51 2021 +0200

testsuite/100176 - fix struct-layout-1_generate.c compile

With -Werror=return-type we run into compile fails complaining about
missing return stmts.

2021-04-21  Richard Biener  

PR testsuite/100176
* g++.dg/compat/struct-layout-1_generate.c: Add missing return.
* gcc.dg/compat/struct-layout-1_generate.c: Likewise.

(cherry picked from commit d8f953819e8f72e646f22c7803d79bd2b56d1e30)

[Bug demangler/100177] New: Rust demangler tests fail on big-endian hosts

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

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

Bug ID: 100177
   Summary: Rust demangler tests fail on big-endian hosts
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: demangler
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nickc at gcc dot gnu.org
  Target Milestone: ---

The rust portion of the libiberty testsuite fails when run on a big-endian
host:

  ./test-demangle < ./libiberty/testsuite/rust-demangle-expected
  FAIL at line 222, options --format=rust:
  in:  _RMCs4fqI2P2rA04_13const_genericINtB0_4CharKc76_E
  out: >
  FAIL at line 285, options --format=auto:
  in:  _RMCs4fqI2P2rA04_13const_genericINtB0_4CharKc76_E
  out: >
  ./test-demangle: 68 tests, 2 failures

The same failures do not happen when the tests are run on a little endian host.

This problem appears to have existed for at least a few months and was recently
reported on the binutils bugzilla system:

  https://sourceware.org/bugzilla/show_bug.cgi?id=27751

[Bug demangler/100177] Rust demangler tests fail on big-endian hosts

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
https://gcc.gnu.org/pipermail/gcc-patches/2021-April/568314.html

[Bug demangler/100177] Rust demangler tests fail on big-endian hosts

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Andreas Schwab :

https://gcc.gnu.org/g:53bc2e123cd44dc26ae3d2c42b85ee2463f2a7c6

commit r12-28-g53bc2e123cd44dc26ae3d2c42b85ee2463f2a7c6
Author: Andreas Schwab 
Date:   Tue Apr 20 17:30:46 2021 +0200

Fix endian bug in rust demangler

libiberty/
PR demangler/100177
* rust-demangle.c (demangle_const_char): Properly print the
character value.

[Bug demangler/100177] Rust demangler tests fail on big-endian hosts

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Andreas Schwab
:

https://gcc.gnu.org/g:4cdb510fb0d4e285b0565f402883025998ba6250

commit r11-8273-g4cdb510fb0d4e285b0565f402883025998ba6250
Author: Andreas Schwab 
Date:   Tue Apr 20 17:30:46 2021 +0200

Fix endian bug in rust demangler

libiberty/
PR demangler/100177
* rust-demangle.c (demangle_const_char): Properly print the
character value.

[Bug demangler/100177] Rust demangler tests fail on big-endian hosts

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #4 from Andreas Schwab  ---
Fixed.

[Bug c/100178] New: Should the “short” be promoted to “int” when use inline asm？

[gengqi at linux dot alibaba.com via Gcc-bugs]

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

Bug ID: 100178
   Summary: Should the “short” be promoted to “int” when use
inline asm？
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gengqi at linux dot alibaba.com
  Target Milestone: ---

When use inline asm:

short MAX16_s(short *a, short *b)
{
  short __result;
  __asm__(
  "maxw %0, %1, %2"
  : "=r"(__result)
  : "r"(*a), "r"(*b)
  );
  return __result;
}

It's expected to generate 'lh'(sign extend), but 'lhu' (zero extend) actually.

The same situation with the use of explicit conversions would not make this
mess.
Like this:

short MAX16_s(short *a, short *b)
{
  short __result;
  __asm__(
  "maxw %0, %1, %2"
  : "=r"(__result)
  : "r"((int)*a), "r"((int)*b)
  );
  return __result;
}

I think the latter implementation is exact, while the first one is ambiguous
that it shouldn't be expected to generate 'lh'.
But my friends think the first one should be treat as well, and it does seem to
make some sense.

I have also read the reference manuals
（https://gcc.gnu.org/onlinedocs/gcc/Extended-Asm.html），
but can find no basis for this.

Should this be treated as a bug? Or may be we should describe this situation
clearly in the documentation.

[Bug libstdc++/100179] New: [12 regression] xtreme-header-2_a.H fails on arm-eabi

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

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

Bug ID: 100179
   Summary: [12 regression] xtreme-header-2_a.H fails on arm-eabi
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

Between r11-8253 and r12-12, I've noticed new failures on arm-eabi (using
newlib)
g++.dg/modules/xtreme-header-2_a.H -std=c++2a (test for excess errors)
g++.dg/modules/xtreme-header-2_a.H -std=c++2b (test for excess errors)
g++.dg/modules/xtreme-header-2_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-2_a.H.gcm)
g++.dg/modules/xtreme-header-2_b.C -std=c++2a (test for excess errors)
g++.dg/modules/xtreme-header-2_b.C -std=c++2b (test for excess errors)
g++.dg/modules/xtreme-header-2_c.C -std=c++2a (test for excess errors)
g++.dg/modules/xtreme-header-2_c.C -std=c++2b (test for excess errors)
g++.dg/modules/xtreme-header-5_a.H -std=c++2a (test for excess errors)
g++.dg/modules/xtreme-header-5_a.H -std=c++2b (test for excess errors)
g++.dg/modules/xtreme-header-5_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-5_a.H.gcm)
g++.dg/modules/xtreme-header-5_b.C -std=c++2a (test for excess errors)
g++.dg/modules/xtreme-header-5_b.C -std=c++2b (test for excess errors)
g++.dg/modules/xtreme-header-5_c.C -std=c++2a (test for excess errors)
g++.dg/modules/xtreme-header-5_c.C -std=c++2b (test for excess errors)
g++.dg/modules/xtreme-header-6_a.H -std=c++2a (test for excess errors)
g++.dg/modules/xtreme-header-6_a.H -std=c++2b (test for excess errors)
g++.dg/modules/xtreme-header-6_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header-6_a.H.gcm)
g++.dg/modules/xtreme-header-6_b.C -std=c++2a (test for excess errors)
g++.dg/modules/xtreme-header-6_b.C -std=c++2b (test for excess errors)
g++.dg/modules/xtreme-header-6_c.C -std=c++2a (test for excess errors)
g++.dg/modules/xtreme-header-6_c.C -std=c++2b (test for excess errors)
g++.dg/modules/xtreme-header_a.H -std=c++2a (test for excess errors)
g++.dg/modules/xtreme-header_a.H -std=c++2b (test for excess errors)
g++.dg/modules/xtreme-header_a.H module-cmi 
(gcm.cache/$srcdir/g++.dg/modules/xtreme-header_a.H.gcm)
g++.dg/modules/xtreme-header_b.C -std=c++2a (test for excess errors)
g++.dg/modules/xtreme-header_b.C -std=c++2b (test for excess errors)


g++.log says:
FAIL: g++.dg/modules/xtreme-header-2_a.H -std=c++2a (test for excess errors)
Excess errors:
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/bits/semaphore_base.h:259:4:
error: #error "No suitable semaphore implementation available"
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:43:42:
error: '__semaphore_impl' has not been declared
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:47:42:
error: '__semaphore_impl' has not been declared
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:49:7:
error: '__semaphore_impl' does not name a type
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:66:57:
error: '_M_sem' was not declared in this scope
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:70:35:
error: '_M_sem' was not declared in this scope
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:74:39:
error: '_M_sem' was not declared in this scope
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:53:11:
error: class 'std::counting_semaphore<__least_max_value>' does not have any
field named '_M_sem'
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:67:9:
error: '_M_sem' was not declared in this scope
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:71:9:
error: '_M_sem' was not declared in this scope
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:75:16:
error: '_M_sem' was not declared in this scope
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:80:18:
error: '_M_sem' was not declared in this scope
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/semaphore:85:18:
error: '_M_sem' was not declared in this scope
/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H: warning: not writing module
'/gcc/testsuite/g++.dg/modules/xtreme-header-2_a.H' due to errors

[Bug analyzer/98447] incorrect -Wanalyzer-shift-count-overflow warning

[vincent-gcc at vinc17 dot net via Gcc-bugs]

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

--- Comment #6 from Vincent Lefèvre  ---
On the test on godbolt, this is still failing with:
gcc (Compiler-Explorer-Build) 12.0.0 20210420 (experimental)

[Bug libstdc++/100179] [12 regression] xtreme-header-2_a.H fails on arm-eabi

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

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

--- Comment #1 from Christophe Lyon  ---
Similar errors noticed in libstdc++ testsuite:
17_intro/headers/c++2020/all_attributes.cc (test for excess errors)
17_intro/headers/c++2020/all_no_exceptions.cc (test for excess errors)
17_intro/headers/c++2020/all_no_rtti.cc (test for excess errors)
17_intro/headers/c++2020/all_pedantic_errors.cc (test for excess errors)
17_intro/headers/c++2020/operator_names.cc (test for excess errors)
17_intro/headers/c++2020/stdc++.cc (test for excess errors)
17_intro/headers/c++2020/stdc++_multiple_inclusion.cc (test for excess
errors)
20_util/polymorphic_allocator/allocate_object.cc (test for excess errors)
20_util/polymorphic_allocator/construct_c++2a.cc (test for excess errors)
20_util/polymorphic_allocator/lwg3237.cc (test for excess errors)
20_util/scoped_allocator/construct_pair_c++2a.cc (test for excess errors)
20_util/uses_allocator/make_obj.cc (test for excess errors)
21_strings/basic_string/hash/hash_char8_t.cc (test for excess errors)
24_iterators/normal_iterator/cmp_c++20.cc (test for excess errors)
27_io/basic_istringstream/cons/char/1.cc (test for excess errors)
27_io/basic_istringstream/cons/wchar_t/1.cc (test for excess errors)
27_io/basic_istringstream/str/char/2.cc (test for excess errors)
27_io/basic_istringstream/str/wchar_t/2.cc (test for excess errors)
27_io/basic_ostringstream/cons/char/1.cc (test for excess errors)
27_io/basic_ostringstream/cons/wchar_t/1.cc (test for excess errors)
27_io/basic_ostringstream/str/char/3.cc (test for excess errors)
27_io/basic_ostringstream/str/wchar_t/3.cc (test for excess errors)
27_io/basic_stringbuf/cons/char/2.cc (test for excess errors)
27_io/basic_stringbuf/cons/wchar_t/2.cc (test for excess errors)
27_io/basic_stringbuf/str/char/4.cc (test for excess errors)
27_io/basic_stringbuf/str/wchar_t/4.cc (test for excess errors)
27_io/basic_stringstream/cons/char/1.cc (test for excess errors)
27_io/basic_stringstream/cons/wchar_t/1.cc (test for excess errors)
27_io/basic_stringstream/str/char/5.cc (test for excess errors)
27_io/basic_stringstream/str/wchar_t/5.cc.cc (test for excess errors)
27_io/basic_syncbuf/basic_ops/1.cc (test for excess errors)
27_io/basic_syncstream/basic_ops/1.cc (test for excess errors)

[Bug libstdc++/100180] New: experimental/net/internet/address/v6/members.cc fails on arm-eabi

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

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

Bug ID: 100180
   Summary: experimental/net/internet/address/v6/members.cc fails
on arm-eabi
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: clyon at gcc dot gnu.org
  Target Milestone: ---

The new test experimental/net/internet/address/v6/members.cc fails on arm-eabi
(using newlib).

On gcc-9, I'm seeing these errors in the logs:
FAIL: experimental/net/internet/address/v6/members.cc (test for excess errors)
Excess errors:
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/experimental/executor:509:
error: 'mutex' in namespace 'std' does not name a type
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/experimental/executor:556:
error: 'mutex' is not a member of 'std'
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/experimental/executor:556:
error: 'mutex' is not a member of 'std'
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/experimental/executor:556:
error: template argument 1 is invalid
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/libstdc++-v3/include/experimental/executor:556:
error: 'class std::experimental::net::v1::execution_context' has no member
named '_M_mutex'
[...]

I think I saw similar errors on trunk a few days ago, but didn't have time to
report them earlier.

[Bug libstdc++/99995] [11/12 Regression] should not include in c++20 mode

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

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

--- Comment #3 from Jonathan Wakely  ---
Similarly,  unconditionally includes POSIX  even if
we're not going to use it.

[Bug c++/88115] Incorrect result from alignof in templates, if also using __alignof__.

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Patrick Palka
:

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

commit r8-10855-ga34c19926b87f9cadd5ea84f5c5b93ae76b14558
Author: Patrick Palka 
Date:   Wed Oct 7 10:49:00 2020 -0400

c++: Distinguish alignof and __alignof__ in cp_tree_equal [PR97273]

cp_tree_equal currently considers alignof the same as __alignof__, but
these operators are semantically different ever since r8-7957.  In the
testcase below, this causes the second static_assert to fail on targets
where alignof(double) != __alignof__(double) because the specialization
table (which uses cp_tree_equal as its equality predicate) conflates the
two dependent specializations integral_constant<__alignof__(T)> and
integral_constant.

This patch makes cp_tree_equal distinguish between these two operators
by inspecting the ALIGNOF_EXPR_STD_P flag.

gcc/cp/ChangeLog:

PR c++/88115
PR libstdc++/97273
* tree.c (cp_tree_equal) : Return false if
ALIGNOF_EXPR_STD_P differ.

gcc/testsuite/ChangeLog:

PR c++/88115
PR libstdc++/97273
* g++.dg/template/alignof3.C: New test.

(cherry picked from commit 592fe221735bdaa375b1834dd49ce125d0b600d8)

[Bug libstdc++/97273] [8/9 Regression] Strange behaviour of unordered_set when vector is included (i686)

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Patrick Palka
:

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

commit r8-10855-ga34c19926b87f9cadd5ea84f5c5b93ae76b14558
Author: Patrick Palka 
Date:   Wed Oct 7 10:49:00 2020 -0400

c++: Distinguish alignof and __alignof__ in cp_tree_equal [PR97273]

cp_tree_equal currently considers alignof the same as __alignof__, but
these operators are semantically different ever since r8-7957.  In the
testcase below, this causes the second static_assert to fail on targets
where alignof(double) != __alignof__(double) because the specialization
table (which uses cp_tree_equal as its equality predicate) conflates the
two dependent specializations integral_constant<__alignof__(T)> and
integral_constant.

This patch makes cp_tree_equal distinguish between these two operators
by inspecting the ALIGNOF_EXPR_STD_P flag.

gcc/cp/ChangeLog:

PR c++/88115
PR libstdc++/97273
* tree.c (cp_tree_equal) : Return false if
ALIGNOF_EXPR_STD_P differ.

gcc/testsuite/ChangeLog:

PR c++/88115
PR libstdc++/97273
* g++.dg/template/alignof3.C: New test.

(cherry picked from commit 592fe221735bdaa375b1834dd49ce125d0b600d8)

[Bug libstdc++/97273] [8/9 Regression] Strange behaviour of unordered_set when vector is included (i686)

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #9 from Patrick Palka  ---
Fixed.

[Bug c++/88115] Incorrect result from alignof in templates, if also using __alignof__.

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |8.5

--- Comment #14 from Patrick Palka  ---
Fixed.

[Bug target/100181] New: hot-cold partitioned code doesn't assemble

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

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

Bug ID: 100181
   Summary: hot-cold partitioned code doesn't assemble
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

I see lots of libgomp fails with offloading for amdgcn like

./pr93515.xamdgcn-amdhsa.mkoffload.2.s:634:2: error: undefined label '.L33'
s_branch.L33
^
mkoffload: fatal error: /usr/bin//x86_64-suse-linux-accel-amdgcn-amdhsa-gcc-11
returned 1 exit status

which is because we compile to

s_branch.L33
.section.text.unlikely
.type   main._omp_fn.4.cold, @function
main._omp_fn.4.cold:
.L33:
s_getpc_b64 s[2:3]
s_add_u32   s2, s2, abort@rel32@lo+4
s_addc_u32  s3, s3, abort@rel32@hi+4
s_swappc_b64s[18:19], s[2:3]
.text

and thus have a section crossing jump using a local label.  The amdgcn
assembler
I'm using doesn't like this, it is

> amdgcn-amdhsa-as --version
LLVM (http://llvm.org/):
  LLVM version 11.0.1
  Optimized build.
  Default target: x86_64-unknown-linux-gnu
  Host CPU: znver2

[Bug target/100181] hot-cold partitioned code doesn't assemble

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||assemble-failure
 Target||gcn

--- Comment #1 from Richard Biener  ---
Example testcases that fail this way include

libgomp.c/../libgomp.c-c++-common/pr93515.c
libgomp.c/pr86660.c
libgomp.c/target-3.c
libgomp.c/target-4.c
libgomp.c/target-5.c
...

and more.  Altering -freorder-blocks-and-partition for amdgcn might be a
possible fix but might also be "interesting" to achieve (it's stuck in the
optimization node of each function).

[Bug target/100181] hot-cold partitioned code doesn't assemble

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

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

--- Comment #2 from Richard Biener  ---
Created attachment 50648
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50648&action=edit
example assembly file

Example file that fails to assemble.

[Bug c++/64194] [C++14] for function template with auto return

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

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

--- Comment #19 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:9499fe0403e310f4eb1f23279bff84259e120e76

commit r9-9453-g9499fe0403e310f4eb1f23279bff84259e120e76
Author: Patrick Palka 
Date:   Wed Jul 29 22:06:44 2020 -0400

c++: overload sets and placeholder return type [PR64194]

In the testcase below, template argument deduction for the call
g(id) goes wrong because the functions in the overload set id
each have a yet-undeduced auto return type, and this undeduced return
type makes try_one_overload fail to match up any of the overloads with
g's parameter type, leading to g's template argument going undeduced and
to the overload set going unresolved.

This patch fixes this issue by performing return type deduction via
instantiation before doing try_one_overload, in a manner similar to what
resolve_address_of_overloaded_function does.

gcc/cp/ChangeLog:

PR c++/64194
* pt.c (resolve_overloaded_unification): If the function
template specialization has a placeholder return type,
then instantiate it before attempting unification.

gcc/testsuite/ChangeLog:

PR c++/64194
* g++.dg/cpp1y/auto-fn60.C: New test.

(cherry picked from commit 2c58f5cadfac338a67723fd6e41c9097760c4a33)

[Bug target/100181] hot-cold partitioned code doesn't assemble

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

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

--- Comment #3 from Richard Biener  ---
llvm-mc from llvm 9.0.1 ICEs:

> llvm-mc-9.0.1 -o t.o pr93515.xamdgcn-amdhsa.mkoffload.2.s 
> -triple=amdgcn--amdhsa -mcpu=fiji -filetype=obj
Stack dump:
0.  Program arguments: llvm-mc-9.0.1 -o t.o
pr93515.xamdgcn-amdhsa.mkoffload.2.s -triple=amdgcn--amdhsa -mcpu=fiji
-filetype=obj 
#0 0x73d9e17d llvm::sys::PrintStackTrace(llvm::raw_ostream&)
(/usr/bin/../lib64/libLLVM.so.9+0xa9b17d)
#1 0x73d9bc30 llvm::sys::RunSignalHandlers()
(/usr/bin/../lib64/libLLVM.so.9+0xa98c30)
#2 0x73d9e5a4 (/usr/bin/../lib64/libLLVM.so.9+0xa9b5a4)
#3 0x72baa4a0 __restore_rt (/lib64/libc.so.6+0x394a0)
#4 0x757fe353
llvm::AMDGPUInstPrinter::printOperandAndFPInputMods(llvm::MCInst const*,
unsigned int, llvm::MCSubtargetInfo const&, llvm::raw_ostream&)
(/usr/bin/../lib64/libLLVM.so.9+0x24fb353)
#5 0x757f1a6f llvm::AMDGPUInstPrinter::printInstruction(llvm::MCInst
const*, llvm::MCSubtargetInfo const&, llvm::raw_ostream&)
(/usr/bin/../lib64/libLLVM.so.9+0x24eea6f)
#6 0x00480c60 
Segmentation fault (core dumped)

[Bug target/100181] hot-cold partitioned code doesn't assemble

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

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

Richard Biener  changed:

   What|Removed |Added

 Depends on||94278

--- Comment #4 from Richard Biener  ---
Ah, looks like a duplicate of PR94278 then.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94278
[Bug 94278] [amdgcn] Offloading build failures due to 'llvm-mc' SIGSEGV

[Bug target/100181] hot-cold partitioned code doesn't assemble

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

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

Thomas Schwinge  changed:

   What|Removed |Added

   Keywords|assemble-failure|
 Depends on|94278   |
 CC||ams at gcc dot gnu.org,
   ||burnus at gcc dot gnu.org,
   ||jules at gcc dot gnu.org,
   ||tschwinge at gcc dot gnu.org

--- Comment #5 from Thomas Schwinge  ---
Isn't that a duplicate of what I once filed as PR94278 "[amdgcn] Offloading
build failures due to 'llvm-mc' SIGSEGV" -- with "improved error reporting":
error diagnostic instead of SIGSEGV?

PR94278 includes a patch that I've locally been using ever since, but Andrew
has not been able to reproduce that problem.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94278
[Bug 94278] [amdgcn] Offloading build failures due to 'llvm-mc' SIGSEGV

[Bug target/94278] [amdgcn] Offloading build failures due to 'llvm-mc' SIGSEGV

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

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

--- Comment #5 from Richard Biener  ---
I'm running into the same issue (and filed PR100181) but with llvm11 based
llvm-mc the CUs are instead rejected due to a section crossing jump:

./pr93515.xamdgcn-amdhsa.mkoffload.2.s:634:2: error: undefined label '.L33'
s_branch.L33
^
mkoffload: fatal error: /usr/bin//x86_64-suse-linux-accel-amdgcn-amdhsa-gcc-11
returned 1 exit status

s_branch.L33
.section.text.unlikely
.type   main._omp_fn.4.cold, @function
main._omp_fn.4.cold:
.L33:
s_getpc_b64 s[2:3]
s_add_u32   s2, s2, abort@rel32@lo+4
s_addc_u32  s3, s3, abort@rel32@hi+4
s_swappc_b64s[18:19], s[2:3]
.text

[Bug target/100181] hot-cold partitioned code doesn't assemble

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #6 from Richard Biener  ---
Yes.  I'm giving the patch a try.

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

[Bug target/94278] [amdgcn] Offloading build failures due to 'llvm-mc' SIGSEGV

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

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

--- Comment #6 from Richard Biener  ---
*** Bug 100181 has been marked as a duplicate of this bug. ***

[Bug target/100182] New: [8/9/10/11/12 Regression] Miscompilation of atomic_float/1.cc on i686

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

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

Bug ID: 100182
   Summary: [8/9/10/11/12 Regression] Miscompilation of
atomic_float/1.cc on i686
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jakub at gcc dot gnu.org
  Target Milestone: ---

Since r7-1112-gbeed3701c796842abbfb27d7484b35bd82818740
the following testcase distilled from 29_atomics/atomic_float/1.cc with -O2
-march=i686 -m32 aborts on i686-linux:
struct __attribute__((aligned (8))) S { double _M_fp; };
union U { double d; unsigned long long int l; };

__attribute__((noipa)) void
foo (void)
{
  struct S a0, a1;
  union U u;
  double d0, d1;
  a0._M_fp = 0.0;
  a1._M_fp = 1.0;
  __atomic_store_8 (&a0._M_fp, __atomic_load_8 (&a1._M_fp, __ATOMIC_SEQ_CST),
__ATOMIC_SEQ_CST);
  u.l = __atomic_load_8 (&a0._M_fp, __ATOMIC_SEQ_CST);
  d0 = u.d;
  u.l = __atomic_load_8 (&a1._M_fp, __ATOMIC_SEQ_CST);
  d1 = u.d;
  if (d0 != d1)
__builtin_abort ();
}

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

[Bug target/100182] [8/9/10/11/12 Regression] Miscompilation of atomic_float/1.cc on i686

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

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

Jakub Jelinek  changed:

   What|Removed |Added

   Last reconfirmed||2021-04-21
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Priority|P3  |P2
   Target Milestone|--- |8.5
 Status|UNCONFIRMED |ASSIGNED

[Bug target/100181] hot-cold partitioned code doesn't assemble

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

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

--- Comment #7 from Tobias Burnus  ---
I can reproduce this one with LLVM trunk when compiled with '-save-temps -O2'
and then

llvm-mc --triple=amdgcn--amdhsa -mcpu=fiji -filetype=obj
--amdhsa-code-object-version=3 a.xamdgcn-amdhsa.mkoffload.1.s -o foo.o

a.xamdgcn-amdhsa.mkoffload.1.s:634:2: error: undefined label '.L33'

Removing the '.unlikely' from the .section name fixes this (or using -O1).
(I could not reproduce the LLVM 9 issue in PR94278 back then.)

[Bug target/100181] hot-cold partitioned code doesn't assemble

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

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

--- Comment #8 from Thomas Schwinge  ---
(In reply to Tobias Burnus from comment #7)
> (I could not reproduce the LLVM 9 issue in PR94278 back then.)

Hmm, but didn't you say in the LLVM issue
 (liked to in _See Also_ in
PR94278) that you _did_ reproduce this back then?  (Just making sure that it's
not actually a different issue that we're discussing now?)

[Bug target/95816] Aarch64 jumps between Hot/Cold sections does not clobber registers x16/x17

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

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

--- Comment #2 from Richard Earnshaw  ---
(In reply to Andrew Pinski from comment #1)
> Confirmed, I wonder if x16 and x17 should not be considered as temps alive
> across all jumps in aarch64 really; not just jumps between hot and cold
> sections ...

The ABI says that the linker can only insert long-branch veneers if the target
symbol is of type STT_FUNC, and gcc's local symbols are all untyped.

[Bug target/95816] Aarch64 jumps between Hot/Cold sections does not clobber registers x16/x17

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

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

--- Comment #3 from Richard Earnshaw  ---
The best thing to do for now is to disable hot/cold partitioning, as we do on
Arm.

[Bug libstdc++/86742] Documented function std::to_chars(char* first, char* last, double value) is not implemented

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=100146
 Resolution|--- |FIXED

--- Comment #3 from Patrick Palka  ---
Implemented for GCC 11 in r11-6249.

[Bug target/94278] [amdgcn] Offloading build failures due to 'llvm-mc' SIGSEGV

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

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

--- Comment #7 from Richard Biener  ---
If people can/cannot reproduce the issue with the same revs. on the same
testcase double-checking the RTL bb-reorder dumps might be in order to rule out
some
memory corruption on the BB counts.

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

[lucier at math dot purdue.edu via Gcc-bugs]

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

--- Comment #16 from lucier at math dot purdue.edu ---
I have figured out how to build and then run the app in lldb to reliably
reproduce the error.

To configure and build Gambit, the Scheme->C compiler:

51  8:56mkdir gambit-test
52  8:56cd gambit-test
53  8:56git clone https://github.com/gambit/gambit.git
54  8:57cd gambit
55  9:00./configure 'CC=/usr/local/gcc-10.3.0/bin/gcc -save-temps -g'
'--enable-single-host' '--enable-shared'
56  9:01make -j12

After a few minutes the "make -j12" should end with the message:

*** to compile the builtin modules you should: make modules

Then in the same directory I ran a command to just print the version number and
configuration information of Gambit; I ran the interpreter gsi instead of the
compiler gsc:

[Bradleys-Mac-mini:~/programs/gambit-test/gambit] lucier% lldb gsi/gsi
(lldb) target create "gsi/gsi"
Current executable set to '/Users/lucier/programs/gambit-test/gambit/gsi/gsi'
(x86_64).
(lldb) process launch -v DYLD_LIBRARY_PATH=./lib:./gsi:./gsc -- 
-:~~bin=./bin,~~lib=./lib,~~include=./include -v
Process 39231 launched: '/Users/lucier/programs/gambit-test/gambit/gsi/gsi'
(x86_64)
Process 39231 stopped
* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_INSTRUCTION
(code=12, subcode=0x0)
frame #0: 0x00010012d010
libgambit.dylib`___SCMOBJ_to_NONNULLSTRING(obj=,
x=0x7ffeefbfa6b8, arg_num=, char_encoding=,
fudge=) at c_intf.c:3280:173
   3277  p = r;
   3278  
   3279  for (i=0; i 3280___UTF_8_put (&p, ___INT(___STRINGREF(obj,___FIX(i;
   3281  
   3282  *p = 0;
   3283  
Target 0: (gsi) stopped.


This is my first time running lldb, so I'm a bit slow.

To your other questions: It's not JIT-generated code, and I'll work on building
a mainline compiler to test it, too.

Hope this helps.

[Bug c++/99586] Use of class template identifier checked for CTAD before instantiation

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 11.

[Bug target/99988] aarch64: GCC generates excessive consecutive bti j instructions

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Alex Coplan :

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

commit r12-34-gfe11882ae34c49f6214f93867783ed1332f35f0f
Author: Alex Coplan 
Date:   Wed Apr 21 14:42:04 2021 +0100

aarch64: Avoid duplicating bti j insns for jump tables [PR99988]

This patch fixes PR99988 which shows us generating large (> 250)
sequences of back-to-back bti j instructions.

The fix is simply to avoid inserting bti j instructions at the target of
a jump table if we've already inserted one for a given label.

gcc/ChangeLog:

PR target/99988
* config/aarch64/aarch64-bti-insert.c (aarch64_bti_j_insn_p): New.
(rest_of_insert_bti): Avoid inserting duplicate bti j insns for
jump table targets.

gcc/testsuite/ChangeLog:

PR target/99988
* gcc.target/aarch64/pr99988.c: New test.

[Bug target/99988] aarch64: GCC generates excessive consecutive bti j instructions

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

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

--- Comment #4 from Alex Coplan  ---
Fixed on trunk. Keeping open for backports (once it's had some decent baking
time).

[Bug target/94278] [amdgcn] Offloading build failures due to 'llvm-mc' SIGSEGV

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

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

--- Comment #8 from Richard Biener  ---
The patch from comment#3 fixes the issue for me.  The tests still fail one or
another way (most not finding libgfortran.a - maybe an error on my side, and
a few with unresolved symbols).

[Bug libstdc++/100164] [11/12 Regression] semaphore_impl not declared on AIX

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

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

--- Comment #14 from David Edelsohn  ---
Thanks for the patch. This now removes the failure that semaphore_impl is not
found.

Because the platform semaphore code never was exercised due to the bug in the
macro, there are more latent bugs.

/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/semaphore:74: error:
'using
 __semaphore_impl = struct std::__platform_semaphore' has no member named
'_M_tr
y_acquire'; did you mean '_M_acquire'?
/tmp/GCC/powerpc-ibm-aix7.2.3.0/libstdc++-v3/include/semaphore:75: error:
'using
 __semaphore_impl = struct std::__platform_semaphore' has no member named
'_M_tr
y_acquire'; did you mean '_M_acquire'?

[Bug libstdc++/97600] [ranges] satisfaction value of range affected by prior use of basic_istream_view::begin()

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #6 from Patrick Palka  ---
The library side workaround is in place for GCC 10.4 and 11, and GCC 11
additionally has a frontend optimization for ruling out unviable conversion ops
sooner which alone is sufficient to fix the PR.  I suppose we could revert the
library-side workaround for GCC 11/12 then, but it seems harmless to keep
around.

[Bug target/100182] [8/9/10/11/12 Regression] Miscompilation of atomic_float/1.cc on i686

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

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

--- Comment #1 from Jakub Jelinek  ---
In this particular case it is the sync.md:398 peephole2:
(define_peephole2
  [(set (match_operand:DF 0 "memory_operand")
(match_operand:DF 1 "any_fp_register_operand"))
   (set (mem:BLK (scratch:SI))
(unspec:BLK [(mem:BLK (scratch:SI))] UNSPEC_MEMORY_BLOCKAGE))
   (set (match_operand:DF 2 "fp_register_operand")
(unspec:DF [(match_operand:DI 3 "memory_operand")]
   UNSPEC_FILD_ATOMIC))
   (set (match_operand:DI 4 "memory_operand")
(unspec:DI [(match_dup 2)]
   UNSPEC_FIST_ATOMIC))]
  "!TARGET_64BIT
   && peep2_reg_dead_p (4, operands[2])
   && rtx_equal_p (XEXP (operands[0], 0), XEXP (operands[3], 0))"
  [(const_int 0)]
{
  emit_insn (gen_memory_blockage ());
  emit_move_insn (gen_lowpart (DFmode, operands[4]), operands[1]);
  DONE;
})
that triggers here but from what I can read, all the r7-1112 peephole2s
optimize away stores to some memory on the assumption that the memory is read
only once (in another insn matched by the same peephole2).
I'm not 100% sure if we can rely for it on spill slots for which r7-112 seems
to have been written, but for other memory we'd need to prove that the memory
is dead.
Rather than removing those peephole2s altogether, I wonder if we just shouldn't
check that the memory_operand which we'd optimize away stores to aren't spill
slots.

[Bug libstdc++/100164] [11/12 Regression] semaphore_impl not declared on AIX

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

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

--- Comment #15 from Thomas Rodgers  ---
>From the most recent patch -

+_GLIBCXX_ALWAYS_INLINE bool
+_M_try_acquire() noexcept
+{
+  for (;;)
+   {
+ auto __err = sem_trywait(&_M_semaphore);
+ if (__err && (errno == EINTR))
+   continue;
+ else if (__err && (errno == EAGAIN))
+   return false;
+ else if (__err)
+   std::terminate();
+ else
+   break;
+   }
+  return true;
+}
+

You are correct it was never exercised. I saw then when I forced it in the test
case and then added the above. I don't understand why you are seeing this error
if you've applied the 0001-libstdc-Work-around-for-PR100164 patch. I don't see
it locally.

[Bug libstdc++/100180] experimental/net/internet/address/v6/members.cc fails on arm-eabi

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

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

--- Comment #1 from Jonathan Wakely  ---
I think I need to backport another piece.

This should not have happened on trunk though.

[Bug libstdc++/100179] [12 regression] xtreme-header-2_a.H fails on arm-eabi

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

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

--- Comment #2 from Jonathan Wakely  ---
I have a patch for this.

[Bug c++/95486] ICE for alias CTAD with non-dependent argument and constrained constructor

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:4806f9157a26cfd66c083bcc01596ff33009c0d6

commit r10-9743-g4806f9157a26cfd66c083bcc01596ff33009c0d6
Author: Patrick Palka 
Date:   Wed Jul 29 22:06:41 2020 -0400

c++: alias_ctad_tweaks and constrained dguide [PR95486]

In the below testcase, we're ICEing from alias_ctad_tweaks ultimately
because the implied deduction guide for X's user-defined constructor
already has constraints associated with it.  We then carry over these
constraints to 'fprime', the overlying deduction guide for the alias
template Y, via tsubst_decl from alias_ctad_tweaks.  Later in
alias_ctad_tweaks we call get_constraints followed by set_constraints
without doing remove_constraints in between, which triggers the !found
assert in set_constraints.

This patch fixes this issue by adding an intervening call to
remove_constraints.

gcc/cp/ChangeLog:

PR c++/95486
* pt.c (alias_ctad_tweaks): Call remove_constraints before
calling set_constraints.

gcc/testsuite/ChangeLog:

PR c++/95486
* g++.dg/cpp2a/class-deduction-alias3.C: New test.

(cherry picked from commit 71141b1bd537cc516e485c834c2d36abba3f4544)

[Bug c++/95486] ICE for alias CTAD with non-dependent argument and constrained constructor

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #10 from Patrick Palka  ---
Fixed for GCC 10.4/11.

[Bug libstdc++/100180] experimental/net/internet/address/v6/members.cc fails on arm-eabi

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

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

--- Comment #2 from Christophe Lyon  ---
On trunk, the error message is:
FAIL: experimental/net/internet/address/v6/members.cc (test for excess errors)
Excess errors:
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include/experimental/io_context:602:
error: '__fdvec' is not a member of
'std::experimental::net::v1::io_context::__reactor'
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include/experimental/io_context:677:
error: 'struct std::experimental::net::v1::io_context::__reactor' has no member
named 'wait'
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include/experimental/io_context:677:
error: '__fds' was not declared in this scope
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include/experimental/io_context:679:
error: '_S_retry' is not a member of
'std::experimental::net::v1::io_context::__reactor'
/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/thumb/v7ve+simd/hard/libstdc++-v3/include/experimental/io_context:682:
error: '_S_timeout' is not a member of
'std::experimental::net::v1::io_context::__reactor'
[...]

[Bug fortran/100183] New: Segmentation fault at runtime when passing an internal procedure as argument

[jellby at yahoo dot com via Gcc-bugs]

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

Bug ID: 100183
   Summary: Segmentation fault at runtime when passing an internal
procedure as argument
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jellby at yahoo dot com
  Target Milestone: ---

I've only been able to reproduce it with:

$ uname -a
Darwin minimac.moose.housegordon.com 20.3.0 Darwin Kernel Version 20.3.0: Thu
Jan 21 00:06:51 PST 2021; root:xnu-7195.81.3~1/RELEASE_ARM64_T8101 arm64

$ gfortran -version
GNU Fortran (Homebrew GCC 10.2.0_4) 10.2.1 20201220


Compiling and running the following code works fine, but with -O1 it gives a
segmentation fault. Alternatively, undefining INTERNAL_PROC_ARG works with -O1.


$ cat test.F90
#define INTERNAL_PROC_ARG  
   
  [45/90681]

module sorting
implicit none
private
public :: argsort
real, pointer :: mod_rV(:)

interface
logical pure function compare_int_t(a, b)
integer, intent(in) :: a, b
end function
end interface

contains

logical pure function my_compare_rV(x, y)
integer, intent(in) :: x, y
my_compare_rV = mod_rV(x) <= mod_rV(y)
end function

function argsort(V) result(idx)
real, target, intent(inout) :: V(:)
integer :: idx(lbound(V, 1):ubound(V, 1)), i

idx = [(i, i = lbound(V, 1), ubound(V, 1))]

#   ifdef INTERNAL_PROC_ARG
call sort(idx, my_compare)
#   else
mod_rV => V
call sort(idx, my_compare_rV)
#   endif

contains
logical pure function my_compare(x, y)
integer, intent(in) :: x, y
my_compare = V(x) <= V(y)
end function
end function argsort

subroutine sort(A, compare)
integer, intent(inout) :: A(:)
procedure(compare_int_t) :: compare
integer :: i, j, t
do i = lbound(A, 1), ubound(A, 1)
  do j = i + 1, ubound(A, 1)
if (.not. compare(A(i), A(j))) then
t = A(i)
A(i) = A(j)
A(j) = t
end if
  end do
end do
end subroutine sort
end module sorting

program test
use sorting, only: argsort

implicit none
integer :: i
integer, parameter :: seed(50) = [(i, i = 1, size(seed))]
real :: lambdas(5)
integer :: idx(size(lambdas))

call random_seed(put=seed)
call random_number(lambdas)

write(6,*) 'Before sorting:'
write(6,*) lambdas(:)
idx(:) = argsort(lambdas)
write(6,*) 'Argsort:'
write(6,*) idx(:)
write(6,*) 'Sorted:'
write(6,*) lambdas(idx(:))
end program test


$ gfortran -O1 test.F90 -o test ; ./test   
 Before sorting:
  0.471070886  0.117344737  0.357547939  0.318134785 
0.696753800
zsh: segmentation fault  ./test


$ gfortran -O0 test.F90 -o test ; ./test
 Before sorting:
  0.471070886  0.117344737  0.357547939  0.318134785 
0.696753800
 Argsort:
   2   4   3   1   5
 Sorted:
  0.117344737  0.318134785  0.357547939  0.471070886 
0.696753800

[Bug target/100181] hot-cold partitioned code doesn't assemble

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

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

--- Comment #9 from Tobias Burnus  ---
(In reply to Thomas Schwinge from comment #8)
> (In reply to Tobias Burnus from comment #7)
> > (I could not reproduce the LLVM 9 issue in PR94278 back then.)
> 
> Hmm, but didn't you say in the LLVM issue
>  that you _did_ reproduce this 
> back then?

I partially mixed it up - I could not reproduce it with a self-build LLVM but
could do so with the distro LLVM ones.

Our/my LLVM bug 45887 is similar to
https://bugs.llvm.org/show_bug.cgi?id=41914, which was fixed by
https://reviews.llvm.org/D79943 and the latter adds the check which causes the
error message: "undefined label '.L33'"

However, the other bug (41914) and the the testcase in the fix (D79943) were
about a label which was truly missing as opposed to one which is just in a
differently named .section.

 * * *

Obviously, with D79943 at place (LLVM 11, 12, ...), I can reproduce the issue
with -O2 (with < -O0 there is only .text) as then 's_branch .L33' is in
.section .text but '.L33:' is in '.section .text.unlikely'.

Whether it is intended that cross-.section s_branch are no longer permitted or
whether it happened by chance by this patch or on purpose, I don't know.

Sections themselves are supported – and the  LVM testsuite for GCN has
testcases with '.section' (under llvm/test/MC/AMDGPU/*.s) – but in the
testsuite one at a time.

GCC guards the .text.unlikely generation by (→ varasm.c's
default_function_section) by

  if (!flag_reorder_functions
  || !targetm_common.have_named_sections)
return NULL;

while the patch in PR 94278 comment 3 uses
   flag_reorder_blocks_and_partition = 0

[Bug c++/94475] [9 Regression] ICE: tree check: expected class 'type', have 'exceptional' (error_mark) in element_mode, at tree.c:13813

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #5 from Patrick Palka  ---
Fixed for GCC 10+.  I reckon this isn't worth backporting since it's just an
error-recovery ICE.

[Bug libstdc++/100180] experimental/net/internet/address/v6/members.cc fails on arm-eabi

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

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

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

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

commit r10-9744-gf0d22d31ceb1373f17045f2527ef2f2251d93be8
Author: Jonathan Wakely 
Date:   Wed Apr 21 15:48:02 2021 +0100

libstdc++: Disable test for non-gthreads targets [PR 100180]

The Networking TS code still requires std::mutex on this branch, so the
tests shouldn't run on targets without gthreads.

PR libstdc++/100180
* testsuite/experimental/net/internet/address/v6/members.cc:
Require gthreads.

[Bug libstdc++/100180] experimental/net/internet/address/v6/members.cc fails on arm-eabi

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

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

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

https://gcc.gnu.org/g:34976f3bf8ff146e31b1ccee9351c5803604d7ae

commit r9-9454-g34976f3bf8ff146e31b1ccee9351c5803604d7ae
Author: Jonathan Wakely 
Date:   Wed Apr 21 15:48:02 2021 +0100

libstdc++: Disable test for non-gthreads targets [PR 100180]

The Networking TS code still requires std::mutex on this branch, so the
tests shouldn't run on targets without gthreads.

PR libstdc++/100180
* testsuite/experimental/net/internet/address/v6/members.cc:
Require gthreads.

(cherry picked from commit f0d22d31ceb1373f17045f2527ef2f2251d93be8)

[Bug libstdc++/100180] experimental/net/internet/address/v6/members.cc fails on arm-eabi

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

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

--- Comment #5 from Jonathan Wakely  ---
(In reply to Christophe Lyon from comment #2)
> On trunk, the error message is:
> FAIL: experimental/net/internet/address/v6/members.cc (test for excess
> errors)
> Excess errors:
> /aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-arm-none-eabi/gcc3/arm-none-eabi/
> thumb/v7ve+simd/hard/libstdc++-v3/include/experimental/io_context:602:
> error: '__fdvec' is not a member of
> 'std::experimental::net::v1::io_context::__reactor'

Thanks, that's a completely different error (and must have been there since
February when the test was added).

That error will happen for any target without , and I would expect it
to also happen for all the other experimental/net/* tests too.

[Bug rtl-optimization/99332] ICE:inreset_sched_cycles_in_current_ebb, at sel-sched.c:7147 with -fprofile-generate -O3 -fselective-scheduling -fselective-scheduling2 -fsel-sched-pipelining

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

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

Alex Coplan  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||acoplan at gcc dot gnu.org
   Last reconfirmed||2021-04-21

--- Comment #1 from Alex Coplan  ---
Confirmed on trunk. I can't reproduce it on GCC 10.

[Bug c++/100172] ICE with "concept concept" keyword

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

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

Marek Polacek  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2021-04-21
 Status|UNCONFIRMED |NEW

--- Comment #3 from Marek Polacek  ---
Confirmed.

[Bug c++/96380] [10/11/12 Regression] ICE in tree check: expected integer_cst, have view_convert_expr in get_len, at tree.h:5954

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Marek Polacek :

https://gcc.gnu.org/g:001c63d15e31bc0a1545426d889a0b9f671b4961

commit r12-42-g001c63d15e31bc0a1545426d889a0b9f671b4961
Author: Marek Polacek 
Date:   Tue Apr 20 12:16:04 2021 -0400

c++: Don't allow defining types in enum-base [PR96380]

In r11-2064 I made cp_parser_enum_specifier commit to tentative parse
when seeing a '{'.  That still looks like the correct thing to do, but
it caused an ICE-on-invalid as well as accepts-invalid.

When we have something sneaky like this, which is broken in multiple
ways:

  template 
  enum struct c : union enum struct c { e = b, f = a };

we parse the "enum struct c" part (that's OK) and then we see that
we have an enum-base, so we consume ':' and then parse the type-specifier
that follows the :.  "union enum" is clearly invalid, but we're still
parsing tentatively and we parse everything up to the ;, and then
throw away the underlying type.  We parsed everything because we were
tricked into parsing an enum-specifier in an enum-base of another
enum-specifier!  Not good.

Since the grammar for enum-base doesn't allow a defining-type-specifier,
only a type-specifier, we should set type_definition_forbidden_message
which fixes all the problems in this PR.

gcc/cp/ChangeLog:

PR c++/96380
* parser.c (cp_parser_enum_specifier): Don't allow defining
types in enum-base.

gcc/testsuite/ChangeLog:

PR c++/96380
* g++.dg/cpp0x/enum_base4.C: New test.
* g++.dg/cpp0x/enum_base5.C: New test.

[Bug c++/96380] [10/11 Regression] ICE in tree check: expected integer_cst, have view_convert_expr in get_len, at tree.h:5954

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

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

Marek Polacek  changed:

   What|Removed |Added

Summary|[10/11/12 Regression] ICE   |[10/11 Regression] ICE in
   |in tree check: expected |tree check: expected
   |integer_cst, have   |integer_cst, have
   |view_convert_expr in|view_convert_expr in
   |get_len, at tree.h:5954 |get_len, at tree.h:5954

--- Comment #8 from Marek Polacek  ---
Fixed on trunk (GCC 12) so far.  Will backport to 11.2 and 10.4.  Note: The
patch uses auto, needs tweaking before backporting to 10.

[Bug libstdc++/100164] [11/12 Regression] semaphore_impl not declared on AIX

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

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

--- Comment #16 from Thomas Rodgers  ---
The _M_try_acquire() change should be on master and gcc-11 now.

[Bug libstdc++/100164] [11/12 Regression] semaphore_impl not declared on AIX

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #17 from Jonathan Wakely  ---
r12-44 and r11-8275

[Bug target/98143] arm: missed vectorization with MVE compared to Neon

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

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

--- Comment #1 from Christophe Lyon  ---
Current trunk generates for MVE:

ldr r3, .L3+16  @ 5 [c=12 l=4]  *thumb2_movsi_vfp/5
vldr.64 d6, .L3 @ 7 [c=8 l=4]  *mve_movv8hi/8
vldr.64 d7, .L3+8
ldr r3, [r3]@ 14[c=12 l=4]  *thumb2_movsi_vfp/5
mov r2, r3  @ 17[c=4 l=2]  *thumb2_movsi_vfp/0
addsr3, r3, #16 @ 18[c=4 l=2]  *thumb2_addsi_short/1
vstrh.16q3, [r2]@ 8 [c=8 l=4] 
*movmisalignv8hi_mve_store
vstrh.16q3, [r3]@ 11[c=8 l=4] 
*movmisalignv8hi_mve_store
bx  lr  @ 45[c=8 l=4]  *thumb2_return
.L4:
.align  3
.L3:
.short  3
.short  3
.short  3
.short  3
.short  3
.short  3
.short  3
.short  3

[Bug target/100152] Possible 10.3 bad code generation regression from 10.2/9.3 on Mac OS 10.15.7 (Catalina)

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

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #17 from Iain Sandoe  ---
(In reply to lucier from comment #16)
> I have figured out how to build and then run the app in lldb to reliably
> reproduce the error.

> To configure and build Gambit, the Scheme->C compiler:
> 
> 51  8:56mkdir gambit-test
> 52  8:56cd gambit-test
> 53  8:56git clone https://github.com/gambit/gambit.git

$ git log -1 --oneline
bb05af0a (HEAD -> master, origin/master, origin/HEAD) Fix missing return
address when using (declare (not optimize-dead-local-variables) (not
interrupts-enabled))

> 54  8:57cd gambit
> 55  9:00./configure 'CC=/usr/local/gcc-10.3.0/bin/gcc -save-temps
> -g' '--enable-single-host' '--enable-shared'

> Hope this helps.

[so far on Darwin16 / macOS 10.12 ]

Yes it does -  can confirm that a 10.2 build works and 10.3 fails but the error
I get is different:

$ DYLD_LIBRARY_PATH=lib:gsi:gsc gsi/gsi
-:~~bin=./bin,~~lib=./lib,~~include=./include -v
Bus error: 10

lldb -- gsi/gsi -:~~bin=./bin,~~lib=./lib,~~include=./include -v
(lldb) env DYLD_LIBRARY_PATH=lib:gsi:gsc
(lldb) r

* thread #1, queue = 'com.apple.main-thread', stop reason = EXC_BAD_ACCESS
(code=2, address=0x1000a88f0)
frame #0: 0x0001000a3475
libgambit.dylib`___release_rc(ptr=0x0001000a8900) at mem.c:724
   721  {
   722___rc_header *h = ___CAST(___rc_header*,ptr) - 1;
   723  
-> 724if (--h->refcount == 0)
   725  {
   726___rc_header *prev = h->prev;

I will try later on 10.15,

[Bug target/100182] [8/9/10/11/12 Regression] Miscompilation of atomic_float/1.cc on i686

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

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

--- Comment #2 from Jakub Jelinek  ---
In addition to r7-1112 r8-3856 also added some similar peephole2s.
I'm afraid I'm getting lost in them, in several other peephole2s there the
store that is optimized away is an atomic store and that is quite certainly not
a spill slot.

[Bug libstdc++/100017] error: 'fenv_t' has not been declared in '::' x86_64-w64-mingw32 host cross toolchain fails to build

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

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

--- Comment #6 from Jonathan Wakely  ---
>From IRC:

It works if I add -nostdinc++ manually to the compile line that fails then I
don't get the error

[Bug target/100182] [8/9/10/11/12 Regression] Miscompilation of atomic_float/1.cc on i686

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

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

--- Comment #3 from Jakub Jelinek  ---
Created attachment 50649
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50649&action=edit
gcc12-pr100182.patch

Untested patch for this particular peephole2.  But, 1) I'm not sure it is 100%
safe even for spill slots 2) I don't know what to do with the remaining 7
peephole2s
I'm afraid during peephole2 pass we don't have anything comparable to RTL DSE
infrastructure, and unfortunately the last RTL DSE2 pass is 5 passes before
peephole2.  So matching these insn sequences e.g. could be done in some machine
specific pass before RTL DSE2 instead of peephole2 and let RTL DSE2 optimize
away what seems unnecessary, or use some patterns that RTL DSE2 would recognize
on its own.

[Bug target/100182] [8/9/10/11/12 Regression] Miscompilation of atomic_float/1.cc on i686

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug fortran/100149] Seg fault passing to CHARACTER(*), DIMENSION(*), INTENT(IN), OPTIONAL

[brtnfld at hdfgroup dot org via Gcc-bugs]

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

Scot Breitenfeld  changed:

   What|Removed |Added

  Known to work||10.3.0
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #3 from Scot Breitenfeld  ---
For future reference, gfortran 10.3.0 does not have this issue. I've updated
the Known to work.

The bug report can be closed.

[Bug c/100184] New: Detect variables which are only "used" in updating themselves

[eyalroz1 at gmx dot com via Gcc-bugs]

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

Bug ID: 100184
   Summary: Detect variables which are only "used" in updating
themselves
   Product: gcc
   Version: 10.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eyalroz1 at gmx dot com
  Target Milestone: ---

Consider the following C function:
```
int bar() 
{
int pow = 1;
return 1;
}
```
If we compile this with -Wall , GCC will warn us of having an unused variable.
If we write:
```
int bar() 
{
int pow = 1;
pow = 2;
return 1;
}
```
a different warning: Variable set but not used.

Now, suppose we write:
```
int bar() 
{
int pow = 1;
pow++;
return 1;
}
```
we will no longer get any warning. I believe GCC should warn in this case; or
at least - there should be a flag which makes it warn when a variable is used
only in updating itself.

[Bug c++/100185] New: transparent_union fails when the union has a destructor

[gonzalobg88 at gmail dot com via Gcc-bugs]

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

Bug ID: 100185
   Summary: transparent_union fails when the union has a
destructor
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gonzalobg88 at gmail dot com
  Target Milestone: ---

Example:

union  __attribute__((transparent_union)) U {
int* a;
~U() {}
};

fails with:

:1:43: error: type transparent 'union U' cannot be made transparent 
because the type of the first field has a different ABI from the class
overall
1 | union  __attribute__((transparent_union)) U {
  |   ^

I think this should be allowed with the following semantics:

void f(int*);
void g(U&);
void h(U);
void j(int);

{
U u;
f(u); // passes U as int*
g(u); // passes U as U&
h(u); // ERROR: U does not have a copy constructor
j(u); // ERROR: cannot convert U to int

//~U() called at the end of the scope
}

[Bug bootstrap/100186] New: lto-wrapper.c assumes std::thread

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

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

Bug ID: 100186
   Summary: lto-wrapper.c assumes std::thread
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---
Target: powerpc-ibm-aix*

lto-wrapper.c:1288:37: error 'std::thread' has not been declared

unsigned long nthreads_var = std::thread::hardware_concurrency ();

[Bug bootstrap/100186] lto-wrapper.c assumes std::thread

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

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

David Edelsohn  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
   Last reconfirmed||2021-04-21
 CC||mliska at suse dot cz
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from David Edelsohn  ---
Confirmed.