[Bug rtl-optimization/96993] [10/11 Regression] invalid code

[pinskia at gcc dot gnu.org]

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

--- Comment #4 from Andrew Pinski  ---
Is there any reason why you didn't use offsetof/__builtin_offsetof here?
Instead of playing tricks like:
(tUint8 *)(&((struct tmm_blk_free_head_t *)0)->ql.column_list)

[Bug rtl-optimization/96993] [10/11 Regression] invalid code

[jan.smets at nokia dot com]

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

--- Comment #3 from Jan Smets  ---
The testcase has a sign-compare warning that we've traditionally been ignoring
given the ancient codebase. 

warning: operand of ‘?:’ changes signedness from ‘int’ to ‘long unsigned int’
due to unsignedness of other operand [-Wsign-compare]

Changing the testcase From:

 ((address_ != (0L)) ? (tUint8 *)(address_) - (tUint8 *)(&((struct
tmm_blk_free_head_t *)0)->ql.column_list) : (uintptr_t)(0L));

To:

 ((address_ != (0L)) ? (uintptr_t)(tUint8 *)(address_) - (uintptr_t)(tUint8
*)(&((struct tmm_blk_free_head_t *)0)->ql.column_list) : (uintptr_t)(0L));

will generate different code in GCC 10, whereas it generates the same code in
GCC 9 for both forms.
 (with the added casts the generated GCC 10 code is good), 


commit 810c42c38d37317c80b57db0a8b6d8991e78ef50
Author: Richard Biener 
Date:   Mon May 20 12:02:35 2019 +

tree-ssa-structalias.c (find_func_aliases): POINTER_DIFF_EXPR doesn't
produce pointers.

2019-05-20  Richard Biener  

* tree-ssa-structalias.c (find_func_aliases): POINTER_DIFF_EXPR
doesn't produce pointers.
{TRUNC,CEIL,FLOOR,ROUND,EXACT}_{DIV,MOD}_EXPR points to what
the first operand points to.

From-SVN: r271414


I've been trying to get a working/crashing testcase for you, but finding the
right 'input data' to trigger the behavior for my testcase seems a bit
problematic.

[Bug target/97005] New: [nvptx] FAIL: c-c++-common/torture/builtin-arith-overflow-15.c -O0 execution test

[vries at gcc dot gnu.org]

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

Bug ID: 97005
   Summary: [nvptx] FAIL:
c-c++-common/torture/builtin-arith-overflow-15.c   -O0
 execution test
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Minimized to:
...
$ cat builtin-arith-overflow-15.c
int
main (void)
{
  signed char r;
  unsigned char y = (unsigned char) 0x80;

  if (__builtin_sub_overflow ((unsigned char)0,
  (unsigned char)y,
  ))
__builtin_abort ();

  return 0;
}
...

Compile like this:
...
$ ./build-gcc/gcc/xgcc \
-B./build-gcc/gcc/ \
builtin-arith-overflow-15.c \
-O0  \
-L./build-gcc/nvptx-none/./newlib \
-mmainkernel \
-o ./builtin-arith-overflow-15.exe
...

Run:
...
$ ./install/bin/nvptx-none-run ./builtin-arith-overflow-15.exe 
nvptx-run: error getting kernel result: an illegal instruction was encountered
(CUDA_ERROR_ILLEGAL_INSTRUCTION, 715)
...

[Bug middle-end/96903] [11 regression] excess errors from gcc.dg/pr89350.c after r11-2973

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553550.html

[Bug target/96791] ICE in convert_mode_scalar, at expr.c:412

[acsawdey at gcc dot gnu.org]

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

--- Comment #9 from acsawdey at gcc dot gnu.org ---
I did post a small patch that fixes this, but more for the purpose of provoking
discussion than because I am sure it is the right way to fix this.

https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553523.html

[Bug target/97004] New: [nvptx] __int128 initializer incorrect

[vries at gcc dot gnu.org]

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

Bug ID: 97004
   Summary: [nvptx] __int128 initializer incorrect
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

Consider this code from c-c++-common/spec-barrier-1.c:
...
#ifdef __SIZEOF_INT128__
__int128 g = 9;
#endif
...

We seem to be generating:
...
// BEGIN GLOBAL VAR DEF: g
.visible .global .align 8 .u64 g[2] =
{9,9 };
...

[Bug c++/91427] Implement P1825R0, Merged wording for P0527R1 and P1155R3

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Implemented for GCC 11.

[Bug c++/96994] Missing code from consteval constructor initializing const variable

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
   Last reconfirmed||2020-09-09
   Keywords||wrong-code
 Ever confirmed|0   |1

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

[Bug c++/88323] implement C++20 language features.

[jason at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88323
Bug 88323 depends on bug 91427, which changed state.

Bug 91427 Summary: Implement P1825R0, Merged wording for P0527R1 and P1155R3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91427

   What|Removed |Added

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

[Bug analyzer/94355] support for C++ new expression

[dmalcolm at gcc dot gnu.org]

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

--- Comment #4 from David Malcolm  ---
(In reply to Ivan Sorokin from comment #0)
> At the moment static analyzer warns about leaked malloc. It would be great
> if C++ new expression were also supported.
> 
> Example:
> 
> void f()
> {
> char* p = new char;
> }
> 
> Expected diagnostic:
> 
> warning: leak of 'p' [CWE-401] [-Wanalyzer-malloc-leak]
> 
> 3 | char* p = new char;

Actual diagnostic with commit
r11-3090-g1690a839cff2e0276017a013419d81d675bbf69d:

demo.cc: In function ‘void f()’:
demo.cc:4:1: warning: leak of ‘p’ [CWE-401] [-Wanalyzer-malloc-leak]
4 | }
  | ^
  ‘void f()’: events 1-2
|
|3 | char* p = new char;
|  |   ^~~~
|  |   |
|  |   (1) allocated here
|4 | }
|  | ~  
|  | |
|  | (2) ‘p’ leaks here; was allocated at (1)
|

where the diagnostic's location is at the point where "p" goes out of scope. 
There's an argument that it would be better emitting it at the "new".

[Bug c++/77841] a new expression of a char array cannot be initialized by a string literal

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Fixed in GCC 11.

[Bug c++/77841] a new expression of a char array cannot be initialized by a string literal

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:81de459ec7ccf46c3e5a776b0c13f01e989d9593

commit r11-3092-g81de459ec7ccf46c3e5a776b0c13f01e989d9593
Author: Marek Polacek 
Date:   Sat Sep 5 20:50:32 2020 -0400

c++: Further tweaks for new-expression and paren-init [PR77841]

This patch corrects our handling of array new-expression with ()-init:

  new int[4](1, 2, 3, 4);

should work even with the explicit array bound, and

  new char[3]("so_sad");

should cause an error, but we weren't giving any.

Fixed by handling array new-expressions with ()-init in the same spot
where we deduce the array bound in array new-expression.  I'm now
always passing STRING_CSTs to build_new_1 wrapped in { } which allowed
me to remove the special handling of STRING_CSTs in build_new_1.  And
since the DIRECT_LIST_INIT_P block in build_new_1 calls digest_init, we
report errors about too short arrays. reshape_init now does the {"foo"}
-> "foo" transformation even for CONSTRUCTOR_IS_PAREN_INIT, so no need
to do it in build_new.

I took a stab at cp_complete_array_type's "FIXME: this code is duplicated
from reshape_init", but calling reshape_init there, I ran into issues
with has_designator_problem: when we reshape an already reshaped
CONSTRUCTOR again, d.cur.index has been filled, so we think that we
have a user-provided designator (though there was no designator in the
source code), and report an error.

gcc/cp/ChangeLog:

PR c++/77841
* decl.c (reshape_init): If we're initializing a char array from
a string-literal that is enclosed in braces, unwrap it.
* init.c (build_new_1): Don't handle string-initializers here.
(build_new): Handle new-expression with paren-init when the
array bound is known.  Always pass string constants to build_new_1
enclosed in braces.  Don't handle string-initializers in any
special way.

gcc/testsuite/ChangeLog:

PR c++/77841
* g++.old-deja/g++.ext/arrnew2.C: Expect the error only in C++17
and less.
* g++.old-deja/g++.robertl/eb58.C: Adjust dg-error.
* g++.old-deja/g++.robertl/eb63.C: Expect the error only in C++17
and less.
* g++.dg/cpp2a/new-array5.C: New test.
* g++.dg/cpp2a/paren-init36.C: New test.
* g++.dg/cpp2a/paren-init37.C: New test.
* g++.dg/pr84729.C: Adjust dg-error.

[Bug middle-end/92942] missing -Wstringop-overflow for allocations with a negative lower bound size

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #2 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-August/552903.html

[Bug analyzer/94355] support for C++ new expression

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2020-09-09

--- Comment #3 from David Malcolm  ---
The above patch is an initial implementation of new/delete support; it works
for the simplest cases.

As noted in the commit message this patch was mostly about generalizing the
sm-malloc.cc code; the implementation of new/delete will no doubt need much
further refinement (and beyond that, the analyzer doesn't yet know about
vfuncs, exceptions, inheritance, RTTI, etc)

Specific things still to be investigated relating to new/delete (if only to add
test coverage):
* all of the various cases seen at
https://en.cppreference.com/w/cpp/memory/new/operator_new
* placement new
* global and class-specific replacements for operator new/new[]
* exceptions vs non-throwing allocators vs -fno-exceptions
* verify that ctors/dtors are simulated appropriately for both scalar and
vector new/delete

Anything else?

Note to self: see also https://en.cppreference.com/w/cpp/language/new

[Bug c++/95164] [9 Regression] ICE regression starting with 9.3

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
Summary|[9/10/11 Regression] ICE|[9 Regression] ICE
   |regression starting with|regression starting with
   |9.3 |9.3
 Resolution|--- |FIXED

--- Comment #7 from Marek Polacek  ---
Fixed.

[Bug c++/95164] [9/10/11 Regression] ICE regression starting with 9.3

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Marek Polacek
:

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

commit r10-8723-gf63831405a32287dea2862ce3663675cc5b55180
Author: Marek Polacek 
Date:   Fri Sep 4 16:04:26 2020 -0400

c++: Fix ICE in reshape_init with init-list [PR95164]

This patch fixes a long-standing bug in reshape_init_r.  Since r209314
we implement DR 1467 which handles list-initialization with a single
initializer of the same type as the target.  In this test this causes
a crash in reshape_init_r when we're processing a constructor that has
undergone the DR 1467 transformation.

