[Bug target/93270] [8/9/10 Regression] DSE removes store incorrectly

[rguenth at gcc dot gnu.org]

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

--- Comment #2 from Richard Biener  ---
And pasting from my ml analysis:

So clearly something is wrong:

 
unit-size 
align:128 warn_if_not_align:0 symtab:0 alias-set 2
canonical-type 0x7682d3f0 precision:80
pointer_to_this >

and thus GET_MODE_SIZE (XFmode) == 16.  The target cannot possibly
just store 12 bytes here,
it lies.  Why's XFmode not 12 bytes but with 8/16 byte alignment?
Does the ABI say sizeof(long double) is 16?

That said, a mode-has-padding or whatever should be reflected in
TYPE_SIZE & friends as well, inconsistencies
there just make things worse.  Now they're at least consistently wrong.

[Bug ipa/93144] [10 Regression] 459.GemsFDTD debug info size increase by 50% since r279563

[marxin at gcc dot gnu.org]

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

--- Comment #6 from Martin Liška  ---
(In reply to Jan Hubicka from comment #5)
> Well, the problem was debug info getting bigger due to more inlining? I guss
> in that case we could close it. That patch is expected to allow more inlines.

There's a code increase of 6%, but the debug info increase of 50%.
Is it something you would like to take a look?

[Bug lto/92600] [9/10 Regression] ICE: symtab_node::verify failed, building 523.xalancbmk_r with -flto -fno-inline since r267359

[marxin at gcc dot gnu.org]

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

--- Comment #7 from Martin Liška  ---
(In reply to Jan Hubicka from comment #6)
> Well, because the source files differs, the comdat group differs and the
> loosing one has fewer symbols in it.  So we end up keeping some symbols from
> the other comdat group that happens to have same name.  The compilation is
> bound to fail, so I guess question is how best to silence the ICE.  I
> suppose we may get around by dissoling comdat groups of all UNDEF symbols

Btw. is this a violation of ODR? Maybe, we could provide a warning for such a
situation?

[Bug lto/89358] [8 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #20 from Martin Liška  ---
(In reply to Jan Hubicka from comment #19)
> I think backporting would be a good idea :) If you beat me on it even
> better. Now I need to set up my trees in git...

I'm going to do the backport.

[Bug ipa/92240] [10 regression] ICE in duplicate, at ipa-prop.c:3883

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #11 from Martin Liška  ---
Yes, it's fixed since g:051d8a5faa3b37b0.

[Bug fortran/93263] -fno-automatic and RECURSIVE

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

 CC||markeggleston at gcc dot 
gnu.org

--- Comment #1 from markeggleston at gcc dot gnu.org ---
https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=274565

I will investigate.

[Bug target/93270] [8/9/10 Regression] DSE removes store incorrectly

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
The question that pops up is more general.  If you consider a store with
a mode that has GET_MODE_BITSIZE > GET_MODE_PRECISION, what happens to the
off-precision bits?  So I would guess the DSE issue applies to PSImode on
some targets as well.

We could try to handle this conservatively.  Assume the "worst" for individual
transforms - for loads that the off-precision bits are still "important",
like the HW might trap if they are not in some canonical form, and for DSE
do not assume the bits are touched while for CSEing a load assume they are.

[Bug tree-optimization/93271] New: SRA producing wrong code on denormals

[hubicka at gcc dot gnu.org]

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

Bug ID: 93271
   Summary: SRA producing wrong code on denormals
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hubicka at gcc dot gnu.org
  Target Milestone: ---

hubicka@lomikamen-jh:~$ cat t2.c
#include 
union test {int a; float b;};

__attribute__ ((noinline)) union test set()
{
  union test r;
  r.a = 0x7f842335;
  return r;
}
__attribute__ ((noinline)) void get(union test a)
{
  if (a.a != 0x7f842335)
   abort ();
}
volatile int val;

int
main ()
{
  union test a = set();
  while (val)
a.b++;
  get (a);
  return 0;
}
hubicka@lomikamen-jh:~$ /aux/hubicka/trunk-install/bin/gcc -O2 -m32 t2.c
hubicka@lomikamen-jh:~$ ./a.out
Aborted

[Bug tree-optimization/93271] SRA producing wrong code on denormals

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #1 from Richard Biener  ---
Thought SRA avoids float modes for total scalarization...

[Bug lto/89358] [8 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings

[cvs-commit at gcc dot gnu.org]

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

--- Comment #21 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Martin Liska
:

https://gcc.gnu.org/g:13ef7dc2448c0f9d8981577bb5448ee9b6842b1c

commit r8-9935-g13ef7dc2448c0f9d8981577bb5448ee9b6842b1c
Author: Martin Liska 
Date:   Wed Jan 15 10:41:14 2020 +0100

Backport d2a0371d2641e85c5e6ca396029be32204d976df

Backport from mainline
2019-04-14  Jan Hubicka  

PR lto/89358
* ipa-devirt.c (skip_in_fields_list_p): New.
(odr_types_equivalent_p): Use it.
Backport from mainline
2019-04-14  Jan Hubicka  

PR lto/89358
* g++.dg/lto/pr89358_0.C: New testcase.
* g++.dg/lto/pr89358_1.C: New testcase.

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

[krebbel at gcc dot gnu.org]

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

Bug ID: 93272
   Summary: LRA: EH reg allocated to hold local variable
   Product: gcc
   Version: 5.5.0
Status: UNCONFIRMED
  Severity: major
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: krebbel at gcc dot gnu.org
  Target Milestone: ---

Created attachment 47655
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47655&action=edit
Reduced testcase

When compiling the attached testcase for IBM Z with r253576
g++ t.cpp -S -march=z196 -mtune=zEC12 -O3 -fPIC -msoft-float -std=c++98

local variable p is live from the try block to the catch block and is being put
into r6 although that register is being used as EH reg on IBM Z.

The problem appears to be triggered by having the assignment in the try block
in a loop. Due to that the allocno in the try block gets a region separate from
the region in the catch block. The allocno used in the catch block is correctly
marked as conflicting with the EH hard regs in ira-lives. The allocno in the
catch handler gets r13 assigned which is fine. The other one r6.

In ira-emit a move between the two regions is being generated. Unfortunately
the move is being put into the catch block making r6 live across the eh edge.

The testcase is correctly compiled with more recent GCCs. However, I'm not sure
that LRA is actively preventing this. It rather looks like recent GCCs just
manage to find a register which is ok for both regions.

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

[krebbel at gcc dot gnu.org]

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

--- Comment #1 from Andreas Krebbel  ---
Created attachment 47656
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47656&action=edit
Experimental patch

[Bug tree-optimization/93199] [8/9/10 Regression] Compile time hog in sink_clobbers

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||patch

--- Comment #23 from Martin Liška  ---
> But it's copied.  There's a reason why I didn't tackle it
> (because of this interwided stuff).  But I don't like the
> simple cache-map.

Sure, I've done that in:
https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00862.html

[Bug target/93270] [8/9/10 Regression] DSE removes store incorrectly

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #4 from Richard Biener  ---
Note the C standard says that the other bytes in the union get indetermined
values upon storing to a union member.

[Bug tree-optimization/93271] SRA producing wrong code on denormals

[hubicka at gcc dot gnu.org]

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

--- Comment #2 from Jan Hubicka  ---
Fails at least for gcc 4.9+, but it must be regression compared to pre-tree-ssa
GCCs (which I don't have installed :)

[Bug lto/89358] [8 Regression] Combining -std=c++14 and -std=c++17 objects gives ODR warnings

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
  Known to work||8.3.1
 Resolution|--- |FIXED

--- Comment #22 from Martin Liška  ---
It's fixed now.

[Bug tree-optimization/93271] SRA producing wrong code on denormals

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||wrong-code
 Target||i?86-linux-gnu
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-15
 Ever confirmed|0   |1

--- Comment #3 from Andrew Pinski  ---
(In reply to Richard Biener from comment #1)
> Thought SRA avoids float modes for total scalarization...

It is not doing total scalarization here.

Created a replacement for a offset: 0, size: 32: a$b

Access trees for a (UID: 1941):
access { base = (1941)'a', offset = 0, size = 32, expr = a.b, type = float,
reverse = 0, grp_read = 1, grp_write = 1, grp_assignment_read = 1,
grp_assignment_write = 1, grp_scalar_read = 1, grp_scalar_write = 1,
grp_total_scalarization = 0, grp_hint = 0, grp_covered = 1,
grp_unscalarizable_region = 0, grp_unscalarized_data = 0, grp_same_access_path
= 1, grp_partial_lhs = 0, grp_to_be_replaced = 1, grp_to_be_debug_replaced = 0}
...
  a$b_7 = a.b;
  goto ; [INV]

   :
  _1 = a$b_8;
  _2 = _1 + 1.0e+0;
  a$b_13 = _2;

   :
  # a$b_8 = PHI 
  val.0_3 ={v} val;
  if (val.0_3 != 0)
goto ; [INV]
  else
goto ; [INV]

   :
  a.b = a$b_8;

[Bug c++/93257] consteval functions returning 'void' are rejected when called

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
I guess another use case could be to delete something.
constexpr T *allocate () { return new T (); }
constexpr void deallocate (T *p) { delete T; }

[Bug tree-optimization/93271] [8/9/10 regression] SRA producing wrong code on denormals

[hubicka at gcc dot gnu.org]

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

Jan Hubicka  changed:

   What|Removed |Added

   Keywords|wrong-code  |
 Target|i?86-linux-gnu  |
 Status|NEW |UNCONFIRMED
   Last reconfirmed|2020-01-15 00:00:00 |
Summary|SRA producing wrong code on |[8/9/10 regression] SRA
   |denormals   |producing wrong code on
   ||denormals
 Ever confirmed|1   |0

--- Comment #4 from Jan Hubicka  ---
GCC 4.4 works.

[Bug tree-optimization/93271] [8/9/10 regression] SRA producing wrong code on denormals

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka  ---
Also I think it is violation of C++ memory model since we introduce load+store
pair where there was none before?

[Bug ipa/92077] Multiple independent functions degrades optimizations

[hubicka at gcc dot gnu.org]

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

--- Comment #4 from Jan Hubicka  ---
We have --param comdat-sharing-probablity which says that average comdat
function has only 20% chance to be shared with another copy of same comdat in
other unit. This was introduced because of Firefox developers complaining that
-Os increases size of C++ and I measured that value somehow in 2010 or so.

It may make sense to re-test if that param works as expected today.

[Bug target/92424] [aarch64] Broken code with -fpatchable-function-entry and BTI

[nsz at gcc dot gnu.org]

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

nsz at gcc dot gnu.org changed:

   What|Removed |Added

 Target|aarch64 |aarch64, x86
 CC||nsz at gcc dot gnu.org

--- Comment #4 from nsz at gcc dot gnu.org ---
also affects x86 with -fcf-protection=branch -fpatchable-function-entry=N

that's the same issue so this should not be target specific.

[Bug tree-optimization/93265] memcmp comparisons of structs wrapping a primitive type not as compact/efficient as direct comparisons of the underlying primitive type under -Os

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 CC||msebor at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=85330
 Blocks||83819

--- Comment #2 from Martin Sebor  ---
The strlen pass does have this optimization but the pass only performs it at
-O2 and higher and not with -Os.  I don't know why it doesn't run at all
optimization levels.  Although some of its transformations might increase code
size, on balance, I'd expect it to both decrease it and emit faster code.  For
this example:

$ cat z.c && gcc -Os -S -Wall -fdump-tree-optimized=/dev/stdout -o/dev/stdout
z.c
int f (int x)
{
  return __builtin_memcmp (&x, (int[]){ 42 }, sizeof x) == 0;
}

.file   "z.c"
.text

;; Function f (f, funcdef_no=0, decl_uid=1930, cgraph_uid=1, symbol_order=0)

f (int x)
{
  int D.1932[1];
  int _1;
  _Bool _2;
  int _5;

   [local count: 1073741824]:
  D.1932[0] = 42;
  _1 = __builtin_memcmp (&x, &D.1932, 4);
  _2 = _1 == 0;
  _5 = (int) _2;
  D.1932 ={v} {CLOBBER};
  return _5;

}


.globl  f
.type   f, @function
f:
.LFB0:
.cfi_startproc
subq$40, %rsp
.cfi_def_cfa_offset 48
movl$4, %edx
movl%edi, 12(%rsp)
leaq28(%rsp), %rsi
leaq12(%rsp), %rdi
movl$42, 28(%rsp)
callmemcmp
testl   %eax, %eax
sete%al
addq$40, %rsp
.cfi_def_cfa_offset 8
movzbl  %al, %eax
ret
.cfi_endproc
.LFE0:
.size   f, .-f
.ident  "GCC: (GNU) 10.0.0 20200115 (experimental)"
.section.note.GNU-stack,"",@progbits

Whereas at -O2 the object code is much smaller:

.p2align 4
.globl  f
.type   f, @function
f:
.LFB0:
.cfi_startproc
xorl%eax, %eax
cmpl$42, %edi
sete%al
ret
.cfi_endproc
.LFE0:
    .size   f, .-f
.ident  "GCC: (GNU) 10.0.0 20200115 (experimental)"
.section.note.GNU-stack,"",@progbits

See also pr85330.  I can look into enabling it at all optimization levels for
GCC 11.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83819
[Bug 83819] [meta-bug] missing strlen optimizations

[Bug c++/93273] New: "error: missing definition" and "internal compiler error: verify_ssa failed", in code involving _setjmp

[sbergman at redhat dot com]

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

Bug ID: 93273
   Summary: "error: missing definition" and "internal compiler
error: verify_ssa failed", in code involving _setjmp
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sbergman at redhat dot com
  Target Milestone: ---

With recent trunk (at g:ddd792fa53345180c782494aa597e438a73b6248):

> $ cat test.cc
> void _setjmp(void *);
> struct S { ~S(); };
> void * (* fn)();
> void f();
> void g() {
> S s;
> _setjmp(fn());
> []{ f(); }();
> }

> $ g++ -c test.cc
> test.cc: In function ‘void g()’:
> test.cc:5:6: error: missing definition
> 5 | void g() {
>   |  ^
> for SSA_NAME: .MEM_22 in statement:
> # .MEM_14(ab) = VDEF <.MEM_22>
> S::~S (&s);
> during GIMPLE pass: ehdisp
> test.cc:5:6: internal compiler error: verify_ssa failed
> 0x11c8802 verify_ssa(bool, bool)
> ../../src/gcc/tree-ssa.c:1208
> 0xeeef55 execute_function_todo
> ../../src/gcc/passes.c:1990
> 0xeefc8c do_per_function
> ../../src/gcc/passes.c:1638
> 0xeefc8c execute_todo
> ../../src/gcc/passes.c:2037
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.

If I rename _setjmp to e.g. f2, it compiles fine.

[Bug fortran/93263] -fno-automatic and RECURSIVE

[markeggleston at gcc dot gnu.org]

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

--- Comment #2 from markeggleston at gcc dot gnu.org ---
I had thought I may have caused this but checking out release/gcc-9.2 shows
that the last commit for that release was r274274 from SVN.

[Bug tree-optimization/93271] [8/9/10 regression] SRA producing wrong code on denormals

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Jan Hubicka from comment #5)
> Also I think it is violation of C++ memory model since we introduce
> load+store pair where there was none before?

No because a cannot be accessed by another thread.  It is not TREE_ADDRESSABLE.

[Bug middle-end/93273] "error: missing definition" and "internal compiler error: verify_ssa failed", in code involving _setjmp

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|c++ |middle-end

--- Comment #1 from Andrew Pinski  ---
Note the reason why _setjmp vs f is because _setjmp is marked with returns
twice attribute.

[Bug target/93274] New: target_clones produces symbols with random digits with -fPIC

[rguenth at gcc dot gnu.org]

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

Bug ID: 93274
   Summary: target_clones produces symbols with random digits with
-fPIC
   Product: gcc
   Version: 9.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

__attribute__((target_clones("default", "sse3")))
static void dt_simd_memcpy (const float *const __restrict__ in,
 float *const __restrict__ out,
 const int num_elem)
{
  for(int k = 0; k < num_elem; k++)
out[k] = in[k];
}

void bar(float *in, float *out, int num_elem)
{
  dt_simd_memcpy (in, out, num_elem);
}

differs in generated code on each invocation of GCC with -fPIC

[Bug target/93274] target_clones produces symbols with random digits with -fPIC

[rguenth at gcc dot gnu.org]

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

--- Comment #1 from Richard Biener  ---
Probably caused by

  /* IFUNC's have to be globally visible.  So, if the default_decl is
 not, then the name of the IFUNC should be made unique.  */
  if (TREE_PUBLIC (default_decl) == 0)
{
  char *ifunc_name = make_unique_name (default_decl, "ifunc", true);
  symtab->change_decl_assembler_name (ifunc_alias_decl,
  get_identifier (ifunc_name));

not sure if easy to avoid.

[Bug target/93274] target_clones produces symbols with random digits with -fPIC

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #2 from Martin Liška  ---
Yes, it's caused by the needed public visibility.

[Bug tree-optimization/93271] [8/9/10 regression] SRA producing wrong code on denormals

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #7 from Martin Jambor  ---
I'll take a look

[Bug middle-end/93273] "error: missing definition" and "internal compiler error: verify_ssa failed", in code involving _setjmp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #2 from Richard Biener  ---
Confirmed.  Wrecked by

#1  0x01627e0d in sink_clobbers (bb=, 
sunk=0x391bb90, found_opportunity=0x0)
at /space/rguenther/src/gcc-work1/gcc/tree-eh.c:3683
3683  SET_USE (use_p, gimple_vdef (first_sunk));

thus mine.

[Bug middle-end/93273] "error: missing definition" and "internal compiler error: verify_ssa failed", in code involving _setjmp

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener  ---
(In reply to Richard Biener from comment #2)
> Confirmed.  Wrecked by
> 
> #1  0x01627e0d in sink_clobbers (bb= (9)>, 
> sunk=0x391bb90, found_opportunity=0x0)
> at /space/rguenther/src/gcc-work1/gcc/tree-eh.c:3683
> 3683  SET_USE (use_p, gimple_vdef (first_sunk));
> 
> thus mine.

We're sinking a clobber across a "backedge", those are not picked up by
the queued insertion.  Didn't figure this would happen ... (but also
didn't think about abnormal edges here).  Usually EH doesn't form loops...

[Bug target/93094] [10 Regression] ICE in maybe_gen_insn, at optabs.c:7433

[rguenth at gcc dot gnu.org]

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

--- Comment #4 from Richard Biener  ---
The issue seems to be that we do not find the LOOP_VECTORIZED guarding IFN
because we have inserted code in the preheader during pattern detection it
seems.
Testing a fix.

[Bug tree-optimization/92765] [10 Regression] wrong code for strcmp of a union member

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Keywords||patch
Summary|[10 Regression] Wrong code  |[10 Regression] wrong code
   |caused by folding of|for strcmp of a union
   |-Wstring-compare since  |member
   |r276773 |

--- Comment #24 from Martin Sebor  ---
Minimal patch: https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00880.html

[Bug target/40838] gcc shouldn't assume that the stack is aligned

[mahatma at eu dot by]

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

--- Comment #95 from Dzianis Kahanovich  ---
Just FYI. Novadays, on my Thinkpad tablet with Atom (32 bit userspace Gentoo),
I globally replace patch/-mstackrealign to "-fvect-cost-model=cheap
-fsimd-cost-model=cheap -malign-data=cacheline" and all works fine for -O3 +.
(This is dirty example, as cacheline for some old SSE CPUs are different, etc).

[Bug target/93243] misoptimization: minor changes of the code leads change up to +/- 30% performance on x86_64, -Os faster than -Ofast/O2/O3

[leo at yuriev dot ru]

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

--- Comment #3 from Leo Yuriev  ---
> (a) < (b) is not equal to ((a) - (b) < 0)
> Compiler will trait them differently.
Yes, of course. Moreover, in the second case, correct sorting requires limiting
the range of keys to avoid overflow when comparing by subtraction.

However, such changes in the code shouldn't cause such a significant
performance change. Moreover, this can't be an excuse for generating slower
code compared to clang.

For clarity:
 - We look to the benchmark of heapsort, with random data, in the two cases:
`small` and `large`.
 - GCC shown unexpected performance changes by minor code changes. 
 - CLANG shown stable result and better perfomance than GCC's in all cases.
 - moreover, GCC shown better performance with -Os rather with -Ofast.

So, seems this is a misoptimization bug.

[Bug c++/93275] New: Error when calculating template parameters in recursive template function call

[tahasuf at gmail dot com]

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

Bug ID: 93275
   Summary: Error when calculating template parameters in
recursive template function call
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tahasuf at gmail dot com
  Target Milestone: ---

Clang and GCC 8 can compile the code without any errors. But GCC 9 gives an
error.


#include 
#include 
#include 

namespace math {

/** forward declaration **/
template 
struct array;

/** is_array **/
template 
struct is_array: std::false_type {};

template 
struct is_array>: std::true_type {};

template 
inline constexpr bool is_array_v = is_array::value;

/** array_depth **/
template 
struct array_depth: std::integral_constant {};

template 
struct array_depth>:
std::integral_constant::value>
{};

template 
inline constexpr bool array_depth_v = array_depth::value;

/** array **/
template 
struct array: std::array {

constexpr array operator * (const array& other) const {
array result {};
std::transform(
std::begin(*this),
std::end(*this),
std::begin(other),
std::begin(result),
std::multiplies());
return result;
}

template  > array_depth_v),
std::nullptr_t> = nullptr>
constexpr array operator * (const Other& other) const {
array result {};
std::transform(
std::begin(*this),
std::end(*this),
std::begin(result),
[other](const T& t) { return t * other; });
return result;
}

friend std::ostream&
operator << (std::ostream& out, const array& source) {
out << ")
out << typeid(T).name();
for (auto it: source) {
if constexpr (!is_array_v)
out << " ";
out << it;
}
out << ">";
return out;
}
};
}

int main() {
math::array, 1> a0
{{math::array{{1.f, 2.f, 3.f, 4.f;
std::cout << a0 * 4.f << std::endl;
return 0;
}

[Bug tree-optimization/93247] [10 Regression] ICE in get_load_store_type, at tree-vect-stmts.c:2462 since g:ac190fcea1bebf87

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Richard Sandiford :

https://gcc.gnu.org/g:711421af001b8f4f044f485c78f1d07ed5201656

commit r10-5980-g711421af001b8f4f044f485c78f1d07ed5201656
Author: Richard Sandiford 
Date:   Tue Jan 14 22:24:37 2020 +

PR tree-optimization/93247 - ICE in get_load_store_type

My earlier update_epilogue_loop_vinfo patch introduced an ICE on these
tests for AVX512.  If we use pattern stmts, STMT_VINFO_GATHER_SCATTER_P
is valid for both the original stmt and the pattern stmt, but
STMT_VINFO_MEMORY_ACCESS_TYPE is valid only for the latter.

2020-01-15  Richard Sandiford  

gcc/
PR tree-optimization/93247
* tree-vect-loop.c (update_epilogue_loop_vinfo): Check the access
type of the stmt that we're going to vectorize.

gcc/testsuite/
PR tree-optimization/93247
* gcc.dg/vect/pr93247-1.c: New test.
* gcc.dg/vect/pr93247-2.c: Likewise.

[Bug tree-optimization/93247] [10 Regression] ICE in get_load_store_type, at tree-vect-stmts.c:2462 since g:ac190fcea1bebf87

[rsandifo at gcc dot gnu.org]

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

rsandifo at gcc dot gnu.org  changed:

   What|Removed |Added

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

--- Comment #5 from rsandifo at gcc dot gnu.org  
---
Fixed on master.

[Bug target/93243] misoptimization: minor changes of the code leads change up to +/- 30% performance on x86_64, -Os faster than -Ofast/O2/O3

[leo at yuriev dot ru]

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

--- Comment #4 from Leo Yuriev  ---
Created attachment 47657
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47657&action=edit
testcase source code

[Bug target/93243] misoptimization: minor changes of the code leads change up to +/- 30% performance on x86_64, -Os faster than -Ofast/O2/O3

[leo at yuriev dot ru]

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

--- Comment #5 from Leo Yuriev  ---
Created attachment 47658
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47658&action=edit
testcase makefile

[Bug target/93274] target_clones produces symbols with random digits with -fPIC

[gccbmw at lsmod dot de]

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

Bernhard M. Wiedemann  changed:

   What|Removed |Added

 CC||gccbmw at lsmod dot de

--- Comment #3 from Bernhard M. Wiedemann  ---
The usual way to get deterministic uniqueness
is to hash over all relevant inputs

[Bug analyzer/93276] New: Build error of current trunk indicating "#pragma GCC diagnostic not allowed inside functions"

[manfred99 at gmx dot ch]

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

Bug ID: 93276
   Summary: Build error of current trunk indicating "#pragma GCC
diagnostic not allowed inside functions"
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: manfred99 at gmx dot ch
  Target Milestone: ---

Current trunk (as of today 2020-01-15) does not bootstrap for me on x86_64,
with errors in stage 1, in the analyzer directory:


../../gcc-trunk-source/gcc/gcc/analyzer/constraint-manager.cc:121:1: error:
#pragma GCC diagnostic not allowed inside functions
...
../../gcc-trunk-source/gcc/gcc/analyzer/region-model.cc:89:1: error: #pragma
GCC diagnostic not allowed inside functions
...


This is with
# gcc --version
gcc (SUSE Linux) 4.5.1 20101208 [gcc-4_5-branch revision 167585]
Copyright (C) 2010 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.


Is there a new minimum version of GCC for bootstapping or do I miss
something else? My build environment worked fine for several years now,
on a daily base, and stopped working with the checkin of the analyzer branch.

[Bug libstdc++/93267] std::ranges::begin|end do not work for iota_view when the element and bound type are the same

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |10.0

--- Comment #8 from Jonathan Wakely  ---
The problem is that std::weakly_incrementable only allows signed integers, not
integer-like types. I have a fix.

[Bug analyzer/93276] Build error of current trunk indicating "#pragma GCC diagnostic not allowed inside functions"

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
Thanks for the bug report; am investigating.

For now, --disable-analyzer at configure time ought to disable this code and
allow your builds to continue.

[Bug c++/93275] Error when calculating template parameters in recursive template function call

[tahasuf at gmail dot com]

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

--- Comment #1 from ahmet özhan  ---
: In substitution of 'template
template
> > array_depth_v), std::nullptr_t>::type  > constexpr
math::array math::array::operator*(const Other&) const [with Other
= ; typename std::enable_if<(array_depth_v > >
array_depth_v), std::nullptr_t>::type  = ; T =
float; long unsigned int N = ]':

:56:36:   required from 'constexpr math::array math::array::operator*(const Other&) const [with Other = float; typename
std::enable_if<(array_depth_v > > array_depth_v),
std::nullptr_t>::type  = nullptr; T = math::array; long
unsigned int N = 1]'

:79:20:   required from here

:48:5: internal compiler error: unexpected expression 'N' of kind
template_parm_index

   48 |(array_depth_v > array_depth_v),

  | ^~~~

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

[Bug middle-end/93273] "error: missing definition" and "internal compiler error: verify_ssa failed", in code involving _setjmp

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:37e27de43133b87ceb529d863f0d1f54d87cf2d8

commit r10-5982-g37e27de43133b87ceb529d863f0d1f54d87cf2d8
Author: Richard Biener 
Date:   Wed Jan 15 13:29:25 2020 +0100

middle-end/93273 - fix sinking clobbers across backedges

The previous work to fix PR93199 didn't take into account backedges
when defering insertion.  The following simply avoids to defer in that
case since we know we'll not take secondary opportunities there.

2020-01-15  Richard Biener  

PR middle-end/93273
* tree-eh.c (sink_clobbers): If we already visited the destination
block do not defer insertion.
(pass_lower_eh_dispatch::execute): Maintain BB_VISITED for
the purpose of defered insertion.

* g++.dg/torture/pr93273.C: New testcase.

[Bug tree-optimization/93199] [8/9/10 Regression] Compile time hog in sink_clobbers

[rguenth at gcc dot gnu.org]

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

Bug 93273 Summary: "error: missing definition" and "internal compiler error: 
verify_ssa failed", in code involving _setjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93273

   What|Removed |Added

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

[Bug middle-end/93273] "error: missing definition" and "internal compiler error: verify_ssa failed", in code involving _setjmp

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)

[wilco at gcc dot gnu.org]

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

--- Comment #10 from Wilco  ---
(In reply to Jakub Jelinek from comment #9)
> Any -march= or similar?  Can't reproduce with current trunk, nor
> with even Oct 10 GCC snapshot (crosses in both cases).
> grep -B1 stxr pr92692.s
> doesn't show any stores before stxr.

It's going to be extremely sensitive to register allocation, so it's not clear
it's worth trying to reproduce.

The easiest option is to see whether replacing "reload_completed" with
"epilogue_completed" in aarch64/atomics.md works fine.

[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)

[ktkachov at gcc dot gnu.org]

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

--- Comment #11 from ktkachov at gcc dot gnu.org ---
It will need a target with LSE atomics. -march=armv8.1-a or equivalent. Or add
+lse to an -march or -mcpu line.

[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)

[ktkachov at gcc dot gnu.org]

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

--- Comment #12 from ktkachov at gcc dot gnu.org ---
(In reply to ktkachov from comment #11)
> It will need a target with LSE atomics. -march=armv8.1-a or equivalent. Or
> add +lse to an -march or -mcpu line.

Wait, no sorry, this shouldn't be related to LSE. Perhaps -mno-outline-atomics
?

[Bug target/93274] target_clones produces symbols with random digits with -fPIC

[amonakov at gcc dot gnu.org]

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||amonakov at gcc dot gnu.org

--- Comment #4 from Alexander Monakov  ---
IFUNCs don't have to be somehow "globally visible". The comment is there from
day 1, but it's not clear why - possibly a misunderstanding? GCC happily
accepts a static ifunc, and rest of toolchain should have no problem either:

__attribute__((used,ifunc("r_f")))
static void f();

static void *r_f()
{
 return 0;
}
.type   r_f, @function
r_f:
xorl%eax, %eax
ret
.size   r_f, .-r_f
.type   f, @gnu_indirect_function
.setf,r_f

[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE

[burnus at gcc dot gnu.org]

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

Tobias Burnus  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-15
 CC||burnus at gcc dot gnu.org,
   ||dominiq at gcc dot gnu.org
  Known to work||8.3.1
Summary|-fno-automatic and  |[9/10 Regression]
   |RECURSIVE   |-fno-automatic and
   ||RECURSIVE
 Ever confirmed|0   |1
  Known to fail||10.0, 9.2.1

--- Comment #3 from Tobias Burnus  ---
GCC 8 (8.3.1 20200110) shows "8" in the last line.
GCC 9 + 10/trunk show "9"
-> Hence, it is a regression.

My bet would be that it has been caused by the fix for PR 37835, r268098 – in
particular the following bit:

--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -16675,3 +16675,3 @@ resolve_types (gfc_namespace *ns)

-  if (ns->save_all)
+  if (ns->save_all || !flag_automatic)
 gfc_save_all (ns);

[Bug c++/93275] internal compiler error: unexpected expression 'N' of kind template_parm_index

[tahasuf at gmail dot com]

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

--- Comment #2 from ahmet özhan  ---
template  > array_depth_v),
std::nullptr_t> = nullptr>
constexpr array operator * (const Other& other) const {
array result {};
std::transform(
std::begin(*this),
std::end(*this),
std::begin(result),
[other](const T& t) { return t * other; });
return result;
}

but change this line and add -fconcepts
--
template  > array_depth_v),
std::nullptr_t> = nullptr>
-
template 
requires (array_depth_v > array_depth_v)

gcc 9.0 compile.

[Bug tree-optimization/88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[msebor at gcc dot gnu.org]

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

Bug 92623 Summary: FAIL: gcc.dg/Wstringop-overflow-17.c on ILP32: missing 
warning on line 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92623

   What|Removed |Added

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

[Bug testsuite/92623] FAIL: gcc.dg/Wstringop-overflow-17.c on ILP32: missing warning on line 8

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Sebor  ---
g:8817bd75802d3ae47c54ec4fe99103308353d4ed was committed to avoid the same
failures on x86_64 that had cropped up since this bug was had been raised and
it seems to take care of the -m32 problem as well.  In my local builds on
x86_64-linux the test passes both with and without -m32.

[Bug fortran/93263] [9/10 Regression] -fno-automatic and RECURSIVE

[markeggleston at gcc dot gnu.org]

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

markeggleston at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #4 from markeggleston at gcc dot gnu.org ---
diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c
index 6f2a4c4d65a..4c009a65287 100644
--- a/gcc/fortran/resolve.c
+++ b/gcc/fortran/resolve.c
@@ -17079,6 +17079,7 @@ resolve_types (gfc_namespace *ns)
   gfc_data *d;
   gfc_equiv *eq;
   gfc_namespace* old_ns = gfc_current_ns;
+  bool recursive = ns->proc_name && ns->proc_name->attr.recursive;

   if (ns->types_resolved)
 return;
@@ -17132,7 +17133,7 @@ resolve_types (gfc_namespace *ns)

   gfc_traverse_ns (ns, resolve_values);

-  if (ns->save_all || !flag_automatic)
+  if (!recursive && (ns->save_all || !flag_automatic))
 gfc_save_all (ns);

   iter_stack = NULL;

Does the trick. Now need to write the test cases and prepare a patch.

[Bug libstdc++/93267] std::ranges::begin|end do not work for iota_view when the element and bound type are the same

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:2a0f6c61b4db19535c632be68bddad74b6adb6cf

commit r10-5985-g2a0f6c61b4db19535c632be68bddad74b6adb6cf
Author: Jonathan Wakely 
Date:   Wed Jan 15 14:09:35 2020 +

libstdc++: Fix weakly_incrementable to allow __int128 (PR 93267)

The __iota_diff_t alias can be the type __int128, but that does not
satisfy the signed_integral and __is_signed_integer_like concepts when
__STRICT_ANSI__ is defined (which is true for -std=c++2a).

Because weakly_incrementable is defined in terms of signed_integral, it
is not satisfied by __int128, which means iota_view's iterator doesn't
always satisfy input_or_output_iterator and so iota_view is not always a
range.

The solution is to define __max_size_type and __max_diff_type using
__int128, so that __is_signed_integer_like allows __int128, and then
make weakly_incrementable use __is_signed_integer_like instead of
signed_integral.

PR libstdc++/93267
* include/bits/iterator_concepts.h (__max_diff_type, __max_size_type):
Move here from  and define using __int128 when
available.
(__is_integer_like, __is_signed_integer_like): Move here from
.
(weakly_incrementable): Use __is_signed_integer_like.
* include/bits/range_access.h (__max_diff_type, __max_size_type)
(__is_integer_like, __is_signed_integer_like): Move to
.
(__make_unsigned_like_t): Move here from .
* include/std/ranges (__make_unsigned_like_t): Move to
.
(iota_view): Replace using-directive with using-declarations.
* testsuite/std/ranges/iota/93267.cc: New test.
* testsuite/std/ranges/iota_view.cc: Move to new 'iota' sub-directory.

[Bug c/53769] [C11]: Macros __STDC_NO_THREADS__ / __STDC_NO_ATOMIC__ missing.

[christophe.monat at st dot com]

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

Christophe Monat  changed:

   What|Removed |Added

 CC||christophe.monat at st dot com

--- Comment #10 from Christophe Monat  ---
Now that C11 is complete, would it be acceptable to have GCC define
__STDC_NO_THREADS__ and __STDC_NO_ATOMIC__ when appropriate ?

Beyond the standard that stipulates this behavior, IAR compilers do provide
these definitions - at least according to their documentation (IAR C/C++
Development Guide Compiling and Linking - ARM version - 2019). I have not
checked other commercial compilers.

This would avoid this behavior of the ARM embedded toolchain:

$ cat samples-threads.c
#if !defined(__STDC_NO_THREADS__)
#include 
#endif

$ gcc-arm-none-eabi-8-2019-q3-update/bin/arm-none-eabi-gcc  samples-threads.c
In file included from samples-threads.c:2:
/sw/FROM_sw_st_gnu_compil_comp/comp/arm/linaro/gcc-arm-none-eabi-8-2019-q3-update/arm-none-eabi/include/threads.h:30:10:
fatal error: machine/_threads.h: No such file or directory
 #include 
  ^~~~

[Bug bootstrap/93277] New: powerpc64*-linux doesn't bootstrap after switch to git

[bergner at gcc dot gnu.org]

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

Bug ID: 93277
   Summary: powerpc64*-linux doesn't bootstrap after switch to git
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: bergner at gcc dot gnu.org
  Target Milestone: ---

Current bootstrap fails on powerpc64*linux due to the following error:

/usr/bin/ld:libstdc++-symbols.ver:774: syntax error in VERSION script
collect2: error: ld returned 1 exit status

I can confirm that the last svn revision builds fine, so the error occurred
after the switch to git.

Looking at the differences between libstdc++-symbols.ver between the svn build
and the git build, it looks like some of the symbols defs have been placed in
the wrong part of the file, leading to the syntax errors:

---
gcc-fsf-mainline-base-svn-test/powerpc64le-linux/libstdc++-v3/src/libstdc++-symbols.ver
2020-01-15 11:22:35.323772108 -0600
+++
gcc-fsf-mainline-base-test/powerpc64le-linux/libstdc++-v3/src/libstdc++-symbols.ver
2020-01-15 08:23:14.635215301 -0600
@@ -771,6 +771,46 @@
 _ZNSt6locale5_Impl19_M_replace_categoryEPKS0_PKPKNS_2idE;
 _ZNSt6locale5_Impl21_M_replace_categoriesEPKS0_i;
 _ZSt18uncaught_exceptionv;
+GLIBCXX_LDBL_3.4 {
+  _ZNSt14numeric_limitsIgE*;
+  _ZNSirsERg;
+  _ZNSolsEg;
+  _ZNSt13basic_istreamIwSt11char_traitsIwEErsERg;
+  _ZNSt13basic_ostreamIwSt11char_traitsIwEElsEg;
+  _ZSt14__convert_to_vIgEvPKcRT_RSt12_Ios_IostateRKP*;
+ 
_ZStlsIg[cw]St11char_traitsI[cw]EERSt13basic_ostreamIT0_T1_ES6_RKSt7complexIT_E;
+ 
_ZStrsIg[cw]St11char_traitsI[cw]EERSt13basic_istreamIT0_T1_ES6_RSt7complexIT_E;
+  *__gnu_cxx_ldbl128[1-6]*;
+  *St9has_facetINSt17__gnu_cxx_ldbl1287*;
+  *St9use_facetINSt17__gnu_cxx_ldbl1287*;
+ 
*__gnu_cxx_ldbl1287num_getI[cw]St19istreambuf_iteratorI[cw]St11char_traitsI[cw]EEE[CD][0-2]E?;
+ 
*__gnu_cxx_ldbl1287num_getI[cw]St19istreambuf_iteratorI[cw]St11char_traitsI[cw]EEE2idE;
+ 
*__gnu_cxx_ldbl1287num_getI[cw]St19istreambuf_iteratorI[cw]St11char_traitsI[cw];
+  *__gnu_cxx_ldbl1287num_getI[cw]*getE*;
+  *__gnu_cxx_ldbl1287num_getI[cw]*14_M_extract_intI*;
+  *__gnu_cxx_ldbl1287num_getI[cw]*16_M_extract_floatE*;
+  *__gnu_cxx_ldbl1287num_putI[cw]*;
+  *__gnu_cxx_ldbl128[8-9]*;
+};
+GLIBCXX_LDBL_3.4.7 {
+  _ZNSi10_M_extractIgEERSiRT_;
+  _ZNSt13basic_istreamIwSt11char_traitsIwEE10_M_extractIgEERS2_RT_;
+  _ZNSo9_M_insertIgEERSoT_;
+  _ZNSt13basic_ostreamIwSt11char_traitsIwEE9_M_insertIgEERS2_T_;
+} GLIBCXX_LDBL_3.4;
+GLIBCXX_LDBL_3.4.10 {
+  _ZNKSt3tr14hashIgEclEg;
+  _ZNKSt4hashIgEclEg;
+} GLIBCXX_LDBL_3.4.7;
+GLIBCXX_LDBL_3.4.21 {
+  __gnu_cxx_ldbl1287num_getI[cw]*14_M_extract_intB5cxx11*;
+  __gnu_cxx_ldbl1287num_getI[cw]*16_M_extract_floatB5cxx11*;
+} GLIBCXX_LDBL_3.4.10;
+CXXABI_LDBL_1.3 {
+  _ZT[IS]g;
+  _ZT[IS]Pg;
+  _ZT[IS]PKg;
+};
   local:
 *;
 };
@@ -1850,43 +1890,3 @@
   global:
 __cxa_tm_cleanup;
 };
-GLIBCXX_LDBL_3.4 {
-  _ZNSt14numeric_limitsIgE*;
-  _ZNSirsERg;
-  _ZNSolsEg;
-  _ZNSt13basic_istreamIwSt11char_traitsIwEErsERg;
-  _ZNSt13basic_ostreamIwSt11char_traitsIwEElsEg;
-  _ZSt14__convert_to_vIgEvPKcRT_RSt12_Ios_IostateRKP*;
- 
_ZStlsIg[cw]St11char_traitsI[cw]EERSt13basic_ostreamIT0_T1_ES6_RKSt7complexIT_E;
- 
_ZStrsIg[cw]St11char_traitsI[cw]EERSt13basic_istreamIT0_T1_ES6_RSt7complexIT_E;
-  *__gnu_cxx_ldbl128[1-6]*;
-  *St9has_facetINSt17__gnu_cxx_ldbl1287*;
-  *St9use_facetINSt17__gnu_cxx_ldbl1287*;
- 
*__gnu_cxx_ldbl1287num_getI[cw]St19istreambuf_iteratorI[cw]St11char_traitsI[cw]EEE[CD][0-2]E?;
- 
*__gnu_cxx_ldbl1287num_getI[cw]St19istreambuf_iteratorI[cw]St11char_traitsI[cw]EEE2idE;
- 
*__gnu_cxx_ldbl1287num_getI[cw]St19istreambuf_iteratorI[cw]St11char_traitsI[cw];
-  *__gnu_cxx_ldbl1287num_getI[cw]*getE*;
-  *__gnu_cxx_ldbl1287num_getI[cw]*14_M_extract_intI*;
-  *__gnu_cxx_ldbl1287num_getI[cw]*16_M_extract_floatE*;
-  *__gnu_cxx_ldbl1287num_putI[cw]*;
-  *__gnu_cxx_ldbl128[8-9]*;
-};
-GLIBCXX_LDBL_3.4.7 {
-  _ZNSi10_M_extractIgEERSiRT_;
-  _ZNSt13basic_istreamIwSt11char_traitsIwEE10_M_extractIgEERS2_RT_;
-  _ZNSo9_M_insertIgEERSoT_;
-  _ZNSt13basic_ostreamIwSt11char_traitsIwEE9_M_insertIgEERS2_T_;
-} GLIBCXX_LDBL_3.4;
-GLIBCXX_LDBL_3.4.10 {
-  _ZNKSt3tr14hashIgEclEg;
-  _ZNKSt4hashIgEclEg;
-} GLIBCXX_LDBL_3.4.7;
-GLIBCXX_LDBL_3.4.21 {
-  __gnu_cxx_ldbl1287num_getI[cw]*14_M_extract_intB5cxx11*;
-  __gnu_cxx_ldbl1287num_getI[cw]*16_M_extract_floatB5cxx11*;
-} GLIBCXX_LDBL_3.4.10;
-CXXABI_LDBL_1.3 {
-  _ZT[IS]g;
-  _ZT[IS]Pg;
-  _ZT[IS]PKg;
-};

[Bug libstdc++/93267] std::ranges::begin|end do not work for iota_view when the element and bound type are the same

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #10 from Jonathan Wakely  ---
Fixed, thanks for the report.

[Bug c++/85515] Bogus suggestions from "GCC's leaky abstractions"

[nathan at gcc dot gnu.org]

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

Nathan Sidwell  changed:

   What|Removed |Added

 CC||nathan at gcc dot gnu.org

--- Comment #8 from Nathan Sidwell  ---
re __val and __forbegin & comment 3 -- that's why I added a space to __ct et
al, so the user couldn't use them.

[Bug bootstrap/93277] powerpc64*-linux doesn't bootstrap after switch to git

[redi at gcc dot gnu.org]

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

--- Comment #1 from Jonathan Wakely  ---
I don't see this, could one of your trees be corrupted somehow?

[Bug bootstrap/93277] powerpc64*-linux doesn't bootstrap after switch to git

[bergner at gcc dot gnu.org]

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

--- Comment #2 from Peter Bergner  ---
(In reply to Jonathan Wakely from comment #1)
> I don't see this, could one of your trees be corrupted somehow?

I see this on two different systems using src trees from two separate git
clones (ie, I didn't rsync one tree over to the other system).

[Bug tree-optimization/93231] [10 Regression] ICEs since r280132

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-5986-gbc071d3a951a98284a3f46043afd44c03c123376
Author: Wilco Dijkstra 
Date:   Wed Jan 15 15:23:54 2020 +

Fix ctz issues (PR93231)

Further improve the ctz recognition: Avoid ICEing on negative shift
counts or multiply constants.  Check the type is a char type for the
string constant case to avoid accidentally matching a wide STRING_CST.
Add a tree_expr_nonzero_p check to allow the optimization even if
CTZ_DEFINED_VALUE_AT_ZERO returns 0 or 1.  Add extra test cases.

Bootstrap OK on AArch64 and x64.

gcc/
PR tree-optimization/93231
* tree-ssa-forwprop.c (optimize_count_trailing_zeroes): Check
input_type is unsigned.  Use tree_to_shwi for shift constant.
Check CST_STRING element size is CHAR_TYPE_SIZE bits.
(simplify_count_trailing_zeroes): Add test to handle known non-zero
inputs more efficiently.

testsuite/
PR tree-optimization/93231
* gcc.dg/pr90838.c: New test.
* gcc.dg/pr93231.c: New test.
* gcc.target/aarch64/pr90838.c: Use #define u 0.

[Bug c/93278] New: huge almost empty array takes huge time to compile and produces huge object file

[doug at cs dot dartmouth.edu]

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

Bug ID: 93278
   Summary: huge almost empty array takes huge time to compile and
produces huge object file
   Product: gcc
   Version: 7.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doug at cs dot dartmouth.edu
  Target Milestone: ---

Example, with HUGE varying from a million to a billion. 
  char a[HUGE] = "x"; 
Object file size varies accordingly. Compile time varies by a factor of a
hundred on my 4GB desktop.

ELF allows sections to be incompletely initialized. Can't gcc exploit that?

I suspect this is not a new complaint, but the search terms I tried didn't find
it.

And I was amused to find that replacing "x"  with "\0" causes the inefficiency
to be optimized away.

[Bug c++/93279] New: [9 Regression] Template substitution ICE

[dje at gcc dot gnu.org]

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

Bug ID: 93279
   Summary: [9 Regression] Template substitution ICE
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dje at gcc dot gnu.org
  Target Milestone: ---

Created attachment 47659
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47659&action=edit
C++ source code example that produces error

From Twitter (https://twitter.com/aozhanmuh/status/1217249292395720705)
and Compiler Explorer (https://godbolt.org/z/5HjwcN)

: In substitution of 'template
template
> > array_depth_v), std::nullptr_t>::type  > constexpr
math::array math::array::operator*(const Other&) const [with Other
= ; typename std::enable_if<(array_depth_v > >
array_depth_v), std::nullptr_t>::type  = ; T =
float; long unsigned int N = ]':

:56:36:   required from 'constexpr math::array math::array::operator*(const Other&) const [with Other = float; typename
std::enable_if<(array_depth_v > > array_depth_v),
std::nullptr_t>::type  = nullptr; T = math::array; long
unsigned int N = 1]'

:79:20:   required from here

:48:5: internal compiler error: unexpected expression 'N' of kind
template_parm_index

   48 |(array_depth_v > array_depth_v),

  | ^~~~

Please submit a full bug report,

with preprocessed source if appropriate.

See  for instructions.

Compiler returned: 1

[Bug c++/93279] [9 Regression] C++ Template substitution ICE

[dje at gcc dot gnu.org]

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

David Edelsohn  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-01-15
 CC||jason at gcc dot gnu.org
Summary|[9 Regression] Template |[9 Regression] C++ Template
   |substitution ICE|substitution ICE
 Ever confirmed|0   |1

--- Comment #1 from David Edelsohn  ---
New

[Bug c++/92590] [10 Regression] Cannot expose protected default constructor with "using" keyword in gcc 10

[proski at gnu dot org]

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

--- Comment #5 from Pavel Roskin  ---
Confirming fix on the original code. Thank you!

[Bug target/93254] g++ -m32 -mfpmath=sse -msse generates sse2 instructions

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:49e76760a298b735a07e4165d9b8c73946e32287

commit r9-8135-g49e76760a298b735a07e4165d9b8c73946e32287
Author: Uros Bizjak 
Date:   Wed Jan 15 20:22:39 2020 +0100

PR target/93254 - -msse generates sse2 instructions

PR target/93254
* config/i386/i386.md (*movsf_internal): Require SSE2 ISA for
alternatives 9 and 10.  Do not require SSE2 ISA for alternatives
14 and 15.

[Bug target/93254] g++ -m32 -mfpmath=sse -msse generates sse2 instructions

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #5 from Uroš Bizjak  ---
Fixed for gcc-9.3+.

[Bug bootstrap/93277] powerpc64*-linux doesn't bootstrap after switch to git

[bergner at gcc dot gnu.org]

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

--- Comment #3 from Peter Bergner  ---
So this ends up not being a git conversion issue.  I can also get this to fail
using my svn tree as well now.  The problem seems to be the choice in gcc
source tree directory name.  I had chosen "gcc.git" to make it easy to identify
from the svn trees I still have a round.  If I rename that to "gcc-git", then
my build completes fine with no problem.  If I rename my gcc svn tree to
"gcc.svn", then it too fails.

Strangely, using "gcc.foo" seems to be ok.  Is there something special about
source directory names "gcc.svn" and "gcc.git"?

[Bug c++/92871] [10 Regression] new test case g++.dg/ext/temp-extend1.C fails starting with its introduction in r279069

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:7192b1ec12484f5ca8b20930d8dc4d28ab4a533a

commit r10-5987-g7192b1ec12484f5ca8b20930d8dc4d28ab4a533a
Author: Jason Merrill 
Date:   Wed Jan 15 09:31:11 2020 -0500

PR c++/92871 - bad code with xvalue and GNU ?: extension.

I steered Jakub wrong on the desired behavior for temp-extend1.C in the
context of bug 92831; it doesn't make sense to try to extend the lifetime
of
a temporary that we've already materialized to evaluate the test.  So this
patch munges the stabilized expression so that it won't be subject to
lifetime extension.

* call.c (prevent_lifetime_extension): New.
(build_conditional_expr_1): Use it.

[Bug c++/92831] CWG1299 extend_ref_init_temps_1 punts on COND_EXPRs

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:7192b1ec12484f5ca8b20930d8dc4d28ab4a533a

commit r10-5987-g7192b1ec12484f5ca8b20930d8dc4d28ab4a533a
Author: Jason Merrill 
Date:   Wed Jan 15 09:31:11 2020 -0500

PR c++/92871 - bad code with xvalue and GNU ?: extension.

I steered Jakub wrong on the desired behavior for temp-extend1.C in the
context of bug 92831; it doesn't make sense to try to extend the lifetime
of
a temporary that we've already materialized to evaluate the test.  So this
patch munges the stabilized expression so that it won't be subject to
lifetime extension.

* call.c (prevent_lifetime_extension): New.
(build_conditional_expr_1): Use it.

[Bug bootstrap/93277] powerpc64*-linux doesn't bootstrap after switch to git

[bergner at gcc dot gnu.org]

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

--- Comment #4 from Peter Bergner  ---
(In reply to Peter Bergner from comment #3)
> Strangely, using "gcc.foo" seems to be ok.  Is there something special about
> source directory names "gcc.svn" and "gcc.git"?

So even "gcc-foo.git" causes a problem, so I guess ".git" cannot show up
anywhere in the gcc source directory name.

[Bug c++/93257] consteval functions returning 'void' are rejected when called

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug c++/92871] [10 Regression] new test case g++.dg/ext/temp-extend1.C fails starting with its introduction in r279069

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

[Bug c++/93257] consteval functions returning 'void' are rejected when called

[jason at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

https://gcc.gnu.org/g:596334fa040094c772965ff1998d171fe3e00348

commit r10-5988-g596334fa040094c772965ff1998d171fe3e00348
Author: Jason Merrill 
Date:   Wed Jan 15 14:45:24 2020 -0500

PR c++/93257 - consteval void function.

A prvalue can have void type, and if it doesn't do anything prohibited in a
constant expression, it's vacuously constant.

* constexpr.c (verify_constant): Allow void_node.

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

[Bug c++/33799] Return value's destructor not executed when a local variable's destructor throws

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:299ddc612136421f1d9865ea4f2f84f7e3791824

commit r10-5989-g299ddc612136421f1d9865ea4f2f84f7e3791824
Author: Jason Merrill 
Date:   Wed Jan 15 14:13:13 2020 -0500

Revert "PR c++/33799 - destroy return value if local cleanup throws."

This change was blocking the coroutines merge, so I'm backing it out for
now
to adjust my approach.

This reverts commit 7c82dd6c02d44d9d2cd84dda137c00b1a3cd6c90.

[Bug c++/93257] consteval functions returning 'void' are rejected when called

[cvs-commit at gcc dot gnu.org]

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

Jason Merrill  changed:

   What|Removed |Added

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

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

https://gcc.gnu.org/g:596334fa040094c772965ff1998d171fe3e00348

commit r10-5988-g596334fa040094c772965ff1998d171fe3e00348
Author: Jason Merrill 
Date:   Wed Jan 15 14:45:24 2020 -0500

PR c++/93257 - consteval void function.

A prvalue can have void type, and if it doesn't do anything prohibited in a
constant expression, it's vacuously constant.

* constexpr.c (verify_constant): Allow void_node.

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

[Bug c++/93280] New: ice: in cp_gimplify_expr, at cp /cp-gimplify.c:933

[dcb314 at hotmail dot com]

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

Bug ID: 93280
   Summary: ice: in cp_gimplify_expr, at cp /cp-gimplify.c:933
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

Created attachment 47660
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47660&action=edit
gzipped C++ source code

For the attached C++ code, compiled by recent gcc trunk and
compiler flag -std=c++17, does this:

../src/oomd/Oomd.cpp:213:15: internal compiler error: in cp_gimplify_expr, at
cp
/cp-gimplify.c:933
0x60a396 cp_gimplify_expr(tree_node**, gimple**, gimple**)
../../trunk.git/gcc/cp/cp-gimplify.c:933
0xe20a97 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
in
t)
../../trunk.git/gcc/gimplify.c:13490
0xe2acb2 gimplify_init_ctor_preeval
../../trunk.git/gcc/gimplify.c:4510
0xe2ad88 gimplify_init_ctor_preeval
../../trunk.git/gcc/gimplify.c:4496

The bug first seems to appear sometime between revision
28 and 280050.

I'll have my usual go at reducing the code.

[Bug analyzer/93281] New: Various analyzer testsuite failures for 32-bit targets

[dmalcolm at gcc dot gnu.org]

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

Bug ID: 93281
   Summary: Various analyzer testsuite failures for 32-bit targets
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: dmalcolm at gcc dot gnu.org
  Target Milestone: ---

As reported here:
  https://gcc.gnu.org/ml/gcc-patches/2020-01/msg00875.html

 Running target unix/-m32
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 610)
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 611)
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 615)
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 616)
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 657)
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 658)
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 662)
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 663)
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 705)
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 706)
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 710)
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 711)
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 753)
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 754)
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 758)
+FAIL: gcc.dg/analyzer/data-model-1.c  (test for warnings, line 759)
+FAIL: gcc.dg/analyzer/data-model-1.c (test for excess errors)

