[Bug c++/105300] New: segfault from static_assert with user-defined string suffix argument

[Jack at Applin dot US via Gcc-bugs]

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

Bug ID: 105300
   Summary: segfault from static_assert with user-defined string
suffix argument
   Product: gcc
   Version: 11.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Jack at Applin dot US
  Target Milestone: ---

Created attachment 52824
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52824=edit
preprocessed source to reproduce the error

$ cat bad.ii
void operator""_x(const char *, unsigned long);
static_assert(false, "foo"_x);
$ g++ bad.ii
bad.ii:2:15: internal compiler error: Segmentation fault
2 | static_assert(false, "foo"_x);
  |   ^
0xb0c67e crash_signal
../../src/gcc/toplev.c:327
0x7fb38e75951f ???
./signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x7dd197 finish_static_assert(tree_node*, tree_node*, unsigned int, bool, bool)
../../src/gcc/cp/semantics.c:10134
0x15089c8 cp_parser_static_assert
../../src/gcc/cp/parser.c:15464
0xf9ed91 cp_parser_declaration
../../src/gcc/cp/parser.c:14164
0x149bba3 cp_parser_toplevel_declaration
../../src/gcc/cp/parser.c:14193
0x149bba3 cp_parser_translation_unit
../../src/gcc/cp/parser.c:4942
0x149bba3 c_parse_file()
../../src/gcc/cp/parser.c:45326
0x1489a5e c_common_parse_file()
../../src/gcc/c-family/c-opts.c:1218
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
$ g++ --version
g++ (Ubuntu 11.2.0-7ubuntu2) 11.2.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug testsuite/105266] new test case gcc.dg/pr105250.c fails with excess errors in r12-8134-g4e892de6774f86

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

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

Kewen Lin  changed:

   What|Removed |Added

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

--- Comment #4 from Kewen Lin  ---
Fixed on latest trunk.

[Bug testsuite/105266] new test case gcc.dg/pr105250.c fails with excess errors in r12-8134-g4e892de6774f86

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

https://gcc.gnu.org/g:021b51814d67bedd8f41ac07edfd05654140c6e5

commit r12-8184-g021b51814d67bedd8f41ac07edfd05654140c6e5
Author: Kewen Lin 
Date:   Sun Apr 17 21:34:51 2022 -0500

testsuite: Skip pr105250.c for powerpc and s390 [PR105266]

This test case pr105250.c is like its related pr105140.c, which
suffers the error with message like "{AltiVec,vector} argument
passed to unprototyped" on powerpc and s390.  So like commits
r12-8025 and r12-8039, this fix is to add the dg-skip-if for
powerpc*-*-* and s390*-*-*.

gcc/testsuite/ChangeLog:

PR testsuite/105266
* gcc.dg/pr105250.c: Skip for powerpc*-*-* and s390*-*-*.

[Bug target/105288] AVX/AVX512 casts should use the "v" constraint

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Hongtao.liu  ---
I think HJ means avx__ can be extended to
evex sse registes by change "x" to "v" when AVX512VL is available.

For avx512f__, it should be
"=Yv,m"
" vm,v"

since operands[0] could be allocated as evex register w/o AVX512VL, but it will
be lower to 256-bit mov which require AVX512VL for evex registers.

Options for re-adding gcj

[Zopolis0 via Gcc-patches]

Over the past few months I have been working on re-adding gcj back into
gcc, as the fundamental issue holding it back (the need to create an
open-source implementation of java from the ground up) has since been
solved by the opening of the JDK.

Unfortunately, as the old gcj code is several years old, it does not work
nicely with the current code and is largely incomplete. I have gotten it
into a state where gcc will compile with default options, unless you
forcibly enable java.

The issues I am now encountering are far beyond my skill level, and would
require someone with much more familiarity with the gcc tree than me and
general coding experience.

This leaves a few options for creating a functional Java compiler using the
OpenJDK.

1. Add the code in its current state to the current gcc tree, and have it
gradually get repaired to a state of feature parity with when it was
removed, then replace the Classpath with the OpenJDK. (There are a variety
of options for this as well, but I aim to implement it in a way similar to
C/C++ standards.)