Take e.g. the

  foo({{1, {H{k);

line in the attached test.  {H{k}} initializes the field b of H in I.
H{k} is a functional cast, so has TREE_HAS_CONSTRUCTOR set, so is
COMPOUND_LITERAL_P.  We perform the DR 1467 transformation and turn
{H{k}} into H{k}.  Then we attempt to reshape H{k} again and since
first_initializer_p is null and it's COMPOUND_LITERAL_P, we go here:

   else if (COMPOUND_LITERAL_P (stripped_init))
 gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));

then complain about the missing braces, go to reshape_init_class and ICE
on
   gcc_checking_assert (d->cur->index
== get_class_binding (type, id));

because due to the missing { } we're looking for 'b' in H, but that's
not found.

So we have to be prepared to handle an initializer whose outer braces
have been removed due to DR 1467.

gcc/cp/ChangeLog:

PR c++/95164
* decl.c (reshape_init_r): When initializing an aggregate member
with an initializer from an initializer-list, also consider
COMPOUND_LITERAL_P.

gcc/testsuite/ChangeLog:

PR c++/95164
* g++.dg/cpp0x/initlist123.C: New test.

(cherry picked from commit acbe30bbc884899da72df47d023ebde89f8f47f1)

[Bug c++/95164] [9/10/11 Regression] ICE regression starting with 9.3

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-3091-gacbe30bbc884899da72df47d023ebde89f8f47f1
Author: Marek Polacek 
Date:   Fri Sep 4 16:04:26 2020 -0400

c++: Fix ICE in reshape_init with init-list [PR95164]

This patch fixes a long-standing bug in reshape_init_r.  Since r209314
we implement DR 1467 which handles list-initialization with a single
initializer of the same type as the target.  In this test this causes
a crash in reshape_init_r when we're processing a constructor that has
undergone the DR 1467 transformation.

Take e.g. the

  foo({{1, {H{k);

line in the attached test.  {H{k}} initializes the field b of H in I.
H{k} is a functional cast, so has TREE_HAS_CONSTRUCTOR set, so is
COMPOUND_LITERAL_P.  We perform the DR 1467 transformation and turn
{H{k}} into H{k}.  Then we attempt to reshape H{k} again and since
first_initializer_p is null and it's COMPOUND_LITERAL_P, we go here:

   else if (COMPOUND_LITERAL_P (stripped_init))
 gcc_assert (!BRACE_ENCLOSED_INITIALIZER_P (stripped_init));

then complain about the missing braces, go to reshape_init_class and ICE
on
   gcc_checking_assert (d->cur->index
== get_class_binding (type, id));

because due to the missing { } we're looking for 'b' in H, but that's
not found.

So we have to be prepared to handle an initializer whose outer braces
have been removed due to DR 1467.

gcc/cp/ChangeLog:

PR c++/95164
* decl.c (reshape_init_r): When initializing an aggregate member
with an initializer from an initializer-list, also consider
COMPOUND_LITERAL_P.

gcc/testsuite/ChangeLog:

PR c++/95164
* g++.dg/cpp0x/initlist123.C: New test.

[Bug fortran/97003] Error: gfortran: No such file or directory and GNU gortran is nor working

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |INVALID

--- Comment #1 from kargl at gcc dot gnu.org ---
(In reply to Seager Du from comment #0)
> Created attachment 49205 [details]
> The configure log with the error information
> 
> Compiled the Gcc as the following on the ubuntu 18.04.
> 1) sudo apt update
> 2) sudo apt upgrade
> 3) contrib/download_prerequisites
> 4) ./configure --prefix=/usr/local/gcc63 --program-suffix=63
> --enable-languages=c,c++,fortran --disable-multilib

Please the instruction for installing GCC at https://gcc.gnu.org/install/

Your step 4) is invalidate.

[Bug fortran/97003] New: Error: gfortran: No such file or directory and GNU gortran is nor working

[xianping.du at gmail dot com]

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

Bug ID: 97003
   Summary: Error: gfortran: No such file or directory and GNU
gortran is nor working
   Product: gcc
   Version: 6.3.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xianping.du at gmail dot com
  Target Milestone: ---
Target: Gcc -7.5.0
 Build: Gcc- 6.3.0

Created attachment 49205
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49205=edit
The configure log with the error information

Compiled the Gcc as the following on the ubuntu 18.04.
1) sudo apt update
2) sudo apt upgrade
3) contrib/download_prerequisites
4) ./configure --prefix=/usr/local/gcc63 --program-suffix=63
--enable-languages=c,c++,fortran --disable-multilib
5) make -j 4

Error is reported as attached with the critical area copied here.
#
/home/seager/Downloads/gcc-6.3.0/libgfortran/configure: line 1897:
/home/seager/Downloads/gcc-6.3.0/host-x86_64-pc-linux-gnu/gcc/gfortran: No such
file or directory
configure:15673: $? = 127
configure: failed program was:
| 
|   program foo
|   real, parameter :: bar = sin (12.34 / 2.5)
|   end program foo
configure:15677: result: no
configure:15679: error: GNU Fortran is not working; please report a bug in
http://gcc.gnu.org/bugzilla, attaching
/home/seager/Downloads/gcc-6.3.0/x86_64-pc-linux-gnu/libgfortran/config.log
###

I can understand the problem, but I do not know how to fix it. Is there someone
can help on this issue? Thank you for any help.

[Bug analyzer/94355] support for C++ new expression

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by David Malcolm :

https://gcc.gnu.org/g:1690a839cff2e0276017a013419d81d675bbf69d

commit r11-3090-g1690a839cff2e0276017a013419d81d675bbf69d
Author: David Malcolm 
Date:   Fri Aug 28 13:43:56 2020 -0400

analyzer: generalize sm-malloc to new/delete [PR94355]

This patch generalizes the state machine in sm-malloc.c to support
multiple allocator APIs, and adds just enough support for C++ new and
delete to demonstrate the feature, allowing for detection of code
paths where the result of new in C++ can leak - for some crude examples,
at least (bearing in mind that the analyzer doesn't yet know about
e.g. vfuncs, exceptions, inheritance, RTTI, etc)

It also implements a new warning: -Wanalyzer-mismatching-deallocation.
For example:

demo.cc: In function 'void test()':
demo.cc:8:8: warning: 'f' should have been deallocated with 'delete'
  but was deallocated with 'free' [CWE-762]
[-Wanalyzer-mismatching-deallocation]
8 |   free (f);
  |   ~^~~
  'void test()': events 1-2
|
|7 |   foo *f = new foo;
|  |^~~
|  ||
|  |(1) allocated here (expects deallocation with
'delete')
|8 |   free (f);
|  |   
|  ||
|  |(2) deallocated with 'free' here; allocation at (1)
expects deallocation with 'delete'
|

The patch also adds just enough knowledge of exception-handling to
suppress a false positive from -Wanalyzer-malloc-leak on
g++.dg/analyzer/pr96723.C on the exception-handling CFG edge after
operator new.  It does this by adding a constraint that the result is
NULL if an exception was thrown from operator new, since the result from
operator new is lost when following that exception-handling CFG edge.

gcc/analyzer/ChangeLog:
PR analyzer/94355
* analyzer.opt (Wanalyzer-mismatching-deallocation): New warning.
* region-model-impl-calls.cc
(region_model::impl_call_operator_new): New.
(region_model::impl_call_operator_delete): New.
* region-model.cc (region_model::on_call_pre): Detect operator new
and operator delete.
(region_model::on_call_post): Likewise.
(region_model::maybe_update_for_edge): Detect EH edges and call...
(region_model::apply_constraints_for_exception): New function.
* region-model.h (region_model::impl_call_operator_new): New decl.
(region_model::impl_call_operator_delete): New decl.
(region_model::apply_constraints_for_exception): New decl.
* sm-malloc.cc (enum resource_state): New.
(struct allocation_state): New state subclass.
(enum wording): New.
(struct api): New.
(malloc_state_machine::custom_data_t): New typedef.
(malloc_state_machine::add_state): New decl.
(malloc_state_machine::m_unchecked)
(malloc_state_machine::m_nonnull)
(malloc_state_machine::m_freed): Delete these states in favor
of...
(malloc_state_machine::m_malloc)
(malloc_state_machine::m_scalar_new)
(malloc_state_machine::m_vector_new): ...this new api instances,
which own their own versions of these states.
(malloc_state_machine::on_allocator_call): New decl.
(malloc_state_machine::on_deallocator_call): New decl.
(api::api): New ctor.
(dyn_cast_allocation_state): New.
(as_a_allocation_state): New.
(get_rs): New.
(unchecked_p): New.
(nonnull_p): New.
(freed_p): New.
(malloc_diagnostic::describe_state_change): Use unchecked_p and
nonnull_p.
(class mismatching_deallocation): New.
(double_free::double_free): Add funcname param for initializing
m_funcname.
(double_free::emit): Use m_funcname in warning message rather
than hardcoding "free".
(double_free::describe_state_change): Likewise.  Use freed_p.
(double_free::describe_call_with_state): Use freed_p.
(double_free::describe_final_event): Use m_funcname in message
rather than hardcoding "free".
(double_free::m_funcname): New field.
(possible_null::describe_state_change): Use unchecked_p.
(possible_null::describe_return_of_state): Likewise.
(use_after_free::use_after_free): Add param for initializing m_api.
(use_after_free::emit): Use m_api->m_dealloc_funcname in message
rather than hardcoding "free".
(use_after_free::describe_state_change): Use freed_p.  

[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop

[segher at gcc dot gnu.org]

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

--- Comment #12 from Segher Boessenkool  ---
Thanks.  Unfortunately it isn't saying much more (well, during which
pass this happened, pretty important ;-) )

> I can prepare the preprocessed source tomorrow if needed.

Thanks!  That will make reproducing the problem much simpler.

[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop

[clyon at gcc dot gnu.org]

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

--- Comment #11 from Christophe Lyon  ---
Ha sorry I missed the beginning (interleaved in the log with other commands):
during RTL pass: sched_fusion
vfprintf-internal.c: In function '__vfprintf_internal':
vfprintf-internal.c:1702:1: internal compiler error: in operator[], at
vec.h:880
 1702 | }
  | ^
0x82a054 vec::operator[](unsigned int)
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/vec.h:880
0x82a054 pre_and_rev_post_order_compute_fn(function*, int*, int*, bool)
   
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/cfganal.c:1036
0x82a0b7 pre_and_rev_post_order_compute(int*, int*, bool)
   
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/cfganal.c:1050
0x7db017 init_alias_analysis()
   
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/alias.c:3392
0x180c862 sched_init()
   
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/haifa-sched.c:7326
0x180e1ed haifa_sched_init()
   
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/haifa-sched.c:7363
0xcd64dc schedule_insns
   
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sched-rgn.c:3514
0xcd6da0 schedule_insns
   
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sched-rgn.c:3930
0xcd6da0 rest_of_handle_sched_fusion
   
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sched-rgn.c:3757
0xcd6da0 execute
   
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sched-rgn.c:3932


I can prepare the preprocessed source tomorrow if needed.


The full compilation command:
/tmp/4800342_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/bin/aarch64-none-linux-gnu-gcc
vfprintf-internal.c -c -std=gnu11 -fgnu89-inline  -g -O2 -Wall -Wwrite-strings
-Wundef -fmerge-all-const
ants -frounding-math -fno-stack-protector -Wstrict-prototypes
-Wold-style-definition -fmath-errno  -ftls-model=initial-exec 
-I../include -I/tmp/4800342_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-
gccsrc/obj-aarch64-none-linux-gnu/glibc-1/stdio-common 
-I/tmp/4800342_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/glibc-1
 -I../sysdeps/unix/sysv/linux/aarch64  -I../sysd
