[Bug fortran/94377] Won't compile when deallocating a parameterized derived type

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
Either update to the most recent version of gfortran, or the code
included in this bug report is not the code that demonstrates the problem.
I get

% gfortran -c a.f90
a.f90:8:14:

   type(av_t(:), allocatable :: av(:)
  1
Error: Malformed type-spec at (1)
a.f90:17:29:

   allocate ( av_t(k2) :: av(k3), stat=ista) ! For this ista not needed
 1
Error: Allocate-object at (1) is neither a data pointer nor an allocatable
variable
a.f90:20:19:

   deallocate(av, stat=ista)
   1
Error: Allocate-object at (1) is not a nonprocedure pointer nor an allocatable
variable

for 8.3.1, 9.2.1, and 10.0

[Bug analyzer/94378] New: -Wanalyzer-malloc-leak false positive when returning a struct by value holding a heap-allocated pointer

[simon.marchi at polymtl dot ca]

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

Bug ID: 94378
   Summary: -Wanalyzer-malloc-leak false positive when returning a
struct by value holding a heap-allocated pointer
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: simon.marchi at polymtl dot ca
  Target Milestone: ---

I tried the analyzer, and I believe it outputs a false positive on this
snippet:

-

#include 

struct ret
{
  int *mem;
};

struct ret do_stuff(void)
{
  struct ret r;

  r.mem = malloc(10);

  return r;
}

-

$ /opt/gcc/git/bin/gcc -c a.c -fanalyzer
a.c: In function ‘do_stuff’:
a.c:14:10: warning: leak of ‘’ [CWE-401] [-Wanalyzer-malloc-leak]
   14 |   return r;
  |  ^
  ‘do_stuff’: events 1-2
|
|   12 |   r.mem = malloc(10);
|  |   ^~
|  |   |
|  |   (1) allocated here
|   13 | 
|   14 |   return r;
|  |  ~ 
|  |  |
|  |  (2) ‘’ leaks here; was allocated at (1)
|
a.c:14:10: warning: leak of ‘r.mem’ [CWE-401] [-Wanalyzer-malloc-leak]
   14 |   return r;
  |  ^
  ‘do_stuff’: events 1-3
|
|   12 |   r.mem = malloc(10);
|  |   ^~
|  | | |
|  | | (1) allocated here
|  | (2) allocated here
|   13 | 
|   14 |   return r;
|  |  ~ 
|  |  |
|  |  (3) ‘r.mem’ leaks here; was allocated at (2)
|

-

The caller receives the `struct ret` struct by value, and is expected to free
the `mem` field.  I believe the analyzer should not conclude that this is a
leak.

I am on commit 52f24a9e989300506f812bacb8cc302a8bf03a06 (a commit from earlier
today).

[Bug fortran/94377] New: Won't compile when deallocating a parameterized derived type

[siteg at mathalacarte dot com]

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

Bug ID: 94377
   Summary: Won't compile when deallocating a parameterized
derived type
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: siteg at mathalacarte dot com
  Target Milestone: ---

Below is the code with the problem.

program pdt
  type :: av_t(n)
integer, len :: n
integer :: i
real :: c
real :: u(n)
  end type av_t
  type(av_t(:), allocatable :: av(:)
  integer :: k2, k3
  k2 = 3
  k3 = 5
contains
  subroutine al_test(k)
integer, intent(in) :: k
integer :: ista
if (k == 1)  then
  allocate ( av_t(k2) :: av(k3), stat=ista) ! For this ista not needed
  return
else
  deallocate(av, stat=ista)
end if
  end subroutine al_test
end program pdt

Here is the compilation.

gfortran -g -o pdt pdt.f90
pdt.f90:20:0:

   20 |   deallocate(av, stat=ista)
  | 
internal compiler error: in gimplify_var_or_parm_decl, at gimplify.c:2755
0x7f446356f1a2 __libc_start_main
../csu/libc-start.c:308

[Bug c++/94376] New: When nested inside a lambda body, [=] captures by const value instead of by value

[arthur.j.odwyer at gmail dot com]

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

Bug ID: 94376
   Summary: When nested inside a lambda body, [=] captures by
const value instead of by value
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: arthur.j.odwyer at gmail dot com
  Target Milestone: ---

David Blaikie, Richard Smith, and I discovered this GCC bug while tracking down
a separate bug in llvm::function_ref whose constructor template was improperly
SFINAEd so that construction from `const T&&` was done wrong. A GCC bug caused
construction from `const T&&` to happen on GCC but not on Clang or EDG. Here's
the reduced test case:

// https://godbolt.org/z/oCvLpv
#include 
#include 

struct I {
I() { puts(__PRETTY_FUNCTION__); }
I(I&) { puts(__PRETTY_FUNCTION__); }
I(const I&) { puts(__PRETTY_FUNCTION__); }
I(I&&) { puts(__PRETTY_FUNCTION__); }
I(const I&&) { puts(__PRETTY_FUNCTION__); }

void operator++() const {}
};

int main() {
I i;
auto one = [=]() { 
return [=]() {
++i;
};
}();
puts("-");
auto two = std::move(one);  // !!
}

On the line marked "!!", one's implicitly generated move-constructor calls
`I(const I&&)` rather than `I(I&&)` to move the captured copy of `i`. It does
this because it has improperly decided that the type of the captured copy of
`i` should be `const I` instead of plain old `I`.

Richard Smith writes:
> [expr.prim.lambda.capture]p10 is the relevant rule:
> "The type of such a data member is the referenced type
> if the entity is a reference to an object, an lvalue reference
> to the referenced function type if the entity is a reference to a function,
> or the type of the corresponding captured entity otherwise."
>
> Regardless of whether you think the captured entity is
> the original variable or the member of the outer closure type,
> the type of that entity is not const-qualified.
> So the inner capture should not have a const-qualified type.

Besides exposing bugs in llvm::function_ref (a good effect!), GCC's
implementation divergence here could have the bad effect of causing additional
expensive copies when lambdas with improperly const-qualified captures are
moved around. Example:
https://godbolt.org/z/LWEF47


Bug 86697 might be related:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86697

[Bug libstdc++/93904] LWG 561 not implemented: std::inserter overly generic

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug libstdc++/94354] std::reverse_iterator comparison operators defined incorrectly

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |11.0

[Bug c/94338] struct member alignment is not carried over to alignment of struct variable

[huaixin....@alibaba-inc.com]

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

--- Comment #11 from huaixin chang  ---
(In reply to huaixin chang from comment #10)
> (In reply to Richard Biener from comment #9)
> > Btw,
> > 
> > struct X {
> > long a __attribute__((__aligned__(128)));
> > long b __attribute__((__aligned__(128)));
> > };
> > struct X A __attribute__((__aligned__(4)));
> > 
> > is not diagnosed (this is what your testcase is, decomposed).
> > 
> > I can't reproduce the diagnostics you describe in comment#5
> 
> I am sorry that I made a mistake in testing typedef described in comment#5.
> 
> I spelled __aligned__ into __aligned, got warned "warning: '__aligned'
> attribute directive ignored [-Wattributes]", and thought I got diagnosed
> because of reduction in alignment. As a result, neither type foo nor object
> A is reduced in alignment with the code describe in comment#5.
> 
> I have tested typedef again, and found that it behaves the same with using
> struct under gcc 9.2.1. That is to say, no matter I define A using struct
> like:
> 
> ---
> struct X {
> long a __attribute__((__aligned__(128)));
> long b __attribute__((__aligned__(128)));
> };
> struct X A __attribute__((__aligned__(4)));
> 
> or use typedef and reduce the alignment of type foo like:
> ---
> typedef struct {
> long a __attribute__((__aligned__(128)));
> long b __attribute__((__aligned__(128)));
> } foo __attribute__((__aligned(4)));

Another spelling mistake. It should be:

} foo __attribute__((__aligned__(4)));

> 
> foo A;
> 
> or use typedef and reduce the alignment of A like:
> ---
> typedef struct {
> long a __attribute__((__aligned__(128)));
> long b __attribute__((__aligned__(128)));
> } foo;
> 
> foo A __attribute__((__aligned__(4)));
> 
> I got no warn on compiling and it behaves like this.
> ---
> address of A 0x42003c
> alignof A 4
> address of A.a 0x42003c
> alignof A.a 128
> address of A.b 0x4200bc
> alignof A.b 128
> address of B 0x420038

[Bug middle-end/90056] 548.exchange2_r regressions on AMD Zen

[jamborm at gcc dot gnu.org]

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

--- Comment #3 from Martin Jambor  ---
So replaced with more specific bugs for newer hardware: PR94373 and PR94375.

[Bug tree-optimization/94374] modification of constant scalars sometimes eliminated, sometimes not

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=94313,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90404

--- Comment #1 from Martin Sebor  ---
As in pr94313, the intent of this report is simply to document the cases where
the removal of these modifying statements is making their reliable detection
(requested in pr90404) difficult.

[Bug tree-optimization/94374] New: modification of constant scalars sometimes eliminated, sometimes not

[msebor at gcc dot gnu.org]

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

Bug ID: 94374
   Summary: modification of constant scalars sometimes eliminated,
sometimes not
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

Similar to pr94313, the test case below shows that GCC silently eliminates some
statements that modify const scalars while emitting others.  As in the other
report, while this isn't strictly wrong (the modification is undefined), doing
so silently, without a warning, is unhelpful.  It prevents the bugs from
getting fixed, and leads to inconsistent results at runtime.

At a minimum, GCC should diagnose all these cases before removing them. 
Preferably, however, it should treat all of them the same (i.e., either remove
all of them or none), ideally leaving the choice of which up to the user.  The
three alternative strategies that have been suggested as most useful are:
either a) removal, or b) insertion of __builtin_trap, or c) insertion of
__builtin_unreachable.

$ cat d.c && gcc -O2 -S -Wall -fdump-tree-optimized=/dev/stdout d.c
extern const int a;

int fa (void)
{ 
  int *p = (int*)
  ++*p;// not eliminated
  return *p;   // not folded
}

static const int b;

int fb (void)
{
  int *p = (int*)
  ++*p;// eliminated
  return *p;   // folded to zero
}

int fc (void)
{ 
  static const int c;
  int *p = (int*)
  ++*p;// eliminated
  return *p;   // folded to zero
}

int fd (void)
{
  const int d = 0;
  int *p = (int*)
  ++*p;// not eliminated
  return *p;   // folded to 1
}


;; Function fa (fa, funcdef_no=0, decl_uid=1931, cgraph_uid=1, symbol_order=0)

fa ()
{
  int _1;
  int _2;

   [local count: 1073741824]:
  _1 = a;
  _2 = _1 + 1;
  a = _2;
  return _2;

}



;; Function fb (fb, funcdef_no=1, decl_uid=1936, cgraph_uid=2, symbol_order=2)

fb ()
{
   [local count: 1073741824]:
  return 0;

}



;; Function fc (fc, funcdef_no=5, decl_uid=1940, cgraph_uid=3, symbol_order=3)

fc ()
{
   [local count: 1073741824]:
  return 0;

}



;; Function fd (fd, funcdef_no=3, decl_uid=1945, cgraph_uid=4, symbol_order=4)

fd ()
{
   [local count: 1073741824]:
  return 1;

}

[Bug tree-optimization/94375] New: 548.exchange2_r run time is 8-18% worse than GCC 9 at -Ofast -march=native

[jamborm at gcc dot gnu.org]

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

Bug ID: 94375
   Summary: 548.exchange2_r run time is 8-18% worse than GCC 9 at
-Ofast -march=native
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

When compiled with trunk revision 26b3e568a60 and options -Ofast
-march=native -mtune=native, SPEC 2017 INTrate benchmark
548.exchange2_r runs 19% slower on AMD Zen2 and 12% slower on Intel
Cascade Lake than when built with GCC 9.2.

It appears that the main culprit is the vectorizer, switching it off
recovers the performance - it is in fact even some 4% better than GCC
9 on AMD).

