[Bug c/98029] [11 Regression] volatile triggers incorrect "warning: right-hand operand of comma expression has no effect [-Wunused-value]" since r11-5188-g32934a4f45a72144

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #4 from Martin Uecker  ---
PATCH https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562465.html

[Bug target/96793] __builtin_floor produces wrong result when rounding direction is FE_DOWNWARD

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #21 from Uroš Bizjak  ---


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

commit r9-9126-gc40b640ebcef1aae78eaca56e04d204dda9e4cad
Author: Uros Bizjak 
Date:   Wed Dec 23 09:09:29 2020 +0100

i386: Fix __builtin_floor with FE_DOWNWARD rounding direction [PR96793]

x86_expand_floorceil expander uses x86_sse_copysign_to_positive, which
is unable to change the sign from - to +.  When FE_DOWNWARD rounding
direction is in effect, the expanded sequence that involves subtraction
can trigger x - x = -0.0 special rule.  x86_sse_copysign_to_positive
fails to change the sign of the intermediate value, assumed to always
be positive, back to positive.

The patch adds one extra fabs that strips the sign from the intermediate
value when flag_rounding_math is in effect.

2020-12-22  Uroš Bizjak  

gcc/
PR target/96793
* config/i386/i386.c (ix86_expand_floorceil):
Remove the sign of the intermediate value for flag_rounding_math.
(ix86_expand_floorceildf_32): Ditto.

gcc/testsuite/
PR target/96793
* gcc.target/i386/pr96793.c: New test.

[Bug target/96793] __builtin_floor produces wrong result when rounding direction is FE_DOWNWARD

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #22 from Uroš Bizjak  ---


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

commit r8-10691-gedb28850520d1137d12a1cc1c0e89c11e6b0c6ef
Author: Uros Bizjak 
Date:   Wed Dec 23 09:18:12 2020 +0100

i386: Fix __builtin_floor with FE_DOWNWARD rounding direction [PR96793]

x86_expand_floorceil expander uses x86_sse_copysign_to_positive, which
is unable to change the sign from - to +.  When FE_DOWNWARD rounding
direction is in effect, the expanded sequence that involves subtraction
can trigger x - x = -0.0 special rule.  x86_sse_copysign_to_positive
fails to change the sign of the intermediate value, assumed to always
be positive, back to positive.

The patch adds one extra fabs that strips the sign from the intermediate
value when flag_rounding_math is in effect.

2020-12-22  Uroš Bizjak  

gcc/
PR target/96793
* config/i386/i386.c (ix86_expand_floorceil):
Remove the sign of the intermediate value for flag_rounding_math.
(ix86_expand_floorceildf_32): Ditto.

gcc/testsuite/
PR target/96793
* gcc.target/i386/pr96793.c: New test.

[Bug target/96793] __builtin_floor produces wrong result when rounding direction is FE_DOWNWARD

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #23 from Uroš Bizjak  ---
Fixed everywhere.

[Bug fortran/93114] Use span passing components of derived types

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

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

--- Comment #3 from Thomas Koenig  ---
Probably a better idea:

If the span can be shown at compile-time to be a multiple of
the size of the component, we need not create the temporaray array
and instead set the strides of the descriptor accordingly.

[Bug bootstrap/98324] [11 Regression] bootstrap broken with a LTO build configured with --enable-default-pie

[doko at debian dot org via Gcc-bugs]

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

--- Comment #4 from Matthias Klose  ---
that's working now.

[Bug libstdc++/79700] std::fabsf and std::fabsl missing from

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

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

--- Comment #6 from Jonathan Wakely  ---
As it says, you can just use std::ceil.

[Bug rtl-optimization/98425] New: Superfluous sign-extend for constrained integer

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

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

Bug ID: 98425
   Summary: Superfluous sign-extend for constrained integer
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: koenigni at gcc dot gnu.org
  Target Milestone: ---

Hello everyone,

A small missed optimization I noticed while toying around with the difference
between signed and unsigned integers. The following code

int
baz(int *p, int i) {
  int j;
  if (i >= 0) {
j = i + 4;
return p[j];
  } else
__builtin_unreachable();
}

is compiled with `gcc -O3 -S` to

baz:
  addl  $4, %esi
  movslq  %esi, %rsi
  movl  (%rdi,%rsi,4), %eax
  ret

The movslq instruction is unnecessary since i is constrained to never be
negative and therefore no sign extension is needed. This probably also prevents
the addl instructions to be removed and the offset being put into the movl. 

For comparison, clang (with the same options) compiles the code to 

baz:
  movl %esi, %eax
  movl 16(%rdi, %rax, 4), %eax
  ret

Optimal would probably be

baz:
  movl 16(%rdi, %rsi, 4), %eax
  ret

[Bug rtl-optimization/98425] Superfluous sign-extend for constrained integer

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ABI

--- Comment #1 from Andrew Pinski  ---
Actually this is an abi issue. The upper 32bits of the register is undefined by
the x86_64 ABI iirc. If this is true then clang has a bug.

[Bug rtl-optimization/98425] Superfluous sign-extend for constrained integer

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

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

--- Comment #2 from Andrew Pinski  ---
Note your optimum code is wrong.
movl %esi, %eax
Is a zero extend.

[Bug rtl-optimization/98425] Superfluous sign-extend for constrained integer

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

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

--- Comment #3 from Jakub Jelinek  ---
Yes, it has been reported to LLVM years ago that they violate the psABI, but
they refused to fix that.

[Bug rtl-optimization/98425] Superfluous sign-extend for constrained integer

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
Sorry, in this case it isn't wrong (that is the passing of char/short case),
the __builtin_unreachable () says that negative values are undefined, therefore
the compiler can use both sign and zero extension interchangeably.
And the undefined signed overflow means when we have:
int i;
...
((unsigned long long) (i + 4)) * 4
we can compute it as
((unsigned long long) (i + 4)) * 4
or
((unsigned long long) i) * 4 + 16
because if i is in [INT_MAX - 3, INT_MAX] it is UB.

[Bug fortran/98426] New: find_symbol in module.c traverses O(N) part of a search tree

[mscfd at gmx dot net via Gcc-bugs]

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

Bug ID: 98426
   Summary: find_symbol in module.c traverses O(N) part of a
search tree
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mscfd at gmx dot net
  Target Milestone: ---

Created attachment 49837
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49837&action=edit
patch

Compilation times of top level modules in a large project I am working on are 
abysmal (up to 30 seconds for modules even with little code in it). Those
modules are using other modules whose mod files are up to 500kB. As far as I
can  see the mod files contain all [including private] symbols from any module
in their use-chain.

I used -pg compiler option to compile gcc itself and ran f951 and gprof with
some modules. gprof showed that about 80% or more of the compilation time is
spent in routine "find_symbol" in module.c.

>From the documentation I can see that argument "gfc_symtree *st" of
"find_symbol" should be a balanced binary search tree, ordered by
gfc_symtree->name. It looks like the tree can have different nodes with the
same name, so traversing the tree to check all nodes of the given name might
require to descend both the left and right subtree.

However, "find_symbol" traverses far more nodes than necessary. (Assuming that
all symbol names are unique, it traverses about half of the tree on average,
making the lookup operation O(N) instead of O(log N).)

The attached patch descends only if it can expect a match in the subtree (and
no match was found so far). This brings down the execution time of find_symbol
to almost nothing, speeding up the compilation time by a factor of about 5-10
for my top level modules (makes a difference if a module compiles in 3 instead
of 30 seconds)!


The patch regtests, and also compiles the large project with its big symbol
trees flawlessly and much faster.

Are there any testcases which check that find_symbol works as expected? If I
change find_symbol to always return NULL, then
make -k check-fortran gives
# of expected passes55911
# of unexpected failures1
# of expected failures  232
# of unsupported tests  81
with just one unexpected failure I could not locate.

In particular if I compile check use_only_1.f90 by hand (added by PR33541,
which added find_symbol), everything seems to work without a proper return
value from find_symbol.

[Bug rtl-optimization/98425] Superfluous sign-extend for constrained integer

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

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

--- Comment #5 from Nicolas Koenig  ---
The advantage of using mov over movs for known-positive integers would be that
32bit moves are also move-eliminated, while movs always has to be executed.