eps/aarch64/nptl  -I../sysdeps/unix/sysv/linux/generic 
-I../sysdeps/unix/sysv/linux/wordsize-64  -I../sysdeps/unix/sysv/linux/include
-I../sysdeps/unix/sysv/linux  -I../sysdeps/nptl  -I../sysdeps/
pthread  -I../sysdeps/gnu  -I../sysdeps/unix/inet  -I../sysdeps/unix/sysv 
-I../sysdeps/unix  -I../sysdeps/posix  -I../sysdeps/aarch64/fpu 
-I../sysdeps/aarch64/multiarch  -I../sysdeps/aarch64  -I.
./sysdeps/wordsize-64  -I../sysdeps/ieee754/ldbl-128 
-I../sysdeps/ieee754/dbl-64/wordsize-64  -I../sysdeps/ieee754/dbl-64 
-I../sysdeps/ieee754/flt-32  -I../sysdeps/ieee754  -I../sysdeps/generic  
-I.. -I../libio -I. -nostdinc -isystem
/tmp/4800342_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/tools/lib/gcc/aarch64-none-linux-gnu/11.0.0/include
-isystem /tmp/4800342_6.tmpdir/aci-gcc-fsf/builds/
gcc-fsf-gccsrc/tools/lib/gcc/aarch64-none-linux-gnu/11.0.0/include-fixed
-isystem
/tmp/4800342_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/sysroot-aarch64-none-linux-gnu/usr/include
 -D_LIBC_REENTRA
NT -include
/tmp/4800342_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/glibc-1/libc-modules.h
-DMODULE_NAME=libc -include ../include/libc-symbols.h   -DTOP_NAMESPACE=gli
bc -D_IO_MTSAFE_IO -o
/tmp/4800342_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/glibc-1/stdio-common/vfprintf-internal.o
-MD -MP -MF /tmp/4800342_6.tmpdir/aci-gcc-fsf/build
s/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/glibc-1/stdio-common/vfprintf-internal.o.dt
-MT
/tmp/4800342_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/glibc-1/stdio-common/v
fprintf-internal.o

[Bug libfortran/96890] Wrong answer with intrinsic IALL

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

Thanks for the report!

[Bug libfortran/96890] Wrong answer with intrinsic IALL

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Harald Anlauf
:

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

commit r8-10441-gb8c7eae4be6fccfe24ed36d618c0f2d67256e993
Author: Harald Anlauf 
Date:   Thu Sep 3 20:33:14 2020 +0200

PR fortran/96890 - Wrong answer with intrinsic IALL

The IALL intrinsic would always return 0 when the DIM and MASK arguments
were present since the initial value of repeated BIT-AND operations was
set to 0 instead of -1.

libgfortran/ChangeLog:

* m4/iall.m4: Initial value for result should be -1.
* generated/iall_i1.c (miall_i1): Generated.
* generated/iall_i16.c (miall_i16): Likewise.
* generated/iall_i2.c (miall_i2): Likewise.
* generated/iall_i4.c (miall_i4): Likewise.
* generated/iall_i8.c (miall_i8): Likewise.

gcc/testsuite/ChangeLog:

* gfortran.dg/iall_masked.f90: New test.

(cherry picked from commit 8cbcc17041fdfd3ccc928161ae86e7f9b456)

[Bug libfortran/96890] Wrong answer with intrinsic IALL

[cvs-commit at gcc dot gnu.org]

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:32f34977d60cafce47e10e601d7ccc7bbfbfabb9

commit r9-8854-g32f34977d60cafce47e10e601d7ccc7bbfbfabb9
Author: Harald Anlauf 
Date:   Thu Sep 3 20:33:14 2020 +0200

PR fortran/96890 - Wrong answer with intrinsic IALL

The IALL intrinsic would always return 0 when the DIM and MASK arguments
were present since the initial value of repeated BIT-AND operations was
set to 0 instead of -1.

libgfortran/ChangeLog:

* m4/iall.m4: Initial value for result should be -1.
* generated/iall_i1.c (miall_i1): Generated.
* generated/iall_i16.c (miall_i16): Likewise.
* generated/iall_i2.c (miall_i2): Likewise.
* generated/iall_i4.c (miall_i4): Likewise.
* generated/iall_i8.c (miall_i8): Likewise.

gcc/testsuite/ChangeLog:

* gfortran.dg/iall_masked.f90: New test.

(cherry picked from commit 8cbcc17041fdfd3ccc928161ae86e7f9b456)

