[Bug rtl-optimization/93272] LRA: EH reg allocated to hold local variable

[krebbel at gcc dot gnu.org]

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

Andreas Krebbel  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
   Last reconfirmed||2020-02-12
 Resolution|FIXED   |---
 Ever confirmed|0   |1

--- Comment #8 from Andreas Krebbel  ---
Since this is a latent bug in LRA I think the patch needs backporting to GCC 8
and 9 branches.

[Bug preprocessor/93677] Create a warning for duplicate macro definition

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-12
 Ever confirmed|0   |1
   Severity|normal  |enhancement

[Bug go/93679] [10 regression] gccgo cannot bootstrap go1.14

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

[Bug fortran/93678] ICE in 9.2/9.2.1 not happening in previous gfortran versions

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

[Bug c++/93684] [8/9/10 Regression] ICE in cp_lexer_consume_token, at cp/parser.c:1120

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P2
   Target Milestone|--- |8.4

[Bug fortran/93686] [9/10 Regression] ICE in gfc_match_data, at fortran/decl.c:702

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |9.3

[Bug fortran/93685] [9/10 Regression] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |9.3

[Bug testsuite/93697] pr93661.c does not warn on (32-bit) powerpc-linux

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-12
  Component|tree-optimization   |testsuite
Version|unknown |10.0
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
I'll see what to do.

[Bug testsuite/93697] pr93661.c does not warn on (32-bit) powerpc-linux

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Fixed.

[Bug testsuite/93697] pr93661.c does not warn on (32-bit) powerpc-linux

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Richard Guenther :

https://gcc.gnu.org/g:12c763c68a28d0c002b382b15ec138a8bc01e3bf

commit r10-6592-g12c763c68a28d0c002b382b15ec138a8bc01e3bf
Author: Richard Biener 
Date:   Wed Feb 12 10:03:09 2020 +0100

testsuite/93697 fix inconsistent warning in testcase

The warning was emitted inconsistently on targets, so disable it since
the testcase was for an ICE.

2020-02-12  Richard Biener  

PR testsuite/93697
* gcc.dg/pr93661.c: Pass -w, remove dg-warning.

[Bug c++/93687] Add mcf thread model to GCC on windows for supporting C++11 std::thread?

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #2 from Eric Botcazou  ---
> I think this patch should be merged into GCC trunk to support mcf thread
> model on windows. Or GCC won't magically compile on windows because lack of
> std::thread support

There is a much lighter approach proposed at:
  https://gcc.gnu.org/ml/gcc-patches/2019-06/msg01840.html

[Bug c++/93698] New: ICE on concept using generic lambda

[kretz at kde dot org]

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

Bug ID: 93698
   Summary: ICE on concept using generic lambda
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kretz at kde dot org
  Target Milestone: ---

Test case (-std=c++2a):

  template  concept foo = [](auto) constexpr -> bool { return true;
}(N);
  bool a = foo<2>;

Extended test case (use lambda in concept to turn integer into index sequence):

  #include 
  template 
  concept foo = [](std::index_sequence) constexpr {
return (Is + ...) > 10;
  }(std::make_index_sequence());
  bool a = foo<7>;