2. Try and identify the breaking changes, speak to the people who made them
(or other people familiar with the relevant areas of the gcc tree) and get
their assistance in extending those changes to the gcj source files.

3. Replace Classpath with OpenJDK in GCC 6, (following the same C/C++
standards idea as above), as this would not require any changes to source
files and would work seamlessly. However, this is obviously not optimal,
and I would prefer to avoid it.

Which option do people think is the best?

[Bug c++/105299] dereference null pointer

[xw111luoye at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Ye Luo  ---
Unfortunately there is no easy reproducer.
Even without the printf. I got the same failure.
Will try with a debugger.

[Bug c++/105299] dereference null pointer

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

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

--- Comment #2 from Andrew Pinski  ---
Also this is not the right place to ask how to debug your code really. This is
about reporting bugs against GCC.  I highly doubt there is a bug in GCC and you
didn't even read https://gcc.gnu.org/bugs/ before reporting a bug report on
what we need.

gcc-12-20220417 is now available

[GCC Administrator via Gcc]

Snapshot gcc-12-20220417 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/12-20220417/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision 000c1b89d259fadb466e1f2e63c79da45fd17372

You'll find:

 gcc-12-20220417.tar.xz   Complete GCC

  SHA256=3725ae2f5d3bf6f6e2bcc1360302390d5f46e5aaecc9070d5038774d06238d60
  SHA1=3f2a83dba4009d4b5ddb22a5c1f69776af92e7c0

Diffs from 12-20220410 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-12
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug c++/105299] dereference null pointer

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
There is no way we can help you debug this code with just a code segment.

Maybe you have a buffer overflow on the stack which is causing ArgMappers to
become null after the fprintf.
gdb and watch points are useful to see when the value of ArgMappers changes if
at all.

Re: [PATCH] c++: Fix up CONSTRUCTOR_PLACEHOLDER_BOUNDARY handling [PR105256]

[Jason Merrill via Gcc-patches]

On 4/15/22 07:22, Jakub Jelinek wrote:

Hi!

The CONSTRUCTOR_PLACEHOLDER_BOUNDARY bit is supposed to separate
PLACEHOLDER_EXPRs that should be replaced by one object or subobjects of it
(variable, TARGET_EXPR slot, ...) from other PLACEHOLDER_EXPRs that should
be replaced by different objects or subobjects.
The bit is set when finding PLACEHOLDER_EXPRs inside of a CONSTRUCTOR, not
looking into nested CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctors, and we prevent
elision of TARGET_EXPRs (through TARGET_EXPR_NO_ELIDE) whose initializer
is a CONSTRUCTOR_PLACEHOLDER_BOUNDARY ctor.  The following testcase ICEs
though, we don't replace the placeholders in there at all, because
CONSTRUCTOR_PLACEHOLDER_BOUNDARY isn't set on the TARGET_EXPR_INITIAL
ctor, but on a ctor nested in such a ctor.  replace_placeholders should be
run on the whole TARGET_EXPR slot.

So, the following patch fixes it by moving the CONSTRUCTOR_PLACEHOLDER_BOUNDARY
bit from nested CONSTRUCTORs to the CONSTRUCTOR containing those (but only
if it is closely nested, if there is some other tree sandwiched in between,
it doesn't do it).


Hmm, Patrick made a similar change and then reverted it for PR90996. 
But it makes sense to me; when we replace placeholders, it's appropriate 
to look at the whole aggregate initialization rather than the innermost 
CONSTRUCTOR that has DMIs.  Patrick, was there a reason that change 
seemed wrong to you, or was it just unnecessary for the bug you were 
working on?



Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?

2022-04-15  Jakub Jelinek  

PR c++/105256
* typeck2.cc (process_init_constructor_array,
process_init_constructor_record, process_init_constructor_union): Move
CONSTRUCTOR_PLACEHOLDER_BOUNDARY flag from CONSTRUCTOR elements to the
containing CONSTRUCTOR.

* g++.dg/cpp0x/pr105256.C: New test.

--- gcc/cp/typeck2.cc.jj2022-04-07 09:09:54.432995137 +0200
+++ gcc/cp/typeck2.cc   2022-04-14 16:02:12.438432494 +0200
@@ -1515,6 +1515,14 @@ process_init_constructor_array (tree typ
  strip_array_types (TREE_TYPE (ce->value);
  
picflags |= picflag_from_initializer (ce->value);

+  /* Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY to outer
+CONSTRUCTOR.  */
+  if (TREE_CODE (ce->value) == CONSTRUCTOR
+ && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ce->value))
+   {
+ CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = 1;
+ CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ce->value) = 0;
+   }
  }
  