Side note: with --param ipa-cp-eval-threshold=1 --param
ipa-cp-unit-growth=80 one can exchange that is 25% faster yet but that
is a different issue.

This started happening in the autumn but not exactly at one point, as
the following table of run-times relative to GCC 9.2 shows. 

Revision:  time 
-  
d82f38123b5 (Nov 14 2019)  117%
d9adca6e663 (Nov 5 2019)   117%
bf037872d3c (Oct 24 2019)  101%
77ef339456f (Oct 14 2019)  118%
38a734350fd (Oct 3 2019)   100%
d469a71e5a0 (Sep 23 2019)  101%


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug libstdc++/94354] std::reverse_iterator comparison operators defined incorrectly

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r10-7434-g81a8d137c22953df2ea046466c62cd26c0dba103
Author: Jonathan Wakely 
Date:   Fri Mar 27 23:21:58 2020 +

libstdc++: Add remaining C++20 changes to iterator adaptors

This adds the missing parts of P0896R4 to reverse_iterator and
move_iterator, so that they meet the C++20 requirements. This should be
the last piece of P0896R4, meaning ranges support is now complete.

The PR 94354 bug with reverse_iterator's comparisons is fixed for C++20
only, but that change should be extended to C++11, C++14 and C++17 modes
in stage 1.

* include/bits/stl_iterator.h (reverse_iterator::iterator_concept)
(reverse_iterator::iterator_category): Define for C++20.
(reverse_iterator): Define comparison operators correctly for
C++20.
(__normal_iterator): Add constraints to comparison operators for
C++20.
(move_iterator::operator++(int)) [__cpp_lib_concepts]: Define new
overload for input iterators.
(move_iterator): Add constraints to comparison operators for C++20.
Define operator<=> for C++20.
* testsuite/24_iterators/move_iterator/input_iterator.cc: New test.
* testsuite/24_iterators/move_iterator/move_only.cc: New test.
* testsuite/24_iterators/move_iterator/rel_ops_c++20.cc: New test.
* testsuite/24_iterators/reverse_iterator/rel_ops_c++20.cc: New
test.

[Bug target/87163] ICE in extract_insn, at recog.c:2305

[seurer at linux dot vnet.ibm.com]

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

Bill Seurer  changed:

   What|Removed |Added

 CC||meissner at gcc dot gnu.org,
   ||seurer at linux dot 
vnet.ibm.com

--- Comment #8 from Bill Seurer  ---
I have duplicated the bug on a cross compile but not natively.

It occurs in the one function:

int do_signbit_if (__ibm128 a) { return __builtin_signbit (a); }

Natively this looks like this when dumped:

;;
;; Full RTL generated for this function:
;;
(note 1 0 4 NOTE_INSN_DELETED)
(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 4 3 2 (set (mem/c:TF (reg/f:DI 112 virtual-stack-vars) [1 a+0 S16
A128])
(reg:TF 33 1 [ a ])) "./signbit-1.c":7:32 -1
 (nil))
...

Cross:
;;
;; Full RTL generated for this function:
;;
(note 1 0 4 NOTE_INSN_DELETED)
(note 4 1 2 2 [bb 2] NOTE_INSN_BASIC_BLOCK)
(insn 2 4 3 2 (set (mem/c:IF (reg/f:DI 112 virtual-stack-vars) [1 a+0 S16
A128])
(reg:IF 33 1 [ a ])) "./signbit-1.c":7:32 -1
 (nil))
...

Note the reg/mem differences.  There are similar ones further on.

[Bug target/94123] [10 regression] r10-1734, SVN r273240, causes gcc.target/powerpc/pr87507.c to fail

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2020-March/5
   ||42840.html

--- Comment #10 from Peter Bergner  ---
I submitted 2 proposed patches that both fix the issue.  Waiting to see which
patch people prefer...if any.

[Bug c/60846] Add 128-bit integer types for general use on 32-bit/64-bit CPUs

[joseph at codesourcery dot com]

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

--- Comment #9 from joseph at codesourcery dot com  ---
Note that supporting on any given 32-bit architecture requires making a 
choice of what the function-calling ABI should be for such types (and 
corresponding complex types) as function arguments and return values; 
architecture maintainers would need to make such a choice, in consultation 
with any group there may be that maintains the ABI for that architecture.

[Bug target/94145] Longcalls mis-optimize loading the function address

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Alan Modra :

https://gcc.gnu.org/g:19e5389debb03c3623f6a2ce8a8f6f4aa2118901

commit r10-7430-g19e5389debb03c3623f6a2ce8a8f6f4aa2118901
Author: Alan Modra 
Date:   Wed Mar 11 21:22:37 2020 +1030

[RS6000] PR94145, make PLT loads volatile

The PLT is volatile.  On PowerPC it is a bss style section which the
dynamic loader initialises to point at resolver stubs (called glink on
PowerPC64) to support lazy resolution of function addresses.  The
first call to a given function goes via the dynamic loader symbol
resolver, which updates the PLT entry for that function and calls the
function.  The second call, if there is one and we don't have a
multi-threaded race, will use the updated PLT entry and thus avoid
the relatively slow symbol resolver path.

Calls via the PLT are like calls via a function pointer, except that
no initialised function pointer is volatile like the PLT.  All
initialised function pointers are resolved at program startup to point
at the function or are left as NULL.  There is no support for lazy
resolution of any user visible function pointer.

So why does any of this matter to gcc?  Well, normally the PLT call
mechanism happens entirely behind gcc's back, but since we implemented
inline PLT calls (effectively putting the PLT code stub that loads the
PLT entry inline and making that code sequence scheduled), the load of
the PLT entry is visible to gcc.  That load then is subject to gcc
optimization, for example in

/* -S -mcpu=future -mpcrel -mlongcall -O2.  */
int foo (int);
void bar (void)
{
  while (foo(0))
foo (99);
}

we see the PLT load for foo being hoisted out of the loop and stashed
in a call-saved register.  If that happens to be the first call to
foo, then the stashed value is that for the resolver stub, and every
call to foo in the loop will then go via the slow resolver path.  Not
a good idea.  Also, if foo turns out to be a local function and the
linker replaces the PLT calls with direct calls to foo then gcc has
just wasted a call-saved register.

This patch teaches gcc that the PLT loads are volatile.  The change
doesn't affect other loads of function pointers and thus has no effect
on normal indirect function calls.  Note that because the
"optimization" this patch prevents can only occur over function calls,
the only place gcc can stash PLT loads is in call-saved registers or
in other memory.  I'm reasonably confident that this change will be
neutral or positive for the "ld -z now" case where the PLT is not
volatile, in code where there is any register pressure.  Even if gcc
could be taught to recognise cases where the PLT is resolved, you'd
need to discount use of registers to cache PLT loads by some factor
involving the chance that those calls would be converted to direct
calls.

PR target/94145
* config/rs6000/rs6000.c (rs6000_longcall_ref): Use unspec_volatile
for PLT16_LO and PLT_PCREL.
* config/rs6000/rs6000.md (UNSPEC_PLT16_LO, UNSPEC_PLT_PCREL):
Remove.
(UNSPECV_PLT16_LO, UNSPECV_PLT_PCREL): Define.
(pltseq_plt16_lo_, pltseq_plt_pcrel): Use unspec_volatile.

[Bug c/60846] Add 128-bit integer types for general use on 32-bit/64-bit CPUs

[pinskia at gcc dot gnu.org]

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

--- Comment #8 from Andrew Pinski  ---
Note with __builtin_*_overflow, implementing 128bit integer (or larger) as a
class for C++ should be easier now.

[Bug c++/84733] [8 Regression] internal compiler error: Segmentation fault (check_local_shadow())

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
 CC||egallager at gcc dot gnu.org