If I read the standard correctly, both test cases are well-formed and should
work: P0315R4 started to allow lambdas in unevaluated contexts
(https://eel.is/c++draft/temp.concept#6).

On a slight tangent: I believe substitution failures on instantiation of the
lambda are not ill-formed, even though P0315R4 seemed to intend that outcome.
While I would love to use it to SFINAE test structured bindings, I think this
is rather a defect in the current WD, no?

[Bug rtl-optimization/93264] [10 Regression] ICE in cfg_layout_redirect_edge_and_branch_force, at cfgrtl.c:4522

[zhroma at gcc dot gnu.org]

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

--- Comment #5 from Roman Zhuykov  ---
Created attachment 47820
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47820&action=edit
Considered "moving sms earlier" patch

I haven't tested "moving sms earlier" patch since 2011.  But I remember there
were some testsuite items where it makes difference, not sure whether it was
arm or ia64 platform.  I decided those passes between substantially change the
loop code and DDG.

I'll run some cross-testing to check how it works for now.

> In general it's a bad idea to try go "back" to CFG layout mode and the fix is
> to not do that.
Also qouting https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00714.html:

> I think the expectation that you can go back to CFG layout mode
> and then work with CFG layout tools after we've lowered to CFG RTL
> is simply bogus.  Yeah, you can probably do analysis things but
> I wouldn't be surprised if a CFG RTL -> CFG layout -> CFG RTL cycle 
> can wreck things.  Undoubtedly doing CFG manipulations is not going
> to work since CFG layout does not respect CFG RTL restrictions.
> Partitioning simply uncovered latent bugs, there's nothing wrong
> with it IMHO.
There are two more passes re-entering cfg layout: pass_reorder_blocks and
pass_machine_reorg.

[Bug target/93696] AVX512VPOPCNTDQ writemask intrinsics produce incorrect results

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-12
 CC||jakub at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
The bug is in the header files, arguments not named according to the usual
conventions and getting the order wrong.

[Bug fortran/93685] [9/10 Regression] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from markeggleston at gcc dot gnu.org ---
Introduced with https://gcc.gnu.org/g:b6e841a699fe43ddf632dd79e0002dd51c8bf864
"decl.c (match_data_constant): Fortran 2018 allows pointer initialization in a
data statement."

Changing the example code to:

program p
   type t
  integer :: a
   end type
   type(t) :: x
   integer, target :: c = 10
   data x%a /c/
end program

results in:

7 |data x%a /c/
  |  1
Error: non-constant initialization expression at (1)

I think the error message is inadequate, it ought to state that 'a' does not
have the pointer attribute or something along those lines.

The ICE only appears to occur if the types of a and x are both CHARACTER.

This is a feature of Fortran 2018, however with the pointer attribute added to
a the code compiles irrespective of the -std option.

I think the issues of error messages and -std can be postponed until the next
release.

[Bug target/93696] AVX512VPOPCNTDQ writemask intrinsics produce incorrect results

[jakub at gcc dot gnu.org]

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

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

Untested fix.

[Bug c++/93699] New: [gcc10] Invalid operator== (returning non-bool type) candidate

[laurent.stacul at gmail dot com]

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

Bug ID: 93699
   Summary: [gcc10] Invalid operator== (returning non-bool type)
candidate
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: laurent.stacul at gmail dot com
  Target Milestone: ---

Hello,

With a HEAD of gcc:

gcc -v 
  
[jobs: 2][history: 5226]
Reading specs from
/remote/tools/Linux/2.6/1A/toolchain/x86_64-v20.0.8/bin/../lib/gcc/x86_64-1a-linux-gnu/10.0.1/specs
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/remote/tools/Linux/2.6/1A/toolchain/x86_64-v20.0.8/bin/../libexec/gcc/x86_64-1a-linux-gnu/10.0.1/lto-wrapper
Target: x86_64-1a-linux-gnu
Configured with: /workdir/src/gcc-10.0.1/configure --build=x86_64-1a-linux-gnu
--host=x86_64-1a-linux-gnu --target=x86_64-1a-linux-gnu
--prefix=/opt/1A/toolchain/x86_64-v20.0.8
--with-local-prefix=/opt/1A/toolchain/x86_64-v20.0.8
--with-native-system-header-dir=/opt/1A/toolchain/x86_64-v20.0.8/include
--enable-languages=c,c++,fortran --disable-multilib --enable-linker-build-id
--with-linker-hash-style=gnu --enable-gnu-indirect-function
--with-build-config=bootstrap-lto --enable-install-libiberty
--enable-checking=release
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.0.1 20200211 (experimental) (GCC)

In the following example, I think there is something odd:

class Base {
public:
virtual int operator==(const Base&) const {
return 1;
}
};

class Derived : public Base {
public:
virtual int operator==(const Base&) const {
return 1;
}
};

int main(int argc, const char *argv[])
{
Base* b;
Derived* d;
if (*b == *d) {
return 1;
}
return 0;
}

The compilation is done as follows:

$ g++ -std=gnu++2a rep.cpp

: In function 'int main(int, const char**)':

:19:12: error: return type of 'virtual int Derived::operator==(const
Base&) const' is not 'bool'

   19 | if (*b == *d) {

  | ~~~^

:19:12: note: used as rewritten candidate for comparison of 'Base' and
'Derived'

Compiler returned: 1

I understand that C++20 introduced the possibility for the compiler to have the
reversed primary operator to be candidate in the function resolution, but as
far as I understand the primary comparison operators are not rewritten.

Is there a bug in the C++20 support or did I miss something ?
Regards,
Stac

[Bug target/93670] ICE for _mm256_extractf32x4_ps (unrecognized insn)

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:62fc0a6ce28c502fc6a7b7c09157840bf98f945f

commit r10-6593-g62fc0a6ce28c502fc6a7b7c09157840bf98f945f
Author: Jakub Jelinek 
Date:   Wed Feb 12 11:58:35 2020 +0100

i386: Fix up vec_extract_lo* patterns [PR93670]

The VEXTRACT* insns have way too many different CPUID feature flags (ATT
syntax)
vextractf128 $imm, %ymm, %xmm/mem   AVX
vextracti128 $imm, %ymm, %xmm/mem   AVX2
vextract{f,i}32x4 $imm, %ymm, %xmm/mem {k}{z}   AVX512VL+AVX512F
vextract{f,i}32x4 $imm, %zmm, %xmm/mem {k}{z}   AVX512F
vextract{f,i}64x2 $imm, %ymm, %xmm/mem {k}{z}   AVX512VL+AVX512DQ
vextract{f,i}64x2 $imm, %zmm, %xmm/mem {k}{z}   AVX512DQ
vextract{f,i}32x8 $imm, %zmm, %ymm/mem {k}{z}   AVX512DQ
vextract{f,i}64x4 $imm, %zmm, %ymm/mem {k}{z}   AVX512F

As the testcase shows and the patch too, we didn't get it right in all
cases.

The first hunk is about avx512vl_vextractf128v8s[if] incorrectly
requiring TARGET_AVX512DQ.  The corresponding insn is the first
vextract{f,i}32x4 above, so it requires VL+F, and the builtins have it
correct (TARGET_AVX512VL implies TARGET_AVX512F):
BDESC (OPTION_MASK_ISA_AVX512VL, 0, CODE_FOR_avx512vl_vextractf128v8sf,
"__builtin_ia32_extractf32x4_256_mask", IX86_BUILTIN_EXTRACTF32X4_256, UNKNOWN,
(int) V4SF_FTYPE_V8SF_INT_V4SF_UQI)
BDESC (OPTION_MASK_ISA_AVX512VL, 0, CODE_FOR_avx512vl_vextractf128v8si,
"__builtin_ia32_extracti32x4_256_mask", IX86_BUILTIN_EXTRACTI32X4_256, UNKNOWN,
(int) V4SI_FTYPE_V8SI_INT_V4SI_UQI)
We only need TARGET_AVX512DQ for avx512vl_vextractf128v4d[if].

The second hunk is about vec_extract_lo_v16s[if]{,_mask}.  These are using
the vextract{f,i}32x8 insns (AVX512DQ above), but we weren't requiring
that,
but instead incorrectly && 1 for non-masked and && (64 == 64 &&
TARGET_AVX512VL)
for masked insns.  This is extraction from ZMM, so it doesn't need VL for
anything.  The hunk actually only requires TARGET_AVX512DQ when the insn
is masked, if it is not masked, when TARGET_AVX512DQ isn't available we can
use vextract{f,i}64x4 instead which is available already in TARGET_AVX512F
and does the same thing, extracts the low 256 bits from 512 bits vector
(often we split it into just nothing, but there are some special cases like
when using xmm16+ when we can't without AVX512VL).

The last hunk is about vec_extract_lo_v8s[if]{,_mask}.  The non-_mask
suffixed ones are ok already and just split into nothing (lowpart subreg).
The masked ones were incorrectly requiring TARGET_AVX512VL and
TARGET_AVX512DQ, when we only need TARGET_AVX512VL.

2020-02-12  Jakub Jelinek  

PR target/93670
* config/i386/sse.md (VI48F_256_DQ): New mode iterator.
(avx512vl_vextractf128): Use it instead of VI48F_256.  Remove
TARGET_AVX512DQ from condition.
(vec_extract_lo_): Use 
instead of  in condition.  If
TARGET_AVX512DQ is false, emit vextract*64x4 instead of
vextract*32x8.
(vec_extract_lo_): Drop 
from condition.

* gcc.target/i386/avx512vl-pr93670.c: New test.

[Bug target/93670] ICE for _mm256_extractf32x4_ps (unrecognized insn)

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek  ---
Fixed on the trunk so far.

[Bug rtl-optimization/93565] [9/10 regression] Combine duplicates instructions

[rearnsha at gcc dot gnu.org]

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

--- Comment #14 from Richard Earnshaw  ---
With the simpler test case we see

Breakpoint 1, try_combine (i3=0x764d33c0, i2=0x764d3380, i1=0x0, 
i0=0x0, new_direct_jump_p=0x7fffd850, 
last_combined_insn=0x764d33c0)
at /home/rearnsha/gnusrc/gcc-cross/master/gcc/combine.c:2671
2671{
(nil)
(nil)
(insn 7 4 8 2 (set (reg/v:SI 96 [ a ])
(and:SI (reg:SI 104)
(const_int 14 [0xe]))) "/tmp/t2.c":3:7 535 {andsi3}
 (expr_list:REG_DEAD (reg:SI 104)
(nil)))
(insn 8 7 10 2 (set (reg:DI 99 [ a ])
(sign_extend:DI (reg/v:SI 96 [ a ]))) "/tmp/t2.c":4:13 106
{*extendsidi2_aarch64}
 (nil))


And then the resulting insn that we try is

(parallel [
(set (reg:DI 99 [ a ])
(and:DI (subreg:DI (reg:SI 104) 0)
(const_int 14 [0xe])))
(set (reg/v:SI 96 [ a ])
(and:SI (reg:SI 104)
(const_int 14 [0xe])))
])

This insn doesn't match, and so we try to break it into two set insn and try
those individually.  But that gives us back insn 7 again and then a new insn
based on the (now extended lifetime) of r104.  It seems to me that if we are
doing this sort of transformation, then it's only likely to be profitable if
the cost of the really new insn is strictly cheaper than what we have before. 
Being the same cost is not enough in this case.

[Bug c++/93700] New: new expression ignores deleted operator new.

[maxim.yegorushkin at gmail dot com]

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

Bug ID: 93700
   Summary: new expression ignores deleted operator new.
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: maxim.yegorushkin at gmail dot com
  Target Milestone: ---

The following code:

struct C {
C() { throw 1; }
static void* operator new(unsigned long);
static void operator delete(void*) = delete;
};

C* f() { return new C; }

Correctly fails to compile with clang:

:7:17: error: attempt to use a deleted function
C* f() { return new C; }
^
:4:10: note: 'operator delete' has been explicitly marked deleted
here
void operator delete(void*) = delete;
 ^

Whereas g++ simply ignores deleted `operator delete` and doesn't call it in the
generated assembly at all. If that `operator delete` is commented out g++ does
call the global `operator delete`.

[Bug target/93300] ICE in convert_mode_scalar, at expr.c:325

[stammark at gcc dot gnu.org]

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

Stam Markianos-Wright  changed:

   What|Removed |Added

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

--- Comment #2 from Stam Markianos-Wright  ---
Have not seen any further instances of this issue since my patch, so moving to
RESOLVED.

[Bug fortran/93701] New: ICE on associate of wrongly accessed array

[simon_brass at gmx dot de]

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

Bug ID: 93701
   Summary: ICE on associate of wrongly accessed array
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: simon_brass at gmx dot de
  Target Milestone: ---

Created attachment 47822
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47822&action=edit
Reproducer file for the ICE using associate and array statements.

I've got the following ICE report appearing in the attached file.

* Error message
f951: internal compiler error: find_array_spec(): Missing spec

* Source Code / Reproducer

The source code *is* erroneous, therefore, should not compile, however, it
should fail with an error message.

The error appears within:
> associate (state => obj%state(TEST_STATES))
>   state%a = a
>   state(TEST_STATE)%a = a
> end associate
where state can be either of intrinsic or derived type.
The compiler should complain on the third line and TEST_STATES, the latter
should be TEST_STATE. 

Exchanging the second and third line, or correcting the name of TEST_STATES to
TEST_STATE (removed the S at the end), leads then to a correct error message by
the compiler.

* Build command
gfortran -c ice-gfortran.f90 -o ice-gfortran.o

Also, tried:
gfortran -Wall -Wextra -c ../test/ice-gfortran.f90 -o ice-gfortran.o
gfortran -Wall -Wextra -fno-strict-aliasing -fwrapv -c ../test/ice-gfortran.f90
-o ice-gfortran.o

* Output of gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-pkgversion='Arch Linux 9.2.1+20200130-2'
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.2.1 20200130 (Arch Linux 9.2.1+20200130-2)

[Bug ada/93702] New: Bug box when using Indefinite_Holders.To_Holder in expression function

[laguest at archeia dot com]

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

Bug ID: 93702
   Summary: Bug box when using Indefinite_Holders.To_Holder in
expression function
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: laguest at archeia dot com
  Target Milestone: ---

Created attachment 47823
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47823&action=edit
Minimal source code and gpr file

Compiled with:

gprbuild -g -p -P examples.gpr

+===GNAT BUG DETECTED==+
| 9.2.0 (x86_64-pc-linux-gnu) Storage_Error stack overflow or erroneous memory
access|
| Error detected at parsing.ads:15:104 |
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Please include these source files with error report
Note that list may not be accurate in some cases,
so please double check that the problem can still
be reproduced with the set of files listed.
Consider also -gnatd.n switch (see debug.adb).

/home/laguest/src/mine-new/compilers/mixers/pc_tut/bug/simple.adb
/home/laguest/src/mine-new/compilers/mixers/pc_tut/bug/parsing.ads

[Bug c++/93703] New: global const getting lost in g++

[felix-gcc at fefe dot de]

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

Bug ID: 93703
   Summary: global const getting lost in g++
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: felix-gcc at fefe dot de
  Target Milestone: ---

I suspect this is my mistake, not gcc's, but I'm out of ideas so sorry for
wasting your time if that is true.

Here is my situation:

  $ cat a.cc
  const int foo = 23;
  $ cat b.cc
  extern const int foo;
  int main() {
return foo;
  }
  $ g++ -o x a.cc b.cc
 
/usr/lib64/gcc/x86_64-pc-linux-gnu/9.2.0/../../../../x86_64-pc-linux-gnu/bin/ld:
/tmp/ccXS1J5J.o: in function `main':
  b.cc:(.text+0x6): undefined reference to `foo'
  collect2: error: ld returned 1 exit status
  $

Wait, what?

  $ g++ -c a.cc b.cc && nm a.o b.o
  a.o:
   r _ZL3foo

  b.o:
   U foo
   T main
  $

What the...? Why is foo mangled in a.o but not in b.o?

I tried this with clang++ too and there it's even worse: a.o is empty and does
not even export a mangled foo.

What am I missing?

[Bug target/93704] New: SPARC GCC emits R_SPARC_TLS_GD_CALL code not understood by Solaris linker

[vita.batrla at gmail dot com]

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

Bug ID: 93704
   Summary: SPARC GCC emits R_SPARC_TLS_GD_CALL code not
understood by Solaris linker
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vita.batrla at gmail dot com
  Target Milestone: ---

In the ELF Handling for Thread-Local Storage document [1] in section 4.1.3
SPARC General Dynamic TLS Model on page 20-21, following code sequence is
defined for GD relocations:

General Dynamic Model Code Sequence Initial Relocation  Symbol
0x00 sethi %hi(@dtlndx(x)), %o0 R_SPARC_TLS_GD_HI22 x
0x04 add   %o0,%lo(@dtlndx(x)), %o0 R_SPARC_TLS_GD_LO10 x
0x08 add   %l7,%o0, %o0 R_SPARC_TLS_GD_ADD  x
0x0c call  __tls_get_addr   R_SPARC_TLS_GD_CALL x

With comment:

> The code sequence must appear in the code as is. It is not possible to move
> the second add instruction in the delay slot of the call instruction since
> the linker would not recognize the instruction sequence. (2)

and note (2):

> This is at least what Sun’s documentation says and apparently how Sun’s
> linker works. Given the relocations which show exactly what the instructions
> do this seems not really necessary.

However, GCC 7/9 emits this sequence in .o file:

  2c:   11 00 00 00 sethi  %hi(0), %o0
2c: R_SPARC_TLS_GD_HI22 __gcov_indirect_call_callee
  30:   90 02 20 00 add  %o0, 0, %o0! 0 
30: R_SPARC_TLS_GD_LO10 __gcov_indirect_call_callee
  34:   40 00 00 00 call  34 
34: R_SPARC_TLS_GD_CALL __gcov_indirect_call_callee
  38:   90 05 c0 08 add  %l7, %o0, %o0
38: R_SPARC_TLS_GD_ADD  __gcov_indirect_call_callee

It is apparent that the compiler generated the GD TLS sequence in different
order than the TLS document suggests. It placed the second add instruction in
the branch delay slot of call instruction, which is against the document
statement:

"It is not possible to move the second add instruction in the delay slot of the
call instruction"

This relaxed order generated by GCC is no doubt more efficient, however, it is
not understood by Solaris linker, which converts the call instruction during
GD->IE transition to add instruction: 'add %g7, %o0, %o0' (opcode: 90 01 c0
08). The problem is that the original instruction in branch delay slot was
supposed to execute before instruction on branch target (it calculates input
argument for call instruction target), but after it is converted to add
instruction, branch is gone and so is its delay slot and instructions execute
in program order. This corrupts value in %o0 register as both instructions
write to it but execute in different than originally supposed order and
corrupted %o0 causes SIGSEGV (if lucky) in subsequent attempt to use it in
memory de-reference to get value of a TLS variable.

[Bug target/93704] SPARC GCC emits R_SPARC_TLS_GD_CALL code not understood by Solaris linker

[vita.batrla at gmail dot com]

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

--- Comment #1 from Vita Batrla  ---
[1] https://www.uclibc.org/docs/tls.pdf

[Bug c++/93703] global const getting lost in g++

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
'const' implies internal linkage unless you specify extern.  So 'extern' is
missing in a.cc.  (this is unlike in C where const does not imply internal
linkage)

[Bug c++/93703] global const getting lost in g++

[felix-gcc at fefe dot de]

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

--- Comment #2 from felix-gcc at fefe dot de ---
OK that answers half of the mystery, but why is foo not mangled?

[Bug target/93704] SPARC GCC emits R_SPARC_TLS_GD_CALL code not understood by Solaris linker

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
How did you configure gcc?

[Bug c++/93703] global const getting lost in g++

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to felix-gcc from comment #2)
> OK that answers half of the mystery, but why is foo not mangled?

Because the ABI says so.  Only names which can have overloading applied
are usually mangled, that is, variables are not (we seem to choose to
mangle internal variables for some reason).

[Bug target/93704] SPARC GCC emits R_SPARC_TLS_GD_XXXX code not understood by Solaris linker

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

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

--- Comment #3 from Eric Botcazou  ---
Yep, a thinko pertaining to TARGET_GNU_TLS.

[Bug target/93704] SPARC GCC emits R_SPARC_TLS_GD_XXXX code not understood by Solaris linker

[ebotcazou at gcc dot gnu.org]

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

Eric Botcazou  changed:

   What|Removed |Added

 Target|sparc-solaris   |sparc-solaris2.*
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org
   Target Milestone|--- |8.4

--- Comment #4 from Eric Botcazou  ---
Fixing.

[Bug target/93704] TLS sequences not understood by SPARC/Solaris linker

[vita.batrla at gmail dot com]

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

--- Comment #5 from Vita Batrla  ---
To answer previous question,
here are configure options for GCC in Solaris:

https://github.com/oracle/solaris-userland/blob/60efc343ffab1adac2d1c9cac7629af26d40de50/components/gcc9/Makefile#L91

CONFIGURE_OPTIONS +=--infodir=$(CONFIGURE_INFODIR)
CONFIGURE_OPTIONS +=--libexecdir=$(CONFIGURE_PREFIX)/lib
CONFIGURE_OPTIONS +=--enable-languages="c,c++,fortran,go,objc"
CONFIGURE_OPTIONS +=--enable-shared
CONFIGURE_OPTIONS +=--enable-initfini-array
CONFIGURE_OPTIONS +=--disable-rpath
CONFIGURE_OPTIONS +=--with-system-zlib
CONFIGURE_OPTIONS +=--with-build-config=no
CONFIGURE_OPTIONS +=--with-gmp-include=$(shell pkg-config
--variable=includedir libgmp)
CONFIGURE_OPTIONS +=--with-mpfr-include=$(shell pkg-config
--variable=includedir libmpfr)
CONFIGURE_OPTIONS +=--without-gnu-ld --with-ld=$(USRBINDIR)/ld
CONFIGURE_OPTIONS +=--with-gnu-as --with-as=$(GNUBIN)/as

See last two lines,
GCC is built with GNU as, but Solaris ld.

[Bug c++/93700] new expression ignores deleted operator delete.

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||accepts-invalid, wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-12
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=20040
Summary|new expression ignores  |new expression ignores
   |deleted operator new.   |deleted operator delete.
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Confirmed. Possibly a dup to PR 20040, or just related to it.

[Bug analyzer/93288] ICE in supergraph.cc:180

[dmalcolm at gcc dot gnu.org]

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

--- Comment #12 from David Malcolm  ---
(In reply to pmatos from comment #11)
> (In reply to David Malcolm from comment #10)
> > Should be fixed by the above commit.
> 
> David, does this mean the analyzer has C++ support now or just that this
> specific bug is fixed in-tree?

The latter.  I don't expect the analyzer to be useful with C++ in this release
(I'm just fixing the ICE in a way that will help with supporting C++ in the
future).

[Bug c++/93705] New: [C++2a] Non-type literal class template-parameter types with mutable data members should not be allowed

[kevin at hart dot mn]

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

Bug ID: 93705
   Summary: [C++2a] Non-type literal class template-parameter
types with mutable data members should not be allowed
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kevin at hart dot mn
  Target Milestone: ---

In the current implementation of C++2a, otherwise structural class types with
mutable data members are allowed as non-type template parameters.

The following sources seem to indicate that these should be rejected:
https://github.com/cplusplus/draft/blob/0354125f1cdfef949d80053528c4a1a4f74b1dea/source/templates.tex#L396
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2019/p1907r1.html

Perhaps non-const member functions should cause rejection as well? I couldn't
find anything about this.

Example:


struct Literal {
constexpr Literal() {}

// This is allowed (not const), but perhaps shouldn't be.
bool has_value = false;
};

template
void Test() {
// The below will fail if uncommented, but seems different
// from the language of the spec.

// error: assignment of member 'Literal::has_value' in read-only object
// lit.has_value = true; 
}

int main()
{
Test();
}

[Bug analyzer/93695] Allocation and freeing memory for array members in loops is not handled properly by the analyzer

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #1 from David Malcolm  ---
Confirmed; thanks.  Seems to happen at every optimization level, not just with
-O1.

[Bug gcov-profile/93706] New: [GCOV] function with inline attribute leads to incorrect code coverage

[yangyibiao at hust dot edu.cn]

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

Bug ID: 93706
   Summary: [GCOV] function with inline attribute leads to
incorrect code coverage
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: gcov-profile
  Assignee: unassigned at gcc dot gnu.org
  Reporter: yangyibiao at hust dot edu.cn
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

$ gcov -v
gcov (GCC) 9.2.0
Copyright (C) 2019 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or 
FITNESS FOR A PARTICULAR PURPOSE.


$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
gcc version 9.2.0 (GCC)


$ cat small.c
static inline __attribute__ ((always_inline)) int foo (unsigned short v)
{
  return (v << 8) | (v >> 8);
}

int main ()
{
  unsigned short b = 0;
  return foo(b);
}


$ gcc -O0 --coverage small.c; ./a.out; gcov small.c; cat small.c.gcov
File 'small.c'
Lines executed:100.00% of 4
Creating 'small.c.gcov'

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:1:static inline __attribute__ ((always_inline)) int foo (unsigned short
v)
-:2:{
1:3:  return (v << 8) | (v >> 8);
-:4:}
-:5:
1:6:int main ()
-:7:{
1:8:  unsigned short b = 0;
2:9:  return foo(b);
-:   10:}




### We can find that: Line #9 is wrongly marked as executed 2 times
### When the "__attribute__ ((always_inline))" is removed for the definition of
function "foo", the code coverage is correct

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

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

--- Comment #160 from Peter Bisroev  ---
Created attachment 47824
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47824&action=edit
.o, .s and RTL dumps

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[peter.bisroev at groundlabs dot com]

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

--- Comment #161 from Peter Bisroev  ---
Hi Dave,

I have added attachment 47824 (sancov.dump.tar.xz) containing .o, .s and RTL
dumps as you have requested. It is for the compilation of gcc/sancov.c in gcc
8.3.0 using 4.7.4 as a host compiler. The exact compilation command line was:

/home/pbisroev/local/aCC/32/gcc-4.7.4-self-bootstrap/bin/g++ -std=gnu++98 \
  -fno-PIE -c -DUSE_LIBUNWIND_EXCEPTIONS -D_XOPEN_SOURCE_EXTENDED -g -O0 \
  -DIN_GCC -fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall \
  -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format \
  -Wmissing-format-attribute -Woverloaded-virtual -pedantic -Wno-long-long \
  -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H \
  -I. -I. -I/home/pbisroev/src/gcc-8.3.0/gcc \
  -I/home/pbisroev/src/gcc-8.3.0/gcc/. \
  -I/home/pbisroev/src/gcc-8.3.0/gcc/../include \
  -I/home/pbisroev/src/gcc-8.3.0/gcc/../libcpp/include \
  -I/home/pbisroev/local/aCC/32/include \
  -I/home/pbisroev/local/aCC/32/include \
  -I/home/pbisroev/local/aCC/32/include  \
  -I/home/pbisroev/src/gcc-8.3.0/gcc/../libdecnumber \
  -I/home/pbisroev/src/gcc-8.3.0/gcc/../libdecnumber/dpd \
  -I../libdecnumber -I/home/pbisroev/src/gcc-8.3.0/gcc/../libbacktrace \
  -o sancov.o -MT sancov.o -MMD -MP -MF ./.deps/sancov.TPo \
  /home/pbisroev/src/gcc-8.3.0/gcc/sancov.c \
  -save-temps -da



The exact HP linker errors from linking cc1, cc1plus and lto1 were (I was
compiling in parallel):

ld: The value 0xfdc6eaf0 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x102 in section index 51 of file
libbackend.a[sancov.o]
ld: The value 0xfd8bf620 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x102 in section index 51 of file
libbackend.a[sancov.o]
ld: The value 0xfdd8c540 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x102 in section index 51 of file
libbackend.a[sancov.o]


Please let me know if there is anything missing.

Thanks!
--peter

[Bug c++/93684] [8/9/10 Regression] ICE in cp_lexer_consume_token, at cp/parser.c:1120

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-6594-ge428a9cf85a8bdde9d031a215e10bd96eb3b789a
Author: Marek Polacek 
Date:   Tue Feb 11 15:29:24 2020 -0500

c++: Fix ICE-on-invalid with broken attribute [PR93684]

We crash when parsing

  [[a::

because we see a CPP_SCOPE and then we're trying to consume a CPP_EOF
token.  So peek before consuming it.

PR c++/93684 - ICE-on-invalid with broken attribute.
* parser.c (cp_parser_std_attribute): Peek a token first before
consuming it.

* g++.dg/parse/attr4.C: New test.

[Bug c++/93684] [8/9 Regression] ICE in cp_lexer_consume_token, at cp/parser.c:1120

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
Summary|[8/9/10 Regression] ICE in  |[8/9 Regression] ICE in
   |cp_lexer_consume_token, at  |cp_lexer_consume_token, at
   |cp/parser.c:1120|cp/parser.c:1120

--- Comment #3 from Marek Polacek  ---
Fixed in GCC 10.

[Bug ipa/93707] New: ICE in perlbench from SPEC2017

[fxue at gcc dot gnu.org]

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

Bug ID: 93707
   Summary: ICE in perlbench from SPEC2017
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: fxue at gcc dot gnu.org
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Compiling options "-flto --param ipa-cp-eval-threshold=1" will trigger an ICE
in the GCC and perlbench benchmark in Spec2017.

during IPA pass: cp
lto1: internal compiler error: in find_more_scalar_values_for_callers_subset,
at ipa-cp.c:4709
0x1698187 find_more_scalar_values_for_callers_subset
../.././gcc/ipa-cp.c:4709
0x169f7d3 decide_about_value
../.././gcc/ipa-cp.c:5490
0x169fdc3 decide_whether_version_node
../.././gcc/ipa-cp.c:5537
0x169fdc3 ipcp_decision_stage
../.././gcc/ipa-cp.c:5718
0x169fdc3 ipcp_driver
../.././gcc/ipa-cp.c:5901

[Bug testsuite/93697] pr93661.c does not warn on (32-bit) powerpc-linux

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org

--- Comment #4 from Martin Sebor  ---
The warning is issued inconsistently because the function is sometimes
eliminated by DSE (ILP32 apparently) and sometimes it isn't (LP64).

[Bug c++/88819] ICE (segfault) when compiling C++ code with -std=c++2a

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |10.0

--- Comment #2 from Marek Polacek  ---
Fixed by r10-1975-g59febe0ece37bedab7f42ae51b9f2b7a372d2950, will add the test.

[Bug ipa/93707] ICE in perlbench from SPEC2017

[fxue at gcc dot gnu.org]

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

fxue at gcc dot gnu.org changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-12
   Assignee|unassigned at gcc dot gnu.org  |fxue at gcc dot gnu.org
 Ever confirmed|0   |1

[Bug ipa/93707] ICE in perlbench from SPEC2017

[fxue at gcc dot gnu.org]

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

--- Comment #1 from fxue at gcc dot gnu.org ---
Created attachment 47825
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47825&action=edit
A simplified case

[Bug ipa/93707] ICE in perlbench from SPEC2017

[fxue at gcc dot gnu.org]

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

--- Comment #2 from fxue at gcc dot gnu.org ---
For a self-recursive function, a for-all-contexts clone could generate an edge
whose callee is not the function. Thus, to check whether an edge stands for a
recursive call during cloning, we should not use ordinary way of comparing
caller and callee of the edge.

[Bug c++/88819] ICE (segfault) when compiling C++ code with -std=c++2a

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:54947e4db0a98a9190bab263e6ae539065ac52c5

commit r10-6595-g54947e4db0a98a9190bab263e6ae539065ac52c5
Author: Marek Polacek 
Date:   Wed Feb 12 11:20:07 2020 -0500

c++: Add new test [PR88819]

Fixed by r10-1975-g59febe0ece37bedab7f42ae51b9f2b7a372d2950.

2020-02-12  Marek Polacek  

PR c++/88819
* g++.dg/cpp2a/nontype-class32.C: New test.

[Bug c++/88819] ICE (segfault) when compiling C++ code with -std=c++2a

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug c++/89953] ICE in nothrow_spec_p, at cp/except.c:1244

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #18 from Marek Polacek  ---
Fixed by r10-2274-gd40e36310722e63675d62711cad7d25393836a00.  Not including the
test because it's kinda large.

[Bug middle-end/93708] New: missing warning on memset overflow with transposed arguments

[msebor at gcc dot gnu.org]

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

Bug ID: 93708
   Summary: missing warning on memset overflow with transposed
arguments
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC diagnoses some suspicious memset calls whose last two arguments look like
they may have been transposed by -Wmemset-transposed-args just as long as the
last argument is zero.

But it doesn't diagnose other similarly suspicious calls with a non-zero last
argument.  What's more, it silently folds away such calls even if they write
past the end of the object, replacing them with stores to the object itself (if
possible).  Folding buffer overflows away may be a reasonable strategy in some
cases but it's certainly the wrong thing to do with no warning in cases where
the in-bounds store most likely ends up setting the data to the wrong
(transposed) value.

The buffer overflow here should be diagnosed regardless of whether or not it's
eliminated.  In addition, it might be worth to also consider enhancing
-Wmemset-transposed-args to diagnose even calls with a non-zero last argument.

$ cat z.c && gcc -O2 -S -Wall -Wextra -Wpedantic
-fdump-tree-optimized=/dev/stdout z.c
void f (int, ...);

struct S { int x, y, z; };

void f0 (void)
{
  struct S *p = __builtin_alloca (sizeof *p);

  __builtin_memset (p, sizeof *p, 0);// -Wmemset-transposed-args
  f (p->x, p->y, p->z);  // missing -Wuninitialized
}

void f1 (void)
{
  struct S s;
  __builtin_memset (&s, sizeof s, -1);   // missing warning
  f (s.x, s.y, s.z);
}
z.c: In function ‘f0’:
z.c:9:3: warning: ‘memset’ used with constant zero length parameter; this could
be due to transposed parameters [-Wmemset-transposed-args]
9 |   __builtin_memset (p, sizeof *p, 0);// -Wmemset-transposed-args
  |   ^~~~

;; Function f0 (f0, funcdef_no=0, decl_uid=1936, cgraph_uid=1, symbol_order=0)

f0 ()
{
  struct S * p;
  int _1;
  int _2;
  int _3;

   [local count: 1073741824]:
  p_6 = __builtin_alloca (12);
  _1 = p_6->z;
  _2 = p_6->y;
  _3 = p_6->x;
  f (_3, _2, _1);
  return;

}



;; Function f1 (f1, funcdef_no=1, decl_uid=1940, cgraph_uid=2, symbol_order=1)

f1 ()
{
   [local count: 1073741824]:
  f (202116108, 202116108, 202116108); [tail call]
  return;

}

[Bug target/93709] New: [10 regression] fortran.dg/minlocval_4.f90 fails on power 9 after r10-4160

[seurer at gcc dot gnu.org]

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

Bug ID: 93709
   Summary: [10 regression] fortran.dg/minlocval_4.f90 fails on
power 9 after r10-4160
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:cf20d00ca1ae5a0da9b329896d7b51e55381bdd7, r10-4160

fortran.dg/maxlocval_4.f90 also fails.  This only happens on power 9.

Executing on host:
/home3/seurer/gcc/git/build/gcc-test2/gcc/testsuite/gfortran/../../gfortran
-B/home3/seurer/gcc/git/build/gcc-test2/gcc/testsuite/gfortran/../../
-B/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/minlocval_4.f90   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never-O2   -pedantic-errors 
-B/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libatomic/.libs
-B/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
 -lm  -o ./minlocval_4.exe(timeout = 300)
spawn -ignore SIGHUP
/home3/seurer/gcc/git/build/gcc-test2/gcc/testsuite/gfortran/../../gfortran
-B/home3/seurer/gcc/git/build/gcc-test2/gcc/testsuite/gfortran/../../
-B/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gfortran.dg/minlocval_4.f90
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O2 -pedantic-errors
-B/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs
-L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libatomic/.libs
-B/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-L/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs
-lm -o ./minlocval_4.exe
PASS: gfortran.dg/minlocval_4.f90   -O2  (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libatomic/.libs:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test2/gcc:.:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libgfortran/.libs:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libatomic/.libs:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs:/home3/seurer/gcc/git/build/gcc-test2/powerpc64le-unknown-linux-gnu/./libquadmath/.libs:/home/seurer/gcc/git/build/gcc-test2/gcc:/home/seurer/gcc/git/build/gcc-test2/./gmp/.libs:/home/seurer/gcc/git/build/gcc-test2/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-test2/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test2/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-test2/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test2/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-test2/./isl/.libs:/home/seurer/gcc/git/build/gcc-test2/./prev-isl/.libs
Execution timeout is: 300
spawn [open ...]
Note: The following floating-point exceptions are signalling: IEEE_INVALID_FLAG
IEEE_DIVIDE_BY_ZERO
STOP 70
FAIL: gfortran.dg/minlocval_4.f90   -O2  execution test

[Bug c++/93710] New: poor location in diagnostics of messages about array initializers

[msebor at gcc dot gnu.org]

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

Bug ID: 93710
   Summary: poor location in diagnostics of messages about array
initializers
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

With one exception, the warnings for the invalid array initializers are not
associated with their location: they all point to the closing brace of the
initializer-list.  When the list consists of many elements that can make it
quite difficult to understand which among them is causing the problem.

$ cat u.C && gcc -S -Wall -Wextra -Wpedantic u.C
struct A { A (int); A (char*); int i; };

int x;

A a1[] = {
  0L,
  &x,   // accurate location
  sizeof (A),
  __builtin_offsetof (A, i)
};
u.C:10:1: error: conversion from ‘long int’ to ‘A’ is ambiguous
   10 | };
  | ^
u.C:1:21: note: candidate: ‘A::A(char*)’
1 | struct A { A (int); A (char*); int i; };
  | ^
u.C:1:12: note: candidate: ‘A::A(int)’
1 | struct A { A (int); A (char*); int i; };
  |^
u.C:7:3: error: invalid conversion from ‘int*’ to ‘int’ [-fpermissive]
7 |   &x,   // accurate location
  |   ^~
  |   |
  |   int*
u.C:1:15: note:   initializing argument 1 of ‘A::A(int)’
1 | struct A { A (int); A (char*); int i; };
  |   ^~~
u.C:10:1: error: conversion from ‘long unsigned int’ to ‘A’ is ambiguous
   10 | };
  | ^
u.C:1:21: note: candidate: ‘A::A(char*)’
1 | struct A { A (int); A (char*); int i; };
  | ^
u.C:1:12: note: candidate: ‘A::A(int)’
1 | struct A { A (int); A (char*); int i; };
  |^

[Bug c++/93710] poor location in diagnostics of messages about array initializers

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-12
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1

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

[Bug middle-end/61577] [4.9.0 Regression] can't compile on hp-ux v3 ia64

[dave.anglin at bell dot net]

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

--- Comment #162 from dave.anglin at bell dot net ---
On 2020-02-12 10:38 a.m., peter.bisroev at groundlabs dot com wrote:
> The exact HP linker errors from linking cc1, cc1plus and lto1 were (I was
> compiling in parallel):
> 
> ld: The value 0xfdc6eaf0 does not fit when applying the relocation
> PCREL21B for symbol ".text" at offset 0x102 in section index 51 of file
> libbackend.a[sancov.o]

The value doesn't fit in 21 bits.

The relocations are introduced by the assembler.  You might check if the HP
assembler can assemble sancov.s and see what type of relocations are used.
You can run readelf on .o to see relocations.

It looks like the problem is branches to weak functions.  For example,

    br.call.sptk.many b0 =
_Z16tree_class_checkPK9tree_node15tree_code_classPKciS4_#

    .section   
.gnu.linkonce.t._Z16tree_class_checkPK9tree_node15tree_code_classPKciS4_,"ax",@progbits
    .align 16
    .weak   _Z16tree_class_checkPK9tree_node15tree_code_classPKciS4_#
    .proc _Z16tree_class_checkPK9tree_node15tree_code_classPKciS4_#
_Z16tree_class_checkPK9tree_node15tree_code_classPKciS4_:

Probably, the error arises when the call resolves to an instance that's a long
way away.  I think
we need to find out why 21-bit branch is being used.

[Bug c++/92010] [8/9/10 Regression] gcc internal error since 8x on warning write-strings

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
template 
void foo(const T t = "; ")
{
}

int main()
{
  foo ();
}

$ ./cc1plus -quiet 92010.C
92010.C: In function ‘int main()’:
92010.C:8:8: internal compiler error: in tsubst_default_argument, at
cp/pt.c:13356
8 |   foo ();
  |^
0xbc86f1 tsubst_default_argument(tree_node*, int, tree_node*, tree_node*, int)
/home/mpolacek/src/gcc/gcc/cp/pt.c:13356
0x938263 convert_default_arg(tree_node*, tree_node*, tree_node*, int, int)
/home/mpolacek/src/gcc/gcc/cp/call.c:8044
0x93b170 build_over_call
/home/mpolacek/src/gcc/gcc/cp/call.c:8751
0x92b2ca build_new_function_call(tree_node*, vec**, int)
/home/mpolacek/src/gcc/gcc/cp/call.c:4587
0xc3b4ce finish_call_expr(tree_node*, vec**, bool,
bool, int)
/home/mpolacek/src/gcc/gcc/cp/semantics.c:2671
0xb2cdd1 cp_parser_postfix_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:7427
0xb2f71e cp_parser_unary_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:8525
0xb30b88 cp_parser_cast_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9416
0xb30c75 cp_parser_binary_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9519
0xb31aba cp_parser_assignment_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9824
0xb31e71 cp_parser_expression
/home/mpolacek/src/gcc/gcc/cp/parser.c:9992
0xb35acb cp_parser_expression_statement
/home/mpolacek/src/gcc/gcc/cp/parser.c:11642
0xb35398 cp_parser_statement
/home/mpolacek/src/gcc/gcc/cp/parser.c:11438
0xb3603f cp_parser_statement_seq_opt
/home/mpolacek/src/gcc/gcc/cp/parser.c:11789
0xb35f23 cp_parser_compound_statement
/home/mpolacek/src/gcc/gcc/cp/parser.c:11739
0xb4bcd6 cp_parser_function_body
/home/mpolacek/src/gcc/gcc/cp/parser.c:22981
0xb4bffa cp_parser_ctor_initializer_opt_and_function_body
/home/mpolacek/src/gcc/gcc/cp/parser.c:23032
0xb57904 cp_parser_function_definition_after_declarator
/home/mpolacek/src/gcc/gcc/cp/parser.c:28880
0xb5772b cp_parser_function_definition_from_specifiers_and_declarator
/home/mpolacek/src/gcc/gcc/cp/parser.c:28796
0xb4700e cp_parser_init_declarator
/home/mpolacek/src/gcc/gcc/cp/parser.c:20596

[Bug c++/93710] poor location in diagnostics of messages about array initializers

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
With

--- a/gcc/cp/call.c
+++ b/gcc/cp/call.c
@@ -4172,8 +4172,9 @@ build_user_type_conversion_1 (tree totype, tree expr, int
flags,
   if (complain & tf_error)
{
  auto_diagnostic_group d;
- error ("conversion from %qH to %qI is ambiguous",
-fromtype, totype);
+ error_at (EXPR_LOCATION (expr),
+   "conversion from %qH to %qI is ambiguous",
+   fromtype, totype);
  print_z_candidates (location_of (expr), candidates);
}

we print

93710.C:6:3: error: conversion from ‘long int’ to ‘A’ is ambiguous
6 |   0L,
  |   ^~
93710.C:1:21: note: candidate: ‘A::A(char*)’
1 | struct A { A (int); A (char*); int i; };
  | ^
93710.C:1:12: note: candidate: ‘A::A(int)’
1 | struct A { A (int); A (char*); int i; };
  |^

which seems much better.

[Bug c++/93710] poor location in diagnostics of messages about array initializers

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
For the whole testcase with the patch we generate:

93710-2.C:6:3: error: conversion from ‘long int’ to ‘A’ is ambiguous
6 |   0L,
  |   ^~
93710-2.C:1:21: note: candidate: ‘A::A(char*)’
1 | struct A { A (int); A (char*); int i; };
  | ^
93710-2.C:1:12: note: candidate: ‘A::A(int)’
1 | struct A { A (int); A (char*); int i; };
  |^
93710-2.C:7:3: error: invalid conversion from ‘int*’ to ‘int’ [-fpermissive]
7 |   &x,   // accurate location
  |   ^~
  |   |
  |   int*
93710-2.C:1:15: note:   initializing argument 1 of ‘A::A(int)’
1 | struct A { A (int); A (char*); int i; };
  |   ^~~
93710-2.C:9:23: error: conversion from ‘long unsigned int’ to ‘A’ is ambiguous
9 |   __builtin_offsetof (A, i)
  |   ^
93710-2.C:1:21: note: candidate: ‘A::A(char*)’
1 | struct A { A (int); A (char*); int i; };
  | ^
93710-2.C:1:12: note: candidate: ‘A::A(int)’
1 | struct A { A (int); A (char*); int i; };
  |^

Testing pending.

[Bug c++/80329] Poor location for array bounds warning

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
   Last reconfirmed||2020-2-12
 CC||msebor at gcc dot gnu.org
 Resolution|--- |DUPLICATE
  Known to fail||10.0, 7.3.0, 8.3.0, 9.2.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  These -Warray-bounds warnings don't include the inlining context. 
I posted a patch some time ago to add it
(https://gcc.gnu.org/ml/gcc-patches/2018-07/msg01286.html).  With it, the
output looks like that below.  I didn't commit the whole patch because it
caused some minor regressions in the test suite: the underlining of array
subscripts in references of multi-dimensional arrays becomes less accurate.  It
might be worth revisiting that decision since the lack of the inlining context
seems like more of a problem than the other issue.

I haven't checked if the inlining context below includes all the inlined
functions.  I've seen cases where it doesn't and I'm not sure what could be
done about those.

Anyway, I'll assume the lack of the inlining context is what you were referring
to so I'll resolve this as a dupe of pr86650.  If you had something else in
mind please reopen this (and say what).

Another thing still missing here even with the inlining context is a note
pointing to the referenced object.  The warning does include that note in many
cases but in this case the access is to the string literal which has no
location associated with it. 

In file included from
/build/gcc-trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/string:56,
 from pr80329.C:1:
In member function ‘void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_construct(_InIterator, _InIterator, std::forward_iterator_tag)
[with _FwdIterator = const char*; _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]’,
inlined from ‘void std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::_M_construct(_InIterator, _InIterator) [with _InIterator = const
char*; _CharT = char; _Traits = std::char_traits; _Alloc =
std::allocator]’ at
/build/gcc-trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:247:23,
inlined from ‘std::__cxx11::basic_string<_CharT, _Traits,
_Alloc>::basic_string(const _CharT*, std::__cxx11::basic_string<_CharT,
_Traits, _Alloc>::size_type, const _Alloc&) [with _CharT = char; _Traits =
std::char_traits; _Alloc = std::allocator]’ at
/build/gcc-trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.h:513:21,
inlined from ‘int main()’ at pr80329.C:5:22:
/build/gcc-trunk/x86_64-pc-linux-gnu/libstdc++-v3/include/bits/basic_string.tcc:225:25:
warning: array subscript 2 is outside array bounds of ‘const char [1]’
[-Warray-bounds]
  225 |{ this->_S_copy_chars(_M_data(), __beg, __end); }
  |  ~~~^

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

[Bug tree-optimization/86650] -Warray-bounds missing inlining context

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||redi at gcc dot gnu.org

--- Comment #6 from Martin Sebor  ---
*** Bug 80329 has been marked as a duplicate of this bug. ***

[Bug middle-end/93582] [10 Regression] -Warray-bounds gives error: array subscript 0 is outside array bounds of struct E[1]

[jakub at gcc dot gnu.org]

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

--- Comment #24 from Jakub Jelinek  ---
Created attachment 47826
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47826&action=edit
gcc10-pr93582.patch

Untested patch for the first step, going to test this now on both little and
big endian.  If that works, my preference would be try to deal with the
composition from multiple stores without byte aligned everything next, and only
then start thinking about factoring stuff out etc.

[Bug c++/93549] [10 Regression] ICE / Segfault in constexpr expansion involving vector_size(16) short COND_EXPR

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug fortran/36725] g0 edit descriptor: Missing compile-time checking for invalid g0.d

[thenlich at gcc dot gnu.org]

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

Thomas Henlich  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 CC||thenlich at gcc dot gnu.org
 Blocks||90374
 Resolution|FIXED   |---

--- Comment #8 from Thomas Henlich  ---
This bug is now apparently invalid.


"C1007 (R1007) For the G edit descriptor, d shall be specified if w is not
zero"

(There is no "and only if")

The compiler does the right thing now (good).

gfortran.dg/fmt_go_4.f08 should be fixed to check for standard-conforming
run-time output, which is currently broken by an incomplete fix for bug 90374.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
[Bug 90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0
edit descriptors for output

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

[thenlich at gcc dot gnu.org]

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

Bug 36725 Summary: g0 edit descriptor: Missing compile-time checking for 
invalid  g0.d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36725

   What|Removed |Added

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

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[joseph at codesourcery dot com]

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

--- Comment #26 from joseph at codesourcery dot com  ---
Adding the support for C++ would also be a matter for people who care 
about this platform that few people do now care about.

I suspect that if you force the back-end insn pattern effects of 
standards-conforming excess precision to on (i.e. stop the back end 
claiming to have SFmode / DFmode operations that use x87 floating point), 
that will still work for languages without special support, because of the 
optabs code that handles expanding using a wiser mode as necessary (even 
if not safe) - but while that would get XFmode spills, the GIMPLE code 
would still think some operations were being carried out in SFmode / 
DFmode, so without the front-end support you wouldn't eliminate optimizer 
anomalies.

[Bug c/85957] i686: Integers appear to be different, but compare as equal

[vincent-gcc at vinc17 dot net]

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

--- Comment #27 from Vincent Lefèvre  ---
(In reply to Rich Felker from comment #25)
> I think standards-conforming excess precision should be forced on, and added
> to C++; there are just too many dangerous ways things can break as it is
> now.

+1

People who currently build x87 software could choose between different
solutions, such as switching to SSE if possible, switching back to "fast"
excess precision if speed is really important and they know that it will work
(this requires testing). They could even try -ffast-math (some of its
optimizations are actually less dangerous than "fast" excess precision)...

[Bug c++/93191] Conversions to arrays of unknown bound P0388 Fails for variadic args

[wjwray at gmail dot com]

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

--- Comment #2 from Will Wray  ---
Actually, the issue now appears to be not with variadic args directly but with
deduction (variadic Args are necessarily deduced, whether via template Arg or
auto placeholder).

So, for single arg, this works with explicit type (i.e. without deduction)
(works on GCC trunk, not Clang trunk as P0388 isn't implemented there yet)
(I thought I'd tested this single-arg case before submitting; maybe not):

void cat(char const(&cstr)[]) { puts(cstr); }
int main() {
cat("Hello");
}

But, changing char -> auto placeholder, this fails:

void cat(auto const(&cstr)[]) { puts(cstr); }
int main() {
cat("Hello");  // error: no matching function
}

So - "Not quite sure if this is valid"; that's the question...

Can check / ask here I guess:

https://github.com/cplusplus/draft/pull/3090
https://github.com/cplusplus/draft/commit/d910b2d9361c3ed1f908f77c8f76bd3e27093c90

[Bug c++/93711] New: ICE: [[no_unique_address] when constructing via template helper

[eteran at alum dot rit.edu]

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

Bug ID: 93711
   Summary: ICE: [[no_unique_address] when constructing via
template helper
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eteran at alum dot rit.edu
  Target Milestone: ---

This is a little hard to explain clearly, but I'll do my best.

I have a container class that I want to make properly allocator aware and ran
into this ICE. When I don't use allocator_traits, and directly copy the
allocator, it works just fine. But once I introduce the usage of
allocator_traits::select_on_container_copy_construction, I get an ICE.

Example A (Works Properly):


#include 

template >
struct MyType {

MyType(const MyType &other)
: a_(other.a_) {
}

MyType(const A &a = A())
: a_(a) {
}

T *p_;
[[no_unique_address]] A a_;
};

int main() {
MyType x;
MyType y(x);
}

Example B (ICE):


#include 

template >
struct MyType {

MyType(const MyType &other)
:
a_(std::allocator_traits::select_on_container_copy_construction(other.a_)) {
}

MyType(const A &a = A())
:
a_(std::allocator_traits::select_on_container_copy_construction(a)) {
}

T *p_;
[[no_unique_address]] A a_;
};

int main() {
MyType x;
MyType y(x);
}

Both cases work correctly if I remove [[no_unique_address], so it seems to be
an interaction between [[no_unique_address]] and
a_(std::allocator_traits::select_on_container_copy_construction(a)).


Here is the complete backtrace for the failing example:


g++ -std=c++17 test.cpp -o test
during RTL pass: expand
test.cpp: In constructor ‘MyType::MyType(const A&) [with T = int; A =
std::allocator]’:
test.cpp:12:74: internal compiler error: in assign_temp, at function.c:982
   12 |   :
a_(std::allocator_traits::select_on_container_copy_construction(a)) {
  |
 ^
0x59a442 assign_temp(tree_node*, int, int)
   
/var/tmp/portage/sys-devel/gcc-9.2.0-r2/work/gcc-9.2.0/gcc/function.c:982
0x7c050f expand_call(tree_node*, rtx_def*, int)
/var/tmp/portage/sys-devel/gcc-9.2.0-r2/work/gcc-9.2.0/gcc/calls.c:3459
0x8c4a2d expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/var/tmp/portage/sys-devel/gcc-9.2.0-r2/work/gcc-9.2.0/gcc/expr.c:11033
0x8d297b expand_normal
/var/tmp/portage/sys-devel/gcc-9.2.0-r2/work/gcc-9.2.0/gcc/expr.h:285
0x8d297b store_field
/var/tmp/portage/sys-devel/gcc-9.2.0-r2/work/gcc-9.2.0/gcc/expr.c:7022
0x8cff37 expand_assignment(tree_node*, tree_node*, bool)
/var/tmp/portage/sys-devel/gcc-9.2.0-r2/work/gcc-9.2.0/gcc/expr.c:5296
0x7cc3f0 expand_call_stmt
   
/var/tmp/portage/sys-devel/gcc-9.2.0-r2/work/gcc-9.2.0/gcc/cfgexpand.c:2722
0x7cc3f0 expand_gimple_stmt_1
   
/var/tmp/portage/sys-devel/gcc-9.2.0-r2/work/gcc-9.2.0/gcc/cfgexpand.c:3691
0x7cc3f0 expand_gimple_stmt
   
/var/tmp/portage/sys-devel/gcc-9.2.0-r2/work/gcc-9.2.0/gcc/cfgexpand.c:3850
0x7d1237 expand_gimple_basic_block
   
/var/tmp/portage/sys-devel/gcc-9.2.0-r2/work/gcc-9.2.0/gcc/cfgexpand.c:5890
0x7d35d7 execute
   
/var/tmp/portage/sys-devel/gcc-9.2.0-r2/work/gcc-9.2.0/gcc/cfgexpand.c:6513
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug rtl-optimization/93565] [9/10 regression] Combine duplicates instructions

[cvs-commit at gcc dot gnu.org]

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

--- Comment #15 from CVS Commits  ---
The master branch has been updated by Wilco Dijkstra :

https://gcc.gnu.org/g:5bfc8303ffe2d86e938d45f13cd99a39469dac4f

commit r10-6598-g5bfc8303ffe2d86e938d45f13cd99a39469dac4f
Author: Wilco Dijkstra 
Date:   Wed Feb 12 18:23:21 2020 +

[AArch64] Set ctz rtx_cost (PR93565)

Combine sometimes behaves oddly and duplicates ctz to remove an unnecessary
sign extension.  Avoid this by setting the cost for ctz to be higher than
that of a simple ALU instruction.  Deepsjeng performance improves by ~0.6%.

gcc/
PR rtl-optimization/93565
* config/aarch64/aarch64.c (aarch64_rtx_costs): Add CTZ costs.

testsuite/
PR rtl-optimization/93565
* gcc.target/aarch64/pr93565.c: New test.

[Bug c++/93191] Conversions to arrays of unknown bound P0388 Fails for variadic args

[mpolacek at gcc dot gnu.org]

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

--- Comment #3 from Marek Polacek  ---
Thanks Will.  I think I'll email CWG and ask about it.

[Bug rtl-optimization/93658] [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #8 from Jakub Jelinek  ---
On the #c7 testcase, this started with
r8-6072-ga3a821c903c9fa2288712d31da2038d0297babcb (so I wonder why this isn't a
8/9/10 Regression).

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

[eteran at alum dot rit.edu]

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

--- Comment #1 from Evan Teran  ---
As a follow-up, it appears that the optimization level is a factor. I only get
the ICE in my builds which don't pass a -O flag.

Here's a live example that can be experimented with:

https://godbolt.org/z/zAEcQd

Adding -Og, -O1, -O2, etc... all make it suddenly work.

[Bug c++/93710] poor location in diagnostics of messages about array initializers

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug c++/93712] New: [10 Regression] ICE in convert_like_real, at cp/call.c:7466

[gs...@t-online.de]

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

Bug ID: 93712
   Summary: [10 Regression] ICE in convert_like_real, at
cp/call.c:7466
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20191006 and 20191013 :


$ cat z1.cc
int f (int const (&)[])
  { return f({1, " "}); }


$ g++-10-20200209 -c z1.cc
z1.cc: In function 'int f(const int (&)[])':
z1.cc:2:22: internal compiler error: in convert_like_real, at cp/call.c:7466
2 |   { return f({1, " "}); }
  |  ^
0x678e40 convert_like_real
../../gcc/cp/call.c:7466
0x67735f convert_like_real
../../gcc/cp/call.c:7344
0x6771e6 convert_like_real
../../gcc/cp/call.c:7578
0x6798b8 build_over_call
../../gcc/cp/call.c:8736
0x67d26a build_new_function_call(tree_node*, vec**, int)
../../gcc/cp/call.c:4587
0x8bb4cc finish_call_expr(tree_node*, vec**, bool,
bool, int)
../../gcc/cp/semantics.c:2671
0x80a8e6 cp_parser_postfix_expression
../../gcc/cp/parser.c:7427
0x81457d cp_parser_unary_expression
../../gcc/cp/parser.c:8525
0x7e4f7f cp_parser_cast_expression
../../gcc/cp/parser.c:9416
0x7e5821 cp_parser_binary_expression
../../gcc/cp/parser.c:9518
0x7e74f0 cp_parser_assignment_expression
../../gcc/cp/parser.c:9822
0x7e7944 cp_parser_expression
../../gcc/cp/parser.c:9992
0x7fa625 cp_parser_jump_statement
../../gcc/cp/parser.c:13046
0x7fa625 cp_parser_statement
../../gcc/cp/parser.c:11316
0x7fb758 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:11789
0x7fb837 cp_parser_compound_statement
../../gcc/cp/parser.c:11739
0x8177b0 cp_parser_function_body
../../gcc/cp/parser.c:22984
0x8177b0 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:23035
0x81a296 cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:28882
0x81b05e cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:28798

[Bug c++/93713] New: [10 Regression] ICE in equivalently_constrained, at cp/constraint.cc:2949

[gs...@t-online.de]

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

Bug ID: 93713
   Summary: [10 Regression] ICE in equivalently_constrained, at
cp/constraint.cc:2949
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20191006 and 20191013 :


$ cat z1.cc
template  T bar ();
void bar () {}
using :: bar;


$ g++-9 -c z1.cc
$
$ g++-10-20200209 -c z1.cc
z1.cc:3:10: internal compiler error: in equivalently_constrained, at
cp/constraint.cc:2949
3 | using :: bar;
  |  ^~~
0x65b2f8 equivalently_constrained(tree_node*, tree_node*)
../../gcc/cp/constraint.cc:2949
0x6d57a6 do_nonmember_using_decl
../../gcc/cp/name-lookup.c:3938
0x6ddbba finish_nonmember_using_decl(tree_node*, tree_node*)
../../gcc/cp/name-lookup.c:5141
0x7154ca cp_parser_using_declaration
../../gcc/cp/parser.c:19862
0x721ff9 cp_parser_declaration
../../gcc/cp/parser.c:13377
0x722771 cp_parser_translation_unit
../../gcc/cp/parser.c:4731
0x722771 c_parse_file()
../../gcc/cp/parser.c:43711
0x7e52d0 c_common_parse_file()
../../gcc/c-family/c-opts.c:1186

[Bug fortran/93714] New: [8/9/10 Regression] ICE in gfc_check_same_strlen, at fortran/check.c:1253

[gs...@t-online.de]

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

Bug ID: 93714
   Summary: [8/9/10 Regression] ICE in gfc_check_same_strlen, at
fortran/check.c:1253
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to r6 :


$ cat z1.f90
program p
   character((1.)) :: a
   character, pointer :: b => a
end


$ cat z2.f90
program p
   character((9.)), target :: a
   character(:), pointer :: b => a
end


$ gfortran-5 -c z1.f90   
z1.f90:3:31:

character, pointer :: b => a
   1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
z1.f90:2:13:

character((1.)) :: a
 1
Error: Expression at (1) must be of INTEGER type, found REAL


$ gfortran-10-20200209 -c z1.f90
f951: internal compiler error: Segmentation fault
0xbae4bf crash_signal
../../gcc/toplev.c:328
0x6201b2 gfc_check_same_strlen(gfc_expr const*, gfc_expr const*, char const*)
../../gcc/fortran/check.c:1253
0x655440 gfc_check_pointer_assign(gfc_expr*, gfc_expr*, bool, bool)
../../gcc/fortran/expr.c:4227
0x655a4d gfc_check_assign_symbol(gfc_symbol*, gfc_component*, gfc_expr*)
../../gcc/fortran/expr.c:4418
0x63506e add_init_expr_to_sym
../../gcc/fortran/decl.c:1901
0x63eec0 variable_decl
../../gcc/fortran/decl.c:2939
0x63eec0 gfc_match_data_decl()
../../gcc/fortran/decl.c:6120
0x6a20f3 match_word
../../gcc/fortran/parse.c:65
0x6a20f3 decode_statement
../../gcc/fortran/parse.c:376
0x6a3b3a next_free
../../gcc/fortran/parse.c:1279
0x6a3b3a next_statement
../../gcc/fortran/parse.c:1511
0x6a518b parse_spec
../../gcc/fortran/parse.c:3922
0x6a7f5c parse_progunit
../../gcc/fortran/parse.c:5851
0x6a9639 gfc_parse_file()
../../gcc/fortran/parse.c:6392
0x6f42bf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug fortran/93715] New: [9/10 Regression] ICE in gfc_trans_auto_array_allocation, at fortran/trans-array.c:6320

[gs...@t-online.de]

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

Bug ID: 93715
   Summary: [9/10 Regression] ICE in
gfc_trans_auto_array_allocation, at
fortran/trans-array.c:6320
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20180819 and 20180826 :


$ cat z1.f90
program p
   integer :: a, b[*]
   read (1, *, asynchronous='yes') a, b
end


$ gfortran-9-20180819 -c z1.f90 -fcoarray=lib
$ gfortran-9-20180819 -c z1.f90 -fcoarray=single
$
$ gfortran-10-20200209 -c z1.f90 -fcoarray=lib
$ gfortran-10-20200209 -c z1.f90 -fcoarray=single
z1.f90:2:0:

2 |integer :: a, b[*]
  |
internal compiler error: in gfc_trans_auto_array_allocation, at
fortran/trans-array.c:6320
0x704363 gfc_trans_auto_array_allocation(tree_node*, gfc_symbol*,
gfc_wrapped_block*)
../../gcc/fortran/trans-array.c:6320
0x71e1d7 gfc_trans_deferred_vars(gfc_symbol*, gfc_wrapped_block*)
../../gcc/fortran/trans-decl.c:4838
0x720f48 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.c:6940
0x6a9d06 translate_all_program_units
../../gcc/fortran/parse.c:6306
0x6a9d06 gfc_parse_file()
../../gcc/fortran/parse.c:6545
0x6f42bf gfc_be_parse_file
../../gcc/fortran/f95-lang.c:210

[Bug middle-end/93576] [8/9/10 Regression] internal compiler error: Segmentation fault (in gimplify.c)

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

   Keywords|error-recovery, |ice-on-valid-code
   |ice-on-invalid-code |
   Priority|P3  |P2
 CC||jakub at gcc dot gnu.org
   Target Milestone|10.0|8.4
Summary|[10 Regression] internal|[8/9/10 Regression]
   |compiler error: |internal compiler error:
   |Segmentation fault (in  |Segmentation fault (in
   |gimplify.c) |gimplify.c)

--- Comment #7 from Jakub Jelinek  ---
Started with r8-6733-gd74641bdd752306ad41b4cd3b2f747ec046cb391
Reduced testcase:
void
foo (void)
{
  int b[] = { 0 };
  (char (*)[(1, 7, 2)]) 0;
}

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

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
 Depends on||93667

--- Comment #2 from Andrew Pinski  ---
Most likely a similar issue as PR 93667.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93667
[Bug 93667] [10 regression] ICE in esra with nested [[no_unique_address]] field

[Bug c++/93712] [10 Regression] ICE in convert_like_real, at cp/call.c:7466

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-12
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |10.0
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Caused by
commit 89e0a492af5bec8ffa2ec5d99c4858df50d22c16
Author: Marek Polacek 
Date:   Wed Oct 9 20:58:00 2019 +

Implement C++20 P0388R4, DR 1307, and DR 330.

so mine.

[Bug c++/93713] [10 Regression] ICE in equivalently_constrained, at cp/constraint.cc:2949

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

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

[Bug fortran/93714] [8/9/10 Regression] ICE in gfc_check_same_strlen, at fortran/check.c:1253

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

   Priority|P3  |P4
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-12
 CC||kargl at gcc dot gnu.org
 Ever confirmed|0   |1
  Known to fail||10.0, 8.3.1, 9.2.1

--- Comment #1 from kargl at gcc dot gnu.org ---
Diff is against svn r280157.

Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 280157)
+++ gcc/fortran/check.c (working copy)
@@ -1244,8 +1244,14 @@ gfc_check_same_strlen (const gfc_expr *a, const gfc_ex
 {
long len_a, len_b;

-   len_a = gfc_var_strlen(a);
-   len_b = gfc_var_strlen(b);
+   if ((a->ts.u.cl && a->ts.u.cl->length
+&& a->ts.u.cl->length->ts.type != BT_INTEGER)
+   || (b->ts.u.cl && b->ts.u.cl->length
+&& b->ts.u.cl->length->ts.type != BT_INTEGER))
+ return false;
+
+   len_a = gfc_var_strlen (a);
+   len_b = gfc_var_strlen (b);

if (len_a == -1 || len_b == -1 || len_a == len_b)
  return true;

[Bug c++/93713] [10 Regression] ICE in equivalently_constrained, at cp/constraint.cc:2949

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
Started with r10-3735-gcb57504a550158913258e5be8ddb991376475efb

commit cb57504a550158913258e5be8ddb991376475efb
Author: Jason Merrill 
Date:   Wed Oct 9 13:20:32 2019 -0400

Update the concepts implementation to conform to C++20.

[Bug c++/93716] New: [feature request] Improve error message for Classes without a default constructor

[volker.weissmann at gmx dot de]

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

Bug ID: 93716
   Summary: [feature request] Improve error message for Classes
without a default constructor
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: volker.weissmann at gmx dot de
  Target Milestone: ---

Consider the following C++ source code:
-
class NoDefaultConstr
{
public:
NoDefaultConstr(int i)
{
(void) i;
}
};
class BadClass
{
public:
NoDefaultConstr obj;
int othervar;
BadClass(int i):
othervar(17)
{
(void) i;
}
};
int main()
{
BadClass abc(123);
}
-
Compilation of the code above should fail. Compiling with g++ main.cpp fails
with the following output:
-
main.cpp: In constructor ‘BadClass::BadClass(int)’:
main.cpp:15:20: error: no matching function for call to
‘NoDefaultConstr::NoDefaultConstr()’
   15 | othervar(17)
  |^
main.cpp:4:5: note: candidate: ‘NoDefaultConstr::NoDefaultConstr(int)’
4 | NoDefaultConstr(int i)
  | ^~~
main.cpp:4:5: note:   candidate expects 1 argument, 0 provided
main.cpp:1:7: note: candidate: ‘constexpr
NoDefaultConstr::NoDefaultConstr(const NoDefaultConstr&)’
1 | class NoDefaultConstr
  |   ^~~
main.cpp:1:7: note:   candidate expects 1 argument, 0 provided
main.cpp:1:7: note: candidate: ‘constexpr
NoDefaultConstr::NoDefaultConstr(NoDefaultConstr&&)’
main.cpp:1:7: note:   candidate expects 1 argument, 0 provided
-
Compiling fails as it should, but it would be nice if the error message would
be a bit more helpful. e.g.:
-
main.cpp: In constructor ‘BadClass::BadClass(int)’:
main.cpp:15:20: error: no matching function for call to
‘NoDefaultConstr::NoDefaultConstr()’
   15 | othervar(17)
  |^
main.cpp:12:23: note: Because of declaration of object ‘obj’
   12 | NoDefaultConstr obj;
  |
main.cpp:4:5: note: candidate: ‘NoDefaultConstr::NoDefaultConstr(int)’
4 | NoDefaultConstr(int i)
  | ^~~
main.cpp:4:5: note:   candidate expects 1 argument, 0 provided
main.cpp:1:7: note: candidate: ‘constexpr
NoDefaultConstr::NoDefaultConstr(const NoDefaultConstr&)’
1 | class NoDefaultConstr
  |   ^~~
main.cpp:1:7: note:   candidate expects 1 argument, 0 provided
main.cpp:1:7: note: candidate: ‘constexpr
NoDefaultConstr::NoDefaultConstr(NoDefaultConstr&&)’
main.cpp:1:7: note:   candidate expects 1 argument, 0 provided
-
The reason why I do not like gcc's error message is that it never mentions the
line 12 or the variable obj. Clang in comparison mentions both and has imho a
much nicer error message:
-
main.cpp:14:5: error: constructor for 'BadClass' must explicitly initialize the
member 'obj' which does not have a default constructor
BadClass(int i):
^
main.cpp:12:21: note: member is declared here
NoDefaultConstr obj;
^
main.cpp:1:7: note: 'NoDefaultConstr' declared here
class NoDefaultConstr
  ^
-

[Bug fortran/36725] g0 edit descriptor: Missing compile-time checking for invalid g0.d

[thenlich at gcc dot gnu.org]

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

--- Comment #9 from Thomas Henlich  ---
Created attachment 47827
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47827&action=edit
Proposed patch to perform runtime check in fmt_g0_4.f08

This checks ensure that G0.d output is not broken.

[Bug c++/93607] Deprecated alias templates don't produce warnings

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-12
 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84542,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84347,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84318
 Ever confirmed|0   |1
  Known to fail||10.0, 9.2.0

--- Comment #1 from Martin Sebor  ---
Confirmed.  The attribute is poorly specified for templates and doesn't work
very well with them (see also pr84542, pr84347, and pr84318).

[Bug target/93694] Inconsistent grammar in darwin.opt

[roland.illig at gmx dot de]

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

--- Comment #2 from Roland Illig  ---
double space:
> dyld  will


missing word:
> two-level information
should probably be "two-level namespace information"


>  Provided
> (Obsolete after 10.3.9) Set
Shouldn't there be a tab between the words instead of the space?


> -pagezero_size size
The other placeholders are written in , so should this one.

[Bug middle-end/93646] confusing -Wstringop-truncation on strncat where -Wstringop-overflow is expected

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-6600-g0a0de9636d29a378961e4c98a129421229918052
Author: Martin Sebor 
Date:   Wed Feb 12 13:53:49 2020 -0700

PR middle-end/93646 - confusing -Wstringop-truncation on strncat where
-Wstringop-overflow is expected

gcc/ChangeLog:

PR middle-end/93646
* tree-ssa-strlen.c (handle_builtin_stxncpy): Rename...
(handle_builtin_stxncpy_strncat): ...to this.  Change first argument.
Issue only -Wstringop-overflow strncat, never -Wstringop-truncation.
(strlen_check_and_optimize_call): Adjust callee name.

gcc/testsuite/ChangeLog:

PR middle-end/93646
* gcc.dg/Wstringop-overflow-31.c: New test.

[Bug middle-end/88781] [meta-bug] bogus/missing -Wstringop-truncation warnings

[msebor at gcc dot gnu.org]

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

Bug 93646 Summary: confusing -Wstringop-truncation on strncat where 
-Wstringop-overflow is expected
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93646

   What|Removed |Added

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

[Bug middle-end/93646] confusing -Wstringop-truncation on strncat where -Wstringop-overflow is expected

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Patch committed in r10-6600.

[Bug target/93694] Inconsistent grammar in darwin.opt

[roland.illig at gmx dot de]

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

--- Comment #3 from Roland Illig  ---
> (Obsolete, ld_classic only) -sectcreate segname sectname file
segname, sectname and file should be marked as .


> -segprot  max_prot init_prot\tThe protection values are
This like only describes the syntax but doesn't lose a single word about the
effect.


> -segs_read_only_addr address
Missing placeholder.
space-tab.


> Allows specifying
I hope that this option actually _sets_ the address instead of only _allowing_
to set. (2 times)


> Specifies content
That's another case of very unspecific wording. As the German translator I have
no idea what this could mean. This option is documented nowhere. It only
appears in the ChangeLogs, darwin.h and darwin.opt.

[Bug middle-end/93663] [10 Regression] ICE in is_halfway_below, at real.c:5192

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:3f3932a0ec875cb7cca187018f3f8f05f2519d3e

commit r10-6602-g3f3932a0ec875cb7cca187018f3f8f05f2519d3e
Author: Jakub Jelinek 
Date:   Wed Feb 12 22:14:27 2020 +0100

real: Fix roundeven on inf/nan [PR93663]

As can be seen in the testcase, roundeven with inf or nan arguments
ICE because of those asserts where nothing prevents from is_halfway_below
being called with those arguments.

The following patch fixes that by just returning false for rvc_inf/rvc_nan
like it returns for rvc_zero, so that we handle roundeven with all those
values as round.  Inf/NaN are not halfway in between two integers...

2020-02-12  Jakub Jelinek  

PR middle-end/93663
* real.c (is_even): Make static.  Function comment fix.
(is_halfway_below): Make static, don't assert R is not inf/nan,
instead return false for those.  Small formatting fixes.

* gcc.dg/torture/builtin-round-roundeven.c (main): Add tests
for DBL_MAX, inf, their negations and nan.

[Bug middle-end/93663] [10 Regression] ICE in is_halfway_below, at real.c:5192

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

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

[Bug libstdc++/79193] libstdc++ configure incorrectly decides linking works for cross-compiler

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Sandra Loosemore :

https://gcc.gnu.org/g:02ce382cd323097f9d02fbf91e0a3f59ebcd3d30

commit r10-6603-g02ce382cd323097f9d02fbf91e0a3f59ebcd3d30
Author: Sandra Loosemore 
Date:   Wed Feb 12 12:20:15 2020 -0800

Use a non-empty test program to test ability to link.

On bare-metal targets, I/O support is typically provided by a BSP and
requires a linker script and/or hosting library to be specified on the
linker command line.  Linking an empty program with the default linker
script may succeed, however, which confuses libstdc++ configuration
when programs that probe for the presence of various I/O features fail
with link errors.

2020-02-12  Sandra Loosemore  

PR libstdc++/79193
PR libstdc++/88999

config/
* no-executables.m4: Use a non-empty program to test for linker
support.

libgcc/
* configure: Regenerated.

libgfortran/
* configure: Regenerated.

libiberty/
* configure: Regenerated.

libitm/
* configure: Regenerated.

libobjc/
* configure: Regenerated.

libquadmath/
* configure: Regenerated.

libssp/
* configure: Regenerated.

libstdc++v-3/
* configure: Regenerated.

[Bug libstdc++/88999] [9/10 Regression] testcases using in_avail() fail on nios2-elf

[cvs-commit at gcc dot gnu.org]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Sandra Loosemore :

https://gcc.gnu.org/g:02ce382cd323097f9d02fbf91e0a3f59ebcd3d30

commit r10-6603-g02ce382cd323097f9d02fbf91e0a3f59ebcd3d30
Author: Sandra Loosemore 
Date:   Wed Feb 12 12:20:15 2020 -0800

Use a non-empty test program to test ability to link.

On bare-metal targets, I/O support is typically provided by a BSP and
requires a linker script and/or hosting library to be specified on the
linker command line.  Linking an empty program with the default linker
script may succeed, however, which confuses libstdc++ configuration
when programs that probe for the presence of various I/O features fail
with link errors.

2020-02-12  Sandra Loosemore  

PR libstdc++/79193
PR libstdc++/88999

config/
* no-executables.m4: Use a non-empty program to test for linker
support.

libgcc/
* configure: Regenerated.

libgfortran/
* configure: Regenerated.

libiberty/
* configure: Regenerated.

libitm/
* configure: Regenerated.

libobjc/
* configure: Regenerated.

libquadmath/
* configure: Regenerated.

libssp/
* configure: Regenerated.

libstdc++v-3/
* configure: Regenerated.

[Bug rtl-optimization/93658] [9/10 Regression] infinite loop building ghostscript and icu with -O3 on powerpc64le-linux-gnu

[bergner at gcc dot gnu.org]

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

--- Comment #9 from Peter Bergner  ---
(In reply to Jakub Jelinek from comment #8)
> On the #c7 testcase, this started with
> r8-6072-ga3a821c903c9fa2288712d31da2038d0297babcb (so I wonder why this
> isn't a 8/9/10 Regression).

I'm not sure Kelvin's patch is to blame.  I think it's just exposing a latent
issue.

[Bug testsuite/93717] New: [10 Regression] gcc.dg/optimize-bswapsi-2.c fails after it was updated in r10-5832

[seurer at gcc dot gnu.org]

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

Bug ID: 93717
   Summary: [10 Regression] gcc.dg/optimize-bswapsi-2.c fails
after it was updated in r10-5832
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

g:0f507a365777b403cf058ee1208bf41a7363a728, r10-5832

The test case was updated in this change and it now fails on powerpc64 BE. 
Looks like it fails on some other archs, too, from a quick scan of
gcc-testresults.

Executing on host: /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test2/gcc/
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/optimize-bswapsi-2.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never   -O2 -fdump-tree-bswap -S
-o optimize-bswapsi-2.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test2/gcc/
/home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/optimize-bswapsi-2.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -O2 -fdump-tree-bswap -S -o
optimize-bswapsi-2.s
Executing on host: /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test2/gcc/ exceptions_enabled35185.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -fdiagnostics-urls=never  -S -o
exceptions_enabled35185.s(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-test2/gcc/ exceptions_enabled35185.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -fdiagnostics-urls=never -S -o
exceptions_enabled35185.s
exceptions_enabled35185.c: In function 'foo':
exceptions_enabled35185.c:4:7: error: 'throw' undeclared (first use in this
function)
exceptions_enabled35185.c:4:7: note: each undeclared identifier is reported
only once for each function it appears in
exceptions_enabled35185.c:4:12: error: expected ';' before numeric constant
compiler exited with status 1
PASS: gcc.dg/optimize-bswapsi-2.c (test for excess errors)
gcc.dg/optimize-bswapsi-2.c: pattern found 3 times
FAIL: gcc.dg/optimize-bswapsi-2.c scan-tree-dump-times bswap "32 bit load in
target endianness found at" 4
gcc.dg/optimize-bswapsi-2.c: pattern found 4 times
FAIL: gcc.dg/optimize-bswapsi-2.c scan-tree-dump-times bswap "32 bit bswap
implementation found at" 3
testcase /home/seurer/gcc/git/gcc-test2/gcc/testsuite/gcc.dg/dg.exp completed
in 1 seconds

=== gcc Summary ===

# of expected passes1
# of unexpected failures2

[Bug c++/85723] [C++17][DR 1496] __is_trivial intrinsic fails with no trivial non-deleted default c'tor

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #2 from Marek Polacek  ---
This came up again . 
I think I could take a look at it for GCC 11.