[Bug c++/98419] wrong code when destructor of local variable modifies returned object

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Closing as invalid then.

[Bug c/98047] assignment does not drop qualifier as observed by typeof

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

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

Martin Liška  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #2 from Martin Liška  ---
I think it's fixed now.

[Bug c/98029] [11 Regression] volatile triggers incorrect "warning: right-hand operand of comma expression has no effect [-Wunused-value]" since r11-5188-g32934a4f45a72144

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

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #5 from Martin Liška  ---
I can confirm that.

[Bug c++/98422] C++ 20 module ICE with lto

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

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

Martin Liška  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 CC||marxin at gcc dot gnu.org
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-12-23

[Bug c/97702] comma operator does not drop qualifiers during lvalue conversion

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Uecker  ---
Patch committed - marking resolved fixed.

[Bug c/98260] volatile triggers incorrect warning "set but not used"

[muecker at gwdg dot de via Gcc-bugs]

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

Martin Uecker  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Uecker  ---
Patch committed - marking resolved fixed.

[Bug bootstrap/98318] libcody breaks DragonFly bootstrap

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #9 from Nathan Sidwell  ---
thanks for investigating.  glad you found the cause.  (I regularly build with
-j24 and -j8, so it did surprise me that you found the parallelism to be
signficant).  I'll close this report.

[Bug libgcc/98395] libgcc_s.so.1 almost 10x bigger in gcc-10.2 than gcc-9.2

[john.frankish at outlook dot com via Gcc-bugs]

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

john.frankish at outlook dot com changed:

   What|Removed |Added

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

--- Comment #6 from john.frankish at outlook dot com ---
compiling with -O2 and -Os looks OK - I must have made a mistake somewhere.

[Bug bootstrap/98324] [11 Regression] bootstrap broken with a LTO build configured with --enable-default-pie

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

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

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

https://gcc.gnu.org/g:544f477536010f055c26bc959b18fccf67902750

commit r11-6314-g544f477536010f055c26bc959b18fccf67902750
Author: Nathan Sidwell 
Date:   Wed Dec 23 04:50:00 2020 -0800

c++tools:  Fix PIE  [PR 98324]

This adds --enable-default-pie support to c++tools, so that the sample
server is build -fPIE if requested.

PR bootstrap/98324
c++tools/
* Makefile.in: Add FLAGPIE.
* configure.ac: Add --enable-default-pie support.
* configure: Rebuilt.

[Bug bootstrap/98324] [11 Regression] bootstrap broken with a LTO build configured with --enable-default-pie

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

--- Comment #6 from Nathan Sidwell  ---
Thanks for confirming!

544f4775360 2020-12-23 | c++tools:  Fix PIE  [PR 98324]

[Bug bootstrap/98318] libcody breaks DragonFly bootstrap

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

Rimvydas (RJ)  changed:

   What|Removed |Added

 Resolution|INVALID |FIXED

--- Comment #10 from Rimvydas (RJ)  ---
With commits:
g:6d972f5183d8d476cfb008b85e224aa9b90e628d
g:31705b068fa5d6cbd04aa4ac5f5275bad37d
g:cf22f78ff6ead2b1f022d7e7367daedf459aa355
gcc11 now can successfully bootstrap on DragonFly BSD.
Marking as fixed.

[Bug bootstrap/98318] libcody breaks DragonFly bootstrap