/* No more initializers. If the array is unbounded, we are done. Otherwise,

@@ -1560,6 +1568,14 @@ process_init_constructor_array (tree typ
  }
  
  	picflags |= picflag_from_initializer (next);

+   /* Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY to outer
+  CONSTRUCTOR.  */
+   if (TREE_CODE (next) == CONSTRUCTOR
+   && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (next))
+ {
+   CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = 1;
+   CONSTRUCTOR_PLACEHOLDER_BOUNDARY (next) = 0;
+ }
if (len > i+1)
  {
tree range = build2 (RANGE_EXPR, size_type_node,
@@ -1754,6 +1770,13 @@ process_init_constructor_record (tree ty
if (fldtype != TREE_TYPE (field))
next = cp_convert_and_check (TREE_TYPE (field), next, complain);
picflags |= picflag_from_initializer (next);
+  /* Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY to outer CONSTRUCTOR.  */
+  if (TREE_CODE (next) == CONSTRUCTOR
+ && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (next))
+   {
+ CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = 1;
+ CONSTRUCTOR_PLACEHOLDER_BOUNDARY (next) = 0;
+   }
CONSTRUCTOR_APPEND_ELT (v, field, next);
  }
  
@@ -1894,6 +1917,14 @@ process_init_constructor_union (tree typ

  ce->value = massage_init_elt (TREE_TYPE (ce->index), ce->value, nested,
  flags, complain);
  
+  /* Propagate CONSTRUCTOR_PLACEHOLDER_BOUNDARY to outer CONSTRUCTOR.  */

+  if (ce->value
+  && TREE_CODE (ce->value) == CONSTRUCTOR
+  && CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ce->value))
+{
+  CONSTRUCTOR_PLACEHOLDER_BOUNDARY (init) = 1;
+  CONSTRUCTOR_PLACEHOLDER_BOUNDARY (ce->value) = 0;
+}
return picflag_from_initializer (ce->value);
  }
  
--- gcc/testsuite/g++.dg/cpp0x/pr105256.C.jj	2022-04-14 16:04:30.518518875 +0200

+++ gcc/testsuite/g++.dg/cpp0x/pr105256.C   2022-04-14 16:03:53.264035175 
+0200
@@ -0,0 +1,18 @@
+// PR c++/105256
+// { dg-do compile { target c++11 } }
+
+int bar (int &);
+
+struct S {
+  struct T {
+struct U {
+  int i = bar (i);
+} u;
+  };
+};
+
+void
+foo (S::T *p)
+{
+  *p = {};
+};

Jakub

[Bug c++/105299] New: dereference null pointer

[xw111luoye at gmail dot com via Gcc-bugs]

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

Bug ID: 105299
   Summary: dereference null pointer
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xw111luoye at gmail dot com
  Target Milestone: ---

My application runs in parallel on Power9 RHEL 8.2 using gcc 9.3. The failure
doesn't show up in small scale runs. However, when running with 24576(4096*6)
MPI processes,

code:
void* ArgMappers; // passed in as a function argument.
...
if (ArgMappers) {
  fprintf(stderr, "ArgMappers is not nullptr %p, I = %d\n", ArgMappers, I);
  if (ArgMappers[I]) {

segfault happens at the second 'if'.
the print out and failure message is
ArgMappers is not nullptr (nil), I = 3
[g32n01:3164430] *** Process received signal ***
[g32n01:3164430] Signal: Segmentation fault (11)
[g32n01:3164430] Signal code: Address not mapped (1)
[g32n01:3164430] Failing at address: 0x18

It is very strange that the first if check passed while ArgMappers is has a
value NULL as the printf shows.
In a few more runs, I got at least three failing
"Failing at address" 0x8 0x18 0x40
Any insight is welcome.

[Bug bootstrap/105298] GCC-12-20220410 FTBFS for --enable-languages=[c,c++,]d: configure: error: can't compile D sources!: gcc/d21: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.29' not found

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

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

--- Comment #2 from Andrew Pinski  ---
https://bugzilla.redhat.com/show_bug.cgi?id=20218 explains why.

[Bug bootstrap/105298] GCC-12-20220410 FTBFS for --enable-languages=[c,c++,]d: configure: error: can't compile D sources!: gcc/d21: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.29' not found

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Use LD_LIBRARY_PATH instead of LD_RUN_PATH.

[Bug bootstrap/105298] New: GCC-12-20220410 FTBFS for --enable-languages=[c,c++,]d: configure: error: can't compile D sources!: gcc/d21: /usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.29' not found

[kdevel at vogtner dot de via Gcc-bugs]

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

Bug ID: 105298
   Summary: GCC-12-20220410 FTBFS for
--enable-languages=[c,c++,]d: configure: error: can't
compile D sources!: gcc/d21:
/usr/lib64/libstdc++.so.6: version `GLIBCXX_3.4.29'
not found
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kdevel at vogtner dot de
  Target Milestone: ---

Different from GCC 11.2 GCC 12 does not seem to build gdc without having
already a gdc installed. In order to overcome this I use a GCC 11.2 which is
installed in a non-std. For this puropose I set

   PATH=:$PATH
   export LD_RUN_PATH=/lib64:/lib

before

   gcc-12-20220410/configure --prefix=$inst --enable-languages=c,c++,d

where $inst ist a non-std. directory.

   make bootstrap

then fails with error 2 and

   configure: error: can't compile D sources!

This is caused by gcc/d21 in the objdir referencing /usr/lib64/libstdc++.so
instead of /libstdc++.so, which is caused by RPATH
set to $inst/lib64 instead of /lib64.

[Bug tree-optimization/105295] missed optimization with -ftrapv for conditional constants

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Depends on||101521

--- Comment #3 from Andrew Pinski  ---
PR 101521 records on how it should be implemented differently. Maybe for GCC
13, it will change.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101521
[Bug 101521] -ftrapv should become something like -fsanitize=undefined
-fsanitize-undefined-trap-on-error

[Bug tree-optimization/105295] missed optimization with -ftrapv for conditional constants

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

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

--- Comment #2 from Andrew Pinski  ---
Yes trapv is implemented during expansion (from gimple to RTL) and not really
optimized.

[Bug tree-optimization/105295] missed optimization with -ftrapv for conditional constants

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
URL|https://godbolt.org/z/4rojo |
   |77a7|

--- Comment #1 from Andrew Pinski  ---
https://godbolt.org/z/4rojo77a7

Re: [PATCH] libgompd: add OMPD support, libgompd initialization and global ICVs functions

[Mohamed Atef via Gcc-patches]

Hi,
This is the second time i ping this patch.
I just remind you of it.

Mohamed

في الأحد، ٣ أبريل، ٢٠٢٢ ٤:٤١ م Mohamed Atef  كتب:

> Hi,
>   I'd like to ping this patch.
> Thanks
>
> Mohamed
>
> On Sun, Mar 20, 2022 at 11:33 AM Mohamed Atef 
> wrote:
>
>> hello,
>>I know it's too much.
>> we fixed the functions' names that are not part of the standard form
>> ompd_ * prefix to gompd_
>> Thanks
>>
>>
>> On Wed, Mar 16, 2022 at 5:48 AM Mohamed Atef 
>> wrote:
>>
>>> Hi,
>>>we found some typos in the ChangeLog and some wrong spaces
>>> (nightmare) in the files.
>>> So here's the best we can do.
>>> and please don't be disappointed and trust us we're doing our best.
>>> I hope you could review it by Sunday night.
>>>
>>> Thanks.
>>>
>>>
>>> libgomp/ChangeLog
>>>
>>> 2022-03-15  Mohamed Atef  
>>>
>>> *config/darwin/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
>>> *config/hpux/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
>>> *config/posix/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
>>> *configure: Regenerate.
>>> * Makefile.am (toolexeclib_LTLIBRARIES): Add libgompd.la.
>>> 
>>> (libgompd_la_LDFLAGS, libgompd_la_DEPENDENCIES, libgompd_la_LINK,
>>> libgompd_la_SOURCES, libgompd_version_dep, libgompd_version_script,
>>> libgompd.ver-sun, libgompd.ver, libgompd_version_info): New.
>>> *Makefile.in: Regenerate.
>>> *aclocal.m4: Regenerate.
>>> *env.c: Include ompd-support.h.
>>> (initialize_env): Call gompd_load.
>>> *team.c: Include ompd-support.h.
>>> (gomp_team_start): Call ompd_bp_parallel_begin.
>>> (gomp_team_end): Call ompd_bp_parallel_end.
>>> *libgomp.map: Add OMP_5.0.3 symbol versions.
>>> *libgompd.map: New.
>>> *omp-tools.h.in: New.
>>> *ompd-types.h.in: New.
>>> *ompd-support.h: New.
>>> *ompd-support.c: New.
>>> *ompd-helper.h: New.
>>> *ompd-helper.c: New.
>>> *ompd-init.c: New.
>>> *ompd-icv.c: New.
>>> *configure.ac (AC_CONFIG_FILES): Add omp-tools.h and ompd-types.h.
>>>
>>>
>>> On Tue, Mar 15, 2022 at 11:32 PM Mohamed Atef 
>>> wrote:
>>>


 On Tue, Mar 15, 2022 at 11:32 PM Mohamed Atef <
 mohamedatef1...@gmail.com> wrote:

> This patch added OMPD support to libgomp, api version funcitos and
> global ICVs functions.
> I hope you review it as soon as possible, to fix the problems.
> I tried as much as I could to follow GNU standards.
> We have a seminar at the college next week, so we need this to be
> reviewed.
> Thanks
>
>
> libgomp/ChangeLog
>
> 2022-03-15  Mohamed Atef  
>
> *config/darwin/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
> *config/hpux/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
> *config/posix/plugin-suffix.h (SONAME_SUFFIX): Remove ()s.
> *configure: Regenerate.
> * Makefile.am (toolexeclib_LTLIBRARIES): Add libgompd.la
> (libgompd_la_LDFLAGS, libgompd_la_DEPENDENCIES, libgompd_la_LINK,
> libgompd_la_SOURCES, libgompd_version_dep, libgompd_version_script,
> libgompd.ver-sun, libgompd.ver, libgompd_version_info): New.
> *Makefile.in: Regenerate.
> *aclocal.m4: Regenerate.
> *env.c: Include ompd-support.h.
> (initialize_env): Call gompd_load.
> *team.c: Include ompd-support.h.
> (gomp_team_start): Call ompd_bp_parallel_begin.
> (gomp_team_end): Call ompd_bp_parallel_end.
> *libgomp.map: Add OMP_5.0.3 symbol versions.
> *libgompd.map: New.
> *omp-tools.h.in: New.
> *ompd-types.h.in: New.
> *ompd-support.h: New.
> *ompd-support.c: New.
> *ompd-helper.h: New.
> *ompd-helper.c: New.
> *ompd-init.c: New.
> *ompd-icv.c: New.
> *configure.ac (AC_CONFIG_FILES): Add omp-tools.h and ompd-types.h.
>

[PATCH] ipa-visibility: Optimize TLS access [PR99619]

[Artem Klimov via Gcc-patches]

Fix issue PR99619, which asks to optimize TLS access based on
visibility. The fix is implemented as an IPA optimization, which allows
to take optimized visibility status into account (as well as avoid
modifying all language frontends).

2022-04-17  Artem Klimov  

gcc/ChangeLog:
PR middle-end/99619
* ipa-visibility.cc (function_and_variable_visibility): Add an
explicit TLS model update after visibility optimisation loops.

gcc/testsuite/ChangeLog:
PR middle-end/99619
* gcc.dg/tls/vis-attr-gd.c: New test.
* gcc.dg/tls/vis-attr-hidden-gd.c: New test.
* gcc.dg/tls/vis-attr-hidden.c: New test.
* gcc.dg/tls/vis-flag-hidden-gd.c: New test.
* gcc.dg/tls/vis-flag-hidden.c: New test.
* gcc.dg/tls/vis-pragma-hidden-gd.c: New test.
* gcc.dg/tls/vis-pragma-hidden.c: New test.

Co-Authored-By:  Alexander Monakov  
Signed-off-by: Artem Klimov 
---
 gcc/ipa-visibility.cc   | 16 
 gcc/testsuite/gcc.dg/tls/vis-attr-gd.c  | 10 ++
 gcc/testsuite/gcc.dg/tls/vis-attr-hidden-gd.c   | 11 +++
 gcc/testsuite/gcc.dg/tls/vis-attr-hidden.c  | 10 ++
 gcc/testsuite/gcc.dg/tls/vis-flag-hidden-gd.c   | 11 +++
 gcc/testsuite/gcc.dg/tls/vis-flag-hidden.c  | 10 ++
 gcc/testsuite/gcc.dg/tls/vis-pragma-hidden-gd.c | 15 +++
 gcc/testsuite/gcc.dg/tls/vis-pragma-hidden.c| 14 ++
 8 files changed, 97 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-attr-gd.c
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-attr-hidden-gd.c
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-attr-hidden.c
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-flag-hidden-gd.c
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-flag-hidden.c
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-pragma-hidden-gd.c
 create mode 100644 gcc/testsuite/gcc.dg/tls/vis-pragma-hidden.c

diff --git a/gcc/ipa-visibility.cc b/gcc/ipa-visibility.cc
index e95a0dd252f..ca5b9a95f5e 100644
--- a/gcc/ipa-visibility.cc
+++ b/gcc/ipa-visibility.cc
@@ -872,6 +872,22 @@ function_and_variable_visibility (bool whole_program)
}
}
 }
+  FOR_EACH_VARIABLE (vnode)
+{
+  tree decl = vnode->decl;
+  
+  /* Optimize TLS model based on visibility (taking into account
+ optimizations done in the preceding loop), unless it was
+ specified explicitly.  */
+  
+  if (DECL_THREAD_LOCAL_P (decl)
+  && !lookup_attribute ("tls_model", DECL_ATTRIBUTES (decl)))
+{
+  enum tls_model new_model = decl_default_tls_model (decl);
+  gcc_checking_assert (new_model >= decl_tls_model (decl));
+  set_decl_tls_model (decl, new_model);
+}
+}
 
   if (dump_file)
 {
diff --git a/gcc/testsuite/gcc.dg/tls/vis-attr-gd.c 
b/gcc/testsuite/gcc.dg/tls/vis-attr-gd.c
new file mode 100644
index 000..473c7846f74
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tls/vis-attr-gd.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
+/* { dg-require-effective-target tls } */
+/* { dg-options "-O2 -fPIC -fdump-ipa-visibility" } */
+
+// tls_model should be global-dynamic due to explicitly specified attribute
+__attribute__((tls_model("global-dynamic")))
+__thread int x;
+
+/* { dg-final { scan-ipa-dump "Varpool flags: tls-global-dynamic" "visibility" 
} } */
diff --git a/gcc/testsuite/gcc.dg/tls/vis-attr-hidden-gd.c 
b/gcc/testsuite/gcc.dg/tls/vis-attr-hidden-gd.c
new file mode 100644
index 000..8f592052361
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tls/vis-attr-hidden-gd.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
+/* { dg-require-effective-target tls } */
+/* { dg-options "-O2 -fPIC -fdump-ipa-visibility" } */
+
+// tls_model should be global-dynamic due to explicitly specified attribute
+__attribute__((visibility("hidden")))
+__attribute__((tls_model("global-dynamic")))
+__thread int x;
+
+/* { dg-final { scan-ipa-dump "Varpool flags: tls-global-dynamic" "visibility" 
} } */
diff --git a/gcc/testsuite/gcc.dg/tls/vis-attr-hidden.c 
b/gcc/testsuite/gcc.dg/tls/vis-attr-hidden.c
new file mode 100644
index 000..2da1bc3fa42
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tls/vis-attr-hidden.c
@@ -0,0 +1,10 @@
+/* { dg-do compile } */
+/* { dg-require-effective-target fpic } */
+/* { dg-require-effective-target tls } */
+/* { dg-options "-O2 -fPIC -fdump-ipa-visibility" } */
+
+//tls_model should be local-dynamic due to visibility("hidden")
+__attribute__((visibility("hidden")))
+__thread int x;
+
+/* { dg-final { scan-ipa-dump "Varpool flags: tls-local-dynamic" "visibility" 
} } */
diff --git a/gcc/testsuite/gcc.dg/tls/vis-flag-hidden-gd.c 
b/gcc/testsuite/gcc.dg/tls/vis-flag-hidden-gd.c
new file mode 100644
index 000..de01ef31776
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/tls/vis-flag-hidden-gd.c
@@ -0,0 +1,11 @@
+/* { dg-do 

[Bug c++/105293] g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)

[estellnb at elstel dot org via Gcc-bugs]

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

--- Comment #4 from Elmar Stellnberger  ---
The related debian-security discussion can be found here: 
https://lists.debian.org/debian-security/2022/04/msg00042.html
(strangely I can not find my last posts when sorting by Thread, simple to see
with sorting by Date)

[Bug c++/105293] g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)

[estellnb at elstel dot org via Gcc-bugs]

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

--- Comment #3 from Elmar Stellnberger  ---
Created attachment 52823
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52823=edit
patch that should be useable under gcc-8-8.3.0/debian/patches/

  I have recompiled g++ and the output of dpkg-buildpackage -b
-kestel...@elstel.org -nc tells me that it should have successfully created the
respective .deb package files as before. I have looked into the same directory
as before but unfortunately I found not a single .deb there and nowhere else
under /usr/src. The files can only have been deleted like the ssh user from
/etc/passwd at my nslu2 machine. Another time I found out about a chmod -x
/etc/init.d/sshd as I suddenly could not connect to my nslu2 via ssh any more.
This looks very similar as what I have experienced with arm-linux-gnueabihf-ld
when the program did neither produce an error message, an !=0 return value and
no output file as given with -o txtfmt. This was when I had all options right
to what I can assess, i.e. just before it must have worked. As for now I can
not find out whether the patch really resolves the bug. Someone else will have
to be as nice to recompile for me.
  The patch makes a forward change to a known good g++ (version as suggested by
use of moc/Qt5 rather than by building Firefox however). It patches the only
piece of code that was different along the backtrace of Firefox-esr-91.8.0esr.

[Bug libstdc++/105291] include/c++/12.0.1/debug/safe_unordered_container.h:71:28: error: captured variable '__local_end' cannot appear here

[corentinjabot at gmail dot com via Gcc-bugs]

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

corentinjabot at gmail dot com changed:

   What|Removed |Added

 CC||corentinjabot at gmail dot com

--- Comment #4 from corentinjabot at gmail dot com ---
Agreed, clang should implement the proposed resolution to CWG2569 very soon so
there isn't anything that needs to change in libstdc++

Re: [PATCH] Add condition coverage profiling

[Jørgen Kvalsvik via Gcc-patches]

On 06/04/2022 09:35, Sebastian Huber wrote:
> Ok, for the default output this is good. The output can be explained in the
> documentation. I will try to help here.

Splendid, thanks! I would be perfectly happy with better and/or more intuitive
messages too, but I figured it shouldn't delay the rest of the algorithm.

> In theory, would it be possible to print the state of the truth table with the
> information available in the gcda and gcno files? For example:
> 
> Truth table for: a && (b || c)) && d
> 
> 0 | 1 | 2 | 3 || covered
> --+---+---+---++
> 0 | X | X | X || Y
> 0 | X | X | X || Y
> 0 | X | X | X || Y
> 0 | X | X | X || Y
> 0 | X | X | X || Y
> 0 | X | X | X || Y
> 0 | X | X | X || Y
> 0 | X | X | X || Y
> 1 | 0 | 0 | X || N
> 1 | 0 | 0 | X || N
> 1 | 0 | 1 | 0 || N
> 1 | 0 | 1 | 1 || N
> 1 | 1 | X | 0 || Y
> 1 | 1 | X | 0 || Y
> 1 | 1 | X | 1 || Y
> 1 | 1 | X | 1 || Y

Maybe? We would at least need to store the masking tables too, which right now
are implicitly stored as in the instrumentation. It's not too bad, but it
probably means the two functions should return some richer structure, which in
turn means a little bit of redesign. Computing the truth table itself shouldn't
be difficult.

> Would it be possible to map the condition index to a source code snippet? For
> example condition 1 to "b"?

Not sure - I didn't find an obvious way from location, but gcc is already able
to point to bad names in complex expressions so I'm sure it is doable. If it can
warn about possibly-uninitialized there's no reason it shouldn't be able to
figure this out. It has the basic block for the condition.

-

I think I have figured out the correct approach for computing masking vectors,
which means I should be able to submit the updated patch next week. I have a
little bit more testing to do before that, including trying out the nested-for
error Sebastian found.

I also went back on a decision:

if (a) if (b) if (c) { ... }; // no else

should be treated as if (a && b && c) {}. It is to be expected that a compiler
makes some minor transformations, and it is more correct that masking works for
(a && b && c) than for the (equivalent) nested-if being different expressions.
The same kind of "reinterpretation" happens with branch coverage, so there is
some precedence. This also means updating a few tests and figuring out how to
handle the conditions inserted by destructors. Do they have some special basic
block flag or property?

--
Thanks,
Jørgen

[Bug c++/104020] [coroutines] ICE in co_await function call with initializer_list arguments

[avi at scylladb dot com via Gcc-bugs]

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

Avi Kivity  changed:

   What|Removed |Added

 CC||avi at scylladb dot com

--- Comment #1 from Avi Kivity  ---
Duplicate of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98056

[Bug c++/105293] g++-8/i586: internal compiler error trying to compile with g++ (evtl. related to qt5/moc bug)

[estellnb at elstel dot org via Gcc-bugs]

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

--- Comment #2 from Elmar Stellnberger  ---
  One of the differences I see around the backtrace is that the type
source_location has been changed into location_t. I could change this in
tree-outof-ssa.c, but in reality the change has been made in many files between
gcc 8.3.0 and gcc 9.2.0 (did not find 9.2.1).
  Another change around the backtrace is that the following code block has been
stripped from pass_expand::execute:

if (chkp_function_instrumented_p (current_function_decl))
chkp_reset_rtl_bounds ();

  However the following in input.h would say it were without effect to change
location_t:

typedef source_location location_t;

  pass_expand is at the very bottom of the stack trace and if it is really
these two lines then great, but it could also be the data passed into this
process.

  The assert that fails is:
expr.c:220:  gcc_assert (from_mode != BLKmode);  // convert_move

from_mode originates from
389 copy_rtx(SA.partition_to_pseudo[src]) // insert_part_to_rtx_on_edge
733 g->stack_pop() -> src  // procedure eliminate_phi
909 elim_graph g(sa->map)  // procedure expand_phi_nodes

  On the other hand perhaps the issue could not even be resolved with 9.2.0.
This was just my first guess.

Re: [pushed] c++: rodata and defaulted ctor [PR104142]

[Andreas Schwab]

On Apr 11 2022, Jason Merrill via Gcc-patches wrote:

> diff --git a/gcc/testsuite/g++.dg/opt/const7.C 
> b/gcc/testsuite/g++.dg/opt/const7.C
> new file mode 100644
> index 000..5bcf94897a8
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/opt/const7.C
> @@ -0,0 +1,7 @@
> +// PR c++/104142
> +// { dg-do compile { target c++11 } }
> +// { dg-additional-options -Wunused-variable }
> +
> +struct B { B()=default; };
> +static const B b_var;//  { dg-bogus "" }
> +// { dg-final { scan-assembler-symbol-section {b_var} 
> {^\.(const|rodata)|\[RO\]} } }

That fails to handle .srodata.

-- 
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."