Am able to reproduce; am investigating.

[Bug analyzer/93281] Various analyzer testsuite failures for 32-bit targets

[dmalcolm at gcc dot gnu.org]

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

David Malcolm  changed:

   What|Removed |Added

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

[Bug analyzer/93281] Various analyzer testsuite failures for 32-bit targets

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
These are all of the various:
  __analyzer_eval (q[-2].x == 107024); /* { dg-warning "TRUE" } */
  __analyzer_eval (q[-2].y == 107025); /* { dg-warning "TRUE" } */
emitting UNKNOWN instead.


The -m32 gimple has:

  _55 = q_92 + 4294967280;
  _56 = _55->x;
  _57 = _56 == 107024;
  _58 = (int) _57;
  __analyzer_eval (_58);

whereas the -m64 gimple has:

  _55 = q_92 + 18446744073709551600;
  _56 = _55->x;
  _57 = _56 == 107024;
  _58 = (int) _57;
  __analyzer_eval (_58);

Looks like somewhere below region_model::convert_byte_offset_to_array_index the
64-bit case reconstructs -2, whereas the 32-bit case doesn't.

[Bug c/93072] [8/9/10 Regression] ICE: gimplifier segfault with undefined nested function

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:7cc6b679a0d0e50c0e1671fefa815dc753554184

