[Bug target/93738] [9/10 regression] test case gcc.target/powerpc/20050603-3.c fails

2020-02-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93738

Richard Biener  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |9.3
Summary|[8/9 regression] test case  |[9/10 regression] test case
   |gcc.target/powerpc/20050603 |gcc.target/powerpc/20050603
   |-3.c fails  |-3.c fails

[Bug target/93619] aarch64 target testsuite is so broken with -mcpu=*

2020-02-13 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93619

--- Comment #3 from Andrew Pinski  ---
The target (non-testsuite) part is located at:
https://gcc.gnu.org/ml/gcc-patches/2020-02/msg00837.html

[Bug fortran/92587] Compiler is unable to generate finalization wrapper

2020-02-13 Thread liakhdi at ornl dot gov
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92587

--- Comment #5 from DIL  ---
If this helps, the gcc/gfortran svn repository from 17 Jan 2019 already had
this regression bug while gcc/gfortran 8.2.0 did not. Hopefully this may help
shorten the length of bisection.

[Bug rtl-optimization/66552] Missed optimization when shift amount is result of signed modulus

2020-02-13 Thread helijia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66552

--- Comment #13 from Li Jia He  ---
In this optimization we assume n is either positive or divisible by the nth
power of 2.
So the result of the % is non-negative.  However, it is not reasonable for
translating (a % 32)) to (a & 31).  If a is signed int and value is -1, (a %
32) will get the follow result, (a %  32) = (-1 % 32) = -1. However, (a & 31)
will get the follow result, (a & 31) = -1 & 31 = 31.  This conversion is not
reasonable at this time.

[Bug target/93619] aarch64 target testsuite is so broken with -mcpu=*

2020-02-13 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93619

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-14
  Component|testsuite   |target
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
I have a fix.

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

2020-02-13 Thread crazylht at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93696

Hongtao.liu  changed:

   What|Removed |Added

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

--- Comment #5 from Hongtao.liu  ---
Fixed in GCC10, backport to GCC9

[Bug c++/93675] Starship operator on a hidden friend operator does not work

2020-02-13 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93675

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed.

[Bug libstdc++/92906] [10 regression] FAIL: libstdc++-abi/abi_check

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92906

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

https://gcc.gnu.org/g:994e0ad41529f5518fd013474a657968807d9ca5

commit r10-6630-g994e0ad41529f5518fd013474a657968807d9ca5
Author: Jakub Jelinek 
Date:   Fri Feb 14 00:11:24 2020 +0100

c++: Emit DFP typeinfos even when DFP is disabled [PR92906]

Before Joseph's changes when compiling
libstdc++-v3/libsupc++/fundamental_type_info.cc
we were emitting
_ZTIPDd, _ZTIPDe, _ZTIPDf, _ZTIPKDd, _ZTIPKDe, _ZTIPKDf, _ZTIDd, _ZTIDe,
_ZTIDf
symbols even when DFP wasn't usable, but now we don't and thus those 9
symbols @@CXXABI_1.3.4 are gone from libstdc++.  While nothing could
probably use it (except perhaps dlsym etc.), various tools don't really
like
symbols disappearing from symbol versioned shared libraries with stable
ABI.
Adding those in assembly would be possible, but would be a portability
nightmare (the PR has something Red Hat uses in libstdc++_nonshared.a, but
that
can handle only a handful of linux ELF targets we care about).
So, instead this patch hacks up the FE, so that it emits those, but in a
way
that won't make the DFP types available again on targets that don't support
them.

2020-02-14  Jakub Jelinek  

PR libstdc++/92906
* cp-tree.h (enum cp_tree_index): Add CPTI_FALLBACK_DFLOAT32_TYPE,
CPTI_FALLBACK_DFLOAT64_TYPE and CPTI_FALLBACK_DFLOAT128_TYPE.
(fallback_dfloat32_type, fallback_dfloat64_type,
fallback_dfloat128_type): Define.
* mangle.c (write_builtin_type): Handle fallback_dfloat*_type like
dfloat*_type_node.
* rtti.c (emit_support_tinfos): Emit DFP typeinfos even when dfp
is disabled for compatibility.

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

