[Bug target/99488] dwz: /usr/lib/gcc/mips64el-linux-gnuabi64/11/go1: Found two copies of .debug_line_str section

[syq at debian dot org via Gcc-bugs]

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

--- Comment #11 from YunQiang Su  ---
This problem will happen when gcc is configured with
--with-build-config=bootstrap-lto-lean
Option.

[Bug fortran/100132] Optimization breaks pointer association

[jrfsousa at gmail dot com via Gcc-bugs]

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

--- Comment #1 from José Rui Faustino de Sousa  ---
Patch posted

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

[Bug fortran/100132] New: Optimization breaks pointer association

[jrfsousa at gmail dot com via Gcc-bugs]

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

Bug ID: 100132
   Summary: Optimization breaks pointer association
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jrfsousa at gmail dot com
  Target Milestone: ---

Created attachment 50622
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50622=edit
Fortran code showing problem

Hi All!

Pointer association is lost when compiling with -O1 or -O2, curiously not with
-O3 unless -fcheck=recursion is used

Seen on:

GNU Fortran (GCC) 11.0.1 20210417 (experimental)
GNU Fortran (GCC) 10.3.1 20210417
GNU Fortran (GCC) 9.3.1 20210417

Thank you very much.

Best regards,
José Rui

[Bug tree-optimization/100115] Bogus -Wmaybe-uninitialized warning with -O3

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

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

--- Comment #3 from Martin Sebor  ---
The reason why the warning tends to disappear in a simpler test case is because
of the limit (I just had it happen with my reduction).  Don't spend more time
on it than you already have, I'll work with the attached translation unit.  The
warning is exquisitely sensitive to optimizations so when GCC doesn't optimize
something in a way that lets it prove the uninitialized read is impossible, it
triggers.  I'm hoping to improve this for GCC 12.

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-04-17
   Keywords||wrong-code
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
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 ...

[Bug c++/95763] Feature request: compiler warning if line width exceeds N symbols

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
   Last reconfirmed||2021-04-17
 Ever confirmed|0   |1

--- Comment #5 from Andrew Pinski  ---
I assume you are talking about stuff like:
int t, t1, t2, t43, t55, t6, t788, t9, t999876, t323434, ttsdgsdg,
thfgd, tdfhghh, t354635463546;

?
If so confirmed. I have not looked into how to do this and if this is normally
not useful without a code style checker.

Having a code style checker part of GCC would be a good long term really.

[Bug middle-end/88175] GCC should not warn within implicit copy-constructor (or should report the implicit function in a special way)

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

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

--- Comment #19 from Jonathan Wakely  ---
Why is that needed? It says the location is something like:

In member function ‘info& info::operator=(const info&)’,

or:

In copy constructor ‘info::info(const info&)’,

If that isn't explicitly defined in the class, then obviously it's being
defined implicitly by the compiler. That property of C++ should not surprise
anybody.

[Bug middle-end/100062] Can't put DECL_STATIC_CONSTRUCTOR/DESTRUCTORs decls on comdat

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

