[Bug c/88430] -Wmissing-attributes warnings when including libquadmath headers

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
Author: jakub
Date: Tue Dec 11 07:45:47 2018
New Revision: 266972

URL: https://gcc.gnu.org/viewcvs?rev=266972&root=gcc&view=rev
Log:
PR c/88430
* quadmath_weak.h (__qmath2): Add __quadmath_throw.

Modified:
trunk/libquadmath/ChangeLog
trunk/libquadmath/quadmath_weak.h

[Bug tree-optimization/88444] [9 Regression] ICE: tree check: expected ssa_name, have integer_cst in live_on_edge, at tree-vrp.c:468; or ICE: tree check: expected ssa_name, have integer_cst in get_val

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-11
 CC||jakub at gcc dot gnu.org
   Target Milestone|--- |9.0
 Ever confirmed|0   |1

--- Comment #1 from Jakub Jelinek  ---
Started with r266739.

[Bug target/88437] Excessive struct alignment on x86_64

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #2 from Uroš Bizjak  ---
This is due to:

'-malign-data=TYPE'
 Control how GCC aligns variables.  Supported values for TYPE are
 'compat' uses increased alignment value compatible uses GCC 4.8 and
 earlier, 'abi' uses alignment value as specified by the psABI, and
 'cacheline' uses increased alignment value to match the cache line
 size.  'compat' is the default.

You can use -malign-data=abi to get 8 byte alignment for your case.

Not a bug.

[Bug target/88437] Excessive struct alignment on x86_64

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
For arrays, this is required by x86-64 psABI, which says that arrays 16 bytes
or larger must be 16 bytes aligned.
For other aggregates, this is an optimization, so that one can use vector
loads/stores to copy the object etc.
If you want to use section attribute and place the structures as an array, you
need to use aligned attribute and specify the exact alignment you want, then it
will be honored and no gaps will be inserted.

[Bug c++/88261] [9 Regression] ICE: verify_gimple failed (error: non-trivial conversion at assignment)

[edlinger at gcc dot gnu.org]

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

--- Comment #4 from Bernd Edlinger  ---
For G++ versions, where this was accepted with -fpermissive, the code was
wrong:

struct str { int len; char s[]; };

int  foo()
{
  struct str b = { 2, "b" };
  return sizeof(b);
}


=>

movl$4, %eax
ret

[Bug tree-optimization/33315] stores not commoned by sinking

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at redhat dot com

--- Comment #11 from Jeffrey A. Law  ---
We're closer now than before:

test ()
{
  int i;

   [local count: 1073741824]:
  i_8 = num;
  if (i_8 == 1)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 365072220]:
  MEM[(int *)&a] = 0;
  MEM[(int *)&a + 4B] = 0;

   [local count: 1073741824]:
  MEM[(int *)&a + 8B] = 0;
  return;

   [local count: 73016]:
  MEM[(int *)&a] = 0;
  MEM[(int *)&a + 4B] = 0;
  goto ; [100.00%]

}


I wonder if the block hashing stuff from ICF would allow us to determine that
bb3 and bb5 are equivalent.  That in turn would allow us to recognize the test
in bb2 isn't actually needed.

It was always my hope that the ICF infrastructure could be used in this way.

[Bug tree-optimization/80520] [7/8/9 Regression] Performance regression from missing if-conversion

[law at gcc dot gnu.org]

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

--- Comment #12 from Jeffrey A. Law  ---
Author: law
Date: Tue Dec 11 04:56:54 2018
New Revision: 266971

URL: https://gcc.gnu.org/viewcvs?rev=266971&root=gcc&view=rev
Log:
PR tree-optimization/80520
* gimple-ssa-split-paths.c (is_feasible_trace): Recognize half
diamonds that are likely if convertable.

* gcc.dg/tree-ssa/split-path-5.c: Update expected output.
* gcc.dg/tree-ssa/split-path-11.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/tree-ssa/split-path-11.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-split-paths.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/tree-ssa/split-path-5.c