2020-02-13 Thread peter.bisroev at groundlabs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #176 from Peter Bisroev  ---
(In reply to dave.anglin from comment #174)
> On 2020-02-13 2:44 p.m., dave.anglin at bell dot net wrote:
> > The first thing to note is aCC doesn't use weak.  Instead, it uses COMDAT
> > sections.  Probably, HP ld does support
> > weak but it's unlikely there is support for linkonce sections.  See defines 
> > in
> > config/pa/som.h.  There we implimented
> > one only support using the linker's COMDAT support.
> Is HAVE_COMDAT_GROUP defined in auto-host.h?

For both 4.9.4 and 8.3.0, gcc/auto-host.h contains only one reference to that:

/* Define 0/1 if your assembler and linker support COMDAT groups. */
#ifndef USED_FOR_TARGET
#define HAVE_COMDAT_GROUP 0
#endif


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

2020-02-13 Thread peter.bisroev at groundlabs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #175 from Peter Bisroev  ---
(In reply to dave.anglin from comment #173)
> On 2020-02-13 1:11 p.m., peter.bisroev at groundlabs dot com wrote:
> > If I try to compare this to aCC dump in attachment 47840 [details], I do 
> > not see any
> > calls to weak. Equivalent section to the above dump in gimple-expr.s
> > (_Z18tree_operand_checkPK9tree_nodeiPKciS3_) can be found on line 9007, also
> > gimple-expr.o.objdump on line 2099. I believe the place where with gcc we
> > expect to see a call to tree_operand_length() through PCREL21B reloc, aCC 
> > does
> > similar thing in gimple-expr.s line 9098 (gimple-expr.o.objdump line 2181).
> I looked at the definition and branches to
> _Z18tree_operand_checkPK9tree_nodeiPKciS3_
> in the gimple-expr.s file that you uploaded.
> 
> We have the following:
> 
>     .type   _Z18tree_operand_checkPK9tree_nodeiPKciS3_,@function
>     .global _Z18tree_operand_checkPK9tree_nodeiPKciS3_
> 
>     .size   _Z18tree_operand_checkPK9tree_nodeiPKciS3_, 784
> // Routine [id=0064] ( tree_operand_check )
> 
> // ===
>     .secalias .abe$170.text, ".text"
>     .section .abe$170.text = "axC", "progbits", .abe$comdat0010
>     .align  16
>     .proc   _Z18tree_operand_checkPK9tree_nodeiPKciS3_
> ..L0:
> //  $start  ARid768 =   ;; // A
> 
> ..L2:
> _Z18tree_operand_checkPK9tree_nodeiPKciS3_::
> .prologue
> //  $entry  ARid770, S:r32, S:r33, S:r34, S:r35, S:r36 =  ;; //
> A [tree.h: 3177/1]
> //file/line/col tree.h/3177/1
> .save ar.pfs, r39
>     alloc   r39 = ar.pfs, 5, 4, 5, 0   // M [tree.h: 3177/1]
> 
>     br.ret.dptk.many rp ;; // B [tree.h: 3181/3]
> 
> ..L1:
> //  $end    ;; // A
> 
>     .endp   _Z18tree_operand_checkPK9tree_nodeiPKciS3_
> 
>     nop.m   0  // M
>     nop.i   0  // I
>     nop.m   0  // M
>     nop.m   0  // M
>     br.call.dptk.many rp = _Z18tree_operand_checkPK9tree_nodeiPKciS3_#
> ;; // B [gimple-expr.c: 658/3]
>     add r9 = 0, r8 // M [gimple-expr.c:
> 658/3]
> 
>     .secalias .abe$comdat0010,
> "_Z18tree_operand_checkPK9tree_nodeiPKciS3_"
> 
> The first thing to note is aCC doesn't use weak.  Instead, it uses COMDAT
> sections.  Probably, HP ld does support
> weak but it's unlikely there is support for linkonce sections.  See defines
> in config/pa/som.h.  There we implimented
> one only support using the linker's COMDAT support.
> 
> Regarding the call to _Z18tree_operand_checkPK9tree_nodeiPKciS3_, this is
> preceeded by a bunch of nops.  This is
> probably to allow linker to modify call should it select a different
> instance of _Z18tree_operand_checkPK9tree_nodeiPKciS3_.

Thank you for the explanation Dave!

I have tried playing around with weak using aCC, however even though it accepts
both attribute and pragma (and complains if you misspell "weak"), both compiler
and linker seem to ignore it. But I might have made some mistake there, will
double check tonight.

[Bug middle-end/93505] [8 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og

2020-02-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505

Jakub Jelinek  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
Summary|[8/9 Regression] wrong code |[8 Regression] wrong code
   |or ICE with |or ICE with
   |__builtin_bswap64() and |__builtin_bswap64() and
   |rotation at -Og |rotation at -Og

--- Comment #20 from Jakub Jelinek  ---
Fixed for 9.3+ too.

[Bug target/93418] [9 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav

2020-02-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #12 from Jakub Jelinek  ---
Fixed for 9.3+ too.

[Bug rtl-optimization/93402] [8 Regression] Wrong code when returning padded struct

2020-02-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93402

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9 Regression] Wrong code |[8 Regression] Wrong code
   |when returning padded   |when returning padded
   |struct  |struct

--- Comment #8 from Jakub Jelinek  ---
Fixed for 9.3+ too.

[Bug target/93637] [9 Regression] ICE: Segmentation fault (in force_operand)

2020-02-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #9 from Jakub Jelinek  ---
Fixed for 9.3+.

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

2020-02-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93576

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[8/9/10 Regression] |[8 Regression] internal
   |internal compiler error:|compiler error:
   |Segmentation fault (in  |Segmentation fault (in
   |gimplify.c) |gimplify.c)

--- Comment #11 from Jakub Jelinek  ---
Fixed for 9.3+ so far.

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

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93576

--- Comment #10 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:7276dd4c7480dd952f0d4a9322ca04ca29f5126f

commit r9-8227-g7276dd4c7480dd952f0d4a9322ca04ca29f5126f
Author: Jakub Jelinek 
Date:   Thu Feb 13 21:00:09 2020 +0100

c: Fix ICE with cast to VLA [93576]

The following testcase ICEs, because the PR84305 changes try to evaluate
the size earlier.  If size has side-effects, that is desirable, and the
side-effects will actually be wrapped in a SAVE_EXPR.  The problem on this
testcase is that there are no side-effects, and c_fully_fold doesn't fold
those COMPOUND_EXPRs to constant, and while before gimplification we
unshare
trees found in the expressions, the unsharing doesn't involve TYPE_SIZE
etc.
of used types.  Gimplification is destructive though, so when we gimplify
the two nested COMPOUND_EXPRs and then try to gimplify it the second time
for the TYPE_SIZEs, we ICE.
Now, we could use unshare_expr in what we push to *expr, SAVE_EXPRs and
their operands in there aren't unshared, but I really don't see a point of
evaluating expressions that don't have side-effects before, so instead
this just pushes there expressions that do have side-effects.

2020-02-13  Jakub Jelinek  

PR c/93576
* c-decl.c (grokdeclarator): If this_size_varies, only push size into
*expr if it has side effects.

* gcc.dg/pr93576.c: New test.

[Bug target/93673] Fake error given by gcc when compiling for _kshift intrinsics

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93673

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

https://gcc.gnu.org/g:488a947b2ddd57a6f44a6aecc32862f8cbf4ec77

commit r9-8225-g488a947b2ddd57a6f44a6aecc32862f8cbf4ec77
Author: Jakub Jelinek 
Date:   Thu Feb 13 08:17:07 2020 +0100

i386: Fix k*shift* intrinsics [PR93673]

As mentioned in the PR, the intrinsics allow counts from 0 to 255, but
we actually reject values from 128 to 255.  That is because QImode
CONST_INTs can be only -128 to 127.  Fixed by using const_0_to_255_operand
and dropping the modes for the operands with those predicates
(the IL actually contains the CONST_INT which has VOIDmode).

2020-02-13  Jakub Jelinek  

PR target/93673
* config/i386/sse.md (k): Drop mode from last operand and
use const_0_to_255_operand predicate instead of immediate_operand.
(avx512dq_fpclass,
avx512dq_vmfpclass,
vgf2p8affineinvqb_,
vgf2p8affineqb_): Drop mode from
const_0_to_255_operand predicated operands.

* gcc.target/i386/avx512f-pr93673.c: New test.
* gcc.target/i386/avx512dq-pr93673.c: New test.
* gcc.target/i386/avx512bw-pr93673.c: New test.

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

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93670

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

https://gcc.gnu.org/g:20ac13c895c5abe7a350de0b664abf190aa28a16

commit r9-8224-g20ac13c895c5abe7a350de0b664abf190aa28a16
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/93637] [9 Regression] ICE: Segmentation fault (in force_operand)

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93637

--- Comment #8 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

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

commit r9-8223-gb7cbce7a174292adc7c9d6db81bba6922a591d69
Author: Jakub Jelinek 
Date:   Mon Feb 10 22:44:40 2020 +0100

i386: Fix -mavx -mno-mavx2 ICE with VEC_COND_EXPR [PR93637]

As mentioned in the PR, for -mavx -mno-avx2 the backend does support
vcondv4div4df and vcondv8siv8sf optabs (while generally 32-byte vectors
aren't much supported in that case, it is performed using
vandps/vandnps/vorps).  The problem is that after the last generic vector
lowering (where the VEC_COND_EXPR still compares two V4DF vectors and
has two V4DI last operands and V4DI result and so is considered ok) fre4
folds the condition into constant, at which point the middle-end during
expansion will try vcond_mask_optab and fall back to trying to expand it
as the constant vector < 0 vcondv4div4di, but neither of them is supported
for -mavx -mno-avx2 and thus we ICE.

So, the options I see is either what the following patch does, also support
vcond_mask_v4div4di and vcond_mask_v4siv4si already for TARGET_AVX, or
require for vcondv4div4df and vcondv8siv8sf TARGET_AVX2 rather than current
TARGET_AVX.

2020-02-10  Jakub Jelinek  

PR target/93637
* config/i386/sse.md (VI_256_AVX2): New mode iterator.
(vcond_mask_): Use it instead of VI_256.
Change condition from TARGET_AVX2 to TARGET_AVX.

* gcc.target/i386/avx-pr93637.c: New test.

[Bug target/65782] Assembly failure (invalid register for .seh_savexmm) with -O3 -mavx512f on mingw-w64

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65782

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

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

commit r9-8222-ga91e5d88970c8d865a49f2a4ed4e17ee2c58b73f
Author: Jakub Jelinek 
Date:   Sat Feb 8 10:59:40 2020 +0100

i386: Make xmm16-xmm31 call used even in ms ABI [PR65782]

On Tue, Feb 04, 2020 at 11:16:06AM +0100, Uros Bizjak wrote:
> I guess that Comment #9 patch form the PR should be trivially correct,
> but althouhg it looks obvious, I don't want to propose the patch since
> I have no means of testing it.

I don't have means of testing it either.
   
https://docs.microsoft.com/en-us/cpp/build/x64-calling-convention?view=vs-2019
is quite explicit that [xyz]mm16-31 are call clobbered and only xmm6-15
(low
128-bits only) are call preserved.

We are talking e.g. about
/* { dg-options "-O2 -mabi=ms -mavx512vl" } */

typedef double V __attribute__((vector_size (16)));
void foo (void);
V bar (void);
void baz (V);
void
qux (void)
{
  V c;
  {
register V a __asm ("xmm18");
V b = bar ();
asm ("" : "=x" (a) : "0" (b));
c = a;
  }
  foo ();
  {
register V d __asm ("xmm18");
V e;
d = c;
asm ("" : "=x" (e) : "0" (d));
baz (e);
  }
}
where according to the MSDN doc gcc incorrectly holds the c value
in xmm18 register across the foo call; if foo is compiled by some Microsoft
compiler (or LLVM), then it could clobber %xmm18.
If all xmm18 occurrences are changed to say xmm15, then it is valid to hold
the 128-bit value across the foo call (though, surprisingly, LLVM saves it
into stack anyway).

The other parts are I guess mainly about SEH.  Consider e.g.
void
foo (void)
{
  register double x __asm ("xmm14");
  register double y __asm ("xmm18");
  asm ("" : "=x" (x));
  asm ("" : "=v" (y));
  x += y;
  y += x;
  asm ("" : : "x" (x));
  asm ("" : : "v" (y));
}
looking at cross-compiler output, with -O2 -mavx512f this emits
.file   "abcdeq.c"
.text
.align 16
.globl  foo
.deffoo;.scl2;  .type   32; .endef
.seh_proc   foo
foo:
subq$40, %rsp
.seh_stackalloc 40
vmovaps %xmm14, (%rsp)
.seh_savexmm%xmm14, 0
vmovaps %xmm18, 16(%rsp)
.seh_savexmm%xmm18, 16
.seh_endprologue
vaddsd  %xmm18, %xmm14, %xmm14
vaddsd  %xmm18, %xmm14, %xmm18
vmovaps (%rsp), %xmm14
vmovaps 16(%rsp), %xmm18
addq$40, %rsp
ret
.seh_endproc
.ident  "GCC: (GNU) 10.0.1 20200207 (experimental)"
Does whatever assembler mingw64 uses even assemble this (I mean the
.seh_savexmm %xmm16, 16 could be problematic)?
I can find e.g.
   
https://stackoverflow.com/questions/43152633/invalid-register-for-seh-savexmm-in-cygwin/43210527
which then links to
https://gcc.gnu.org/PR65782

2020-02-08  Uroš Bizjak  
Jakub Jelinek  

PR target/65782
* config/i386/i386.h (CALL_USED_REGISTERS): Make
xmm16-xmm31 call-used even in 64-bit ms-abi.

* gcc.target/i386/pr65782.c: New test.

Co-authored-by: Uroš Bizjak 

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

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93696

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:08cf145f991327d943d785066709f5f39d20bd85

commit r9-8226-g08cf145f991327d943d785066709f5f39d20bd85
Author: Jakub Jelinek 
Date:   Thu Feb 13 10:43:27 2020 +0100

i386: Fix up _mm*_mask_popcnt_epi* [PR93696]

As mentioned in the PR and as
   
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_mask_popcnt_epi
also documents, _mm*_popcnt_epi* intrinsics are consistent with all other
unary AVX512* intrinsics regarding arguments, i.e. the
_mm*_whatever has just single argument (called a in the docs, and __A in
the
GCC headers),
_mm*_mask_whatever has 3 arguments (called src, k, a in the docs and
_W, __U, __A in GCC headers) and
_mm*_maskz_whatever 2 arguments (called k, a in the docs and __U, __A in
GCC
headers).  Unfortunately, whomever implemented the _mm*_popcnt_epi*
intrinsics got it wrong for the _mm*_mask_popcnt_epi* ones, calling the
args __A, __U, __B and not passing them in the canonical order to the
builtins, making it API incompatible with ICC as well as clang (tested on
godbolts clang 7/8/9/trunk and ICC 19.0.{0,1}, older clang/ICC don't
understand those, so it isn't that it used to be broken even in other
compilers and got changed afterwards).

2020-02-13  Jakub Jelinek  

PR target/93696
* config/i386/avx512bitalgintrin.h (_mm512_mask_popcnt_epi8,
_mm512_mask_popcnt_epi16, _mm256_mask_popcnt_epi8,
_mm256_mask_popcnt_epi16, _mm_mask_popcnt_epi8,
_mm_mask_popcnt_epi16): Rename __B argument to __A and __A to __W,
pass __A to the builtin followed by __W instead of __A followed by
__B.
* config/i386/avx512vpopcntdqintrin.h (_mm512_mask_popcnt_epi32,
_mm512_mask_popcnt_epi64): Likewise.
* config/i386/avx512vpopcntdqvlintrin.h (_mm_mask_popcnt_epi32,
_mm256_mask_popcnt_epi32, _mm_mask_popcnt_epi64,
_mm256_mask_popcnt_epi64): Likewise.

* gcc.target/i386/pr93696-1.c: New test.
* gcc.target/i386/pr93696-2.c: New test.
* gcc.target/i386/avx512bitalg-vpopcntw-1.c (TEST): Fix argument order
of _mm*_mask_popcnt_*.
* gcc.target/i386/avx512vpopcntdq-vpopcntq-1.c (TEST): Likewise.
* gcc.target/i386/avx512vpopcntdq-vpopcntd-1.c (TEST): Likewise.
* gcc.target/i386/avx512bitalg-vpopcntb-1.c (TEST): Likewise.
* gcc.target/i386/avx512bitalg-vpopcntb.c (foo): Likewise.
* gcc.target/i386/avx512bitalg-vpopcntbvl.c (foo): Likewise.
* gcc.target/i386/avx512vpopcntdq-vpopcntd.c (foo): Likewise.
* gcc.target/i386/avx512bitalg-vpopcntwvl.c (foo): Likewise.
* gcc.target/i386/avx512bitalg-vpopcntw.c (foo): Likewise.
* gcc.target/i386/avx512vpopcntdq-vpopcntq.c (foo): Likewise.

[Bug libgomp/93515] OpenMP target teams distribute parallel for with defaultmap not mapping correctly

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93515

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

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

commit r9-8220-gd3266b1311723841ec553277f1fb6bfddef8809d
Author: Jakub Jelinek 
Date:   Thu Feb 6 09:15:13 2020 +0100

openmp: Notice reduction decl in outer contexts after adding it to shared
[PR93515]

If we call omp_add_variable, following omp_notice_variable will already
find it
on that construct and not go through outer constructs, the following patch
fixes that.
Note, this still doesn't follow OpenMP 5.0 semantics on target combined
with other
constructs with reduction/lastprivate/linear clauses, will handle that for
GCC11.

2020-02-06  Jakub Jelinek  

PR libgomp/93515
* gimplify.c (gimplify_scan_omp_clauses) : If adding
shared clause, call omp_notice_variable on outer context if any.

[Bug c++/93557] __builtin_convertvector doesn't mark input as used

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93557

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:520b364da0b20dcb492229757190cc3f30322052

commit r9-8219-g520b364da0b20dcb492229757190cc3f30322052
Author: Jakub Jelinek 
Date:   Wed Feb 5 23:35:08 2020 +0100

c++: Mark __builtin_convertvector operand as read [PR93557]

In C++ we weren't calling mark_exp_read on the __builtin_convertvector
first
argument.  I guess it could misbehave even with lambda implicit captures.

Fixed by calling decay_conversion on the argument, we use the argument as
rvalue so we want the standard lvalue to rvalue conversions, but as the
argument must be a vector type, e.g. integral promotions aren't really
needed.

2020-02-05  Jakub Jelinek  

PR c++/93557
* semantics.c (cp_build_vec_convert): Call decay_conversion on arg
prior to passing it to c_build_vec_convert.

* c-c++-common/Wunused-var-17.c: New test.

[Bug libgomp/93515] OpenMP target teams distribute parallel for with defaultmap not mapping correctly

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93515

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:05fa0de35ec63db2c3aacd30cc34a7389b3c4e5d

commit r9-8221-g05fa0de35ec63db2c3aacd30cc34a7389b3c4e5d
Author: Jakub Jelinek 
Date:   Thu Feb 6 09:19:08 2020 +0100

openmp: Fix handling of non-addressable shared scalars in parallel nested
inside of target [PR93515]

As the following testcase shows, we need to consider even target to be a
construct
that forces not to use copy in/out for shared on parallel inside of the
target.
E.g. for parallel nested inside another parallel or host teams, we already
avoid
copy in/out and we need to treat target the same.

2020-02-06  Jakub Jelinek  

PR libgomp/93515
* omp-low.c (use_pointer_for_field): For nested constructs, also
look for map clauses on target construct.
(scan_omp_1_stmt) : Bump temporarily
taskreg_nesting_level.

* testsuite/libgomp.c-c++-common/pr93515.c: New test.

[Bug middle-end/93505] [8/9 Regression] wrong code or ICE with __builtin_bswap64() and rotation at -Og

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93505

--- Comment #19 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:329475795c6eeaa2b122672091c9119b9d6c5564

commit r9-8217-g329475795c6eeaa2b122672091c9119b9d6c5564
Author: Jakub Jelinek 
Date:   Thu Jan 30 21:28:17 2020 +0100

combine: Punt on out of range rotate counts [PR93505]

What happens on this testcase is with the out of bounds rotate we get:
Trying 13 -> 16:
   13: r129:SI=r132:DI#0<-<0x20
  REG_DEAD r132:DI
   16: r123:DI=r129:SI<0
  REG_DEAD r129:SI
Successfully matched this instruction:
(set (reg/v:DI 123 [  ])
(const_int 0 [0]))
during combine.  So, perhaps we could also change simplify-rtx.c to punt
if it is out of bounds rather than trying to optimize anything.
Or, but probably GCC11 material, if we decide that ROTATE/ROTATERT doesn't
have out of bounds counts or introduce targetm.rotate_truncation_mask,
we should truncate the argument instead of punting.
Punting is better for backports though.

2020-01-30  Jakub Jelinek  

PR middle-end/93505
* combine.c (simplify_comparison) : Punt on out of range
rotate counts.

* gcc.c-torture/compile/pr93505.c: New test.

[Bug middle-end/93555] ICE in simd_clone_struct_copy, at omp-simd-clone.c:84

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93555

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

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

commit r9-8218-gd42f9eaa3e189d4228a4b3a63d02b83fed6385e7
Author: Jakub Jelinek 
Date:   Wed Feb 5 11:32:37 2020 +0100

openmp: Avoid ICEs with declare simd; declare simd inbranch [PR93555]

The testcases ICE because when processing the declare simd inbranch,
we don't create the i == 0 clone as it already exists, which means
clone_info->nargs is not adjusted, but we then rely on it being adjusted
when trying other clones.

2020-02-05  Jakub Jelinek  

PR middle-end/93555
* omp-simd-clone.c (expand_simd_clones): If simd_clone_mangle or
simd_clone_create failed when i == 0, adjust clone->nargs by
clone->inbranch.

* c-c++-common/gomp/pr93555-1.c: New test.
* c-c++-common/gomp/pr93555-2.c: New test.
* gfortran.dg/gomp/pr93555.f90: New test.

[Bug c++/91118] ubsan does not work with openmp default (none) directive

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91118

--- Comment #4 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

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

commit r9-8216-g4b124e3c9c35121969cc23d0aea4bcb2c406fd21
Author: Jakub Jelinek 
Date:   Wed Jan 29 09:41:42 2020 +0100

openmp: c++: Consider typeinfo decls to be predetermined shared [PR91118]

If the typeinfo decls appear in OpenMP default(none) regions, as we no
longer
predetermine const with no mutable members, they are diagnosed as errors,
but it isn't something the users can actually provide explicit sharing for
in
the clauses.

2020-01-29  Jakub Jelinek  

PR c++/91118
* cp-gimplify.c (cxx_omp_predetermined_sharing): Return
OMP_CLAUSE_DEFAULT_SHARED for typeinfo decls.

* g++.dg/gomp/pr91118-1.C: New test.
* g++.dg/gomp/pr91118-2.C: New test.

[Bug fortran/93463] ICE in oacc_code_to_statement, at fortran/openmp.c:6007

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93463

--- Comment #5 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:244f4b8c2823531a1e479a3773272af539dda258

commit r9-8215-g244f4b8c2823531a1e479a3773272af539dda258
Author: Jakub Jelinek 
Date:   Wed Jan 29 09:39:16 2020 +0100

openmp: Handle rest of EXEC_OACC_* in oacc_code_to_statement [PR93463]

As the testcase shows, some EXEC_OACC_* codes weren't handled in
oacc_code_to_statement.  Fixed thusly.

2020-01-29  Jakub Jelinek  

PR fortran/93463
* openmp.c (oacc_code_to_statement): Handle
EXEC_OACC_{ROUTINE,UPDATE,WAIT,CACHE,{ENTER,EXIT}_DATA,DECLARE}.

* gfortran.dg/goacc/pr93463.f90: New test.

[Bug rtl-optimization/93402] [8/9 Regression] Wrong code when returning padded struct

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93402

--- Comment #7 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

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

commit r9-8213-g3b2fbe3e723b20ea9089e5f45c55b79feb37085b
Author: Jakub Jelinek 
Date:   Thu Jan 23 20:08:22 2020 +0100

postreload: Fix up postreload combine [PR93402]

The following testcase is miscompiled, because the postreload pass changes:
-(insn 14 13 23 2 (parallel [
-(set (reg:DI 1 dx [94])
-(plus:DI (reg:DI 1 dx [95])
-(reg:DI 5 di [92])))
-(clobber (reg:CC 17 flags))
-]) "pr93402.c":8:30 186 {*adddi_1}
- (expr_list:REG_EQUAL (plus:DI (reg:DI 5 di [92])
-(const_int  [0x19debd01c7]))
-(nil)))
-(insn 23 14 25 2 (set (reg:SI 0 ax)
+(insn 23 13 25 2 (set (reg:SI 0 ax)
 (const_int 0 [0])) "pr93402.c":10:1 67 {*movsi_internal}
  (nil))
 (insn 25 23 26 2 (use (reg:SI 0 ax)) "pr93402.c":10:1 -1
  (nil))
-(insn 26 25 35 2 (use (reg:DI 1 dx)) "pr93402.c":10:1 -1
+(insn 26 25 35 2 (use (plus:DI (reg:DI 1 dx [95])
+(reg:DI 5 di [92]))) "pr93402.c":10:1 -1
  (nil))
A USE insn is not a normal insn and verify_changes called from
apply_change_group is happy about any changes into it.
The following patch avoids this optimization if we were to change
the USE operand (this routine only changes a reg into (plus reg reg2)).

2020-01-23  Jakub Jelinek  

PR rtl-optimization/93402
* postreload.c (reload_combine_recognize_pattern): Don't try to adjust
USE insns.

* gcc.c-torture/execute/pr93402.c: New test.

[Bug target/93418] [9 Regression] GCC incorrectly constant propagates _mm_sllv/srlv/srav

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93418

--- Comment #11 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jakub Jelinek
:

https://gcc.gnu.org/g:764e831291a2e510978ca7be0bffb55589a5a0b6

commit r9-8214-g764e831291a2e510978ca7be0bffb55589a5a0b6
Author: Jakub Jelinek 
Date:   Tue Jan 28 08:46:23 2020 +0100

i386: Fix ix86_fold_builtin shift folding [PR93418]

The following testcase is miscompiled, because the variable shift left
operand, { -1, -1, -1, -1 } is represented as a VECTOR_CST with
VECTOR_CST_NPATTERNS 1 and VECTOR_CST_NELTS_PER_PATTERN 1, so when
we call builder.new_unary_operation, builder.encoded_nelts () will be just
1
and thus we encode the resulting vector as if all the elements were the
same.
For non-masked is_vshift, we could perhaps call
builder.new_binary_operation
(TREE_TYPE (args[0]), args[0], args[1], false), but then there are masked
shifts, for non-is_vshift we could perhaps call it too but with args[2]
instead of args[1], but there is no builder.new_ternary_operation.
All this stuff is primarily for aarch64 anyway, on x86 we don't have any
variable length vectors, and it is not a big deal to compute all elements
and just let builder.finalize () find the most efficient VECTOR_CST
representation of the vector.  So, instead of doing too much, this just
keeps using new_unary_operation only if only one VECTOR_CST is involved
(i.e. non-masked shift by constant) and for the rest just compute all elts.

2020-01-28  Jakub Jelinek  

PR target/93418
* config/i386/i386.c (ix86_fold_builtin) : If mask is not
-1 or is_vshift is true, use new_vector with number of elts npatterns
rather than new_unary_operation.

* gcc.target/i386/avx2-pr93418.c: New test.

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

2020-02-13 Thread dave.anglin at bell dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #174 from dave.anglin at bell dot net ---
On 2020-02-13 2:44 p.m., dave.anglin at bell dot net wrote:
> The first thing to note is aCC doesn't use weak.  Instead, it uses COMDAT
> sections.  Probably, HP ld does support
> weak but it's unlikely there is support for linkonce sections.  See defines in
> config/pa/som.h.  There we implimented
> one only support using the linker's COMDAT support.
Is HAVE_COMDAT_GROUP defined in auto-host.h?

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

2020-02-13 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565

--- Comment #21 from Segher Boessenkool  ---
(In reply to Andrew Pinski from comment #20)
> (In reply to Segher Boessenkool from comment #18)
> > Created attachment 47841 [details]
> > Patch to treat sign_extend as is_just_move
> 
> Do you think zero_extend should maybe be treated as such too?

Maybe?

> What about truncate (MIPS64 uses truncate a lot as moves)?

Also maybe.

Test runs take a little over three hours (vs. less than two hours
in GCC 8 times).  I'll experiment with those things, but first the
bigger issue (parallel of two identical SETs, just with different
dest).

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

2020-02-13 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565

--- Comment #20 from Andrew Pinski  ---
(In reply to Segher Boessenkool from comment #18)
> Created attachment 47841 [details]
> Patch to treat sign_extend as is_just_move

Do you think zero_extend should maybe be treated as such too?  What about
truncate (MIPS64 uses truncate a lot as moves)?

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

2020-02-13 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565

--- Comment #19 from Segher Boessenkool  ---
With that above patch, I get (T0 is original, T2 is with patch, these are
file sizes of a Linux build, mostly defconfig):

T0T2
   alpha   6049096  100.020%
 arc   4019384  100.000%
 arm  14177962   99.999%
   arm64  12968466   99.938%
 c6x   2346077  100.000%
csky   3332454  100.000%
   h8300   1165256   99.999%
i386  11227764  100.001%
ia64  18088488  100.003%
m68k   3716871  100.000%
  microblaze   4935181  100.000%
mips   8407681  100.000%
  mips64   6979344   99.987%
   nds32   4471023  100.000%
   nios2   3643253  100.000%
openrisc   4182200  100.000%
  parisc   7710095  100.001%
parisc64   8676725  100.003%
 powerpc  10603859  100.000%
   powerpc64  17552718  100.007%
 powerpc64le  17552718  100.007%
 riscv32   1546172  100.000%
 riscv64   6623170  100.010%
s390  13103095   99.995%
  sh   3216555   99.999%
 shnommu   1611176   99.999%
   sparc   436  100.000%
 sparc64   6751939  100.000%
  x86_64  19681173  100.000%
  xtensa 0 0

I think I'll commit this, but let's look at the original problem first as well.

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

2020-02-13 Thread segher at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93565

--- Comment #18 from Segher Boessenkool  ---
Created attachment 47841
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47841=edit
Patch to treat sign_extend as is_just_move

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

2020-02-13 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93713

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed.

[Bug c++/93643] [10 Regression] Static function pointer inside inline function with "C" linkage is not mangled

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93643

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

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

commit r10-6628-gabc79c6498a99e9c39e6056f432796c6dde3a887
Author: Jason Merrill 
Date:   Thu Feb 13 16:42:04 2020 +0100

c++: Fix static local vars in extern "C".

Since my patch for PR 91476 moved visibility determination sooner, a local
static in a vague linkage function now gets TREE_PUBLIC set before
retrofit_lang_decl calls set_decl_linkage, which was making decl_linkage
think that it has external linkage.  It still has no linkage according to
the standard.

gcc/cp/ChangeLog
2020-02-13  Jason Merrill  

PR c++/93643
PR c++/91476
* tree.c (decl_linkage): Always lk_none for locals.

[Bug c++/91476] [9/10 Regression] const reference variables sharing the same name in two anonymous namespaces cause a multiple definition error

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91476

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

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

commit r10-6628-gabc79c6498a99e9c39e6056f432796c6dde3a887
Author: Jason Merrill 
Date:   Thu Feb 13 16:42:04 2020 +0100

c++: Fix static local vars in extern "C".

Since my patch for PR 91476 moved visibility determination sooner, a local
static in a vague linkage function now gets TREE_PUBLIC set before
retrofit_lang_decl calls set_decl_linkage, which was making decl_linkage
think that it has external linkage.  It still has no linkage according to
the standard.

gcc/cp/ChangeLog
2020-02-13  Jason Merrill  

PR c++/93643
PR c++/91476
* tree.c (decl_linkage): Always lk_none for locals.

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

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93713

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

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

commit r10-6629-g9a0c4f5b373e236cb4af5491f50862d41fd8775a
Author: Jason Merrill 
Date:   Thu Feb 13 16:56:08 2020 +0100

c++: Fix useless using-declaration.

Here reintroducing the same declarations into the global namespace via
using-declaration is useless but OK.  And a function and a function
template
with the same parameters do not conflict.

gcc/cp/ChangeLog
2020-02-13  Jason Merrill  

PR c++/93713
* name-lookup.c (matching_fn_p): A function does not match a
template.

[Bug c++/93643] [10 Regression] Static function pointer inside inline function with "C" linkage is not mangled

2020-02-13 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93643

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug target/93737] inline memmove for insertion into small arrays

2020-02-13 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93737

--- Comment #3 from Martin Sebor  ---
I was thinking for small N, the middle-end could make it work by emitting
copies of the sequences using MEM_REFs, along these lines:

  char _2[N - 2];
  _2 = MEM  [(char * {ref-all}) + 1];
  MEM  [(char * {ref-all}) + 2] = _2;

[Bug target/90262] Inline small constant memmoves

2020-02-13 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90262

Andrew Pinski  changed:

   What|Removed |Added

 Target||aarch64-linux-gnu
  Component|middle-end  |target

--- Comment #2 from Andrew Pinski  ---
Most of the infrastructure is there now:
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00087.html

[Bug target/93737] inline memmove for insertion into small arrays

2020-02-13 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93737

--- Comment #2 from Andrew Pinski  ---
Sdee the thread starting at:
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01618.html
Continued at:
https://gcc.gnu.org/ml/gcc-patches/2019-10/msg00277.html

This infastructure patch was committed October 2, 2019.  So it is now a target
specific issue.

[Bug sanitizer/93731] [10 regression] asan tests cause kernel panic on Darwin 11

2020-02-13 Thread egallager at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93731

--- Comment #4 from Eric Gallager  ---
(In reply to Iain Sandoe from comment #3)
> These systems are EOL so we can't expect any fixes to the systems themselves.
> 
> The question is "is the latest imported as an version even supposed to
> support 10.7"?
> 
> I have a patch to unsupport the sanitiser for <= 10.6 [where it has been
> unsupported upstream since at least the last release].  That is something
> that I can apply immediately.
> 
> If the latest sanitiser code is _supposed_ to work on 10.7 - we should at
> least take a cursory look at why/where it's failing before punting.
> 
> I agree that spending much time on making the sanitisers work on EOL
> machines is not a priority.  I don't have access to my 10.7 box right now -
> but will take a look next week.

I'm on 10.6 and have been configuring with --disable-libsanitizer for some time
now anyways, so it won't be too much of a loss if that becomes the default

[Bug c++/90515] g++ ignores [[deprecated("text")]] in some template specialisations

2020-02-13 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90515

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-13
 Ever confirmed|0   |1

[Bug c++/93228] [[deprecated("message")]] on template struct/class drops message

2020-02-13 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93228

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #5 from Jonathan Wakely  ---
PR 90515 has similar cases that still fail.

[Bug c++/68061] Can't use [[deprecated]] with requires clause

2020-02-13 Thread redi at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68061

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-13
  Known to work||10.0
 Blocks||67491
 Ever confirmed|0   |1
  Known to fail||9.2.0

--- Comment #3 from Jonathan Wakely  ---
This was fixed for GCC 10 by r276764.

It still fails on the release branches. I'm not sure if there's a test to
detect regressions.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67491
[Bug 67491] [meta-bug] concepts issues

[Bug c++/92572] Vague linkage does not work reliably when a matching segment is in a dynamically linked libarary on Linux

2020-02-13 Thread wkaras at yahoo dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92572

--- Comment #7 from Walt Karas  ---
I see this problem running in a Docker container on a MacBook.  When I try it
on the Mac (clang, Darwin kernel), the output is 2.

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

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93576

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

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

commit r10-6625-gbacdd5e978dad84e9c547b0d5c7fed14b8d75157
Author: Jakub Jelinek 
Date:   Thu Feb 13 21:00:09 2020 +0100

c: Fix ICE with cast to VLA [93576]

The following testcase ICEs, because the PR84305 changes try to evaluate
the size earlier.  If size has side-effects, that is desirable, and the
side-effects will actually be wrapped in a SAVE_EXPR.  The problem on this
testcase is that there are no side-effects, and c_fully_fold doesn't fold
those COMPOUND_EXPRs to constant, and while before gimplification we
unshare
trees found in the expressions, the unsharing doesn't involve TYPE_SIZE
etc.
of used types.  Gimplification is destructive though, so when we gimplify
the two nested COMPOUND_EXPRs and then try to gimplify it the second time
for the TYPE_SIZEs, we ICE.
Now, we could use unshare_expr in what we push to *expr, SAVE_EXPRs and
their operands in there aren't unshared, but I really don't see a point of
evaluating expressions that don't have side-effects before, so instead
this just pushes there expressions that do have side-effects.

2020-02-13  Jakub Jelinek  

PR c/93576
* c-decl.c (grokdeclarator): If this_size_varies, only push size into
*expr if it has side effects.

* gcc.dg/pr93576.c: New test.

[Bug target/93738] [8/9 regression] test case gcc.target/powerpc/20050603-3.c fails

2020-02-13 Thread seurer at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93738

seurer at gcc dot gnu.org changed:

   What|Removed |Added

 Target||powerpc64-linux-gnu
 CC||segher at gcc dot gnu.org
   Host||powerpc64-linux-gnu
  Build||powerpc64-linux-gnu

--- Comment #1 from seurer at gcc dot gnu.org ---
The actual FAILs only seem to happen with gcc 9 and 10 (trunk)  and then only
on BE.  On some of the other combos I see some XPASSes, though.

[Bug target/93738] New: [8/9 regression] test case gcc.target/powerpc/20050603-3.c fails

2020-02-13 Thread seurer at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93738

Bug ID: 93738
   Summary: [8/9 regression] test case
gcc.target/powerpc/20050603-3.c fails
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

git g:8d2d39587d941a40f25ea0144cceb677df115040, r9-3594

ok, this is an old issue that slipped past unnoticed somehow.  It was
introduced in gcc 8 or maybe 9 but also then effects 10.  I am not sure which
order the changes were done back in 8/9.  There is an extra instruction,
rldicl, generated after the change in this test case.


Executing on host: /home/seurer/gcc/git/build/gcc-9-test-2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-9-test-2/gcc/
/home/seurer/gcc/git/gcc-9-test-2/gcc/testsuite/gcc.target/powerpc/20050603-3.c
   -fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -O2 -ffat-lto-objects -fno-ident -S -o 20050603-3.s 
  (timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-9-test-2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-9-test-2/gcc/
/home/seurer/gcc/git/gcc-9-test-2/gcc/testsuite/gcc.target/powerpc/20050603-3.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O2 -ffat-lto-objects -fno-ident -S -o 20050603-3.s
PASS: gcc.target/powerpc/20050603-3.c (test for excess errors)
PASS: gcc.target/powerpc/20050603-3.c scan-assembler-not \\mrlwinm
FAIL: gcc.target/powerpc/20050603-3.c scan-assembler-not \\mrldic
PASS: gcc.target/powerpc/20050603-3.c scan-assembler-not \\mrot[lr]
PASS: gcc.target/powerpc/20050603-3.c scan-assembler-not \\ms[lr][wd]
PASS: gcc.target/powerpc/20050603-3.c scan-assembler-times \\mrl[wd]imi 1
Executing on host: /home/seurer/gcc/git/build/gcc-9-test-2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-9-test-2/gcc/ vmx_hw_available76502.c   
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never  -mno-vsx  -lm  -o vmx_hw_available76502.exe   
(timeout = 300)
spawn -ignore SIGHUP /home/seurer/gcc/git/build/gcc-9-test-2/gcc/xgcc
-B/home/seurer/gcc/git/build/gcc-9-test-2/gcc/ vmx_hw_available76502.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -mno-vsx -lm -o vmx_hw_available76502.exe
Setting LD_LIBRARY_PATH to
:/home/seurer/gcc/git/build/gcc-9-test-2/gcc::/home/seurer/gcc/git/build/gcc-9-test-2/gcc:/home/seurer/gcc/git/build/gcc-9-test-2/./gmp/.libs:/home/seurer/gcc/git/build/gcc-9-test-2/./prev-gmp/.libs:/home/seurer/gcc/git/build/gcc-9-test-2/./mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-9-test-2/./prev-mpfr/src/.libs:/home/seurer/gcc/git/build/gcc-9-test-2/./mpc/src/.libs:/home/seurer/gcc/git/build/gcc-9-test-2/./prev-mpc/src/.libs:/home/seurer/gcc/git/build/gcc-9-test-2/./isl/.libs:/home/seurer/gcc/git/build/gcc-9-test-2/./prev-isl/.libs:/home/seurer/gcc/install/gcc-7.4.0/lib64
Execution timeout is: 300
spawn [open ...]
testcase
/home/seurer/gcc/git/gcc-9-test-2/gcc/testsuite/gcc.target/powerpc/powerpc.exp
completed in 1 seconds

=== gcc Summary ===

# of expected passes5
# of unexpected failures1


/* This should generate a single rl[wd]imi. */
void rotins (unsigned int x)
{
  b.y = (x<<12) | (x>>20);
}



Before the change:

addis 10,2,.LC0@toc@ha
ld 10,.LC0@toc@l(10)
lwz 9,0(10)
rlwimi 9,3,20,20,23
stw 9,0(10)
blr


After the change:

addis 10,2,.LC0@toc@ha
ld 10,.LC0@toc@l(10)
*** rldicl 9,3,52,32
lwz 3,0(10)
rlwimi 3,9,0,3840
stw 3,0(10)
blr

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

2020-02-13 Thread dave.anglin at bell dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #173 from dave.anglin at bell dot net ---
On 2020-02-13 1:11 p.m., peter.bisroev at groundlabs dot com wrote:
> If I try to compare this to aCC dump in attachment 47840, I do not see any
> calls to weak. Equivalent section to the above dump in gimple-expr.s
> (_Z18tree_operand_checkPK9tree_nodeiPKciS3_) can be found on line 9007, also
> gimple-expr.o.objdump on line 2099. I believe the place where with gcc we
> expect to see a call to tree_operand_length() through PCREL21B reloc, aCC does
> similar thing in gimple-expr.s line 9098 (gimple-expr.o.objdump line 2181).
I looked at the definition and branches to
_Z18tree_operand_checkPK9tree_nodeiPKciS3_
in the gimple-expr.s file that you uploaded.

We have the following:

    .type   _Z18tree_operand_checkPK9tree_nodeiPKciS3_,@function
    .global _Z18tree_operand_checkPK9tree_nodeiPKciS3_

    .size   _Z18tree_operand_checkPK9tree_nodeiPKciS3_, 784
// Routine [id=0064] ( tree_operand_check )

// ===
    .secalias .abe$170.text, ".text"
    .section .abe$170.text = "axC", "progbits", .abe$comdat0010
    .align  16
    .proc   _Z18tree_operand_checkPK9tree_nodeiPKciS3_
..L0:
//  $start  ARid768 =   ;; // A

..L2:
_Z18tree_operand_checkPK9tree_nodeiPKciS3_::
.prologue
//  $entry  ARid770, S:r32, S:r33, S:r34, S:r35, S:r36 =  ;; // A
[tree.h: 3177/1]
//file/line/col tree.h/3177/1
.save ar.pfs, r39
    alloc   r39 = ar.pfs, 5, 4, 5, 0   // M [tree.h: 3177/1]

    br.ret.dptk.many rp ;; // B [tree.h: 3181/3]

..L1:
//  $end    ;; // A

    .endp   _Z18tree_operand_checkPK9tree_nodeiPKciS3_

    nop.m   0  // M
    nop.i   0  // I
    nop.m   0  // M
    nop.m   0  // M
    br.call.dptk.many rp = _Z18tree_operand_checkPK9tree_nodeiPKciS3_# ;;
// B [gimple-expr.c: 658/3]
    add r9 = 0, r8 // M [gimple-expr.c: 658/3]

    .secalias .abe$comdat0010, "_Z18tree_operand_checkPK9tree_nodeiPKciS3_"

The first thing to note is aCC doesn't use weak.  Instead, it uses COMDAT
sections.  Probably, HP ld does support
weak but it's unlikely there is support for linkonce sections.  See defines in
config/pa/som.h.  There we implimented
one only support using the linker's COMDAT support.

Regarding the call to _Z18tree_operand_checkPK9tree_nodeiPKciS3_, this is
preceeded by a bunch of nops.  This is
probably to allow linker to modify call should it select a different instance
of _Z18tree_operand_checkPK9tree_nodeiPKciS3_.

[Bug fortran/93736] Add .f18 and .F18 file suffixes

2020-02-13 Thread sgk at troutmask dot apl.washington.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736

--- Comment #5 from Steve Kargl  ---
On Thu, Feb 13, 2020 at 05:59:18PM +, thenlich at gcc dot gnu.org wrote:
> 
> --- Comment #4 from Thomas Henlich  ---
> Additionally, we could also imply -std=f2018 with the .f18/.F18 suffix. That
> would make them more useful.
> 

That would be a POLA as neither f03 nor f08 imply -std=f2003 or
-std=f2008.  AFAIK, these were added as a simply mnemonic for
the programmer.  By default, we have -std=gnu, which is a garabage
consumer (meaning, here's some code, do whatever it takes to 
compile it).  I think that that was a mistake, but that ship
sailed 15+ years ago.

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

2020-02-13 Thread peter.bisroev at groundlabs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

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

(In reply to dave.anglin from comment #168)
> There seems to be something broken regarding stub insertion for calls to
> weak functions.  Are we
> using the correct branch form for calls to weak?  There doesn't seem to be a
> problem with branches
> to functions that aren't defined in the module.
> 
> Could you try compiling sancov.c from gcc-8 with aCC in C++ mode.  Use -S to
> get assembler output.
> What happens to weak calls (e.g., the one I pointed out previously)?

Unfortunately as mentioned in comment 165 I was unable to get aCC to compile
sancov.c from gcc 8.3.0 or use HP's assember with gcc generated .s output.
However I was able to reproduce the same relocation issue when attempting to
compile gcc 4.9.4 and at the same time was able to compile one of the
problematic files (gimple-expr.c) with aCC as well.

I have attached relevant results as you have requested in attachment 47828. But
I did not see the relevant functions appearing in object file compiled with aCC
(attachment 47829). I took a look at it a bit more last night and realized that
the code that was causing relocation issues with gcc was not compiled in when
using aCC. After a bit of mucking around with aCC to approximate compilations
options to as close as possible to gcc ones (so -O0, no inlining, target arhc,
etc...) and enabling gnu mode and a few defines allowed me to compile the
relevant parts in to the object. You can see the .o and .s from aCC as well as
a few more dumps in attachment 47840.

Just to make sure I do not waste your time, I tried to get some info for you
from the gcc dumps (attachment 47828) as you have previously requested for
sancov.c (please let me know if I made any mistakes there).

Original linker error was:

ld: The value 0xfdf81640 does not fit when applying the relocation
PCREL21B for symbol ".text" at offset 0x102 in section index 59 of file
libbackend.a[gimple-expr.o]


Looking for section 59's name and confirming with readlef:

$ elfdump -C -D 59 -h gimple-expr.o

gimple-expr.o:

*** Section Header ***

Idx: 59  
  Section: .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
  Type:PBIT   Flags:   -- EA-  
  Vaddr:   0x Offset:  0xcd50
  Size:0x0240 Link:  
  Info:   Align:   0x0010
  Entsize: 0x

$ readelf -S -W gimple-expr.o | grep '\[59\]'   
  [59] .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_ PROGBITS 
   00cd50 000240 00  AX  0   0 16


Dumping relocations for this section:

$ objdump -r -j .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
gimple-expr.o

gimple-expr.o: file format elf32-ia64-hpux-big

RELOCATION RECORDS FOR
[.gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_]:
OFFSET   TYPE  VALUE 
0071 LTOFF22X  .rodata
0080 LDXMOV.rodata
0082 LTOFF22X  .rodata+0x0188
0090 LDXMOV.rodata+0x0188
0092 PCREL21B  _Z10expr_checkPK9tree_nodePKciS3_
0102 PCREL21B  .text
01d2 PCREL21B  _Z25tree_operand_check_failediPK9tree_nodePKciS3_


And we can see the PCREL21B relocation at offset 0x102 there.

And here is a disassembly of this section showing the same PCREL21B relocation
at the same offset. If I understand the code correctly than that should be a
call to tree_operand_length() at that offset.

$ objdump -d -C -S -t -r -j
.gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_ gimple-expr.o

gimple-expr.o: file format elf32-ia64-hpux-big

SYMBOL TABLE:
 ld  .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
 .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
  wF .gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_
0240 tree_operand_check(tree_node const*, int, char const*, int, char
const*)



Disassembly of section
.gnu.linkonce.t._Z18tree_operand_checkPK9tree_nodeiPKciS3_:

 :
}

inline const_tree *
tree_operand_check (const_tree __t, int __i,
const char *__f, int __l, const char *__g)
{
   0:   00 30 39 12 80 05   [MII]   alloc r38=ar.pfs,14,9,0
   6:   70 02 30 00 42 80   mov r39=r12
   c:   01 65 fc 8c adds r12=-48,r12
  10:   01 00 00 00 01 00   [MII]   nop.m 0x0
  16:   50 02 00 62 00 00   mov r37=b0
  1c:   05 08 00 84 mov r40=r1;;
  20:   0b 70 c0 4f 3f 23   [MMI]   adds r14=-16,r39;;
  26:   00 00 39 20 23 c0   st4 [r14]=r32
  2c:   41 3f fd 8c adds r14=-12,r39;;
  30:   02 00 84 1c 90 11   

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

2020-02-13 Thread peter.bisroev at groundlabs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #171 from Peter Bisroev  ---
Comment on attachment 47839
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47839
GCC 4.9.4 gimple-expr.c dump (aCC)

Obsoleted by attachment 47840 as in this attachment inlining with aCC was not
fully disabled.

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

2020-02-13 Thread peter.bisroev at groundlabs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

Peter Bisroev  changed:

   What|Removed |Added

  Attachment #47839|0   |1
is obsolete||

--- Comment #170 from Peter Bisroev  ---
Created attachment 47840
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47840=edit
GCC 4.9.4 gimple-expr.c dump (aCC) V3

[Bug fortran/93736] Add .f18 and .F18 file suffixes

2020-02-13 Thread thenlich at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736

Thomas Henlich  changed:

   What|Removed |Added

   Priority|P3  |P5

--- Comment #4 from Thomas Henlich  ---
Additionally, we could also imply -std=f2018 with the .f18/.F18 suffix. That
would make them more useful.

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

2020-02-13 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93572

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-13
 CC||msebor at gcc dot gnu.org
  Known to work||4.4.3
Summary|internal compiler error: q  |[8/9/10 Regression]
   |from h referenced in main   |internal compiler error: q
   ||from h referenced in main
 Ever confirmed|0   |1
  Known to fail||10.0, 4.5.3, 4.6.4, 4.7.4,
   ||4.8.4, 4.9.4, 5.5.0, 6.4.0,
   ||7.2.0, 8.0, 9.2.0

--- Comment #2 from Martin Sebor  ---
Confirmed.  Bisection points to r145256 (4.5.0):

commit 2ec5deb5c3146cdaf0119ebf7f37df6e57f1521d
Author: Paolo Bonzini 
Date:   Sun Mar 29 18:26:43 2009 +

c-common.c (c_expand_expr, c_staticp): Remove.

2009-03-28  Paolo Bonzini  

* c-common.c (c_expand_expr, c_staticp): Remove.
* c-common.def (COMPOUND_LITERAL_EXPR): Delete.
* c-common.h (emit_local_var, c_staticp,
COMPOUND_LITERAL_EXPR_DECL,
COMPOUND_LITERAL_EXPR_DECL_EXPR): Remove.
* c-gimplify.c (gimplify_compound_literal_expr,
optimize_compound_literals_in_ctor): Remove.
(c_gimplify_expr): Remove COMPOUND_LITERAL_EXPR handling.
* c-objc-common.h (LANG_HOOKS_STATICP): Remove.
* c-semantics.c (emit_local_var): Remove.

* langhooks-def.h (lhd_expand_expr): Remove.
* langhooks.c (lhd_expand_expr): Remove.
* langhooks.h (LANG_HOOKS_DEF): Remove LANG_HOOKS_EXPAND_EXPR.

* expr.c (expand_expr_real_1): Move COMPOUND_LITERAL_EXPR
handling from c-semantics.c; don't call into langhook.
(expand_expr_addr_expr_1): Check that we don't get non-GENERIC
trees.
* gimplify.c (gimplify_compound_literal_expr,
optimize_compound_literals_in_ctor): Move from c-gimplify.c.
(gimplify_init_constructor): Call
optimize_compound_literals_in_ctor.
(gimplify_modify_expr_rhs, gimplify_expr): Handle
COMPOUND_LITERAL_EXPR
as was done in c-gimplify.c.
* tree.c (staticp): Move COMPOUND_LITERAL_EXPR handling from
c_staticp.
* tree.h (COMPOUND_LITERAL_EXPR_DECL,
COMPOUND_LITERAL_EXPR_DECL_EXPR):
Move from c-common.h.
* tree.def (COMPOUND_LITERAL_EXPR): Move from c-common.def.

* tree.c (staticp): Do not call langhook.
* langhooks.c (lhd_staticp): Delete.
* langhooks-def.h (lhd_staticp): Delete prototype.
(LANG_HOOKS_STATICP): Delete.
(LANG_HOOKS_INITIALIZER): Delete LANG_HOOKS_STATICP.

* doc/c-tree.texi (Expression nodes): Refer to DECL_EXPRs
instead of DECL_STMTs.

cp:
2009-03-28  Paolo Bonzini  

* cp/cp-objcp-common.h (LANG_HOOKS_STATICP): Remove.
* cp/cp-objcp-common.c (cxx_staticp): Remove.
* cp/cp-tree.h (cxx_staticp): Remove.

From-SVN: r145256

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

2020-02-13 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93573

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-13
 CC||msebor at gcc dot gnu.org
  Known to work||7.3.0
Summary|internal compiler error: in |[8/9/10 Regression]
   |force_constant_size, at |internal compiler error: in
   |gimplify.c:733  |force_constant_size, at
   ||gimplify.c:733
 Ever confirmed|0   |1
  Known to fail||10.0, 8.3.0, 9.2.0

--- Comment #2 from Martin Sebor  ---
Confirmed.  Bisection points to r256748 (GCC 8):

commit 47c268c4b27782717fbccec5019e0cd97d005afb
Author: Jakub Jelinek 
Date:   Tue Jan 16 16:18:24 2018 +0100

re PR libgomp/83590 ([nvptx] openacc reduction C regressions)

PR libgomp/83590
* gimplify.c (gimplify_one_sizepos): For is_gimple_constant (expr)
return early, inline manually is_gimple_sizepos.  Make sure if we
call gimplify_expr we don't end up with a gimple constant.
* tree.c (variably_modified_type_p): Don't return true for
is_gimple_constant (_t).  Inline manually is_gimple_sizepos.
* gimplify.h (is_gimple_sizepos): Remove.

Co-Authored-By: Richard Biener 

From-SVN: r256748

[Bug fortran/93736] Add .f18 and .F18 file suffixes

2020-02-13 Thread sgk at troutmask dot apl.washington.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736

--- Comment #3 from Steve Kargl  ---
On Thu, Feb 13, 2020 at 04:40:08PM +, thenlich at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736
> 
> --- Comment #2 from Thomas Henlich  ---
> I don't know why the Fortran compiler doesn't treat all files as free-form
> Fortran source files, unless they have a known extension indicating otherwise.

I suppose it has something to do with the fact that gfortran
will accept languages other than Fortran.

% gfortran9 -o z hello.c 
% ./z
hello

If you're really keen on the idea of adding yet another 
useless extension.  Look in gcc/fortran/lang-specs.h.

In 70 years, when F2090 is released, I'll let the next
generation deal with .F90 and .f90. :-)

[Bug tree-optimization/93737] inline memmove for insertion into small arrays

2020-02-13 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93737

Martin Sebor  changed:

   What|Removed |Added

   Keywords||missed-optimization
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=90262

--- Comment #1 from Martin Sebor  ---
A similar, if not the same, improvement is tracked in pr90262.

[Bug tree-optimization/93737] New: inline memmove for insertion into small arrays

2020-02-13 Thread msebor at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93737

Bug ID: 93737
   Summary: inline memmove for insertion into small arrays
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

GCC emits what's likely more efficient code for the insertion of elements into
the middle of small arrays by copying parts of the array into a temporary
buffer than it does for straight calls to memmove that achieve the same result
without the temporary buffer.

The example below shows the difference.  Clang emits the same, presumably
optimally efficient, code for both functions as GCC does for f0.

$ cat t.c && gcc -DN=32 -O2 -S -Wall -o/dev/stdout t.c
int a[N];

void f0 (int x)
{
  int b[N];
  __builtin_memcpy (b, a + 1, sizeof a - sizeof *a);
  __builtin_memcpy (a + 2, b, sizeof a - 2 * sizeof *a);
  a[1] = x;
}

void f2 (int x)
{
  __builtin_memmove (a + 2, a + 1, sizeof a - 2 * sizeof *a);
  a[1] = x;
}


.file   "t.c"
.text
.p2align 4
.globl  f0
.type   f0, @function
f0:
.LFB0:
.cfi_startproc
subq$16, %rsp
.cfi_def_cfa_offset 24
movdqu  a+20(%rip), %xmm5
movdqu  a+36(%rip), %xmm4
movdqu  a+52(%rip), %xmm3
movdqu  a+68(%rip), %xmm2
movdqu  a+84(%rip), %xmm1
movdqu  a+100(%rip), %xmm0
movups  %xmm5, a+24(%rip)
movqa+116(%rip), %rax
movdqu  a+4(%rip), %xmm6
movups  %xmm4, a+40(%rip)
movl%edi, a+4(%rip)
movq%rax, a+120(%rip)
movups  %xmm6, a+8(%rip)
movups  %xmm3, a+56(%rip)
movups  %xmm2, a+72(%rip)
movups  %xmm1, a+88(%rip)
movups  %xmm0, a+104(%rip)
addq$16, %rsp
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE0:
.size   f0, .-f0
.p2align 4
.globl  f2
.type   f2, @function
f2:
.LFB1:
.cfi_startproc
pushq   %rbx
.cfi_def_cfa_offset 16
.cfi_offset 3, -16
movl$120, %edx
movl%edi, %ebx
movl$a+4, %esi
movl$a+8, %edi
callmemmove
movl%ebx, a+4(%rip)
popq%rbx
.cfi_def_cfa_offset 8
ret
.cfi_endproc
.LFE1:
.size   f2, .-f2
.globl  a
.bss
.align 32
.type   a, @object
.size   a, 128
a:
.zero   128
.ident  "GCC: (GNU) 10.0.1 20200212 (experimental)"
.section.note.GNU-stack,"",@progbits

[Bug sanitizer/93731] [10 regression] asan tests cause kernel panic on Darwin 11

2020-02-13 Thread iains at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93731

--- Comment #3 from Iain Sandoe  ---
These systems are EOL so we can't expect any fixes to the systems themselves.

The question is "is the latest imported as an version even supposed to support
10.7"?

I have a patch to unsupport the sanitiser for <= 10.6 [where it has been
unsupported upstream since at least the last release].  That is something that
I can apply immediately.

If the latest sanitiser code is _supposed_ to work on 10.7 - we should at least
take a cursory look at why/where it's failing before punting.

I agree that spending much time on making the sanitisers work on EOL machines
is not a priority.  I don't have access to my 10.7 box right now - but will
take a look next week.

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

2020-02-13 Thread sgk at troutmask dot apl.washington.edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678

--- Comment #4 from Steve Kargl  ---
On Thu, Feb 13, 2020 at 03:46:17PM +, mail.luis at web dot de wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678
> 
> --- Comment #3 from Luis Kornblueh  ---
> Thanks @kargl for simplifing my still very long case. However, a bug has been
> introduced in this version.
> 
> The nested transfers cannot be split into two as the result of the first
> transfer is not a character :: c(1) result, but, in the nested case a 
> presumably  character :: tmp(4) array to keep an integer. which gets passed to
> the outer transfer. A write another, a bit bigger case, doing things 
> correctly.
> 
> I created a new testcase, a little bit larger, but, as I think, correct
> Fortran.
> 

I was trying to get to the minimum code required to
trigger the bug.

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

2020-02-13 Thread peter.bisroev at groundlabs dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

Peter Bisroev  changed:

   What|Removed |Added

  Attachment #47829|0   |1
is obsolete||

--- Comment #169 from Peter Bisroev  ---
Created attachment 47839
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47839=edit
GCC 4.9.4 gimple-expr.c dump (aCC)

[Bug fortran/93736] Add .f18 and .F18 file suffixes

2020-02-13 Thread thenlich at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736

--- Comment #2 from Thomas Henlich  ---
I don't know why the Fortran compiler doesn't treat all files as free-form
Fortran source files, unless they have a known extension indicating otherwise.

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

2020-02-13 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93713

Jason Merrill  changed:

   What|Removed |Added

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

[Bug tree-optimization/93734] [8/9/10 Regression] Invalid code generated with -O2 -march=haswell -ftree-vectorize

2020-02-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93734

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
#c2 isn't miscompiled since r10-4543-g599bd99078439b9f11cb271aa919844318381ec5
and the miscompilation started with
r8-6708-g85c5e2f576fd41e1ab5620cde3c63b3ca6673bea

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

2020-02-13 Thread mail.luis at web dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678

--- Comment #3 from Luis Kornblueh  ---
Thanks @kargl for simplifing my still very long case. However, a bug has been
introduced in this version.

The nested transfers cannot be split into two as the result of the first
transfer is not a character :: c(1) result, but, in the nested case a 
presumably  character :: tmp(4) array to keep an integer. which gets passed to
the outer transfer. A write another, a bit bigger case, doing things correctly.

I created a new testcase, a little bit larger, but, as I think, correct
Fortran.

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

2020-02-13 Thread mail.luis at web dot de
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678

--- Comment #2 from Luis Kornblueh  ---
Created attachment 47838
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47838=edit
New testcase

[Bug c++/93643] [10 Regression] Static function pointer inside inline function with "C" linkage is not mangled

2020-02-13 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93643

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/93736] Add .f18 and .F18 file suffixes

2020-02-13 Thread kargl at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #1 from kargl at gcc dot gnu.org ---
IMHO, this should be closed.  The file naming scheme does not imply a standard.
 It implies fixed-form versus free-form.  It was a mistake to add f03, f08,
etc.

[Bug fortran/93736] New: Add .f18 and .F18 file suffixes

2020-02-13 Thread thenlich at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93736

Bug ID: 93736
   Summary: Add .f18 and .F18 file suffixes
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thenlich at gcc dot gnu.org
  Target Milestone: ---

The Fortran compiler should recognize Fortran source files with the .f18 and
.F18 filename extension.

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

2020-02-13 Thread kevin at hart dot mn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93705

Kevin Hartman  changed:

   What|Removed |Added

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

--- Comment #1 from Kevin Hartman  ---
I misread the spec. “Non-mutable” means “not marked with the ‘mutable’
specifier.

[Bug tree-optimization/93734] [8/9/10 Regression] Invalid code generated with -O2 -march=haswell -ftree-vectorize

2020-02-13 Thread amonakov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93734

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #3 from Alexander Monakov  ---
I tried to make an equivalent C testcase, but complex ops don't map 1:1 from
Fortran, so it's a bit difficult. Nevertheless, here's a somewhat similar
testcase that aborts on 8/9, works on trunk, but IR and resulting assembly look
quite different:

( needs -O2 -ftree-vectorize -mfma -fcx-limited-range )

__attribute__((noipa))
static
_Complex double
test(_Complex double * __restrict a,
 _Complex double * __restrict x,
 _Complex double t, long jx)
{
long i, j;

for (j = 6, i = 3; i>=0; i--, j-=jx)
x[j] -= t*a[i];

return x[4];
}

int main()
{
_Complex double a[5] = {1, 1, 1, 1, 10};
_Complex double x[9] = {1,1,1,1,1,1,1,1,1};
if (test(a, x, 1, 2))
__builtin_abort();
}

[Bug tree-optimization/93734] [8/9/10 Regression] Invalid code generated with -O2 -march=haswell -ftree-vectorize

2020-02-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93734

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Known to work||10.0
  Known to fail|10.0|

--- Comment #2 from Richard Biener  ---
Hmm, it seems to be fixed on trunk.

Testcase that aborts on failure, we probably have a duplicate.

subroutine test(incx)
  implicit none
  integer i,incx,jx
  double complex a(5),x(9),temp

  a(1:4)=1
  a(5)=10
  x(1:9)=1

  jx = 9
  temp = x(9)
  do i = 4,1,-1
 jx = jx - incx
 x(jx) = x(jx) - temp*a(i)
  enddo

  if (x(5).ne.0) call abort
end subroutine test

program bug
  call test(2)
end program bug

[Bug tree-optimization/93734] [8/9/10 Regression] Invalid code generated with -O2 -march=haswell -ftree-vectorize

2020-02-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93734

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
   Priority|P3  |P2
 Status|UNCONFIRMED |NEW
  Known to work||7.5.0
   Keywords||wrong-code
   Last reconfirmed||2020-02-13
  Component|fortran |tree-optimization
 Blocks||53947
 Ever confirmed|0   |1
Summary|Invalid code generated with |[8/9/10 Regression] Invalid
   |-O2 -march=haswell  |code generated with -O2
   |-ftree-vectorize|-march=haswell
   ||-ftree-vectorize
   Target Milestone|--- |8.4
  Known to fail||10.0, 8.1.0, 8.3.1, 9.1.0,
   ||9.2.1

--- Comment #1 from Richard Biener  ---
It works fine with GCC 7.5.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug gcov-profile/93735] New: [GCOV] incorrect coverage for calling variable arguments function with incremental expression in its parameter list

2020-02-13 Thread yangyibiao at hust dot edu.cn
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93735

Bug ID: 93735
   Summary: [GCOV] incorrect coverage for calling variable
arguments function with incremental expression in its
parameter list
   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
int v = 8;

__attribute__((noinline)) int foo(int x, int y, ...) { return x; }

inline __attribute__((always_inline, gnu_inline)) int bar(int x, ...) { return
foo(x, 1, 2); }

int main(void)
{
  bar(0, ++v, 1);
  if (bar(0, ++v, 1) != 0)
return 1;
  return 0;
}


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

-:0:Source:small.c
-:0:Graph:small.gcno
-:0:Data:small.gcda
-:0:Runs:1
-:1:int v = 8;
-:2:
2:3:__attribute__((noinline)) int foo(int x, int y, ...) { return x; }
-:4:
#:5:inline __attribute__((always_inline, gnu_inline)) int bar(int x,
...) { return foo(x, 1, 2); }
-:6:
1:7:int main(void)
-:8:{
1:9:  bar(0, ++v, 1);
2:   10:  if (bar(0, ++v, 1) != 0)
#:   11:return 1;
1:   12:  return 0;
-:   13:}



### We can find that: Line #9 is marked as executed one time. 
### However, Line #10 is wrongly marked as executed two times. 
### when removing ++v in its parameter list, the coverage will be correct. 


[Bug fortran/93734] New: Invalid code generated with -O2 -march=haswell -ftree-vectorize

2020-02-13 Thread bartoldeman at users dot sourceforge.net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93734

Bug ID: 93734
   Summary: Invalid code generated with -O2 -march=haswell
-ftree-vectorize
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bartoldeman at users dot sourceforge.net
  Target Milestone: ---

Created attachment 47837
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47837=edit
Fortran code that prints 0 if correct, and -9 if miscompiled

The attached code prints -9. if compiled using

gfortran -O2 -march=haswell -ftree-vectorize bug.f90 -o bug
./bug
  -9.
using
GNU Fortran (Debian 8.3.0-6) 8.3.0
Copyright (C) 2018 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.

also reproduceable on GCC 9.2.0, but not with GCC 7.3.0 and earlier.

The correct answer is 1-1=0.

(I found this issue first when compiling the reference BLAS using those options
and running the "zblat2" tests, the test is a much reduced version of ztrsv,
see
http://www.netlib.org/lapack/explore-html/dc/dc1/group__complex16__blas__level2_ga99cc66f0833474d6607e6ea7dbe2f9bd.html#ga99cc66f0833474d6607e6ea7dbe2f9bd)

[Bug target/93656] FAIL: gcc.target/i386/pr67770.c execution test with -fcf-protection

2020-02-13 Thread cvs-commit at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93656

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

https://gcc.gnu.org/g:1d69147af203d4dcd2270429f90c93f1a37ddfff

commit r10-6622-g1d69147af203d4dcd2270429f90c93f1a37ddfff
Author: H.J. Lu 
Date:   Thu Feb 13 05:28:38 2020 -0800

i386: Skip ENDBR32 at the target function entry

Skip ENDBR32 at the target function entry when initializing trampoline.

Tested on Linux/x86-64 CET machine with and without -m32.

gcc/

PR target/93656
* config/i386/i386.c (ix86_trampoline_init): Skip ENDBR32 at
the target function entry.

gcc/testsuite/

PR target/93656
* gcc.target/i386/pr93656.c: New test.

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

2020-02-13 Thread markeggleston at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93714

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #2 from markeggleston at gcc dot gnu.org ---
Patch in comment 1 produces:

z1.f90 -> pr93714_1.f90

pr93714_1.f90:3:4:

3 |character, pointer :: b => a
  |1
Error: Unclassifiable statement at (1)
pr93714_1.f90:2:13:

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

z2.f90 -> pr93714_1.f90

pr93714_2.f90:3:4:

3 |character(:), pointer :: b => a
  |1
Error: Unclassifiable statement at (1)
pr93714_2.f90:2:13:

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

Can do better than "Unclassifiable statement".

Moving the check for lvalue being a character to after the handling of pointer
and target attributes:

diff --git a/gcc/fortran/expr.c b/gcc/fortran/expr.c
index a9698c3e3d2..79e00b4112a 100644
--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -4222,13 +4222,6 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr
*rvalue,
   if (rvalue->expr_type == EXPR_NULL)
 return true;

-  if (lvalue->ts.type == BT_CHARACTER)
-{
-  bool t = gfc_check_same_strlen (lvalue, rvalue, "pointer assignment");
-  if (!t)
-   return false;
-}
-
   if (rvalue->expr_type == EXPR_VARIABLE && is_subref_array (rvalue))
 lvalue->symtree->n.sym->attr.subref_array_pointer = 1;

@@ -4284,6 +4277,13 @@ gfc_check_pointer_assign (gfc_expr *lvalue, gfc_expr
*rvalue,
}
 }

+  if (lvalue->ts.type == BT_CHARACTER)
+{
+  bool t = gfc_check_same_strlen (lvalue, rvalue, "pointer assignment");
+  if (!t)
+   return false;
+}
+
   if (is_pure && gfc_impure_variable (rvalue->symtree->n.sym))
 {
   gfc_error ("Bad target in pointer assignment in PURE "

and omitting Steve Kargl's patch results in:

pr93714_1.f90:3:31:

3 |character, pointer :: b => a
  |   1
Error: Pointer assignment target in initialization expression does not have the
TARGET attribute at (1)
pr93714_1.f90:2:13:

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

and

pr93714_2.f90:3:34:

3 |character(:), pointer :: b => a
  |  1
Error: Pointer assignment target in initialization expression does not have the
TARGET attribute at (1)
pr93714_2.f90:2:13:

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

Running make with check-fortran resulted in char_pointer_assign_6.f90 failing:

char_pointer_assign_6.f90:8:2:

8 |   p1 => s1(2:3) ! { dg-error "Unequal character lengths \\(20/2\\)" }
  |  1
Error: Unequal character lengths (20/2) in pointer assignment at (1)
char_pointer_assign_6.f90:9:8:

9 |   p1 => c(1:) ! { dg-error "Unequal character lengths \\(20/4\\)" }
  |1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
char_pointer_assign_6.f90:10:8:

   10 |   p1 => c(:4) ! { dg-error "Unequal character lengths \\(20/4\\)" }
  |1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)

The variable c does not have the target attribute so the unequal character
lengths messages should not have occurred.

I'm now modifying char_pointer_assign_6.f90 and adding test cases so I can send
a patch upstream for approval.

[Bug fortran/93733] New: F2008: G0.d output editing for integer/logical/character data

2020-02-13 Thread thenlich at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93733

Bug ID: 93733
   Summary: F2008: G0.d output editing for
integer/logical/character data
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thenlich at gcc dot gnu.org
  Target Milestone: ---

This example compiles and runs.

But the second part should be rejected with -std=f2008 because these are
Fortran 2018 features.


program g0d_ilc
!F2008:
write(*, "(g0)")  23
write(*, "(g0)")  .true.
write(*, "(g0)")  'hello'
!F2018:
write(*, "(g0.2)")  -23
write(*, "(g0.2)")  .true.
write(*, "(g0.2)")  'hello'
end


gfortran -std=f2008 g0d_ilc.f90 && ./a.out
23
T
hello
-23
T
hello


The new features of Fortran 2018 (ISO/IEC JTC1/SC22/WG5 N2145):

"The g0.d edit descriptor can be used to specify the output of integer,
logical, and character data. It follows the rules for the i0, l1, and a edit
descriptors, respectively."

F2008:

10.7.5.2.1 Generalized integer editing
When used to specify the input/output of integer data, the Gw.d and Gw.d Ee
edit descriptors follow the rules for the Iw edit descriptor (10.7.2.2), except
that w shall not be zero. When used to specify the output of integer data, the
G0 edit descriptor follows the rules for the I0 edit descriptor.

10.7.5.3 Generalized logical editing
When used to specify the input/output of logical data, the Gw.d and Gw.d Ee
edit descriptors follow the rules for the Lw edit descriptor (10.7.3). When
used to specify the output of logical data, the G0 edit descriptor follows the
rules for the L1 edit descriptor. 

10.7.5.4 Generalized character editing
When used to specify the input/output of character data, the Gw.d and Gw.d Ee
edit descriptors follow the rules for the Aw edit descriptor (10.7.4). When
used to specify the output of character data, the G0 edit descriptor follows
the rules for the A edit descriptor with no field width.

F2018:

13.7.5.2.2 Generalized integer editing
When used to specify the input/output of integer data, the Gw, Gw.d, and Gw.d
Ee edit descriptors follow the rules for the Iw edit descriptor (13.7.2.2).
Note that w cannot be zero for input editing (13.7.5.1). 

13.7.5.3 Generalized logical editing
When used to specify the input/output of logical data, the Gw.d and Gw.d Ee
edit descriptors with nonzero w follow the rules for the Lw edit descriptor
(13.7.3). When used to specify the output of logical data, the G0 and G0.d edit
descriptors follow the rules for the L1 edit descriptor. 

13.7.5.4 Generalized character editing
When used to specify the input/output of character data, the Gw.d and Gw.d Ee
edit descriptors with nonzero w follow the rules for the Aw edit descriptor
(13.7.4). When used to specify the output of character data, the G0 and G0.d
edit descriptors follow the rules for the A edit descriptor with no field
width.

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

2020-02-13 Thread dave.anglin at bell dot net
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577

--- Comment #168 from dave.anglin at bell dot net ---
On 2020-02-13 12:24 a.m., peter.bisroev at groundlabs dot com wrote:
> Tonight I have been trying to find a test case where this problem can be
> reproduced with gcc and then compiled with aCC. Unfortunately no luck so far. 
>
> With objdump I can see PCREL21B relocations in my .o files. However after the
> final linking, disassembly shows direct short branch if the distance is small
> enough and a call through a stub with brl.few if the distance is large enough.
> I have almost no experience with IA-64 arch, but this behavior seems expected
> to me.
The ia64 PCREL21B relocation is very similar to the PA-RISC 2.0
R_PARISC_PCREL22F relocation.
These determine the maximum branch distance by a pc-relative branch.  I believe
ia64 aligns
code on 8-byte boundaries.  PA-RISC aligns on 4-byte boundaries.  So, in both
cases a branch
is capable of branching about 8 MB from call point.

There seems to be something broken regarding stub insertion for calls to weak
functions.  Are we
using the correct branch form for calls to weak?  There doesn't seem to be a
problem with branches
to functions that aren't defined in the module.

Could you try compiling sancov.c from gcc-8 with aCC in C++ mode.  Use -S to
get assembler output.
What happens to weak calls (e.g., the one I pointed out previously)?

Dave

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

2020-02-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93576

Jakub Jelinek  changed:

   What|Removed |Added

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

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

Untested fix.

[Bug target/93722] rorq is not produced for rotate on some cases

2020-02-13 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93722

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
q is quad word where word is really 16bits.  Stupid x86 world where things are
confusing :).

[Bug lto/93609] gcc -flto -fno-comon places symbols into ".text" section

2020-02-13 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93609

Andrew Pinski  changed:

   What|Removed |Added

 CC||laurent.stacul at gmail dot com

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

[Bug lto/93732] [10 Regression] Incorrect symbol type when activating LTO a compile step

2020-02-13 Thread pinskia at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93732

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 93609.  The issue is mostly inside binutils.  The duplicated bug
report explains more.

-fno-common is the default which caused the major difference between the
versions and why it is a regression.

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

[Bug sanitizer/93731] [10 regression] asan tests cause kernel panic on Darwin 11

2020-02-13 Thread ro at CeBiTec dot Uni-Bielefeld.DE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93731

--- Comment #2 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #1 from Jakub Jelinek  ---
> So you could just disable asan and keep ubsan (set ASAN_SUPPORTED=no in
> libsanitizer/configure.tgt for a particular darwin OS version, and if it is
> 32-bit only, also test x$ac_cv_sizeof_void_p = x4 ?

Right now there's only [LT]SAN_SUPPORTED in configure.{ac,tgt}.  Sure
ASAN_SUPPORTED (and/or UBSAN_SUPPORTED) could be added, but I doubt it's
worth the effort.

I have a prototype patch that just sets UNSUPPORTED=1 for *86*-apple-darwin11*.

> Of course, trying to workaround kernel bugs this way is weird, but if it isn't
> supported anymore or Apple isn't willing to fix their bugs...

Mac OS X 10.7 is almost 9 years old by now and long past support.  I
don't feel particularly inclined to reghunt which gcc/sanitizer change
caused this, let alone debug the Darwin kernel either.

[Bug inline-asm/93027] ICE: in match_reload, at lra-constraints.c:1060

2020-02-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93027

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
So fixed for trunk?  GCC 9 seems to ICE on this too in the same spot (but with
-fchecking only or --enable-checking=yes), GCC 8 in extract_constraint_insn
(but again with checking only).

[Bug lto/93732] New: [10 Regression] Incorrect symbol type when activating LTO a compile step

2020-02-13 Thread laurent.stacul at gmail dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93732

Bug ID: 93732
   Summary: [10 Regression] Incorrect symbol type when activating
LTO a compile step
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: laurent.stacul at gmail dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

Hello,

With gcc (GCC) 10.0.1 20200211 and the following program:

#ifdef __cplusplus
extern "C" {
#endif
char nm_test_var;
void nm_test_func(void);
void nm_test_func(void){}
#ifdef __cplusplus
}
#endif
int main(){nm_test_var='a';nm_test_func();return(0);}

If you compile with the LTO support, with the command:

$  gcc -c  -DNDEBUG -O3 -std=gnu17 -fno-working-directory -ggdb3 -flto
-ffat-lto-objects -fuse-linker-plugin conftest.c

The symbol nm_test_var will be flagged as in text section.

$ nm conftest.o
 T main
 T nm_test_func
 T nm_test_var

Whereas, compiling without LTO support as follow:

$ $  gcc -c  -DNDEBUG -O3 -std=gnu17 -fno-working-directory -ggdb3 -fno-lto
-ffat-lto-objects -fuse-linker-plugin conftest.c

Will give:

$ nm conftest.o
 T main
 T nm_test_func
 B nm_test_var

I also compared with gcc (GCC) 9.2.1 20191112. With or without LTO, the result
is the same but the symbol nm_test_var is neither in the text section not in
the BSS one, but in the common section:

 T main
 T nm_test_func
 C nm_test_var

For info, this leads to errors when you build libtoolized libraries (error at
configure step).

Regards,
Laurent

[Bug c++/93639] [c++2a] Segfault on non type template parameter and consteval (master)

2020-02-13 Thread raphael.grimm at kit dot edu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93639

--- Comment #4 from raphael grimm  ---
Created attachment 47835
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47835=edit
reduced to 11 lines and no includes

http://coliru.stacked-crooked.com/a/be3bbfdf6a59b45e

on g++ (GCC) 9.2.0

output:

main.cpp:8:26: internal compiler error: Segmentation fault
8 | using type = B;
  |  ^
0xb5c5ff crash_signal
../.././gcc/toplev.c:326
0x5cb5c3 resolve_args
../.././gcc/cp/call.c:4350
0x5da0c7 build_new_function_call(tree_node*, vec**, int)
../.././gcc/cp/call.c:4469
0x6bbeaf do_class_deduction
../.././gcc/cp/pt.c:27497
0x6bbeaf do_auto_deduction(tree_node*, tree_node*, tree_node*, int,
auto_deduction_context, tree_node*, int)
../.././gcc/cp/pt.c:27556
0x6c492d convert_template_argument
../.././gcc/cp/pt.c:8086
0x6c492d convert_template_argument
../.././gcc/cp/pt.c:7859
0x6cf795 coerce_template_parms
../.././gcc/cp/pt.c:8589
0x6d0b2a lookup_template_class_1
../.././gcc/cp/pt.c:9399
0x6d0b2a lookup_template_class(tree_node*, tree_node*, tree_node*, tree_node*,
int, int)
../.././gcc/cp/pt.c:9769
0x6ebe5d finish_template_type(tree_node*, tree_node*, int)
../.././gcc/cp/semantics.c:3312
0x6929c5 cp_parser_template_id
../.././gcc/cp/parser.c:16481
0x692b07 cp_parser_class_name
../.././gcc/cp/parser.c:23276
0x695790 cp_parser_qualifying_entity
../.././gcc/cp/parser.c:6696
0x695790 cp_parser_nested_name_specifier_opt
../.././gcc/cp/parser.c:6382
0x6931f5 cp_parser_simple_type_specifier
../.././gcc/cp/parser.c:17839
0x68a1a5 cp_parser_type_specifier
../.././gcc/cp/parser.c:17507
0x69d118 cp_parser_type_specifier_seq
../.././gcc/cp/parser.c:21985
0x69a4b4 cp_parser_type_id_1
../.././gcc/cp/parser.c:21814
0x69e902 cp_parser_type_id
../.././gcc/cp/parser.c:21893
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug sanitizer/93731] [10 regression] asan tests cause kernel panic on Darwin 11

2020-02-13 Thread jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93731

--- Comment #1 from Jakub Jelinek  ---
So you could just disable asan and keep ubsan (set ASAN_SUPPORTED=no in
libsanitizer/configure.tgt for a particular darwin OS version, and if it is
32-bit only, also test x$ac_cv_sizeof_void_p = x4 ?
Of course, trying to workaround kernel bugs this way is weird, but if it isn't
supported anymore or Apple isn't willing to fix their bugs...

[Bug rtl-optimization/93730] [Bug] internal compiler error: in make_decl_rtl, at varasm.c:1375

2020-02-13 Thread akhilesh.k at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93730

--- Comment #2 from Akhilesh Kumar  ---
Working on Arm architecture.
I am trying to reproduce the same with sample test case

[Bug rtl-optimization/93730] [Bug] internal compiler error: in make_decl_rtl, at varasm.c:1375

2020-02-13 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93730

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |WAITING
   Last reconfirmed||2020-02-13
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Please provide a testcase.  What architecture is this on?

[Bug sanitizer/93731] [10 regression] asan tests cause kernel panic on Darwin 11

2020-02-13 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93731

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |10.0

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

2020-02-13 Thread markeggleston at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93715

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #1 from markeggleston at gcc dot gnu.org ---
Confirmed using compiler built at commit
https://gcc.gnu.org/g:8ea884b85e338d09b14e6a54043c53ae0c1b1fe9

ICE also occurs for 9.1 and 9.2 releases.

[Bug sanitizer/93731] New: [10 regression] asan tests cause kernel panic on Darwin 11

2020-02-13 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93731

Bug ID: 93731
   Summary: [10 regression] asan tests cause kernel panic on
Darwin 11
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
iains at gcc dot gnu.org, jakub at gcc dot gnu.org, kcc at 
gcc dot gnu.org,
marxin at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-apple-darwin11.4.2
Target: x86_64-apple-darwin11.4.2
 Build: x86_64-apple-darwin11.4.2

Sometime after 20191101, my mainline bootstraps on Mac OS X 10.7/Darwin 11
began
to fail completely.  Initially it seemed the Mac minis I've been using remotely
had just been turned off willy-nilly, but even after it had been assured that
this
wasn't the case, the machines still stopped in the middle of make check without
any indication of what had happened.

Only after I'd run such a bootstrap in a VirtualBox VM (with Mac OS X 10.7.5)
did
I see that the machines (obviously like bare metal) crashed with a kernel panic
for some asan tests (I've seen alloca_big_alignment.exe,
alloca_detect_custom_size. and bitfield-1.exe).  Only asan tests seem to be
affected (I didn't try any more given the tedious nature of the failure) and
probably only 64-bit ones (I do run multilib tests on Darwin if possible).

As expected, the ubsan tests still work.

Here's the gist of the panics (I do have screen shots if need be):

panic(cpu 0 caller 0xff8002c4794): Kernel trap at 0xff800053ae2, type
14=page fault, registers:
[...]

Debugger called: 
Backtrace (CPU 0),Frame : Return Address
[...] mach_kernel : _panic + 0x252
_kernel_trap + 0x6a4
_return_from_trap + 0xcd
_fdexec + 0x172
_kco_ma_addsample + 0x162c
_kco_ma_addsample + 0x2a80
_posix_spawn + 0xab6
_unix_syscall64 + 0x1fb
_hndl_unix_scall64 + 0x13

BSD process name corresponding to current thread: alloca_big_align

The obvious immediate fix is to disable libsanitizer on Darwin 11.  While in
theory one could keep the 32-bit tests if it really turns out that they
continue
to work and the ubsan ones, it's probably not worth the effort given the age of
the OS version and missing provision for enabling ubsan separately.

[Bug c++/93667] [10 regression] ICE in esra with nested [[no_unique_address]] field

2020-02-13 Thread jamborm at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93667

--- Comment #5 from Martin Jambor  ---
It is easy to prevent the ICE with the following, which prevents total
scalarization from happening.  However, if someone marked a field with
such an attribute, the encompassing structure perhaps should be
optimized a much as we can?

So I am thinking of adding a predicate
bunch_of_empty_records_p which will return true for a type which only
consists of records which only have field_decls which are other
records but nothing else and still allow total scalarization of
those.

The easy fix is:

--- a/gcc/tree-sra.c
+++ b/gcc/tree-sra.c
@@ -958,6 +958,9 @@ scalarizable_type_p (tree type, bool const_decl)
   if (type_contains_placeholder_p (type))
 return false;

+  bool have_predecesor_field = false;
+  HOST_WIDE_INT prev_pos = 0;
+
   switch (TREE_CODE (type))
   {
   case RECORD_TYPE:
@@ -966,6 +969,14 @@ scalarizable_type_p (tree type, bool const_decl)
{
  tree ft = TREE_TYPE (fld);

+ HOST_WIDE_INT pos = int_bit_position (fld);
+ if (have_predecesor_field
+ && pos <= prev_pos)
+   return false;
+
+ have_predecesor_field = true;
+ prev_pos = pos;
+
  if (DECL_BIT_FIELD (fld))
return false;

[Bug c++/93093] __builtin_source_location reports values for default arguments not aligned with the Standard

2020-02-13 Thread jason at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93093

--- Comment #6 from Jason Merrill  ---
This is https://github.com/cplusplus/nbballot/issues/167

In CWG today we decided that since this is all compiler magic anyway, we can be
a bit more magical to get around this problematic interaction with consteval.

[Bug rtl-optimization/93730] New: [Bug] internal compiler error: in make_decl_rtl, at varasm.c:1375

2020-02-13 Thread akhilesh.k at samsung dot com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93730

Bug ID: 93730
   Summary: [Bug] internal compiler error: in make_decl_rtl, at
varasm.c:1375
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: akhilesh.k at samsung dot com
  Target Milestone: ---

Hello 

I am Getting "internal compiler error: in make_decl_rtl, at varasm.c:1375"
during RTL optimization, but works fine if i pass value instead of variable
name 


#g++ -c -Wno-format-truncation -Wno-narrowing MYTV/Picture.cpp
-I=/usr/include/kernel-headers/ -I=/usr/include/mylog/
-I/usr/include/kernel-interfaces/ 
during RTL pass: expand
/home/user/MY/Picture.cpp:1521:13: internal compiler error: in make_decl_rtl,
at varasm.c:1375
1521 | int GammaTable[RGB_LAST][SeedCnt] = {{0,},};   /Where my seed count
is 1024 
  | ^~

but code works fine if i pass direct Value in array 

-int GammaTable[RGB_LAST][SeedCnt] = {{0,},};
int GammaTable[RGB_LAST][1024] = {{0,},};
#g++ -c -Wno-format-truncation -Wno-narrowing MYTV/Picture.cpp
-I=/usr/include/kernel-headers/ -I=/usr/include/mylog/
-I/usr/include/kernel-interfaces/ 
#

Unfortunately I can share Picture.cpp code 
but I am trying to reproduce this issue with some sample test application

  1   2   >