[rimvydas.jas at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Rimvydas (RJ)  ---
Nathan,

there seem to be another issue for 'make check' invoke in top level dir:
configure --enable-bootstrap ...
gmake -j128 && gmake -j1 -k check

gmake[2]: Leaving directory '/zzz/build/trunk/libbacktrace'
gmake[2]: Entering directory '/zzz/build/trunk/libcpp'
gmake[2]: Nothing to be done for 'check'.
gmake[2]: Leaving directory '/zzz/build/trunk/libcpp'
gmake[2]: Entering directory '/zzz/build/trunk/libcody'
No ZSH, maybe flakey
echo '# Automatically generated by Make' >tests/cody.defs
echo 'testdir=/data/gg/libcody/tests' >>tests/cody.defs
echo 'timelimit=60' >>tests/cody.defs
echo 'memlimit=1' >>tests/cody.defs
echo 'cpulimit=60' >>tests/cody.defs
echo 'filelimit=1' >>tests/cody.defs
echo 'SHELL=/bin/sh' >>tests/cody.defs
/zzz/build/trunk/./prev-gcc/xg++ -B/zzz/build/trunk/./prev-gcc/
-B/opt/gcc11f/x86_64-unknown-dragonfly5.9/bin/ -nostdinc++
-B/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/src/.libs
-B/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/libsupc++/.libs

-I/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/include/x86_64-unknown-dragonfly5.9
 -I/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/include 
-I/data/gg/libstdc++-v3/libsupc++
-L/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/src/.libs
-L/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/libsupc++/.libs
-g -O2 -include config.h -I/data/gg/libcody
-I/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/include/x86_64-unknown-dragonfly5.9
-I/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/include
-I/data/gg/libstdc++-v3/libsupc++ \
  -MMD -MP -MF tests/01-serialize/connect.d -c -o tests/01-serialize/connect.o
/data/gg/libcody/tests/01-serialize/connect.cc
/zzz/build/trunk/./prev-gcc/xg++ -B/zzz/build/trunk/./prev-gcc/
-B/opt/gcc11f/x86_64-unknown-dragonfly5.9/bin/ -nostdinc++
-B/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/src/.libs
-B/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/libsupc++/.libs

-I/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/include/x86_64-unknown-dragonfly5.9
 -I/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/include 
-I/data/gg/libstdc++-v3/libsupc++
-L/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/src/.libs
-L/zzz/build/trunk/prev-x86_64-unknown-dragonfly5.9/libstdc++-v3/libsupc++/.libs
-static-libstdc++ -static-libgcc  tests/01-serialize/connect.o -lcody  -o
tests/01-serialize/connect
/usr/libexec/binutils234/elf/ld.gold: error: cannot find -lcody
/data/gg/libcody/cody.hh:288: error: undefined reference to
'Cody::Packet::Destroy()'
/data/gg/libcody/tests/01-serialize/connect.cc:24: error: undefined reference
to 'Cody::Client::~Client()

The make -k check issue in libcody directory is reproducible on Linux box too.

[Bug bootstrap/98318] libcody breaks DragonFly bootstrap

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

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

Nathan Sidwell  changed:

   What|Removed |Added

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

[Bug d/98427] New: d: ICE in assign_temp, at function.c:986

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Bug ID: 98427
   Summary: d: ICE in assign_temp, at function.c:986
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Reduced test:

@trusted memoizeExpr()
{
struct CodepointSet
{
struct CowArray
{
uint *ptr;
}

const CodepointSet binary(U)(U rhs)
{
return rhs;
}

CowArray array;
}

CodepointSet().binary(CodepointSet());
}

[Bug bootstrap/98318] libcody breaks DragonFly bootstrap

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

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

Nathan Sidwell  changed:

   What|Removed |Added

 Status|ASSIGNED|WAITING

--- Comment #12 from Nathan Sidwell  ---
Deleting testsuite:
16929214fd1 2020-12-23 | libcody:  Remove testsuite [PR 98318]

[Bug d/98427] d: ICE in assign_temp, at function.c:986

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

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

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

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

commit r11-6317-gfeb3c40c8ee043cc893410c9985926439292caee
Author: Iain Buclaw 
Date:   Tue Dec 22 09:47:22 2020 +0100

d: Force TYPE_MODE of classes and non-POD structs as BLKmode

Without this being forced, the optimizer could still make decisions that
require objects of the non-POD types to need a temporary, which would
result in an ICE during the expand to RTL passes.

gcc/d/ChangeLog:

PR d/98427
* types.cc (TypeVisitor::visit (TypeStruct *)): Set TYPE_MODE of
all
non-trivial types as BLKmode.
(TypeVisitor::visit (TypeClass *)): Likewise.

gcc/testsuite/ChangeLog:

PR d/98427
* gdc.dg/pr98427.d: New test.

[Bug d/98427] d: ICE in assign_temp, at function.c:986

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Buclaw  ---
Fix committed.

[Bug tree-optimization/98160] [11 Regression] ICE in default_tree_printer at gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f

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

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

Martin Liška  changed:

   What|Removed |Added

   Assignee|msebor at gcc dot gnu.org  |marxin at gcc dot 
gnu.org

--- Comment #9 from Martin Liška  ---
I've just sent a patch for it:
https://gcc.gnu.org/pipermail/gcc-patches/2020-December/562476.html

[Bug target/98428] New: [11 regression] ICE with omp simd loop + optimization

[evan--- via Gcc-bugs]

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

Bug ID: 98428
   Summary: [11 regression] ICE with omp simd loop + optimization
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: e...@coeus-group.com
  Target Milestone: ---

This is based on the gcc-11 currently in Debian experimental (gcc-11 (Debian
11-20201216-2) 11.0.0 20201216 (experimental) [master revision
4e42f6ebf48:da5e758223c:134afa38f0befc49f51747f3afe931fa4707c2f8]), but as
you'll see the build on Compiler Explorer also fails.

I'm getting an ICE when attempting to compile SIMDe on GCC 11 on x86_64 with
-O1.  Here is a minimized test case (or, on Compiler Explorer if you prefer:
):

#include 
typedef struct {
  float d[4];
} f;
typedef __m128 e;
f k;
float ak;
e j;
f fn1(e g) {
  __builtin_memcpy(&k, &g, sizeof(k));
  return k;
}
typedef struct {
  float d[8];
} ag;
void l() {
  ag ao;
  f ap = fn1(j);

#pragma omp simd
  for (size_t i = 0; i < sizeof(ao.d[0]); i += 2)
ao.d[i] = ao.d[i + 1] = ap.d[1];
  ag g = ao;
  __builtin_memcpy(&ak, &g, ak);
}
int main() {}

It generates an ICE with `-O1 -fopenmp-simd`. but removing either -O1 or
-fopenmp-simd makes compilation succeed.  This only happens on gcc-11; gcc-10
works as expected.

The original code which I fed into C-Reduce is at
,
and the `simde_mm512_maskz_broadcast_f64x2` function it calls is at

[Bug c++/98429] New: Some FMA expressions are evaluated less efficiently when -ffast-math is active

[chtz at informatik dot uni-bremen.de via Gcc-bugs]

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

Bug ID: 98429
   Summary: Some FMA expressions are evaluated less efficiently
when -ffast-math is active
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: chtz at informatik dot uni-bremen.de
  Target Milestone: ---

If you compile an expression like

x - x*y

using fast-math optimizations it appears to get re-arranged to 

   x*(1-y)

which is (probably) never more efficient than the original expression,
especially if the target supports FMA operations.

Simple godbolt demonstration: https://godbolt.org/z/4q1oj9

(This is very likely not C++ specific, but I'm not sure what the correct
component is -- I also just tried this for AVX-FMA)

[Bug libstdc++/79700] std::fabsf and std::fabsl missing from

[kip at thevertigo dot com via Gcc-bugs]

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

--- Comment #7 from Kip Warner  ---
Not if I want any certainty at compile time that it is single precision.

[Bug c++/98430] New: C++20 module binary bloat by introducing iostream silently.

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 98430
   Summary: C++20 module binary bloat by introducing iostream
silently.
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

Created attachment 49838
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49838&action=edit
Preprocessed file

OH NO!!! PLEASE. NO IOSTREAM.!! We ban iostream and we do not use it.

g++ -S hello.cc main.cc -Ofast -std=c++20 -s -fmodules-ts

.LFE5373:
.size   _GLOBAL__sub_I_main, .-_GLOBAL__sub_I_main
.section.init_array,"aw"
.align 8
.quad   _GLOBAL__sub_I_main
.globl  _ZTVSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE
.section.rodata
.align 8
.type   _ZTVSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE,
@object
.size   _ZTVSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE,
120
_ZTVSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE:
.quad   0
.quad   _ZTISt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE
.quad  
_ZNSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEED1Ev
.quad  
_ZNSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEED0Ev
.quad  
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE6do_getES3_S3_RSt8ios_baseRSt12_Ios_IostateRb
.quad  
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE6do_getES3_S3_RSt8ios_baseRSt12_Ios_IostateRl
.quad  
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE6do_getES3_S3_RSt8ios_baseRSt12_Ios_IostateRt
.quad  
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE6do_getES3_S3_RSt8ios_baseRSt12_Ios_IostateRj
.quad  
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE6do_getES3_S3_RSt8ios_baseRSt12_Ios_IostateRm
.quad  
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE6do_getES3_S3_RSt8ios_baseRSt12_Ios_IostateRx
.quad  
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE6do_getES3_S3_RSt8ios_baseRSt12_Ios_IostateRy
.quad  
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE6do_getES3_S3_RSt8ios_baseRSt12_Ios_IostateRf
.quad  
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE6do_getES3_S3_RSt8ios_baseRSt12_Ios_IostateRd
.quad  
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE6do_getES3_S3_RSt8ios_baseRSt12_Ios_IostateRe
.quad  
_ZNKSt7num_getIwSt19istreambuf_iteratorIwSt11char_traitsIwEEE6do_getES3_S3_RSt8ios_baseRSt12_Ios_IostateRPv
.globl  _ZTVSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE
.align 8
.type   _ZTVSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE,
@object
.size   _ZTVSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE,
96
_ZTVSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE:
.quad   0
.quad   _ZTISt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE
.quad  
_ZNSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEED1Ev
.quad  
_ZNSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEED0Ev
.quad  
_ZNKSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE6do_putES3_RSt8ios_basewb
.quad  
_ZNKSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE6do_putES3_RSt8ios_basewl
.quad  
_ZNKSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE6do_putES3_RSt8ios_basewm
.quad  
_ZNKSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE6do_putES3_RSt8ios_basewx
.quad  
_ZNKSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE6do_putES3_RSt8ios_basewy
.quad  
_ZNKSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE6do_putES3_RSt8ios_basewd
.quad  
_ZNKSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE6do_putES3_RSt8ios_basewe
.quad  
_ZNKSt7num_putIwSt19ostreambuf_iteratorIwSt11char_traitsIwEEE6do_putES3_RSt8ios_basewPKv
.hidden
_ZTCSt14basic_iostreamIwSt11char_traitsIwEE16_St13basic_ostreamIwS1_E
.globl 
_ZTCSt14basic_iostreamIwSt11char_traitsIwEE16_St13basic_ostreamIwS1_E
.align 8
.type  
_ZTCSt14basic_iostreamIwSt11char_traitsIwEE16_St13basic_ostreamIwS1_E, @object
.size  
_ZTCSt14basic_iostreamIwSt11char_traitsIwEE16_St13basic_ostreamIwS1_E, 80
_ZTCSt14basic_iostreamIwSt11char_traitsIwEE16_St13basic_ostreamIwS1_E:
.quad   8
.quad   0
.quad   _ZTISt13basic_ostreamIwSt11char_traitsIwEE
.quad   0
.quad   0
.quad   -8
.quad   -8
.quad   _ZTISt13basic_ostreamIwSt11char_traitsIwEE
.quad   0
.quad   0
.hidden
_ZTCSt14basic_iostreamIwSt11cha

[Bug c++/98430] C++20 module binary bloat by introducing iostream silently.

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
inline functions should not emit anything.

[Bug fortran/98307] Dependency check fails when using "allocatable" instead of "pointer" (forall_3.f90)

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

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

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

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

commit r9-9127-gea8d2c77e11b7a27d29e2a438536dcd203c206a9
Author: Harald Anlauf 
Date:   Thu Dec 17 10:31:55 2020 +0100

PR fortran/98307 - Dependency check fails when using "allocatable"

The dependency check for FORALL constructs already handled pointer
components to derived types, but missed allocatables.  Fix that.

gcc/fortran/ChangeLog:

PR fortran/98307
* trans-stmt.c (check_forall_dependencies): Extend dependency
check to allocatable components of derived types.

gcc/testsuite/ChangeLog:

PR fortran/98307
* gfortran.dg/forall_19.f90: New test.

(cherry picked from commit c09deceb534b82ce144af3a345dcb06ab5e49ba4)

[Bug fortran/98307] Dependency check fails when using "allocatable" instead of "pointer" (forall_3.f90)

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

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

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

https://gcc.gnu.org/g:75de7b2ace83028afa46bdb9a286d66ce1fa26b8

commit r8-10692-g75de7b2ace83028afa46bdb9a286d66ce1fa26b8
Author: Harald Anlauf 
Date:   Thu Dec 17 10:31:55 2020 +0100

PR fortran/98307 - Dependency check fails when using "allocatable"

The dependency check for FORALL constructs already handled pointer
components to derived types, but missed allocatables.  Fix that.

gcc/fortran/ChangeLog:

PR fortran/98307
* trans-stmt.c (check_forall_dependencies): Extend dependency
check to allocatable components of derived types.

gcc/testsuite/ChangeLog:

PR fortran/98307
* gfortran.dg/forall_19.f90: New test.

(cherry picked from commit c09deceb534b82ce144af3a345dcb06ab5e49ba4)

[Bug fortran/98307] Dependency check fails when using "allocatable" instead of "pointer" (forall_3.f90)

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed on master for gcc-11, and backported to all open branches.  Closing.

Thanks for the report!

[Bug c/98431] New: Gcc crashes with segmentation fault

[Farshid at virginhyperloop dot com via Gcc-bugs]

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

Bug ID: 98431
   Summary: Gcc crashes with segmentation fault
   Product: gcc
   Version: 9.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Farshid at virginhyperloop dot com
  Target Milestone: ---

# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
9.3.0-17ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-9-HskZEa/gcc-9-9.3.0/debian/tmp-nvptx/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04) 