--- Comment #25 from Eric Gallager  ---
(In reply to Nathan Sidwell from comment #23)
> Fixed trunk and gcc-9

And 8 now too:

(In reply to CVS Commits from comment #24)
> The releases/gcc-8 branch has been updated by Nathan Sidwell
> :
> 
> https://gcc.gnu.org/g:4c36b54de7ddbcb580f4b99936af4a0195db9d2f
> 
> commit r8-10145-g4c36b54de7ddbcb580f4b99936af4a0195db9d2f
> Author: Nathan Sidwell 
> Date:   Fri Mar 27 13:24:27 2020 -0700
> 
> c++: Fix ICE on popping local scope [pr84733]
> 
> PR c++/84733
> * name-lookup.c (do_pushdecl): Look through cleanp levels.

So, FIXED.

[Bug target/94373] 548.exchange2_r run time is 7-12% worse than GCC 9 at -O2 and generic march/mtune

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
  Component|tree-optimization   |target

--- Comment #1 from Andrew Pinski  ---
Seems IV related and most likely a target cost model issue too.

[Bug tree-optimization/94373] New: 548.exchange2_r run time is 7-12% worse than GCC 9 at -O2 and generic march/mtune

[jamborm at gcc dot gnu.org]

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

Bug ID: 94373
   Summary: 548.exchange2_r run time is 7-12% worse than GCC 9 at
-O2 and generic march/mtune
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: rguenth at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

When compiled with just -O2, SPEC 2017 INTrate benchmark
548.exchange2_r runs slower than when compiled with GCC 9.2. It is:

-  8% slower on AMD Zen2-based server CPU (rev. 26b3e568a60)
- 12% slower on Intel Cascade Lake server CPU (rev. abe13e1847f)
-  7% slower on AMD Zen1-based server CPU (rev. 26b3e568a60)

During GCC 10 development cycle the benchmark was relatively noisy and
the run time was increasing in many small steps, but between October 7
and November 15 we were doing 3% better than GCC 9 (on Zen2).
Specifically the following commit brought about the improvement:

  commit 806bdf4e40d31cf55744c876eb9f17654de36b99
  Author: Richard Biener 
  Date:   Mon Oct 7 07:53:45 2019 +

re PR tree-optimization/91975 (worse code for small array copy using
pointer arithmetic than array indexing)

2019-10-07  Richard Biener  

PR tree-optimization/91975
* tree-ssa-loop-ivcanon.c (constant_after_peeling): Consistently
handle invariants.

From-SVN: r276645

But it was undone by its revert:

  commit f0af4848ac40d2342743c9b16416310d61db85b5
  Author: Richard Biener 
  Date:   Fri Nov 15 09:09:16 2019 +

re PR tree-optimization/92039 (Spurious -Warray-bounds warnings building
32-bit glibc)

2019-11-15  Richard Biener  

PR tree-optimization/92039
PR tree-optimization/91975
* tree-ssa-loop-ivcanon.c (constant_after_peeling): Revert
previous change, treat invariants consistently as non-constant.
(tree_estimate_loop_size): Ternary ops with just the first op
constant are not optimized away.

* gcc.dg/tree-ssa/cunroll-2.c: Revert to state previous to
unroller adjustment.
* g++.dg/tree-ssa/ivopts-3.C: Likewise.

From-SVN: r278281

On the Intel machine, reverting the revert fixes the regression too.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[iains at gcc dot gnu.org]

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

--- Comment #3 from Iain Sandoe  ---
Note1 : the 32b multilib works without any error.

Note2 : The dumps are gimple from symmetric-transfer-00-basic.C.020t.fixup_cfg1
which is the pass after all the coroutine-specific stuff is complete.

thus, For O0 (produces the error saying it can't tail call):

   :
actor.continue.ret:
  actor.continue = VIEW_CONVERT_EXPR(D.38505);
  _38 = std::__n4835::coroutine_handle::address ();
  _39 = MEM[(void (*) (void *) *)_38];
  _39 (_38); [tail call] [must tail call]
  goto ; [INV]

...

   :

   :
  actor.continue = {CLOBBER};

   :
:
  return;



for O2 (execute fails, because without the tail-call we overflow the stack).

   :
actor.continue.ret:
  frame_ptr->__resume_at = 6;
  _22 = _ptr->__lv.1.1.aw;
  D.38734 = Loopy::loopy_awaiter::await_suspend (_22,
frame_ptr->__self_h); [return slot optimization]
  actor.continue = VIEW_CONVERT_EXPR(D.38734);
  _38 = std::__n4835::coroutine_handle::address ();
  _39 = MEM[(void (*) (void *) *)_38];
  _39 (_38); [tail call]
  goto ; [INV]

...

   :
actor.suspend.ret:
:
  actor.continue = {CLOBBER};
  return;

[Bug c++/90711] [9/10 Regression] Failing SFINAE from unrelated struct since r9-6794

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/94314] [10 Regression] Optimizing mismatched new/delete pairs since r10-2106-g6343b6bf3bb83c87

[jason at gcc dot gnu.org]

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

--- Comment #6 from Jason Merrill  ---
(In reply to Marc Glisse from comment #5)
> I don't think we need heavy machinery linking new and delete (and if we did
> I'd be tempted to store it in some global table rather than in the nodes).
> The most important case is the global replacable functions, for which we
> have a finite list, and for those a few checks like not matching array with
> non-array versions should do. For user overloads with attribute malloc (a
> gcc extension), I would go with heuristics like both/neither being class
> members, being members of the same class, etc. Although I am not quite sure
> how doable that is from the middle-end, how much of that information is
> still available (I think it is available in the mangled name, but demangling
> doesn't seem like a great idea).

It should be sufficient to check whether they have the same DECL_CONTEXT.

[Bug middle-end/94339] [10 regression] ICE in tree_class_check_failed since r10-7344-gca6c722561ce9b9d

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:54de5afb4a9b2f7296f614820a33ec0e4eb8bf39

commit r10-7429-g54de5afb4a9b2f7296f614820a33ec0e4eb8bf39
Author: Jakub Jelinek 
Date:   Fri Mar 27 22:29:50 2020 +0100

c++: Handle COMPOUND_EXPRs in ocp_convert [PR94339]

With the PR94346 fix in, we can revert the attr-copy-2.C workaround.

2020-03-27  Jakub Jelinek  

PR c++/94339
* g++.dg/ext/attr-copy-2.C: Revert the last changes.

[Bug target/94372] New: pthread doesn't define _REENTRANT in preprocessor on OpenRISC

[bernd.ku...@t-online.de]

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

Bug ID: 94372
   Summary: pthread doesn't define _REENTRANT in preprocessor on
OpenRISC
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bernd.ku...@t-online.de
  Target Milestone: ---

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

OpenRISC doesn't have _REENTRANT defined when -pthread is appended.

Some software, like libmicrohttpd, check in their configure script if
_REENTRANT is correctly defined as seen on buildroot autobuilders:
http://autobuild.buildroot.net/results/ceb802eea0fee5812efd717ae4cdbd9673d9507e/libmicrohttpd-0.9.70/config.log

This bug is similar to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84475

[Bug analyzer/94371] New: Macro-printing within diagnostic paths can be very verbose.

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 94371
   Summary: Macro-printing within diagnostic paths can be very
verbose.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

The default -fdiagnostics-path-format=inline-events prints each macro expansion
for every event in the path that's from a macro expansion.  This can be very
verbose; consider e.g. the krb5 example here:
  https://dmalcolm.fedorapeople.org/gcc/2020-02-28/recvauth.c.html
where there's a:
 #define krb5_xfree(val) free((char *)(val))
The expansion is printed many times:
* for the primary location of each of the two diagnostics
* for events 9, 10, and 11 of the first diagnostic
* for events 9, 10, 12 and 13 of the second diagnostic
i.e. it's printed 4 times for the first diagnostic, and 5 times for the second
diagnostic.

Ideas for making it less verbose:
* only print macro expansions with paths once per path (so in the example it
would print the expansions per primary loc, and once per path)
* only print macro expansions within paths once per diagnostic_group (and not
printing it if the primary location showed it, so in the example it would only
print it per primary loc)
* only once within paths per diagnostic_context (so it the example it would
only print it once)
* or some other kind of consolidation

However, this is a simple macro; it's not clear what we should do with more
complicated macros.  Perhaps do it per token of the macro, so that if we're
exploring control flow within a macro, we show that.

[Bug c++/94155] internal compiler error: in gimplify_init_ctor_eval, at gimplify.c:4664

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Even simpler:

struct S { int i, j; };

struct A {
  S s;
  constexpr A(S e) : s(e) {}
};

void
f()
{
  A g[1]({{1, 1}});
}

[Bug c/60846] Add 128-bit integer types for general use on 32-bit/64-bit CPUs

[feliks314159 at yahoo dot com]

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

Bill Gray  changed:

   What|Removed |Added

 CC||feliks314159 at yahoo dot com

--- Comment #7 from Bill Gray  ---
I'd really like to see 128-bit ints made available on 32-bit targets.  I
realize it wouldn't be fast for multiplying/dividing,  but almost all of my use
cases (and most uses in general,  I'd bet,  except for crypto) involve bitwise
operations.

For that matter,  I'd expect crypto folks would welcome 256- and higher-count
integers (get a SHA256 hash in a single scalar value).  But perhaps not;  they
already have workarounds for such issues.

[Bug c++/94078] bogus and missing -Wmismatched-tags on an instance of a template

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Fixed in r10-7424.  GCC's poutput is now as expected:

$ gcc -O2 -S -Wall  -Wmismatched-tags -Wredundant-tags pr94078.C
pr94078.C:2:8: warning: redundant class-key ‘class’ in reference to ‘struct
S’ [-Wredundant-tags]
2 | extern class S si;// missing -Wmismatched-tags
  |^
  |-
pr94078.C:3:8: warning: redundant class-key ‘struct’ in reference to ‘class
S’ [-Wredundant-tags]
3 | extern struct S si;   // bogus -Wmismatched-tags
  |^~
  |--
pr94078.C:2:14: warning: ‘S’ declared with a mismatched class-key ‘class’
[-Wmismatched-tags]
2 | extern class S si;// missing -Wmismatched-tags
  |  ^~
pr94078.C:2:14: note: replace the class-key with ‘struct’
pr94078.C:1:25: note: ‘S’ first declared as ‘struct’ here
1 | template  struct S;
  | ^

[Bug c++/93824] bogus -Wredundant-tags on a first declaration in use

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Sebor  ---
Fixed in r10-7424.  Stephan, please give it a try and open new bugs if you run
into any other issues.

[Bug middle-end/26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[jamborm at gcc dot gnu.org]

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

Bug 90056 Summary: 548.exchange2_r regressions on AMD Zen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90056

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

[Bug middle-end/90056] 548.exchange2_r regressions on AMD Zen

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |MOVED

--- Comment #2 from Martin Jambor  ---
(In reply to Martin Jambor from comment #0)
> As of revision 270053, the 548.exchange2_r benchmark from SPEC 2017
> INTrate suite suffered a number of smaller regressions on AMD Zen
> CPUs:
> 
>   - At -O2, it is 4.5% slower than when compiled with GCC 7

I am about to file a specific bug about exchange at -O2.

>   - At -Ofast, it is 4.7% slower than when compiled with GCC 8

This is no longer true.

>   - At -Ofast -march=native -mutine=native, this difference is 6.9%

Again, I will file a more specific bug about -Ofast -march=native in a
little while.

>   - At -Ofast and native tuning, it is 6% slower with PGO than
> without it.

I can still see this in my measurements on Zen1-based CPU but not in
those done on AMD Zen2 or Intel Cascade Lake.  So I am not sure if we
care.  I'll e happy to file a specific bug if we do.

[Bug c++/94346] [9 Regression] ICE due to handle_copy_attribute since r9-3982

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

  Known to work||10.0
Summary|[9/10 Regression] ICE due   |[9 Regression] ICE due to
   |to handle_copy_attribute|handle_copy_attribute since
   |since r9-3982   |r9-3982
  Known to fail|10.0|

--- Comment #7 from Martin Sebor  ---
The ICE is resolved for GCC 10.  The patch should be safe enough to backport to
GCC 9 after a few days.

[Bug c++/94346] [9/10 Regression] ICE due to handle_copy_attribute since r9-3982

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

https://gcc.gnu.org/g:52f24a9e989300506f812bacb8cc302a8bf03a06

commit r10-7428-g52f24a9e989300506f812bacb8cc302a8bf03a06
Author: Martin Sebor 
Date:   Fri Mar 27 14:24:03 2020 -0600

PR c++/94346 - [9/10 Regression] ICE due to handle_copy_attribute since
r9-3982

gcc/c-family/ChangeLog:

PR c++/94346
* c-attribs.c (handle_copy_attribute): Avoid passing expressions
to decl_attributes.  Make handling of different kinds of entities
more robust.

gcc/c-c++-common/ChangeLog:

PR c++/94346
* c-c++-common/attr-copy.c: New test.

[Bug c++/84733] [8 Regression] internal compiler error: Segmentation fault (check_local_shadow())

[cvs-commit at gcc dot gnu.org]

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

--- Comment #24 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Nathan Sidwell
:

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

commit r8-10145-g4c36b54de7ddbcb580f4b99936af4a0195db9d2f
Author: Nathan Sidwell 
Date:   Fri Mar 27 13:24:27 2020 -0700

c++: Fix ICE on popping local scope [pr84733]

PR c++/84733
* name-lookup.c (do_pushdecl): Look through cleanp levels.

[Bug c++/94155] internal compiler error: in gimplify_init_ctor_eval, at gimplify.c:4664

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Reduced:

template  struct A {
  int i;
  T t;
  constexpr A(int, T e) : i(), t(e) {}
};

void
f()
{
  A> g[1]({1, {1, 1}});
}

We ICE because we don't satisfy:
 4662   /* ??? Here's to hoping the front end fills in all of the indices,
 4663  so we don't have to figure out what's missing ourselves.  */
 4664   gcc_assert (purpose);

[Bug web/94351] bugzilla search is not as useful as before

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|RESOLVED|CLOSED

--- Comment #6 from Andrew Pinski  ---
(In reply to Frédéric Buclin from comment #5)
> Template-Toolkit has been upgraded to 3.007. Problem fixed.

Thanks.

[Bug tree-optimization/93946] Bogus redundant store removal

[sandra at gcc dot gnu.org]

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

--- Comment #11 from sandra at gcc dot gnu.org ---
RTL before sched2 does look sane and similar to that generated for x86 with
-m32.

I've been trying to step through sched2.  I think that where things get
interesting is the call to true_dependence at sched-deps.c:2663.

Breakpoint 6, true_dependence (mem=0x7742c9a8, mem_mode=E_VOIDmode, 
x=0x7742cac8)
at /scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/alias.c:3056
3056  return true_dependence_1 (mem, mem_mode, NULL_RTX,
(gdb) print debug_rtx(mem)
(mem/j:SI (reg/v/f:SI 5 r5 [orig:48 ptr ] [48]) [1 MEM[(struct aa
*)ptr_1(D)].a.u.i+0 S4 A32])
$19 = void
(gdb) print debug_rtx(x)
(mem/j:SI (reg/v/f:SI 4 r4 [orig:47 bv ] [47]) [1 bv_3(D)->b.u.f+0 S4 A32])
$20 = void

This is making it all the way to the end of true_dependence_1, into
rtx_refs_may_alias_p, and into refs_may_alias_p_1, which is returning false,
which gets propagated back up as the result of true_dependence.  IIUC, this is
what is allowing sched2 to move the read from "x" ahead of the write to "mem".

Before I spend more time on this, am I on the right track here?  And is this
pointing at the problem being in refs_may_alias_p_1 rather than somewhere along
the way e.g. in true_dependence_1?

[Bug c++/94326] g++: error: pack.ii: ‘-fcompare-debug’ failure (length)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #6 from Jakub Jelinek  ---
Fixed for 10+.

[Bug middle-end/94339] [10 regression] ICE in tree_class_check_failed since r10-7344-gca6c722561ce9b9d

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #8 from Jakub Jelinek  ---
Fixed.

[Bug c++/84733] [8/9/10 Regression] internal compiler error: Segmentation fault (check_local_shadow())

[nathan at gcc dot gnu.org]

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

--- Comment #23 from Nathan Sidwell  ---
Fixed trunk and gcc-9

[Bug c++/84733] [8/9/10 Regression] internal compiler error: Segmentation fault (check_local_shadow())

[cvs-commit at gcc dot gnu.org]

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

--- Comment #22 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Nathan Sidwell
:

https://gcc.gnu.org/g:070a0b6392d682f11ca79d22ae00bc822332cdcf

commit r9-8419-g070a0b6392d682f11ca79d22ae00bc822332cdcf
Author: Nathan Sidwell 
Date:   Fri Mar 27 13:13:39 2020 -0700

c++: Fix ICE popping local scope [pr84733]

PR c++/84733
* name-lookup.c (do_pushdecl): Look through cleanp levels.

[Bug c++/84733] [8/9/10 Regression] internal compiler error: Segmentation fault (check_local_shadow())

[cvs-commit at gcc dot gnu.org]

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

--- Comment #21 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

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

commit r10-7427-gc7fc15f54b321b2522ae26abebb86957de5c6fae
Author: Nathan Sidwell 
Date:   Fri Mar 27 13:09:12 2020 -0700

[pr84733]  Fix ICE popping local scope

PR c++/84733
* name-lookup.c (do_pushdecl): Look through cleanp levels.

[Bug web/94351] bugzilla search is not as useful as before

[LpSolit at gmail dot com]

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

Frédéric Buclin  changed:

   What|Removed |Added

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

--- Comment #5 from Frédéric Buclin  ---
Template-Toolkit has been upgraded to 3.007. Problem fixed.

[Bug web/94349] Bugzilla user preferences are blank

[LpSolit at gmail dot com]

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

Frédéric Buclin  changed:

   What|Removed |Added

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

--- Comment #7 from Frédéric Buclin  ---
Template-Toolkit has been upgraded to 3.007. Problem fixed.

[Bug c++/94098] [10 Regression] ICE: canonical types differ for identical types 'int(void*, void*)' and 'int(void*, void*)'

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Sebor  ---
Fixed via r10-7426.

[Bug c++/94098] [10 Regression] ICE: canonical types differ for identical types 'int(void*, void*)' and 'int(void*, void*)'

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Martin Sebor :

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

commit r10-7426-gccacf77be5508dd5b4df59f402965196d11edb05
Author: Martin Sebor 
Date:   Fri Mar 27 13:54:22 2020 -0600

PR c++/94098 - ICE on attribute access redeclaration

gcc/c-family/ChangeLog:

PR c++/94098
* c-attribs.c (handle_access_attribute): Avoid setting
TYPE_ATTRIBUTES
here.

gcc/ChangeLog:

PR c++/94098
* calls.c (init_attr_rdwr_indices): Iterate over all access
attributes.

gcc/testsuite/ChangeLog:

PR c++/94098
* g++.dg/ext/attr-access-2.C: New test.

[Bug c/94370] New: double negation in diagnostic

[roland.illig at gmx dot de]

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

Bug ID: 94370
   Summary: double negation in diagnostic
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

>From c-typeck.c:
> warning_at (input_location, OPT_Wattributes,
> "%qs attribute cannot be applied to a function that "
> "does not take variable arguments", "format");

"cannot ... does not" is a double negation, which for most people is difficult
to understand. For situations like these, there is the word "only":

"%qs attribute can only be applied to a function that "
"takes variable arguments"

[Bug c++/94255] template specialization in different namespace causes crash

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2020-03-27

--- Comment #4 from Marek Polacek  ---
Confirmed, started with r0-113135-g28704289327e4295928663b5bab7953718f71bc1

[Bug c++/84733] [8/9/10 Regression] internal compiler error: Segmentation fault (check_local_shadow())

[jakub at gcc dot gnu.org]

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

--- Comment #20 from Jakub Jelinek  ---
And even r10-7425 still ICEs.

[Bug gcov-profile/94369] New: 505.mcf_r is 6-7% slower at -Ofast -march=native with PGO+LTO than with just LTO

[jamborm at gcc dot gnu.org]

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

Bug ID: 94369
   Summary: 505.mcf_r is 6-7% slower at -Ofast -march=native with
PGO+LTO than with just LTO
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

SPEC 2017 INTrate benchmark 505.mcf_r, when compiled with options
-Ofast -march=native -mtune=native, is 6-7% slower when compiled with
both PGO and LTO than when built with just LTO.  I have observed this
on both AMD Zen2 (7%) and Intel Cascade Lake (6%) server CPUs.  The
train run cannot be very bad because without LTO, PGO improves
run-time by 15% on both systems.  This is with master revision
26b3e568a60.

Profiling results (from an AMD CPU):

LTO:

  OverheadSamples  Shared ObjectSymbol 
    .  ...  

39.53% 518450  mcf_r_peak.mine  spec_qsort.constprop.0
22.13% 289745  mcf_r_peak.mine  master.constprop.0
19.00% 248641  mcf_r_peak.mine  replace_weaker_arc
 9.37% 122669  mcf_r_peak.mine  main
 8.60% 112601  mcf_r_peak.mine  spec_qsort.constprop.1

PGO+LTO:

  OverheadSamples  Shared ObjectSymbol 
    .  ...  ...

40.13% 562770  mcf_r_peak.mine  spec_qsort.constprop.0
21.68% 303543  mcf_r_peak.mine  master.constprop.0
18.24% 255236  mcf_r_peak.mine  replace_weaker_arc
10.32% 144433  mcf_r_peak.mine  main
 8.07% 112775  mcf_r_peak.mine  arc_compare

Perhaps I should note that we have patched qsort in the benchmark to
work with strict aliasing even with LTO.  But the performance gap is
there also with -fno-strict-aliasing.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug c++/84733] [8/9/10 Regression] internal compiler error: Segmentation fault (check_local_shadow())

[jakub at gcc dot gnu.org]

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

--- Comment #19 from Jakub Jelinek  ---
(In reply to Nathan Sidwell from comment #18)
> fixed GCC 10 13dfc007557c384683118fa12cd255e69b70a34d

I don't see such a commit in the repo.

[Bug libgomp/94290] [gfortran] OpenMP target teams distribute default firstprivate causes failure to map back values from device

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
This is a test bug.  Please see
https://www.openmp.org/spec-html/5.0/openmpse22.html#x116-4340002.14
When you have a combined or composite constructs, clauses that apply to just
one of the constructs generally are applied to the construct which allows them,
while clauses that can be applied to multiple constructs have more complicated
clause distribution rules in that section.
When you have combined
!$omp target teams default(firstprivate) map(from:a)
then the default clause, as it applies to teams only and not target, goes to
teams, and map clauses go to target.
So, it is like
!$omp target map(from:a)
!$omp teams default(firstprivate)
Now, if you reference a in the teams region, there is no data sharing clause on
the teams construct for a, and the default is firstprivate, which means an
implicit firstprivate(a) clause is added to the teams construct.  The target
construct has a map clause, so a on that construct is mapped rather than
privatized, which means that each team will have its own privatized copy of a,
and the uninitialized original mapped a is then copied back.
Either don't use default(firstprivate) on the combined constructs because you
really want sharing for those vars, or you can use
!$omp target teams default(firstprivate) map(from:a) shared(a)
While OpenMP has a restriction that the same list item can't be specified in
mapping and data sharing clauses, my understanding is that this applies after
the clauses are distributed among the constituent constructs, and as target
construct doesn't allow shared clause and teams construct doesn't allow map
clause, each goes to one of them and should do what you want.
Adding shared(a, b, c, d) clause to both combined directives in your testcase
fixes it.  You can even just add shared(d), though in that case the a, b, c
arrays are mapped to the device and then copied from that to each of the teams
private copies.

[Bug gcov-profile/91601] gcov: ICE in handle_cycle, at gcov.c:699 happen which get code coverage with lcov.

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #13 from Marek Polacek  ---
The fix hasn't been backported to gcc 8 but the problem exists there too. 
Martin, will you fix 8 too?

[Bug c++/84733] [8/9/10 Regression] internal compiler error: Segmentation fault (check_local_shadow())

[nathan at gcc dot gnu.org]

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

--- Comment #18 from Nathan Sidwell  ---
fixed GCC 10 13dfc007557c384683118fa12cd255e69b70a34d

[Bug c/94081] -Waddress-of-packed-member doesn’t take variable attributes or __builtin_assume_aligned into account

[felix.von.s at posteo dot de]

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

My initial report text was apparently lost in the Bugzilla migration, so here I
am submitting it again.



In this code:

#include 

struct foo {
uint16_t a, b;
} __attribute__((packed));

extern struct foo *f(void);
extern void g(uint16_t *p);

void h(void) {
struct foo *s0 = __builtin_assume_aligned(f(), 16);
g(>a);

struct foo s1 __attribute__ ((aligned(16)));
g();
}

GCC will warn about taking the address of s0->a and s1.a, even though it has
enough information to recognise those as false positives.

On many platforms, variables on the stack are naturally aligned at a 32-bit (or
coarser) boundary, so I believe  is a false positive on those platforms
even without the attribute, but I’m less sure if skipping the warning for this
case is desirable.

[Bug rtl-optimization/94368] New: [9/10 Regression] ICE in final_scan_insn_1, at final.c:3074(error: could not split insn) on aarch64-linux-gnu

[doko at debian dot org]

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

Bug ID: 94368
   Summary: [9/10 Regression] ICE in final_scan_insn_1, at
final.c:3074(error: could not split insn) on
aarch64-linux-gnu
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen with gcc-9 branch 20200325, with -O1 on aarch64-linux-gnu.

$ cat partr.i
# 5 "" 3
b, c, d, e, f;
short g;
a() __attribute__((__const__));
h() {
i:
  for (;;) {
__atomic_load_n(, d);
long j = a(2) && __sync_val_compare_and_swap(, 0, j);
b = 1;
if (h == e)
  break;
  }
  __sync_val_compare_and_swap(, -1, f);
  goto i;
}

$ gcc-9 -c -O1 -Wall partr.i 
: In function ‘h’:
:19:1: error: could not split insn
(insn 51 49 110 (parallel [
(set (reg:CC 66 cc)
(unspec_volatile:CC [
(const_int 0 [0])
] UNSPECV_ATOMIC_CMPSW))
(set (reg:SI 1 x1 [125])
(zero_extend:SI (mem/v:HI (reg/f:DI 27 x27 [132]) [-1  S2
A16])))
(set (mem/v:HI (reg/f:DI 27 x27 [132]) [-1  S2 A16])
(unspec_volatile:HI [
(const_int -1 [0x])
(reg:HI 0 x0 [orig:122 f ] [122])
(const_int 0 [0])
(const_int 32773 [0x8005]) repeated x2
] UNSPECV_ATOMIC_CMPSW))
(clobber (reg:SI 2 x2 [138]))
]) "":17:3 3636 {aarch64_compare_and_swaphi}
 (expr_list:REG_DEAD (reg:HI 0 x0 [orig:122 f ] [122])
(expr_list:REG_UNUSED (reg:CC 66 cc)
(expr_list:REG_UNUSED (reg:SI 2 x2 [138])
(expr_list:REG_UNUSED (reg:SI 1 x1 [125])
(nil))
during RTL pass: final
:19:1: internal compiler error: in final_scan_insn_1, at final.c:3074
Please submit a full bug report,
with preprocessed source if appropriate.


$ gcc-10 -c -O1 -Wall partr.i 
: In function ‘h’:
:19:1: error: could not split insn
(insn 49 47 5 (parallel [
(set (reg:CC 66 cc)
(unspec_volatile:CC [
(const_int 0 [0])
] UNSPECV_ATOMIC_CMPSW))
(set (reg:SI 1 x1 [127])
(zero_extend:SI (mem/v:HI (reg/f:DI 27 x27 [120]) [-1  S2
A16])))
(set (mem/v:HI (reg/f:DI 27 x27 [120]) [-1  S2 A16])
(unspec_volatile:HI [
(const_int -1 [0x])
(reg:HI 0 x0 [orig:124 f ] [124])
(const_int 0 [0])
(const_int 32773 [0x8005]) repeated x2
] UNSPECV_ATOMIC_CMPSW))
(clobber (reg:SI 2 x2 [137]))
]) "":17:3 3908 {aarch64_compare_and_swaphi}
 (expr_list:REG_DEAD (reg:HI 0 x0 [orig:124 f ] [124])
(expr_list:REG_UNUSED (reg:CC 66 cc)
(expr_list:REG_UNUSED (reg:SI 2 x2 [137])
(expr_list:REG_UNUSED (reg:SI 1 x1 [127])
(nil))
during RTL pass: final
:19:1: internal compiler error: in final_scan_insn_1, at final.c:3073
0x60be4f _fatal_insn(char const*, rtx_def const*, char const*, int, char
const*)
../../src/gcc/rtl-error.c:108
0x8380bb final_scan_insn_1
../../src/gcc/final.c:3073
0x8382d3 final_scan_insn(rtx_insn*, _IO_FILE*, int, int, int*)
../../src/gcc/final.c:3152
0x8385a7 final_1
../../src/gcc/final.c:2020
0x838d23 rest_of_handle_final
../../src/gcc/final.c:4658
0x838d23 execute
../../src/gcc/final.c:4736
Please submit a full bug report,
with preprocessed source if appropriate.


this is a compiler with hardening flags enabled by default.

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[romain.geissler at amadeus dot com]

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

--- Comment #28 from Romain Geissler  ---
Hi David,

Do you have plans to submit this patch for review when stage 1 of gcc 11 opens
?

Cheers,
Romain

[Bug preprocessor/94367] pragma GCC diagnostics messes up with one line "if" blocks without curly braces

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 63326.

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

[Bug c/63326] whether a #pragma is a statement depends on the type of pragma

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||romain.geissler at amadeus dot 
com

--- Comment #27 from Andrew Pinski  ---
*** Bug 94367 has been marked as a duplicate of this bug. ***

[Bug preprocessor/94367] pragma GCC diagnostics messes up with one line "if" blocks without curly braces

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
pragma GCC diagnostics
is a full statement.

[Bug preprocessor/94367] New: pragma GCC diagnostics messes up with one line "if" blocks without curly braces

[romain.geissler at amadeus dot com]

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

Bug ID: 94367
   Summary: pragma GCC diagnostics messes up with one line "if"
blocks without curly braces
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: preprocessor
  Assignee: unassigned at gcc dot gnu.org
  Reporter: romain.geissler at amadeus dot com
  Target Milestone: ---

Hi,

It looks like "if" blocks without curly braces cannot be surrounded by pragma
diagnostics. It looks like this is a very old issue, gcc 4.6 already seem to
have this problem on Compiler Explorer. Clang raises no such error.

void f()
{
if (true)
#pragma GCC diagnostic push
;
#pragma GCC diagnostic pop
else
;
}


: In function 'void f()':
:7:5: error: 'else' without a previous 'if'
7 | else
  | ^~~~
Compiler returned: 1
Compiler Explorer uses cookies and other related techs to serve you

[Bug c/94366] New: OpenMP Parallel Reduction with "&&" operator does not compute correct result

[satzeni at nvidia dot com]

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

Bug ID: 94366
   Summary: OpenMP Parallel Reduction with "&&" operator does not
compute correct result
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: satzeni at nvidia dot com
  Target Milestone: ---

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

Consider this program:

#include 
#include 
#include 

static int expect = 1;
static int result;

int main() {
int a = 2;  /* or any another even number */

#pragma omp parallel reduction(&& : a)
{
a = a && 1;
}
result = a ? 1 : 0;
assert(result == 1);
}

Compiler and run with:

$ gcc -fopenmp test.c
$ OMP_NUM_THREADS=2 ./a.out

GCC is not correctly computing the logical-and reduction on variable "a".

Inside the parallel region "a" value is 1, but right after the parallel region
is 0 failing the assertion. The correct result should be 1 as the initial value
is 2 and the logical-and between 2 && 1 should be non zero.

Looking at the assembly code, GCC is using a bitwise “and” instruction to
perform the “&&” operation:

mov(%rbx),%edx
jmp0x400782 
xchg   %ax,%ax
mov%eax,%edx
mov%edx,%ecx
mov%edx,%eax
and$0x1,%ecx
lock cmpxchg %ecx,(%rbx)

However the the value of “a” is not reduced to “1” before it is passed to the
parallel region.

  movl   $0x2,(%rsp)
  callq  0x4005c0 

[Bug analyzer/94365] New: false positive leak when using container_of-like constructs

[npfhrotynz-ptnqh.myvf at noclue dot notk.org]

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

Bug ID: 94365
   Summary: false positive leak when using container_of-like
constructs
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: npfhrotynz-ptnqh.myvf at noclue dot notk.org
  Target Milestone: ---

Created attachment 48136
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48136=edit
test program.c

First, thanks for this awesome feature! I'm not sure how "ready" it is, but
there are other open bugs and I did not see this one, so here goes...


I'm often using patterns where I return a pointer to an inner field of a struct
and then use it with container_of later on.

The attached example program gives two warnings; only the first one is
interesting to me but figured I could cite both since I stumbled on the second
when writing the reproducer...

-
In function ‘foo’:
t.c:22:9: warning: leak of ‘a’ [CWE-401] [-Wanalyzer-malloc-leak]
   22 |  return >b;
  | ^
  ‘foo’: events 1-5
|
|   14 |  struct container *a = malloc(sizeof(*a));
|  |^~
|  ||
|  |(1) allocated here
|..
|   19 |  if (!a)
|  | ~   
|  | |
|  | (2) assuming ‘a’ is non-NULL
|  | (3) following ‘false’ branch (when ‘a’ is non-NULL)...
|..
|   22 |  return >b;
|  | ~   
|  | |
|  | (4) ...to here
|  | (5) ‘a’ leaks here; was allocated at (1)
|

-
In function ‘main’:
t.c:41:2: warning: ‘free’ of ‘’ which points to memory not on the heap
[CWE-590] [-Wanalyzer-free-of-non-heap]
   41 |  free(container_of(b, struct container, b));
  |  ^~
  ‘main’: events 1-2
|
|   29 | int main() {
|  | ^~~~
|  | |
|  | (1) entry to ‘main’
|   30 |  struct a_struct *b = foo();
|  |   ~
|  |   |
|  |   (2) calling ‘foo’ from ‘main’
|
+--> ‘foo’: events 3-5
   |
   |   13 | struct a_struct *foo() {
   |  |  ^~~
   |  |  |
   |  |  (3) entry to ‘foo’
   |..
   |   19 |  if (!a)
   |  | ~ 
   |  | |
   |  | (4) following ‘false’ branch (when ‘a’ is non-NULL)...
   |..
   |   22 |  return >b;
   |  | ~ 
   |  | |
   |  | (5) ...to here
   |
<--+
|
  ‘main’: events 6-10
|
|   30 |  struct a_struct *b = foo();
|  |   ^
|  |   |
|  |   (6) returning to ‘main’ from ‘foo’
|..
|   33 |  if (!b)
|  | ~  
|  | |
|  | (7) following ‘false’ branch (when ‘b’ is non-NULL)...
|..
|   41 |  free(container_of(b, struct container, b));
|  |  ~~
|  |  |
|  |  (8) ...to here
|  |  (9) pointer is from here
|  |  (10) call to ‘free’ here
|
-

I would think that as long as it is programmatically possible to go back to the
allocated pointer (e.g. the return value is a constant offset from malloc
value) then there should be no leak.

Thanks,
-- 
Dominique Martinet

[Bug c/93572] [8/9/10 Regression] internal compiler error: q from h referenced in main

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Somewhat reduced:

void
bar ()
{
  void foo (a) char a;
  int b[ != (char *) 0x4000];
}

[Bug tree-optimization/94364] New: 505.mcf_r is 8% faster when compiled with -mprefer-vector-width=128

[jamborm at gcc dot gnu.org]

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

Bug ID: 94364
   Summary: 505.mcf_r is 8% faster when compiled with
-mprefer-vector-width=128
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

SPEC 2017 INTrate benchmark 505.mcf_r, when compiled with options
-Ofast -march=native -mtune=native, is 8% slower than when we also use
option -mprefer-vector-width=128.  I have observed it on both AMD Zen2
and Intel Cascade Lake Server CPUs (using master revision 26b3e568a60).

Better vector width selection would therefore bring about noticeable
speed-up.


Symbol profiles (collected on AMD Rome):

-Ofast -march=native -mtune=native:

  Overhead   Samples  Shared ObjectSymbol  
      ...  

28.64%462302  mcf_r_peak.mine  spec_qsort
21.58%348703  mcf_r_peak.mine  cost_compare
15.81%255029  mcf_r_peak.mine  primal_bea_mpp
15.58%251176  mcf_r_peak.mine  replace_weaker_arc
 7.37%118646  mcf_r_peak.mine  arc_compare
 6.53%105337  mcf_r_peak.mine  price_out_impl
 1.38% 22276  mcf_r_peak.mine  update_tree

-Ofast -march=native -mtune=native -mprefer-vector-width=128:

  Overhead   Samples  Shared ObjectSymbol  
      ...  

23.57%354536  mcf_r_peak.mine  spec_qsort
23.51%353767  mcf_r_peak.mine  cost_compare
16.98%255104  mcf_r_peak.mine  primal_bea_mpp
16.65%249891  mcf_r_peak.mine  replace_weaker_arc
 7.29%109267  mcf_r_peak.mine  arc_compare
 7.09%106380  mcf_r_peak.mine  price_out_impl
 1.53% 22968  mcf_r_peak.mine  update_tree


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug c/93573] [8/9/10 Regression] internal compiler error: in force_constant_size, at gimplify.c:733

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Created attachment 48135
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48135=edit
gcc10-pr93573.patch

For the error-recovery ICE, we can just make sure that after errors the type
isn't assumed to be VLA.

Unfortunately:
void bar ();

void
foo (char a, int b)
{
  union C { int d[b]; char *e; };
  bar ((union C) );
}

still ICEs.

[Bug c/93573] [8/9/10 Regression] internal compiler error: in force_constant_size, at gimplify.c:733

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Priority|P4  |P2

[Bug other/79469] Feature request: provide `__builtin_assume` builtin function to allow more aggressive optimizations and to match clang

[felix.von.s at posteo dot de]

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

felix  changed:

   What|Removed |Added

 CC||felix.von.s at posteo dot de

--- Comment #1 from felix  ---
> Unfortunately the macro trick is arcane and has one potential issue: the 
> compiler may actually generate code to check `cond` at run-time if it cannot 
> deduce that it's a pure function.

Oh, don't worry; the Other Compiler’s solution isn’t perfect either :)

__builtin_assume(({ for (;;) {}; 1; }));

This emits code for the infinite loop. For a less silly example:

__attribute__((__const__,__always_inline__))
inline static int is_pow2(unsigned j) {
__auto_type i = j;

for (int c = 0; c < CHAR_BIT * sizeof(i); ++c) {
i = (i >> 1) | ((i & 1) << (CHAR_BIT * sizeof(i) - 1));
if (i == 1)
break;
}

return i == 1;
}

int foo(void) {
extern unsigned bar(void);
__auto_type x = bar();

__builtin_assume(is_pow2(x));

return __builtin_popcount(x);
}

This will also emit code for the loop, even though the result is not used at
runtime. The code is not very idiomatic, but I don’t believe it’s wrong either:
the __attribute__((const)) on is_pow2 I consider correct, because the side
effects do not escape the function.

If anyone takes this up, it would be nice if GCC at least did not outright
pessimise such code.

[Bug c/94363] New: possible typo: attribute attribute

[roland.illig at gmx dot de]

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

Bug ID: 94363
   Summary: possible typo: attribute attribute
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

>From cgraphunit.c:
> warning_at (DECL_SOURCE_LOCATION (node->decl), OPT_Wattributes,
> "%"
> " attribute attribute is ignored on aliases");

Either the "attribute attribute" is a typo, or it is a bad word play that I
don't understand. Whatever it is, it should be corrected.

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  ---
it is not mandatory (for C++20 compliance) that the implementation provides
symmetric transfer - so it could be switched off - or XFAILed. 

However, users state that an impl. that can't do the symmetric transfers is not
useful in a number of important applications.

[Bug target/94359] new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[iains at gcc dot gnu.org]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #1 from Iain Sandoe  ---
There are two cases here.

1) When the optimisation level is < 2 (where GCC does not normally tail-call).

 - in that case, the specific call [ which is in the tail position, and AFAIU
should be tail-callable ] is marked as TAIL_CALL, MUST_TAIL_CALL (hence the
complaint error: cannot tail-call: target is not able to optimize the call into
a sibling call, I suppose).

2) for O >= 2 where GCC would normally tail call anyway
 - for this, the coroutine code does not mark the cll specially, so for these
cases it indicates that the tail-call is not being made in "normal"
circumstance.

the function signature is

 void actor (void *)

and the codgen should be emitting an indirect call, followed by a void return 

(the indirect call is expanding __builtin_coro_resume() [expansion happens very
early in the ME].

[Bug tree-optimization/94356] Missed optimisation: useless multiplication generated for pointer comparison

[glisse at gcc dot gnu.org]

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

--- Comment #3 from Marc Glisse  ---
I tried https://gcc.gnu.org/pipermail/gcc-patches/2017-May/475037.html some
time ago. Having a different type for the multiplication and the offsetting
introduced a lot of NOPs and caused a few regressions (from my notes,
pta-ptrarith-3.c and ssa-pre-8.c were just testsuite issues, but there were
others). I filed a bug or 2 about those (PR 88926 at least). Then I tried to
also make the offsets signed, to be consistent, but that's a much bigger piece
and I ran out of time and motivation.

[Bug ipa/94360] 6% run-time regression of 502.gcc_r against GCC 9 when compiled with -O2 and both PGO and LTO

[marxin at gcc dot gnu.org]

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

--- Comment #1 from Martin Liška  ---
Unfortunately, the mentioned configuration is not tested on LNT periodic
benchmarks.

[Bug analyzer/94362] New: False analyzer report due to i >= 0 and i < 0 on openssl

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 94362
   Summary: False analyzer report due to i >= 0 and i < 0 on
openssl
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

Created attachment 48134
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48134=edit
Reduced test case

https://github.com/openssl/openssl/issues/11420 reports what looks like a false
positive:
  crypto/asn1/ameth_lib.c:131:18: error: dereference of NULL 'ameth' [CWE-690]
[-Werror=analyzer-null-dereference]

where on the path to the diagnostic i >= 0 and i < 0, which ought to be
rejected by constraint-checking.

I'm attaching a somewhat simplified reproducer.

[Bug fortran/94361] New: Memory leak in nested types with final

[antony at cosmologist dot info]

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

Bug ID: 94361
   Summary: Memory leak in nested types with final
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antony at cosmologist dot info
  Target Milestone: ---

The code below leaks memory (mem grows with each loop interation), but does not
if the "FINAL" is commented. The issue is also present in trunk (10.0.1
20200218), and may be a reduced test case for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94109 (in which case the problem
was introduced around 8.3.1, but I have not tested versions extensively).


module debug
private

Type TypeWithFinal
contains
FINAL :: finalizer  !No leak if this line is commented
end type

Type Tester
real, dimension(:), allocatable :: Dat
Type(TypeWithFinal) :: X
end Type

Type :: TestType2
Type(Tester) :: T
end type TestType2
public Leaker
contains

subroutine Leaker
type(TestType2) :: Test

allocate(Test%T%Dat(1))
end subroutine

subroutine finalizer(this)
Type(TypeWithFinal) :: this
end subroutine finalizer

end module


program run
use debug
implicit none
integer i

do i=1, 1
call Leaker()
call sleep(1)
end do

end program

[Bug c/93573] [8/9/10 Regression] internal compiler error: in force_constant_size, at gimplify.c:733

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Reduced testcase:
void bar ();

void
foo (char a)
{
  union C { int d[100.0]; char *e; };
  bar ((union C) );
}

[Bug ipa/94360] New: 6% run-time regression of 502.gcc_r against GCC 9 when compiled with -O2 and both PGO and LTO

[jamborm at gcc dot gnu.org]

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

Bug ID: 94360
   Summary: 6% run-time regression of 502.gcc_r against GCC 9 when
compiled with -O2 and both PGO and LTO
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jamborm at gcc dot gnu.org
CC: hubicka at gcc dot gnu.org, marxin at gcc dot gnu.org
Blocks: 26163
  Target Milestone: ---
  Host: x86_64-linux
Target: x86_64-linux

When built at -O2, generic march/mtune and with both PGO and LTO and
current trunk/master, SPEC 2017 INTrate 502.gcc_r is 6% slower when
run on and AMD Zen2-based CPU - and about 4.8% slower on Intel Cascade
Lake.

Looking at how the run-time of the benchmark evolved over the course
of GCC 10 development cycle, the first and biggest regression (9%)
comes with:

  commit 2925cad2151842daa387950e62d989090e47c91d
  Author: Jan Hubicka 
  Date:   Thu Oct 3 17:08:21 2019 +0200

params.def (PARAM_INLINE_HEURISTICS_HINT_PERCENT, [...]): New.

* params.def (PARAM_INLINE_HEURISTICS_HINT_PERCENT,
PARAM_INLINE_HEURISTICS_HINT_PERCENT_O2): New.
* doc/invoke.texi (inline-heuristics-hint-percent,
inline-heuristics-hint-percent-O2): Document.
* tree-inline.c (inline_insns_single, inline_insns_auto): Add new
hint attribute.
(can_inline_edge_by_limits_p): Use it.

   From-SVN: r276516

Then between Wed Nov 6 (72d6aeecd95) and Mon Nov 18 (58c036c8354) it
improved to about 103% of GCC 9 run-time (I did not exactly found what
caused it because in much of this range the compiler was segfaulting
in the LTO phase).  Eventually, the benchmark regresses to current
106% of GCC 9 run-time with Honza's:

  - 9340d34599e Convert inliner to function specific param infrastructure, or
  - 1e83bd7003e Convert inliner to new param infrastructure.

The former cannot be built without the latter.

Symbol profiles are:

trunk (26b3e568a60):
  OverheadSamples  Shared Object Symbol 
    .   


 4.04%  42371  cpugcc_r_peak.pgolto  bitmap_ior_into
 2.91%  30281  cpugcc_r_peak.pgolto  df_worklist_dataflow
 2.24%  23342  cpugcc_r_peak.pgolto  df_note_compute
 1.92%  20120  cpugcc_r_peak.pgolto  bitmap_set_bit
 1.75%  18148  cpugcc_r_peak.pgolto  rest_of_handle_fast_dce.lto_priv.0
 1.58%  16580  libc-2.31.so  __memset_avx2_unaligned_erms
 1.40%  14514  cpugcc_r_peak.pgolto  extract_new_fences_from.lto_priv.0
 1.39%  14732  libc-2.31.so  _int_malloc
 1.33%  13824  cpugcc_r_peak.pgolto  bitmap_copy
 1.24%  12962  cpugcc_r_peak.pgolto  bitmap_bit_p
 1.19%  12346  cpugcc_r_peak.pgolto  bitmap_and
 1.18%  12242  cpugcc_r_peak.pgolto  df_lr_local_compute.lto_priv.0
 1.02%  10618  cpugcc_r_peak.pgolto  cleanup_cfg.isra.0


vs gcc 9 (releases/gcc-9.3.0):


  OverheadSamples  Shared Object Symbol 
    .   
.

 6.81%  66967  cpugcc_r_peak.pgolto  df_worklist_dataflow
 2.83%  28063  cpugcc_r_peak.pgolto  bitmap_ior_into
 2.80%  27489  cpugcc_r_peak.pgolto  df_note_compute.lto_priv.0
 2.17%  21334  cpugcc_r_peak.pgolto  rest_of_handle_fast_dce.lto_priv.0
 1.69%  16671  libc-2.31.so  __memset_avx2_unaligned_erms
 1.51%  14876  cpugcc_r_peak.pgolto  try_optimize_cfg.lto_priv.0
 1.50%  14990  libc-2.31.so  _int_malloc
 1.50%  14715  cpugcc_r_peak.pgolto  extract_new_fences_from.lto_priv.0
 1.36%  13406  cpugcc_r_peak.pgolto  df_lr_local_compute.lto_priv.0
 1.20%  11926  cpugcc_r_peak.pgolto  remove_unused_locals
 1.06%  10433  cpugcc_r_peak.pgolto  sched_analyze_insn
 1.04%  10210  cpugcc_r_peak.pgolto  init_alias_analysis
 1.04%  10188  cpugcc_r_peak.pgolto  prescan_insns_for_dce.lto_priv.0
 1.00%   9876  cpugcc_r_peak.pgolto  compute_transp


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug target/94359] New: new test case g++.dg/coroutines/torture/symmetric-transfer-00-basic.C fails

[seurer at linux dot vnet.ibm.com]

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

Bug ID: 94359
   Summary: new test case
g++.dg/coroutines/torture/symmetric-transfer-00-basic.
C fails
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at linux dot vnet.ibm.com
  Target Milestone: ---

FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O0  (test for
excess errors)
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O1  (test for
excess errors)
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O2  execution
test
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O2 -flto
-fno-use-linker-plugin -flto-partition=none  execution test
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O2 -flto
-fuse-linker-plugin -fno-fat-lto-objects  execution test
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O3
-fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-functions 
execution test
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -O3 -g 
execution test
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C   -Os  execution
test
FAIL: g++.dg/coroutines/torture/symmetric-transfer-00-basic.C (test for excess
errors)

spawn -ignore SIGHUP
/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../xg++
-B/home/seurer/gcc/git/build/gcc-test/gcc/testsuite/g++/../../
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -nostdinc++
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include/powerpc64-unknown-linux-gnu
-I/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/libstdc++-v3/include
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/libsupc++
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/include/backward
-I/home/seurer/gcc/git/gcc-test/libstdc++-v3/testsuite/util -fmessage-length=0
-pedantic-errors -Wno-long-long -std=c++17 -fcoroutines
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libstdc++-v3/src/.libs
-B/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/
-L/home/seurer/gcc/git/build/gcc-test/powerpc64-unknown-linux-gnu/./libitm/.libs
-lm -o ./symmetric-transfer-00-basic.exe
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C:
In function 'void _Z8pingpongPKc.actor(pingpong(const
char*)::_Z8pingpongPKc.frame*)':
/home/seurer/gcc/git/gcc-test/gcc/testsuite/g++.dg/coroutines/torture/symmetric-transfer-00-basic.C:75:1:
error: cannot tail-call: target is not able to optimize the call into a sibling
call
compiler exited with status 1

[Bug middle-end/86715] ICE passing too large argument on stack

[segher at gcc dot gnu.org]

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

Segher Boessenkool  changed:

   What|Removed |Added

 Resolution|--- |WONTFIX
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Segher Boessenkool  ---
"struct Matrix" is over 2GB big.  The whole stack is just a few megabytes
typically.  Passing "struct Matrix" on the stack is entirely unreasonable.

The comment right before this sorry() is
  /* We don't allow passing huge (> 2^30 B) arguments
 by value.  It would cause an overflow later on.  */
and this is in generic code.

Closing as WONTFIX.  Sorry.

[Bug middle-end/93786] [8/9/10 Regression] gimplifier ICE with statement expression since r8-5526

[jakub at gcc dot gnu.org]

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

--- Comment #8 from Jakub Jelinek  ---
Created attachment 48133
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48133=edit
gcc10-pr93786.patch

Untested fix.

[Bug c++/94078] bogus and missing -Wmismatched-tags on an instance of a template

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:04dd734b52de121853e1ea6b3c197a598b294e23

commit r10-7424-g04dd734b52de121853e1ea6b3c197a598b294e23
Author: Martin Sebor 
Date:   Fri Mar 27 12:07:45 2020 -0400

c++: avoid -Wredundant-tags on a first declaration in use [PR 93824]

-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struct S);' and
issues false positives for those.  According to the reported that's
making it harder to use the warning to clean up LibreOffice.

The attached patch extends -Wredundant-tags to avoid these false
positives by relying on the same class_decl_loc_t::class2loc mapping
as -Wmismatched-tags.  The patch also improves the detection
of both issues in template declarations.

gcc/cp/ChangeLog
2020-03-27  Martin Sebor  

PR c++/94078
PR c++/93824
PR c++/93810
* cp-tree.h (most_specialized_partial_spec): Declare.
* parser.c (cp_parser_elaborated_type_specifier): Distinguish alias
from declarations.
(specialization_of): New function.
(cp_parser_check_class_key): Move code...
(class_decl_loc_t::add): ...to here.  Add parameters.  Avoid
issuing
-Wredundant-tags on first-time declarations in other declarators.
Correct handling of template specializations.
(class_decl_loc_t::diag_mismatched_tags): Also expect to be called
when -Wredundant-tags is enabled.  Use primary template or partial
specialization as the guide for uses of implicit instantiations.
* pt.c (most_specialized_partial_spec): Declare extern.

gcc/testsuite/ChangeLog
2020-03-27  Martin Sebor  

PR c++/94078
PR c++/93824
PR c++/93810
* g++.dg/warn/Wmismatched-tags-3.C: New test.
* g++.dg/warn/Wmismatched-tags-4.C: New test.
* g++.dg/warn/Wmismatched-tags-5.C: New test.
* g++.dg/warn/Wmismatched-tags-6.C: New test.
* g++.dg/warn/Wredundant-tags-3.C: Remove xfails.
* g++.dg/warn/Wredundant-tags-6.C: New test.
* g++.dg/warn/Wredundant-tags-7.C: New test.

[Bug c++/93824] bogus -Wredundant-tags on a first declaration in use

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:04dd734b52de121853e1ea6b3c197a598b294e23

commit r10-7424-g04dd734b52de121853e1ea6b3c197a598b294e23
Author: Martin Sebor 
Date:   Fri Mar 27 12:07:45 2020 -0400

c++: avoid -Wredundant-tags on a first declaration in use [PR 93824]

-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struct S);' and
issues false positives for those.  According to the reported that's
making it harder to use the warning to clean up LibreOffice.

The attached patch extends -Wredundant-tags to avoid these false
positives by relying on the same class_decl_loc_t::class2loc mapping
as -Wmismatched-tags.  The patch also improves the detection
of both issues in template declarations.

gcc/cp/ChangeLog
2020-03-27  Martin Sebor  

PR c++/94078
PR c++/93824
PR c++/93810
* cp-tree.h (most_specialized_partial_spec): Declare.
* parser.c (cp_parser_elaborated_type_specifier): Distinguish alias
from declarations.
(specialization_of): New function.
(cp_parser_check_class_key): Move code...
(class_decl_loc_t::add): ...to here.  Add parameters.  Avoid
issuing
-Wredundant-tags on first-time declarations in other declarators.
Correct handling of template specializations.
(class_decl_loc_t::diag_mismatched_tags): Also expect to be called
when -Wredundant-tags is enabled.  Use primary template or partial
specialization as the guide for uses of implicit instantiations.
* pt.c (most_specialized_partial_spec): Declare extern.

gcc/testsuite/ChangeLog
2020-03-27  Martin Sebor  

PR c++/94078
PR c++/93824
PR c++/93810
* g++.dg/warn/Wmismatched-tags-3.C: New test.
* g++.dg/warn/Wmismatched-tags-4.C: New test.
* g++.dg/warn/Wmismatched-tags-5.C: New test.
* g++.dg/warn/Wmismatched-tags-6.C: New test.
* g++.dg/warn/Wredundant-tags-3.C: Remove xfails.
* g++.dg/warn/Wredundant-tags-6.C: New test.
* g++.dg/warn/Wredundant-tags-7.C: New test.

[Bug c++/93810] missing -Wmismatched-tags and -Wredundant-tags on a typedef of an implicit class template specialization

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:04dd734b52de121853e1ea6b3c197a598b294e23

commit r10-7424-g04dd734b52de121853e1ea6b3c197a598b294e23
Author: Martin Sebor 
Date:   Fri Mar 27 12:07:45 2020 -0400

c++: avoid -Wredundant-tags on a first declaration in use [PR 93824]

-Wredundant-tags doesn't consider type declarations that are also
the first uses of the type, such as in 'void f (struct S);' and
issues false positives for those.  According to the reported that's
making it harder to use the warning to clean up LibreOffice.

The attached patch extends -Wredundant-tags to avoid these false
positives by relying on the same class_decl_loc_t::class2loc mapping
as -Wmismatched-tags.  The patch also improves the detection
of both issues in template declarations.

gcc/cp/ChangeLog
2020-03-27  Martin Sebor  

PR c++/94078
PR c++/93824
PR c++/93810
* cp-tree.h (most_specialized_partial_spec): Declare.
* parser.c (cp_parser_elaborated_type_specifier): Distinguish alias
from declarations.
(specialization_of): New function.
(cp_parser_check_class_key): Move code...
(class_decl_loc_t::add): ...to here.  Add parameters.  Avoid
issuing
-Wredundant-tags on first-time declarations in other declarators.
Correct handling of template specializations.
(class_decl_loc_t::diag_mismatched_tags): Also expect to be called
when -Wredundant-tags is enabled.  Use primary template or partial
specialization as the guide for uses of implicit instantiations.
* pt.c (most_specialized_partial_spec): Declare extern.

gcc/testsuite/ChangeLog
2020-03-27  Martin Sebor  

PR c++/94078
PR c++/93824
PR c++/93810
* g++.dg/warn/Wmismatched-tags-3.C: New test.
* g++.dg/warn/Wmismatched-tags-4.C: New test.
* g++.dg/warn/Wmismatched-tags-5.C: New test.
* g++.dg/warn/Wmismatched-tags-6.C: New test.
* g++.dg/warn/Wredundant-tags-3.C: Remove xfails.
* g++.dg/warn/Wredundant-tags-6.C: New test.
* g++.dg/warn/Wredundant-tags-7.C: New test.

[gnu.org #1509189] [wwwdocs] https://www.gnu.org/software/gcc/git.html gives internal server error

[Therese Godefroy via RT]

Hello GCC maintainers,

The same sort of error was reported by Jake Vossen on January 17
(gnu.org #1465799): 

"On the home page of gcc (https://www.gnu.org/software/gcc/) if you
click on 'Git' on the right hand side it takes you to
https://www.gnu.org/software/gcc/git.html, which is giving me an
internal server error."

Thanks in advance for looking into this.

Best regards,
Thérèse

Le Ven 27 Mar 2020 10:26:02, ten...@iseries-guru.com a écrit :
> Hello,
> 
> Around 2020-03-27 1409 GMT, on page "GCC 4.1 Release Series"
> , I clicked link "our 
> version control system" .
> The site presented error page "Internal Server Error", which asks
> me to contact you.
> 
> I you this is helpful.
> 
> Terry.
> 
> 
> 

[Bug analyzer/94350] internal compiler error: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|WAITING |RESOLVED
 Resolution|--- |FIXED

--- Comment #8 from Martin Liška  ---
Fixed with r10-7168-g5c048755ec98645f.

Support More Than 10452 Families All Over Lebanon

[Banin Charity Association]

 Email not displaying correctly? View it in your browser | Share it
 You are seeing this Email in Plain Text Version; Switch to HTML or Click this 
link http://dits.ws/a/44654 to View it properly.

http://www.spx-em.com/url/u8nGvLduh5R6hJJpe5rKzMl6pqrCvMO1tKW7vcfOgLu2sHmFm7e6aXuawsO-tbKumMLDs8CtuMJ5yLq7uLK4kImGgnl9
 

 Subscription Information:
 This email was sent to gcc-bugs@gcc.gnu.org because you are Subscribed to 
Kuwait List
 Click Here to permanently Unsubscribe from this List.

 Sent to you by:
 DIGITAL ITS | Tel: +961 5 464 323

 
 

[Bug analyzer/94350] internal compiler error: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874

[stephen at networkplumber dot org]

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

--- Comment #7 from Stephen Hemminger  ---
Verbose make output shows compiler flags

gcc -Wp,-MD,./.eal_memalloc.o.d.tmp  -m64 -pthread
-I/home/shemminger/DPDK/upstream/lib/librte_eal/linux/eal/include 
-march=native -DRTE_MACHINE_CPUFLAG_SSE -DRTE_MACHINE_CPUFLAG_SSE2
-DRTE_MACHINE_CPUFLAG_SSE3 -DRTE_MACHINE_CPUFLAG_SSSE3
-DRTE_MACHINE_CPUFLAG_SSE4_1 -DRTE_MACHINE_CPUFLAG_SSE4_2
-DRTE_MACHINE_CPUFLAG_AES -DRTE_MACHINE_CPUFLAG_PCLMULQDQ
-DRTE_MACHINE_CPUFLAG_AVX -DRTE_MACHINE_CPUFLAG_RDRAND
-DRTE_MACHINE_CPUFLAG_RDSEED -DRTE_MACHINE_CPUFLAG_FSGSBASE
-DRTE_MACHINE_CPUFLAG_F16C -DRTE_MACHINE_CPUFLAG_AVX2 
-I/home/shemminger/DPDK/upstream/build/include -DRTE_USE_FUNCTION_VERSIONING
-include /home/shemminger/DPDK/upstream/build/include/rte_config.h
-D_GNU_SOURCE -DALLOW_EXPERIMENTAL_API
-I/home/shemminger/DPDK/upstream/lib/librte_eal/linux/eal/include
-I/home/shemminger/DPDK/upstream/lib/librte_eal/common
-I/home/shemminger/DPDK/upstream/lib/librte_eal/common/include -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wmissing-declarations
-Wold-style-definition -Wpointer-arith -Wcast-align -Wnested-externs
-Wcast-qual -Wformat-nonliteral -Wformat-security -Wundef -Wwrite-strings
-Wdeprecated -Werror -Wno-missing-field-initializers -Wimplicit-fallthrough=2
-Wno-format-truncation -Wno-address-of-packed-member -O3   -fanalyzer -o
eal_memalloc.o -c
/home/shemminger/DPDK/upstream/lib/librte_eal/linux/eal/eal_memalloc.c 
during IPA pass: analyzer
cc1: internal compiler error: in make_region_for_unexpected_tree_code, at
analyzer/region-model.cc:4874
Please submit a full bug report,
with preprocessed source if appropriate.

[Bug analyzer/94350] internal compiler error: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874

[stephen at networkplumber dot org]

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

--- Comment #6 from Stephen Hemminger  ---
$ gcc --version
gcc (GCC) 10.0.1 20200311 (Red Hat 10.0.1-0.9)

[Bug fortran/94030] [8/9/10 Regression] ICE equivalence of an integer and an element of an array of size n

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to markeggleston from comment #3)
> A patch from Steve Kargl was sent to the fortran mailing list, (see
> https://gcc.gnu.org/pipermail/fortran/2020-March/054130.html) without
> reference to any PR.
> 
> It appeared to be related to this PR. I have verified the patch and also
> checked it with the test case in the original report.

Techinically, it is related to 

https://stackoverflow.com/questions/60846187/fortran-equivalence-statement-with-array-length-from-subroutine-input

In the stackoverflow thread, someone mentioned this is a regression going back
to at least 6.5.

[Bug analyzer/94350] internal compiler error: in make_region_for_unexpected_tree_code, at analyzer/region-model.cc:4874

[stephen at networkplumber dot org]

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

--- Comment #5 from Stephen Hemminger  ---
Created attachment 48132
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48132=edit
Preprocessed version of source code

[Bug tree-optimization/94356] Missed optimisation: useless multiplication generated for pointer comparison

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Given
struct S { char a[37]; };
int f1 (struct S *s, int a) { struct S *sa = s + a; return s < sa; }
int f2 (struct S *s, int a, int b) { struct S *sa = s + a; return sa < s + b; }
int f3 (struct S *s, int a) { struct S *sa = s + a; return s == sa; }
int f4 (struct S *s, int a, int b) { struct S *sa = s + a; return sa == s + b;
}
f3 is optimized in:
/* X + Y < Y is the same as X < 0 when there is no overflow.  */
...
/* For equality, this is also true with wrapping overflow.  */
...
 (simplify
  (op:c (nop_convert?@3 (pointer_plus@2 (convert1? @0) @1)) (convert2? @0))
  (if (tree_nop_conversion_p (TREE_TYPE (@2), TREE_TYPE (@0))
   && tree_nop_conversion_p (TREE_TYPE (@3), TREE_TYPE (@0))
   && (CONSTANT_CLASS_P (@1) || (single_use (@2) && single_use (@3
   (op @1 { build_zero_cst (TREE_TYPE (@1)); }
f4 is optimized too, but not exactly sure where, partly e.g. in
/* For integral types with wrapping overflow and C odd fold
   x * C EQ/NE y * C into x EQ/NE y.  */
(for cmp (eq ne)
 (simplify
  (cmp (mult @0 INTEGER_CST@1) (mult @2 @1))
  (if (INTEGRAL_TYPE_P (TREE_TYPE (@1))
   && TYPE_OVERFLOW_WRAPS (TREE_TYPE (@0))
   && (TREE_INT_CST_LOW (@1) & 1) != 0)
   (cmp @0 @2
For f1/f2 we likely only optimize the ptr + x < ptr + y into x < y at RTL time,
and in any case, the multiplications are done right now in sizetype which is
unsigned type.

[Bug c++/94257] ICE in inline nested namespace

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #3 from Nathan Sidwell  ---
Fixed 9dba60130dc3ebf7cce8716a36672281688693f7

[Bug c++/94257] ICE in inline nested namespace

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Nathan Sidwell :

https://gcc.gnu.org/g:9dba60130dc3ebf7cce8716a36672281688693f7

commit r10-7423-g9dba60130dc3ebf7cce8716a36672281688693f7
Author: Nathan Sidwell 
Date:   Fri Mar 27 07:54:33 2020 -0700

c++: Fix ICE after ambiguous inline namespace reopen [PR94257]

Following DR2061, 'namespace F', looks for 'F's inside inline namespaces.
That can result in ambiguous lookups that we failed to diagnose early
enough,
leading us to push a new namespace and ICE later.  Diagnose the ambiguity
earlier, and then pick one.

PR c++/94257
* name-lookup.c (push_namespace): Triage ambiguous lookups that
contain namespaces.

[Bug tree-optimization/94329] [8/9/10 Regression] error: use_only.f90: ‘-fcompare-debug’ failure (length)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Created attachment 48131
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48131=edit
gcc10-pr94329.patch

Untested fix.

[Bug tree-optimization/94329] [8/9/10 Regression] error: use_only.f90: ‘-fcompare-debug’ failure (length)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
  Component|debug   |tree-optimization

[Bug tree-optimization/94356] Missed optimisation: useless multiplication generated for pointer comparison

[glisse at gcc dot gnu.org]

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

--- Comment #1 from Marc Glisse  ---
That's because internally we use an unsigned type for offsets (including for
the multiplication). There have been tries to change that...

[Bug fortran/94358] [OMP] Privatize internal array variables introduced by the Fortran FE

[tschwinge at gcc dot gnu.org]

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

--- Comment #1 from Thomas Schwinge  ---
To help with OpenACC 'kernels' support, Gergő later submitted for og8 an
additional change in

"Rework OpenACC Fortran DO loop initialization", and committed:

openacc-gcc-8-branch commit 7c2f3f5c50e029bec704605b065d63273c2425dd
Author: Gergö Barany 
AuthorDate: Mon Jan 21 03:08:57 2019 -0800
Commit: Gergö Barany 
CommitDate: Tue Jan 29 05:21:14 2019 -0800

Rework OpenACC Fortran DO loop initialization

Fortran DO loops on arrays with non-constant bounds (like a(lo:hi))
need
special setup code to compute the bounds and offsets for the iteration.
In
an OpenACC region containing multiple loops, this used to be done in a
block
of code at the start of the region for all of the loops. But the
upcoming
kernels conversion expects this kind of setup code to immediately
precede
the corresponding loop, and variables are not mapped correctly
otherwise.
This patch separates out the initialization part for each loop and
places it
immediately before the loop.

gcc/fortran/
* trans-openmp.c (gfc_privatize_nodesc_array_clauses): Renamed from
gfc_privatize_nodesc_arrays, initialization part factored out to...
(gfc_reinitialize_privatized_arrays): ... this new function,
called...
(gfc_trans_omp_do): ... from here for OpenACC loops.

libgomp/
* testsuite/libgomp.oacc-fortran/initialize_kernels_loops.f90: New
test.

Reviewed-by: Thomas Schwinge 

 gcc/fortran/ChangeLog.openacc   |  7
+++
 gcc/fortran/trans-openmp.c  | 86
++
 libgomp/ChangeLog.openacc   |  4

 libgomp/testsuite/libgomp.oacc-fortran/initialize_kernels_loops.f90 | 36

 4 files changed, 97 insertions(+), 36 deletions(-)

(I did approve that for the og8 development branch, but had not actually
reviewed.)

This patch did not make it into og9 either (obviously, as it depends on the
other one).

Comparing the previous dumps to this "Rework OpenACC Fortran DO loop
initialization" variant (no og8 commits reverted):

In the 'original' dump, we now again see the 'private' clauses disappear (so,
same as in the "baseline" variant) -- yet the re-computation of 'offset.5' as
well as 'D.3818' remaining inside the region, "unprivatized".

In the 'gimple' dump, we then see 'firstprivate(size.6) firstprivate(offset.5)
firstprivate(stride.4) firstprivate(ubound.3) firstprivate(lbound.2)
firstprivate(ubound.1) firstprivate(lbound.0)' appear (supposedly due to
implicit 'firstprivate' inside OpenACC 'parallel'?) -- huh, that doesn't seem
right, given that the point was to avoid all these 'firstprivate' (data
transfers)!  (..., and for OpenACC 'kernels', these would all be implicit
'copy', thus global device data, slow, and prone to race-conditions -- so, much
worse?)

That doesn't seem to make sense, and will need further investigation.  But
let's first concentrate on the "Privatize internal array variables introduced
by the fortran FE" changes alone.

[Bug fortran/94358] [OMP] Privatize internal array variables introduced by the Fortran FE

[tschwinge at gcc dot gnu.org]

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

Thomas Schwinge  changed:

   What|Removed |Added

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

[Bug fortran/94358] New: [OMP] Privatize internal array variables introduced by the Fortran FE

[tschwinge at gcc dot gnu.org]

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

Bug ID: 94358
   Summary: [OMP] Privatize internal array variables introduced by
the Fortran FE
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc, openmp
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: burnus at gcc dot gnu.org, jakub at gcc dot gnu.org
  Target Milestone: ---

This is discussed in context of OpenACC, but I suppose also applies to OpenMP?


Just "a while ago", Cesar submitted for gomp-4_0-branch in
 "[gomp4]
privatize internal array variables introduced by the fortran FE", and
committed:

gomp-4_0-branch, openacc-gcc-7-branch commit
fb7036c540273b8da507dac254f5fcf2033a8fb1
Author: cesar 
AuthorDate: Tue Oct 13 20:17:47 2015 +
Commit: cesar 
CommitDate: Tue Oct 13 20:17:47 2015 +

gcc/fortran/
* trans-array.c (gfc_trans_array_bounds): Add an INIT_VLA
argument
to control whether VLAs should be initialized.  Don't mark this
function as static.
(gfc_trans_auto_array_allocation): Update call to
gfc_trans_array_bounds.
(gfc_trans_g77_array): Likewise.
* trans-array.h: Declare gfc_trans_array_bounds.
* trans-openmp.c (gfc_scan_nodesc_arrays): New function.
(gfc_privatize_nodesc_arrays_1): New function.
(gfc_privatize_nodesc_arrays): New function.
(gfc_init_nodesc_arrays): New function.
(gfc_trans_oacc_construct): Initialize any internal variables
for
arrays without array descriptors inside the offloaded parallel
and
kernels region.
(gfc_trans_oacc_combined_directive): Likewise.

gcc/testsuite/
* gfortran.dg/goacc/default_none.f95: New test.

git-svn-id:
svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@228782
138bc75d-0d04-0410-961f-82ee72b054a4

 gcc/fortran/ChangeLog.gomp   |  18 ++
 gcc/fortran/trans-array.c|  12 +++-
 gcc/fortran/trans-array.h|   2 ++
 gcc/fortran/trans-openmp.c   | 179
---
 gcc/testsuite/ChangeLog.gomp |   4 
 gcc/testsuite/gfortran.dg/goacc/default_none.f95 |  59
+++
 6 files changed, 266 insertions(+), 8 deletions(-)

Later, a bug fix got submitted for gomp-4_0-branch in
 "[gomp4] arrays
inside modules" (but wrong patch file attached), and committed:

gomp-4_0-branch, openacc-gcc-7-branch commit
b9a99e0c7b39ab4b82f5dd148923f03c0dba7aa4
commit b9a99e0c7b39ab4b82f5dd148923f03c0dba7aa4
Author: cesar 
AuthorDate: Wed Jan 13 01:43:16 2016 +
Commit: cesar 
CommitDate: Wed Jan 13 01:43:16 2016 +

gcc/fortran/
* trans-openmp.c (gfc_privatize_nodesc_arrays): Use
gfc_get_symbol_decl instead of accessing backend_decl directly.

gcc/testsuite/
* gfortran.dg/goacc/mod-array.f90: New test.

git-svn-id:
svn+ssh://gcc.gnu.org/svn/gcc/branches/gomp-4_0-branch@232307
138bc75d-0d04-0410-961f-82ee72b054a4

 gcc/fortran/ChangeLog.gomp|  5 +
 gcc/fortran/trans-openmp.c|  2 +-
 gcc/testsuite/ChangeLog.gomp  |  4 
 gcc/testsuite/gfortran.dg/goacc/mod-array.f90 | 23 +++
 4 files changed, 33 insertions(+), 1 deletion(-)

These two got merged in og8:

openacc-gcc-8-branch commit be4fecc76b4166e4af6bd1d9646393830ba28df4
commit be4fecc76b4166e4af6bd1d9646393830ba28df4
Author: Cesar Philippidis 
AuthorDate: Tue Oct 13 20:17:47 2015 +
Commit: Thomas Schwinge 
CommitDate: Wed May 23 08:36:03 2018 +0200

Privatize internal array variables introduced by the fortran FE

gcc/fortran/
* trans-array.c (gfc_trans_array_bounds): Add an INIT_VLA
argument
to control whether VLAs should be initialized.  Don't mark this
function as static.
(gfc_trans_auto_array_allocation): Update call to
gfc_trans_array_bounds.
(gfc_trans_g77_array): Likewise.
* trans-array.h: Declare