commit r9-8136-g7cc6b679a0d0e50c0e1671fefa815dc753554184
Author: Joseph Myers 
Date:   Wed Jan 15 20:52:45 2020 +

Fix setting of DECL_CONTEXT in pushdecl (PR c/93072).

Bug 93072 is a case where the C front end (a) wrongly interprets an
inline declaration at block scope as indicating that DECL_CONTEXT
should be set for an inline function and (b) this results in an ICE.
This is a regression resulting from a previous fix of mine for other
bugs involving such declarations being wrongly interpreted elsewhere
as nested function declarations.  The fix is similar to the previous
fix: use TREE_PUBLIC instead of DECL_EXTERNAL in another place as the
relevant test to determine whether to set DECL_CONTEXT.  (When a
variable reaches the code in question in pushdecl, the two are
equivalent.)

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

PR c/93072
gcc/c:
* c-decl.c (pushdecl): Use TREE_PUBLIC, not DECL_EXTERNAL, to
determine whether to set DECL_CONTEXT.

gcc/testsuite:
* gcc.dg/inline-42.c, gcc.dg/inline-43.c: New tests.

(cherry picked from commit e2346a33b05871fc065815d4cfd531dfa0195507)

[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)

[wilco at gcc dot gnu.org]

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

Wilco  changed:

   What|Removed |Added

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