#gcc -save-temps -c -m64 -fwrapv  -O0 -DCLASSIC_INTERFACE=0 -DALLOCATIONFCN=0
-DMAT_FILE=1 -DONESTEPFCN=0 -DTERMFCN=1 -DMULTI_INSTANCE_CODE=0
-DINTEGER_CODE=0 -DMT=0 -DNI_ROOTMODEL_TMS_Build -DTID01EQ=1 -DMODEL=TMS_Build
-DNUMST=4 -DNCSTATES=0 -DHAVESTDIO -DRT -DUSE_RTMODEL  @TMS_Build_comp.rsp
-o"TMS_Build_106165d6_1_ds_dxf.obj"
"../TMS_Build_veristand_rtw/TMS_Build_106165d6_1_ds_dxf.c"
gcc: fatal error: Killed signal terminated program cc1
compilation terminated.

[Bug c/98431] Gcc crashes with segmentation fault

[Farshid at virginhyperloop dot com via Gcc-bugs]

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

--- Comment #1 from Farshid Shadpey  ---
cannot attach the preprocessed file .i since it is too big (14 MB)
Please advise.

[Bug libstdc++/79700] std::fabsf and std::fabsl missing from

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

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

--- Comment #8 from Jonathan Wakely  ---
If you call std::ceil with a float, you get the ceil(float) overload. If you
don't call it with a float, you haven't got subtle precision anyway and calling
ceil didn't change that.

If you need ceilf you can include  and call ceilf.

[Bug libstdc++/79700] std::fabsf and std::fabsl missing from

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

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

--- Comment #9 from Jonathan Wakely  ---
And calling ceilf(x) doesn't give you any certainty of single precision,
because if x is a double then it will still work, but you're now doing a
conversion from double to float.

If you already know x is a float, then std::ceil(x) is single precision. If you
don't know it's a float, using ceilf doesn't change that. The only certainty
you have is x will be converted to float.

[Bug c/98431] Gcc crashes with segmentation fault

[Farshid at virginhyperloop dot com via Gcc-bugs]

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

--- Comment #2 from Farshid Shadpey  ---
Also it is intersting to know that the same file compiles with the following
gcc compiler on Windows:

c:\Farshid\Matlab\Veristand_issue_models\TMS_Repro\TMS_Build_veristand_rtw>"C:\PROGRA~3\MATLAB\SUPPOR~1\R2019b\3P778C~1.INS\MINGW_~1.INS\bin/gcc"
-v
Using built-in specs.
COLLECT_GCC=C:\PROGRA~3\MATLAB\SUPPOR~1\R2019b\3P778C~1.INS\MINGW_~1.INS\bin/gcc
COLLECT_LTO_WRAPPER=C:/PROGRA~3/MATLAB/SUPPOR~1/R2019b/3P778C~1.INS/MINGW_~1.INS/bin/../libexec/gcc/x86_64-w64-mingw32/6.3.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-6.3.0/configure --host=x86_64-w64-mingw32
--build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64
--with-sysroot=/c/mingw630/x86_64-630-posix-seh-rt_v5-rev2/mingw64
--enable-shared --enable-static --disable-multilib
--enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes
--enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto
--enable-graphite --enable-checking=release --enable-fully-dynamic-string
--enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes
--disable-libstdcxx-pch --disable-libstdcxx-debug --disable-bootstrap
--disable-rpath --disable-win32-registry --disable-nls --disable-werror
--disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona
--with-tune=core2 --with-libiconv --with-system-zlib
--with-gmp=/c/mingw630/prerequisites/x86_64-w64-mingw32-static
--with-mpfr=/c/mingw630/prerequisites/x86_64-w64-mingw32-static
--with-mpc=/c/mingw630/prerequisites/x86_64-w64-mingw32-static
--with-isl=/c/mingw630/prerequisites/x86_64-w64-mingw32-static
--with-pkgversion='x86_64-posix-seh-rev2, Built by MinGW-W64 project'
--with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-fno-ident -I/c/mingw630/x86_64-630-posix-seh-rt_v5-rev2/mingw64/opt/include
-I/c/mingw630/prerequisites/x86_64-zlib-static/include
-I/c/mingw630/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2
-pipe -fno-ident
-I/c/mingw630/x86_64-630-posix-seh-rt_v5-rev2/mingw64/opt/include
-I/c/mingw630/prerequisites/x86_64-zlib-static/include
-I/c/mingw630/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS='
-I/c/mingw630/x86_64-630-posix-seh-rt_v5-rev2/mingw64/opt/include
-I/c/mingw630/prerequisites/x86_64-zlib-static/include
-I/c/mingw630/prerequisites/x86_64-w64-mingw32-static/include' LDFLAGS='-pipe
-fno-ident -L/c/mingw630/x86_64-630-posix-seh-rt_v5-rev2/mingw64/opt/lib
-L/c/mingw630/prerequisites/x86_64-zlib-static/lib
-L/c/mingw630/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 6.3.0 (x86_64-posix-seh-rev2, Built by MinGW-W64 project)

[Bug c++/98432] New: [coroutine] leaked frame created using await_transform

[hering.t at seznam dot cz via Gcc-bugs]

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

Bug ID: 98432
   Summary: [coroutine] leaked frame created using await_transform
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hering.t at seznam dot cz
  Target Milestone: ---

I think I encounter a memory leak caused by implementation when using
await_transform to turn arbitrary type into awaitable. I track the number of
(internally) allocated coroutine frames and expect to see zero as the final
figure, one remains unfreed however.

cmd line: g++.exe gcc_coro_leak.cpp -std=c++20 -O3 -Wall -Wextra -fcoroutines

Platforms tested: avr, x86

Compilation output: 
returned: 0

Execution output:
allocating frame, total count:
1
allocating frame, total count:
2
hello coro-world
deleting frame, remaining count:
1

Program returned: 0

[Bug c++/98432] [coroutine] leaked frame created using await_transform

[hering.t at seznam dot cz via Gcc-bugs]

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

--- Comment #1 from Tomáš Hering  ---
Created attachment 49839
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49839&action=edit
preprocessed file that triggers the bug

[Bug fortran/93340] [8/9/10/11 Regression] ICE in check_constant_initializer, at fortran/trans-decl.c:5450

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #5 from anlauf at gcc dot gnu.org ---
There is also a related missed simplification of substrings.
The dump-tree of

subroutine p
  call foo ('abcd'(1:1))
end

is:

void p ()
{
  foo (&"abcd"[1]{lb: 1 sz: 1}, 1);
}


I'd expect:

void p ()
{
  foo (&"a"[1]{lb: 1 sz: 1}, 1);
}

which we get for

  call foo ('a'(1:1))

or

  call foo ('a')