[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop

[segher at gcc dot gnu.org]

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

--- Comment #10 from Segher Boessenkool  ---
Please show the full message?  (It starts with "internal compiler error".)

[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop

[clyon at gcc dot gnu.org]

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

Christophe Lyon  changed:

   What|Removed |Added

 CC||clyon at gcc dot gnu.org

--- Comment #9 from Christophe Lyon  ---
(In reply to Segher Boessenkool from comment #8)
> Fixed on trunk.  Needs backports.

This is causing ICEs when compiling glibc (2.29) for
aarch64-none-linux-gnu and 
arm-none-linux-gnueabihf --with-mode=thumb --with-cpu=cortex-a15
--with-fpu=neon-vfpv4

0x82a054 vec::operator[](unsigned int)
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/vec.h:880
0x82a054 pre_and_rev_post_order_compute_fn(function*, int*, int*, bool)
   
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/cfganal.c:1036
0x82a0b7 pre_and_rev_post_order_compute(int*, int*, bool)
   
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/cfganal.c:1050
0x7db017 init_alias_analysis()
   
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/alias.c:3392
0x180c862 sched_init()
   
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/haifa-sched.c:7326
0x180e1ed haifa_sched_init()
   
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/haifa-sched.c:7363
0xcd64dc schedule_insns
   
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sched-rgn.c:3514
0xcd6da0 schedule_insns
   
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sched-rgn.c:3930
0xcd6da0 rest_of_handle_sched_fusion
   
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sched-rgn.c:3757
0xcd6da0 execute
   
/tmp/4800342_6.tmpdir/aci-gcc-fsf/sources/gcc-fsf/gccsrc/gcc/sched-rgn.c:3932
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make[2]: *** [../o-iterator.mk:9:
/tmp/4800342_6.tmpdir/aci-gcc-fsf/builds/gcc-fsf-gccsrc/obj-aarch64-none-linux-gnu/glibc-1/stdio-common/vfprintf-internal.o]
Error 1

[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

 CC||meissner at gcc dot gnu.org,
   ||segher at gcc dot gnu.org

--- Comment #11 from Peter Bergner  ---
(In reply to anlauf from comment #8)
> There's apparently a real kind with mode_precision >= 128,
> so we have to find out what it is, and if we can convert to it.

To really confuse things, there are 2 16-byte float types on POWER. :-)

Our old IBM double double format (__ibm128) and the newer IEEE128 format
(__ieee128).  We support using both types at the same time.  Our "long double"
type (is that what fortran uses?) is set to one of those types, depending on a
configure time option (...and maybe a compile time option?).

[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042

[anlauf at gcc dot gnu.org]

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

--- Comment #10 from anlauf at gcc dot gnu.org ---
(In reply to r...@cebitec.uni-bielefeld.de from comment #9)
> >> 0x67606b build_round_expr
> >> /vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:408
> >
> > That's:
> >
> >   arg = fold_convert (gfc_float128_type_node, arg);
> >
> > Can you find out what gfc_float128_type_node is on SPARC,

> 408 arg = fold_convert (gfc_float128_type_node, arg);
> (gdb) p gfc_float128_type_node
> $2 = 

OK.  Can you print kind which was determined a few lines before?
Also, to find out why gfc_float128_type_node is NULL_TREE,
can you investigate the array gfc_real_kinds?

On x86, the supported kind values are 4,8,10,16, and

(gdb) p gfc_real_kinds[3]
$9 = {epsilon = {{_mpfr_prec = 113, _mpfr_sign = 1, _mpfr_exp = -111, 
  _mpfr_d = 0x27ee628}}, huge = {{_mpfr_prec = 113, _mpfr_sign = 1,
_mpfr_exp = 16384, 
  _mpfr_d = 0x27ee5e8}}, tiny = {{_mpfr_prec = 113, _mpfr_sign = 1, 
  _mpfr_exp = -16381, _mpfr_d = 0x27ee5c8}}, subnormal = {{_mpfr_prec =
113, 
  _mpfr_sign = 1, _mpfr_exp = -16493, _mpfr_d = 0x27ee608}}, kind = 16,
radix = 2, 
  digits = 113, min_exponent = -16381, max_exponent = 16384, range = 4931,
precision = 33, 
  mode_precision = 128, c_float = 0, c_double = 0, c_long_double = 0,
c_float128 = 1}

In trans-types.c we have:

  if (gfc_real_kinds[index].c_float128)
gfc_float128_type_node = type;

Look in particular at the value of c_float128.

> I'd expect that's long double, which is IEEE128 on SPARC.

So if it is IEEE128, where does the difference from x86 come from?

[Bug target/96955] Implement __builtin_thread_pointer for x86 TLS

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r11-3081-gbf69edf8ce47ca618eff30df2308279a40b22096
Author: H.J. Lu 
Date:   Wed Sep 9 10:29:47 2020 -0700

x32: Update gcc.target/i386/builtin_thread_pointer.c

Update gcc.target/i386/builtin_thread_pointer.c for x32.  For

int
foo3 (int i)
{
  int* p = (int*) __builtin_thread_pointer ();
  return p[i];
}

we can't generate:

movl%fs:0(,%edi,4), %eax
ret

for x32 since the address of %fs:0(,%edi,4) is %fs + zero-extended to 64
bits of 0(,%edi,4).  Instead, we generate:

movl%fs:0, %eax
movl(%eax,%edi,4), %eax

PR target/96955
* gcc.target/i386/builtin_thread_pointer.c: Update scan-assembler
for x32.

[Bug tree-optimization/97000] [11 Regression][nvptx, openacc] internal compiler error: in nvptx_find_par, at config/nvptx/nvptx.c:3293

[vries at gcc dot gnu.org]

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

--- Comment #8 from Tom de Vries  ---
This detects the problem earlier, in the host compiler:
...
diff --git a/gcc/omp-offload.c b/gcc/omp-offload.c
index 32c2485abd4..fce01af7682 100644
--- a/gcc/omp-offload.c
+++ b/gcc/omp-offload.c
@@ -1148,6 +1148,7 @@ oacc_loop_discover_walk (oacc_loop *loop, basic_block bb)
  break;

case IFN_UNIQUE:
+ gcc_assert (stmt == last_stmt (CONST_CAST_BB (bb)));
  enum ifn_unique_kind kind
= (enum ifn_unique_kind) (TREE_INT_CST_LOW
  (gimple_call_arg (call, 0)));
...

[Bug d/95680] libdruntime doesn't support shadow stack

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

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

commit r11-3080-gc6632dc9a8ee77ad66a8d62d736a9112de9e41c7
Author: H.J. Lu 
Date:   Tue Sep 8 05:54:56 2020 -0700

libphobos: Include  to generate the CET marker for -fcf-protection

Include  to generate the CET marker for -fcf-protection to avoid

/bin/ld:
../libdruntime/.libs/libgdruntime_convenience.a(libgdruntime_convenience_la-switchcontext.o):
error: missing IBT and SHSTK properties

when -z cet-report=error is passed to the linker to create libgphobos.so
and libgdruntime.so.

PR d/95680
* libdruntime/config/x86/switchcontext.S: Include  to
generate the CET marker for -fcf-protection.

[Bug rtl-optimization/96998] GCC ICEs in on building AArch64 Linux kernel after basepoints/gcc-11-2903-g6b3034eaba83

[acoplan at gcc dot gnu.org]

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

--- Comment #5 from Alex Coplan  ---
This just looks like a missing pattern which we've started noticing since the
new canonicalisation was introduced.

I imagine reinstating the *add__multp2 pattern and rewriting it to
use shifts instead will fix the issue.

I should have a patch to fix this tomorrow.

[Bug d/96989] SSA_NAMEs in Wuninitialized warning messages after r11-959

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
The MEM_REF formatting done by the C and C++ pretty-printers is very basic and
doesn't always result in useful output (usually in the most interesting cases).

I posted a patch some time ago to improve it for C++ (as part of fix for an ICE
reported in pr95768):
https://gcc.gnu.org/pipermail/gcc-patches/2020-June/548698.html

Richi had some concerns with it but I think it's a significant improvement
despite them.  I plan to extend the C++-only patch to C and post it again at
some point when I'm done with stage 1 work.  If it's approved it should be
straightforward to use the same approach in the D front end (in fact, all front
ends should share the same code for this).

[Bug target/87767] Missing AVX512 memory broadcast for constant vector

[vmakarov at gcc dot gnu.org]

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

Vladimir Makarov  changed:

   What|Removed |Added

 CC||vmakarov at gcc dot gnu.org

--- Comment #16 from Vladimir Makarov  ---
(In reply to Hongtao.liu from comment #15)
> (In reply to Jakub Jelinek from comment #12)
>
> Hi Vladimir Makarov: 
>   I saw you add DEFINE_SPECIAL_MEMORY_CONSTRAINT in PR69299, currently we
> encounter a similar problem as PR69299, we want to add
> special_memory_constraint for broadcast memory operand(call it
> bcst_mem_operand later), but problem is bcst_mem_operand is not MEM_P, it's
> like (vec_duplicate:V4SF (mem:SF (reg:...))), so pass_reload can't properly
> handle this constraint(it alway assumes the operand should be MEM_P). So the
> question is can we enhance the handling of special_memory_constraint, not
> only restricted to MEM_P, but also for operand containing a memory_operand
> inside(i.e. bcst_mem_operand).

Sure, I am open to any patches to solve this problem by extending special
memory constraint semantic or even introducing new special constraint.

It would have no sense to implement this for old reload pass as gcc targets are
moving from it.  So you need to do this only for LRA.

[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-09-09
 Status|UNCONFIRMED |NEW

--- Comment #8 from Segher Boessenkool  ---
Fixed on trunk.  Needs backports.

[Bug rtl-optimization/96475] direct threaded interpreter with computed gotos generates suboptimal dispatch loop

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Segher Boessenkool :

https://gcc.gnu.org/g:69ca5f3a988266da8905aef9cf22aa02807e0471

commit r11-3078-g69ca5f3a988266da8905aef9cf22aa02807e0471
Author: Segher Boessenkool 
Date:   Fri Aug 7 01:31:38 2020 +

bb-reorder: Remove a misfiring micro-optimization (PR96475)

When the compgotos pass copies the tail of blocks ending in an indirect
jump, there is a micro-optimization to not copy the last one, since the
original block will then just be deleted.  This does not work properly
if cleanup_cfg does not merge all pairs of blocks we expect it to.  It
also does not work if that last block can be merged into multiple
predecessors.

2020-09-09  Segher Boessenkool  

PR rtl-optimization/96475
* bb-reorder.c (maybe_duplicate_computed_goto): Remove
single_pred_p
micro-optimization.

[Bug tree-optimization/97000] [11 Regression][nvptx, openacc] internal compiler error: in nvptx_find_par, at config/nvptx/nvptx.c:3293

[vries at gcc dot gnu.org]

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

--- Comment #7 from Tom de Vries  ---
(In reply to Tom de Vries from comment #6)
> I wonder if this will work:
> ...
> diff --git a/gcc/tree-cfgcleanup.c b/gcc/tree-cfgcleanup.c
> index f8169eef781..79f716b9dbe 100644
> --- a/gcc/tree-cfgcleanup.c
> +++ b/gcc/tree-cfgcleanup.c
> @@ -212,7 +212,9 @@ static void
>  cleanup_call_ctrl_altering_flag (basic_block bb, gimple *bb_end)
>  {
>if (!is_gimple_call (bb_end)
> -  || !gimple_call_ctrl_altering_p (bb_end))
> +  || !gimple_call_ctrl_altering_p (bb_end)
> +  || (gimple_call_internal_p (bb_end)
> + && gimple_call_internal_unique_p (bb_end)))
>  return;
>  
>int flags = gimple_call_flags (bb_end);
> ...

Yep, that seems to do the trick.

[Bug d/97002] New: d: Promote types in d_type_promotes_to when linkage is not D

[ibuclaw at gdcproject dot org]

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

Bug ID: 97002
   Summary: d: Promote types in d_type_promotes_to when linkage is
not D
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

There is no promoting of variadic arguments when the linkage is D.  However
extern(C) and extern(C++) functions do undergo type promotions.

This needs to be handled by d_type_promotes_to so that relevant warnings can be
issues on misuse of va_arg.

e.g:

import core.stdc.stdarg;
extern(C) int foo(short a, ...)
{
va_list ap;
va_start(ap, a);
auto f = va_arg!float(ap);
return cast(int)f;
}


int bar(short a, float f)
{
return foo(a, f);   // passed as (double) f
}

[Bug tree-optimization/97000] [11 Regression][nvptx, openacc] internal compiler error: in nvptx_find_par, at config/nvptx/nvptx.c:3293

[vries at gcc dot gnu.org]

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

--- Comment #6 from Tom de Vries  ---
I wonder if this will work:
...
diff --git a/gcc/tree-cfgcleanup.c b/gcc/tree-cfgcleanup.c
index f8169eef781..79f716b9dbe 100644
--- a/gcc/tree-cfgcleanup.c
+++ b/gcc/tree-cfgcleanup.c
@@ -212,7 +212,9 @@ static void
 cleanup_call_ctrl_altering_flag (basic_block bb, gimple *bb_end)
 {
   if (!is_gimple_call (bb_end)
-  || !gimple_call_ctrl_altering_p (bb_end))
+  || !gimple_call_ctrl_altering_p (bb_end)
+  || (gimple_call_internal_p (bb_end)
+ && gimple_call_internal_unique_p (bb_end)))
 return;

   int flags = gimple_call_flags (bb_end);
...

[Bug libstdc++/96995] The link to std API documentation is unversioned

[giecrilj at stegny dot 2a.pl]

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

--- Comment #6 from Christopher Yeleighton  ---
Why wouldn’t locally installed documentation have the API book at the same
relative location?

[Bug libstdc++/96995] The link to std API documentation is unversioned

[redi at gcc dot gnu.org]

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

--- Comment #5 from Jonathan Wakely  ---
If you have a relative URL like href="../../api/namespaces.html" then it only
works if the user has the API docs at that relative location.

If you have an absolute URL like
href="https://gcc.gnu.org/onlinedocs/gcc-10.2.0/libstdc++/manual/manual/../../api/namespaces.html;
then I don't see any advantage to your suggestion, since it still needs the
"gcc-10.2.0" version in the URL, which requires modifying the docs for each
release as I said (or fixing them up in the
maintainer-scripts/generate_libstdcxx_web_docs script).

[Bug tree-optimization/97000] [11 Regression][nvptx, openacc] internal compiler error: in nvptx_find_par, at config/nvptx/nvptx.c:3293

[vries at gcc dot gnu.org]

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

--- Comment #5 from Tom de Vries  ---
Right, I just found this:
...
  /* IFN_UNIQUE should be the last insn, to make checking for it
 as cheap as possible.  */
  || (gimple_call_internal_p (stmt)
  && gimple_call_internal_unique_p (stmt)))
gimple_call_set_ctrl_altering (stmt, true);
...

[Bug tree-optimization/97000] [11 Regression][nvptx, openacc] internal compiler error: in nvptx_find_par, at config/nvptx/nvptx.c:3293

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2020-09-09
Summary|[nvptx, openacc] internal   |[11 Regression][nvptx,
   |compiler error: in  |openacc] internal compiler
   |nvptx_find_par, at  |error: in nvptx_find_par,
   |config/nvptx/nvptx.c:3293   |at
   ||config/nvptx/nvptx.c:3293
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-valid-code
Version|unknown |11.0
   Target Milestone|--- |11.0
 CC||burnus at gcc dot gnu.org,
   ||rguenth at gcc dot gnu.org

--- Comment #4 from Tobias Burnus  ---
Bisecting points to r11-3009-gfab77644842869adc8871e133e4c3f4c35b2b245
PR tree-optimization/96931 - clear ctrl-altering flag more aggressively

2020-09-04  Richard Biener  

PR tree-optimization/96931
* tree-cfgcleanup.c (cleanup_call_ctrl_altering_flag): If
there's a fallthru edge and no abnormal edge the call is
no longer control-altering.
(cleanup_control_flow_bb): Pass down the BB to
cleanup_call_ctrl_altering_flag.

@Richard: See also tentative patch in comment 2

[Bug rtl-optimization/96998] GCC ICEs in on building AArch64 Linux kernel after basepoints/gcc-11-2903-g6b3034eaba83

[acoplan at gcc dot gnu.org]

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

--- Comment #4 from Alex Coplan  ---
Ok, the following reduced testcase ICEs at -O2:

int h(void);
struct c d;
struct c {
  int e[1];
};

void f(void) {
  int g;
  for (;; g = h()) {
int *i = [g];
asm("" : "=Q"(*i));
  }
}

[Bug libstdc++/96995] The link to std API documentation is unversioned

[giecrilj at stegny dot 2a.pl]

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

--- Comment #4 from Christopher Yeleighton  ---
Why wouldn’t it work for local documentation?

[Bug tree-optimization/97000] [nvptx, openacc] internal compiler error: in nvptx_find_par, at config/nvptx/nvptx.c:3293

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
(In reply to Tom de Vries from comment #2)
> Tentative patch:

That fixes all the new libgomp FAILs.

[Bug debug/96997] step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-09-09
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Confirmed:

$ gdb -quiet  -ex start -ex n -ex l -ex where  -ex n -ex l -ex where -ex n -ex
l -ex where -ex cont -ex quit  a.out
Reading symbols from a.out...
Temporary breakpoint 1 at 0x4011bf: file so.C, line 7.
Starting program: /tmp/a.out 

Temporary breakpoint 1, main () at so.C:7
7   std::cout << std::string{"str1"};
525   basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
520 #if __cpp_deduction_guides && ! defined
_GLIBCXX_DEFINING_STRING_INSTANTIATIONS
521   // _GLIBCXX_RESOLVE_LIB_DEFECTS
522   // 3076. basic_string CTAD ambiguity
523   template>
524 #endif
525   basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
526   : _M_dataplus(_M_local_data(), __a)
527   { _M_construct(__s, __s ? __s + traits_type::length(__s) :
__s+npos); }
528
529   /**
#0  main () at /usr/include/c++/10/bits/basic_string.h:525
8   std::cout << std::string{"str2"};
3
4
5   int main()
6   {
7   std::cout << std::string{"str1"};
8   std::cout << std::string{"str2"};
9   return 0;
10  }
11
#0  main () at so.C:8
525   basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
520 #if __cpp_deduction_guides && ! defined
_GLIBCXX_DEFINING_STRING_INSTANTIATIONS
521   // _GLIBCXX_RESOLVE_LIB_DEFECTS
522   // 3076. basic_string CTAD ambiguity
523   template>
524 #endif
525   basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())
526   : _M_dataplus(_M_local_data(), __a)
527   { _M_construct(__s, __s ? __s + traits_type::length(__s) :
__s+npos); }
528
529   /**
#0  main () at /usr/include/c++/10/bits/basic_string.h:525
Continuing.
str1str2[Inferior 1 (process 2307959) exited normally]

Although the current frame is still main() the current location is shown as the
basic_string constructor.

[Bug libstdc++/96995] The link to std API documentation is unversioned

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
That would work for the online docs, not necessarily when users build them and
read them locally.

[Bug libstdc++/97001] API documentation should mention the minimum dialect

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2020-09-09

--- Comment #1 from Jonathan Wakely  ---
And we should also build the docs with the latest dialect, so that everything
gets documented.

[Bug libstdc++/97001] New: API documentation should have a minimum dialect

[giecrilj at stegny dot 2a.pl]

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

Bug ID: 97001
   Summary: API documentation should have a minimum dialect
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: giecrilj at stegny dot 2a.pl
  Target Milestone: ---

For example, the documentation for std::cbegin[1] should say:
> Minimum dialect: c++14

___
[1] https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/a01544.html#ac10e18b5c09f39bc07430a9d47e584a5
>

[Bug libstdc++/96999] [8/9 Regression] std::variant requires default constructor with gcc 8-9, gcc 7.x and 10.x works

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to fail||8.4.0, 9.3.0
   Last reconfirmed||2020-09-09
 Status|UNCONFIRMED |ASSIGNED
   Keywords||rejects-valid
  Known to work||10.1.0, 11.0, 7.4.0
 Ever confirmed|0   |1
   Target Milestone|--- |8.5
  Component|c++ |libstdc++
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
Summary|regression: std::variant|[8/9 Regression]
   |requires default|std::variant requires
   |constructor with gcc 8-9,   |default constructor with
   |gcc 7.x and 10.x works  |gcc 8-9, gcc 7.x and 10.x
   ||works

--- Comment #1 from Jonathan Wakely  ---
This seems to be a similar problem to PR 94033, and is fixed by its r10-7270

[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #8 from anlauf at gcc dot gnu.org ---
> (In reply to Rainer Orth from comment #6)
>> The test also FAIL on 64-bit SPARC with an ICE/SEGV:
>> 
>> 0x67606b build_round_expr
>> /vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:408
>
> That's:
>
>   arg = fold_convert (gfc_float128_type_node, arg);
>
> Can you find out what gfc_float128_type_node is on SPARC,

I find

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x008edab4 in fold_convert_loc (loc=0, type=, arg=)
at /vol/gcc/src/hg/master/local/gcc/fold-const.c:2404
2404  if (TREE_CODE (arg) == ERROR_MARK
(gdb) p gfc_float128_type_node
$1 = 
(gdb) up
#1  0x0067606c in build_round_expr (restype=
, arg=)
at /vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:408
408   arg = fold_convert (gfc_float128_type_node, arg);
(gdb) p gfc_float128_type_node
$2 = 

> and why the conversion fails?

I've not the slightest idea how to do that.

> There's apparently a real kind with mode_precision >= 128,
> so we have to find out what it is, and if we can convert to it.

I'd expect that's long double, which is IEEE128 on SPARC.

[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042

[anlauf at gcc dot gnu.org]

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
(In reply to Rainer Orth from comment #6)
> The test also FAIL on 64-bit SPARC with an ICE/SEGV:
> 
> 0x67606b build_round_expr
> /vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:408

That's:

  arg = fold_convert (gfc_float128_type_node, arg);

Can you find out what gfc_float128_type_node is on SPARC,
and why the conversion fails?

There's apparently a real kind with mode_precision >= 128,
so we have to find out what it is, and if we can convert to it.

[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042

[anlauf at gcc dot gnu.org]

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Peter Bergner from comment #5)
> (In reply to seurer from comment #3)
> > That said, should the dg-require-effective-target fortran_real_16 "work" on
> > powerpc64?
> 
> REAL*16 is a 16 byte double, correct?  Ie, our long double?  Therefore, it
> should exist and work too.

The failure is:

f951: internal compiler error: Could not find real kind with at least 128 bits

Can you please list the table: gfc_real_kinds[i].mode_precision

We're expecting a real kind with mode_precision >= 128.

If "your" long double has less, how can I know?

[Bug tree-optimization/97000] [nvptx, openacc] internal compiler error: in nvptx_find_par, at config/nvptx/nvptx.c:3293

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
Tentative patch:
...
diff --git a/gcc/tracer.c b/gcc/tracer.c
index 82ede722534..ec97eb51538 100644
--- a/gcc/tracer.c
+++ b/gcc/tracer.c
@@ -99,6 +99,12 @@ ignore_bb_p (const_basic_block bb)
 must be duplicated in its entirety or not at all.  */
   if (gimple_code (g) == GIMPLE_TRANSACTION)
return true;
+}
+
+  for (gimple_stmt_iterator gsi = gsi_start_bb (CONST_CAST_BB (bb));
+   !gsi_end_p (gsi); gsi_next ())
+{
+  gimple *g = gsi_stmt (gsi);

   /* An IFN_UNIQUE call must be duplicated as part of its group,
 or not at all.  */
...

[Bug tree-optimization/97000] [nvptx, openacc] internal compiler error: in nvptx_find_par, at config/nvptx/nvptx.c:3293

[vries at gcc dot gnu.org]

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

--- Comment #1 from Tom de Vries  ---
At asyncwait-1.xnvptx-none.mkoffload.179t.slsr, we have the valid:
...
   [local count: 87490071]:
  _14 = .UNIQUE (OACC_FORK, 0, 2);
  _75 = .GOACC_DIM_SIZE (0);
  _76 = .GOACC_DIM_POS (0);
  _77 = .GOACC_DIM_POS (2);
  _60 = _75 * 32;
  _61 = _60 + 63;
  _63 = _61 / _60;
  _44 = _63 * _76;
  _65 = _44 * 32;
  _19 = _65 + _77;
  _71 = _63 * 32;
  _72 = _19 + _71;
  _20 = MIN_EXPR <_72, 64>;
  if (_19 < _20)
goto ; [27.00%]
  else
goto ; [73.00%]


   [local count: 437450366]:
  .UNIQUE (OACC_JOIN, _14, 2);
  return;
...
and at asyncwait-1.xnvptx-none.mkoffload.181t.tracer, we have in addition:
...
   [local count: 373582614]:
  .UNIQUE (OACC_JOIN, _14, 2);
  return;
...
which causes the ICE.

There's some code in ignore_bb_p in tracer.c to stop this from happening.  But
it doesn't work, because it only checks for .UNIQUE in the last stmt in the bb,
while in bb3 the last is a return (and in bb2, the .UNIQUE is the first stmt).

[Bug tree-optimization/97000] New: [nvptx, openacc] internal compiler error: in nvptx_find_par, at config/nvptx/nvptx.c:3293

[vries at gcc dot gnu.org]

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

Bug ID: 97000
   Summary: [nvptx, openacc] internal compiler error: in
nvptx_find_par, at config/nvptx/nvptx.c:3293
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

When building an x86_64 + nvptx accelerator setup with the patch adding
libatomic for nvptx (
https://gcc.gnu.org/pipermail/gcc-patches/2020-September/553393.html ) , we run
into:
...
during RTL pass: mach
/home/vries/oacc/trunk/source-gcc/libgomp/testsuite/libgomp.oacc-fortran/asyncwait-1.f90:
In function ‘MAIN__._omp_fn.0’:
/home/vries/oacc/trunk/source-gcc/libgomp/testsuite/libgomp.oacc-fortran/asyncwait-1.f90:19:
internal compiler error: in nvptx_find_par, at config/nvptx/nvptx.c:3293
0x160c390 nvptx_find_par
/home/vries/oacc/trunk/source-gcc/gcc/config/nvptx/nvptx.c:3293
0x160c48a nvptx_find_par
/home/vries/oacc/trunk/source-gcc/gcc/config/nvptx/nvptx.c:3320
0x160c48a nvptx_find_par
/home/vries/oacc/trunk/source-gcc/gcc/config/nvptx/nvptx.c:3320
0x160c48a nvptx_find_par
/home/vries/oacc/trunk/source-gcc/gcc/config/nvptx/nvptx.c:3320
0x160c48a nvptx_find_par
/home/vries/oacc/trunk/source-gcc/gcc/config/nvptx/nvptx.c:3320
0x160c522 nvptx_discover_pars
/home/vries/oacc/trunk/source-gcc/gcc/config/nvptx/nvptx.c:3344
0x1611046 nvptx_reorg
/home/vries/oacc/trunk/source-gcc/gcc/config/nvptx/nvptx.c:5055
0x1059c88 execute
/home/vries/oacc/trunk/source-gcc/gcc/reorg.c:4028
...

[Bug c++/96647] Can't resolve pointer to overloaded member with auto return type

[ppalka at gcc dot gnu.org]

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
Fixed for GCC 11.  Thanks for the report!

[Bug rtl-optimization/96998] GCC ICEs in on building AArch64 Linux kernel after basepoints/gcc-11-2903-g6b3034eaba83

[acoplan at gcc dot gnu.org]

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

Alex Coplan  changed:

   What|Removed |Added

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

--- Comment #3 from Alex Coplan  ---
Confirmed. GCC trunk ICEs on AArch64 when compiling kernel/cgroup/cgroup.c.
Seems to happen when compiling multiple kernel source files.

I'll reduce a testcase and take a look.

[Bug c++/96996] Missed optimzation for constant members of non-constant objects

[redi at gcc dot gnu.org]

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

--- Comment #3 from Jonathan Wakely  ---
Yes, that's what I said:

> I'm not saying the optimization would be invalid

[Bug c++/96999] New: regression: std::variant requires default constructor with gcc 8-9, gcc 7.x and 10.x works

[dushistov at mail dot ru]

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

Bug ID: 96999
   Summary: regression: std::variant requires default constructor
with gcc 8-9, gcc 7.x and 10.x works
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dushistov at mail dot ru
  Target Milestone: ---

For code bellow, gcc 9.3 from Ubuntu reports error:
```
In file included from /usr/include/c++/9/variant:36,
 from test.cpp:1:
...
/usr/include/c++/9/type_traits:931:47: error: ‘Foo::Foo()’ is private within
this context
  931 | : public integral_constant   
  |   ^ 
test.cpp:10:3: note: declared private here  
   10 |   Foo() noexcept {} 
  |   ^~~   
```
gcc 8.x also reports error. gcc 7.x and 10.x works just fine:

```
#include 
#include 

struct Foo {
public:
  explicit Foo(int) noexcept {}
  Foo(Foo &&) noexcept = default;
  Foo =(Foo &&) = default;
private:
  Foo() noexcept {}
};

struct Boo {
public:
  explicit Boo(int) noexcept {}
  Boo(Boo &&) noexcept = default;
  Boo =(Boo &&) = default;
private:
  Boo() noexcept {}
};


template
std::variant g(int v, int x) {
 return  v == 0 ? std::variant{Foo{x}} :
 std::variant{Boo{x}};
}

int main()
{
  std::variant, std::string> err{std::string("aaa")};
}
```

[Bug libstdc++/96995] The link to std API documentation is unversioned

[giecrilj at stegny dot 2a.pl]

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

--- Comment #2 from Christopher Yeleighton  ---
https://gcc.gnu.org/onlinedocs/gcc-10.2.0/libstdc++/manual/manual/../../api/namespaces.html
> would do the trick.

[Bug c++/96976] g++ reports "call of overloaded '...' is ambiguous" when universal reference is used

[vorfeed.canal at gmail dot com]

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

Vorfeed Canal  changed:

   What|Removed |Added

 CC||vorfeed.canal at gmail dot com

--- Comment #3 from Vorfeed Canal  ---
Why couldn't you use std::enable_if in it's usual (for functions) place?

Like this:

template 
auto f(K&& k, Args&&... args) -> std::enable_if_t
{
}

Works with all somewhat decent compilers:

https://godbolt.org/z/rds3vM

[Bug c++/96647] Can't resolve pointer to overloaded member with auto return type

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r11-3075-g4e03e2e08b94f65f2be3db17f880c205ec262f87
Author: Patrick Palka 
Date:   Wed Sep 9 09:21:09 2020 -0400

c++: Fix resolving the address of overloaded pmf [PR96647]

In resolve_address_of_overloaded_function, currently only the second
pass over the overload set (which considers just the function templates
in the overload set) checks constraints and performs return type
deduction when necessary.  But as the testcases below show, we need to
do the same when considering non-template functions during the first
pass.

gcc/cp/ChangeLog:

PR c++/96647
* class.c (resolve_address_of_overloaded_function): Check
constraints_satisfied_p and perform return-type deduction via
maybe_instantiate_decl when considering non-template functions
in the overload set.
* cp-tree.h (maybe_instantiate_decl): Declare.
* decl2.c (maybe_instantiate_decl): Remove static.

gcc/testsuite/ChangeLog:

PR c++/96647
* g++.dg/cpp0x/auto-96647.C: New test.
* g++.dg/cpp0x/error9.C: New test.
* g++.dg/cpp2a/concepts-fn6.C: New test.

[Bug rtl-optimization/96998] GCC ICEs in on building AArch64 Linux kernel after basepoints/gcc-11-2903-g6b3034eaba83

[acoplan at gcc dot gnu.org]

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

--- Comment #2 from Alex Coplan  ---
I'll take a look, thanks.

[Bug c++/96996] Missed optimzation for constant members of non-constant objects

[matthijs at stdin dot nl]

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

--- Comment #2 from Matthijs Kooijman  ---
> Replacing non_constant_test with a new object is possible, and allowed. But 
> the name "non_constant_test" cannot be used to refer to the new object, so 
> any calls to non_constant_ref() after the object was replaced would have 
> undefined behaviour. Which means the compiler can assume there are no such 
> calls.

Thanks for clarifying. But then I could reason that *if* "non_constant_test" is
replaced, then accessing it through the old name is undefined behavior, so that
would make any value for the constant member variables (such as the original
values before replacement) acceptable, right? Hence that does not conflict with
applying this optimzation, I'd think.

[Bug c++/96996] Missed optimzation for constant members of non-constant objects

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|web |c++
   Keywords||missed-optimization

--- Comment #1 from Jonathan Wakely  ---
(In reply to Matthijs Kooijman from comment #0)
> There is still the caveat of "during its lifetime", IOW, what if you would
> destroy the object and create a new one it is place. However, see
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80794#c5 for a discussion of
> this case. In short, replacing non_constant_test with a new object is
> possible, but only when it "does not contain any non-static data member
> whose type is const-qualified or a reference type", which does not hold for
> this object.

That's not quite accurate. Replacing non_constant_test with a new object is
possible, and allowed. But the name "non_constant_test" cannot be used to refer
to the new object, so any calls to non_constant_ref() after the object was
replaced would have undefined behaviour. Which means the compiler can assume
there are no such calls.

I'm not saying the optimization would be invalid, just clarifying what the
related discussion says.

[Bug libstdc++/96995] The link to std API documentation is unversioned

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||documentation

--- Comment #1 from Jonathan Wakely  ---
That would require editing the doc sources for every release, which isn't going
to happen.

[Bug rtl-optimization/96998] GCC ICEs in on building AArch64 Linux kernel after basepoints/gcc-11-2903-g6b3034eaba83

[mkuvyrkov at gcc dot gnu.org]

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

Maxim Kuvyrkov  changed:

   What|Removed |Added

 CC||acoplan at gcc dot gnu.org,
   ||mkuvyrkov at gcc dot gnu.org
 Target||aarch64-linux-gnu

--- Comment #1 from Maxim Kuvyrkov  ---
Alex, would you please look into this?

Let me know if you have problems reproducing the crash and I'll make a smaller
reproducer.

[Bug rtl-optimization/96998] New: GCC ICEs in on building AArch64 Linux kernel after basepoints/gcc-11-2903-g6b3034eaba83

[mkuvyrkov at gcc dot gnu.org]

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

Bug ID: 96998
   Summary: GCC ICEs in on building AArch64 Linux kernel after
basepoints/gcc-11-2903-g6b3034eaba83
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mkuvyrkov at gcc dot gnu.org
  Target Milestone: ---

GCC ICEs on building Linux kernel for AArch64 target after
basepoints/gcc-11-2903-g6b3034eaba83:
===
commit 6b3034eaba83935d9f6dfb20d2efbdb34b5b00bf
Author: Alex Coplan 
Date:   Thu Aug 27 09:49:57 2020 +0100

lra: Canonicalize mult to shift in address reloads
===

The error message is:
===
00:01:02 during RTL pass: reload
00:01:02 mm/backing-dev.c: In function ‘clear_bdi_congested’:
00:01:02 mm/backing-dev.c:930:1: internal compiler error: in
lra_set_insn_recog_data, at lra.c:1006
00:01:02   930 | }
00:01:02   | ^
00:01:03 0xb4f991 lra_set_insn_recog_data(rtx_insn*)
00:01:03   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/lra.c:1004
00:01:03 0xb4feb7 lra_get_insn_recog_data
00:01:03   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/lra-int.h:488
00:01:03 0xb4feb7 lra_update_insn_regno_info(rtx_insn*)
00:01:03   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/lra.c:1625
00:01:03 0xb50027 lra_update_insn_regno_info(rtx_insn*)
00:01:03   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/lra.c:1774
00:01:03 0xb50027 lra_push_insn_1
00:01:03   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/lra.c:1780
00:01:03 0xb50027 lra_push_insn(rtx_insn*)
00:01:03   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/lra.c:1788
00:01:03 0xb50027 push_insns
00:01:03   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/lra.c:1831
00:01:03 0xb51c0c push_insns
00:01:03   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/rtl.h:886
00:01:03 0xb51c0c lra_process_new_insns(rtx_insn*, rtx_insn*, rtx_insn*, char
const*)
00:01:03   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/lra.c:1879
00:01:03 0xb6981e curr_insn_transform
00:01:03   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/lra-constraints.c:4572
00:01:03 0xb6b7cd lra_constraints(bool)
00:01:03   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/lra-constraints.c:5066
00:01:03 0xb52c4c lra(_IO_FILE*)
00:01:03   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/lra.c:2415
00:01:03 0xb032a9 do_reload
00:01:03   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/ira.c:5525
00:01:03 0xb032a9 execute
00:01:03   
/home/tcwg-buildslave/workspace/tcwg_kernel_0/abe/snapshots/gcc.git~master/gcc/ira.c:5711
00:01:03 Please submit a full bug report,
00:01:03 with preprocessed source if appropriate.
00:01:03 Please include the complete backtrace with any bug report.
00:01:03 See  for instructions.
00:01:03 scripts/Makefile.build:283: recipe for target 'mm/backing-dev.o'
failed
00:01:03 make[1]: *** [mm/backing-dev.o] Error 1
===

Toolchain configurations is a no-frills default aarch64-linux-gnu toolchain,
but only linux-next tree seems to be affected.  It's possible that the ICE is
due to a wrong register constraint in a poorly-tested patch in linux-next. 
Nevertheless, the ICE is worth investigating.

The linux-next tree as tested was "7a6956579ce69 Add linux-next specific files
for 20200903".

More details on the toolchain build:
https://ci.linaro.org/view/tcwg_kernel-gnu/job/tcwg_kernel-gnu-bisect-gnu-master-aarch64-next-allnoconfig/4/artifact/artifacts/build-first_bad/04-build_abe-stage1/console.log/*view*/
More details on the linux build:
https://ci.linaro.org/view/tcwg_kernel-gnu/job/tcwg_kernel-gnu-bisect-gnu-master-aarch64-next-allnoconfig/4/artifact/artifacts/build-first_bad/05-build_linux/console.log/*view*/
.

[Bug debug/93865] .debug_line with LTO refers to bogus file-names

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Created attachment 49204
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49204=edit
gcc11-pr93865-wip.patch

Untested WIP patch which seems to fix the problem.

I have some problems with make_relative_prefix_ignore_links though, one is that
it has way too many cases in which it just returns NULL, another one is that
due to all the memory allocations it is quite expensive and lastly e.g. for
"/", "/usr/src/gcc/obj/gcc/tt/b", "/usr/src/gcc/obj/gcc/tt" it returns
"../../tt" rather than ".." I'd expect.  So I'm considering writing a lighter
version of that and have a fallback to using absolute path e.g. if the two
paths
have nothing in common (consider Windowsy C:\foo and D:\bar ).

[Bug target/96991] [nvptx] internal compiler error: in write_fn_proto, at config/nvptx/nvptx.c:913

[vries at gcc dot gnu.org]

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

Tom de Vries  changed:

   What|Removed |Added

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

--- Comment #6 from Tom de Vries  ---
Patch committed, test-case postponed for when there's libatomic support for
nvptx.

Marking resolved-fixed.

[Bug target/96991] [nvptx] internal compiler error: in write_fn_proto, at config/nvptx/nvptx.c:913

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Tom de Vries :

https://gcc.gnu.org/g:505590b796df18ec3fcdcd6b8060f6f1410660b2

commit r11-3073-g505590b796df18ec3fcdcd6b8060f6f1410660b2
Author: Tom de Vries 
Date:   Wed Sep 9 09:51:43 2020 +0200

[nvptx] Fix boolean type test in write_fn_proto

When running this libgomp testcase for nvptx accelerator:
...
/* { dg-do run } */
__uint128_t v;
int main () {
  #pragma omp target
  {
__uint128_t exp = 2;
__atomic_compare_exchange_n (, , 7, false, __ATOMIC_RELEASE,
 __ATOMIC_ACQUIRE);
  }
}
...
we run into this assert in write_fn_proto:
...
913 gcc_assert (type == boolean_type_node);
...

This happens when doing some special-handling code for
__atomic_compare_exchange_1/2/4/8/16.  The function decls have a parameter
called weak of type bool, which is skipped when writing the decl because
the corresponding libatomic functions do not have that parameter.  The
assert
is there to verify that we skip the correct parameter.

However, we assert because we have different type of bools:
...
(gdb) call debug_generic_expr (type)
_Bool
(gdb) call debug_generic_expr (global_trees[TI_BOOLEAN_TYPE])
bool
...

Fix this by checking for TREE_CODE (type) == BOOLEAN_TYPE instead.

Tested libgomp on x86_64-linux with nvptx accelerator.

Likewise, tested that the test-case above does not ICE anymore.

gcc/ChangeLog:

PR target/96991
* config/nvptx/nvptx.c (write_fn_proto): Fix boolean type check.

[Bug debug/96997] New: step over in gdb always stops in basic_string(const _CharT* __s, const _Alloc& __a = _Alloc())

[alexis.jeandet at member dot fsf.org]

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

Bug ID: 96997
   Summary: step over in gdb always stops in basic_string(const
_CharT* __s, const _Alloc& __a = _Alloc())
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alexis.jeandet at member dot fsf.org
  Target Milestone: ---

Minimum code to reproduce the issue:

#include 
#include 


int main()
{
std::cout << std::string{"str1"};
std::cout << std::string{"str2"};
return 0;
}

Stepping over will stop in basic_string ctor which is unexpected. This is
reproductible with G++ 10.2.1 and 10.2.0 (Fedora 32, 32 and Arch). 
On the same machine building with clang and debugging with gdb doesn't have
this issue.

g++9 and 8 works as expected.

[Bug web/96996] New: Missed optimzation for constant members of non-constant objects

[matthijs at stdin dot nl]

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

Bug ID: 96996
   Summary: Missed optimzation for constant members of
non-constant objects
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: web
  Assignee: unassigned at gcc dot gnu.org
  Reporter: matthijs at stdin dot nl
  Target Milestone: ---

When a global class instance is const and initialized using constant arguments
to a constexpr constructor, any member references are optimized away (using the
constant value rather than a lookup). However, when the object is *not* const,
but does have const members, such optimization does not happen.

$ cat test2.cpp; gcc -O3 -S -Wall -Wextra -fdump-tree-optimized=/dev/stdout
test2.cpp
constexpr int v = 1;

struct Test {
  constexpr Test(int v, const int *p) : v(v), p(p) { }
  int const v;
  const int * const p;
};

const Test constant_test(v, );
Test non_constant_test(v, );

int constant_ref() {
return constant_test.v + *constant_test.p;
}

int non_constant_ref() {
return non_constant_test.v + *non_constant_test.p;
}

;; Function constant_ref (_Z12constant_refv, funcdef_no=3, decl_uid=2360,
cgraph_uid=4, symbol_order=6)

constant_ref ()
{
   [local count: 1073741824]:
  return 2;

}



;; Function non_constant_ref (_Z16non_constant_refv, funcdef_no=4,
decl_uid=2362, cgraph_uid=5, symbol_order=7)

non_constant_ref ()
{
  int _1;
  const int * _2;
  int _3;
  int _5;

   [local count: 1073741824]:
  _1 = non_constant_test.v;
  _2 = non_constant_test.p;
  _3 = *_2;
  _5 = _1 + _3;
  return _5;

}


In the constant_f() case, the values are completely optimized and the return
value is determined at compiletime. In the non_constant_f() case, the values
are retrieved at runtime.

However, AFAICS there should be no way that these values can be modified at
runtime, even when the object itself is not const, since the members are const.
So AFAICS, it shoul be possible to evaluation non_constant_f() at compiletime
as well.

Looking at the C++ spec (I'm quoting from the C++14 draft here), this would
seem to be possible as well.

[basic.type.qualifier] says "A const object is an object of type const T or a
non-mutable subobject of such an object."

If I read [intro.object] correctly, subobjects (such as non-static member
variables) are also objects, so a non-static member variable declared const
would be a "const object".

[dcl.type.cv] says "Except that any class member declared mutable (7.1.1) can
be modified, any attempt to modify a const object during its lifetime (3.8)
results in undefined behavior."

So, one can assume that the const member variable is not modified, because if
it was, that would be undefined behavior.

There is still the caveat of "during its lifetime", IOW, what if you would
destroy the object and create a new one it is place. However, see
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80794#c5 for a discussion of this
case. In short, replacing non_constant_test with a new object is possible, but
only when it "does not contain any non-static data member whose type is
const-qualified or a reference type", which does not hold for this object. This
sounds like this provision was made for pretty much this case, even.

I suspect that reason that it works for the const object now, is because of the
rules for constant expressions. [expr.const] defines rules for constant
exprssions and seems to only allow using(through lvalue-to-rvalue conversion)
objects of non-integral types when they are constexpr. I can imagine that gcc
derives that constant_test might be effectively constexpr, making any
expressions that use it also effectively constant expressions. This same
derivation probably does not happen for subobjects (I guess "constexpr" is not
actually a concept that applies to subobjects at all). However, I think this
does not mean this optimization would be invalid, just that it would happen on
different grounds than the current optimization.


This issue is also related to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80794, but AFAICS that is more
about partial compilation and making assumptions about what an external
function can or cannot do, while this issue is primarily about link-time
(though maybe they are more similar internally, I don't exactly know).

I believe that this optimization would be quite significant to make, since it
allows better abstraction and separation of concerns (i.e. it allows writing a
class to be generic, using constructor-supplied parameters, but if you pass
constants for these parameters and have just a single instance of such a class,
or when methods are inlined or constprop'd, there could be zero runtime
overhead for this extra abstraction). Currently, I believe that you either have
to accept runtime overhead, or resort to using template argument for such
parameters (which significantly complicates everything, and 

[Bug libstdc++/96942] std::pmr::monotonic_buffer_resource causes CPU cache misses

[dmitriy.ovdienko at gmail dot com]

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

--- Comment #37 from Dmitriy Ovdienko  ---
> I assume you can't just preallocate a buffer for the pool?

I dunno... here is a requirement:

 * When possible, use default GC; otherwise use per node allocation or use a
library memory pool.

 * As a practical matter, the myriad ways to tune GC will not be accepted.

 * As a practical matter, the myriad ways to custom allocate memory will not be
accepted.

 * Please don't implement your own custom "arena" or "memory pool" or "free
list" - they will not be accepted.


I've submitted the code yesterday. Let's see if they accept it. If they do, I
will submit the next version with what you @Jonathan suggest

[Bug libstdc++/96995] New: The link to std api documentation is unversioned

[giecrilj at stegny dot 2a.pl]

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

Bug ID: 96995
   Summary: The link to std api documentation is unversioned
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: giecrilj at stegny dot 2a.pl
  Target Milestone: ---

Reading the section "Available Namespaces" [1]:

Actual:
> A complete list of implementation namespaces (including namespace contents) 
> is available in the generated source documentation [2].

Expected:
> A complete list of implementation namespaces (including namespace contents) 
> is available in the generated source documentation [3].

___
[1] https://gcc.gnu.org/onlinedocs/gcc-10.2.0/libstdc++/manual/manual/using_namespaces.html#manual.intro.using.namespaces.all
>
[2] https://gcc.gnu.org/onlinedocs/libstdc++/latest-doxygen/namespaces.html >
[3] https://gcc.gnu.org/onlinedocs/gcc-10.2.0/libstdc++/api/namespaces.html >

[Bug libstdc++/96942] std::pmr::monotonic_buffer_resource causes CPU cache misses

[dmitriy.ovdienko at gmail dot com]

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

--- Comment #36 from Dmitriy Ovdienko  ---
> It doesn't seem to make much difference.

It is visible in the assembly. In case if you use __unlikelly, compiler moves
this code out of hot path minimizing the amount of instructions to decode.

[Bug c++/96988] Bad/missing warnings when returning a temporary from an inlined function

[blubban at gmail dot com]

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

--- Comment #2 from Alfred Agrell  ---
Poked this thing a bit more, and discovered that there's no need for inlining,
you can reproduce it just as well with an extra {}.

And if you copy the function a few times, the warnings start pointing to wrong
source location. Is that just another facet of this issue, or is it a separate
bug?


$ gcc -O2 -Wall bug.c

int foo1() { int * b; { int a = 1; b =  } return *b; }
int foo2() { int * b; { int a = 2; b =  } return *b; }
int foo3() { int * b; { int a = 3; b =  } return *b; }
int foo4() { int * b; { int a = 4; b =  } return *b; }
int foo5() { int * b; { int a = 5; b =  } return *b; }


: In function 'foo1':
:1:54: warning: 'a' is used uninitialized in this function
[-Wuninitialized]
1 | int foo1() { int * b; { int a = 1; b =  } return *b; }
  | ^~
: In function 'foo2':
:1:29: warning: 'a' is used uninitialized in this function
[-Wuninitialized]
1 | int foo1() { int * b; { int a = 1; b =  } return *b; }
  | ^
: In function 'foo3':
:1:29: warning: 'a' is used uninitialized in this function
[-Wuninitialized]
: In function 'foo4':
:1:29: warning: 'a' is used uninitialized in this function
[-Wuninitialized]
: In function 'foo5':
:1:29: warning: 'a' is used uninitialized in this function
[-Wuninitialized]

[Bug c++/96994] New: Missing code from consteval constructor initializing const variable

[sbergman at redhat dot com]

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

Bug ID: 96994
   Summary: Missing code from consteval constructor initializing
const variable
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

At least with a local build of recent GCC 11 trunk and with
gcc-c++-10.2.1-1.fc32.x86_64:

> $ cat test.cc
> #include 
> struct S1 {
> consteval S1() { i = 1; }
> int i = 0;
> };
> struct S2 {
> constexpr S2() { i = 1; }
> int i = 0;
> };
> S1 const s1a;
> constexpr S1 s1b;
> S2 const s2;
> int main() { std::cout << s1a.i << ' ' << s1b.i << ' ' << s2.i << '\n'; }

> $ g++ -std=c++20 test.cc
> $ ./a.out
> 0 1 1

The first "0" is not as expected, the following two "1" demonstrate how slight
modifications of the code would lead to the expected outcome.

[Bug fortran/94690] [OpenMP] omp ... distribute – lastprivate not permitted and more issues

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #16 from Tobias Burnus  ---
FIXED on mainline (GCC 11), backported to GCC 10 and to OG10 =
devel/omp/gcc-10.

[Bug fortran/95109] [11 regression] ICE in gfortran.dg/gomp/target1.f90 after r11-349

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #9 from Tobias Burnus  ---
FIXED on mainline (GCC 11), backported to GCC 10 and to OG10 =
devel/omp/gcc-10.

[Bug fortran/95654] nvptx offloading: FAIL: libgomp.fortran/pr66199-5.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions execution test

[burnus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95654
Bug 95654 depends on bug 95109, which changed state.

Bug 95109 Summary: [11 regression] ICE in gfortran.dg/gomp/target1.f90 after 
r11-349
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95109

   What|Removed |Added

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

[Bug tree-optimization/92266] Duplicate code generation for live stmts from SLP

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
So it would probably be good to mark the live lane to code-generate from in the
SLP node itself and make sure to mark only one for each original scalar stmt.

[Bug target/96955] Implement __builtin_thread_pointer for x86 TLS

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #6 from H.J. Lu  ---
Fixed for GCC 11.

[Bug middle-end/96200] Implement __builtin_thread_pointer() and __builtin_set_thread_pointer() if TLS is supported

[hjl.tools at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96200
Bug 96200 depends on bug 96955, which changed state.

Bug 96955 Summary: Implement __builtin_thread_pointer for x86 TLS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96955

   What|Removed |Added

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

[Bug rtl-optimization/96993] [10/11 Regression] invalid code

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Can you turn it into a self-contained testcase (add noipa attributes to the
external functions and define them some way that it detects the problem, add
noipa attribute to the problematic function and add main that invokes it so
that it can reproduce)?
Without that and knowledge what to look for, it is not really possible e.g. to
bisect it and find out what changed and why.

[Bug target/96991] [nvptx] internal compiler error: in write_fn_proto, at config/nvptx/nvptx.c:913

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
(In reply to Jakub Jelinek from comment #3)
> Note, the testcase would need to require int128 effective target or even
> sync_int_128_runtime, ensure linking with -latomic on offloading targets
> that need it (unless we handle it automatically), but also as I said, it
> contains just 3 randomly chosen atomics.
> Would be nice to have more complete test coverage of the atomics, like
> having one test per basic atomic size (char, short, int, long long, int128)
> and in each test at least most of the __atomic* and __sync_* builtins that
> are out there.
> See e.g. gcc.dg/atomic*.c and gcc.dg/sync*.c.  Perhaps use macros to avoid
> too many repetitions.

For now, I'm going to commit without test-case.

I've tried for a while to make something that does not depend on libatomic, but
didn't manage.

And I didn't manage to xfail the resulting link failure due to no libatomic
support in a way that doesn't also xfail the ICE.

So, to be revisited once libatomic support for nvptx has been committed.

[Bug target/96357] [10/11 Regression] could not split insn UNSPEC_COND_FSUB with AArch64 SVE

[ktkachov at gcc dot gnu.org]

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from ktkachov at gcc dot gnu.org ---
Fixed everywhere then, thanks.

[Bug fortran/95109] [11 regression] ICE in gfortran.dg/gomp/target1.f90 after r11-349

[cvs-commit at gcc dot gnu.org]

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Tobias Burnus
:

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

commit r10-8721-gf93eba8c5fde83100bf0854607848b6f50c8bbb2
Author: Tobias Burnus 
Date:   Wed Sep 9 11:54:43 2020 +0200

Fortran: Fixes for OpenMP loop-iter privatization (PRs 95109 + 94690)

This commit also fixes a gfortran.dg/gomp/target1.f90 regression;
target1.f90 tests the resolve.c and openmp.c changes.

gcc/fortran/ChangeLog:

PR fortran/95109
PR fortran/94690
* resolve.c (gfc_resolve_code): Also call
gfc_resolve_omp_parallel_blocks for 'distribute parallel do
(simd)'.
* openmp.c (gfc_resolve_omp_parallel_blocks): Handle it.
* trans-openmp.c (gfc_trans_omp_target): For
TARGET_PARALLEL_DO_SIMD,
call simd not do processing function.

gcc/testsuite/ChangeLog:

PR fortran/95109
PR fortran/94690
* gfortran.dg/gomp/openmp-simd-5.f90: New test.

(cherry picked from commit 61c2d476a52bb108bd05d0226c5522bf0c4b24b5)

[Bug fortran/94690] [OpenMP] omp ... distribute – lastprivate not permitted and more issues

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Tobias Burnus
:

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

commit r10-8721-gf93eba8c5fde83100bf0854607848b6f50c8bbb2
Author: Tobias Burnus 
Date:   Wed Sep 9 11:54:43 2020 +0200

Fortran: Fixes for OpenMP loop-iter privatization (PRs 95109 + 94690)

This commit also fixes a gfortran.dg/gomp/target1.f90 regression;
target1.f90 tests the resolve.c and openmp.c changes.

gcc/fortran/ChangeLog:

PR fortran/95109
PR fortran/94690
* resolve.c (gfc_resolve_code): Also call
gfc_resolve_omp_parallel_blocks for 'distribute parallel do
(simd)'.
* openmp.c (gfc_resolve_omp_parallel_blocks): Handle it.
* trans-openmp.c (gfc_trans_omp_target): For
TARGET_PARALLEL_DO_SIMD,
call simd not do processing function.

gcc/testsuite/ChangeLog:

PR fortran/95109
PR fortran/94690
* gfortran.dg/gomp/openmp-simd-5.f90: New test.

(cherry picked from commit 61c2d476a52bb108bd05d0226c5522bf0c4b24b5)

[Bug libstdc++/96942] std::pmr::monotonic_buffer_resource causes CPU cache misses

[redi at gcc dot gnu.org]

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

--- Comment #35 from Jonathan Wakely  ---
(In reply to Dmitriy Ovdienko from comment #33)
> @Jonathan Wakely
> 
> I have one idea to improve code of p_m_r
> 
> I expect that allocation are very rare operation. If true, it makes sense to
> add __unlikelly to `if (!__p)` inside the `do_allocate` member function

It doesn't seem to make much difference.

[Bug fortran/96983] [11 regression] ICE compiling gfortran.dg/pr96711.f90 starting with r11-3042

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|powerpc64*-linux-gnu|powerpc64*-linux-gnu,
   ||sparc*-sun-solaris2.11
 CC||ro at gcc dot gnu.org
  Build|powerpc64*-linux-gnu|
   Host|powerpc64*-linux-gnu|

--- Comment #6 from Rainer Orth  ---
The test also FAIL on 64-bit SPARC with an ICE/SEGV:

Excess errors:
/vol/gcc/src/hg/master/local/gcc/testsuite/gfortran.dg/pr96711.f90:20:0:
internal compiler error: Segmentation Fault
0xca67df crash_signal
/vol/gcc/src/hg/master/local/gcc/toplev.c:327
0x8edab4 fold_convert_loc(unsigned int, tree_node*, tree_node*)
/vol/gcc/src/hg/master/local/gcc/fold-const.c:2405
0x67606b build_round_expr
/vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:408
0x67606b build_fix_expr
/vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:436
0x676257 gfc_conv_intrinsic_int
/vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:566
0x662867 gfc_trans_assignment_1
/vol/gcc/src/hg/master/local/gcc/fortran/trans-expr.c:10908
0x605d97 trans_code
/vol/gcc/src/hg/master/local/gcc/fortran/trans.c:1864
0x641567 gfc_generate_function_code(gfc_namespace*)
/vol/gcc/src/hg/master/local/gcc/fortran/trans-decl.c:6865
0x5a7e13 translate_all_program_units
/vol/gcc/src/hg/master/local/gcc/fortran/parse.c:6347
0x5a7e13 gfc_parse_file()
/vol/gcc/src/hg/master/local/gcc/fortran/parse.c:6616
0x60143f gfc_be_parse_file
/vol/gcc/src/hg/master/local/gcc/fortran/f95-lang.c:212

$ f951 pr96711.f90 -mptr64 -mstack-bias -mno-v8plus -quiet -m64 -mcpu=v9 -O0
-fdump-tree-original -fintrinsic-modules-path finclude -o pr96711.s

Thread 2 received signal SIGSEGV, Segmentation fault.
[Switching to Thread 1 (LWP 1)]
0x008edab4 in fold_convert_loc (loc=0, type=, arg=) at
/vol/gcc/src/hg/master/local/gcc/fold-const.c:2404
2404  if (TREE_CODE (arg) == ERROR_MARK
(gdb) where
#0  0x008edab4 in fold_convert_loc (loc=0, type=, arg=) at /vol/gcc/src/hg/master/local/gcc/fold-const.c:2404
#1  0x0067606c in build_round_expr (restype=, arg=) at
/vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:408
#2  build_fix_expr (pblock=0xffbfdde4, arg=,
type=, op=) at
/vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:436
#3  0x00676258 in gfc_conv_intrinsic_int (se=0xffbfdde4, expr=0x1be80a0,
op=RND_ROUND) at /vol/gcc/src/hg/master/local/gcc/fortran/trans-intrinsic.c:566
#4  0x00662868 in gfc_trans_assignment_1 (expr1=0x1be7ae0, expr2=0x1be80a0,
init_flag=, dealloc=, use_vptr_copy=, may_alias=) at
/vol/gcc/src/hg/master/local/gcc/fortran/trans-expr.c:10908
#5  0x00605d98 in trans_code (code=0x1be8138, cond=) at
/vol/gcc/src/hg/master/local/gcc/fortran/trans.c:1864
#6  0x00641568 in gfc_generate_function_code (ns=0x1be52c8) at
/vol/gcc/src/hg/master/local/gcc/fortran/trans-decl.c:6865
#7  0x005a7e14 in translate_all_program_units (gfc_global_ns_list=0x1be52c8) at
/vol/gcc/src/hg/master/local/gcc/fortran/parse.c:6347
#8  gfc_parse_file () at /vol/gcc/src/hg/master/local/gcc/fortran/parse.c:6616
#9  0x00601440 in gfc_be_parse_file () at
/vol/gcc/src/hg/master/local/gcc/fortran/f95-lang.c:212
#10 0x00ca69c8 in compile_file () at
/vol/gcc/src/hg/master/local/gcc/toplev.c:457
#11 0x00ca9614 in do_compile () at
/vol/gcc/src/hg/master/local/gcc/toplev.c:2314
#12 toplev::main (this=0xffbfe6b6, argc=, argv=)
at /vol/gcc/src/hg/master/local/gcc/toplev.c:2453
#13 0x016dac70 in main (argc=14, argv=0xffbfe71c) at
/vol/gcc/src/hg/master/local/gcc/main.c:39

[Bug c++/96988] Bad/missing warnings when returning a temporary from an inlined function

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-09-09

[Bug rtl-optimization/96993] invalid code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||x86_64-*-*

--- Comment #1 from Richard Biener  ---
did you by any chance look at the assembly and figured what is wrong?

[Bug rtl-optimization/96993] [10/11 Regression] invalid code

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.3
Summary|invalid code|[10/11 Regression] invalid
   ||code

[Bug rtl-optimization/96993] New: invalid code

[jan.smets at nokia dot com]

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

Bug ID: 96993
   Summary: invalid code
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jan.smets at nokia dot com
  Target Milestone: ---

Created attachment 49203
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49203=edit
testcase

Following testcase produces invalid code in 10.1, 10.2. Works with 9.3. 

%rdi is sometimes invalid in call to listReplaceEntry()   (is 0x8)
(or if listReplaceEntry() would always return, it would crash on mov   
0x18(%rbx),%rbx right before constructing %rdi for the call (%rbx is zero on
second loop iteration)

Adding simple code changes, like a asm("nop") before if (b_rep), makes it
produce working code.

Configured with: /usr/src/gcc/configure --build=x86_64-linux-gnu
--disable-multilib --enable-languages=c,c++,fortran,go

Compile testcase with -O2 [-fno-omit-frame-pointer]

[Bug d/96989] SSA_NAMEs in Wuninitialized warning messages after r11-959

[ibuclaw at gdcproject dot org]

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

--- Comment #2 from Iain Buclaw  ---
(In reply to Richard Biener from comment #1)
> I guess an actual example is still helpful

After spending a few hours away and looking back, it looks like it only happens
when using any example related to pr96564 or pr96987.

This correctly prints 'a' in the warning message.
---
int fun (uint *x) {
  uint *a = void;
  return a[2];
}
---

Whereas this print '*_3'
---
import gcc.builtins;
int fun (uint *x) {
  uint *a = cast(uint*)__builtin_malloc(*x);
  return a[2];
}
---

This prints 'MEM[(int *)a_6 + 8B]'
---
import gcc.builtins;
int fun (uint *x) {
  int *a = cast(int*)__builtin_malloc(*x);
  return a[2];
}
---

So now I'm unsure whether I should wait until the broader regression in the
middle-end is fixed, or just go ahead and implement a d_tree_printer out of
necessity to prevent the middle-end warning about lowered nodes instead of the
original symbol/code it represents.

[Bug libstdc++/96942] std::pmr::monotonic_buffer_resource causes CPU cache misses

[redi at gcc dot gnu.org]

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

--- Comment #34 from Jonathan Wakely  ---
(In reply to Dmitriy Ovdienko from comment #26)
> According to requirements to the task, I cannot implement my own memory
> arena. So I have to find way how to use STL to achieve same effect.

I assume you can't just preallocate a buffer for the pool?

  std::unique_ptr bytes(new std::byte[poolSize(stretch_depth)]);
  // Alloc then dealloc stretchdepth tree.
  int count = 0;
  for(int i = 0; i < 20; ++i)
  {
// num_nodes = 0;
MemoryPool store (bytes.get(), poolSize(stretch_depth));

Here store.release() will reuse the original buffer supplied to the
constructor, so it never actually allocates.