[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

 CC||egallager at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=61864

--- Comment #15 from Eric Gallager  ---
(In reply to Askar Safin from comment #11)
> (In reply to Jonathan Wakely from comment #10)
> > I wish people would just learn how enums work, it's not that complicated.
> 
> Okey, now I understand everything. Now I see that, well, -fstrict-enums
> silences warning for code from comment #1 only because number of enum
> alternatives happen to be power of 2. If it would be, say, 3, then code from
> comment #1 will always produce a warning even with -fstrict-enums. And also
> I understand that code with "enum class" will always produce a warning.
> 
> So, gcc doesn't have way to enable clang-style warning behavior for enums.
> And gcc doesn't have such way for "enum class", too. And -fstrict-enums
> enables clang-style warning behavior for code from comment #1 only because
> this code has power of 2 number of alternatives.
> 
> And also I understand that current gcc behavior is not bug and is absolutely
> standard-compliant.
> 
> But, well, I still don't like current g++ behavior. I want g++ to not report
> "reaching end of non-void..." if all switch alternatives are handled, at
> least if some optional option is passed to gcc. I want clang behavior. Okey,
> you may mark this bug as "wishlist", but I still think that clang-style
> behavior here is very useful feature.
> 
> Look here, LLVM project was forced to introduce special kludge to make sure
> g++ will not give useless warnings:
> http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-
> covered-switches-over-enumerations

For the warning clang uses mentioned in the link (-Wcovered-switch-default) see
bug 61864. (It looks like the behavior to respect unreachables has been updated
since the last time I checked it)

[Bug tree-optimization/88444] New: [9 Regression] ICE: tree check: expected ssa_name, have integer_cst in live_on_edge, at tree-vrp.c:468; or ICE: tree check: expected ssa_name, have integer_cst in ge

[asolokha at gmx dot com]

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

Bug ID: 88444
   Summary: [9 Regression] ICE: tree check: expected ssa_name,
have integer_cst in live_on_edge, at tree-vrp.c:468;
or ICE: tree check: expected ssa_name, have
integer_cst in get_value_range, at vr-values.c:84
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Keywords: ice-checking, ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

1.

gcc-9.0.0-alpha20181209 snapshot (r266934) ICEs when compiling the following
snippet w/ -O1 (-O2, -O3, -Ofast):

int ve;

int
br (int, int);

int
nd (long int xt)
{
  return !!xt ? xt : 1;
}

void
yo (int ub)
{
  ve += br (0, 0) + nd (ub);
}

void
fy (void)
{
  int sb = 0;

  ve = ve || br (0, 0);
  ve = ve || br (0, 0);
  ve = ve || br (0, 0);
  yo (sb);
}

% gcc-9.0.0-alpha20181209 -O1 -finline-functions -finline-small-functions
-ftree-vrp -fno-tree-ccp -fno-tree-forwprop -fno-tree-fre -c cki1gbbg.c
during GIMPLE pass: vrp
cki1gbbg.c: In function 'fy':
cki1gbbg.c:19:1: internal compiler error: tree check: expected ssa_name, have
integer_cst in live_on_edge, at tree-vrp.c:468
   19 | fy (void)
  | ^~
0x6dceef tree_check_failed(tree_node const*, char const*, int, char const*,
...)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/tree.c:9757
0x6d9c18 tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/tree.h:3157
0x6d9c18 live_on_edge
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/tree-vrp.c:468
0x6d9c18 live_on_edge
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/tree-vrp.c:465
0xf7b53f finish_register_edge_assert_for
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/tree-vrp.c:3510
0xf8a927 find_conditional_asserts
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/tree-vrp.c:3554
0xf8a927 find_assert_locations_1
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/tree-vrp.c:3823
0xf8ea12 find_assert_locations
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/tree-vrp.c:3984
0xf8ea12 insert_range_assertions
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/tree-vrp.c:4308
0xf8ea12 execute_vrp
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/tree-vrp.c:6758

2.

Replacing -O1 w/ -Og yield the following:

% gcc-9.0.0-alpha20181209 -Og -finline-functions -finline-small-functions
-ftree-vrp -fno-tree-ccp -fno-tree-forwprop -fno-tree-fre -c cki1gbbg.c
during GIMPLE pass: printf-return-value
cki1gbbg.c: In function 'fy':
cki1gbbg.c:19:1: internal compiler error: tree check: expected ssa_name, have
integer_cst in get_value_range, at vr-values.c:84
   19 | fy (void)
  | ^~
0x6dceef tree_check_failed(tree_node const*, char const*, int, char const*,
...)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/tree.c:9757
0x6f4cd1 tree_check(tree_node const*, char const*, int, char const*, tree_code)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/tree.h:3413
0x6f4cd1 vr_values::get_value_range(tree_node const*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/vr-values.c:84
0x14f9bd6 evrp_range_analyzer::get_value_range(tree_node const*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/gimple-ssa-evrp-analyze.h:41
0x14f9bd6 evrp_range_analyzer::try_find_new_range(tree_node*, tree_node*,
tree_code, tree_node*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/gimple-ssa-evrp-analyze.c:87
0x14fa9d3
evrp_range_analyzer::record_ranges_from_incoming_edge(basic_block_def*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/gimple-ssa-evrp-analyze.c:193
0x14faf4d evrp_range_analyzer::enter(basic_block_def*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/gimple-ssa-evrp-analyze.c:76
0x151a7eb before_dom_children
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/gimple-ssa-sprintf.c:4157
0x14d78d2 dom_walker::walk(basic_block_def*)
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/domwalk.c:353
0x1515acd execute
   
/var/tmp/portage/sys-devel/gcc-9.0.0_alpha20181209/work/gcc-9-20181209/gcc/gimple-ssa-sprintf.c:4192

[Bug fortran/88139] ICE in get_c_type_name, at fortran/dump-parse-tree.c:3047

[kargl at gcc dot gnu.org]

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

--- Comment #5 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #4)
> Record F2018 constraint.
> 
> C1554  If proc-language-binding-spec is specified for a procedure, each
>of its dummy arguments shall be an interoperable procedure (18.3.7)
>or a variable that is interoperable (18.3.5, 18.3.6), assumed-shape,
>assumed-rank, assumed-type, of type CHARACTER with assumed length,
>or that has the ALLOCATABLE or POINTER attribute.
> 
> I had a patch for this, but lost it when committing my last 10 patches.

Thankfully, there are mailing list archives.  See

https://gcc.gnu.org/ml/fortran/2018-12/msg00038.html

for the patch.

[Bug fortran/88139] ICE in get_c_type_name, at fortran/dump-parse-tree.c:3047

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #4 from kargl at gcc dot gnu.org ---
Record F2018 constraint.

C1554  If proc-language-binding-spec is specified for a procedure, each
   of its dummy arguments shall be an interoperable procedure (18.3.7)
   or a variable that is interoperable (18.3.5, 18.3.6), assumed-shape,
   assumed-rank, assumed-type, of type CHARACTER with assumed length,
   or that has the ALLOCATABLE or POINTER attribute.

I had a patch for this, but lost it when committing my last 10 patches.

[Bug fortran/87922] ICE in gfc_wide_strlen, at fortran/scanner.c:142

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|9.0 |8.3

--- Comment #3 from kargl at gcc dot gnu.org ---
Fixed on trunk and branch-8.  Have wrong PR number in ChangeLogs on trunk,
which is why the commit is not reflected here.

[Bug fortran/87922] ICE in gfc_wide_strlen, at fortran/scanner.c:142

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Tue Dec 11 02:34:44 2018
New Revision: 266969

URL: https://gcc.gnu.org/viewcvs?rev=266969&root=gcc&view=rev
Log:
2018-12-10  Steven G. Kargl  

PR fortran/87922
* io.c (gfc_match_open): Additional checks on ASYNCHRONOUS.

2018-12-10  Steven G. Kargl  

PR fortran/87922
* gfortran.dg/io_constraints_8.f90: Update error message.
* gfortran.dg/pr87922.f90: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr87922.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/io.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/io_constraints_8.f90

[Bug tree-optimization/86196] [9 Regression] Bogus -Wrestrict on memcpy between array elements at unequal indices

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Sebor  ---
Fixed via r266967.

[Bug tree-optimization/84774] [meta-bug] bogus/missing -Wrestrict

[msebor at gcc dot gnu.org]

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

Bug 86196 Summary: [9 Regression] Bogus -Wrestrict on memcpy between array 
elements at unequal indices
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86196

   What|Removed |Added

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

[Bug tree-optimization/86196] [9 Regression] Bogus -Wrestrict on memcpy between array elements at unequal indices

[msebor at gcc dot gnu.org]

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

--- Comment #3 from Martin Sebor  ---
Author: msebor
Date: Tue Dec 11 01:22:08 2018
New Revision: 266967

URL: https://gcc.gnu.org/viewcvs?rev=266967&root=gcc&view=rev
Log:
PR tree-optimization/86196 - Bogus -Wrestrict on memcpy between array elements
at unequal indices

gcc/ChangeLog:

PR tree-optimization/86196
* gimple-ssa-warn-restrict.c (builtin_memref::builtin_memref): Use
base size only of arrays.

gcc/testsuite/ChangeLog:

PR tree-optimization/86196
* gcc.dg/Wrestrict-18.c: New test.

Added:
trunk/gcc/testsuite/gcc.dg/Wrestrict-18.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/gimple-ssa-warn-restrict.c
trunk/gcc/testsuite/ChangeLog

[Bug target/88433] wrong code for printf after a pointer cast from a pointer to an adjacent object

[msebor at gcc dot gnu.org]

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

--- Comment #1 from Martin Sebor  ---
Then again, the "problem" would disappear if the middle-end could be made to
understand that memcmp(&p, &q, sizeof p) is the same thing as p == q for any
integer or pointer types p and q.  So maybe it is a middle-end issue because
the back-end doesn't know and can't tell that y is the same as *p.

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

[msebor at gcc dot gnu.org]

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

Bug ID: 88443
   Summary: [meta-bug] bogus/missing -Wstringop-overflow warnings
   Product: gcc
   Version: 9.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: ---

This is a meta-bug to track false positives and negatives in the
-Wstringop-overflow warning.

[Bug c/88442] New: Misleading error message with duplicated struct definitions

[a...@linux-foundation.org]

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

Bug ID: 88442
   Summary: Misleading error message with duplicated struct
definitions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: a...@linux-foundation.org
  Target Milestone: ---

q:/home/akpm> cat t.c
struct foo;

struct foo { int a; };

struct foo { int a, b; };

q:/home/akpm> gcc -c t.c
t.c:5:8: error: redefinition of 'struct foo'
 struct foo { int a, b; };
^~~
t.c:1:8: note: originally defined here
 struct foo;


It's arguably misleading and certainly unuseful to say that struct foo was
originally defined at line 1.  You sit there scratching your head looking at
line 1 wondering why it didn't compile. It would be more useful to point the
user at line 3!

[Bug tree-optimization/88441] New: missing warning on a buffer overflow with non-constant offset and constant size

[msebor at gcc dot gnu.org]

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

Bug ID: 88441
   Summary: missing warning on a buffer overflow with non-constant
offset and constant size
   Product: gcc
   Version: 9.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: ---

The calls to memcpy in both functions either very likely or certainly overflow
the destination yet they are not diagnosed.  At least in the simple cases when
the size of the destination (or source) object is known sufficiently early,
before the calls are transformed to MEM_REF, the overflow could be diagnosed.

$ cat x.c && gcc -O2 -S -Wall -fdump-tree-gimple=/dev/stdout x.c
char a[8];

void f (int i, const void *p)
{
  // overflow very likely
  __builtin_memcpy (a + i, p, sizeof a);   // missing -Wstringop-overflow
}

void g (unsigned i, const void *p)
{
  // overflow certain
  if (i)
__builtin_memcpy (a + i, p, sizeof a);   // missing -Wstringop-overflow
}
f (int i, const void * p)
{
  _1 = (sizetype) i;
  _2 = &a + _1;
  __builtin_memcpy (_2, p, 8);
}


g (unsigned int i, const void * p)
{
  if (i != 0) goto ; else goto ;
  :
  _1 = (sizetype) i;
  _2 = &a + _1;
  __builtin_memcpy (_2, p, 8);
  :
}

[Bug tree-optimization/88440] size optimization of memcpy-like code

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
I thought I had a dup of this bug somewhere which was asking for this
optimization to moved to -O2 (and -Os) and above rather than keep it at -O3 and
above.

[Bug c++/88434] operator< should take precedence over template argument in basic.lookup.classref

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||rejects-valid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-11
 Blocks||12944
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
>Semi-related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85570

It might be related in the sense the namelookup of rank is happening a
definition time rather instantation time.

Shorter testcase (without includes):

template  struct rank{};

struct A{ int rank; };

template
bool comp_rank(const T &a, const T &b){
return a.rank < b.rank;
}

int main()
{
A a{42}, b{0};
comp_rank(a, b);
}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12944
[Bug 12944] [meta-bug] C++ name-lookup problems

[Bug tree-optimization/88440] New: size optimization of memcpy-like code

[hoganmeier at gmail dot com]

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

Bug ID: 88440
   Summary: size optimization of memcpy-like code
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hoganmeier at gmail dot com
  Target Milestone: ---

https://godbolt.org/z/RTji7B

void foo(char* restrict dst, const char* buf) {
for (int i=0; i<8; ++i)
*dst++ = *buf++;
}

$ gcc -Os
$ gcc -O2
.L2:
mov dl, BYTE PTR [rsi+rax]
mov BYTE PTR [rdi+rax], dl
inc rax
cmp rax, 8
jne .L2

$ gcc -O3
mov rax, QWORD PTR [rsi]
mov QWORD PTR [rdi], rax

$ arm-none-eabi-gcc -O3 -mthumb -mcpu=cortex-m4
ldr r3, [r1]  @ unaligned
ldr r2, [r1, #4]  @ unaligned
str r2, [r0, #4]  @ unaligned
str r3, [r0]  @ unaligned

The -O3 code is both faster and smaller for both ARM and x64:
"note: Loop 1 distributed: split to 0 loops and 1 library calls."

Should be considered for -O2 and -Os as well.

[Bug c++/85570] Resolution of unqualified-id in member access involving templates fails

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
Note typedef has a similar issue and you don't even need to have main or an use
of test to show the issue:
  void func() {}
};
template 
struct C : public A {
  typedef A TheA;
};
template 
void test1() {
  C b;
  b.TheA::func();
}

[Bug tree-optimization/88439] New: missing -Wrestrict on memcpy with a variable offset

[msebor at gcc dot gnu.org]

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

Bug ID: 88439
   Summary: missing -Wrestrict on memcpy with a variable offset
   Product: gcc
   Version: 9.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: ---

Thew -Wrestrict warning doesn't trigger for the following overlapping call to
memcpy even though it seems that it could:

$ cat x.c && gcc -O2 -S -Wall x.c
char a[32][32];

void g (int i, int j)
{
  if (i == j) // typo, should be: i != j
__builtin_memcpy (a[j], a[i], sizeof a[i]);   // missing -Wrestrict
}

[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||msebor at gcc dot gnu.org
 Resolution|--- |DUPLICATE

--- Comment #14 from Martin Sebor  ---
This is a duplicate of bug 87950, with most of the same discussion.

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

[Bug c/87950] GCC warns about reaching end of non-void function when all switch cases are completely handled

[msebor at gcc dot gnu.org]

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

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

[Bug fortran/88438] New: A pointer function reference can denote a variable in any variable definition context.

[juergen.reuter at desy dot de]

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

Bug ID: 88438
   Summary: A pointer function reference can denote a variable in
any variable definition context.
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: juergen.reuter at desy dot de
  Target Milestone: ---

Apparently this feature of F2008 is still flagged as unimplemented in the F2008
chart on the gfortran wiki page. Today there was a discussion on the Intel
Forum, https://software.intel.com/en-us/comment/1930834#comment-1930834
that the following code is valid F2008, but not valid F2003, because the
selector is a function reference with a data pointer result. 
I think this should be marked as an item in the chart here
https://gcc.gnu.org/wiki/Fortran2008Status with a red "No" status. 
The code discussed in that Intel forum is repeated here:
module mod

implicit none
private

public get
public inc

type, public :: t
   integer :: i = 5
end type t

contains

function get(x) result(p)
   integer, pointer :: p
   type(t), target, intent(in) :: x
   p => x%i
end function get

subroutine inc(i)
   integer, intent(inout) :: i
   i = i + 1
end subroutine inc

end module mod


program assoc_func_intent

use mod
implicit none

type(t) :: x

print *,x%i
associate(p => get(x))
   call inc(p)
end associate
print *,x%i 

end program assoc_func_intent

[Bug middle-end/86979] [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres  ---
Created attachment 45204
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45204&action=edit
tarball for gcc9 -S -da
/opt/gcc/work/gcc/testsuite/gcc.c-torture/compile/pr69102.c -Og
-fschedule-insns2 -fselective-scheduling2 -fno-tree-fre
--param=max-sched-extend-regions-iters=2 -m32

> Perhaps could you attach a tarball with -da dumps with the above options,
> so I can try to figure out why I can't reproduce this?

tarball attached.

[Bug middle-end/86979] [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin

[dominiq at lps dot ens.fr]

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

--- Comment #4 from Dominique d'Humieres  ---
Created attachment 45203
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45203&action=edit
auto-host.h

> Any particular tuning option (what -march/-mtune is the default)?

Target: x86_64-apple-darwin18.2.0
Configured with: ../work/configure --prefix=/opt/gcc/gcc9w
--enable-languages=c,c++,fortran,objc,obj-c++,ada,lto --with-gmp=/opt/mp-new
--with-system-zlib --with-isl=/opt/mp-new --enable-lto --enable-plugin
--with-arch=corei7 --with-cpu=corei7
--with-sysroot=/Applications/Xcode-6.2.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.9.sdk

> Can you attach your auto-host.h?

auto-host.h attached.

[Bug c/88437] New: Excessive struct alignment on x86_64

[jwerner at chromium dot org]

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

Bug ID: 88437
   Summary: Excessive struct alignment on x86_64
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jwerner at chromium dot org
  Target Milestone: ---

Compile the following test file for the x86_64 target:

 struct {
  void *a;
  void *b;
 } mystruct __attribute__((__section__(".data.mystruct"));

Then run objdump -x on the output file. The .data.mystruct section will have an
alignment of 2**4, even though the largest member of the struct only requires
an alignment of 2**3. GCC always seems to align structures to the whole struct
size, at least to a maximum of 2**5.

This behavior seems questionable at best, and it is inconsistent from all other
architectures (I tested i686 and aarch64, both of which always only align to
the largest member). I assume it may be intended as a cache line
optimization(?), but it affects code size very negatively, so it should at
least be up to the user and not hardcoded by architecture. I couldn't find any
flag in the documentation to disable this. It even occurs with -Os even though
that's meant to strongly favor size over other optimizations.

[Bug target/88435] Compiling with optimizations causes the compiler to fail.

[pkoning at gcc dot gnu.org]

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

--- Comment #2 from pkoning at gcc dot gnu.org ---
I don't see it in the current V9, rev 266823.

./xgcc -B. -O2 -S ~/Documents/pr88435.c -m10 
cat pr88435.s 

.text
.even
.globl  _pollConsole
_pollConsole:
mov @$-0220,r0
mov $011,r1
L_4:
clc
ror r0
dec r1
bne L_4
bic $-02,r0
rts pc

Clearly this is not optimal -- it shouldn't do this with a shift but rather
using a "BIT" instruction.  But the code does produce the correct answer and
the compiler doesn't fail.

[Bug lto/88422] collect2.exe: fatal error: lto-wrapper returned 1 exit status: file not recognized: file truncated

[wilson at gcc dot gnu.org]

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

--- Comment #4 from Jim Wilson  ---
I used a cross compiler, so ulong_type is easy enough to check.  For
simple-object-elf.i I see
__extension__ typedef unsigned long long uint64_t;
...
__extension__ typedef uint64_t ulong_type;
which looks right.

[Bug testsuite/88436] New: [9 regression] r265421 causes gcc.target/powerpc/pr54240.c to fail

[seurer at gcc dot gnu.org]

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

Bug ID: 88436
   Summary: [9 regression] r265421 causes
gcc.target/powerpc/pr54240.c to fail
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: testsuite
  Assignee: unassigned at gcc dot gnu.org
  Reporter: seurer at gcc dot gnu.org
  Target Milestone: ---

Looks like this test case may have been missed when updating those affected by
the changes in this revision.

spawn -ignore SIGHUP /home/seurer/gcc/build/gcc-test2/gcc/xgcc
-B/home/seurer/gcc/build/gcc-test2/gcc/
/home/seurer/gcc/gcc-test2/gcc/testsuite/gcc.target/powerpc/pr54240.c
-fno-diagnostics-show-caret -fno-diagnostics-show-line-numbers
-fdiagnostics-color=never -O2 -misel -fdump-tree-phiopt-details -S -o pr54240.s
PASS: gcc.target/powerpc/pr54240.c (test for excess errors)
FAIL: gcc.target/powerpc/pr54240.c scan-tree-dump phiopt1 "Hoisting adjacent
loads"

[Bug rtl-optimization/88435] Compiling with optimizations causes the compiler to fail.

[mattis at mattisborgen dot se]

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

--- Comment #1 from Mattis Lind  ---
The very same bug is present in 9.0

The problem goes away if you change to pdp-11/40 rather than pdp-11/10 using
-m40 option.

[Bug target/88271] Omit test instruction after add

[bugzi...@poradnik-webmastera.com]

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

--- Comment #10 from Daniel Fruzynski  ---
Here is possible code transformation to equivalent form, where this
optimization can be simply applied. This change also has a bit surprising side
effect, second nested while loop is unrolled.

[code]
void test2()
{
int level = 0;
int val = 1;
while (1)
{
while(1)
{
val = data[level] << 1;
++level;
if (val)
continue;
else
break;
}

while(1)
{
--level;
val = data[level];
if (!val)
continue;
else
break;

}
}
}
[/code]

[Bug rtl-optimization/88435] New: Compiling with optimizations causes the compiler to fail.

[mattis at mattisborgen dot se]

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

Bug ID: 88435
   Summary: Compiling with optimizations causes the compiler to
fail.
   Product: gcc
   Version: 8.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mattis at mattisborgen dot se
  Target Milestone: ---

pdp11-aout-gcc -save-temps -O2 -v  -m10  -Ttext 1000 -msoft-float 
-nostartfiles  -nodefaultlibs  -nostdlib   -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations gccbug.c 
Using built-in specs.
COLLECT_GCC=pdp11-aout-gcc
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/pdp11-aout/8.2.0/lto-wrapper
Target: pdp11-aout
Configured with: ./configure --target=pdp11-aout --disable-nls
--without-headers --enable-languages=c
Thread model: single
gcc version 8.2.0 (GCC) 
COLLECT_GCC_OPTIONS='-save-temps' '-O2' '-v' '-m10' '-Ttext' '1000'
'-msoft-float' '-nostartfiles' '-nodefaultlibs' '-nostdlib'
'-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations'
 /usr/local/libexec/gcc/pdp11-aout/8.2.0/cc1 -E -quiet -v -imultilib
msoft-float gccbug.c -m10 -msoft-float -fno-strict-aliasing -fwrapv
-fno-aggressive-loop-optimizations -O2 -fpch-preprocess -o gccbug.i
ignoring nonexistent directory
"/usr/local/lib/gcc/pdp11-aout/8.2.0/../../../../pdp11-aout/sys-include"
ignoring nonexistent directory
"/usr/local/lib/gcc/pdp11-aout/8.2.0/../../../../pdp11-aout/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/pdp11-aout/8.2.0/include
 /usr/local/lib/gcc/pdp11-aout/8.2.0/include-fixed
End of search list.
COLLECT_GCC_OPTIONS='-save-temps' '-O2' '-v' '-m10' '-Ttext' '1000'
'-msoft-float' '-nostartfiles' '-nodefaultlibs' '-nostdlib'
'-fno-strict-aliasing' '-fwrapv' '-fno-aggressive-loop-optimizations'
 /usr/local/libexec/gcc/pdp11-aout/8.2.0/cc1 -fpreprocessed gccbug.i -quiet
-dumpbase gccbug.c -m10 -msoft-float -auxbase gccbug -O2 -version
-fno-strict-aliasing -fwrapv -fno-aggressive-loop-optimizations -o gccbug.s
GNU C17 (GCC) version 8.2.0 (pdp11-aout)
compiled by GNU C version 4.2.1 Compatible Apple LLVM 5.0
(clang-500.2.76), GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl
version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (GCC) version 8.2.0 (pdp11-aout)
compiled by GNU C version 4.2.1 Compatible Apple LLVM 5.0
(clang-500.2.76), GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl
version none
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: bc392ef67ca9ec448731a9f0a726ee14
gccbug.c: In function 'pollConsole':
gccbug.c:11:1: error: unrecognizable insn:
 }
 ^
(insn 13 12 14 2 (set (reg:SI 35)
(ashift:SI (reg:SI 34)
(const_int -9 [0xfff7]))) "gccbug.c":5 -1
 (nil))
during RTL pass: vregs
gccbug.c:11:1: internal compiler error: in extract_insn, at recog.c:2304
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.




$ cat gccbug.c
int pollConsole () {
  volatile unsigned int  * rxcsr = (unsigned int *) 0177560; 
  unsigned int tmp =  512 & *rxcsr;
  if (tmp == 512) {
return 1;
  }
  else {
return 0;
  }
} 

The compile fail if the two literals 512 is equal and greater than 16. It also
has to have one single bit set. I.e. 32, 64, 128... 

33,34 woks fine.

$ cat gccbug.i
# 1 "gccbug.c"
# 1 ""
# 1 ""
# 1 "gccbug.c"

int pollConsole () {
  volatile unsigned int * rxcsr = (unsigned int *) 0177560;
  unsigned int tmp = 512 & *rxcsr;
  if (tmp == 512) {
return 1;
  }
  else {
return 0;
  }
}

[Bug c++/86608] [7/8/9 Regression] volatile variable is taken as a constexpr

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
On it now.

[Bug c++/88434] New: operator< should take precedence over template argument in basic.lookup.classref

[gieseanw+gcc at gmail dot com]

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

Bug ID: 88434
   Summary: operator< should take precedence over template
argument in basic.lookup.classref
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gieseanw+gcc at gmail dot com
  Target Milestone: ---

Semi-related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85570
Bug discovered here: https://stackoverflow.com/q/53712642/27678


The following code does not compile in gcc 9 (or earlier) or clang 8 (or
earlier), but does in MSVC 19.00.23506.

compile with -std=c++11 Code follows:

#include 

using namespace std;

struct A{ int rank; };

template
bool comp_rank(const T &a, const T &b){
return a.rank < b.rank;
}

int main()
{
A a{42}, b{0};
comp_rank(a, b);
}

gcc fails with 

prog.cc: In function 'bool comp_rank(const T&, const T&)':
prog.cc:9:23: error: type/value mismatch at argument 1 in template parameter
list for 'template struct std::rank'
9 | return a.rank < b.rank;
  |   ^~~~
prog.cc:9:23: note:   expected a type, got 'b.rank'


This appears to violate [basic.lookup.classref] which states

In a class member access expression, if the . or -> token is immediately
followed by an identifier followed by a <, the identifier must be looked up to
determine whether the < is the beginning of a template argument list or a
less-than operator. The identifier is first looked up in the class of the
object expression. If the identifier is not found, it is then looked up in the
context of the entire postfix-expression and shall name a class template.

[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
(In reply to Jonathan Wakely from comment #12)
> It's not a useless warning. If I call your function from comment 7 like
> this, I get undefined behaviour:
> 
>   CoverMyBases( Enum{2} );
> 
> Your switch is undefined for this code. That's what GCC is warning you
> about. To tell GCC you will never call the function with any value except
> Enum::A or Enum::B, add
> 
>   default: __builtin_unreachable();

Maybe better to add it after the switch if you want to make sure that you get a
warning with -Wswitch if a new enumerator is added.

[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled

[redi at gcc dot gnu.org]

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

--- Comment #12 from Jonathan Wakely  ---
It's not a useless warning. If I call your function from comment 7 like this, I
get undefined behaviour:

  CoverMyBases( Enum{2} );

Your switch is undefined for this code. That's what GCC is warning you about.
To tell GCC you will never call the function with any value except Enum::A or
Enum::B, add

  default: __builtin_unreachable();

[Bug c++/52869] [DR 1207] "this" not being allowed in noexcept clauses

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #13 from Marek Polacek  ---
Thanks Jon, I'll poke at it some more.

[Bug fortran/88269] ICE in gfc_format_decoder, at fortran/error.c:947

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 CC||kargl at gcc dot gnu.org
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |kargl at gcc dot gnu.org
   Target Milestone|--- |7.5

--- Comment #5 from kargl at gcc dot gnu.org ---
Fixed on trunk, branch-8, and branch-7. Closing

[Bug fortran/88269] ICE in gfc_format_decoder, at fortran/error.c:947

[kargl at gcc dot gnu.org]

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

--- Comment #4 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Dec 10 20:03:32 2018
New Revision: 266962

URL: https://gcc.gnu.org/viewcvs?rev=266962&root=gcc&view=rev
Log:
2018-12-10  Steven G. Kargl  

PR fortran/88269
* io.c (io_constraint): Update macro. If locus line buffer is NULL,
use gfc_current_locus in error messages.
(check_io_constraints): Catch missing IO UNIT in write and read
statements.  io_constraint macro is incompatible here.

2018-12-10  Steven G. Kargl  

PR fortran/88269
* gfortran.dg/pr88269.f90: New test.

Added:
branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr88269.f90
Modified:
branches/gcc-7-branch/gcc/fortran/ChangeLog
branches/gcc-7-branch/gcc/fortran/io.c
branches/gcc-7-branch/gcc/testsuite/ChangeLog

[Bug c++/87951] GCC warns about reaching end of non-void function when all switch is completely handled

[safinaskar at mail dot ru]

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

--- Comment #11 from Askar Safin  ---
(In reply to Jonathan Wakely from comment #10)
> I wish people would just learn how enums work, it's not that complicated.

Okey, now I understand everything. Now I see that, well, -fstrict-enums
silences warning for code from comment #1 only because number of enum
alternatives happen to be power of 2. If it would be, say, 3, then code from
comment #1 will always produce a warning even with -fstrict-enums. And also I
understand that code with "enum class" will always produce a warning.

So, gcc doesn't have way to enable clang-style warning behavior for enums. And
gcc doesn't have such way for "enum class", too. And -fstrict-enums enables
clang-style warning behavior for code from comment #1 only because this code
has power of 2 number of alternatives.

And also I understand that current gcc behavior is not bug and is absolutely
standard-compliant.

But, well, I still don't like current g++ behavior. I want g++ to not report
"reaching end of non-void..." if all switch alternatives are handled, at least
if some optional option is passed to gcc. I want clang behavior. Okey, you may
mark this bug as "wishlist", but I still think that clang-style behavior here
is very useful feature.

Look here, LLVM project was forced to introduce special kludge to make sure g++
will not give useless warnings:
http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations

[Bug c++/88216] [9 Regression] ICE (-std=c++2a) in cxx_eval_constant_expression, at cp/constexpr.c:4602

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek  ---
Patch posted: 
We'll see how that goes.

[Bug fortran/88269] ICE in gfc_format_decoder, at fortran/error.c:947

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Dec 10 19:26:43 2018
New Revision: 266960

URL: https://gcc.gnu.org/viewcvs?rev=266960&root=gcc&view=rev
Log:
2018-12-10  Steven G. Kargl  

PR fortran/88269
* io.c (io_constraint): Update macro. If locus line buffer is NULL,
use gfc_current_locus in error messages.
(check_io_constraints): Catch missing IO UNIT in write and read
statements.  io_constraint macro is incompatible here.

2018-12-10  Steven G. Kargl  

PR fortran/88269
* gfortran.dg/pr88269.f90: New test.

Added:
branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88269.f90
Modified:
branches/gcc-8-branch/gcc/fortran/ChangeLog
branches/gcc-8-branch/gcc/fortran/io.c
branches/gcc-8-branch/gcc/testsuite/ChangeLog

[Bug middle-end/86979] [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Any particular tuning option (what -march/-mtune is the default)?
Can you attach your auto-host.h?
Perhaps could you attach a tarball with -da dumps with the above options, so I
can try to figure out why I can't reproduce this?

[Bug middle-end/86979] [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-10
 Ever confirmed|0   |1

--- Comment #2 from Dominique d'Humieres  ---
> Can't reproduce in current trunk's cross to darwin, can you still reproduce?

Yes with compilers configured with --enable-checking=yes. I don't see any ICE
for those configured with --enable-checking=release.

[Bug middle-end/88397] attribute malloc ignored on function pointers when alloc_size is accepted

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
The problem with attribute noreturn is tracked separately in bug 79604 (the C
front end seems to do the right thing there, as do Clang and ICC in both C and
C++ modes).

For attributes alloc_align and malloc, what concern do you have with accepting
them on function pointers and function types?  (So they work the same way as
alloc_size.)

[Bug middle-end/86979] [9 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2348 with -m32 on darwin

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Can't reproduce in current trunk's cross to darwin, can you still reproduce?

[Bug tree-optimization/86196] [9 Regression] Bogus -Wrestrict on memcpy between array elements at unequal indices

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Any progress on this?

[Bug target/88433] New: wrong code for printf after a pointer cast from a pointer to an adjacent object

[msebor at gcc dot gnu.org]

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

Bug ID: 88433
   Summary: wrong code for printf after a pointer cast from a
pointer to an adjacent object
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: msebor at gcc dot gnu.org
  Target Milestone: ---

This is from Exploring C Semantics and Pointer Provenance:
  https://www.cl.cam.ac.uk/~pes20/cerberus/cerberus-popl2019.pdf

the following test case:
 
https://cerberus.cl.cam.ac.uk/cerberus?defacto/provenance_basic_using_uintptr_t_global_yx.c

GCC emits code with different effects for each of the two functions below even
when the objects x and y are adjacent to each other: in f(), the call to printf
outputs the modified value of y.  In g(), however, it outputs the value of y
before modification.

I consider the code in the test case undefined, but a) my understanding from
Richard is that the middle-end intentionally doesn't track pointer provenance
through integer conversions (and so doesn't necessarily treat this sort of
"object hopping" as undefined), and b) the PNVI model outlined in the paper
above and expected to be proposed for C2X makes this code valid (the model
allows p to take on the provenance of y as a result of the integer <-> pointer
casts).

Looking at the dumps, I think (a) is true for this test case in both f() and
g().  The different output from g() appears to be due to the x86_64 back
performing the assignment *p = 11 only after it has stored the value of y in
the register passed to printf.  Other back-ends I've looked at produce the same
output from g() as from f().

int y = 2, x = 1;

void f (void)
{
  long ix = (long)&x;
  long iy = (long)&y;

  ix += 4;

  int *p = (int*)ix;
  int *q = (int*)iy;

  if (p == q) {
*p = 11;
__builtin_printf ("%i", y);   // prints 11
  }
}

void g (void)
{
  long ix = (long)&x;
  long iy = (long)&y;

  ix += 4;

  int *p = (int*)ix;
  int *q = (int*)iy;

  if (!__builtin_memcmp (&p, &q, sizeof p)) {
*p = 11;
__builtin_printf ("%i", y);   // prints 2
  }
}

[Bug fortran/88269] ICE in gfc_format_decoder, at fortran/error.c:947

[kargl at gcc dot gnu.org]

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

--- Comment #2 from kargl at gcc dot gnu.org ---
Author: kargl
Date: Mon Dec 10 18:05:37 2018
New Revision: 266959

URL: https://gcc.gnu.org/viewcvs?rev=266959&root=gcc&view=rev
Log:
2018-12-10  Steven G. Kargl  

PR fortran/88269
* io.c (io_constraint): Update macro. If locus line buffer is NULL,
use gfc_current_locus in error messages.
(check_io_constraints): Catch missing IO UNIT in write and read
statements.  io_constraint macro is incompatible here.

2018-12-10  Steven G. Kargl  

PR fortran/88269
* gfortran.dg/pr88269.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr88269.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/testsuite/ChangeLog

[Bug target/87369] [9 Regression] Regression on aarch64/copysign-bsl.c since r264264

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|samtebbs at gcc dot gnu.org|rearnsha at gcc dot 
gnu.org

[Bug c/88430] -Wmissing-attributes warnings when including libquadmath headers

[msebor at gcc dot gnu.org]

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

--- Comment #4 from Martin Sebor  ---
The expected mechanism to apply the attributes is by using the new copy
attribute.  (It's been on my to-do list to look into these.)

[Bug c/88430] -Wmissing-attributes warnings when including libquadmath headers

[dominiq at lps dot ens.fr]

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

--- Comment #3 from Dominique d'Humieres  ---
The change occurred between r265975 (no warning) and r266035 (warnings).

[Bug c/88430] -Wmissing-attributes warnings when including libquadmath headers

[jakub at gcc dot gnu.org]

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

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

For quadmath_weak.h it can be easily handled with the attached patch.
There are additional 166 occurrences of warnings in gthr*.h, and some further
ones in libgfortran.
I'm worried about this warning though, because while in the libquadmath case
the alias targets are declared next to it in adjacent header provided by the
same library, in gthr*.h case it is a common example how a weakref is created
for a system header provided function.  For those one often doesn't know what
exact attributes are used and it is quite hard to query that (configure
grepping preprocessed source, what else?).

[Bug rtl-optimization/84345] [8/9 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 1)

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek  ---
I thought the main argument for the qsort checking was to avoid different code
generation between different hosts (e.g. with cross-compilers etc.).
Some of the comparator issues were just easy bugs in the logic, but others are
not really easily convertible to what the checking requires, it is just a
heuristic to get reasonable code generation (especially some of the RTL ones).
The argument about different code generation is gone with gcc_qsort.

[Bug rtl-optimization/84345] [8/9 Regression] ICE: qsort checking failed (error: qsort comparator non-negative on sorted output: 1)

[amonakov at gcc dot gnu.org]

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

--- Comment #6 from Alexander Monakov  ---
I think gcc_qsort doesn't really change things here, validation failure implies
a logic issue in the comparator, so some step is not always working as the
author intended.

And even with gcc_qsort it's still an ice-checking (possibly on valid code).

I guess evidently people don't worry too much about currently open qsort_chk
bugs, but it doesn't make sense that with gcc_qsort we should care even less.

[Bug lto/86004] [9 regression] Several lto test cases begin failing with r260963

[hubicka at ucw dot cz]

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

--- Comment #12 from Jan Hubicka  ---
Thanks a lot for looking into this.  Indeed disabling the tests is
probably good idea, so the patch looks good to me. Somewhere we should
document minimal binutils release supporting incremental link...

Honza

[Bug c++/88413] g++ mangles names involving unresolved names in function argument template parameters differently from the ABI standard.

[brennan at umanwizard dot com]

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

--- Comment #9 from brennan at umanwizard dot com ---
There is an open issue from Oct. 2017 on the ABI standard's official website
(which is a Github repo):

https://github.com/itanium-cxx-abi/cxx-abi/issues/38

It appears to be the exact thing we are seeing here.

The person who opened that issue does think GCC's behavior, although wrong
according to the standard, is better. However it doesn't seem to have gone
anywhere since 10/2017 so I'm not sure whether they will in fact change the
standard.

[Bug c++/88413] g++ mangles names involving unresolved names in function argument template parameters differently from the ABI standard.

[brennan at umanwizard dot com]

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

--- Comment #8 from brennan at umanwizard dot com ---
Yes that is the literal srN string and in fact GCC does output that sometimes,
for example on the following program which made it a lot clearer to me what is
going on.

template 
struct S1 {
};

struct S2
{
  template 
  struct S3 {
static constexpr int val = sizeof(T);
  };
};

template 
void g(S1::val> * = nullptr) {
}

void h() {
  g();
}

in which g is mangled as __Z1gIiEvP2S1IXsrN2S22S3IT_EE3valEE . Clang
mangles it as __Z1gIiEvP2S1IXsr2S22S3IT_EE3valEE -- notice there is no "N" in
Clang's version. Again I feel Clang is correct, based on my understanding of
the standard.

GCC apparently uses only the two productions
 ::= sr   # T::x /
decltype(p)::x
 ::= srN  + E

# T::N::x
/decltype(p)::N::x

But if you look up "unresolved-type" in the standard, it is clear that those
two productions should only be used when the first element in the chain is a
template parameter, not some random class or namespace. So it is wrong to
encode "S2::S3::val" with either of those, because "S2" is not an
"". Presumably this is what the standard authors were getting
at by using the letter "T" in the comment.

The production GCC should be using in that program, and the one Clang actually
does use, is:

 ::= [gs] sr + E
  
# A::x,
N::y, A::z; "gs" means leading "::"

In S2::S3::val, each of S2 and S3 is an ""
and val is a "".

[Bug sanitizer/85777] [7/8/9 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[vincent-gcc at vinc17 dot net]

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

--- Comment #6 from Vincent Lefèvre  ---
But this cannot apply to projects that use GNU Automake, which does not
generate such rules. And with Automake, things are more complex in practice,
because in the rules, there are additional options for dependency tracking.

[Bug tree-optimization/85459] [8/9 Regression] Larger code generated from GMP template meta-programming

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jamborm at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
On the #c4 testcase it is:
/opt/notnfs/gcc-bisect/obj/gcc/cc1plus.24 -quiet -O3 -fno-exceptions
pr85459.C; g++ -c -o pr85459{.o,.s}; size pr85459.o
   textdata bss dec hex filename
438   0   0 438 1b6 pr85459.o
/opt/notnfs/gcc-bisect/obj/gcc/cc1plus.255509 -quiet -O3 -fno-exceptions
pr85459.C; g++ -c -o pr85459{.o,.s}; size pr85459.o
   textdata bss dec hex filename
334 152   0 486 1e6 pr85459.o
/opt/notnfs/gcc-bisect/obj/gcc/cc1plus.255510 -quiet -O3 -fno-exceptions
pr85459.C; g++ -c -o pr85459{.o,.s}; size pr85459.o
   textdata bss dec hex filename
833 160   0 993 3e1 pr85459.o
/opt/notnfs/gcc-bisect/obj/gcc/cc1plus.266943 -quiet -O3 -fno-exceptions
pr85459.C; g++ -c -o pr85459{.o,.s}; size pr85459.o
   textdata bss dec hex filename
813 160   0 973 3cd pr85459.o
So the only significant growth there is due to the SRA change.
For -Os the sizes are much larger, 1075 at r24, 789 at r255509, 919 at
r255510 and 939 at r266943.

[Bug sanitizer/85777] [7/8/9 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek  ---
That can be dealt in the Makefile rules, for sanitization use something like
$(CC) $(CFLAGS) $(WARNOPTS) -S -o /dev/null $<
$(CC) $(CFLAGS) $(SANITIZEOPTS) -c -o $@ $< 2>/dev/null
or similar.

[Bug sanitizer/85777] [7/8/9 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[vincent-gcc at vinc17 dot net]

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

--- Comment #4 from Vincent Lefèvre  ---
(In reply to Jakub Jelinek from comment #3)
> If you care about warnings as well as sanitization, I'd suggest separate
> builds for warnings and for sanitization, the latter perhaps with -w.

This is fine for code that is fixed, but this makes developing and debugging
harder, when testing code just after making changes.

[Bug target/88418] [7/8/9 Regression] ICE in extract_insn, at recog.c:2305 (error: unrecognizable insn)

[uros at gcc dot gnu.org]

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

--- Comment #2 from uros at gcc dot gnu.org ---
Author: uros
Date: Mon Dec 10 15:47:16 2018
New Revision: 266958

URL: https://gcc.gnu.org/viewcvs?rev=266958&root=gcc&view=rev
Log:
PR target/88418
* config/i386/i386.c (ix86_expand_sse_cmp): For vector modes,
check operand 1 with vector_operand predicate.
(ix86_expand_sse_movcc): For vector modes, check op_true with
vector_operand, not nonimmediate_operand.

testsuite/ChangeLog:

PR target/88418
* gcc.target/i386/pr88418.c: New test.


Added:
trunk/gcc/testsuite/gcc.target/i386/pr88418.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/config/i386/i386.c
trunk/gcc/testsuite/ChangeLog

[Bug libstdc++/88290] [9 regression] 23_containers/deque/erasure.cc fails after r266672

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

  Component|testsuite   |libstdc++

--- Comment #3 from Jonathan Wakely  ---
Yes, it would have been r266673.

The component should have been "libstdc++" (I won't see it otherwise). It was a
problem in the library headers (revealed by the tests), not a problem in the
testsuite itself.

[Bug lto/86004] [9 regression] Several lto test cases begin failing with r260963

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #11 from Jakub Jelinek  ---
Created attachment 45201
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45201&action=edit
gcc9-pr86004.patch

Untested testsuite fix, tested both on a system with binutils 2.25 (where those
tests previously failed, now UNSUPPORTED) and recent ones (where it still
PASSes).

[Bug testsuite/88290] [9 regression] 23_containers/deque/erasure.cc fails after r266672

[seurer at gcc dot gnu.org]

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

seurer at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from seurer at gcc dot gnu.org ---
Not sure when it was fixed but it is not failing any longer.

[Bug debug/88432] Dwarf line numbering inadequate when using -fstack-protector-strong

[alahay01 at gcc dot gnu.org]

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

--- Comment #3 from alahay01 at gcc dot gnu.org ---
I considered a number of solutions, but they all had issues:


1) Place the RTL for the stack guard inside the prologue, giving:

*function prologue rtl
*stack guard code (__stack_chk_guard)
*NOTE_INSN_PROLOGUE_END
*NOTE_INSN_FUNCTION_BEG
*rest of the function rtl

Then this would then automatically stop the line number being dumped for the
stack guard. The rest of the assembly would be the same.

Downside here is that in the future new optimisations could be added that have
exactly the same issue.


2) Add line numbers to NOTE_INSN_FUNCTION_BEG and remove line numbers from
stack guard code (which currently has the line number for the { line)


3) Ensure the stack guard code has the line number of the first line of the
function main body.


I'm not sure if 2 and 3 will break instruction reordering.

[Bug fortran/88393] [7/8/9 Regression] [OOP] Segfault with type-bound assignment

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

   What|Removed |Added

 CC||vehre at gcc dot gnu.org

--- Comment #3 from janus at gcc dot gnu.org ---
(In reply to janus from comment #2)
> Looking at this range of commits, I suspect that r241885 is the culprit.


Using -fdump-tree-original to compare the dumps of versions 6 and 7 shows that
the assignment subroutine itself is identical in both, but the dump from v7
contains additional code after the call to 'ass' that is not present in v6.

With v6, the call is translated as follows:

  {
struct __class_m_T_t class.7;
struct __class_m_T_t class.8;

class.7._vptr = (struct __vtype_m_T * {ref-all}) &__vtab_m_T;
class.7._data = &arr[1].c;
class.8._vptr = (struct __vtype_m_T * {ref-all}) &__vtab_m_T;
class.8._data = &arr[0].c;
ass (&class.7, &class.8);
  }


With v7, it looks much bulkier:

  {
struct __class_m_T_t class.7;
struct __class_m_T_t class.8;
struct t D.3602;
struct __class_m_T_t * D.3603;
struct __class_m_T_t D.3604;
void * restrict D.3605;

class.7._vptr = (struct __vtype_m_T * {ref-all}) &__vtab_m_T;
class.7._data = &arr[1].c;
class.8._vptr = (struct __vtype_m_T * {ref-all}) &__vtab_m_T;
D.3602 = arr[0].c;
class.8._data = &D.3602;
D.3603 = &class.8;
D.3604 = *D.3603;
ass (&class.7, D.3603);
D.3603->_cs_length = D.3604._cs_length;
if ((void *) D.3604.cs != 0B)
  {
D.3605 = (void * restrict) __builtin_malloc (MAX_EXPR <(unsigned long)
D.3603->_cs_length, 1>);
D.3603->cs = (character(kind=1)[1:0] *) D.3605;
__builtin_memcpy (D.3603->cs, D.3604.cs, (unsigned long)
D.3603->_cs_length);
  }
else
  {
D.3603->cs = 0B;
  }
if (D.3603->_data->cs != 0B)
  {
__builtin_free ((void *) D.3603->_data->cs);
D.3603->_data->cs = 0B;
  }
  }

Looks like there is some copying and deallocation of the allocatable components
here. Not sure why that would be necessary ...?!?

[Bug debug/88432] Dwarf line numbering inadequate when using -fstack-protector-strong

[alahay01 at gcc dot gnu.org]

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

--- Comment #2 from alahay01 at gcc dot gnu.org ---
Created attachment 45200
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45200&action=edit
Final assembly dump for the .cc file with dwarf

[Bug debug/88432] Dwarf line numbering inadequate when using -fstack-protector-strong

[alahay01 at gcc dot gnu.org]

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

--- Comment #1 from alahay01 at gcc dot gnu.org ---
Created attachment 45199
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45199&action=edit
rtl final dump for the .cc file

[Bug demangler/87675] Stack Overflow in function next_is_type_qual() in cp-demangle.c, as demonstrated by "nm -C"

[nickc at gcc dot gnu.org]

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

--- Comment #8 from Nick Clifton  ---
(In reply to Tanaya Patil from comment #7)
> Should we expect this fix to be in Binutil 2.32?

Yes. :-)

[Bug debug/88432] New: Dwarf line numbering inadequate when using -fstack-protector-strong

[alahay01 at gcc dot gnu.org]

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

Bug ID: 88432
   Summary: Dwarf line numbering inadequate when using
-fstack-protector-strong
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: alahay01 at gcc dot gnu.org
  Target Milestone: ---

Created attachment 45198
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45198&action=edit
Example breaking program

Using -fstack-protector-strong will cause GDB to break on the wrong line when
placing a breakpoint on a function.

[ Note that the GCC provided with Ubuntu will default to
-fstack-protector-strong, causing all function breakpoints to break on the
wrong line. This breaks roughly 50 GDB tests when run on x86 and AArch64 Ubuntu
]

The issue in GDB
=

Consider the following program:
47: int main ()
48: {
49:   char arg2 = 2;
50:   signed char arg3 = 3;

(full program attached. Ignore everything in it except for main. Testcase taken
from the GDB testsuite.)

When compiled with -fstack-protector-strong, then running it in GDB,
“breakpoint main” will stop at line 48, the "{". This is wrong, it should
instead stop on line 49 – the first line of the function body.

GDB figures this out by looking at the dwarf line numbers. It finds the entry
for the start of the function (from other dwarf entries), and assumes that it
the entry for the function prologue. It then jumps forward one entry.

With stack proctector turned off we get the following. Note that the dwarf
label for main points at index 2.

INDEXLINE ADDRESS
0  45 0x00400680
1  45 0x00400680
2  48 0x00400688 - main: prologue pt1
3  49 0x004006ac - main: first line of function
4  50 0x004006b4 - main: second line of function
...etc

With stack protector on (like Ubuntu):

INDEXLINE ADDRESS
0  45 0x00400680
1  45 0x00400680
2  48 0x00400688 - main: prologue pt1
3  48 0x00400698 - main: stack protector code
4  49 0x004006ac - main: first line of function
5  50 0x004006b4 - main: second line of function
...etc

Ok, we could jump forward two entries. But then breaks with the following (with
either stack protector on or off):
47: int main ()
48: {  char arg2 = 2;
49: signed char arg3 = 3;

It will result in the same line table, with just two entries at line 48:

INDEXLINE ADDRESS
0  45 0x00400680
1  45 0x00400680
2  48 0x00400688 - main: prologue pt1
3  48 0x00400698 - main: stack protector code
4  49 0x004006ac - main: second line of function
...etc

There is no way to tell if a repeated line is the first line of code or the
stack protector.



The underlying issue in GCC
===

See the attached rtl final dump from GCC (note: aarch64 code, but that doesn't
matter).

With the stack protector on, GCC produces RTL for the stack protector at the
beginning of the function, after the prologue.
You roughly get:
*function prologue rtl
*NOTE_INSN_PROLOGUE_END
*NOTE_INSN_FUNCTION_BEG
*stack guard code (__stack_chk_guard)
*rest of the function rtl

The stack guard rtl is given the line number of the "{" line.

When dumping line locations, notice_source_line() decides which RTL expressions
should cause a dump.  It will force a dump of the first expression following
the end of the prologue - expecting this to be the first line of the function.
This gives us:

.LFB1:
.loc 1 48 0.   – function prologue.
.cfi_startproc
sub sp, sp, #176
.cfi_def_cfa_offset 176
stp  x29, x30, [sp, 32]
.cfi_offset 29, -144
.cfi_offset 30, -136
add x29, sp, 32
.cfi_def_cfa 29, 144
str   x19, [sp, 48]
.cfi_offset 19, -128
.loc 1 48 0--   Start of  stack guard code
adrp   x0, __stack_chk_guard
add x0, x0, :lo12:__stack_chk_guard
ldr   x1, [x0]
str   x1, [x29, 136]
mov   x1,0
.loc 1 49 0.   – first line of function
mov   w0, 2
strbw0, [x29, 45]
.loc 1 50 0
mov   w0, 3
strbw0, [x29, 46]

[Bug c/88430] -Wmissing-attributes warnings when including libquadmath headers

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-10
 CC||msebor at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Richard Biener  ---
Confirmed.

[Bug tree-optimization/85762] [8/9 Regression] range-v3 abstraction overhead not optimized away

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-12-10
 CC||jamborm at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jamborm at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #3 from Martin Jambor  ---
Sure.

[Bug d/88431] New: link errors on build

[dcb314 at hotmail dot com]

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

Bug ID: 88431
   Summary: link errors on build
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: dcb314 at hotmail dot com
  Target Milestone: ---

For this configure line:

../trunk/configure --prefix=/home/dcb/gcc/results.266950 \
--disable-multilib \
--disable-werror \
--enable-checking=df,extra,fold,rtl,yes \
--enable-languages=c,c++,d,fortran

sed 's/-O2/-O3 -march=native -Wlogical-op/' < Makefile > Makefile.tmp
mv Makefile.tmp Makefile

I got:

/home/dcb/gcc/working/./gcc/xgcc -shared-libgcc -B/home/dcb/gcc/working/./gcc
-nostdinc++ -L/home/dcb/gcc/working/x86_64-pc-linux-gnu/libstdc++-v3/src
-L/home/dcb/gcc/working/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs
-L/home/dcb/gcc/working/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/dcb/gcc/results.266950/x86_64-pc-linux-gnu/bin/
-B/home/dcb/gcc/results.266950/x86_64-pc-linux-gnu/lib/ -isystem
/home/dcb/gcc/results.266950/x86_64-pc-linux-gnu/include -isystem
/home/dcb/gcc/results.266950/x86_64-pc-linux-gnu/sys-include -D_GNU_SOURCE
-D_DEBUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-I. -I../../../../trunk/libsanitizer/lsan -I.. -I
../../../../trunk/libsanitizer/include -I ../../../../trunk/libsanitizer -Wall
-W -Wno-unused-parameter -Wwrite-strings -pedantic -Wno-long-long -fPIC
-fno-builtin -fno-exceptions -fno-rtti -fomit-frame-pointer -funwind-tables
-fvisibility=hidden -Wno-variadic-macros -I../../libstdc++-v3/include
-I../../libstdc++-v3/include/x86_64-pc-linux-gnu
-I../../../../trunk/libsanitizer/../libstdc++-v3/libsupc++ -std=gnu++11 -g -O3
-march=native -Wlogical-op -D_GNU_SOURCE -MT lsan_allocator.lo -MD -MP -MF
.deps/lsan_allocator.Tpo -c
../../../../trunk/libsanitizer/lsan/lsan_allocator.cc  -fPIC -DPIC -o
.libs/lsan_allocator.o
/usr/bin/ld: core/.libs/atomic.o: relocation R_X86_64_32S against hidden symbol
`gdc.dso_slot' can not be used when making a shared object
/usr/bin/ld: core/.libs/attribute.o: relocation R_X86_64_32S against hidden
symbol `gdc.dso_slot' can not be used when making a shared object
/usr/bin/ld: core/.libs/bitop.o: relocation R_X86_64_32 against
`.rodata.str1.8' can not be used when making a shared object; recompile with
-fPIC

[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #15 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #14 from Jakub Jelinek  ---
> That would be the
>  gcc_checking_assert (TREE_TYPE (name) == t);
> assert then.  So, what is TREE_TYPE (name) and what is t when this happens?

Here's what I find (after recompiling tree.c with -g3 -O0):

(gdb) up
#1  0x09777f85 in fld_incomplete_type_of (t=0xfa58cc60, fld=0xfeffd6a8)
at /vol/gcc/src/hg/trunk/local/gcc/tree.c:5312
5312  gcc_checking_assert (TREE_TYPE (name) == t);
(gdb) p name
$1 = (tree) 0xfa593000
(gdb) call TREE_TYPE (name)
$2 = (tree) 0xfa58ccc0
(gdb) pt
warning: Expression is not an assignment (and might have no effect)
 
constant 64>
unit-size 
constant 8>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type fa58ccc0
fields 
static unsigned SI
size 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
fa542900>
side-effects volatile unsigned nonaddressable SI
/var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/libada/adainclude/s-tpobop.ads:193:7
size  unit-size 
align:32 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context 
chain 
side-effects volatile unsigned nonaddressable QI
/var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/libada/adainclude/s-tpobop.ads:194:7
size 
unit-size 
align:8 warn_if_not_align:0 offset_align 128 offset  bit-offset  context  chain
>> context 
Ada size 
constant visited 48>
pointer_to_this  reference_to_this  chain >
(gdb) p t
$3 = (tree) 0xfa58cc60
(gdb) pt
warning: Expression is not an assignment (and might have no effect)
 
constant 64>
unit-size 
constant 8>
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type fa58cc60
fields 
static unsigned SI
size 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
fa542900>
side-effects volatile unsigned nonaddressable SI
/var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/libada/adainclude/s-tpobop.ads:193:7
size  unit-size 
align:32 warn_if_not_align:0 offset_align 128
offset 
bit-offset  context 
chain 
side-effects volatile unsigned nonaddressable QI
/var/gcc/regression/trunk/11-gcc/build/i386-pc-solaris2.11/libada/adainclude/s-tpobop.ads:194:7
size 
unit-size 
align:8 warn_if_not_align:0 offset_align 128 offset  bit-offset  context  chain
>> context 
Ada size 
constant visited 48>
chain >

[Bug tree-optimization/88427] [9 Regression] ICE: tree check: expected integer_cst, have plus_expr in get_len, at tree.h:5617

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/88427] [9 Regression] ICE: tree check: expected integer_cst, have plus_expr in get_len, at tree.h:5617

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Mon Dec 10 13:56:51 2018
New Revision: 266955

URL: https://gcc.gnu.org/viewcvs?rev=266955&root=gcc&view=rev
Log:
2018-12-10  Richard Biener  

PR tree-optimization/88427
* vr-values.c (vr_values::extract_range_from_phi_node):
Handle symbolic ranges conservatively when trying to drop
to Inf +- 1.

* gcc.dg/pr88427.c: New testcase.

Added:
trunk/gcc/testsuite/gcc.dg/pr88427.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/testsuite/ChangeLog
trunk/gcc/vr-values.c

[Bug tree-optimization/85762] [8/9 Regression] range-v3 abstraction overhead not optimized away

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
Martin, could you please have a look?

[Bug sanitizer/85777] [7/8/9 Regression] -fsanitize=undefined makes a -Wmaybe-uninitialized warning disappear

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
The expectations that sanitization doesn't change generated warnings is a wrong
one, the runtime instrumentation affects the code generation so much that
necessarily some further warnings will be emitted and others omitted.
If you care about warnings as well as sanitization, I'd suggest separate builds
for warnings and for sanitization, the latter perhaps with -w.

[Bug ipa/80726] [7/8/9 Regression] Destructor not inlined anymore (regression)

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Honza, have you managed to look at this?

[Bug ipa/87955] [9 Regression] ICE in cl_target_option_print_diff at gcc/options-save.c:3803 since r265920

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 CC||jakub at gcc dot gnu.org
 Resolution|--- |FIXED

--- Comment #7 from Jakub Jelinek  ---
Should be fixed now.

[Bug ipa/87955] [9 Regression] ICE in cl_target_option_print_diff at gcc/options-save.c:3803 since r265920

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek  ---
Author: jakub
Date: Mon Dec 10 13:30:49 2018
New Revision: 266954

URL: https://gcc.gnu.org/viewcvs?rev=266954&root=gcc&view=rev
Log:
PR ipa/87955
* gcc.target/i386/pr87955.c: Add -msse2 -mfpmath=sse to dg-options.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.target/i386/pr87955.c

[Bug ipa/87957] [9 Regression] ICE tree check: expected tree that contains ‘decl minimal’ structure, have ‘identifier_node’ in warn_odr, at ipa-devirt.c:1051 since r265519

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #14 from Jakub Jelinek  ---
That would be the
 gcc_checking_assert (TREE_TYPE (name) == t);
assert then.  So, what is TREE_TYPE (name) and what is t when this happens?

[Bug c/88430] New: -Wmissing-attributes warnings when including libquadmath headers

[jb at gcc dot gnu.org]

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

Bug ID: 88430
   Summary: -Wmissing-attributes warnings when including
libquadmath headers
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jb at gcc dot gnu.org
  Target Milestone: ---

When building libgfortran trunk one nowadays (within the past month or two,
maybe?) gets lots of warnings like below:


In file included from ../../../../trunk/libgfortran/libgfortran.h:61,
 from ../../../../trunk/libgfortran/ieee/ieee_helper.c:26:

../../../../trunk/libgfortran/../libquadmath/quadmath_weak.h:36:33: warning:
‘__qmath_crealq’ specifies less restrictive attribute than its target ‘crealq’:
‘nothrow’ [-Wmissing-attributes]

   36 | #define __qmath3(name) __qmath2(__qmath_ ## name,name,name)
  | ^~~~

../../../../trunk/libgfortran/../libquadmath/quadmath_weak.h:28:25: note: in
definition of macro ‘__qmath2’

   28 |   static __typeof(type) name __attribute__ ((__weakref__(#name2)));
  | ^~~~

../../../../trunk/libgfortran/../libquadmath/quadmath_weak.h:113:1: note: in
expansion of macro ‘__qmath3’

  113 | __qmath3 (crealq)
  | ^~~~



According to 'git blame', there has been no recent changes to the quadmath
header files recently, thus I suspect the implementation of
-Wmissing-attributes is to blame.

Though since libquadmath lives in-tree, a feasible solution would be to fix the
quadmath headers, if the missing attribute warning otherwise works as intended?
Please reassign to libquadmath if so.

See thread starting at https://gcc.gnu.org/ml/fortran/2018-12/msg00055.html

[Bug testsuite/88290] [9 regression] 23_containers/deque/erasure.cc fails after r266672

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Wasn't this already fixed in r266673 ?

[Bug bootstrap/65725] Bootstrap errors on Solaris 10 x86-64, including object diffs

[ro at CeBiTec dot Uni-Bielefeld.DE]

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

--- Comment #7 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #6 from Rainer Orth  ---
[...]
>> > 2. stage2 vs. stage3 diffs
[...]
> When trying a mainline bootstrap, I've run into quite a number of issues
> (libcc1 and ada not building), but once I've worked around those, I could
> bootstrap on amd64-pc-solaris2.11 (admittedly) with as/ld without comparison
> failures.  This was without --with-pic, which I'll try next.

That bootstrap (amd64-pc-solaris2.10 with as/ld, --disable-shared
--with-pic) has now completed as well: in addition to libcc1 (PR
other/66955) and ada (cf. PR ada/88429), I also had to disable go
because it uses sendfile without explicitly linking with -lsendfile (in
the shared case, this works because libgo is linked with libsendfile).

Anyway, the bootstrap has now finished successfully and make check is
running: no comparison failures at all.  So unless there's additional
information how to reproduce this, I'll close the PR as WORKSFORME.

[Bug ipa/88214] ICE in bitmap_intersect_p() on 32-bit BE platforms

[jamborm at gcc dot gnu.org]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #9 from Martin Jambor  ---
Fixed.

[Bug go/56431] -lpthread should be added to -lgo

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org

--- Comment #7 from Rainer Orth  ---
I'm seeing the same link error on Linux/x86_64 on mainline when configured with
--disable-shared:

/vol/gcc/bin/gld-2.31:
/var/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/./gcc/libgcc.a(generic-morestack.o):
in function `__morestack_block_signals':
/vol/gcc/src/hg/trunk/local/libgcc/generic-morestack.c:661: undefined reference
to `pthread_sigmask'

linking e.g. test2json.

[Bug other/66955] Bootstrap error: libcc1 compiled as shared library despite --disable-shared

[ro at gcc dot gnu.org]

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

Rainer Orth  changed:

   What|Removed |Added

 Target|x86_64-unknown-linux-gnu|x86_64-unknown-linux-gnu,
   ||i?86-pc-solaris2.11,
   ||amd64-pc-solaris2.11
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2018-12-10
  Component|libgcc  |other
 CC||aoliva at gcc dot gnu.org,
   ||ro at gcc dot gnu.org
   Host|x86_64-unknown-linux-gnu|
 Ever confirmed|0   |1
  Build|x86_64-unknown-linux-gnu|

--- Comment #4 from Rainer Orth  ---
Confirmed on all of Linux/x86_64 and Solaris/x86.  Recategorizing: libcc1 has
nothing to do with libgcc.  There's no category for it and the MAINTAINERS file
lists none.

[Bug ipa/88214] ICE in bitmap_intersect_p() on 32-bit BE platforms

[jamborm at gcc dot gnu.org]

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

--- Comment #8 from Martin Jambor  ---
Author: jamborm
Date: Mon Dec 10 12:45:47 2018
New Revision: 266953

URL: https://gcc.gnu.org/viewcvs?rev=266953&root=gcc&view=rev
Log:
[PR 88214] Check that an argument is a pointer

2018-12-10  Martin Jambor  

PR ipa/88214
* ipa-prop.c (determine_locally_known_aggregate_parts): Make sure
we check pointers against pointers.

testsuite/
* gcc.dg/ipa/pr88214.c: New test.


Added:
trunk/gcc/testsuite/gcc.dg/ipa/pr88214.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/ipa-prop.c
trunk/gcc/testsuite/ChangeLog

[Bug testsuite/88369] [9 regression] g++.dg/vect/pr33426-ivdep.cc etc. FAIL

[jakub at gcc dot gnu.org]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #4 from Jakub Jelinek  ---
Hopefully fixed.

[Bug testsuite/88369] [9 regression] g++.dg/vect/pr33426-ivdep.cc etc. FAIL

[jakub at gcc dot gnu.org]

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

--- Comment #3 from Jakub Jelinek  ---
Author: jakub
Date: Mon Dec 10 12:42:05 2018
New Revision: 266952

URL: https://gcc.gnu.org/viewcvs?rev=266952&root=gcc&view=rev
Log:
PR testsuite/88369
* gcc.dg/vect/vect-ivdep-1.c: Prune versioning for alignment messages.
* gcc.dg/vect/vect-ivdep-2.c: Likewise.
* gcc.dg/vect/nodump-vect-opt-info-1.c: Likewise.
* g++.dg/vect/pr33426-ivdep.cc: Likewise.
* g++.dg/vect/pr33426-ivdep-2.cc: Likewise. 
* g++.dg/vect/pr33426-ivdep-3.cc: Likewise.
* g++.dg/vect/pr33426-ivdep-4.cc: Likewise.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/g++.dg/vect/pr33426-ivdep-2.cc
trunk/gcc/testsuite/g++.dg/vect/pr33426-ivdep-3.cc
trunk/gcc/testsuite/g++.dg/vect/pr33426-ivdep-4.cc
trunk/gcc/testsuite/g++.dg/vect/pr33426-ivdep.cc
trunk/gcc/testsuite/gcc.dg/vect/nodump-vect-opt-info-1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-ivdep-1.c
trunk/gcc/testsuite/gcc.dg/vect/vect-ivdep-2.c

[Bug ada/88429] New: Ada bootstrap fails with --disable-shared

[ro at gcc dot gnu.org]

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

Bug ID: 88429
   Summary: Ada bootstrap fails with --disable-shared
   Product: gcc
   Version: 9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
  Target Milestone: ---
Target: amd64-pc-solaris2.11, x86_64-pc-linux-gnu

Prompted by PR bootstrap/65725 (a Solaris bootstrap failure with
--disable-shared),
I tried both Solaris/amd64 and Linux/x86_64 bootstraps with --disable-shared:
both fail in the same way:

cp -p /vol/gcc/src/hg/trunk/local/gcc/tsystem.h rts_32
rm -f ../stamp-gnatlib-rts_32
touch ../stamp-gnatlib1-rts_32
rm -f rts_32/s-oscons-tmplt.i rts_32/s-oscons-tmplt.s
(cd rts_32 ; \
/var/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/./gcc/xgcc
-B/var/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/./gcc/
-B/vol/gcc/x86_64-pc-linux-gnu/bin/ -B/vol/gcc/x86_64-pc-linux-gnu/lib/
-isystem /vol/gcc/x86_64-pc-linux-gnu/include -isystem
/vol/gcc/x86_64-pc-linux-gnu/sys-include   -fchecking=1 -W -Wall -g -O2 -g -O2
-fexceptions -DIN_RTS -DHAVE_GETIPINFO  -m32 -E -C
-DTARGET=\"x86_64-pc-linux-gnu\" -iquote /vol/gcc/src/hg/trunk/local/gcc/ada
/vol/gcc/src/hg/trunk/local/gcc/ada/s-oscons-tmplt.c > s-oscons-tmplt.i ; \
/var/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/./gcc/xgcc
-B/var/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/./gcc/
-B/vol/gcc/x86_64-pc-linux-gnu/bin/ -B/vol/gcc/x86_64-pc-linux-gnu/lib/
-isystem /vol/gcc/x86_64-pc-linux-gnu/include -isystem
/vol/gcc/x86_64-pc-linux-gnu/sys-include   -fchecking=1 -W -Wall -g -O2 -g -O2
-fexceptions -DIN_RTS -DHAVE_GETIPINFO  -m32 -S s-oscons-tmplt.i ; \
../bldtools/oscons/xoscons s-oscons)
/bin/bash: line 0: cd: rts_32: Not a directory

Unlike the default (--enable-shared) case, it seems that the rts directory for
the non-default multilib is created incorrectly: with --enable-shared, I see

make THREAD_KIND=native setup-rts
make[9]: Entering directory
'/var/scratch/gcc/regression/trunk/4.17.3-gcc-gas-gld/build/gcc/ada'
rm -rf rts_32
mkdir -p rts_32
chmod u+w rts_32

while with --disable-shared, I get the creation of rts twice.

This may be related to libada/configure.ac referencing a gnatlib-plain
target for --disable-shared, which I couldn't find elsewhere.

[Bug tree-optimization/88415] [7/8 Regression] ICE: verify_gimple failed (error: dead STMT in EH table)

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

  Known to work||9.0
Summary|[7/8/9 Regression] ICE: |[7/8 Regression] ICE:
   |verify_gimple failed|verify_gimple failed
   |(error: dead STMT in EH |(error: dead STMT in EH
   |table)  |table)

--- Comment #3 from Richard Biener  ---
Fixed on trunk sofar.