[Bug c++/98332] [10/11 Regression] ICE in unshare_constructor, at cp/constexpr.c:1527 since r6-7607-g52228180f1e50cbb

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

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

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

https://gcc.gnu.org/g:6b7d53a25933f4aed71d6d5134e971bd995f8973

commit r11-6320-g6b7d53a25933f4aed71d6d5134e971bd995f8973
Author: Jason Merrill 
Date:   Tue Dec 22 16:40:37 2020 -0500

c++: Fix constexpr array ICE [PR98332]

The element initializer was non-constant, so its CONSTRUCTOR element ended
up NULL, so unshare_constructor crashed trying to look at it.  This patch
fixes this in two places: First, by returning when we see a non-constant
initializer; second, by not crashing on NULL.

gcc/cp/ChangeLog:

PR c++/98332
* constexpr.c (unshare_constructor): Check for NULL.
(cxx_eval_vec_init_1): Always exit early if non-constant.

gcc/testsuite/ChangeLog:

PR c++/98332
* g++.dg/cpp0x/constexpr-overflow3.C: New test.

[Bug c++/98353] [8/9/10 Regression] ICE in propagate_necessity, at tree-ssa-dce.c:1053 since r6-4886-gcda0a029f45d20f4

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

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

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

https://gcc.gnu.org/g:550880a31688f1031a21efe7923c86db423cbbf1

commit r11-6321-g550880a31688f1031a21efe7923c86db423cbbf1
Author: Jakub Jelinek 
Date:   Wed Dec 23 22:45:56 2020 +0100

c++: Fix up floating point complex handling in build_zero_init_1 [PR98353]

While the gimplifier patch I've just committed fixed an ICE, in some cases
like on the committed testcase cp folding doesn't happen after
build_zero_init_1 because it is called already during gimplification.

For the scalar types, if we want to use convert, the problem with complex
floats
is that it returns a COMPLEX_EXPR with FLOAT_EXPR arguments which have
INTEGER_CST 0 as argument.  As fold isn't recursive, it doesn't do anything
in that case, we need to first fold those FLOAT_EXPRs to REAL_CST 0.0 and
only afterwards the COMPLEX_EXPR can be folded into COMPLEX_CST with 0.0
arguments.

This patch instead just uses build_zero_cst that creates the zero constant
for
any scalar types (and more) directly, instead of going through multiple
hops.

2020-12-23  Jakub Jelinek  

PR c++/98353
* init.c (build_zero_init_1): Use build_zero_cst for SCALAR_TYPE_P
zero initializers.

[Bug libstdc++/79700] std::fabsf and std::fabsl missing from

[kip at thevertigo dot com via Gcc-bugs]

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

--- Comment #10 from Kip Warner  ---
Thanks Jonathan, but I disagree. The point is that the caller might be wrong in
any number of assumptions. The library designers were in agreement, hence why
there is an explicit ceilf function.

[Bug c++/97597] [11 Regression] ICE in build_over_call, at cp/call.c:9034

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

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

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

https://gcc.gnu.org/g:612cf351c700b6216209e3f3f4b3a0959bf2dee7

commit r11-6324-g612cf351c700b6216209e3f3f4b3a0959bf2dee7
Author: Jason Merrill 
Date:   Tue Dec 22 15:41:56 2020 -0500

c++: Fix initializing empty base from prvalue [PR97597]

unsafe_return_slot_p wasn't recognizing an empty base as
potentially-overlapping, which it definitely is.

The change to build_base_path is to make the virtual conversion also
recognized by is_empty_base_ref; unsafe_return_slot_p doesn't to handle
virtual conversions, but hypothetical future callers might.

gcc/cp/ChangeLog:

PR c++/97597
* class.c (is_empty_base_ref): New.
(build_base_path): Add NOP_EXPR after offset.
* cp-tree.h (is_empty_base_ref): Declare it.
* call.c (unsafe_return_slot_p): Call it.

gcc/testsuite/ChangeLog:

PR c++/97597
* g++.dg/init/empty3.C: New test.

[Bug c++/90254] [8/9/10 Regression] ice on aggregate initialization of unmovable base

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

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

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

https://gcc.gnu.org/g:97014e4ada448aa8978b3cd14ed95e0e56f375d9

commit r10-9168-g97014e4ada448aa8978b3cd14ed95e0e56f375d9
Author: Jason Merrill 
Date:   Wed Aug 12 05:45:02 2020 -0400

c++: Copy elision and [[no_unique_address]]. [PR93711]

We don't elide a copy from a function returning a class by value into a
base
because that can overwrite data laid out in the tail padding of the base
class; we need to handle [[no_unique_address]] fields the same way, or we
ICE when the middle-end wants to create a temporary object of a
TYPE_NEEDS_CONSTRUCTING type.

This means that we can't always express initialization of a field with
INIT_EXPR from a TARGET_EXPR the way we usually do, so I needed
to change several places that were assuming that was sufficient.

This also fixes 90254, the same problem with C++17 aggregate initialization
of a base.

gcc/cp/ChangeLog:

PR c++/90254
PR c++/93711
* cp-tree.h (unsafe_return_slot_p): Declare.
* call.c (is_base_field_ref): Rename to unsafe_return_slot_p.
(build_over_call): Check unsafe_return_slot_p.
(build_special_member_call): Likewise.
* init.c (expand_default_init): Likewise.
* typeck2.c (split_nonconstant_init_1): Likewise.

gcc/testsuite/ChangeLog:

PR c++/90254
PR c++/93711
* g++.dg/cpp1z/aggr-base10.C: New test.
* g++.dg/cpp2a/no_unique_address7.C: New test.
* g++.dg/cpp2a/no_unique_address7a.C: New test.

[Bug c++/93711] [9/10 Regression] ICE: [[no_unique_address] when constructing via template helper

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:97014e4ada448aa8978b3cd14ed95e0e56f375d9

commit r10-9168-g97014e4ada448aa8978b3cd14ed95e0e56f375d9
Author: Jason Merrill 
Date:   Wed Aug 12 05:45:02 2020 -0400

c++: Copy elision and [[no_unique_address]]. [PR93711]

We don't elide a copy from a function returning a class by value into a
base
because that can overwrite data laid out in the tail padding of the base
class; we need to handle [[no_unique_address]] fields the same way, or we
ICE when the middle-end wants to create a temporary object of a
TYPE_NEEDS_CONSTRUCTING type.

This means that we can't always express initialization of a field with
INIT_EXPR from a TARGET_EXPR the way we usually do, so I needed
to change several places that were assuming that was sufficient.

This also fixes 90254, the same problem with C++17 aggregate initialization
of a base.

gcc/cp/ChangeLog:

PR c++/90254
PR c++/93711
* cp-tree.h (unsafe_return_slot_p): Declare.
* call.c (is_base_field_ref): Rename to unsafe_return_slot_p.
(build_over_call): Check unsafe_return_slot_p.
(build_special_member_call): Likewise.
* init.c (expand_default_init): Likewise.
* typeck2.c (split_nonconstant_init_1): Likewise.

gcc/testsuite/ChangeLog:

PR c++/90254
PR c++/93711
* g++.dg/cpp1z/aggr-base10.C: New test.
* g++.dg/cpp2a/no_unique_address7.C: New test.
* g++.dg/cpp2a/no_unique_address7a.C: New test.

[Bug c++/98332] [10/11 Regression] ICE in unshare_constructor, at cp/constexpr.c:1527 since r6-7607-g52228180f1e50cbb

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

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

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

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

commit r10-9169-gf5cea9c5c4f8cce36963973e432a8575ef9ffd63
Author: Jason Merrill 
Date:   Tue Dec 22 16:40:37 2020 -0500

c++: Fix constexpr array ICE [PR98332]

The element initializer was non-constant, so its CONSTRUCTOR element ended
up NULL, so unshare_constructor crashed trying to look at it.  This patch
fixes this in two places: First, by returning when we see a non-constant
initializer; second, by not crashing on NULL.

gcc/cp/ChangeLog:

PR c++/98332
* constexpr.c (unshare_constructor): Check for NULL.
(cxx_eval_vec_init_1): Always exit early if non-constant.

gcc/testsuite/ChangeLog:

PR c++/98332
* g++.dg/cpp0x/constexpr-overflow3.C: New test.

[Bug fortran/98433] New: double free detected in tcache 2, after merge of structures

[guez at lmd dot ens.fr via Gcc-bugs]

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

Bug ID: 98433
   Summary: double free detected in tcache 2, after merge of
structures
   Product: gcc
   Version: 10.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guez at lmd dot ens.fr
  Target Milestone: ---

This is the output of `gcc -v` on my machine:

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper
OFFLOAD_TARGET_NAMES=nvptx-none:hsa
OFFLOAD_TARGET_DEFAULT=1
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
9.3.0-17ubuntu1~20.04' --with-bugurl=file:///usr/share/doc/gcc-9/README.Bugs
--enable-languages=c,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-9
--program-prefix=x86_64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --with-default-libstdcxx-abi=new
--enable-gnu-unique-object --disable-vtable-verify --enable-plugin
--enable-default-pie --with-system-zlib --with-target-system-zlib=auto
--enable-objc-gc=auto --enable-multiarch --disable-werror --with-arch-32=i686
--with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib
--with-tune=generic
--enable-offload-targets=nvptx-none=/build/gcc-9-HskZEa/gcc-9-9.3.0/debian/tmp-nvptx/usr,hsa
--without-cuda-driver --enable-checking=release --build=x86_64-linux-gnu
--host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04)

