[Bug debug/93865] New: .debug_line with LTO refers to bogus file-names

[rguenth at gcc dot gnu.org]

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

Bug ID: 93865
   Summary: .debug_line with LTO refers to bogus file-names
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

Consider

.../t.c
.../tmp/t.c
.../a/

within the respective directories containing t.c do

gcc -c t.c -g -flto

then inside a/ do

gcc ../t.o ../tmp/t.o -g -flto

when you inspect a.out you'll see

 <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
   DW_AT_producer: (indirect string, offset: 0x1e4): GNU 
GIMPLE 9.2.0 -mtune=generic -march=x86-64 -g -fno-openmp -fno-openacc
-fno-pie -fltrans
   DW_AT_language: 12   (ANSI C99)
   DW_AT_name: (indirect string, offset: 0x1d0):

   DW_AT_comp_dir: (indirect string, offset: 0x1dd): /tmp/a
...
   DW_AT_stmt_list   : 0xe9

  Offset:  0xe9
...
 The Directory Table is empty.

 The File Name Table (offset 0x105):
  Entry Dir TimeSizeName
  1 0   0   0   t.c

so .debug_line lost the fact that we have two distinct t.c files and the
debugger has no way of actually finding it since we point it at /tmp/a

[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping

[pinskia at gcc dot gnu.org]

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

--- Comment #21 from Andrew Pinski  ---
(In reply to Oleg Endo from comment #20)
> (In reply to Andrew Pinski from comment #19)
> > t = (const uintptr_t *)(e - (4 -1));
> > 
> > is problemantic though.  e is not known to be aligned to uintptr_t.
> 
> That's right.  But it makes me wonder, why this has been discovered only on
> SH with, seemingly caused by fcross-jumping optimization option.  There are
> other more popular strict-alignment targets like ARM ... something is
> smelly, I think.

I think it is more by accident.strict-alginment here should not make a
difference really as it is undefined even on non-strict targets. 
fcross-jumping in this case causes the BB that contains __builtin_unreachable
to go to an invalid basic-block which is valid optimization which just happens
on sh and for some reason not arm or other targets.  I have not looked into the
code or even the RTL to double check this theory though.

[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping

[olegendo at gcc dot gnu.org]

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

--- Comment #20 from Oleg Endo  ---
(In reply to Andrew Pinski from comment #19)
> t = (const uintptr_t *)(e - (4 -1));
> 
> is problemantic though.  e is not known to be aligned to uintptr_t.

That's right.  But it makes me wonder, why this has been discovered only on SH
with, seemingly caused by fcross-jumping optimization option.  There are other
more popular strict-alignment targets like ARM ... something is smelly, I
think.

[Bug c/87488] hyperlink filenames in diagnostics

[msl0000023508 at gmail dot com]

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

--- Comment #24 from WHR  ---
Looks like commit r10-6643-g458c8d6459c4005fc9886b6e25d168a6535ac415 is a well
fix, and my terminal is no longer nosiy running GCC 10.

I have a suggestion, consider check for a few more 'TERM' types that would
certainly broken (emitting garbage and/or unwanted bell) with URL escape
sequences:
vt100
sun-color
xfce

'TERM=sun-color' is the type of Solaris local console, and it breaks on URL
sequences.
Some terminals with 'TERM=vt100' break however I don't have a real VT-100 to
test.
'TERM=xfce' would be a very uncommon configuration, but it is supported by
ncurses.

[Bug translation/93861] typo in warning: %qs is not valid for %

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic, easyhack
 CC||egallager at gcc dot gnu.org
   Severity|normal  |trivial

[Bug target/93860] darwin: wrong quotation in diagnostic #pragma options align=reset

[egallager at gcc dot gnu.org]

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

Eric Gallager  changed:

   What|Removed |Added

   Keywords||diagnostic, easyhack
 CC||egallager at gcc dot gnu.org,
   ||iains at gcc dot gnu.org
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=50909
   Severity|normal  |trivial

--- Comment #1 from Eric Gallager  ---
The code in that area probably needs to be reworked anyways; see bug 50909

[Bug tree-optimization/25290] PHI-OPT could be rewritten so that is uses match

[pinskia at gcc dot gnu.org]

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

--- Comment #15 from Andrew Pinski  ---
(In reply to rguent...@suse.de from comment #13)
> On February 21, 2018 2:13:22 PM GMT+01:00, "egallager at gcc dot gnu.org"
>  wrote:
> >https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25290
> >
> >Eric Gallager  changed:
> >
> >   What|Removed |Added
> >
> >   Keywords||patch
> >   CC||egallager at gcc dot gnu.org
> >
> >--- Comment #11 from Eric Gallager  ---
> >(In reply to Andrew Pinski from comment #10)
> >> Note this needs at least:
> >> https://gcc.gnu.org/ml/gcc-patches/2016-11/msg02837.html
> >> 
> >
> >This was approved; has it been committed yet?
> 
> 
> AFAIK no

Just for refernce, the above patch (which does not fix this bug but was needed
as GCC would crash without it) was committed as revision r242970 (or
g:28ea3e977ce07c1d0ad14c188336419288fce8d1 ).

[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[ch3root at openwall dot com]

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

--- Comment #16 from Alexander Cherepanov  ---
On 21/02/2020 03.40, vincent-gcc at vinc17 dot net wrote:
> Concerning -fno-signed-zeros, your code has undefined behavior since the sign
> of zero is significant in "1 / x == 1 / 0.", i.e. changing the sign of 0
> changes the result. If you use this option, you are telling GCC that this
> cannot be the case. Thus IMHO, this is not a bug.

If I understand correctly what you are saying, then one cannot even do
`printf("%f", 0);` because changing the sign of 0 will add a minus in front of
0. This seems kinda restrictive.

> I would say that -fno-trapping-math should have no effect because there are no
> traps by default (for floating point).

With -fno-trapping-math gcc simplifies `1 / x == 1 / 0.` into `1 / x >
1.79769313486231570814527423731704356798070567525844996599e+308`.

[Bug target/53386] Bad assembly code produced for m68000

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Status|SUSPENDED   |RESOLVED
 Resolution|--- |INVALID

--- Comment #15 from Jeffrey A. Law  ---
Nothing we can do without a testcase.

[Bug c++/93589] Template instantiation creates a conversion warning when it should not

[jrdowning at yahoo dot com]

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

--- Comment #9 from John Downing  ---
(In reply to Jason Merrill from comment #7)

> Rather, it was suppressed for the simple case where the RHS has a suitable
> type.  As Jonathan says, (CHAR_BIT * static_cast(i)) has type int (it
> would be unsigned without the cast).  And then the << expression has type
> int.  And then the | expression has type int.
> 
> Before the patch for 40752, we would warn based just on the type of the |
> expression.  Now we also look at the type of the << expression, see that it
> is also int, and warn.  You can avoid the warning by breaking up the
> expression more:
> 
> #define CHAR_BIT 8
> void print_byte_order( short )
> {
>short val = 0;
>unsigned i = 1;
>short pat1 = (CHAR_BIT * static_cast(i));
>short pat2 = pat1 << (CHAR_BIT * static_cast(i));
>val |= pat2;
> }
> 
> or adding another cast as in comment #1.

The code I posted has two casts, as in comment #1.  When I compile code like
this:

#define CHAR_BIT 8

void print_byte_order_short( short )
{
   short val = 0;
   unsigned int i =1;

   for(i = 1; i < sizeof(short); ++i)
   {
  short part1 =  (CHAR_BIT * static_cast(i));
  short part2 = part1 << CHAR_BIT * static_cast(i);
  val |= part2;
   }
   cout << val;
}

I get this warning:

example2.cpp: In function void print_byte_order_short(short int):
example2.cpp:15:32: warning: conversion from int to short int may change value
[-Wconversion]
   short part1 =  (CHAR_BIT * static_cast(i));
  ~~^~~~
example2.cpp:16:27: warning: conversion from int to short int may change value
[-Wconversion]
   short part2 = part1 << CHAR_BIT * static_cast(i);
 ~~^~~

Which seems like the same "design decision" I referenced in comment #8.

[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[vincent-gcc at vinc17 dot net]

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

--- Comment #15 from Vincent Lefèvre  ---
Note that there are very few ways to be able to distinguish the sign of zero.
The main one is division by zero. Other ones are:

* Conversion to a character string, e.g. via printf(). But in this case, if
-fno-signed-zeros is used, whether "0" or "-0" is output (even in a way that
seems to be inconsistent) doesn't matter since the user does not care about the
sign of 0, i.e. "0" and "-0" are regarded as equivalent (IIRC, this would be a
bit like NaN, which has a sign bit in IEEE 754, but the output does not need to
match its sign bit).

* Memory analysis. Again, the sign does not matter, but for instance, reading
an object twice as a byte sequence while the object has not been changed by the
code must give the same result. I doubt that this is affected by optimization.

* copysign(). The C standard is clear: "On implementations that represent a
signed zero but do not treat negative zero consistently in arithmetic
operations, the copysign functions regard the sign of zero as positive." Thus
with -fno-signed-zeros, the sign of zero must be regarded as positive with this
function. If GCC chooses to deviate from the standard here, this needs to be
documented.

[Bug c++/93589] Template instantiation creates a conversion warning when it should not

[jrdowning at yahoo dot com]

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

--- Comment #8 from John Downing  ---

> (In reply to John Downing from comment #5)
> > This will generate a warning, for the char and short cases, when the "|="
> > happens.  This is despite "val" being explicitly declared as a char or an
> > short.
> 
> It's not *despite* being declared as char or short, it's *because* they are
> declare as char and short.

This means that the "|=" operator or the "<<" operator changes the RHS side to
an int?  While that is within the guidelines of the cpp standard, the standard
as referenced in this thread says "can" change type, not "must".  So then why
does this change happen?

>  
> > I can see this being correct if "val" has been declared as "unsigned", which
> > i shorthand for "unsigned int".  But if "val" is explicitly declared as
> > something, there should be a potential for the conversion to change the
> > value.
> 
> That's not true. Given:

You are right, that's my opps - I meant to say "there should *no* potential".

> 
>   val |= (CHAR_BIT * static_cast(i)) << (CHAR_BIT *
> static_cast(i));
> 
> The type of (CHAR_BIT * static_cast(i)) is int, due to:
> https://en.cppreference.com/w/cpp/language/
> implicit_conversion#Integral_promotion

It is this the reference which uses "can" not "must".

> 
> And the type of the entire right-hand side is int, so you are doing val |=
> int(some_value) which the compiler correctly says might not fit in a short
> or char. In this specific case, your loop conditions mean that the value of
> the right hand side will fit, but the warning doesn't know about the values,
> it only cares that conversion from int to short int involves a potentially
> lossy conversion.

Yes, and with the standard using the word "can" to change the RHS to an int, it
is a "design decision".

[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[bugdal at aerifal dot cx]

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

--- Comment #14 from Rich Felker  ---
Indeed, without Anenx F, division by zero is UB, so it's fine to do anything if
the program performs division by zero. So we need examples without division by
zero.

[Bug analyzer/93863] internal compiler error: unhandled tree code in region_model::get_lvalue_1: ‘integer_cst’

[dmalcolm at gcc dot gnu.org]

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

--- Comment #1 from David Malcolm  ---
What version of gcc was this with?  This ought to have been fixed by
r10-6667-gf76a88ebf089871dcce215aa0cb1956ccc060895 (for PR analyzer/93388).

[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[vincent-gcc at vinc17 dot net]

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

--- Comment #13 from Vincent Lefèvre  ---
(In reply to Rich Felker from comment #12)
> To me the meaning of internal consistency is very clear: that the semantics
> of the C language specification are honored and that the only valid
> transformations are those that follow the "as-if rule".

which is not clear...

> Since C without Annex F allows arbitrarily awful floating point results,

In C without Annex F, division by 0 is undefined behavior (really undefined
behavior, not an unspecified result, which would be very different).

With the examples using divisions by 0, you need to assume that Annex F
applies, but at the same time, with your interpretation, -fno-signed-zeros
breaks Annex F in some cases, e.g. if you have floating-point divisions by 0.
So I don't follow you...

[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[bugdal at aerifal dot cx]

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

--- Comment #12 from Rich Felker  ---
To me the meaning of internal consistency is very clear: that the semantics of
the C language specification are honored and that the only valid
transformations are those that follow the "as-if rule". Since C without Annex F
allows arbitrarily awful floating point results, your example in comment 11 is
fine. Each instance of 1/a can evaluate to a different value. They could even
evaluate to random values. However, if you had written:

  int b = 1/a == 1/0.;
  int c = b;
  return b == c;

then the function must necessarily return 1, because the single instance of
1/a==1/0. in the abstract machine has a single value, either 0 or 1, and in the
abstract machine that value is stored to b, then copied to c, and b and c
necessarily have the same value. While I don't think it's likely that GCC would
mess up this specific example, it seems that it currently _can_ make
transformations such that a more elaborate version of the same idea would be
broken.

[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[vincent-gcc at vinc17 dot net]

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

--- Comment #11 from Vincent Lefèvre  ---
(In reply to Rich Felker from comment #10)
> I don't think it's at all clear that -fno-signed-zeros is supposed to mean
> the programmer is promising that their code has behavior independent of the
> sign of zeros, and that any construct which would be influenced by the sign
> of a zero has undefined behavior. I've always read it as a license to
> optimize in ways that disregard the sign of a zero or change the sign of a
> zero, but with internal consistency of the program preserved.

But what does "internal consistency" mean? IMHO, if you choose a strict, safe
meaning, then the optimization option is likely to have no effect in practice.

An example:

int foo (double a)
{
  double b, c;
  b = 1 / a;
  c = 1 / a;
  return b == -c;
}

If a is a zero, would you regard a result 1 as correct? Some users may regard
this as inconsistent, since even though they do not care about the sign of zero
when computing a value, they may assume that the sign of a will not change
magically.

[Bug target/81594] Optimize PowerPC vector set and store

[meissner at gcc dot gnu.org]

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

--- Comment #3 from Michael Meissner  ---
I looked at this a little.  The proposed patch doesn't generate the expected
code any more (due to setting the length attribute, which makes it look like
the fix generates slower code).

I re-implemented it as a peephole2 for ISA 2.07 (power9) and above.  The
peephole2 does find several places in the 2017 Spec INT benchmarks, where it
replaces:

MTVSRDD
XXPERMDI
STV

with:

STD
STD

[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[bugdal at aerifal dot cx]

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

--- Comment #10 from Rich Felker  ---
I don't think it's at all clear that -fno-signed-zeros is supposed to mean the
programmer is promising that their code has behavior independent of the sign of
zeros, and that any construct which would be influenced by the sign of a zero
has undefined behavior. I've always read it as a license to optimize in ways
that disregard the sign of a zero or change the sign of a zero, but with
internal consistency of the program preserved.

If -fno-signed-zeros is really supposed to be an option that vastly expands the
scope of what's undefined behavior, rather than just removing part of Annex F
and allowing the unspecified quality of floating point results that C otherwise
allows in the absence of Annex F, it really needs a much much bigger warning in
its documentation!

[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[vincent-gcc at vinc17 dot net]

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

--- Comment #9 from Vincent Lefèvre  ---
(In reply to Alexander Cherepanov from comment #8)
> A similar problem happens with -fno-signed-zeros -fno-trapping-math. Not
> sure if a separate PR should be filed...

Concerning -fno-signed-zeros, your code has undefined behavior since the sign
of zero is significant in "1 / x == 1 / 0.", i.e. changing the sign of 0
changes the result. If you use this option, you are telling GCC that this
cannot be the case. Thus IMHO, this is not a bug.

I would say that -fno-trapping-math should have no effect because there are no
traps by default (for floating point). But since your code has undefined
behavior, this is not necessarily surprising.

[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping

[pinskia at gcc dot gnu.org]

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

--- Comment #19 from Andrew Pinski  ---
t = (const uintptr_t *)(e - (4 -1));

is problemantic though.  e is not known to be aligned to uintptr_t.

[Bug c++/93862] [10 Regression] ICE on static_cast of rvalue-reference-to-array of unknown bound [P0338] to its known static bound

[mpolacek at gcc dot gnu.org]

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

--- Comment #2 from Marek Polacek  ---
In build_static_cast_1:
 7397   tree lref = cp_build_reference_type (TREE_TYPE (type), false);
 7398   result = (perform_direct_initialization_if_possible
 7399 (lref, expr, c_cast_p, complain));
 7400   result = build1 (NON_LVALUE_EXPR, type, result);
result is NULL_TREE so we create a bogus NON_LVALUE_EXPR<>.  Need to figure out
why perform_direct_initialization_if_possible returns a null tree.

clang++ trunk crashes on this code too.

[Bug c++/93862] [10 Regression] ICE on static_cast of rvalue-reference-to-array of unknown bound [P0338] to its known static bound

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-21
 CC||mpolacek at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |mpolacek at gcc dot 
gnu.org
   Target Milestone|--- |10.0
Summary|ICE on static_cast of   |[10 Regression] ICE on
   |rvalue-reference-to-array   |static_cast of
   |of unknown bound [P0338] to |rvalue-reference-to-array
   |its known static bound  |of unknown bound [P0338] to
   ||its known static bound
 Ever confirmed|0   |1

--- Comment #1 from Marek Polacek  ---
Thanks for the report Will.  As expected, started with

commit 89e0a492af5bec8ffa2ec5d99c4858df50d22c16
Author: Marek Polacek 
Date:   Wed Oct 9 20:58:00 2019 +

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

and so mine.

[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping

[olegendo at gcc dot gnu.org]

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

--- Comment #18 from Oleg Endo  ---
(In reply to Andrew Pinski from comment #17)
> In the original code we have:
>  if ((uintptr_t)p % 4) {
>  int l = 4 - (uintptr_t)p % 4;
>  p += l;
>  switch (l) {
> 
> l range should be 0...3


Ha!  This code is an autostereogram.  You gotta stare at it until something
comes out of it (or falls in) ...

  if (0 || e - p >= 4)
  {
if ((uintptr_t)p % 4)
{
  // when here, p % 4 is never zero.

  // thus, l = 4 - {3|2|1}
  int l = 4 - (uintptr_t)p % 4;

However, that's not where it crashes.  It's in the second switch statement.  I
assume that's because it's never supposed to get there, but it does.

What the code does is trying to walk an array of bytes in 4-byte steps.  For
that it potentially steps 0...3 bytes to get a 4-byte aligned pointer 'p', then
does the 4-byte steps in the for loop, then does  the remaining 0...3 bytes
after the loop.

Perhaps this line

p = (const char *)s;

somehow results in wrong code with p not being updated correctly, and then (e -
p) is not in the range {3|2|1|0} as the code expects.

[Bug translation/93864] New: typo: paramter

[roland.illig at gmx dot de]

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

Bug ID: 93864
   Summary: typo: paramter
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

This is a popular typo that occurs 13 times in the GCC tree. Most of them are
in comments, but one is in intrinsic.texi.

[Bug analyzer/93863] New: internal compiler error: unhandled tree code in region_model::get_lvalue_1: ‘integer_cst’

[cstratak at redhat dot com]

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

Bug ID: 93863
   Summary: internal compiler error: unhandled tree code in
region_model::get_lvalue_1: ‘integer_cst’
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: cstratak at redhat dot com
  Target Milestone: ---

After bug 93520 got fixed I retried the -fanalyzer flag with the CPython
sources from the master branch.

Getting a different error this time after the compilation has progressed a bit:


gcc -pthread -c -Wno-unused-result -Wsign-compare -DNDEBUG -g -fwrapv -O3 -Wall
 -fanalyzer  -std=c99 -Wextra -Wno-unused-result -Wno-unused-parameter
-Wno-missing-field-initializers -Werror=implicit-function-declaration
-fvisibility=hidden  -I./Include/internal  -I. -I./Include-DPy_BUILD_CORE
-o Python/getargs.o Python/getargs.c
during IPA pass: analyzer
Python/getargs.c:2196:31: internal compiler error: unhandled tree code in
region_model::get_lvalue_1: ‘integer_cst’
 2196 | current_arg = find_keyword(kwnames, kwstack, keyword);
  |   ^~~
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
Preprocessed source stored into /tmp/ccIfmkb2.out file, please attach this to
your bugreport.
make: *** [Makefile:1718: Python/getargs.o] Error 1

[Bug c++/93862] New: ICE on static_cast of rvalue-reference-to-array of unknown bound [P0338] to its known static bound

[wjwray at gmail dot com]

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

Bug ID: 93862
   Summary: ICE on static_cast of rvalue-reference-to-array of
unknown bound [P0338] to its known static bound
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wjwray at gmail dot com
  Target Milestone: ---

https://wandbox.org/permlink/ZaGwU3l7WbEc91Hw

1st line below an rvalue array binds, with lifetime extension,
to an (rvalue-)reference-to-array of unknown bound (by P0388),
so decltype(intu_rvref) is int(&&)[]

2nd line attempts to static_cast to its correct static type,
as an lvalue-ref; this is rejected, it should be accepted.

3rd line attempts to static_cast to rvalue-ref of correct static 
at which point the compiler crashes (stack trace below):

int(&_rvref)[]{1,2,3,4};  // (1) OK since P0388

 // int(_lvref)[4] = static_cast(intu_rvref); // (2)
 // error: invalid 'static_cast' from type 'int []' to type 'int (&)[4]'

int(&_rvref)[4] = static_cast(intu_rvref); // (3) ICE


stack trace

prog.cc:6:58: internal compiler error: Segmentation fault
6 | int(&_rvref)[4] = static_cast(intu_rvref); // ICE
  |  ^
0xc173ef crash_signal
../../source/gcc/toplev.c:328
0xe583b4 tree_nop_conversion
../../source/gcc/tree.c:12663
0xe583b4 tree_nop_conversion
../../source/gcc/tree.c:12652
0xe583b4 tree_strip_nop_conversions(tree_node*)
../../source/gcc/tree.c:12694
0x63284e potential_constant_expression_1
../../source/gcc/cp/constexpr.c:7381
0x6337d2 potential_constant_expression_1(tree_node*, bool, bool, bool, int)
../../source/gcc/cp/constexpr.c:7981
0x6337d2 potential_constant_expression(tree_node*)
../../source/gcc/cp/constexpr.c:7990
0x6779ac cp_finish_decl(tree_node*, tree_node*, bool, tree_node*, int)
../../source/gcc/cp/decl.c:7550
0x6f96c0 cp_parser_init_declarator
../../source/gcc/cp/parser.c:20828
0x6dc7c0 cp_parser_simple_declaration
../../source/gcc/cp/parser.c:13678
0x701a82 cp_parser_declaration
../../source/gcc/cp/parser.c:13377
0x7021a4 cp_parser_translation_unit
../../source/gcc/cp/parser.c:4731
0x7021a4 c_parse_file()
../../source/gcc/cp/parser.c:43709
0x7c9aab c_common_parse_file()
../../source/gcc/c-family/c-opts.c:1186
Please submit a full bug report

[Bug translation/93861] New: typo in warning: %qs is not valid for %

[roland.illig at gmx dot de]

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

Bug ID: 93861
   Summary: typo in warning: %qs is not valid for
%
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From darwin-driver.c:
> warning (0, "%qs is not valid for %",

There should be a hyphen in front of the command line option.

For comparison, darwin-c.c has:
>  error ("unknown value %qs of %<-mmacosx-version-min%>",

[Bug fortran/93814] [9/10 Regression] ICE in build_entry_thunks, at fortran/trans-decl.c:2898

[kargl at gcc dot gnu.org]

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

--- Comment #3 from kargl at gcc dot gnu.org ---
Patch is against svn r280157.

Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c   (revision 280157)
+++ gcc/fortran/resolve.c   (working copy)
@@ -12230,9 +12230,26 @@ gfc_verify_binding_labels (gfc_symbol *sym)
   return;
 }

-  if ((sym->attr.function || sym->attr.subroutine)
-  && ((gsym->type != GSYM_SUBROUTINE && gsym->type != GSYM_FUNCTION)
-  || (gsym->defined && sym->attr.if_source != IFSRC_IFBODY))
+  if (sym->attr.function
+  && (gsym->type != GSYM_FUNCTION
+ || (gsym->defined && sym->attr.if_source != IFSRC_IFBODY))
+  && (sym != gsym->ns->proc_name)
+  && (module != gsym->mod_name
+ || strcmp (gsym->sym_name, sym->name) != 0
+ || (module && strcmp (module, gsym->mod_name) != 0)))
+{
+  /* Print an error if the procedure is defined multiple times; we have to
+exclude references to the same procedure via module association or
+multiple checks for the same procedure.  */
+  gfc_error ("Procedure %qs with binding label %qs at %L uses the same "
+"global identifier as entity at %L", sym->name,
+sym->binding_label, >declared_at, >where);
+  sym->binding_label = NULL;
+}
+
+  if (sym->attr.subroutine
+  && (gsym->type != GSYM_SUBROUTINE
+ || (gsym->defined && sym->attr.if_source != IFSRC_IFBODY))
   && (sym != gsym->ns->proc_name && sym->attr.entry == 0)
   && (module != gsym->mod_name
  || strcmp (gsym->sym_name, sym->name) != 0

[Bug target/93860] New: darwin: wrong quotation in diagnostic #pragma options align=reset

[roland.illig at gmx dot de]

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

Bug ID: 93860
   Summary: darwin: wrong quotation in diagnostic #pragma options
align=reset
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From darwin-c.c:
> error ("too many %<#pragma options%> align=reset");

The align=reset should be inside the quotes.

There should be tests that show example code and the corresponding diagnostic.
This would have made it more obvious that the %> comes too early in the
diagnostic.

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

[wjwray at gmail dot com]

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

--- Comment #4 from Will Wray  ---
Reduced code for deduction of element type
for reference-to-array https://godbolt.org/z/tpkKjN:

int f(auto()[1]);
int g(auto()[ ]);

int test_f = f("");
int test_g = g(""); // error: no match for call

and same for pointer-to-array https://godbolt.org/z/dL9bGP

int f(auto(*a)[1]);
int g(auto(*a)[ ]);

int test_f = f(&"");
int test_g = g(&""); // error: no match for call

So, in both cases, ptr and ref, gcc currently deduces element type
if the bound is known but not with unknown bound.

My reading of http://eel.is/c++draft/temp.deduct.call#4 suggests that
only deduced *pointer* type is candidate for qualification conversion
(which should now allow the new conversion to unknown bound), whereas
deduced & type can only be more cv qual'd than the source.

But then in [conv.qual] pointers and references are treated the same.

Any follow-up from CWG?

[Bug c++/90966] [9/10 Regression] ICE in tsubst_copy, at cp/pt.c:16155

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #7 from Marek Polacek  ---
Fixed for GCC 9.3 and 10.

[Bug fortran/93833] [8/9/10 Regression] ICE in trans_array_constructor, at fortran/trans-array.c:2566

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
It is not clear to me why ice-on-valid-code is set here.
The code is clearly invalid.  However, it should not
cause and ICE.

To be clear, in 'associate (y => [c])', c is referenced
but it has not been allocated.  Simply doing 

program p
   character(:), allocatable :: c
contains
   subroutine s
  c = 'steve'
  associate (y => [c])
 if (any(y /= [c])) stop
  end associate
   end
end

allows the code to compile and execute correctly.

[Bug tree-optimization/90883] Generated code is worse if returned struct is unnamed

[wilson at gcc dot gnu.org]

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

Jim Wilson  changed:

   What|Removed |Added

 CC||wilson at gcc dot gnu.org

--- Comment #29 from Jim Wilson  ---
The testcase works for riscv64-elf but does not work for riscv32-elf.  The
difference is in the einline pass before dse1.  riscv64-elf has
tmp.C:12:17: optimized:  Inlining constexpr C::C()/1 into C slow()/3.
where as riscv32-elf has
tmp.C:12:17: missed:   will not early inline: C slow()/3->constexpr
C::C()/1, call is cold and code would grow by 1

Since the constructor was not early inlined, dse1 can't eliminate the redundant
store.  The constructor eventually gets inlined between
085i.materialize-all-clones and 088t.fixup_cfg3 which allows dse2 to eliminate
the redundant store.

I can make the testcase work for riscv32-elf if I add
--param max-inline-insns-size=1
to allow the constructor to be inlined during the einline pass.  I didn't check
to see if this works for the other failing targets.

[Bug c++/90997] [9 Regression] ICE on a memset in a template in tsubst_copy_and_build, at cp/pt.c:18480

[mpolacek at gcc dot gnu.org]

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

Marek Polacek  changed:

   What|Removed |Added

 CC||mpolacek at gcc dot gnu.org
Summary|[9/10 Regression] ICE on a  |[9 Regression] ICE on a
   |memset in a template in |memset in a template in
   |tsubst_copy_and_build, at   |tsubst_copy_and_build, at
   |cp/pt.c:18480   |cp/pt.c:18480

--- Comment #4 from Marek Polacek  ---
Fixed on trunk so far.

[Bug c++/93801] False -Wmismatched-tags upon redundant typename

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Patch (https://gcc.gnu.org/ml/gcc-patches/2020-02/msg01070.html) committed.

[Bug c++/93801] False -Wmismatched-tags upon redundant typename

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:96cbc56ed96490c58a9800f3e7507758b6602777

commit r10-6768-g96cbc56ed96490c58a9800f3e7507758b6602777
Author: Martin Sebor 
Date:   Thu Feb 20 14:31:38 2020 -0700

PR c++/93801 - False -Wmismatched-tags upon redundant typename

gcc/cp/ChangeLog:

PR c++/93801
* parser.c (cp_parser_check_class_key): Only handle true C++
class-keys.

gcc/testsuite/ChangeLog:

PR c++/93801
* g++.dg/warn/Wredundant-tags-3.C: New test.

[Bug target/93828] [10 Regression] incorrect shufps instruction emitted for -march=k8

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #7 from Uroš Bizjak  ---
Fixed for gcc-8.4+.

[Bug target/93828] [10 Regression] incorrect shufps instruction emitted for -march=k8

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r8-10042-ge4a43b20c564aaca847ae74cc17ca0b48ce6d3ff
Author: Uros Bizjak 
Date:   Thu Feb 20 22:00:45 2020 +0100

i386: Fix *vec_extractv2sf_1 and *vec_extractv2sf_1 shufps alternative
[PR93828]

shufps moves two of the four packed single-precision floating-point values
from *destination* operand (first operand) into the low quadword of the
destination operand.  Match source operand to the destination.

PR target/93828
* config/i386/mmx.md (*vec_extractv2sf_1): Match source operand
to destination operand for shufps alternative.
(*vec_extractv2si_1): Ditto.

[Bug target/93828] [10 Regression] incorrect shufps instruction emitted for -march=k8

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r9-8260-gbd2537ed5d4cda1a896974f30bd62dfb68ae39b0
Author: Uros Bizjak 
Date:   Thu Feb 20 21:58:57 2020 +0100

i386: Fix *vec_extractv2sf_1 and *vec_extractv2sf_1 shufps alternative
[PR93828]

shufps moves two of the four packed single-precision floating-point values
from *destination* operand (first operand) into the low quadword of the
destination operand.  Match source operand to the destination.

PR target/93828
* config/i386/mmx.md (*vec_extractv2sf_1): Match source operand
to destination operand for shufps alternative.
(*vec_extractv2si_1): Ditto.

[Bug middle-end/93806] Wrong optimization: instability of floating-point results with -funsafe-math-optimizations leads to nonsense

[ch3root at openwall dot com]

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

--- Comment #8 from Alexander Cherepanov  ---
A similar problem happens with -fno-signed-zeros -fno-trapping-math. Not sure
if a separate PR should be filed...

--
#include 

__attribute__((noipa)) // imagine it in a separate TU
static double opaque(double d) { return d; }

int main()
{
int zero = opaque(0);

double x = opaque(-0.);
int a = 1 / x == 1 / 0.;

printf("zero = %d\n", zero);

opaque(a);
if (zero == a) {
opaque(0);
if (x == 0) {
opaque(0);
if (a) {
opaque(0);
if (zero == 1)
printf("zero = %d\n", zero);
}
}
}
}
--
$ gcc -std=c11 -pedantic -Wall -Wextra -fno-signed-zeros -fno-trapping-math -O3
test.c && ./a.out
zero = 0
zero = 1
--
gcc x86-64 version: gcc (GCC) 10.0.1 20200220 (experimental)
--

[Bug c/93859] New: missing test for diagnostic: the omitted middle operand will always be true

[roland.illig at gmx dot de]

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

Bug ID: 93859
   Summary: missing test for diagnostic: the omitted middle
operand will always be true
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From c-family.c:
> warning_at (location, OPT_Wparentheses,
> "the omitted middle operand in % will always be %, "
> "suggest explicit middle operand");

The test suite does not contain the words "the omitted middle operand". As the
German i18n translator I'd like to see example code that triggers this warning,
so that I can translate it properly.

[Bug c/93858] New: missing question mark in diagnostic: unknown option after #pragma GCC diagnostic

[roland.illig at gmx dot de]

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

Bug ID: 93858
   Summary: missing question mark in diagnostic: unknown option
after #pragma GCC diagnostic
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From c-pragma.c:
> warning_at (loc, OPT_Wpragmas,
> "unknown option after %<#pragma GCC diagnostic%> kind;"
> " did you mean %<-%s%>", hint);

The other "did you mean" diagnostics end with a question mark. Maybe this could
be added to the existing gcc-internal-format checks in c-format.c?

[Bug translation/93853] typo: writing one too many bytes

[roland.illig at gmx dot de]

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

--- Comment #3 from Roland Illig  ---
Thanks for the explanation.

Since there are many users of GCC who are not native English speakers, it might
make sense to avoid such complicated grammar. The GCC users should rather
concentrate on fixing their code instead of being distracted by wondering
whether the GCC authors know their English.

To prevent the i18n translators from writing bug reports like this, it might
make sense to add a /* TRANSLATORS: This is correct English grammar. */ above
the diagnostic. :)

[Bug translation/93855] typo: function argument vs. parameter

[roland.illig at gmx dot de]

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

--- Comment #4 from Roland Illig  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Roland Illig from comment #2)
> > While here, the comment style should be made the same in
> > attr-access-read-write.c and attr-access-read-only.c. Currently, one file
> > uses /* block comments */ while the other uses // line-end comments.
> 
> Why should they be made the same?  Yes it does make it easier to same thing
> to them both but who cares as this is the testsuite.

If the files use the same comment style, a word-wise diff will contain less
noise and makes it easier to compare the files. This is useful when you want to
cross-check whether the test cases are still the same for both cases.

[Bug target/93828] [10 Regression] incorrect shufps instruction emitted for -march=k8

[cvs-commit at gcc dot gnu.org]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r10-6766-gd56779b8ae587c599bf46b20587afcd6ee51fcaa
Author: Uros Bizjak 
Date:   Thu Feb 20 21:06:18 2020 +0100

i386: Fix *vec_extractv2sf_1 and *vec_extractv2sf_1 shufps alternative
[PR93828]

shufps moves two of the four packed single-precision floating-point values
from *destination* operand (first operand) into the low quadword of the
destination operand.  Match source operand to the destination.

PR target/93828
* config/i386/mmx.md (*vec_extractv2sf_1): Match source operand
to destination operand for shufps alternative.
(*vec_extractv2si_1): Ditto.

testsuite/ChangeLog:

PR target/93828
* g++.target/i386/pr93828.C: New test.

[Bug target/93828] [10 Regression] incorrect shufps instruction emitted for -march=k8

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r10-6765-gf6088573d81d52e8573b704984fdb515e4391b1a
Author: Uros Bizjak 
Date:   Thu Feb 20 21:04:44 2020 +0100

i386: Fix *vec_extractv2sf_1 and *vec_extractv2sf_1 shufps alternative
[PR93828]

shufps moves two of the four packed single-precision floating-point values
from *destination* operand (first operand) into the low quadword of the
destination operand.  Match source operand to the destination.

PR target/93828
* config/i386/mmx.md (*vec_extractv2sf_1): Match source operand
to destination operand for shufps alternative.
(*vec_extractv2si_1): Ditto.

testsuite/ChangeLog:

PR target/93828
* g++.target/i386/pr93828.C: New test.

[Bug c/93857] missing test for diagnostic: using integer constants in boolean context

[roland.illig at gmx dot de]

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

--- Comment #1 from Roland Illig  ---
I wrote a small example program, which I thought would trigger the diagnostic,
but it didn't do that in GCC 9.2.1.

int main(void) {
if (3 ? 4 : 5) {
return 1;
}
return 0;
}

gcc -Wall -Wextra -Wint-in-bool-context demo.c -O2

[Bug target/93828] [10 Regression] incorrect shufps instruction emitted for -march=k8

[ubizjak at gmail dot com]

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

Uroš Bizjak  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |ubizjak at gmail dot com

--- Comment #2 from Uroš Bizjak  ---
Created attachment 47880
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47880=edit
Patch in testing.

[Bug c/93857] New: missing test for diagnostic: using integer constants in boolean context

[roland.illig at gmx dot de]

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

Bug ID: 93857
   Summary: missing test for diagnostic: using integer constants
in boolean context
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From c-common.c:
> warning_at (EXPR_LOCATION (expr), OPT_Wint_in_bool_context,
> "% using integer constants in boolean context, "
> "the expression will always evaluate to %");

The text "using integer constants in boolean context" does not appear in the
test suite. As an i18n translator, I'd like to see example code for each
diagnostic, and having a test is a good way for that.

[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping

[pinskia at gcc dot gnu.org]

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

--- Comment #17 from Andrew Pinski  ---
In the original code we have:
 if ((uintptr_t)p % 4) {
 int l = 4 - (uintptr_t)p % 4;
 p += l;
 switch (l) {

l range should be 0...3

[Bug c/93856] New: missing test for diagnostic: attribute %qs invalid positional argument

[roland.illig at gmx dot de]

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

Bug ID: 93856
   Summary: missing test for diagnostic: attribute %qs invalid
positional argument
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From c-attribs.c:
> error ("attribute %qs invalid positional argument", attrstr);

This diagnostic is not covered by the test suite. Only its close relatives
"attribute %qs invalid positional argument %i" are covered.

[Bug translation/93855] typo: function argument vs. parameter

[pinskia at gcc dot gnu.org]

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Roland Illig from comment #2)
> While here, the comment style should be made the same in
> attr-access-read-write.c and attr-access-read-only.c. Currently, one file
> uses /* block comments */ while the other uses // line-end comments.

Why should they be made the same?  Yes it does make it easier to same thing to
them both but who cares as this is the testsuite.

[Bug translation/93855] typo: function argument vs. parameter

[roland.illig at gmx dot de]

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

--- Comment #2 from Roland Illig  ---
While here, the comment style should be made the same in
attr-access-read-write.c and attr-access-read-only.c. Currently, one file uses
/* block comments */ while the other uses // line-end comments.

[Bug translation/93855] typo: function argument vs. parameter

[roland.illig at gmx dot de]

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

--- Comment #1 from Roland Illig  ---
In addition, I had expected that the %i placeholder were 1-based. From
attr-access-read-only.c:
> int RDONLY (4)
> rdonly_i_i_i_4 (int, int, int);
>// { dg-error "attribute 'access\\(read_only, 4\\)'
>// positional argument 1 value 4 exceeds number of
>// function arguments 3" }

It's the second parameter's value that is too large here. That parameter should
not be called parameter 1.

[Bug fortran/93832] [8/9/10 Regression] ICE in gfc_convert_to_structure_constructor, at fortran/primary.c:3100

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
Patch is against svn r280157.

The 1st chuck suppress output of the error message if any
other error had previously been emitted.

The 2nd chuck is the actual fix for this PR.  gfortran
should not dereference a NULL pointer.

The 3rd chuck is a large whitespace cleanup.

The last bit adjusts a testcase that is effected by the
1st chunk.

Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c   (revision 280157)
+++ gcc/fortran/primary.c   (working copy)
@@ -2979,8 +2979,11 @@ build_actual_constructor (gfc_structure_ctor_component
}
  else if (!comp->attr.artificial)
{
- gfc_error ("No initializer for component %qs given in the"
-" structure constructor at %C", comp->name);
+ int ecnt;
+ gfc_get_errors (NULL, );
+ if (ecnt == 0)
+   gfc_error ("No initializer for component %qs given in the"
+  " structure constructor at %C", comp->name);
  return false;
}
}
@@ -3097,6 +3100,7 @@ gfc_convert_to_structure_constructor (gfc_expr *e, gfc
   if (this_comp->ts.type == BT_CHARACTER && !this_comp->attr.allocatable
  && this_comp->ts.u.cl && this_comp->ts.u.cl->length
  && this_comp->ts.u.cl->length->expr_type == EXPR_CONSTANT
+ && actual->expr
  && actual->expr->ts.type == BT_CHARACTER
  && actual->expr->expr_type == EXPR_CONSTANT)
{
@@ -3161,35 +3165,36 @@ gfc_convert_to_structure_constructor (gfc_expr *e, gfc
  goto cleanup;
}

-  /* If not explicitly a parent constructor, gather up the components
- and build one.  */
-  if (comp && comp == sym->components
-&& sym->attr.extension
-   && comp_tail->val
-&& (!gfc_bt_struct (comp_tail->val->ts.type)
-  ||
-comp_tail->val->ts.u.derived != this_comp->ts.u.derived))
-{
-  bool m;
- gfc_actual_arglist *arg_null = NULL;
+  /* If not explicitly a parent constructor, gather up the components
+and build one.  */
+  if (comp && comp == sym->components
+ && sym->attr.extension
+ && comp_tail->val
+ && (!gfc_bt_struct (comp_tail->val->ts.type)
+ || comp_tail->val->ts.u.derived != this_comp->ts.u.derived))
+   {
+ bool m;
+ gfc_actual_arglist *arg_null = NULL;

- actual->expr = comp_tail->val;
- comp_tail->val = NULL;
+ actual->expr = comp_tail->val;
+ comp_tail->val = NULL;

-  m = gfc_convert_to_structure_constructor (NULL,
-   comp->ts.u.derived, _tail->val,
-   comp->ts.u.derived->attr.zero_comp
- ? _null : , true);
-  if (!m)
-goto cleanup;
+#define shorter gfc_convert_to_structure_constructor
+ m = shorter (NULL, comp->ts.u.derived, _tail->val,
+  comp->ts.u.derived->attr.zero_comp
+  ? _null : , true);
+#undef shorter

- if (comp->ts.u.derived->attr.zero_comp)
-   {
- comp = comp->next;
- continue;
-   }
-}
+ if (!m)
+   goto cleanup;

+ if (comp->ts.u.derived->attr.zero_comp)
+   {
+ comp = comp->next;
+ continue;
+   }
+   }
+
   if (comp)
comp = comp->next;
   if (parent && !comp)
@@ -3239,7 +3244,8 @@ gfc_convert_to_structure_constructor (gfc_expr *e, gfc
 *arglist = actual;
   return true;

-  cleanup:
+cleanup:
+
   gfc_current_locus = old_locus;

   for (comp_iter = comp_head; comp_iter; )
Index: gcc/testsuite/gfortran.dg/structure_constructor_6.f03
===
--- gcc/testsuite/gfortran.dg/structure_constructor_6.f03   (revision
280157)
+++ gcc/testsuite/gfortran.dg/structure_constructor_6.f03   (working copy)
@@ -15,6 +15,5 @@ PROGRAM test
   TYPE(basics_t) :: basics

   basics = basics_t (i = 42) ! { dg-error "No initializer for component 'r'" }
-  basics = basics_t (42) ! { dg-error "No initializer for component 'r'" }

 END PROGRAM test

[Bug translation/93855] New: typo: function argument vs. parameter

[roland.illig at gmx dot de]

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

Bug ID: 93855
   Summary: typo: function argument vs. parameter
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From c-attribs.c:
> error ("attribute %qs positional argument %i value %wi exceeds "
>"number of function arguments %u",

The correct term is "parameter" instead of "argument". See ISO C11 6.5.2.2p2.

[Bug translation/93853] typo: writing one too many bytes

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
"writing one too many bytes"

This is one of the English rules that gets non-native speakers.  one is not the
modifier to byte but rather many is "one too many" is.  And many is more than
one.  Even "one or more bytes" is still uses the plural version of bytes.

[Bug translation/93853] typo: writing one too many bytes

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski  ---
No this is correct english.
It means one or more extra bytes were written.

[Bug libstdc++/93851] FAIL: 20_util/integer_comparisons/equal.cc execution test

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #1 from Jonathan Wakely  ---
Should be fixed at r10-6711 ce7b39d0fc694e5ec80520b7cc76f91a5476d7db

[Bug translation/93854] New: typo: defined here %qD

[roland.illig at gmx dot de]

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

Bug ID: 93854
   Summary: typo: defined here %qD
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From tree-vrp.c:
>   inform (DECL_SOURCE_LOCATION (rec), "defined here %qD", rec);

This should probably be "%qD was defined here".

[Bug translation/93853] New: typo: writing one too many bytes

[roland.illig at gmx dot de]

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

Bug ID: 93853
   Summary: typo: writing one too many bytes
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From tree-ssa-strlen.c:
> writing one too many bytes

The words "one bytes" don't match.

[Bug translation/93852] typo: def instead of definition

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski  ---
These are all diagonstic which normally don't go for normal compilation
including when user has provided invalid code.  These are all have an internal
error message after them.

[Bug translation/93852] typo: def instead of definition

[roland.illig at gmx dot de]

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

--- Comment #1 from Roland Illig  ---
>   error ("virtual def operand missing for statement");

Curiously, the diagnostic a few lines above this one uses the correct word
"definition".

[Bug translation/93852] New: typo: def instead of definition

[roland.illig at gmx dot de]

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

Bug ID: 93852
   Summary: typo: def instead of definition
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: translation
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

From tree-cfg.c:
> error ("missing % def");

The GCC diagnostics guidelines recomment to use actual words instead of
internal abbreviations.

[Bug tree-optimization/70020] Forward propagation leaves compile-time computable conditional in IL

[law at redhat dot com]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #2 from Jeffrey A. Law  ---
Appears to have been fixed a while ago.

[Bug libstdc++/93851] New: FAIL: 20_util/integer_comparisons/equal.cc execution test

[danglin at gcc dot gnu.org]

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

Bug ID: 93851
   Summary: FAIL: 20_util/integer_comparisons/equal.cc execution
test
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa2.0w-hp-hpux11.11
Target: hppa2.0w-hp-hpux11.11
 Build: hppa2.0w-hp-hpux11.11

spawn /test/gnu/gcc/objdir/./gcc/xg++ -shared-libgcc
-B/test/gnu/gcc/objdir/./gc
c -nostdinc++ -L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src
-L/t
est/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/.libs
-L/test/gnu/gcc/
objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/libsupc++/.libs
-B/opt/gnu/gcc/gcc-10/
hppa2.0w-hp-hpux11.11/bin/ -B/opt/gnu/gcc/gcc-10/hppa2.0w-hp-hpux11.11/lib/
-isy
stem /opt/gnu/gcc/gcc-10/hppa2.0w-hp-hpux11.11/include -isystem
/opt/gnu/gcc/gcc
-10/hppa2.0w-hp-hpux11.11/sys-include -fchecking=1
-B/test/gnu/gcc/objdir/hppa2.
0w-hp-hpux11.11/./libstdc++-v3/src/.libs -fmessage-length=0 -fno-show-column -g
-O2 -DLOCALEDIR="." -nostdinc++
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/lib
stdc++-v3/include/hppa2.0w-hp-hpux11.11
-I/test/gnu/gcc/objdir/hppa2.0w-hp-hpux1
1.11/libstdc++-v3/include -I/test/gnu/gcc/gcc/libstdc++-v3/libsupc++
-I/test/gnu
/gcc/gcc/libstdc++-v3/include/backward
-I/test/gnu/gcc/gcc/libstdc++-v3/testsuit
e/util
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/integer_comparisons/equa
l.cc -std=gnu++2a -fno-diagnostics-show-caret -fdiagnostics-color=never
./libtes
tc++.a
-L/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/libstdc++-v3/src/filesystem/
.libs -lm -o ./equal.exe
PASS: 20_util/integer_comparisons/equal.cc (test for excess errors)
Setting LD_LIBRARY_PATH to
:/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa2.
0w-hp-hpux11.11/./libstdc++-v3/../libatomic/.libs:/test/gnu/gcc/objdir/hppa2.0w-
hp-hpux11.11/./libstdc++-v3/../libgomp/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs::/test/gnu/gcc/objdir/gcc:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/../libatomic/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/../libgomp/.libs:/test/gnu/gcc/objdir/hppa2.0w-hp-hpux11.11/./libstdc++-v3/src/.libs
spawn [open ...]
/test/gnu/gcc/gcc/libstdc++-v3/testsuite/20_util/integer_comparisons/equal.cc:64:
void test03(): Assertion '!std::cmp_equal(u, ul)' failed.
FAIL: 20_util/integer_comparisons/equal.cc execution test
extra_tool_flags are:
 -std=gnu++2a

[Bug c/93850] 'stack smashing detected' in the special index for an array

[sch...@linux-m68k.org]

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

--- Comment #2 from Andreas Schwab  ---
*** Bug 93849 has been marked as a duplicate of this bug. ***

[Bug c/93849] 'Segmentation fault' in the special index for an array

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
.

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

[Bug c/93850] 'stack smashing detected' in the special index for an array

[sch...@linux-m68k.org]

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

Andreas Schwab  changed:

   What|Removed |Added

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

--- Comment #1 from Andreas Schwab  ---
Don't write beyond the bounds of the array, then.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Peter Bergner :

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

commit r10-6762-ge6f24f824beb8ba6805702e287bbd6153b472488
Author: Peter Bergner 
Date:   Thu Feb 20 11:25:12 2020 -0600

rs6000: Fix infinite loop building ghostscript and icu [PR93658]

Previous push didn't get the ChangeLog entries or the actual fix.
Push those now.

gcc/
PR target/93658
* config/rs6000/rs6000.c (rs6000_legitimate_address_p): Handle VSX
vector modes.

gcc/testsuite/
PR target/93658
* gcc.target/powerpc/pr93658.c: New test.

[Bug fortran/93825] [OpenACC] Implicit typing not honored – bogus type errors

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Tobias Burnus :

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

commit r10-6761-g2c52b2884ba10b1c5050fe066bae651680c8ebae
Author: Tobias Burnus 
Date:   Thu Feb 20 18:11:32 2020 +0100

OpenACC's tile clause fix for implicit typing (PR93825)

2020-02-20  Tobias Burnus  

PR fortran/93825
* openmp.c (resolve_oacc_loop_blocks): Move call to
resolve_oacc_nested_loops from here ...
(resolve_oacc_loop): ... to here.

PR fortran/93825
* gfortran.dg/goacc/tile-3.f90: New.

[Bug c/93850] New: 'stack smashing detected' in the special index for an array

[haoxintu at gmail dot com]

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

Bug ID: 93850
   Summary: 'stack smashing detected' in the special index for an
array
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, I am developing a random c generation tool to find c compiler bugs.

I found an interesting code that compiles successfully but get a "stack
smashing detected" error when executing it.

The c code is 

void foo(int* a ) {
  a[2]=1;
}
int main (int argc, char* argv[]) {
  int array[] = {0};
  foo(array);
  return 0;
}

My compile command is "gcc test.cc" and it succeeds. Then I execute it using
"./a.out" but I got a 

"*** stack smashing detected ***: ./a.out terminated 
Aborted" 

error. 

I know we should initialize an array before using it. But the most interesting
thing is that only an index of 2 in an array can trigger the error, other index
is fine for execution.

I test the code in GCC 5.4.0 in ubuntu 16.04.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Peter Bergner :

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

commit r10-6760-gb82d426662469ee8b78ec7e8f74abe950485c9d5
Author: Peter Bergner 
Date:   Thu Feb 20 11:08:02 2020 -0600

rs6000: Fix infinite loop building ghostscript and icu [PR93658]

Fix rs6000_legitimate_address_p(), which erroneously marks a valid Altivec
address as being invalid, which causes LRA's process_address()  to go into
an infinite loop spilling the same address over and over again.

gcc/
PR target/93658
* config/rs6000/rs6000.c (rs6000_legitimate_address_p): Handle VSX
vector modes.

gcc/testsuite/
PR target/93658
* gcc.target/powerpc/pr93658.c: New test.

[Bug c/93849] New: 'Segmentation fault' in the special index for an array

[haoxintu at gmail dot com]

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

Bug ID: 93849
   Summary: 'Segmentation fault' in the special index for an array
   Product: gcc
   Version: 5.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: haoxintu at gmail dot com
  Target Milestone: ---

Hi, I am developing a random c generation tool to find c compiler bugs.

I found an interesting code that compiles successfully but get a "Segmentation
fault" result when executing it.

The c code is 

void foo(int* a ) {
  a[6]=1;
}
int main (int argc, char* argv[]) {
  int array[] = {0};
  foo(array);
  return 0;
}

My compile command is "gcc test.cc" and it succeeds. Then I execute it using
"./a.out" but I got a "Segmentation fault" error. 

I know we should initialize an array before using it. But the most interesting
thing is that only an index of 6 in an array can trigger the error, other index
is fine for execution.

I test the code in GCC 5.4.0 in ubuntu 16.04.

[Bug middle-end/90248] [8/9/10 Regression] larger than 0 compare fails with -ffinite-math-only -funsafe-math-optimizations

[ch3root at openwall dot com]

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

Alexander Cherepanov  changed:

   What|Removed |Added

 CC||ch3root at openwall dot com

--- Comment #13 from Alexander Cherepanov  ---
(In reply to Andrew Pinski from comment #7)
> I copied an optimization from LLVM so I
> think they also mess up a similar way (though differently).
I looked into reporting this problem to llvm but I don't see it there. In the
current llvm sources I can only find this:
https://github.com/llvm/llvm-project/blob/master/llvm/lib/Transforms/InstCombine/InstCombineSelect.cpp#L2348

  // If needed, negate the value that will be the sign argument of the
copysign:
  // (bitcast X) <  0 ? -TC :  TC --> copysign(TC,  X)
  // (bitcast X) <  0 ?  TC : -TC --> copysign(TC, -X)
  // (bitcast X) >= 0 ? -TC :  TC --> copysign(TC, -X)
  // (bitcast X) >= 0 ?  TC : -TC --> copysign(TC,  X)

AIUI `bitcast` here means a bitcast to an integer type. For example, this:

--
union u { double d; long l; };

double f(double x)
{
return (union u){x}.l >= 0 ? 2.3 : -2.3;
}
--

is optimized into this:

--
; Function Attrs: nounwind readnone uwtable
define dso_local double @f(double %0) local_unnamed_addr #0 {
  %2 = tail call double @llvm.copysign.f64(double 2.30e+00, double %0)
  ret double %2
}
--

Did I miss something?

[Bug c++/68531] changing bound variable of a VLA type changes type size

[msebor at gcc dot gnu.org]

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

Martin Sebor  changed:

   What|Removed |Added

   Last reconfirmed|2016-07-11 00:00:00 |2020-2-20
Summary|incorrect code for VLA in   |changing bound variable of
   |C++ |a VLA type changes type
   ||size
  Known to fail||10.0, 6.3.0, 7.0.1, 8.3.0,
   ||9.1.0

--- Comment #2 from Martin Sebor  ---
No change in GCC 10.  The root cause of the problem can be seen in the original
dump:

$ gcc -Wall -Wextra  -fdump-tree-original=/dev/stdout pr68531.C

;; Function int main() (null)
;; enabled by -tree-original


{
  int nelems = 7;
  typedef char A[0:(sizetype) (SAVE_EXPR <(ssizetype) nelems + -1>)];
  char a[0:(sizetype) (SAVE_EXPR <(ssizetype) nelems + -1>)];

  <>;
  <;
  <)];>>;
  if (SAVE_EXPR <(ssizetype) nelems + -1> != 6 || SAVE_EXPR <(ssizetype) nelems
+ -1> != 6)
{
  <;
}
}
return  = 0;


The C front-end emits the correct code:

;; Function main (null)
;; enabled by -tree-original


{
  int nelems = 7;
  typedef char A[0:(sizetype) ((long int) SAVE_EXPR  + -1)];
  char a[0:(sizetype) ((long int) SAVE_EXPR  + -1)];

int nelems = 7;
  (void) SAVE_EXPR ;
typedef char A[0:(sizetype) ((long int) SAVE_EXPR  + -1)];
  nelems = 2;
char a[0:(sizetype) ((long int) SAVE_EXPR  + -1)];
  if (SAVE_EXPR  != 7 || (a, SAVE_EXPR  != 7;))
{
  __builtin_abort ();
}
}
return 0;

[Bug c/93848] New: missing -Warray-bounds warning for array subscript 1 is outside array bounds

[vincent-gcc at vinc17 dot net]

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

Bug ID: 93848
   Summary: missing -Warray-bounds warning for array subscript 1
is outside array bounds
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: vincent-gcc at vinc17 dot net
  Target Milestone: ---

Consider the following C code:

void foo_aux (int);

void foo (void)
{
  int i;
  int *p = 
  foo_aux (p[1]);
}

void bar_aux (int *);

void bar (void)
{
  int i[4];
  int (*p)[4] = 
  bar_aux (p[1]);
}

As expected, I get a warning concerning foo:

tst.c: In function ‘foo’:
tst.c:7:3: warning: array subscript 1 is outside array bounds of ‘int[1]’
[-Warray-bounds]
7 |   foo_aux (p[1]);
  |   ^~
tst.c:5:7: note: while referencing ‘i’
5 |   int i;
  |   ^

but I don't get a warning concerning bar (probably because there's no memory
access in this particular case), even though this use is forbidden by the ISO C
standard. Indeed, the end of 6.5.6p8 (about the "pointer + integer" case) says:

  If the result points one past the last element of the array object,
  it shall not be used as the operand of a unary * operator that is
  evaluated.

Tested with gcc-10 (Debian 10-20200211-1) 10.0.1 20200211 (experimental), using

  gcc-10 -O3 -std=c11 -pedantic -Warray-bounds=2 -c tst.c

[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping

[olegendo at gcc dot gnu.org]

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

--- Comment #16 from Oleg Endo  ---
This seems to be actually valid code?!

  switch (e - p)
  {
default: __builtin_unreachable();
case 3: if (e[-3]&0x80) return e-3;
case 2: if (e[-2]&0x80) return e-2;
case 1: if (e[-1]&0x80) return e-1;
case 0: return ((void *)0);
  }

gets compiled to

.L101:
sub r3,r1   ! 465   [c=4 l=2]  *subsi3_internal
mov r1,r3   ! 1083  [c=4 l=2]  movsi_i/1
.L33:
mov #3,r7   ! 469   [c=4 l=2]  movsi_i/2
cmp/hi  r7,r3   ! 474   [c=4 l=2]  cmpgtusi_t

! when here: T bit = r3 > #3
! this is the 'default' case
.L153:
! always branch into nowhere
bt  .L11! 475   [c=17 l=2]  *cbranch_t <<< bad jump


So somehow it hits the case that is supposed to be unreachable.

[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping

[olegendo at gcc dot gnu.org]

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #15 from Oleg Endo  ---
Compiling attachment 47879 with regular sh-elf cross compiler:

sh-elf-gcc -c -O2 -save-temps -dp string_coderange_scan.c 

and looking at the generated assembly, clearly shows the bug right before the
2nd casesi_worker_1 insn:


.L48:
mov.l   .L120,r0! 11[c=10 l=2]  movsi_i/0
add #8,r15  ! 1214  [c=4 l=2]  *addsi3/0
lds.l   @r15+,pr! 1216  [c=1 l=2]  movsi_i/14
mov.l   @r15+,r14   ! 1217  [c=1 l=2]  movsi_i/5
mov.l   @r15+,r13   ! 1218  [c=1 l=2]  movsi_i/5
mov.l   @r15+,r12   ! 1219  [c=1 l=2]  movsi_i/5
mov.l   @r15+,r11   ! 1220  [c=1 l=2]  movsi_i/5
mov.l   @r15+,r10   ! 1221  [c=1 l=2]  movsi_i/5
mov.l   @r15+,r9! 1222  [c=1 l=2]  movsi_i/5
rts ! 1225  [c=0 l=2]  *return_i
mov.l   @r15+,r8! 1223  [c=1 l=2]  movsi_i/5
.align 1
.L96:
sub r2,r10  ! 278   [c=4 l=2]  *subsi3_internal
mov #3,r2   ! 282   [c=4 l=2]  movsi_i/2


.L11:   !  jump target BEFORE the constant pool
.L121:
.align 2
.L120:
.long   1048576 !  this is a constant in the constant pool
.align 1
.L58:
mov r13,r3  ! 1119  [c=4 l=2]  movsi_i/1
bra .L15! 1261  [c=5 l=2]  jump_compact
add #-16,r3 ! 1120  [c=4 l=2]  *addsi3/0
.align 1
.L29:
mov.b   @(14,r3),r0 ! 316   [c=2 l=2] 
*extendqisi2_compact_mem_disp/0
cmp/pz  r0  ! 317   [c=4 l=2]  cmpgesi_t/0
bf  .L107   ! 318   [c=17 l=2]  *cbranch_t
.L30:
mov.b   @(15,r3),r0 ! 330   [c=2 l=2] 
*extendqisi2_compact_mem_disp/0
cmp/pz  r0  ! 331   [c=4 l=2]  cmpgesi_t/0
bt  .L48! 332   [c=17 l=2]  *cbranch_t
mov r13,r8  ! 1068  [c=4 l=2]  movsi_i/1
bra .L23! 1265  [c=5 l=2]  jump_compact
add #-1,r8  ! 334   [c=4 l=2]  *addsi3/0
.align 1
.L101:
sub r3,r1   ! 465   [c=4 l=2]  *subsi3_internal
mov r1,r3   ! 1083  [c=4 l=2]  movsi_i/1
.L33:
mov #3,r7   ! 469   [c=4 l=2]  movsi_i/2
cmp/hi  r7,r3   ! 474   [c=4 l=2]  cmpgtusi_t
.L153:
bt  .L11! 475   [c=17 l=2]  *cbranch_t <<< bad jump
mova.L42,r0 ! 1085  [c=9 l=2]  mova
add r3,r3   ! 1086  [c=9 l=4]  casesi_worker_1/0
mov.w   @(r0,r3),r3
add r0,r3   ! 1087  [c=4 l=2]  *addsi3/0
jmp @r3
nop ! 477   [c=4 l=4]  casesi_jump_1
.align 2

[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' with -fcrossjumping

[olegendo at gcc dot gnu.org]

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

--- Comment #14 from Oleg Endo  ---
Created attachment 47879
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47879=edit
reduced case

I've reduced the preprocessed file string.c down to the problematic function
'coderange_scan'

[Bug c/93847] Nios II ICE

[giulio.benetti at benettiengineering dot com]

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

--- Comment #1 from Giulio Benetti  ---
Here is another test-case:
http://autobuild.buildroot.net/results/e22/e225e62ea2d48660df4110790664f0c3306c1ea9/

Here gcc is built from scratch instead of using Codesourcery one, so it should
be easy for you to check.

I've found that this bug affects Nios II on gcc 6,7,8.

[Bug middle-end/80922] #pragma diagnostic ignored not honoured with -flto

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
No, it's still not supported with LTO, it's not so easy to implement that. I
can return to it in the next stage.

[Bug c/93847] New: Nios II ICE

[giulio.benetti at benettiengineering dot com]

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

Bug ID: 93847
   Summary: Nios II ICE
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: giulio.benetti at benettiengineering dot com
  Target Milestone: ---

When building git package on Buildroot gcc throws:
'''
ref-filter.c: In function 'find_longest_prefixes_1':
ref-filter.c:1914:1: internal compiler error: Segmentation fault
 }
 ^
'''

To reproduce it:

# git clone git://git.busybox.net/buildroot
# wget https://git.busybox.net/buildroot-test/tree/utils/br-reproduce-build

- modify BASE_GIT=... with your buildroot path in br-reproduce-build then:
# chmod a+x br-reproduce-build
# ./br-reproduce-build 432a2766836107ed5536f861a8fbcab33e1f8cf6

The only way I've found to build correctly is to turn off optimization
overriding CFLAGS with -O0.

Hope you can reproduce this way as they've done for RISCV32:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93532

Otherwise it become useless to send you only .i file.

[Bug middle-end/80922] #pragma diagnostic ignored not honoured with -flto

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org

--- Comment #3 from Richard Biener  ---
ISTR Martin made -W options streamed per function for GCC 10?

[Bug target/93808] [9 Regression] [SH] Ruby crashes with 'Illegal Instruction' when compiled with gcc-9

[glaubitz at physik dot fu-berlin.de]

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

--- Comment #13 from John Paul Adrian Glaubitz  ---
(In reply to John Paul Adrian Glaubitz from comment #12)
> Building with -O1 fixes the problem for me. Now I need to compare the flags
> for -O1 and -O2 and check which one breaks the build.

It's -fcrossjumping which causes the crash. Passing -fno-crossjumping fixes the
build.

[Bug middle-end/80922] #pragma diagnostic ignored not honoured with -flto

[romain.geissler at amadeus dot com]

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

Romain Geissler  changed:

   What|Removed |Added

 CC||romain.geissler at amadeus dot 
com

--- Comment #2 from Romain Geissler  ---
Hi,

I am hitting this issue when trying to leverage lto in many libraries (on the
exact same warning class by the way, but this affects all warnings).

Since the last entry in this bug 3 years ago, is there now updated plans to
stream/support warning flags/pragma diagnostics in the LTO sections in gcc 11 ?

Cheers,
Romain

[Bug fortran/93826] [OpenMP][OpenACC] Collapsed loop – code silently ignored

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus  ---
The C code rejects this as follows.

The OpenACC specification talks about "tightly nested loops"; the OpenMP spec
is less clear but for "collapse" contrary to "tile" the implication that
tightly nested loops are meant is not far.

--
int foo (int x, int y) {
  int i, j;
#pragma omp parallel for collapse(2)
#pragma acc parallel loop collapse(2)
  for (i = 0; i < 2; ++i)
{
  for (j = 0; j < 2; ++j)
x = 5;
  y = 7;  /* { dg-error "collapsed loops not perfectly nested before 'y'" }
 */
}
  return x + y;
}

int bar (int a, int b) {
  int i, j;
#pragma acc parallel loop tile(2,2)
  for (i = 0; i < 2; ++i)
{
  for (j = 0; j < 2; ++j)
a = 5;
  b = 7;  /* { dg-error "collapsed loops not perfectly nested before 'b'" }
 */
}
  return a + b;
}

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

[dave.anglin at bell dot net]

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

--- Comment #191 from dave.anglin at bell dot net ---
On 2020-02-19 9:50 p.m., peter.bisroev at groundlabs dot com wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61577
>
> --- Comment #190 from Peter Bisroev  ---
> (In reply to dave.anglin from comment #189)
>> On 2020-02-16 4:21 p.m., John David Anglin wrote:
>>> On 2020-02-15 3:32 p.m., peter.bisroev at groundlabs dot com wrote:
 I have not had a chance to look through these in great detail, will do this
 later today, but some things I've noticed (not sure how important they are
 yet):
 - aCC seems to use PCREL21BI relocations while GCC PCREL21B.
>>> That may be the clue.  With GNU ld, only PCREL21BI goes through PLT.  Need 
>>> to look at when
>>> GNU as uses PCREL21BI instead of PCREL21B.  I believe this selection is 
>>> done in assembler.
>> Sorry, only PCREL21B goes through PLT.  PCREL21BI is for local (internal)
>> calls.
> Hi Dave, I apologize for the delay in response, been a busy week so far.
> However I should be able to take a look at this further tomorrow.
>
> As per your recommendation I will try and find out when GNU as generates
> PCREL21BI relocations instead of PCREL21B. I am assuming this is what we want
> in order to match aCC behavior, right?
I Peter, no problem.  I've been busy...

The problem seems to be that HP ld doesn't handle the PCREL21B relocation
correctly when it refers
to a weak function (i.e., it doesn't direct the call through the PLT).  At the
same time, weak references
don't seem to work with aCC.

As far as I can tell, the PCREL21B is generated by gas in gas/config/tc-ia64.c
at line 5919.  You could try
changing it to PCREL21BI to see if that helps (run binutils testsuite before
installing) but the change doesn't
seem correct.  We might need to generate a 32-bit branch to weak functions in
gcc.

It would be useful to find out why weak doesn't work with aCC.

[Bug go/93844] [debug] Incorrect scope for local variables

[rguenth at gcc dot gnu.org]

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

--- Comment #5 from Richard Biener  ---
(In reply to Tom de Vries from comment #4)
> (In reply to Richard Biener from comment #1)
> > The only way to capture these may
> > be to introduce additional scoping in the FEs whenever new local decls
> > are added.  Also consider
> > 
> >   const char *oldst = st;
> >   const char *st = "Hello, world!";
> > 
> > so even consecutive inits may need two separate scopes.
> 
> At the DWARF side, DW_AT_start_scope looks applicable:
> ...
> The debugging information entry for a program variable, formal parameter or
> constant may have the following attributes:
> ...
> 11. A DW_AT_start_scope attribute if the scope of an object is smaller than
> (that is, is a subset of the addresses of) the scope most closely enclosing
> the object.
> ...
> 
> Maybe this can be generating without introducing additional scoping?

One the DWARF side maybe.  But on the GCC side all we have is the BLOCK
tree and all FEs put the "late" declarations in the enclosing BLOCKs
BLOCK_VARS.  So DW_AT_start_scope would be an optimization that can be used
to elide DW_TAG_lexical_block if the end of the enclosing scope is the
same as the end of the current scope.

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

[guojiufu at gcc dot gnu.org]

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

--- Comment #4 from Jiu Fu Guo  ---
This issue can be reproduced with GCC9 "-O2 -funroll-loops -mcpu=power9" or
"-O3 -mcpu=power9".

[Bug sanitizer/93846] libsanitizer compilation error with glibc 2.31

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
It's duplicate of PR92154. Please build current gcc-9 branch master.

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

[Bug sanitizer/92154] new glibc breaks arm bootstrap due to libsanitizer

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||rezso at rezso dot net

--- Comment #11 from Martin Liška  ---
*** Bug 93846 has been marked as a duplicate of this bug. ***

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

[guojiufu at gcc dot gnu.org]

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

--- Comment #3 from Jiu Fu Guo  ---
This issue may relates to cunroll and cunrollli; after cunroll, for power9 some
special instructions were selected.
In RTL, for power9, 'smax' is generated at ce1 pass; 
While for power8, 'smax' is not used.

[Bug sanitizer/93846] New: libsanitizer compilation error with glibc 2.31

[rezso at rezso dot net]

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

Bug ID: 93846
   Summary: libsanitizer compilation error with glibc 2.31
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rezso at rezso dot net
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

If I try to compile gcc 9.2.0 release with glibc 2.31, I get this error:

In file included from
/var/uhubuild/work/compile/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cc:193:
/var/uhubuild/work/compile/libsanitizer/sanitizer_common/sanitizer_internal_defs.h:339:72:
error: narrowing conversion of ‘-1’ from ‘int’ to ‘long unsigned int’
[-Wnarrowing]
  339 | typedef char IMPL_PASTE(assertion_failed_##_,
line)[2*(int)(pred)-1]

How to fix this error?

[Bug target/81652] [meta-bug] -fcf-protection=full bugs

[hjl.tools at gmail dot com]

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

Bug 93656 Summary: FAIL: gcc.target/i386/pr67770.c execution test with 
-fcf-protection
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93656

   What|Removed |Added

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

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

[hjl.tools at gmail dot com]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #4 from H.J. Lu  ---
Fixed for GCC 10, GCC 9.3 and GCC 8.4.

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-8 branch has been updated by H.J. Lu :

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

commit r8-10040-gb4edc88453b61d6f3bdb9143cd0486536f95598d
Author: H.J. Lu 
Date:   Thu Feb 20 03:05:27 2020 -0800

i386: Skip ENDBR32 at the target function entry

Skip ENDBR32 at the target function entry when initializing trampoline.

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

gcc/

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

gcc/testsuite/

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

(cherry picked from commit 1d69147af203d4dcd2270429f90c93f1a37ddfff)

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #2 from CVS Commits  ---
The releases/gcc-9 branch has been updated by H.J. Lu :

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

commit r9-8259-gf55bf4ddbfac3c7360cb00f3200b663c19baf504
Author: H.J. Lu 
Date:   Thu Feb 20 03:05:27 2020 -0800

i386: Skip ENDBR32 at the target function entry

Skip ENDBR32 at the target function entry when initializing trampoline.

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

gcc/

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

gcc/testsuite/

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

(cherry picked from commit 1d69147af203d4dcd2270429f90c93f1a37ddfff)

[Bug translation/93831] wrong abbreviation in diagnostic for 64-bit Darwin

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #4 from Martin Liška  ---
Fixed.