--- Comment #2 from Iain Buclaw  ---
(In reply to Richard Biener from comment #1)
> Since you say this happens on a DSO level why is this not achieved via some
> additional object at link-time (like crt*.o)?  It sounds like you place
> the CDTOR in each object file instead and want to merge them in the linker
> via comdat?

Quite possibly, though I'd have to see if what is generated is readily
representable in C (or D) code.

That is correct, currently the CDTORs are put in each object file.  My initial
assumption is that it would be trivial to adapt get_section.

[Bug libstdc++/100128] Behavior and performance depends on order of ctype.h and stdlib.h include

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

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

--- Comment #2 from Jonathan Wakely  ---
(In reply to Jonathan Wakely from comment #1)
> Glibc should probably act as though __NO_CTYPE is implicitly defined by
> __cplusplus, so that the effect is independent of the order of includes.

Or it should define the ctype functions as C++ inline functions (without macros
hiding their names) so they can still be inlined.

[Bug bootstrap/95364] contrib/gcc_update -r 8712 does not work with git

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |trivial
Summary|[Regression]|contrib/gcc_update -r 8712
   |contrib/gcc_update -r 8712  |does not work with git
   |no longer works |

[Bug libstdc++/100128] Behavior and performance depends on order of ctype.h and stdlib.h include

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

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

--- Comment #1 from Jonathan Wakely  ---
(In reply to Travis Downs from comment #0)
> Evidently, the behavior and definitions exposed by these headers should not
> depend on the order of include. I suspect there are other cases besides the
> __NO_CTYPE as long as files that don't trigger the C++ header include chain
> like ctype.h exist.

I think that's the only one.

Glibc should probably act as though __NO_CTYPE is implicitly defined by
__cplusplus, so that the effect is independent of the order of includes.

Alternatively, libstdc++ could add its own  wrapper to ensure that we
always include os_defines.h before the libc .

[Bug c++/100124] Why is "flexible array member '...' in an otherwise empty '...'" an issue?

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

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

Martin Sebor  changed:

   What|Removed |Added

 Blocks||69698

--- Comment #5 from Martin Sebor  ---
G++ accepted structs where a flexible array is the sole member until version 6.
 G++ 6 tightened up the rules (in r231665) to more closely match the C front
end.  I suspect Clang implemented the more permissive historical G++ behavior
in C++ mode for compatibility with G++ and the stricter GCC behavior in C mode,
and to this day hasn't changed.  My impression is that the historical G++
permissiveness was due to oversights rather than deliberate features (we're
tracking a few such outstanding issues in pr69698 that are yet to be fixed).


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69698
[Bug 69698] [meta-bug] flexible array members

[Bug tree-optimization/95034] Failure to convert xor pattern (made out of or+and) to xor

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug sanitizer/100114] libasan built against latest glibc doesn't work

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

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

--- Comment #6 from Jakub Jelinek  ---
Fixed on the trunk so far, guess some backporting will be useful.

[Bug c/51971] unclear/unverified restrictions on attribute((const|pure))

[davidfromonline at gmail dot com via Gcc-bugs]

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

David Stone  changed:

   What|Removed |Added

 CC||davidfromonline at gmail dot 
com

--- Comment #4 from David Stone  ---
Here are more examples that are currently unclear:

```
struct a {
[[gnu::const]] a(): m(1) {}
int m;
};
```

If you think of a constructor as a function (that is named after the type) that
returns a value of that type, then the default constructor of `a` can safely be
marked `gnu::const`. If you think of a constructor as a member function that
gets a hidden `this` pointer passed in and then writes into that memory, then
the default constructor of `a` cannot even be marked `gnu::pure`.

```
struct b {
b(): m(1) {}
~b() {}
int m;
};

[[gnu::const]] b make_b() {
return b();
}
```

Because `b` is not trivially destructible, the Itanium ABI requires that the
return value passed by invisible reference. Here, whether it follows the
requirements of the attribute depend on the calling convention of your platform
if you take the "writing to memory in the return address is a side effect"
view.

The following function is not even `gnu::pure`, but it is not immediately
obvious why and the documentation should probably mention exception handling:

```
int c() {
try {
throw 1;
} catch(int) {
return 1;
}
}
```

The issue here is that `c()` could be called in a destructor, and that
destructor could be called during stack unwinding while handling another
exception (in which case `std::terminate()` is called rather than this function
returning 1).

Finally, the documentation is also not clear on what happens if you violate the
requirements. Richard Biener's comment suggests that you get some somewhat
unspecified result (some unspecified number of your calls might be replaced by
the result of another call), and what you are communicating to the compiler is
statements about whether side effects matter to you. Another possible
interpretation is that the behavior of the program is undefined on violation.
These are two very different models for what the attributes mean, but I suspect
only the "undefined behavior" model ends up actually being workable in the long
run. Consider the following code:

```
int d() {
int x;
std::vector temporary_buffer;
// do some work
return x;
}
```

>From the perspective of the world, this is logically `gnu::const`, assuming we
don't run out of memory. From the "You might get fewer calls and some of your
side effects might get discarded" model, I'm perfectly happy if the compiler
remembers this result of calling the function and doesn't allocate and
deallocate memory multiple times. My code doesn't handle `std::bad_alloc` so
I'm fine with it calling `std::terminate` in that rare case, but I'm also fine
with it not calling `std::terminate` in cases where I didn't have enough
memory, but the result was effectively cached by the compiler. I suspect this
will cause strange bugs in the optimizer if users adopt this model:

```
int e() {
// After some inlining
std::allocator::__some_internal_call();
d();
std::allocator::__some_other_internal_call();
}
```

These internal calls might expect consistent state of the allocator that can be
violated if `d` calls `allocate()`. It seems like a safer model to just come
right out and say that the behavior of your program is undefined if you violate
these requirements.

[Bug middle-end/88175] GCC should not warn within implicit copy-constructor (or should report the implicit function in a special way)

[jg at jguk dot org via Gcc-bugs]

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

--- Comment #18 from Jonny Grant  ---
Hello Martin
It looks better.
May I ask, if the "implicitly generated copy assignment" and "copy constructor"
could be mentioned in the warning that they were implicitly generated?
Thank you, Jonny

[Bug c++/100131] [meta-bug] internal compiler error: in hashtab_chk_error, at hash-table.c:137

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

Alexander Lelyakin  changed:

   What|Removed |Added

 CC||alexander.lelyakin@googlema
   ||il.com

--- Comment #1 from Alexander Lelyakin  ---
Here: 

http://lelyakin.de/hashtab/in%20hashtab_chk_error/

You can find much more examples of this error.

[Bug c++/99227] [meta] [modules] Bugs relating to header-units of STL header files

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

--- Comment #3 from Alexander Lelyakin  ---
During last two and a half weeks 
3 bugs was closed:
99283 - in assert_definition
99284 - in key_mergeable
99427 - non-constant condition for static assertion

99246 ICE in write_location was reopened under number 99915

And 3 added:
99948 - in add_mergeable_specialization 
99861 - in hashtab_chk_error
100129 - ICE free(): invalid pointer

There is a suspect that 99737,99479,99722,99948 are all somehow connected with
hashtab checking. At least some of examples change diagnostic with:
  --param=hash-table-verification-limit=1000

So here: 

 http://lelyakin.de/hashtab/

you can find results of slightly modified script that compiles system modules
with additional hashtab checking.

[Bug c++/100131] New: [meta-bug] internal compiler error: in hashtab_chk_error, at hash-table.c:137

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

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

Bug ID: 100131
   Summary: [meta-bug] internal compiler error: in
hashtab_chk_error, at hash-table.c:137
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
Blocks: 12, 91190, 93907, 97093, 99445
  Target Milestone: ---

hash table checking failed: equal operator returns true for a pair of values
with a different hash value
/export/gnu/import/git/gitlab/x86-gcc/gcc/testsuite/g++.dg/modules/xtreme-tr1_b.C:4:25:
internal compiler error: in hashtab_chk_error, at hash-table.c:137
0x8f2583 hashtab_chk_error()
/export/gnu/import/git/sources/gcc/gcc/hash-table.c:137
0xb01265 hash_table::verify(spec_entry*
const&, unsigned int)
/export/gnu/import/git/sources/gcc/gcc/hash-table.h:1033
0xb017ee hash_table::find_slot_with_hash(spec_entry* const&, unsigned int,
insert_option)
/export/gnu/import/git/sources/gcc/gcc/hash-table.h:968
0xabe57b match_mergeable_specialization(bool, spec_entry*)
/export/gnu/import/git/sources/gcc/gcc/cp/pt.c:29961
0xa37998 trees_in::key_mergeable(int, merge_kind, tree_node*, tree_node*,
tree_node*, tree_node*, bool)
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:10670
0xa3b594 trees_in::decl_value()
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:7903
0xa343f7 trees_in::tree_node(bool)
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:9153
0xa3aa1b module_state::read_cluster(unsigned int)
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:14811
0xa3af1d module_state::load_section(unsigned int, binding_slot*)
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:18082
0xa3d6b5 module_state::read_language(bool)
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:18011
0xa3d87e direct_import
/export/gnu/import/git/sources/gcc/gcc/cp/module.cc:18877
0xaa4f97 cp_parser_translation_unit
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:4907
0xaa4f97 c_parse_file()
/export/gnu/import/git/sources/gcc/gcc/cp/parser.c:45268
0xbc9a9d c_common_parse_file()
/export/gnu/import/git/sources/gcc/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.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91190
[Bug 91190] [10 Regression] ICE on valid code: in hashtab_chk_error, at
hash-table.c:137
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93907
[Bug 93907] [10 Regression] internal compiler error: in hashtab_chk_error, at
hash-table.c:137
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97093
[Bug 97093] ICE on C++20 code when chaining requirements (in hashtab_chk_error,
at hash-table.c:137)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99445
[Bug 99445] [11 Regression] ICE in hashtab_chk_error, at hash-table.c:137 since
r11-7011-g6e0a231a4aa2407b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12
[Bug 12] internal compiler error: in hashtab_chk_error, at hash-table.c:137

[Bug tree-optimization/100115] Bogus -Wmaybe-uninitialized warning with -O3

[boris at kolpackov dot net via Gcc-bugs]

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

--- Comment #2 from Boris Kolpackov  ---
> I'm trying to reduce the test case to something manageable but that can take 
> many hours, even days.

Right. On our side we have spent hours, even days trying to suppress this
warning (both by rearranging the code and with #pragma) but it keep popping up
in different places and on different targets (MinGW, Mac OS, etc). In fact,
we've wasted so much time on chasing this (and similar issues in the past),
that I am seriously considering just globally disabling this warning since it
seems more trouble than it's worth. Sorry, just venting a bit here...

> It would be really helpful if you could trim it down a bit, e.g., by removing 
> the biggest non-essentials like .

I will try. The thing is, such simplifications often make the warning
disappear. We have tens of similar code fragments in our codebase, but only
this one triggers a warning on x86_64-linux (other places trigger it on MinGW
and Mac OS).

> That being said, the context of the warning mentions std::optional which has 
> been known to be challenging for analysis [...]

Yes, I can confirm that most of the issues with this warning we've encountered
in the past involved std::optional.

[Bug d/99914] d: Template symbols not overridable by normal symbols

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

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

commit r11-8234-gbda519596543e49f77914b5677693e86be5d01d0
Author: Iain Buclaw 
Date:   Tue Apr 13 22:28:55 2021 +0200

d: Add TARGET_D_TEMPLATES_ALWAYS_COMDAT

Following up on the fix for PR99914, when testing on MinGW, it was found
not to support weak in the same way as on ELF or Mach-O targets.

So the linkage has been reverted back to COMDAT for that target, however
in order to properly support overriding functions and variables, all
declarations with external linkage must be put on COMDAT.  For this a
new target hook has been added to control the behavior.

gcc/ChangeLog:

PR d/99914
* config/i386/winnt-d.c (TARGET_D_TEMPLATES_ALWAYS_COMDAT): Define.
* doc/tm.texi: Regenerate.
* doc/tm.texi.in (D language and ABI): Add @hook for
TARGET_D_TEMPLATES_ALWAYS_COMDAT.

gcc/d/ChangeLog:

PR d/99914
* d-target.def (d_templates_always_comdat): New hook.
* d-tree.h (mark_needed): Remove prototype.
* decl.cc: Include d-target.h.
(mark_needed): Rename to...
(d_mark_needed): ...this.  Make static.
(set_linkage_for_decl): Put variables in comdat if
d_templates_always_comdat.

[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

   Last reconfirmed||2021-04-17
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |rsandifo at gcc dot 
gnu.org
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from rsandifo at gcc dot gnu.org  
---
Testing a patch.

[Bug middle-end/100130] New: 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

Bug ID: 100130
   Summary: R section flag handling doesn't cope with intervening
decls
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rsandifo at gcc dot gnu.org
  Target Milestone: ---

c-c++-common/attr-retain-7.c checks that we warn for:

int __attribute__((used,retain,section(".data.foo"))) foo2 = 2;
int __attribute__((section(".data.foo"))) foo1 = 1;

It also makes sure that we output two .section directives, one with
the R flag for foo2 and once without for foo1.

But this is all keyed on whether we try to “switch” to the same section.
It therefore doesn't work if there's an intervening decl, such as:

int __attribute__((used,retain,section(".data.foo"))) foo2 = 2;
int between = 1;
int __attribute__((section(".data.foo"))) foo1 = 1;

(-fno-toplevel-reorder should ensure this fails, but it fails for
me without as well.)

This also doesn't work for -fsection-anchors, which is what made
me look at it originally.  I guess that's a separate bug, but I think
it affects how this PR should be fixed.

[Bug libstdc++/58876] No non-virtual-dtor warning in std::unique_ptr

[db0451 at gmail dot com via Gcc-bugs]

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

DB  changed:

   What|Removed |Added

 CC||db0451 at gmail dot com

--- Comment #10 from DB  ---
Sorry to pester, but is this likely to get anywhere, any time soon? I fixed a
bug in one of my projects recently by using AddressSanitizer, which this
would've caught if it warned on non-polymorphic deletion via unique_ptr,
so it'd be nice to see.

I presume the same goes for std::shared_ptr, too.

[Bug fortran/98534] Intrinsic functions failing with unlimited polymorphic actual arguments

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

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

Paul Thomas  changed:

   What|Removed |Added

   Assignee|pault at gcc dot gnu.org   |unassigned at gcc dot 
gnu.org
 CC||burnus at gcc dot gnu.org

--- Comment #4 from Paul Thomas  ---
This needs to be incorporated into the fix for PR100027. I hope that Jose takes
this PR over :-)

Paul

[Bug fortran/100027] ICE on storage_size with polymorphic argument

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #3 from Paul Thomas  ---
(In reply to José Rui Faustino de Sousa from comment #1)
> Patch posted
> 
> https://gcc.gnu.org/pipermail/fortran/2021-April/055922.html

Hi Jose,

Please take a look at PR98534. I think that you need to adjust your patch a
little bit to take account of unlimited polymorphic entities with character
dynamic type. I agree that it is a bit of a corner case but it is as well that
your patch be complete.

I will remove myself as the assignee.

Best regards

Paul

[Bug sanitizer/100114] libasan built against latest glibc doesn't work

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

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

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

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

commit r11-8230-gd9f462fb372fb02da032cefd6b091d7582c425ae
Author: Jakub Jelinek 
Date:   Sat Apr 17 11:27:14 2021 +0200

sanitizer: Fix asan against glibc 2.34 [PR100114]

As mentioned in the PR, SIGSTKSZ is no longer a compile time constant in
glibc 2.34 and later, so
static const uptr kAltStackSize = SIGSTKSZ * 4;
needs dynamic initialization, but is used by a function called indirectly
from .preinit_array and therefore before the variable is constructed.
This results in using 0 size instead and all asan instrumented programs
die with:
==91==ERROR: AddressSanitizer failed to allocate 0x0 (0) bytes of
SetAlternateSignalStack (error code: 22)

Here is a cherry-pick from upstream to fix this.

2021-04-17  Jakub Jelinek  

PR sanitizer/100114
* sanitizer_common/sanitizer_posix_libcdep.cpp: Cherry-pick
llvm-project revisions 82150606fb11d28813ae6da1101f5bda638165fe
and b93629dd335ffee2fc4b9b619bf86c3f9e6b0023.

[Bug target/99555] [OpenMP/nvptx] Execution-time hang for simple nested OpenMP 'target'/'parallel'/'task' constructs

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

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

Tom de Vries  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #6 from Tom de Vries  ---
Current theory ...

All omp-threads are supposed to participate in a team barrier, and then all
together move on.  The master omp-thread participates from gomp_team_end, the
other omp-threads from the worker loop in gomp_thread_start.

Instead, it seems the master omp-thread gets stuck at the team barrier, while
all other omp-threads move on, to the thread pool barrier, and that state
corresponds to the observed hang.

AFAICT, the problem starts when gomp_team_barrier_wake is called with count ==
1:
...
void
gomp_team_barrier_wake (gomp_barrier_t *bar, int count)
{
  if (bar->total > 1)
asm ("bar.sync 1, %0;" : : "r" (32 * bar->total));
}
...
The count argument is ignored, and instead all omp-threads are woken up, which
causes omp-threads to escape the team barrier.

This all is a result of the gomp_barrier_handle_tasks path being taken in
gomp_team_barrier_wait_end, and I haven't figured out why that is triggered, so
it still may be that the root cause lies elsewhere.

Anyway, the nvptx bar.{c,h} is copied from linux/bar.{c,h}, which is
implemented using futex, and with futex uses replaced with bar.sync uses.

FWIW, replacing libgomp/config/nvptx/bar.{c,h} with libgomp/config/posix.{c,h}
fixes the problem.  Did a full libgomp test run, all problems fixed.

[Bug c++/100129] New: [modules] ICE free(): invalid pointer

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

Bug ID: 100129
   Summary: [modules] ICE free(): invalid pointer
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexander.lelyakin at googlemail dot com
  Target Milestone: ---

/usr/local/bin/g++ --param=hash-table-verification-limit=1000 -std=c++20
-fmodules-ts -x c++-system-header execution
/usr/local/bin/g++ --param=hash-table-verification-limit=1000 -std=c++20
-fmodules-ts -x c++-system-header limits
/usr/local/bin/g++ --param=hash-table-verification-limit=1000 -std=c++20
-fmodules-ts -x c++-system-header unordered_set
/usr/local/bin/g++ --param=hash-table-verification-limit=1000 -std=c++20
-fmodules-ts -x c++-system-header stack
/usr/local/bin/g++ --param=hash-table-verification-limit=1000 -std=c++20
-fmodules-ts -x c++-system-header condition_variable
/usr/local/bin/g++ --param=hash-table-verification-limit=1000 -std=c++20
-fmodules-ts -x c++-system-header future

free(): invalid pointer
g++: internal compiler error: Segmentation fault signal terminated program
cc1plus
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

g++ (GCC) 11.0.1 20210416 (experimental)
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 c++/99722] [modules] internal compiler error: segmentation fault

[alexander.lelyakin at googlemail dot com via Gcc-bugs]

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

--- Comment #1 from Alexander Lelyakin  ---
All so far found examples of such error message 
change its behavior if you add the parameter:
  --param=hash-table-verification-limit=1000

Most of them to the error message: ICE in hashtab_chk_error.

[Bug c++/100002] internal compiler error: in hashtab_chk_error, at hash-table.c:137

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code

--- Comment #1 from Andrew Pinski  ---
So just a quick look into this (not reproduced though).

This would mean comp_template_args is returning true but the hash give by
iterative_hash_template_arg is different.

The only thing -mrtm changes would change is the DECL_UIDs which is the
starting hash.