Here is a test program for the bug:

$ cat test_bug_merge.f90
module bug_merge_m
  implicit none
contains
  subroutine bug_merge
type t
   real, allocatable:: v(:)
end type t

type(t) x1, x2, x3

allocate(x1%v(1))
x1%v = 1.
allocate(x2%v(1))
x2%v = 2.
x3 = merge(x1, x2, .false.)
print *, "x3%v = ", x3%v
  end subroutine bug_merge
end module bug_merge_m

program test_bug_merge
  use bug_merge_m, only: bug_merge
  implicit none
  call bug_merge
end program test_bug_merge

And here is the result of compilation and execution:

$ gfortran test_bug_merge.f90

$ a.out
 x3%v =2.
free(): double free detected in tcache 2

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
#0  0x146659050d3a
#1  0x14665904fed5
#2  0x146658e7e20f
#3  0x146658e7e18b
#4  0x146658e5d858
#5  0x146658ec83ed
#6  0x146658ed047b
#7  0x146658ed20ec
#8  0x55a871b8756c
#9  0x55a871b8759c
#10  0x55a871b875d5
#11  0x146658e5f0b2
#12  0x55a871b8711d
#13  0x
Aborted (core dumped)

I think there is nothing wrong in the program. x1 and x2 are well defined. The
error disappears if I replace the merge line with a simple x3 = x2. The error
also disappears if I inline the content of the subroutine in the main program
unit. Also, the program works with the Intel compiler.

[Bug c++/96045] [11 Regression] Wrong line and column diagnostic message in a class template instantiation

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

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

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

https://gcc.gnu.org/g:745f22096c3a2a5e63d5bab1fb079e2c437cf9bc

commit r11-6325-g745f22096c3a2a5e63d5bab1fb079e2c437cf9bc
Author: Nathan Sidwell 
Date:   Wed Dec 23 14:17:17 2020 -0800

c++: EOF location [PR 96045]

Setting the EOF token location to be the start of a line just after
the ending newline is not most helpful.  While that location is
probably the right place to report preprocessing and lexing issues,
when parsing, the location just after the last token is better.  That
way we get to point at some actual text.  Setting the location from
the previous token has the advantage over just setting the location to
be the end of the final line, in that any ending comments do not get
considered, which I think is better.

PR c++/96045
gcc/cp/
* parser.c (cp_lexer_new_main): Adjust EOF token location.
gcc/testsuite/
* g++.dg/diagnostic/pr96045-1.C: New.
* g++.dg/diagnostic/pr96045-2.C: New.
* g++.dg/diagnostic/pr96045-3.C: New.
* c-c++-common/goacc/pr79428-1.c: Adjust EOF diagnostic location.
* c-c++-common/gomp/pr79428-2.c: Likewise
* c-c++-common/raw-string-6.c: Likewise
* g++.dg/cpp0x/decltype63.C: Likewise
* g++.dg/cpp0x/gen-attrs-64.C: Likewise
* g++.dg/cpp0x/pr68726.C: Likewise
* g++.dg/cpp0x/pr78341.C: Likewise
* g++.dg/cpp1y/pr65202.C: Likewise
* g++.dg/cpp1y/pr65340.C: Likewise
* g++.dg/cpp1y/pr68578.C: Likewise
* g++.dg/cpp1z/class-deduction44.C: Likewise
* g++.dg/diagnostic/unclosed-extern-c.C: Likewise
* g++.dg/diagnostic/unclosed-function.C: Likewise
* g++.dg/diagnostic/unclosed-namespace.C: Likewise
* g++.dg/diagnostic/unclosed-struct.C: Likewise
* g++.dg/ext/pr84598.C: Likewise
* g++.dg/other/switch4.C: Likewise
* g++.dg/parse/attr4.C: Likewise
* g++.dg/parse/cond4.C: Likewise
* g++.dg/parse/crash10.C: Likewise
* g++.dg/parse/crash18.C: Likewise
* g++.dg/parse/crash27.C: Likewise
* g++.dg/parse/crash34.C: Likewise
* g++.dg/parse/crash35.C: Likewise
* g++.dg/parse/crash52.C: Likewise
* g++.dg/parse/crash59.C: Likewise
* g++.dg/parse/crash61.C: Likewise
* g++.dg/parse/crash67.C: Likewise
* g++.dg/parse/error14.C: Likewise
* g++.dg/parse/error56.C: Likewise
* g++.dg/parse/invalid1.C: Likewise
* g++.dg/parse/parameter-declaration-1.C: Likewise
* g++.dg/parse/parser-pr28152-2.C: Likewise
* g++.dg/parse/parser-pr28152.C: Likewise
* g++.dg/parse/pr68722.C: Likewise
* g++.dg/parse/pr96258.C: Likewise
* g++.dg/pr46852.C: Likewise
* g++.dg/pr46868.C: Likewise
* g++.dg/template/crash115.C: Likewise
* g++.dg/template/crash43.C: Likewise
* g++.dg/template/crash90.C: Likewise
* g++.dg/template/error-recovery1.C: Likewise
* g++.dg/template/error57.C: Likewise
* g++.old-deja/g++.other/crash31.C: Likewise

[Bug fortran/98433] double free detected in tcache 2, after merge of structures

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   Priority|P3  |P4

--- Comment #1 from kargl at gcc dot gnu.org ---

The issue goes away if you replace this line:

x3 = merge(x1, x2, .false.)

with the likely correct line

x3%v = merge(x1%v, x2%v, .false.)

[Bug libstdc++/79700] std::fabsf and std::fabsl missing from

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

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

--- Comment #11 from Jonathan Wakely  ---
Nope, ceilf comes from C, which has no overloading.

C++ doesn't need separate names for ceil, ceilf and ceill, so you just have
std::ceil.

The fact std::ceilf exists at all is just for consistency with C, not because
"the library designers" considered it important. That's why it wasn't even
mentioned in C++98, C++03, C++11, or C++14.

We will add all the functions listed above in this bug, because they're meant
to be there, but they are not essential. You can use std::ceil((float)x) or
::ceilf(x) as a workaround with identical semantics.

[Bug libstdc++/79700] std::fabsf and std::fabsl missing from

[kip at thevertigo dot com via Gcc-bugs]

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

--- Comment #12 from Kip Warner  ---
I didn't say STL. I said library designers which includes the standard C
runtime. And no, I don't agree with you. Separate names are helpful for greater
certainty. As for std::ceilf existing just for consistency with C, that's
speculative and, in my view doubtful.

[Bug fortran/98433] double free detected in tcache 2, after merge of structures

[guez at lmd dot ens.fr via Gcc-bugs]

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

--- Comment #2 from Lionel GUEZ  ---
Sure, the issue goes away if you specify the components.

