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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

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

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

[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 #11 from John Paul Adrian Glaubitz  ---
Created attachment 47878
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47878&action=edit
Source and compiler output for string.c with stack-protector disabled

(In reply to Oleg Endo from comment #10)
> It's difficult to see what's going on there.  Can you try building this
> without the stackprotector options and see if still crashes in the same way?

I have stripped "-fstack-protector" and "-fstack-protector-strong" from the
CFLAGS, still crashes. Attaching the corresponding tarball of the string.*
files.

I can try removing more flags from CFLAGS and see if that helps.

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |8.4

[Bug fortran/93834] [8/9/10 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |8.4

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

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Priority|P3  |P4
   Target Milestone|--- |8.4

[Bug fortran/93835] [9/10 Regression] ICE in simplify_findloc_nodim, at fortran/simplify.c:5513

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|10.0|9.3

[Bug tree-optimization/93843] wrong code at -O3 on x86_64-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
  Known to work||9.2.0
Version|unknown |10.0
   Keywords||wrong-code
   Last reconfirmed||2020-02-20
 CC||marxin at gcc dot gnu.org,
   ||rsandifo at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |10.0
  Known to fail||10.0

--- Comment #1 from Martin Liška  ---
Nice catch. Actually started with -fno-common with r10-4742-g9b75f56d4b7951c6.

[Bug tree-optimization/93843] [10 Regression] wrong code at -O3 on x86_64-linux-gnu

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
Summary|wrong code at -O3 on|[10 Regression] wrong code
   |x86_64-linux-gnu|at -O3 on x86_64-linux-gnu

[Bug c++/93842] generic lambda accesses a variable with with automatic storage duration that wasn't captured by the lambda expression

[rguenth at gcc dot gnu.org]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||accepts-invalid, diagnostic

--- Comment #1 from Richard Biener  ---
Hmm, maybe a 'constexpr char' isn't  a variable with automatic storage
duration.

[Bug translation/93838] space at the end of a diagnostic in cp/parser.c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
I can fix it.

[Bug c++/93842] generic lambda accesses a variable with with automatic storage duration that wasn't captured by the lambda expression

[marxin at gcc dot gnu.org]

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

--- Comment #2 from Martin Liška  ---
Confirmed that clang really rejects the code:

$ clang pr93842.cc  -Wunused -std=c++14 -c
pr93842.cc:4:20: error: variable 'ch' cannot be implicitly captured in a lambda
with no capture-default specified
[](auto) { return ch; }; // NOT OK
  ^
pr93842.cc:2:17: note: 'ch' declared here
constexpr char ch = '=';
   ^
pr93842.cc:4:2: note: lambda expression begins here
[](auto) { return ch; }; // NOT OK
^
pr93842.cc:4:2: warning: expression result unused [-Wunused-value]
[](auto) { return ch; }; // NOT OK
^~~
1 warning and 1 error generated.

For the record, we print the warning since r8-3497-g281e6c1d8f1b4ca5.

[Bug translation/93841] typo in or1kopt: generated using using

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
I can fix it.

[Bug c/93837] overly complicated code in c_finish_omp_declare_variant

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Keywords||easyhack
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

[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|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2020-02-20
 CC||marxin at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
I can fix this one as well.

[Bug translation/93830] typo in avr command line error message

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #1 from Martin Liška  ---
I can fix it.

[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 #1 from Richard Biener  ---
Guess it's the same bug as with C99 or C++ where you can write

const char *st = "Shall we?";
int main()
{
  printf ("%s\n", st);
  printf ("%s\n", "Before assignment");
  const char *st = "Hello, world!";
  printf ("%s\n", st);
  return 0;
}

(gdb) start
Temporary breakpoint 1, main () at t.c:5
5 printf ("%s\n", st);
(gdb) p st
$1 = 0x0
(gdb) n
Shall we?
6 printf ("%s\n", "Before assignment");
(gdb) p st
$2 = 0x0
(gdb) n
Before assignment
7 const char *st = "Hello, world!";
(gdb) p st
$3 = 0x0
(gdb) n
8 printf ("%s\n", st);
(gdb) p st
$4 = 0x4005c0 "Hello, world!"

and there's a duplicate PR about this.  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.

[Bug tree-optimization/93845] New: [10 regression] ICE in verify_sra_access_forest, at tree-sra.c:2358

[dimhen at gmail dot com]

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

Bug ID: 93845
   Summary: [10 regression] ICE in verify_sra_access_forest, at
tree-sra.c:2358
   Product: gcc
   Version: 10.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimhen at gmail dot com
  Target Milestone: ---

probably differs from PR93776 and PR93516

r10-6309 PASS
r10-6342 FAIL
r10-6723 FAIL

[r10-6723] g++ -fpreprocessed -fchecking=1 -O -c x.ii
g++  -fpreprocessed -fchecking=1 -O -c x.ii; ll x.ii
during GIMPLE pass: esra
x.ii: In function ‘void m()’:
x.ii:21:1: internal compiler error: in verify_sra_access_forest, at
tree-sra.c:2358
   21 | }
  | ^
0x817afd verify_sra_access_forest(access*)
/home/dimhen/src/gcc_current/gcc/tree-sra.c:2358
0x1334bca verify_all_sra_access_forests()
/home/dimhen/src/gcc_current/gcc/tree-sra.c:2403
0x1339910 analyze_all_variable_accesses
/home/dimhen/src/gcc_current/gcc/tree-sra.c:3414
0x1339e31 perform_intra_sra
/home/dimhen/src/gcc_current/gcc/tree-sra.c:4468
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

$ cat x.ii
struct a;
struct b {
  a *operator->();
};
class c {
  void *g;
  int d;

public:
  template  e f() { return *static_cast(this); }
};
struct h : c {};
struct a {
  void i(c);
};
void m() {
  b j;
  c k;
  h l = k.f();
  j->i(l);
}

[Bug fortran/93835] [9/10 Regression] ICE in simplify_findloc_nodim, at fortran/simplify.c:5513

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 CC||marxin at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org

--- Comment #3 from Martin Liška  ---
Started with r9-3688-g01ce9e31a02c8039.

[Bug fortran/93834] [8/9/10 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-20
 CC||marxin at gcc dot gnu.org,
   ||vehre at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Started with r7-5021-gba85c8c3fcb19c77, before that it was rejected:

pr93834.f90:3:22:

print *, allocated(a[1])
  1
Error: ‘array’ argument of ‘allocated’ intrinsic at (1) must be a variable
re PR fortran/78593 (ICE in gfc_match_varspec, at fortran/primary.c:2053)

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-20
 CC||marxin at gcc dot gnu.org,
   ||pault at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r8-6877-g5c60dbc14b42430d.

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

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-02-20
 CC||marxin at gcc dot gnu.org,
   ||tkoenig at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Martin Liška  ---
Confirmed, started with r8-6898-g04946c6b905572f3.

[Bug tree-optimization/93845] [10 regression] ICE in verify_sra_access_forest, at tree-sra.c:2358

[dimhen at gmail dot com]

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

--- Comment #1 from Dmitry G. Dyachenko  ---
'-Wall -Wextra -O3' free variant

$ cat x.ii
struct g;
struct h {
  g *operator->();
};
class i {
  void *a;
  int b;

public:
  template  f j() { return *static_cast(this); }
};
struct k : i {};
struct l : k {};
struct m {
  i n();
  i o(l, l, int);
};
struct g {
  void m_fn4(k);
};
h a;
i b;
i m::n() {
  l c, d, e = o(d, c, 0).j();
  a->m_fn4(e);
  return b;
}

$ ~/arch-gcc/r10-6309/bin/g++ -fpreprocessed -fchecking=1 -O3 -Wall -Wextra -c
x.ii

$ $ ~/arch-gcc/r10-6723/bin/g++ -fpreprocessed -fchecking=1 -O -c x.ii
during GIMPLE pass: esra
x.ii: In member function ‘i m::n()’:
x.ii:27:1: internal compiler error: in verify_sra_access_forest, at
tree-sra.c:2358
   27 | }
  | ^
0x817afd verify_sra_access_forest(access*)
/home/dimhen/src/gcc_current/gcc/tree-sra.c:2358
0x1334bca verify_all_sra_access_forests()
/home/dimhen/src/gcc_current/gcc/tree-sra.c:2403
0x1339910 analyze_all_variable_accesses
/home/dimhen/src/gcc_current/gcc/tree-sra.c:3414
0x1339e31 perform_intra_sra
/home/dimhen/src/gcc_current/gcc/tree-sra.c:4468
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

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

[rguenth at gcc dot gnu.org]

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

--- Comment #31 from Richard Biener  ---
(In reply to Jakub Jelinek from comment #29)
> Passed bootstrap/regtest on all of {x86_64,i686,powerpc64{,le}}-linux now,
> with powerpc64-linux doing both -m32/-m64 testing.

LGTM.

[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 #12 from John Paul Adrian Glaubitz  ---
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.

[Bug tree-optimization/93845] [10 regression] ICE in verify_sra_access_forest, at tree-sra.c:2358

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

   Priority|P3  |P1
 Status|UNCONFIRMED |NEW
  Known to work||9.2.0
   Keywords||ice-on-valid-code
   Last reconfirmed||2020-02-20
 CC||jamborm at gcc dot gnu.org,
   ||marxin at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |10.0
  Known to fail||10.0

--- Comment #2 from Martin Liška  ---
Confirmed, started with r10-6322-g6693911f069b1ada.

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

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  ---
you're welcome, of course - if not, hopefully I can get to this and the other
translation comments over the weekend (been out of the office at WG21, and
catching up)

[Bug c++/93443] gcc/cp/coroutines.cc:3555:23: runtime error: load of value 255, which is not a valid value for type 'bool'

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Liška  ---
Yes, it is.

[Bug c++/93443] gcc/cp/coroutines.cc:3555:23: runtime error: load of value 255, which is not a valid value for type 'bool'

[iains at gcc dot gnu.org]

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

--- Comment #2 from Iain Sandoe  ---
AFAICS, this should be fixed now, yes?

[Bug other/63426] [meta-bug] Issues found with -fsanitize=undefined

[marxin at gcc dot gnu.org]

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

Bug 93443 Summary: gcc/cp/coroutines.cc:3555:23: runtime error: load of value 
255, which is not a valid value for type 'bool'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93443

   What|Removed |Added

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

[Bug c++/93842] generic lambda accesses a variable with with automatic storage duration that wasn't captured by the lambda expression

[kuzniar95 at o2 dot pl]

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

--- Comment #3 from kuzniar95 at o2 dot pl ---
@Richard Biener changing it to

char const ch = '='; // NOT OK

doesn't solve the issue. Interestingly dropping constness:

char ch = '='; // OK

works.

So we are onto something - both const and constexpr introduce some different
handling but this special behaviour changes accessibility.

I understand "different handling" when we're talking about compile-time
expressions such as using constants for array dimensions but accessibility
changes are quite suspicious.

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

[kito at gcc dot gnu.org]

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

Kito Cheng  changed:

   What|Removed |Added

 CC||kito at gcc dot gnu.org

--- Comment #28 from Kito Cheng  ---
pr90883.C got fail for following target:

| fail reason
arm-eabi| "Deleted redundant store:" appear dse2
mips-elf| "Deleted dead store: .a[*] = 0;" appear at dse2
mips64-elf  | "Deleted dead store: .a[*] = 0;" appear at dse2
nds32le-elf | "Deleted redundant store:" appear dse2
riscv32-elf | "Deleted redundant store:" appear dse2


And configure options:

| configure option
arm-eabi| --target=arm-eabi
mips-elf| --target=mips-elf
mips64-elf  | --target=mips64-elf
nds32le-elf | --target=nds32le-elf
riscv32-elf | --target=riscv32-elf --with-arch=rv32gc --with-abi=ilp32d

sha1: g:85232b45840330df0fef81f2d4756d9a25d5ac3b

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

[vries at gcc dot gnu.org]

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

--- Comment #2 from Tom de Vries  ---
(In reply to Richard Biener from comment #1)
> Guess it's the same bug as with C99 or C++ where you can write
> 
> const char *st = "Shall we?";
> int main()
> {
>   printf ("%s\n", st);
>   printf ("%s\n", "Before assignment");
>   const char *st = "Hello, world!";
>   printf ("%s\n", st);
>   return 0;
> }
> 

AFAIU, the go language rules define the scope of the variable to start at the
variable declaration ( https://golang.org/ref/spec#Declarations_and_scope ):
...
The scope of a constant or variable identifier declared inside a function
begins at the end of the ConstSpec or VarSpec (ShortVarDecl for short variable
declarations) and ends at the end of the innermost containing block.
...

For C++, things are well-defined in terms of declarative region, potential
scope, actual scope and point of declaration.

[ FWIW, for C99, I can't actually find a clear interpretation of the program in
the standard. That is, it's defined that the local variable has block scope,
and that the block scope ends at the end of the associated block. But it's not
defined where the block scope starts. If we interpret the block scope to start
at the start of the block, then the compiler should emit a use-before-declare
error. But I'm guessing I'm missing something. ]

So agreed, it's the same bug, at least for C++.

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

[vries at gcc dot gnu.org]

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

--- Comment #3 from Tom de Vries  ---
(In reply to Richard Biener from comment #1)
> and there's a duplicate PR about this.

I found: PR92386 - "gdb issue with variable-shadowing"  which sound similar.

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

[vries at gcc dot gnu.org]

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

--- Comment #4 from Tom de Vries  ---
(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?

[Bug translation/93841] typo in or1kopt: generated using using

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-6755-g4a172be3e5e849ef82f07ce034837630e73f025b
Author: Martin Liska 
Date:   Thu Feb 20 12:01:48 2020 +0100

Remove superfluous word in documentation.

PR translation/93841
* config/or1k/or1k.opt: Remove superfluous word.
* doc/invoke.texi: Likewise.

[Bug translation/93830] typo in avr command line error message

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

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

[cvs-commit at gcc dot gnu.org]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Martin Liska :

https://gcc.gnu.org/g:093bdf2cec611947fb69d8ced21a2d875166cba0

commit r10-6753-g093bdf2cec611947fb69d8ced21a2d875166cba0
Author: Martin Liska 
Date:   Thu Feb 20 12:01:41 2020 +0100

Fix error message for Darwin.

PR translation/93831
* config/darwin.c (darwin_override_options): Change 64b to 64-bit mode.

[Bug translation/93838] space at the end of a diagnostic in cp/parser.c

[cvs-commit at gcc dot gnu.org]

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

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

https://gcc.gnu.org/g:6c39d0b79db7f9bf58a64bf987c161ae0b9dcec4

commit r10-6754-g6c39d0b79db7f9bf58a64bf987c161ae0b9dcec4
Author: Martin Liska 
Date:   Thu Feb 20 12:01:44 2020 +0100

Remove triling space for a warning.

PR translation/93838
* parser.c (cp_parser_decl_specifier_seq): Remove trailing space.

[Bug translation/93830] typo in avr command line error message

[cvs-commit at gcc dot gnu.org]

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

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

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

commit r10-6752-gf40237a37b28a4c9143bfcbf5886fc9a6d3b5cfe
Author: Martin Liska 
Date:   Thu Feb 20 12:01:09 2020 +0100

Remove trailing | in help message.

PR translation/93830
* common/config/avr/avr-common.c: Remote trailing "|".

[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.

[Bug translation/93841] typo in or1kopt: generated using using

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug translation/93838] space at the end of a diagnostic in cp/parser.c

[marxin at gcc dot gnu.org]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[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 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

[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/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 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/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/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 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 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 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 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 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/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 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

[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 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

[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] 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 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&action=edit
reduced case

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

[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 #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 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 = &i;
  foo_aux (p[1]);
}

void bar_aux (int *);

void bar (void)
{
  int i[4];
  int (*p)[4] = &i;
  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 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 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/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 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/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 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 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 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 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 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 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 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 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] 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/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/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 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/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 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/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 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, &ecnt);
+ 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, &comp_tail->val,
-   comp->ts.u.derived->attr.zero_comp
- ? &arg_null : &actual, true);
-  if (!m)
-goto cleanup;
+#define shorter gfc_convert_to_structure_constructor
+ m = shorter (NULL, comp->ts.u.derived, &comp_tail->val,
+  comp->ts.u.derived->attr.zero_comp
+  ? &arg_null : &actual, 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] 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 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

[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 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 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/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/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&action=edit
Patch in testing.

[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

[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 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 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 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 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 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.