--- Comment #13 from Wilco  ---
(In reply to Wilco from comment #10)

> The easiest option is to see whether replacing "reload_completed" with
> "epilogue_completed" in aarch64/atomics.md works fine.

That works indeed, I'll post a patch.

[Bug bootstrap/93282] New: [10 Regression] build failure introduced with the git conversion

[doko at debian dot org]

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

Bug ID: 93282
   Summary: [10 Regression] build failure introduced with the git
conversion
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: doko at debian dot org
  Target Milestone: ---

seen with trunk 20200115:

x86_64-linux-gnu-g++-9 -std=gnu++98 -c   -g -DIN_GCC -fno-exceptions
-fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strin
gs -Wcast-qual -Wno-format -Wmissing-format-attribute -Woverloaded-virtual
-pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings   -D
HAVE_CONFIG_H  -DGENERATOR_FILE -fno-PIE -I. -Ibuild -I../../src/gcc
-I../../src/gcc/build -I../../src/gcc/../include 
-I../../src/gcc/../libcpp/incl
ude  \
-DBASEVER="\"10.0.1\"" -DDATESTAMP="\" 20200115\"" \
-DREVISION="\"\"" \
-DDEVPHASE="\" (experimental)\"" -DPKGVERSION="\"(Debian 10-20200115-1) \"" \
-DBUGURL="\"\"" -o build/version.o
../../src/gcc/version.c
make[5]: *** No rule to make target ')', needed by 's-options'.  Stop.
make[5]: *** Waiting for unfinished jobs
4470 translated messages, 1667 fuzzy translations, 7127 un

gcc configured with

Configured with: -v
 --with-pkgversion='Debian 10-20200115-1'
 --with-bugurl='file:///usr/share/doc/gcc-10/README.Bugs'
 --enable-languages=c,c++,go,brig,d,fortran,objc,obj-c++
 --prefix=/usr
 --with-gcc-major-version-only
 --program-suffix=-10
 --program-prefix=x86_64-linux-gnu-
 --enable-shared
 --enable-linker-build-id
 --libexecdir=/usr/lib
 --without-included-gettext
 --enable-threads=posix
 --libdir=/usr/lib
 --enable-nls
 --enable-clocale=gnu
 --enable-libstdcxx-debug
 --enable-libstdcxx-time=yes
 --with-default-libstdcxx-abi=new
 --enable-gnu-unique-object
 --disable-vtable-verify
 --enable-plugin
 --enable-default-pie
 --with-system-zlib
 --with-target-system-zlib=auto
 --enable-objc-gc=auto
 --enable-multiarch
 --disable-werror
 --with-arch-32=i686
 --with-abi=m64
 --with-multilib-list=m32,m64,mx32
 --enable-multilib
 --with-tune=generic
 --enable-offload-targets=nvptx-none,amdgcn-amdhsa,hsa
 --without-cuda-driver
 --enable-checking=release
 --build=x86_64-linux-gnu
 --host=x86_64-linux-gnu
 --target=x86_64-linux-gnu

[Bug c++/93280] ice: in cp_gimplify_expr, at cp /cp-gimplify.c:933

[dcb314 at hotmail dot com]

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

--- Comment #1 from David Binderman  ---
Reduced C++ code is:

struct a {
  template  a(b);
  int c;
};
struct d {
  a e{0};
};
void f() {
  d g;
  g = {};
}

$ /home/dcb/gcc/results/bin/gcc -c bug583.cc
bug583.cc: In function ‘void f()’:
bug583.cc:10:5: internal compiler error: in cp_gimplify_expr, at
cp/cp-gimplify.c:933
   10 |   g = {};
  |   ~~^~~~
0x60a396 cp_gimplify_expr(tree_node**, gimple**, gimple**)
../../trunk.git/gcc/cp/cp-gimplify.c:933

It seems that the -std=c++17 is not required.

[Bug c++/91073] [9/10 Regression] if constexpr no longer works directly with Concepts

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Paolo Carlini :

https://gcc.gnu.org/g:83fe2b921830c177e3dee514aa07cbc7c8ceef1c

commit r10-5990-g83fe2b921830c177e3dee514aa07cbc7c8ceef1c
Author: Paolo Carlini 
Date:   Wed Jan 15 22:28:46 2020 +0100

Fix "PR c++/91073 if constexpr no longer works directly with Concepts."

This is a rather serious regression, filed in July 2019. Luckily the
fix is simple: is localized to parser.c and cp-tree.h in cp and boils
down to only a few lines.

Testing OK on x86_64-linux. Approved off-line by Jason Merrill.

/cp
PR c++/91073
* cp-tree.h (is_constrained_auto): New.
* parser.c (cp_parser_maybe_commit_to_declaration): Correctly
handle concept-check expressions; take a cp_decl_specifier_seq*
instead of a bool.
(cp_parser_condition): Update call.
(cp_parser_simple_declaration): Likewise.
(cp_parser_placeholder_type_specifier): Correctly handle
concept-check expressions.

/testsuite
PR c++/91073
* g++.dg/concepts/pr91073-1.C: New.
* g++.dg/concepts/pr91073-2.C: Likewise.

[Bug target/92692] [9/10 Regression] Saving off the callee saved register between ldxr/stxr (caused by shrink wrapping improvements)

[jakub at gcc dot gnu.org]

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

--- Comment #14 from Jakub Jelinek  ---
(In reply to Wilco from comment #10)
> (In reply to Jakub Jelinek from comment #9)
> > Any -march= or similar?  Can't reproduce with current trunk, nor
> > with even Oct 10 GCC snapshot (crosses in both cases).
> > grep -B1 stxr pr92692.s
> > doesn't show any stores before stxr.
> 
> It's going to be extremely sensitive to register allocation, so it's not
> clear it's worth trying to reproduce.
> 
> The easiest option is to see whether replacing "reload_completed" with
> "epilogue_completed" in aarch64/atomics.md works fine.

For the shrink wrapping issue that is really needed on splitters that split
into multiple basic blocks, atomic splitters that don't create any branches nor
labels should be fine with reload_completed.

[Bug c++/93280] ice: in cp_gimplify_expr, at cp /cp-gimplify.c:933

[dcb314 at hotmail dot com]

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

David Binderman  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org

--- Comment #2 from David Binderman  ---
git blame suggests a recent change by Jason Merrill:

08f594eb399d gcc/cp/cp-gimplify.c (Jason Merrill  2020-01-08 15:31:25
-0500  933)   gcc_checking_assert (!TARGET_EXPR_DIRECT_INIT_P (*expr_p));

Adding Jason to the CC list.

[Bug c++/91073] [9 Regression] if constexpr no longer works directly with Concepts

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
 CC|paolo at gcc dot gnu.org   |
   Assignee|unassigned at gcc dot gnu.org  |paolo.carlini at oracle 
dot com
Summary|[9/10 Regression] if|[9 Regression] if constexpr
   |constexpr no longer works   |no longer works directly
   |directly with Concepts  |with Concepts

--- Comment #12 from Paolo Carlini  ---
Fixed in trunk for now.

[Bug c/53769] [C11]: Macros __STDC_NO_THREADS__ / __STDC_NO_ATOMIC__ missing.

[joseph at codesourcery dot com]

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

--- Comment #11 from joseph at codesourcery dot com  ---
On Wed, 15 Jan 2020, christophe.monat at st dot com wrote:

> Now that C11 is complete, would it be acceptable to have GCC define
> __STDC_NO_THREADS__ and __STDC_NO_ATOMIC__ when appropriate ?

That should be done via the implicit preinclude mechanism, with libc 
providing a header and GCC knowing what libc calls that header.

[Bug c/93072] [8/9/10 Regression] ICE: gimplifier segfault with undefined nested function

[cvs-commit at gcc dot gnu.org]

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-8 branch has been updated by Joseph Myers :

https://gcc.gnu.org/g:67cceb6c538b7a10cd5cf5693bce7fc7a646581d

commit r8-9938-g67cceb6c538b7a10cd5cf5693bce7fc7a646581d
Author: Joseph Myers 
Date:   Wed Jan 15 22:33:04 2020 +

Fix setting of DECL_CONTEXT in pushdecl (PR c/93072).

Bug 93072 is a case where the C front end (a) wrongly interprets an
inline declaration at block scope as indicating that DECL_CONTEXT
should be set for an inline function and (b) this results in an ICE.
This is a regression resulting from a previous fix of mine for other
bugs involving such declarations being wrongly interpreted elsewhere
as nested function declarations.  The fix is similar to the previous
fix: use TREE_PUBLIC instead of DECL_EXTERNAL in another place as the
relevant test to determine whether to set DECL_CONTEXT.  (When a
variable reaches the code in question in pushdecl, the two are
equivalent.)

Bootstrapped with no regressions for x86_64-pc-linux-gnu.

PR c/93072
gcc/c:
* c-decl.c (pushdecl): Use TREE_PUBLIC, not DECL_EXTERNAL, to
determine whether to set DECL_CONTEXT.

gcc/testsuite:
* gcc.dg/inline-42.c, gcc.dg/inline-43.c: New tests.

(cherry picked from commit e2346a33b05871fc065815d4cfd531dfa0195507)

[Bug c/93072] [8/9/10 Regression] ICE: gimplifier segfault with undefined nested function

[jsm28 at gcc dot gnu.org]

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

Joseph S. Myers  changed:

   What|Removed |Added

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

--- Comment #7 from Joseph S. Myers  ---
Fixed for GCC 8.4, GCC 9.3, GCC 10.

[Bug c++/93283] New: Partial specialization not specializing any parameters is allowed with alias templates

[omerfaruko at gmail dot com]

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

Bug ID: 93283
   Summary: Partial specialization not specializing any parameters
is allowed with alias templates
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: omerfaruko at gmail dot com
  Target Milestone: ---

Partial specializations with template aliases are allowed even if they don't
specialize any template arguments.

Taken from https://stackoverflow.com/q/59756201/7771076.

https://godbolt.org/z/Ne9Tav



// okay
#include 

template
using sfinae_t = T;

template 
struct Test;

template 
struct Test> {};

Test t;



// fail
#include 

template
using sfinae_t = T;

template 
struct Test;

template 
struct Test> {};

Test t;



Error message for the latter:

:10:8: error: partial specialization 'struct Test' does not
specialize any template arguments; to define the primary template, remove the
template argument list
   10 | struct Test> {};
  |^
:7:8: note: primary template here
7 | struct Test;
  |



There is a separate discussion on whether this is valid:

https://godbolt.org/z/ztuRSq



#include 

template
using sfinae_t = T;

template
using sfinae_v_t = sfinae_t::type...>;

template 
struct Test;

template 
struct Test>> {};

void f() {
Test t;
}



This compiles fine with gcc (possibly due to above bug), but not with
clang/icc/MSVC.

The last one is actually useful for specializing std::hash, std::tuple_size,
std::tuple_element etc. based on user's template types.

Thanks.

[Bug analyzer/93281] Various analyzer testsuite failures for 32-bit targets

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
  tree index
= fold_build2 (TRUNC_DIV_EXPR, integer_type_node,
   offset_cst, byte_size);
looks wrong.
offset_cst probably doesn't have integer_type_node type, byte_size almost
surely.
If you want to perform a signed division, you should use ssizetype and
fold_convert the arguments to ssizetype.

[Bug bootstrap/93277] powerpc64*-linux doesn't bootstrap after switch to git

[bergner at gcc dot gnu.org]

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

Peter Bergner  changed:

   What|Removed |Added

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

--- Comment #5 from Peter Bergner  ---
So with some help from Joseph, this ended up being luser error on my part!

The problem was libtool uses grep to extract some version strings from some
files in the gcc source tree.  That's all fine and dandy, but I had grep setup
to use --exclude=*.svn* --exclude=*.git*, so any path with either .svn or .git
anywhere in the path name would cause grep to not find the version string. 
Clearly, that regex expression is way too greedy!