When you say "the likely correct line", do you imply that the line without the
components is incorrect? I would insist that the line without the components is
correct. See for example Adams, Fortran 2003 Handbook, 2009, section 7.5.2:
"Derived-type intrinsic assignment is performed as if the assignment were
expanded, component-by-component with corresponding elements from the variable
and the expression, into separate assignment statements. [...] If the component
is allocatable:
a. if it is allocated, it is deallocated.
b. if the corresponding component of the expression is allocated, the variable
component is allocated with the same dynamic type and type parameters and,
if it is an array, with the same bounds. [...]"

gfortran usually implements this well, as we can see when we replace the merge
with a simple x3 = x2. But there is something wrong here in gfortran when it
encounters the combination of derived-type assignment, merge function, and
being in a subroutine.

Since the line without the components is valid, the crash is a bug. (I might
add that, of course, I produced the simplest possible test case but, in my
original program, the allocatable component in the derived type is only one of
several components and so, it is not an equivalently satisfying code to
manually assign all components one by one.)

[Bug c++/98413] [11 Regression] ICE with placement new since r11-3827-g83685efd5fd1623c

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

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

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

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

commit r11-6328-gfdd8560cce9f10fe5dcd26483440be136b81701d
Author: Martin Sebor 
Date:   Wed Dec 23 16:28:06 2020 -0700

PR c++/98413 - ICE on placement new and member pointer

gcc/ChangeLog:

PR c++/98413
* builtins.c (get_offset_range): Avoid non-integers/-pointers.

gcc/testsuite/ChangeLog:

PR c++/98413
* g++.dg/warn/pr98413.C: New test.

[Bug tree-optimization/98160] [11 Regression] ICE in default_tree_printer at gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f

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

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

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

https://gcc.gnu.org/g:0df311657dc8c2a7f6ce3464c9d9ae5d5033840c

commit r11-6329-g0df311657dc8c2a7f6ce3464c9d9ae5d5033840c
Author: Martin Sebor 
Date:   Wed Dec 23 16:34:12 2020 -0700

PR middle-end/98160 - ICE in warn_dealloc_offset on member placement new
and delete

gcc/ChangeLog:

PR middle-end/98160
* builtins.c (warn_dealloc_offset): Avoid assuming calls are made
through declared functions and not pointers.

gcc/testsuite/ChangeLog:

PR middle-end/98160
* g++.dg/warn/pr98160.C: New test.

[Bug tree-optimization/98160] [11 Regression] ICE in default_tree_printer at gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f

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

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

Martin Sebor  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|REOPENED|RESOLVED

--- Comment #11 from Martin Sebor  ---
It should be fixed now for real.

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

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

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

Bug 98160 Summary: [11 Regression] ICE in default_tree_printer at 
gcc/tree-diagnostic.c:270 since r11-5732-gdce6c58db87ebf7f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98160

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

[Bug c++/98413] [11 Regression] ICE on placement new and member pointer

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

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

Martin Sebor  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
Summary|[11 Regression] ICE with|[11 Regression] ICE on
   |placement new since |placement new and member
   |r11-3827-g83685efd5fd1623c  |pointer
 Resolution|--- |FIXED

--- Comment #4 from Martin Sebor  ---
Fixed in r11-6328.

[Bug libstdc++/79700] std::fabsf and std::fabsl missing from

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

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

--- Comment #13 from Jonathan Wakely  ---
(In reply to Kip Warner from comment #12)
> I didn't say STL. I said library designers which includes the standard C
> runtime.

Why a particular name is used by C is not relevant to C++. The function is in
C++ because it was inherited from C99, with no discussion or consideration
about suitability for the C++ library.

> And no, I don't agree with you. Separate names are helpful for
> greater certainty. As for std::ceilf existing just for consistency with C,
> that's speculative and, in my view doubtful.

It's not speculative. I am certain that ceilf was never once mentioned in a
WG21 proposal (or minutes of WG21 meetings) until https://wg21.link/p0175
proposed explicitly naming it in the C++ standard for consistency with the
contents of  in C99.

It had previously been mentioned in https://wg21.link/lwg289 which concluded
that ceilf etc were *not* part of the C++ standard (which meant C++98 at the
time). There was no subsequent design decision to explicitly add it to C++, it
was brought it when C++ rebased its library on the C99 library. In other words,
for consistency with C.

Your time would be better spent submitting a patch to add it to libstdc++
rather than trying to convince me of its history in the C++ library.

[Bug fortran/98433] double free detected in tcache 2, after merge of structures

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #3 from Steve Kargl  ---
On Wed, Dec 23, 2020 at 11:29:47PM +, guez at lmd dot ens.fr wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98433
> 
> --- Comment #2 from Lionel GUEZ  ---
> Sure, the issue goes away if you specify the components.
> 
> When you say "the likely correct line", do you imply that the line without the
> components is incorrect?

Likely, as in I need to check the Fortran standard for
the correct behavior.

> I would insist that the line without the components is
> correct. See for example Adams, Fortran 2003 Handbook, 2009, section 7.5.2:

Don't own that book.  In fact, I own no books that cover 
anything beyond Fortran 95.

[Bug libstdc++/79700] std::fabsf and std::fabsl missing from

[kip at thevertigo dot com via Gcc-bugs]

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

--- Comment #14 from Kip Warner  ---
Thanks Jonathan, but I still think you are mistaken in that you don't
understand why the function exists in its various forms. Your explanation is
technical and not philosophical.

Whether it was originally inherited from the standard C library or was a
creature of a C++ WG committee isn't material. And yes, you are being
speculative. 

We can discuss another day the history, design choices, and rationale behind
how floating point calculations have been done. In any event, we are going
around in circles.

But the important thing is that this is thankfully being patched.

[Bug c/98431] Gcc crashes with segmentation fault

[Farshid at virginhyperloop dot com via Gcc-bugs]

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

--- Comment #3 from Farshid Shadpey  ---
Sorry i appended a wrong output from a machine without enough ram. The correct
report with segmentation fault is:

# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-nilrt-linux/7.3.0/lto-wrapper
Target: x86_64-nilrt-linux
Configured with: ../../../../../../work-shared/gcc-7.3.0-r0/gcc-7.3.0/configure
--build=x86_64-linux --host=x86_64-nilrt-linux --target=x86_64-nilrt-linux
--prefix=/usr --exec_prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin
--libexecdir=/usr/libexec --datadir=/usr/share --sysconfdir=/etc
--sharedstatedir=/com --localstatedir=/var --libdir=/usr/lib
--includedir=/usr/include --oldincludedir=/usr/include
--infodir=/usr/share/info --mandir=/usr/share/man --disable-silent-rules
--disable-dependency-tracking
--with-libtool-sysroot=/srv/jenkins/perforce/ThirdPartyExports/NIOpenEmbedded/trunk/8.5/objects/build.x64/tmp-glibc/work/core2-64-nilrt-linux/gcc/7.3.0-r0/recipe-sysroot
--with-gnu-ld --enable-shared --enable-languages=c,c++ --enable-threads=posix
--enable-multilib --enable-c99 --enable-long-long --enable-symvers=gnu
--enable-libstdcxx-pch --program-prefix=x86_64-nilrt-linux-
--without-local-prefix --enable-lto --enable-libssp --enable-libitm
--disable-bootstrap --disable-libmudflap --with-system-zlib
--with-linker-hash-style=gnu --enable-linker-build-id --with-ppl=no
--with-cloog=no --enable-checking=release --enable-cheaders=c_global
--without-isl --with-sysroot=/
--with-build-sysroot=/srv/jenkins/perforce/ThirdPartyExports/NIOpenEmbedded/trunk/8.5/objects/build.x64/tmp-glibc/work/core2-64-nilrt-linux/gcc/7.3.0-r0/recipe-sysroot
--with-gxx-include-dir=/usr/include/c++/7.3.0 --without-long-double-128
--enable-nls --enable-initfini-array --enable-__cxa_atexit
Thread model: posix
gcc version 7.3.0 (GCC)

# gcc   -c -m64 -fPIC -fdollars-in-identifiers -DkNIOSLinux  -O0
-DCLASSIC_INTERFACE=1 -DALLOCATIONFCN=0 -DMAT_FILE=1 -DONESTEPFCN=0 -DTERMFCN=1
-DMULTI_INSTANCE_CODE=0 -DINTEGER_CODE=0 -DMT=0 -DNI_ROOTMODEL_TMS_Build
-DTID01EQ=1 -DMODEL=TMS_Build -DNUMST=4 -DNCSTATES=0 -DHAVESTDIO -DRT
-DUSE_RTMODEL  @TMS_Build_comp.rsp -o"TMS_Build_106165d6_1_ds_dxf.obj"
"../TMS_Build_veristand_rtw/TMS_Build_106165d6_1_ds_dxf.c" -save-temps
gcc: internal compiler error: Segmentation fault (program cc1)
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

[Bug c/98431] Gcc crashes with segmentation fault

[Farshid at virginhyperloop dot com via Gcc-bugs]

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

--- Comment #4 from Farshid Shadpey  ---
the gzip version of preprocessed file is 1.4 MB and cannot be attached.
please advise

[Bug target/97891] [x86] Consider using registers on large initializations

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Hongtao.liu  ---
cat test.c

typedef struct {
  long a;
  long b;
}TI;

extern TI r;
void
foo ()
{
  r.a = 0;
  r.b = 0;
}

gcc -Ofast -march=cascadelake -S got

foo:
.LFB0:
.cfi_startproc
movq$0, r(%rip)
movq$0, r+8(%rip)
ret
.cfi_endproc
.LFE0:


SLP failed to vectorize due to cost

test1.c:10:7: note:   === vect_slp_analyze_instance_alignment ===
test1.c:10:7: note:   vect_compute_data_ref_alignment:
test1.c:10:7: note:   can't force alignment of ref: r.a
test1.c:10:7: note:   === vect_slp_analyze_instance_dependence ===
test1.c:10:7: note:   === vect_slp_analyze_operations ===
test1.c:10:7: note:   ==> examining statement: r.a = 0;
test1.c:10:7: note:   vect_is_simple_use: operand 0, type of def: constant
test1.c:10:7: note:   Vectorizing an unaligned access.
test1.c:10:7: note:   vect_model_store_cost: unaligned supported by hardware.
test1.c:10:7: note:   vect_model_store_cost: inside_cost = 16, prologue_cost =
0 .
test1.c:10:7: note:   === vect_bb_partition_graph ===
test1.c:10:7: note: * Analysis succeeded with vector mode V16QI
test1.c:10:7: note: SLPing BB part
0x48bc3d0 0 1 times unaligned_store (misalign -1) costs 16 in body
0x48bc3d0  1 times vector_load costs 12 in prologue
0x48bbf50 0 1 times scalar_store costs 12 in body
0x48bbf50 0 1 times scalar_store costs 12 in body
test1.c:10:7: note: Cost model analysis: 
  Vector inside of basic block cost: 16
  Vector prologue cost: 12
  Vector epilogue cost: 0
  Scalar cost of basic block: 24

Shouldn't cost of zero vector CTOR be different from normal ones?
Since x86 could have pxor, similar for aarch64 (eor??).

[Bug target/98434] New: [AVX512] Missing expander for vashl, vlshr, vashr{v32hi,v16hi,v4di,v8di}

[crazylht at gmail dot com via Gcc-bugs]

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

Bug ID: 98434
   Summary: [AVX512] Missing expander for vashl,
vlshr, vashr{v32hi,v16hi,v4di,v8di}
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: crazylht at gmail dot com
CC: hjl.tools at gmail dot com, wei3.xiao at intel dot com,
wwwhhhyyy333 at gmail dot com
  Target Milestone: ---
Target: x86_64-*-* i?86-*-*

[Bug target/98434] [AVX512] Missing expander for vashl, vlshr, vashr{v32hi,v16hi,v4di,v8di}

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Hongtao.liu  ---
Also may add expander for VI1_AVX512BW by int16 emulation.

[Bug target/98435] New: [ARM NEON] Missed optimization in expanding vector constructor

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

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

Bug ID: 98435
   Summary: [ARM NEON] Missed optimization in expanding vector
constructor
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: prathamesh3492 at gcc dot gnu.org
  Target Milestone: ---

For the following test-case:

#include 

bfloat16x4_t f1 (bfloat16_t a)
{
  return vdup_n_bf16 (a);
}

bfloat16x4_t f2 (bfloat16_t a)
{
  return (bfloat16x4_t) {a, a, a, a};
}

Compiling with arm-linux-gnueabi -O3 -mfpu=neon -mfloat-abi=softfp 
-march=armv8.2-a+bf16+fp16 results in f2 not being vectorized:

f1:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
vdup.16 d16, r0
vmovr0, r1, d16  @ v4bf
bx  lr


f2:
@ args = 0, pretend = 0, frame = 0
@ frame_needed = 0, uses_anonymous_args = 0
@ link register save eliminated.
mov r3, r0  @ __bf16
adr r1, .L4
ldrdr0, [r1]
mov r2, r3  @ __bf16
mov ip, r3  @ __bf16
bfi r1, r2, #0, #16
bfi r0, ip, #0, #16
bfi r1, r3, #16, #16
bfi r0, r2, #16, #16
bx  lr


.optimized dump shows:
bfloat16x4_t f1 (bfloat16_t a)
{
  __simd64_bfloat16_t _3;

   [local count: 1073741824]:
  _3 = __builtin_neon_vdup_nv4bf (a_2(D)); [tail call]
  return _3;

}

bfloat16x4_t f2 (bfloat16_t a)
{
  bfloat16x4_t _2;

   [local count: 1073741824]:
  _2 = {a_1(D), a_1(D), a_1(D), a_1(D)};
  return _2;
}

[Bug target/98435] [ARM NEON] Missed optimization in expanding vector constructor

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

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

prathamesh3492 at gcc dot gnu.org changed:

   What|Removed |Added

   Severity|normal  |enhancement
  Build||x86_64-unknown-linux-gnu
   Keywords||missed-optimization
 CC||prathamesh3492 at gcc dot 
gnu.org
 Target||arm-linux-gnueabi
   Host||x86_64-unknown-linux-gnu

[Bug tree-optimization/98281] - -Wformat-truncation false positive due to excessive integer range (gcc 10.2.0)

[ishikawa at yk dot rim.or.jp via Gcc-bugs]

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

--- Comment #4 from ishikawa,chiaki  ---
(In reply to Martin Sebor from comment #3)
> The warning works as designed but the range information it depends on is
> less than perfect.  As discussed in pr94021 that's a known limitation of the
> current range propagation infrastructure.  GCC 11 adds an improved range
> engine known as the Ranger that's expected to remedy this but it is yet to
> be integrated with the sprintf/strlen pass.  The argument ranges can be
> constrained by using a "narrower" directive such as %hhu.
> 

Thank you for the detailed explanation.

It would be great to see this Ranger incorporated into the sprintf/strlen pass.
I say this because I found a bug in a popular code which this feature could
have found.  (The bug was found by the dynamic check done by ASAN-build.)

Thank you for continuously developing GCC with these new features.
Happy festive season to all.

[Bug tree-optimization/98281] - -Wformat-truncation false positive due to excessive integer range (gcc 10.2.0)

[ishikawa at yk dot rim.or.jp via Gcc-bugs]

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

--- Comment #5 from ishikawa,chiaki  ---
(In reply to Martin Sebor from comment #3)
> The warning works as designed but the range information it depends on is
> less than perfect.  As discussed in pr94021 that's a known limitation of the
> current range propagation infrastructure.  GCC 11 adds an improved range
> engine known as the Ranger that's expected to remedy this but it is yet to
> be integrated with the sprintf/strlen pass.  The argument ranges can be
> constrained by using a "narrower" directive such as %hhu.
> 

Thank you for the detailed explanation.

It would be great to see this Ranger incorporated into the sprintf/strlen pass.
I say this because I found a bug in a popular code which this feature could
have found.  (The bug was found by the dynamic check done by ASAN-build.)

Thank you for continuously developing GCC with these new features.
Happy festive season to all.

[Bug fortran/98433] double free detected in tcache 2, after merge of structures

[guez at lmd dot ens.fr via Gcc-bugs]

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

--- Comment #4 from Lionel GUEZ  ---
Well, you will find that assignment of an expression of derived type to a
variable of the same type was already available in Fortran 95 (for example
Metcalf, 1999, Fortran 90/95 explained, section 3.9). But allocatable
components appeared in Fortran 2003. (I think it is time now we stopped
referring to Fortran 95.)