[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

  Component|lto |target
 CC||mfortune at gmail dot com

--- Comment #6 from Richard Biener  ---
I see.  Still GCC or GAS produces a bogus object file (the original linker
error).  It might be the new problem is an entirely different one?  It looks
more and more like a target problem to me.

CCing the mips maintainer.

[Bug lto/97812] [9/10/11 Regression] Wrong output when compiling the testcase with -O2 -flto since r9-4558-g476a31b55b5471262

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

Summary|Wrong output when compiling |[9/10/11 Regression] Wrong
   |the testcase with -O2 -flto |output when compiling the
   ||testcase with -O2 -flto
   ||since
   ||r9-4558-g476a31b55b5471262
   Keywords|needs-bisection |
   Target Milestone|--- |9.4
 CC||rguenth at gcc dot gnu.org

--- Comment #8 from Martin Liška  ---
Started with r9-4558-g476a31b55b5471262.

Slightly modified test-case:

$ cat pr97812.c
char c;

int main() {
volatile short b = 4066;
  unsigned d = b & 2305;
  signed char e = d;
  c = e ? : e;
  if (!d)
__builtin_abort ();
  return 0;
}

@Richi: You can reproduce that on needle machine (su mliska):
$ cd /tmp/
$ gcc pr97812.c -O2 -flto -fdump-tree-all -o a.out && ./a.out
Aborted (core dumped)

[Bug c/88566] -Wconversion not using value range information

[trass3r at gmail dot com via Gcc-bugs]

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

Trass3r  changed:

   What|Removed |Added

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

--- Comment #6 from Trass3r  ---
Looks like this has been fixed in gcc 10 with the first Project Ranger merge.
https://godbolt.org/z/p0RMde
https://linuxplumbersconf.org/event/7/contributions/743/attachments/511/921/plumbers.pdf

[Bug target/96265] building nvptx-none on aarch64-linux-gnu

[burnus at gcc dot gnu.org via Gcc-bugs]

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

Tobias Burnus  changed:

   What|Removed |Added

Summary|building nvptx-none on  |building nvptx-none on
   |platforms other than|aarch64-linux-gnu
   |x86_64-linux-gnu, e.g.  |
   |aarch64-linux-gnu and   |
   |powerpc64le-linux-gnu   |

--- Comment #2 from Tobias Burnus  ---
(Remove powerpc64le-linux-gnu from the summary as this PR is only about
aarch64-linux and GCC is known to work on powerpc64le-linux-gnu.)

(In reply to Matthias Klose from comment #1)
> patch for the target hook posted at
> https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550534.html

This patch has been committed on Fri Jul 24 16:17:44 2020 +0200 as
https://gcc.gnu.org/g:29a14a1a907947fe9e43bce62d3468559f17da97

[Bug rtl-optimization/92294] alias attribute generates incorrect code

[mhillen at linux dot ibm.com via Gcc-bugs]

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

--- Comment #6 from Marius Hillenbrand  ---
Same behavior on s390x: the testcase always calls abort(). As on aarch64,
-fno-section-anchors avoids the issue.

the first cse pass already makes a mistake -- on both aarch64 and s390x, the
compare looses its memory-read for the current value of b and instead reuses
the constant 1 assigned to b earlier.

on aarch64 that looks like

(insn # # # 2 (set (reg:SI 110)
(mem:SI (plus:DI (mult:DI (reg:DI 109)
(const_int 4 [0x4]))
(reg/f:DI 107)) [1 b[off.0_1]+0 S4 A32])) "alias-2.c":9:6#
{*movsi_aarch64}
 (nil))
(insn # # # 2 (set (reg:CC 66 cc)
(compare:CC (reg:SI 110)
(const_int 2 [0x2]))) "alias-2.c":9:6# {cmpsi}
 (nil))

... becomes ...

(insn # # # 2 (set (reg:SI 100)
(const_int 1 [0x1])) "alias-2.c":7:9# {*movsi_aarch64}
 (nil)) [from the write to b]
...
(insn # # # 2 (set (reg:CC 66 cc)
(compare:CC (reg:SI 100)
(const_int 2 [0x2]))) "alias-2.c":9:6# {cmpsi}
 (expr_list:REG_DEAD (reg:SI 110 [ b[off.0_1] ])
(nil)))

[Bug lto/97812] [9/10/11 Regression] Wrong output when compiling the testcase with -O2 -flto since r9-4558-g476a31b55b5471262

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Richard Biener  ---
(In reply to Martin Liška from comment #8)
> Started with r9-4558-g476a31b55b5471262.
> 
> Slightly modified test-case:
> 
> $ cat pr97812.c
> char c;
> 
> int main() {
> volatile short b = 4066;
>   unsigned d = b & 2305;
>   signed char e = d;
>   c = e ? : e;
>   if (!d)
> __builtin_abort ();
>   return 0;
> }
> 
> @Richi: You can reproduce that on needle machine (su mliska):
> $ cd /tmp/
> $ gcc pr97812.c -O2 -flto -fdump-tree-all -o a.out && ./a.out
> Aborted (core dumped)

Why would you need -flto?  Can you share dumps of the previous pass
of where it goes wrong?  I also fail to see why it would need aarch64,
there's no piece that should influence GIMPLE.

Hmm, OK.  So a cross shows differences in the initial IL from the FE:

   volatile short int b = 4066;
-  unsigned int d = (unsigned int) b & 2305;
+  unsigned int d = (unsigned int) (unsigned short) b & 2305;
   signed char e = (signed char) d;

the GIMPLE dump reveals association:

-_2 = (unsigned int) b.0_1;
-d = _2 & 2305;
+b.1_2 = (unsigned short) b.0_1;
+_3 = (unsigned int) b.1_2;
+d = _3 & 2305;

for some reason on aarch64 we are zero-extending b only on aarch64.
>From here things go downhill.

Ah, the difference stems from fold_unary which does

  /* Convert (T)(x & c) into (T)x & (T)c, if c is an integer
 constants (if x has signed type, the sign bit cannot be set
 in c).  This folds extension into the BIT_AND_EXPR.
 ??? We don't do it for BOOLEAN_TYPE or ENUMERAL_TYPE because they
 very likely don't have maximal range for their precision and this
 transformation effectively doesn't preserve non-maximal ranges.  */
  if (TREE_CODE (type) == INTEGER_TYPE
  && TREE_CODE (op0) == BIT_AND_EXPR
  && TREE_CODE (TREE_OPERAND (op0, 1)) == INTEGER_CST)
{
..
  if (change
  && !flag_syntax_only
  && (load_extend_op (TYPE_MODE (TREE_TYPE (and0)))
  == ZERO_EXTEND))
{
  tree uns = unsigned_type_for (TREE_TYPE (and0));
  and0 = fold_convert_loc (loc, uns, and0);
  and1 = fold_convert_loc (loc, uns, and1);

on x86_64 load_extend_op (HImode) returns UNKNOWN while on aarch64 it
returns ZERO_EXTEND.

Not sure why we do this kind of thing so prematurely here :/

Then one needs -funsigned-char to reproduce it on x86_64 but indeed only with
-flto ...

So, testcase failing on x86_64 with -O2 -flto:

unsigned char c;
int main()
{
  volatile short b = 4066;
  unsigned short bp = b;
  unsigned d = bp & 2305;
  signed char e = d;
  c = e ? : e;
  if (!d)
__builtin_abort ();
  return 0;
}

[Bug lto/97812] [9/10/11 Regression] Wrong output when compiling the testcase with -O2 -flto since r9-4558-g476a31b55b5471262

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #10 from Richard Biener  ---
OK, and the reason is that wi::fits_to_tree_p interprets USHORT_MAX as signed
-1
(wide_int is canonically sign-extended) and that fits signed char.  I guess
fits_to_tree_p was supposed to be used on widest_ints only.

[Bug fortran/97799] [10/11 Regression] Passing CHARACTER*(*) var(*) through ENTRY causes segfaults

[tkoenig at gcc dot gnu.org via Gcc-bugs]

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

Thomas Koenig  changed:

   What|Removed |Added

   Target Milestone|--- |10.3
Summary|Passing CHARACTER*(*)   |[10/11 Regression] Passing
   |var(*) through ENTRY causes |CHARACTER*(*) var(*)
   |segfaults   |through ENTRY causes
   ||segfaults
 Status|VERIFIED|RESOLVED

--- Comment #12 from Thomas Koenig  ---
(In reply to George Hockney from comment #11)
> We've verified a large-scale legacy build against 
> 
> GNU Fortran (gcc8.2) 11.0.0 2020 (experimental)
> 
> and
> 
> GNU Fortran (GCC) 10.2.1 20201017
> 
> All our regressions pass these compilers.

Thanks for letting us know.

> Therefore, I'm changing the status to verified (this is per our bugzilla
> workflow; if it's not your workflow please fix)

It's not usually done, so I'll just change this back (there are
a few search masks which don't have VERIFIED in).

> Unfortunately, 10.2.0 was released with this bug.

Yep.

I have looked over the changes to gcc10 since the 10.2 release to the gfortran
front end  haven't found anything obvious that could have fixed this;
I don't think we need to do a bisection, having the test case should
be enough.

[Bug tree-optimization/97812] [9/10/11 Regression] Wrong output when compiling the testcase with -O2 -flto since r9-4558-g476a31b55b5471262

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

   Keywords|lto |
  Component|lto |tree-optimization
   Priority|P3  |P2

--- Comment #11 from Richard Biener  ---
With -fdisable-tree-evrp it also doesn't need -flto.  testing patch.

[Bug objc/77404] Add Wobjc-root-class

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

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

commit r11-4969-g3fe07cdec8c79bce53ea5aeb8e607df6eb5c8c2c
Author: Iain Sandoe 
Date:   Sun Oct 25 07:49:16 2020 +

C-family, Objective-C [1/3] : Implement Wobjc-root-class [PR77404].

This warning catches the case that the user has left the
superclass specification from a class interface.  Root
classes are, of course, permitted and an attribute is added
to mark these so that the diagnostic is suppressed.

The warning and attribute spellings have been kept in sync
with the language reference implementation (clang).

The diagnostic location information present in the objective-c
interface and class definitions is relatively poor.  This patch
adds a location for the class name to the interface and makes use
of it in existing warnings.

Part 1 is the changes to code and added tests.

Many entries in the testsuite make use of root classes so
there are a large number of mechanical changes there adding
"-Wno-objc-root-class" to the options.

The test changes are parts 2 (objective-c) and 3 (objective-c++)
in the patch series.

gcc/c-family/ChangeLog:

PR objc/77404
* c-attribs.c (handle_objc_root_class_attribute): New
* c-objc.h (objc_start_class_interface): Add a location
value for the position of the class name.
* c.opt: Add Wobjc-root-class.
* stub-objc.c (objc_start_class_interface): Add a location
value for the position of the class name.

gcc/c/ChangeLog:

PR objc/77404
* c-parser.c (c_parser_objc_class_definition): Pass the
location of the class name to the interface declaration.

gcc/cp/ChangeLog:

PR objc/77404
* parser.c (cp_parser_objc_class_interface): Pass the
location of the class name to the interface declaration.

gcc/objc/ChangeLog:

PR objc/77404
* objc-act.c (objc_start_class_interface): Accept the location
of the class name, use it in existing diagnostic.
(start_class): Accept obj_root_class type attributes.  Warn when
the interface for an implementation does not contain a super
class (unless the diagnostic is suppressed by the the command
line flag or the objc_root_class type attribute).

gcc/testsuite/ChangeLog:

PR objc/77404
* objc.dg/attributes/root-class-01.m: New test.
* objc.dg/root-class-00.m: New test.
* obj-c++.dg/attributes/root-class-01.mm: New test.
* obj-c++.dg/root-class-00.mm: New test.

gcc/ChangeLog:

PR objc/77404
* doc/extend.texi: Document the objc_root_class attribute.
* doc/invoke.texi: Document -Wobjc-root-class.

[Bug objc/77404] Add Wobjc-root-class

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:64f191b152cb1df0e108a91880cb415e413bad56

commit r11-4971-g64f191b152cb1df0e108a91880cb415e413bad56
Author: Iain Sandoe 
Date:   Sun Oct 25 09:54:21 2020 +

Objective-C [3/3] : Implement Wobjc-root-class [PR77404].

Add Wno-objc-root-class where needed to the objective-c++
tests.

gcc/testsuite/ChangeLog:

PR objc/77404
* obj-c++.dg/attributes/class-attribute-1.mm:
Add Wno-objc-root-class.
* obj-c++.dg/attributes/class-attribute-2.mm: Likewise.
* obj-c++.dg/attributes/class-attribute-3.mm: Likewise.
* obj-c++.dg/attributes/method-deprecated-1.mm: Likewise.
* obj-c++.dg/attributes/method-deprecated-2.mm: Likewise.
* obj-c++.dg/attributes/method-deprecated-3.mm: Likewise.
* obj-c++.dg/attributes/method-format-1.mm: Likewise.
* obj-c++.dg/attributes/method-nonnull-1.mm: Likewise.
* obj-c++.dg/attributes/method-noreturn-1.mm: Likewise.
* obj-c++.dg/attributes/method-sentinel-1.mm: Likewise.
* obj-c++.dg/attributes/nsobject-01.mm: Likewise.
* obj-c++.dg/attributes/parameter-attribute-1.mm: Likewise.
* obj-c++.dg/attributes/parameter-attribute-2.mm: Likewise.
* obj-c++.dg/attributes/proto-attribute-1.mm: Likewise.
* obj-c++.dg/attributes/proto-attribute-3.mm: Likewise.
* obj-c++.dg/attributes/proto-attribute-4.mm: Likewise.
* obj-c++.dg/attributes/unused-parameter-1.mm: Likewise.
* obj-c++.dg/bad-receiver-type.mm: Likewise.
* obj-c++.dg/bitfield-3.mm: Likewise.
* obj-c++.dg/bitfield-5.mm: Likewise.
* obj-c++.dg/class-extension-1.mm: Likewise.
* obj-c++.dg/class-extension-2.mm: Likewise.
* obj-c++.dg/class-extension-3.mm: Likewise.
* obj-c++.dg/class-extension-4.mm: Likewise.
* obj-c++.dg/class-protocol-1.mm: Likewise.
* obj-c++.dg/comp-types-1.mm: Likewise.
* obj-c++.dg/comp-types-10.mm: Likewise.
* obj-c++.dg/comp-types-2.mm: Likewise.
* obj-c++.dg/comp-types-3.mm: Likewise.
* obj-c++.dg/comp-types-5.mm: Likewise.
* obj-c++.dg/comp-types-6.mm: Likewise.
* obj-c++.dg/comp-types-7.mm: Likewise.
* obj-c++.dg/comp-types-8.mm: Likewise.
* obj-c++.dg/demangle-2.mm: Likewise.
* obj-c++.dg/demangle-3.mm: Likewise.
* obj-c++.dg/duplicate-class-1.mm: Likewise.
* obj-c++.dg/encode-1-next.mm: Likewise.
* obj-c++.dg/encode-1.mm: Likewise.
* obj-c++.dg/enhanced-proto-2.mm: Likewise.
* obj-c++.dg/exceptions-1.mm: Likewise.
* obj-c++.dg/exceptions-3.mm: Likewise.
* obj-c++.dg/exceptions-4.mm: Likewise.
* obj-c++.dg/exceptions-5.mm: Likewise.
* obj-c++.dg/extern-c-1.mm: Likewise.
* obj-c++.dg/fobjc-std-1.mm: Likewise.
* obj-c++.dg/gnu-api-2-class-meta.mm: Likewise.
* obj-c++.dg/gnu-api-2-class.mm: Likewise.
* obj-c++.dg/gnu-api-2-ivar.mm: Likewise.
* obj-c++.dg/gnu-api-2-method.mm: Likewise.
* obj-c++.dg/gnu-api-2-objc.mm: Likewise.
* obj-c++.dg/gnu-api-2-objc_msg_lookup.mm: Likewise.
* obj-c++.dg/gnu-api-2-object.mm: Likewise.
* obj-c++.dg/gnu-api-2-property.mm: Likewise.
* obj-c++.dg/gnu-api-2-protocol.mm: Likewise.
* obj-c++.dg/gnu-api-2-resolve-method.mm: Likewise.
* obj-c++.dg/gnu-api-2-sel.mm: Likewise.
* obj-c++.dg/invalid-method-2.mm: Likewise.
* obj-c++.dg/ivar-invalid-type-1.mm: Likewise.
* obj-c++.dg/ivar-problem-1.mm: Likewise.
* obj-c++.dg/lto/lto.exp: Likewise.
* obj-c++.dg/lto/trivial-1_0.mm: Likewise.
* obj-c++.dg/method-1.mm: Likewise.
* obj-c++.dg/method-12.mm: Likewise.
* obj-c++.dg/method-18.mm: Likewise.
* obj-c++.dg/method-19.mm: Likewise.
* obj-c++.dg/method-20.mm: Likewise.
* obj-c++.dg/method-3.mm: Likewise.
* obj-c++.dg/method-4.mm: Likewise.
* obj-c++.dg/method-5.mm: Likewise.
* obj-c++.dg/method-8.mm: Likewise.
* obj-c++.dg/method-9.mm: Likewise.
* obj-c++.dg/method-namespace-1.mm: Likewise.
* obj-c++.dg/plugin/diagnostic-test-expressions-1.mm:
Likewise.
* obj-c++.dg/pr23709.mm: Likewise.
* obj-c++.dg/pragma-2.mm: Likewise.
* obj-c++.dg/private-1.mm: Likewise.
* obj-c++.dg/private-2.mm: Likewise.
* obj-c++.dg/property/property.exp: Likewise.
* obj-c++.d

[Bug objc/77404] Add Wobjc-root-class

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

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

commit r11-4970-gd35fbf7f7673b5c72ee61720f1a209d4e798152f
Author: Iain Sandoe 
Date:   Thu Nov 12 13:11:11 2020 +

Objective-C [2/3] : Implement Wobjc-root-class [PR77404].

Add "Wno-objc-root-class" to tests in the Objective-C suite where
needed.

gcc/testsuite/ChangeLog:

PR objc/77404
* objc.dg/anon-1.m: Add Wno-objc-root-class.
* objc.dg/attributes/class-attribute-1.m: Likewise.
* objc.dg/attributes/class-attribute-2.m: Likewise.
* objc.dg/attributes/class-attribute-3.m: Likewise.
* objc.dg/attributes/method-deprecated-1.m: Likewise.
* objc.dg/attributes/method-deprecated-2.m: Likewise.
* objc.dg/attributes/method-deprecated-3.m: Likewise.
* objc.dg/attributes/method-format-1.m: Likewise.
* objc.dg/attributes/method-nonnull-1.m: Likewise.
* objc.dg/attributes/method-noreturn-1.m: Likewise.
* objc.dg/attributes/method-sentinel-1.m: Likewise.
* objc.dg/attributes/nsobject-01.m: Likewise.
* objc.dg/attributes/objc-exception-1.m: Likewise.
* objc.dg/attributes/parameter-attribute-1.m: Likewise.
* objc.dg/attributes/parameter-attribute-2.m: Likewise.
* objc.dg/attributes/proto-attribute-1.m: Likewise.
* objc.dg/attributes/proto-attribute-2.m: Likewise.
* objc.dg/attributes/proto-attribute-3.m: Likewise.
* objc.dg/attributes/proto-attribute-4.m: Likewise.
* objc.dg/bitfield-2.m: Likewise.
* objc.dg/break-in-ifstmt.m: Likewise.
* objc.dg/class-1.m: Likewise.
* objc.dg/class-extension-1.m: Likewise.
* objc.dg/class-extension-2.m: Likewise.
* objc.dg/class-extension-3.m: Likewise.
* objc.dg/class-extension-4.m: Likewise.
* objc.dg/class-protocol-1.m: Likewise.
* objc.dg/comp-types-7.m: Likewise.
* objc.dg/demangle-1.m: Likewise.
* objc.dg/duplicate-class-1.m: Likewise.
* objc.dg/encode-6-next.m: Likewise.
* objc.dg/encode-6.m: Likewise.
* objc.dg/enhanced-proto-2.m: Likewise.
* objc.dg/exceptions-1.m: Likewise.
* objc.dg/exceptions-3.m: Likewise.
* objc.dg/exceptions-4.m: Likewise.
* objc.dg/exceptions-5.m: Likewise.
* objc.dg/fobjc-std-1.m: Likewise.
* objc.dg/foreach-2.m: Likewise.
* objc.dg/foreach-4.m: Likewise.
* objc.dg/foreach-5.m: Likewise.
* objc.dg/fsyntax-only.m: Likewise.
* objc.dg/gnu-api-2-class-meta.m: Likewise.
* objc.dg/gnu-api-2-class.m: Likewise.
* objc.dg/gnu-api-2-ivar.m: Likewise.
* objc.dg/gnu-api-2-method.m: Likewise.
* objc.dg/gnu-api-2-objc.m: Likewise.
* objc.dg/gnu-api-2-objc_msg_lookup.m: Likewise.
* objc.dg/gnu-api-2-object.m: Likewise.
* objc.dg/gnu-api-2-property.m: Likewise.
* objc.dg/gnu-api-2-protocol.m: Likewise.
* objc.dg/gnu-api-2-resolve-method.m: Likewise.
* objc.dg/gnu-api-2-sel.m: Likewise.
* objc.dg/incomplete-type-1.m: Likewise.
* objc.dg/instancetype-0.m: Likewise.
* objc.dg/invalid-method-2.m: Likewise.
* objc.dg/ivar-invalid-type-1.m: Likewise.
* objc.dg/ivar-problem-1.m: Likewise.
* objc.dg/ivar-scope-1.m: Likewise.
* objc.dg/ivar-scope-2.m: Likewise.
* objc.dg/ivar-scope-4.m: Likewise.
* objc.dg/ivar-visibility-1.m: Likewise.
* objc.dg/ivar-visibility-2.m: Likewise.
* objc.dg/ivar-visibility-3.m: Likewise.
* objc.dg/ivar-visibility-4.m: Likewise.
* objc.dg/local-decl-1.m: Likewise.
* objc.dg/lto/lto.exp: Likewise.
* objc.dg/lto/trivial-1_0.m: Likewise.
* objc.dg/method-1.m: Likewise.
* objc.dg/method-12.m: Likewise.
* objc.dg/method-13.m: Likewise.
* objc.dg/method-14.m: Likewise.
* objc.dg/missing-proto-3.m: Likewise.
* objc.dg/next-runtime-1.m: Likewise.
* objc.dg/objc-foreach-1.m: Likewise.
* objc.dg/objc-foreach-2.m: Likewise.
* objc.dg/objc-foreach-3.m: Likewise.
* objc.dg/objc-nofilename-1.m: Likewise.
* objc.dg/param-1.m: Likewise.
* objc.dg/pch/pch.exp: Likewise.
* objc.dg/plugin/diagnostic-test-expressions-1.m: Likewise.
* objc.dg/pr23709.m: Likewise.
* objc.dg/private-1.m: Likewise.
* objc.dg/private-2.m: Likewise.
* 

[Bug objc/90707] GNU Objective C (C++) does not support nullability syntax.

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Iain D Sandoe :

https://gcc.gnu.org/g:5e28fca09c9c72bf5631efd0f0b06d52b0ebdb4d

commit r11-4972-g5e28fca09c9c72bf5631efd0f0b06d52b0ebdb4d
Author: Iain Sandoe 
Date:   Sun Oct 25 19:33:07 2020 +

C-Family, Objective-C : Implement Objective-C nullability Part 1[PR90707].

This part of the implementation covers property nullability attributes
and includes the changes to common code. Follow-on changes will be needed
to cover Objective-C method definitions, but those are expected to be
local to the Objective-C front end.

The basis of the implementation is to translate the Objective-C-specific
keywords into an attribute (objc_nullability) which has the required
states to carry the attribute markup.

We introduce the keywords, and these are parsed and validated in the same
manner as other property attributes.  The resulting value is attached to
the property as an objc_nullability attribute.

gcc/c-family/ChangeLog:

PR objc/90707
* c-common.c (c_common_reswords): null_unspecified, nullable,
nonnull, null_resettable: New keywords.
* c-common.h (enum rid): RID_NULL_UNSPECIFIED, RID_NULLABLE,
RID_NONNULL, RID_NULL_RESETTABLE: New.
(OBJC_IS_PATTR_KEYWORD): Include nullability keywords in the
ranges accepted for property attributes.
* c-attribs.c (handle_objc_nullability_attribute): New.
* c-objc.h (enum objc_property_attribute_group): Add
OBJC_PROPATTR_GROUP_NULLABLE.
(enum objc_property_attribute_kind):Add
OBJC_PROPERTY_ATTR_NULL_UNSPECIFIED, OBJC_PROPERTY_ATTR_NULLABLE,
OBJC_PROPERTY_ATTR_NONNULL, OBJC_PROPERTY_ATTR_NULL_RESETTABLE.

gcc/objc/ChangeLog:

PR objc/90707
* objc-act.c (objc_prop_attr_kind_for_rid): Handle nullability.
(objc_add_property_declaration): Handle nullability attributes.
Check that these are applicable to the property type.
* objc-act.h (enum objc_property_nullability): New.

gcc/testsuite/ChangeLog:

PR objc/90707
* obj-c++.dg/property/at-property-4.mm: Add basic nullability
tests.
* objc.dg/property/at-property-4.m: Likewise.
* obj-c++.dg/attributes/nullability-00.mm: New test.
* obj-c++.dg/property/nullability-00.mm: New test.
* objc.dg/attributes/nullability-00.m: New test.
* objc.dg/property/nullability-00.m: New test.

gcc/ChangeLog:

PR objc/90707
* doc/extend.texi: Document the objc_nullability attribute.

[Bug objc/77404] Add Wobjc-root-class

[iains at gcc dot gnu.org via Gcc-bugs]

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #10 from Iain Sandoe  ---
..

[Bug objc/77404] Add Wobjc-root-class

[iains at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Iain Sandoe  ---
fixed for GCC-11

[Bug c++/87403] [Meta-bug] Issues that suggest a new warning

[iains at gcc dot gnu.org via Gcc-bugs]

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

Bug 77404 Summary: Add Wobjc-root-class
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77404

   What|Removed |Added

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

[Bug fortran/97799] [10/11 Regression] Passing CHARACTER*(*) var(*) through ENTRY causes segfaults

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
Trunk bisection shows this started with
r11-271-g892c7427ee234c04852e90d9ce32913a429adf9d
and went away with r11-2923-gcb3c3d63315ceb4dc262e5efb83b42c73c43387d

[Bug fortran/97799] [10/11 Regression] Passing CHARACTER*(*) var(*) through ENTRY causes segfaults

[jakub at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #14 from Jakub Jelinek  ---
So dup of https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94672#c12 ?

[Bug tree-optimization/97812] [9/10/11 Regression] Wrong output when compiling the testcase with -O2 -flto since r9-4558-g476a31b55b5471262

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Richard Biener :

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

commit r11-4976-gdcfd302a79a5e2ea3bb16fc4fc45a5ee31cc0eab
Author: Richard Biener 
Date:   Fri Nov 13 11:31:22 2020 +0100

tree-optimization/97812 - fix range query in VRP assert discovery

This makes sure to properly extend the input range before seeing
whether it fits the target.

2020-11-13  Richard Biener  

PR tree-optimization/97812
* tree-vrp.c (register_edge_assert_for_2): Extend the range
according to its sign before seeing whether it fits.

* gcc.dg/torture/pr97812.c: New testcase.

[Bug tree-optimization/97812] [9/10 Regression] Wrong output when compiling the testcase with -O2 -flto since r9-4558-g476a31b55b5471262

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

Richard Biener  changed:

   What|Removed |Added

  Known to fail||10.2.0
  Known to work||11.0
Summary|[9/10/11 Regression] Wrong  |[9/10 Regression] Wrong
   |output when compiling the   |output when compiling the
   |testcase with -O2 -flto |testcase with -O2 -flto
   |since   |since
   |r9-4558-g476a31b55b5471262  |r9-4558-g476a31b55b5471262

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

[Bug target/97815] New: QNX should use thread_file=posix instead of defining THREAD_MODEL_SPEC

[redi at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97815
   Summary: QNX should use thread_file=posix instead of defining
THREAD_MODEL_SPEC
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
CC: mdaniels at qnx dot com
Blocks: 63287
  Target Milestone: ---
Target: i?86-*-nto-qnx*

gcc/config/i386/nto.h has:

#undef THREAD_MODEL_SPEC
#define THREAD_MODEL_SPEC "posix"

It's unnecessary to use the spec hook for this, as there's only a single value.

I think this is the right way to do it (untested):

diff --git a/gcc/config.gcc b/gcc/config.gcc
index 15318b20ce03..5a8c8cbebd72 100644
--- a/gcc/config.gcc
+++ b/gcc/config.gcc
@@ -2018,6 +2018,7 @@ i[34567]86-*-lynxos*)
 i[34567]86-*-nto-qnx*)
tm_file="${tm_file} i386/att.h dbxelf.h tm-dwarf2.h elfos.h i386/unix.h
i386/nto.h"
extra_options="${extra_options} i386/nto.opt"
+   thread_file=posix
gnu_ld=yes
gas=yes
;;
diff --git a/gcc/config/i386/nto.h b/gcc/config/i386/nto.h
index c09c2b17fc05..2335d38ce9f0 100644
--- a/gcc/config/i386/nto.h
+++ b/gcc/config/i386/nto.h
@@ -36,9 +36,6 @@ along with GCC; see the file COPYING3.  If not see
 }  \
   while (0)

-#undef THREAD_MODEL_SPEC
-#define THREAD_MODEL_SPEC "posix"
-
 #ifdef CROSS_DIRECTORY_STRUCTURE
 #define SYSROOT_SUFFIX_SPEC "x86"
 #endif


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63287
[Bug 63287] __STDCPP_THREADS__ is not defined

[Bug ipa/97816] New: [11 Regression] ICE in good_cloning_opportunity_p, at ipa-cp.c:3266 since r11-4949-gb86aedb0cc083efe712e530a723f1237051a6b56

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Bug ID: 97816
   Summary: [11 Regression] ICE in good_cloning_opportunity_p, at
ipa-cp.c:3266 since
r11-4949-gb86aedb0cc083efe712e530a723f1237051a6b56
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: marxin at gcc dot gnu.org
CC: jamborm at gcc dot gnu.org, marxin at gcc dot gnu.org
  Target Milestone: ---

Created attachment 49554
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49554&action=edit
test-case

It's reduced from gcc SPEC2017 test:

$ gcc -std=c99 -O3 -flto=1 -march=znver1 -g -fprofile-generate -fgnu89-inline
-shared -fPIC reduced/*.
...
during IPA pass: cp
lto1: internal compiler error: in good_cloning_opportunity_p, at ipa-cp.c:3266
0x22cc3b2 good_cloning_opportunity_p
/home/marxin/Programming/gcc/gcc/ipa-cp.c:3266
0x22d331a decide_about_value
/home/marxin/Programming/gcc/gcc/ipa-cp.c:5502
0x22d1cc4 decide_whether_version_node
/home/marxin/Programming/gcc/gcc/ipa-cp.c:5573
0x22d25b9 ipcp_decision_stage
/home/marxin/Programming/gcc/gcc/ipa-cp.c:5754
0x22d2e53 ipcp_driver
/home/marxin/Programming/gcc/gcc/ipa-cp.c:5942
0x22d3014 execute
/home/marxin/Programming/gcc/gcc/ipa-cp.c:6017

I'm reducing that more, but it goes very slowly.

[Bug ipa/97816] [11 Regression] ICE in good_cloning_opportunity_p, at ipa-cp.c:3266 since r11-4949-gb86aedb0cc083efe712e530a723f1237051a6b56

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

   Last reconfirmed||2020-11-13
 Blocks||26163
   Target Milestone|--- |11.0
 Status|UNCONFIRMED |NEW
  Known to work||10.2.0
 Ever confirmed|0   |1
   Priority|P3  |P1
  Known to fail||11.0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26163
[Bug 26163] [meta-bug] missed optimization in SPEC (2k17, 2k and 2k6 and 95)

[Bug ipa/97816] [11 Regression] ICE in good_cloning_opportunity_p, at ipa-cp.c:3266 since r11-4949-gb86aedb0cc083efe712e530a723f1237051a6b56

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Martin Liška  ---
Apparently, without the '-fPIC' option.

[Bug ipa/97816] [11 Regression] ICE in good_cloning_opportunity_p, at ipa-cp.c:3266 since r11-4949-gb86aedb0cc083efe712e530a723f1237051a6b56

[marxin at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Martin Liška  ---
size_cost: -2147480169

So it's likely about an integer overflow..

[Bug c++/63287] __STDCPP_THREADS__ is not defined

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

   See Also||https://bugs.llvm.org/show_
   ||bug.cgi?id=33230

--- Comment #5 from Jonathan Wakely  ---
FWIW libc++ does it in the library:

#if !defined(_LIBCPP_HAS_NO_THREADS) && !defined(__STDCPP_THREADS__)
#define __STDCPP_THREADS__ 1
#endif

[Bug ada/97805] [11 Regression] adaint.c:1488:12: note: 'LLONG_MIN' is defined in header ''; did you forget to '#include '?

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

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

Eric Botcazou  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2020-11-13
 CC||ebotcazou at gcc dot gnu.org
 Ever confirmed|0   |1
   Target Milestone|--- |11.0

--- Comment #1 from Eric Botcazou  ---
Obviously.

[Bug ada/97805] [11 Regression] adaint.c:1488:12: note: 'LLONG_MIN' is defined in header ''; did you forget to '#include '?

[ebotcazou at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Eric Botcazou  ---
Created attachment 49555
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49555&action=edit
Tentative fix

Please give it a try when you get a chance.

[Bug ipa/97816] [11 Regression] ICE in good_cloning_opportunity_p, at ipa-cp.c:3266 since r11-4949-gb86aedb0cc083efe712e530a723f1237051a6b56

[jamborm at gcc dot gnu.org via Gcc-bugs]

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Jambor  ---
I see, mine.

[Bug libstdc++/96042] Reference type of std::ranges::iota is __int128 with -std=c++2a?!

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:12042aeb9336f20b9225b2e5139e5f6c9bde7642

commit r10-9021-g12042aeb9336f20b9225b2e5139e5f6c9bde7642
Author: Jonathan Wakely 
Date:   Fri Nov 13 13:04:10 2020 +

libstdc++: Fix test that fails for targets without __int128 [PR 96042]

When backporting this test (and the changes it depends on) I forgot that
the __max_diff_type and __max_size_type classes are only present on
trunk, not the gcc-10 branch. That using iota_view
oonly works correctly when __int128 is available, so the test fails on
32-bit targets.

This just skips the failing check.

PR libstdc++/96042
* testsuite/std/ranges/iota/96042.cc: Only assert that the
difference type is wider than long long if __int128 is
supported.

[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #18 from Jonathan Wakely  ---
The patch will apply cleanly to gcc-10 but not gcc-9. Let me know if you want
me to prepare a patch for the gcc-9 branch.

[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

[jozefl at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #19 from jozefl at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #18)
> The patch will apply cleanly to gcc-10 but not gcc-9. Let me know if you
> want me to prepare a patch for the gcc-9 branch.

If it's not too much work, it would be great if you could. I'm actually just
finalizing the MSP430-GCC release that TI will distribute, and it's the last
one based off GCC 9, and the last one to be released for a while, so getting it
in there would be great.

Let me know if I can help, thanks.

[Bug d/97644] FAIL: gdc.dg/gdc204.d due to ICE in finish_thunk

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Iain Buclaw :

https://gcc.gnu.org/g:5d4b824faf1e5846ec684a74f93912cf347928df

commit r11-4979-g5d4b824faf1e5846ec684a74f93912cf347928df
Author: Iain Buclaw 
Date:   Thu Nov 12 15:37:46 2020 +0100

d: Fix ICE in finish_thunk (PR97644)

Because this what the upstream reference compiler did, thunks for the D
front-end were associated with the class definition, so were forced
code-gen even if the target function was extern.  This has now been
changed so there are now only generated if there is a function
definition, fixing the ICE that occurred in PR 97644, which was caused
by calling expand_thunk() early.

gcc/d/ChangeLog:

PR d/97644
* dmd/MERGE: Merge upstream dmd 95044d8e4.
* d-target.cc (TargetCPP::thunkMangle): New function.
* decl.cc (finish_thunk): Don't force expand thunks for external
functions.
(make_thunk): Emit thunks only if the function has a definition.
Generate correct mangling for thunks to C++ classes.

gcc/testsuite/ChangeLog:

* gdc.dg/pr92216.d: Update scan-assember.

[Bug d/97644] FAIL: gdc.dg/gdc204.d due to ICE in finish_thunk

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #13 from Iain Buclaw  ---
Marking as fixed.

[Bug ipa/96734] gcc 10.2.0 fails to compile on mips64 due to crash in IPA SRA pass

[ncopa at alpinelinux dot org via Gcc-bugs]

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

Natanael Copa  changed:

   What|Removed |Added

 CC||ncopa at alpinelinux dot org

--- Comment #7 from Natanael Copa  ---
I was able to reproduce using latest commit from gcc 10 branch:

/home/ncopa/aports/main/gcc/src/build/./prev-gcc/xg++
-B/home/ncopa/aports/main/gcc/src/build/./prev-gcc/
-B/usr/mips64-alpine-linux-musl/bin/ -nostdinc++
-B/home/ncopa/aports/main/gcc/src/build/prev-mips64-alpine-linux-musl/libstdc++-v3/src/.libs
-B/home/ncopa/aports/main/gcc/src/build/prev-mips64-alpine-linux-musl/libstdc++-v3/libsupc++/.libs

-I/home/ncopa/aports/main/gcc/src/build/prev-mips64-alpine-linux-musl/libstdc++-v3/include/mips64-alpine-linux-musl

-I/home/ncopa/aports/main/gcc/src/build/prev-mips64-alpine-linux-musl/libstdc++-v3/include
 -I/home/ncopa/aports/main/gcc/src/gcc-10.2.1/libstdc++-v3/libsupc++
-L/home/ncopa/aports/main/gcc/src/build/prev-mips64-alpine-linux-musl/libstdc++-v3/src/.libs
-L/home/ncopa/aports/main/gcc/src/build/prev-mips64-alpine-linux-musl/libstdc++-v3/libsupc++/.libs
-fno-PIE -c  -DIN_GCC_FRONTEND -g -O2 -fno-checking -gtoggle  -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall -Wno-narrowing
-Wwrite-strings -Wcast-qual -Wno-error=format-diag -Wmissing-format-attribute
-Woverloaded-virtual -pedantic -Wno-long-long -Wno-variadic-macros
-Wno-overlength-strings   -DHAVE_CONFIG_H -I. -Icp
-I/home/ncopa/aports/main/gcc/src/gcc-10.2.1/gcc
-I/home/ncopa/aports/main/gcc/src/gcc-10.2.1/gcc/cp
-I/home/ncopa/aports/main/gcc/src/gcc-10.2.1/gcc/../include
-I/home/ncopa/aports/main/gcc/src/gcc-10.2.1/gcc/../libcpp/include 
-I/home/ncopa/aports/main/gcc/src/gcc-10.2.1/gcc/../libdecnumber
-I/home/ncopa/aports/main/gcc/src/gcc-10.2.1/gcc/../libdecnumber/dpd
-I../libdecnumber
-I/home/ncopa/aports/main/gcc/src/gcc-10.2.1/gcc/../libbacktrace  -Os
-fomit-frame-pointer -o cp/method.o -MT cp/method.o -MMD -MP -MF
cp/.deps/method.TPo /home/ncopa/aports/main/gcc/src/gcc-10.2.1/gcc/cp/method.c
during IPA pass: sra
In file included from
/home/ncopa/aports/main/gcc/src/gcc-10.2.1/gcc/cp/method.c:3199:
./gt-cp-method.h:36:2: internal compiler error: Segmentation fault
   36 | };
  |  ^
0x120807513 crash_signal
/home/ncopa/aports/main/gcc/src/gcc-10.2.1/gcc/toplev.c:328
0x1204210f5 cgraph_edge::redirect_callee(cgraph_node*)
/home/ncopa/aports/main/gcc/src/gcc-10.2.1/gcc/cgraph.c:1374
0x1204340c3 cgraph_edge::redirect_callee_duplicating_thunks(cgraph_node*)
/home/ncopa/aports/main/gcc/src/gcc-10.2.1/gcc/cgraphclones.c:262
0x120434557 cgraph_node::create_clone(tree_node*, profile_count, bool,
vec, bool, cgraph_node*, ipa_param_adjustments*,
char const*)
/home/ncopa/aports/main/gcc/src/gcc-10.2.1/gcc/cgraphclones.c:427
0x12043497b cgraph_node::create_virtual_clone(vec, vec*, ipa_param_adjustments*, char
const*, unsigned int)
/home/ncopa/aports/main/gcc/src/gcc-10.2.1/gcc/cgraphclones.c:613
0x1205ee357 process_isra_node_results
/home/ncopa/aports/main/gcc/src/gcc-10.2.1/gcc/ipa-sra.c:3811
0x1205ee357 ipa_sra_analysis
/home/ncopa/aports/main/gcc/src/gcc-10.2.1/gcc/ipa-sra.c:4047
0x1205ee357 execute
/home/ncopa/aports/main/gcc/src/gcc-10.2.1/gcc/ipa-sra.c:4099
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.
make: *** [Makefile:1117: cp/method.o] Error 1

Withs some help from Ariadne we figured out that

 it passes with -O1
 it fails with -O2 (or -Os)
 it fails with -O1 -fipa-sra -fpartial-inlining
 it fails with -Og -fipa-sra -fpartial-inlining
 it passes with -Og -fipa-sra
 it passes with -Og -fpartial-inlining
 it passes with -O2  and either -fnoipa-sra or -fnopartial-inlining
 it passes with -fipa-sra -fpartial-inlining


So it seems that it is some -Og optimization in combination with -fipa-sra
-fpartial-inlining triggers it. I have not been able to pinpoint any of the
documented -O1 or -Og optimization flags.

It fails with:
-Og -fipa-sra -fpartial-inlining  -fno-combine-stack-adjustments
-fno-compare-elim -fno-cprop-registers -fno-defer-pop -fno-ipa-profile
-fno-ipa-pure-const -fno-ipa-reference -fno-ipa-reference-addressable
-fno-merge-constants -fno-omit-frame-pointer -fno-reorder-blocks
-fno-shrink-wrap -fno-split-wide-types -fno-tree-builtin-call-dce -fno-tree-ccp
-fno-tree-ch -fno-tree-coalesce-vars -fno-tree-copy-prop -fno-tree-dce
-fno-tree-dominator-opts -fno-tree-fre -fno-tree-sink -fno-tree-slsr
-fno-tree-ter

[Bug libstdc++/97273] [8/9 Regression] Strange behaviour of unordered_set when vector is included (i686)

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r9-9043-g9df05884b3a30d32744a070d3fc5780b7323231a
Author: Patrick Palka 
Date:   Wed Oct 7 10:49:00 2020 -0400

c++: Distinguish alignof and __alignof__ in cp_tree_equal [PR97273]

cp_tree_equal currently considers alignof the same as __alignof__, but
these operators are semantically different ever since r8-7957.  In the
testcase below, this causes the second static_assert to fail on targets
where alignof(double) != __alignof__(double) because the specialization
table (which uses cp_tree_equal as its equality predicate) conflates the
two dependent specializations integral_constant<__alignof__(T)> and
integral_constant.

This patch makes cp_tree_equal distinguish between these two operators
by inspecting the ALIGNOF_EXPR_STD_P flag.

gcc/cp/ChangeLog:

PR c++/88115
PR libstdc++/97273
* tree.c (cp_tree_equal) : Return false if
ALIGNOF_EXPR_STD_P differ.

gcc/testsuite/ChangeLog:

PR c++/88115
PR libstdc++/97273
* g++.dg/template/alignof3.C: New test.

(cherry picked from commit 592fe221735bdaa375b1834dd49ce125d0b600d8)

[Bug c++/88115] Incorrect result from alignof in templates, if also using __alignof__.

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r9-9043-g9df05884b3a30d32744a070d3fc5780b7323231a
Author: Patrick Palka 
Date:   Wed Oct 7 10:49:00 2020 -0400

c++: Distinguish alignof and __alignof__ in cp_tree_equal [PR97273]

cp_tree_equal currently considers alignof the same as __alignof__, but
these operators are semantically different ever since r8-7957.  In the
testcase below, this causes the second static_assert to fail on targets
where alignof(double) != __alignof__(double) because the specialization
table (which uses cp_tree_equal as its equality predicate) conflates the
two dependent specializations integral_constant<__alignof__(T)> and
integral_constant.

This patch makes cp_tree_equal distinguish between these two operators
by inspecting the ALIGNOF_EXPR_STD_P flag.

gcc/cp/ChangeLog:

PR c++/88115
PR libstdc++/97273
* tree.c (cp_tree_equal) : Return false if
ALIGNOF_EXPR_STD_P differ.

gcc/testsuite/ChangeLog:

PR c++/88115
PR libstdc++/97273
* g++.dg/template/alignof3.C: New test.

(cherry picked from commit 592fe221735bdaa375b1834dd49ce125d0b600d8)

[Bug tree-optimization/94406] 503.bwaves_r is 11% slower on Zen2 CPUs than GCC 9 with -Ofast -march=native

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

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

commit r11-4983-gac91af71c93462cbc701bbd104fa21894bb15e86
Author: Martin Jambor 
Date:   Fri Nov 13 15:35:18 2020 +0100

loops: Invoke lim after successful loop interchange

This patch makes the entry point to loop invariant motion public, so
that it can be called after loop interchange when that pass has
swapped loops.  This avoids the non-LTO -Ofast run-time regressions of
410.bwaves and 503.bwaves_r (which are 19% and 15% faster than current
master on an AMD zen2 machine) while not introducing a full LIM pass
into the pass pipeline.

The patch also adds a parameter which allows not to perform any store
motion so that it is not done after an interchange.

gcc/ChangeLog:

2020-11-12  Martin Jambor  

PR tree-optimization/94406
* tree-ssa-loop-im.c (tree_ssa_lim): Renamed to
loop_invariant_motion_in_fun, added a parameter to control store
motion.
(pass_lim::execute): Adjust call to tree_ssa_lim, now
loop_invariant_motion_in_fun.
* tree-ssa-loop-manip.h (loop_invariant_motion_in_fun): Declare.
* gimple-loop-interchange.cc (pass_linterchange::execute): Call
loop_invariant_motion_in_fun if any interchange has been done.

[Bug rtl-optimization/69609] block reordering consumes an inordinate amount of time, REE consumes much memory

[rguenth at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #16 from Richard Biener  ---
current HEAD with -O2 -fno-checking (a checking enabled build) shows

 callgraph ipa passes   :   6.80 ( 14%)   0.19 ( 12%)   7.00 ( 14%)
   33M (  5%)
 tree FRE   :   6.55 ( 13%)   0.05 (  3%)   6.58 ( 13%)
 4146k (  1%)
 PRE:  13.08 ( 26%)   0.04 (  3%)  13.12 ( 26%)
   13k (  0%)
 machine dep reorg  :   4.63 (  9%)   0.00 (  0%)   4.62 (  9%)
0  (  0%)
 TOTAL  :  49.61  1.55 51.18   
  706M

I looked at the tree FRE time and improved PHI hashing a bit but we still
spend a lot of time in processing PHIs.

[Bug c++/78655] gcc doesn't exploit the fact that the result of pointer addition can not be nullptr

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #9 from Andrew Macleod  ---
Created attachment 49556
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49556&action=edit
testcase

(In reply to Marc Glisse from comment #8)
> (just to put this somewhere)
> We have multiple ways of doing pointer arithmetic in gcc. After the recent
> patch, we know that g returns nonnull, but we don't know it for f.
> 
> struct A{int a,b;};
> int*f(A*p){return&p->b;}
> int*g(A*p){return(int*)p+1;}

I tweaked this and made a testcase out of it. I think it is correct?  
We do know that both f and g are non-null now, as well as checks for when
returning p->a for 0 offsets... So I think this is covered?

Furthermore,

bool f(int* a)
{
  bool x = a == nullptr;
  a += 10;
  return x;
}
turns into
a_1(D)  int * VARYING
 :
x_2 = a_1(D) == 0B;
a_3 = a_1(D) + 40;
return x_2;

a_3 : int * [1B, +INF]

And from there, I don't see any way to determine that 'a_1' can't be nullptr. 
we've lost whatever context nullptr is suppose to provide... its just a 0 now.
All we can see is that a_3 is non-null.

[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #20 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jonathan Wakely
:

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

commit r10-9022-gf9d6781ea2ef1cdfd0d6d6b649a5cb5a217a8d5e
Author: Jonathan Wakely 
Date:   Thu Nov 12 10:29:21 2020 +

libstdc++: Fix __numeric_traits_integer<__int20> [PR 97798]

The expression used to calculate the maximum value for an integer type
assumes that the number of bits in the value representation is always
sizeof(T) * CHAR_BIT. This is not true for the __int20 type on msp430,
which has only 20 bits in the value representation but 32 bits in the
object representation. This causes an integer overflow in a constant
expression, which is ill-formed.

This problem was already solved by DJ for std::numeric_limits<__int20>
by generalizing the helper macros to use a specified number of bits
instead of assuming sizeof(T) * CHAR_BIT. Then the INT_N_n types can
specify the number of bits using the __GLIBCXX_BITSIZE_INT_N_n macros
that the compiler defines.

I'm using a slightly different approach here. I've replaced the helper
macros entirely, and just expanded the calculations in the initializers
for the static data members. By reordering the data members we can reuse
__is_signed and __digits in the other initializers. This removes the
repetition of expanding __glibcxx_signed(T) and __glibcxx_digits(T)
multiple times in each initializer.

The __is_integer_nonstrict trait now defines a new constant, __width,
which is sizeof(T) * CHAR_BIT by default (defined as an enumerator so
that no storage is needed for a static data member). By specializing
__is_integer_nonstrict for the INT_N types that have padding bits, we
can provide the correct width via the __GLIBCXX_BITSIZE_INT_N_n macros.

libstdc++-v3/ChangeLog:

PR libstdc++/97798
* include/ext/numeric_traits.h (__glibcxx_signed)
(__glibcxx_digits, __glibcxx_min, __glibcxx_max): Remove
macros.
(__is_integer_nonstrict::__width): Define new constant.
(__numeric_traits_integer): Define constants in terms of each
other and __is_integer_nonstrict::__width, rather than the
removed macros.
(_GLIBCXX_INT_N_TRAITS): Macro to define explicit
specializations for non-standard integer types.

(cherry picked from commit 99f22a5ed91c7e4306b727f61c01484faf104115)

[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #21 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jonathan Wakely
:

https://gcc.gnu.org/g:62c2d527307d8adce31f5c9ca6e19e15b2866b83

commit r9-9045-g62c2d527307d8adce31f5c9ca6e19e15b2866b83
Author: Jonathan Wakely 
Date:   Thu Nov 12 10:29:21 2020 +

libstdc++: Fix __numeric_traits_integer<__int20> [PR 97798]

The expression used to calculate the maximum value for an integer type
assumes that the number of bits in the value representation is always
sizeof(T) * CHAR_BIT. This is not true for the __int20 type on msp430,
which has only 20 bits in the value representation but 32 bits in the
object representation. This causes an integer overflow in a constant
expression, which is ill-formed.

This problem was already solved by DJ for std::numeric_limits<__int20>
by generalizing the helper macros to use a specified number of bits
instead of assuming sizeof(T) * CHAR_BIT. Then the INT_N_n types can
specify the number of bits using the __GLIBCXX_BITSIZE_INT_N_n macros
that the compiler defines.

I'm using a slightly different approach here. I've replaced the helper
macros entirely, and just expanded the calculations in the initializers
for the static data members. By reordering the data members we can reuse
__is_signed and __digits in the other initializers. This removes the
repetition of expanding __glibcxx_signed(T) and __glibcxx_digits(T)
multiple times in each initializer.

The __is_integer_nonstrict trait now defines a new constant, __width,
which is sizeof(T) * CHAR_BIT by default (defined as an enumerator so
that no storage is needed for a static data member). By specializing
__is_integer_nonstrict for the INT_N types that have padding bits, we
can provide the correct width via the __GLIBCXX_BITSIZE_INT_N_n macros.

The backport for the gcc-9 branch adds the __is_integer_nonstrict trait,
which was not previously present on the branch at all.

libstdc++-v3/ChangeLog:

PR libstdc++/97798
* include/ext/numeric_traits.h (__glibcxx_signed)
(__glibcxx_digits, __glibcxx_min, __glibcxx_max): Remove
macros.
(__is_integer_nonstrict::__width): Define new constant.
(__numeric_traits_integer): Define constants in terms of each
other and __is_integer_nonstrict::__width, rather than the
removed macros.
(_GLIBCXX_INT_N_TRAITS): Macro to define explicit
specializations for non-standard integer types.

(cherry picked from commit 99f22a5ed91c7e4306b727f61c01484faf104115)

[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #22 from Jonathan Wakely  ---
I tested the patches on x86_64-linux and confirmed that the branches can
bootstrap msp430-elf, so I went ahead and pushed them.

If you're not going to release anything from the gcc-8 branch, is it OK to
leave that unfixed? If so, I think we can close this.

[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

[jozefl at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #23 from jozefl at gcc dot gnu.org ---
(In reply to Jonathan Wakely from comment #22)
> I tested the patches on x86_64-linux and confirmed that the branches can
> bootstrap msp430-elf, so I went ahead and pushed them.
> 
> If you're not going to release anything from the gcc-8 branch, is it OK to
> leave that unfixed? If so, I think we can close this.

Fine by me, thanks!

[Bug libstdc++/97798] FTB msp430-elf error: the value of '__gnu_cxx::__numeric_traits_integer<__int20>::__max' is not usable in a constant expression

[redi at gcc dot gnu.org via Gcc-bugs]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|11.0|9.4
 Status|ASSIGNED|RESOLVED

--- Comment #24 from Jonathan Wakely  ---
OK, fixed for 9.4, 10.3 and 11.

[Bug ada/97805] [11 Regression] adaint.c:1488:12: note: 'LLONG_MIN' is defined in header ''; did you forget to '#include '?

[dave.anglin at bell dot net via Gcc-bugs]

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

--- Comment #3 from dave.anglin at bell dot net ---
On 2020-11-13 7:39 a.m., ebotcazou at gcc dot gnu.org wrote:
> Please give it a try when you get a chance.
Will do.

Thanks,
Dave

[Bug other/93067] diagnostics are not aware of -finput-charset

[dmalcolm at gcc dot gnu.org via Gcc-bugs]

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

David Malcolm  changed:

   What|Removed |Added

 CC||dmalcolm at gcc dot gnu.org

--- Comment #2 from David Malcolm  ---
Did the patch ever get posted to gcc-patches?  Does it still apply cleanly?  (I
just ran into this issue and was about to file my own bug about it)

[Bug tree-optimization/79191] potentially truncating unsigned conversion defeats range propagation

[amacleod at redhat dot com via Gcc-bugs]

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

Andrew Macleod  changed:

   What|Removed |Added

 CC||amacleod at redhat dot com

--- Comment #6 from Andrew Macleod  ---
There are a couple of things going on.

VRP understands casts perfectly well.  If we were to run EVRP "earlier", we get
this fine in EVRP.
ie.  with -fno-tree-forwprop
we get
 :
  n_4 = (unsigned int) m_3(D);
  if (n_4 <= 2)
goto ; [INV]
  else
goto ; [INV]

   :
  _1 = (long unsigned int) n_4;
  if (_1 > 3)
goto ; [0.00%]
  else
goto ; [100.00%]

   [count: 0]:
  __builtin_abort ();

and that works out fine:
  :
  n_4 = (unsigned int) m_3(D);
  if (n_4 <= 2)
goto ; [INV]
  else
goto ; [INV]

   :
  _1 = (long unsigned int) n_4;

   :
  return;


With forwprop, we get the masking of the original value:
  n_4 = (unsigned int) m_3(D);
  if (n_4 <= 2)
goto ; [INV]
  else
goto ; [INV]

   :
  _7 = m_3(D) & 4294967295;
  _8 = m_3(D) & 4294967292;
  if (_8 != 0)
goto ; [0.00%]


Ranger knows the range of m_3 on entry to BB3 is:
[0, 2][4294967296, 18446744069414584322]
we cant enumerate all the ranges that have [0,2] in the lower words, or there'd
just be too many subranges.

and sadly, if that code were instead:
 _7 = m_3(D) & 4294967295;
 _8 = _7 & 4294967292;

we would again get [0,2] for a range for _8.   but no. someone thinks they are
smarter again.  Why the heck don't we do that??

Another way Ranger is going to be able to figure this out would be when we
implement bitmask tracking along with ranges. 

  n_4 = (unsigned int) m_3(D);
  if (n_4 <= 2)
goto ; [INV]
in addition to [0, 2][4294967296, 18446744069414584322]
we'd should be able to track in addition the lower bit are masked with 0x03

The final option that may eventually handle this is the new equivalency
tracking slated for next release.
It will track n_4 as a "less precision" equivalence of m_3, and when thats is
tied in with the rangers knowledge that n_4 is [0,2], it should (hopefully) be
able to recognize that  
_8 = m_3(D) & 4294967292; 
brings m_3 into the same precision as n_4 and then use the value of n_4.

but we aren't there yet.  Maybe we need an early early VRP pass.. right after
early optimizations before the IL gets mucked with too much :-P

[Bug tree-optimization/79191] potentially truncating unsigned conversion defeats range propagation

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #7 from Andrew Macleod  ---
(In reply to Andrew Macleod from comment #6)

> Ranger knows the range of m_3 on entry to BB3 is:
> [0, 2][4294967296, 18446744069414584322]
> we cant enumerate all the ranges that have [0,2] in the lower words, or
> there'd just be too many subranges.
> 
> and sadly, if that code were instead:
>  _7 = m_3(D) & 4294967295;
>  _8 = _7 & 4294967292;
> 
> we would again get [0,2] for a range for _8.   but no. someone thinks they
> are smarter again.  Why the heck don't we do that??
> 

scratch that. we still wouldn't get it. I was delusional.  we still dont know
that all the upper ranges don't fill some of those bits.. ie 0x1 thru
0x1FFF is in the range of m_3... and so we'd still fail the masking test.

only bitmask tracking or precision sensitive equivalence will capture this
case.

[Bug testsuite/97788] [11 regression] g++.dg/ubsan/pr61272.C fails after r11-4852

[marxin at gcc dot gnu.org via Gcc-bugs]

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

Martin Liška  changed:

   What|Removed |Added

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

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

[Bug testsuite/97788] [11 regression] g++.dg/ubsan/pr61272.C fails after r11-4852

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

https://gcc.gnu.org/g:2935ff7eb7ac2bb089e61078162d3d68b5745281

commit r11-4996-g2935ff7eb7ac2bb089e61078162d3d68b5745281
Author: Martin Liska 
Date:   Fri Nov 13 17:38:41 2020 +0100

testsuite: move expected error location

gcc/testsuite/ChangeLog:

PR testsuite/97788
* g++.dg/ubsan/pr61272.C: Move expected error location.

[Bug other/93067] diagnostics are not aware of -finput-charset

[lhyatt at gcc dot gnu.org via Gcc-bugs]

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

lhyatt at gcc dot gnu.org changed:

   What|Removed |Added

  Attachment #47547|0   |1
is obsolete||
 CC||lhyatt at gcc dot gnu.org

--- Comment #3 from lhyatt at gcc dot gnu.org ---
Created attachment 49557
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49557&action=edit
updated patch to apply to current master

It seems I did not pursue this beyond filing this bug report with the patch.
The patch requires some minor rebasing, just due to surrounding context, so
here is a version that applies now, and still bootstraps and works. Should I
send to gcc-patches as well?

I think the main potential issue with it is that it requires input.h / input.c
to get a global variable so that frontends can let it know they are using
libcpp to read their input. (Otherwise -finput-charset is not applicable). I am
sure there is a better way to do that, but not sure the cleanest one, none of
the routines in input.c seem to make use of a diagnostic_context or similar
thing.

-Lewis

[Bug c++/91318] [C++][PATCH] warnings about unused internal macros with -Wunused-macros and #pragma GCC optimize

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Jeff Law :

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

commit r11-4999-g6f1ae1ecd351348eb33b515c5e23778651bee028
Author: Piotr H. Dabrowski 
Date:   Fri Nov 13 12:27:16 2020 -0500

Do not warn about unused macros while processing #pragma GCC optimize

libcpp

PR c++/91318
* include/cpplib.h: Added cpp_define_unused(),
cpp_define_formatted_unused()
* directives.c: Likewise.

gcc/c-family

PR c++/91318
* c-cppbuiltin.c: c_cpp_builtins_optimize_pragma(): use
cpp_define_unused()

[Bug ipa/97816] [11 Regression] ICE in good_cloning_opportunity_p, at ipa-cp.c:3266 since r11-4949-gb86aedb0cc083efe712e530a723f1237051a6b56

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

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

commit r11-5000-g2e97d6443f0a862ce9b798084499635914e3b8c6
Author: Martin Jambor 
Date:   Fri Nov 13 18:30:11 2020 +0100

ipa-cp: One more safe_add (PR 97816)

The new behavior of safe_add triggered an ICE because of one use where
it had not been used instead of a simple addition.  I'll fix it with the
following obvious patch so that periodic benchmarkers can continue
working because a proper fix (see below) will need a review.

The testcase showed me, however, that we can propagate time and cost
from one lattice to another more than once even when that was not the
intent.  I'll address that as a follow-up after I verify it does not
affect the IPA-CP heuristics too much or change the corresponding
params accordingly.

Bootstrapped and tested on x86_64-linux.

gcc/ChangeLog:

2020-11-13  Martin Jambor  

PR ipa/97816
* ipa-cp.c (value_topo_info::propagate_effects): Use
safe_add instead of a simple addition.

[Bug c/89180] [meta-bug] bogus/missing -Wunused warnings

[law at redhat dot com via Gcc-bugs]

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

Bug 91318 Summary: [C++][PATCH] warnings about unused internal macros with 
-Wunused-macros and #pragma GCC optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91318

   What|Removed |Added

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

[Bug c++/91318] [C++][PATCH] warnings about unused internal macros with -Wunused-macros and #pragma GCC optimize

[law at redhat dot com via Gcc-bugs]

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #8 from Jeffrey A. Law  ---
Should be fixed on the trunk now.

[Bug ipa/97816] [11 Regression] ICE in good_cloning_opportunity_p, at ipa-cp.c:3266 since r11-4949-gb86aedb0cc083efe712e530a723f1237051a6b56

[jamborm at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #5 from Martin Jambor  ---
As noted in the commit message above, the ICE will go away but the underlying
issue stays so please keep this opened until I fix it, hopefully no later than
next week.

[Bug c/97817] New: -Wformat-truncation=2 elicits invalid warning

[jim at meyering dot net via Gcc-bugs]

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

Bug ID: 97817
   Summary: -Wformat-truncation=2 elicits invalid warning
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jim at meyering dot net
  Target Milestone: ---

Here's the invalid warning.
The buffer's size is obviously not 6. It is AT LEAST 6.

$ gcc -Wformat-truncation=2 -O2 -c strerror_r.c
strerror_r.c: In function ‘strerror_r’:
strerror_r.c:12:35: warning: ‘Unknown error ’ directive output truncated
writing 14 bytes into a region of size 6 [-Wformat-truncation=]
   12 | snprintf (buf, buflen, "Unknown error %d", errnum);
  | ~~^~~~
strerror_r.c:12:5: note: ‘snprintf’ output between 16 and 26 bytes into a
destination of size 6
   12 | snprintf (buf, buflen, "Unknown error %d", errnum);
  | ^~

Here's the reduced test case (from gnulib's strerror.c):

$ cat strerror_r.c
#define size_t unsigned long long
extern int snprintf (char *__restrict __s, size_t __maxlen,
 const char *__restrict __format, ...)
  __attribute__ ((__format__ (__printf__, 3, 4)));
extern int __xpg_strerror_r (int errnum, char *buf, size_t buflen);
int strerror_r (int errnum, char *buf, size_t buflen)
{
  if (buflen <= 5)
return 9;
  int ret = __xpg_strerror_r (errnum, buf, buflen);
  if (ret == 1 && !*buf)
snprintf (buf, buflen, "Unknown error %d", errnum);
  return ret;
}

[Bug c/97817] -Wformat-truncation=2 elicits invalid warning

[jim at meyering dot net via Gcc-bugs]

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

--- Comment #1 from jim at meyering dot net ---
I confirmed this happens both with the very latest built from git: gcc version
11.0.0 20201113 (experimental) (GCC), and Fedora 32's gcc version 10.2.1
20201016 (Red Hat 10.2.1-6) (GCC).

[Bug c/97817] -Wformat-truncation=2 elicits invalid warning

[schwab--- via Gcc-bugs]

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

--- Comment #2 from Andreas Schwab  ---
But when it's 6 it's truncated.

[Bug debug/97060] Missing DW_AT_declaration=1 in dwarf data

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #15 from Jason Merrill  ---
Fixed for GCC 11.  The patch will also be backported to the Red Hat GCC 10
branch that has the same bug.

[Bug c++/97388] By-value function parameter changes are rolled back prior to destructor call during constant evaluation

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
 CC||jason at gcc dot gnu.org

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

[Bug c++/91367] Implement P1099R5: using enum

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
 CC||jason at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #1 from Jason Merrill  ---
Implemented for GCC 11.

[Bug c++/88323] implement C++20 language features.

[jason at gcc dot gnu.org via Gcc-bugs]

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

Bug 91367 Summary: Implement P1099R5: using enum
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91367

   What|Removed |Added

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

[Bug c++/90537] Implement P1286R2, Contra CWG DR1778

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

   Assignee|mpolacek at gcc dot gnu.org|jason at gcc dot gnu.org
 Resolution|--- |FIXED
 Status|ASSIGNED|RESOLVED
 CC||jason at gcc dot gnu.org

--- Comment #3 from Jason Merrill  ---
Implemented in r277351.

[Bug c++/88323] implement C++20 language features.

[jason at gcc dot gnu.org via Gcc-bugs]

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

Bug 90537 Summary: Implement P1286R2, Contra CWG DR1778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90537

   What|Removed |Added

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

[Bug c++/91581] ICE on usage requiring complete class in exception-specification of defaulted method

[jason at gcc dot gnu.org via Gcc-bugs]

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

Bug 90537 Summary: Implement P1286R2, Contra CWG DR1778
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90537

   What|Removed |Added

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

[Bug c++/91370] Implement P1041R4 and P1139R2: Stronger Unicode requirements

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #2 from Jakub Jelinek  ---
Fixed for 10.1+.

[Bug c++/88323] implement C++20 language features.

[jakub at gcc dot gnu.org via Gcc-bugs]

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

Bug 91370 Summary: Implement P1041R4 and P1139R2: Stronger Unicode requirements
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91370

   What|Removed |Added

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

[Bug c++/86252] Abstract class in function return type

[jason at gcc dot gnu.org via Gcc-bugs]

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug target/97787] [10/11 regression] 64bit mips lto: .symtab local symbol at index x (>= sh_info of y)

[bunk at stusta dot de via Gcc-bugs]

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

--- Comment #7 from Adrian Bunk  ---
(In reply to Richard Biener from comment #6)
> I see.  Still GCC or GAS produces a bogus object file (the original linker
> error).  It might be the new problem is an entirely different one?  It looks
> more and more like a target problem to me.

My guess would be that the situations where -mxgot is required on 64bit MIPS
are not (no longer?) handled properly with LTO.

Note that when compiling from precompiled sources the linker also exits with an
error, the main difference in that case is that the correct "relocation
truncated to fit" error message is not output in the LTO case.

More worrisome is that adding -mxgot to compiler and linker flags did not fix
it in the LTO case.

[Bug fortran/97818] New: PDT Parameterized Derived Type fails with SIGABRT at -O1

[adamjermyn at gmail dot com via Gcc-bugs]

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

Bug ID: 97818
   Summary: PDT Parameterized Derived Type fails with SIGABRT at
-O1
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: adamjermyn at gmail dot com
  Target Milestone: ---

Created attachment 49558
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49558&action=edit
Minimal broken example. Compile with -O1. Should result in SIGABRT.

Hello,

I encountered an error (SIGABRT on macOS) using parameterized derived types in
Fortran with gfortran v10.2.0. The error only appears at -O1 or above. I've
attached a minimal broken example. An example of the error message is:

---
a.out(64288,0x116e325c0) malloc: *** error for object 0x7ffee429c8e8: pointer
being freed was not allocated
a.out(64288,0x116e325c0) malloc: *** set a breakpoint in malloc_error_break to
debug

Program received signal SIGABRT: Process abort signal.
---

The derived type supports arithmetic operations (+-/*), but for the minimal
example I've stripped this down to just addition, and removed the actual
addition logic (just leaving empty functions).

>From some testing, the error only appears when there are common
sub-expressions. So for instance in the attached example I've written


z = (x + 2.0) + ((x + 2.0) + 1.0)

which fails. When I manually break the expression up into smaller pieces that
don't share common sub-expressions (as below) it works:

y = x + 2.0
z = y + (y + 1.0)

I've tested ~10 examples like this and only ones where common sub-expressions
occur in a single function produce this problem.

I'm happy to provide a version of this example that has the arithmetic logic
filled in if that would be helpful.

If this is not a compiler problem and I'm doing something wrong I would greatly
appreciate being pointed in the right direction.

Many thanks,
Adam

[Bug c++/97819] New: Pack expansion in member initializer lists nested with their parameter list got rejected.

[gnaggnoyil at gmail dot com via Gcc-bugs]

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

Bug ID: 97819
   Summary: Pack expansion in member initializer lists nested with
their parameter list got rejected.
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gnaggnoyil at gmail dot com
  Target Milestone: ---

The following code got accepted by Clang 10.0 and MSVC 19.27.29112, yet fails
to compile under GCC:

template 
class foo : public Ts...{
public:
template 
explicit foo(T &&t, Us &&...us)
//: Ts(Ts(t, us))...{} -> This line is accepted
//: Ts{t, us...}...{} -> This line is accepted too
: Ts(t, us...)...{} // This line is rejected
};

class bar{
public:
explicit bar(int){}
};

class qux{
public:
explicit qux(int){}
};

class baz{
public:
explicit baz(int){}
};

int main(){
foo x(3);
(void)x;
return 0;
}

I tried GCC version 4.9.3 with -std=c++14, 5.5.0, 6.3.0, 7.3.0 with -std=c++17,
and 8.3.0, 9.3.0, 10.1.0 with -std=c++2a, all of them rejects this code.

Error outputs for GCC 4.9.3, 5.5.0, 9.3.0, 10.1.0 ones are:

prog.cc: In instantiation of 'foo::foo(T&&, Us&& ...) [with T = int; Us =
{}; Ts = bar, baz, qux]':
prog.cc:27:27:   required from here
prog.cc:8:23: error: invalid use of pack expansion expression
 : Ts(t, us...)...{}
   ^

Error outputs for GCC 6.3.0, 7.3.0, 8.3.0 ones are:

prog.cc: In instantiation of 'foo::foo(T&&, Us&& ...) [with T = int; Us =
{}; Ts = {bar, baz, qux}]':
prog.cc:27:27:   required from here
prog.cc:8:23: error: no matching function for call to 'bar::bar(int&, bool)'
 : Ts(t, us...)...{}
   ^~~
prog.cc:13:14: note: candidate: bar::bar(int)
 explicit bar(int){}
  ^~~
prog.cc:13:14: note:   candidate expects 1 argument, 2 provided
prog.cc:11:7: note: candidate: constexpr bar::bar(const bar&)
 class bar{
   ^~~
prog.cc:11:7: note:   candidate expects 1 argument, 2 provided
prog.cc:11:7: note: candidate: constexpr bar::bar(bar&&)
prog.cc:11:7: note:   candidate expects 1 argument, 2 provided
prog.cc:8:23: error: no matching function for call to 'baz::baz(int&, bool)'
 : Ts(t, us...)...{}
   ^~~
prog.cc:23:14: note: candidate: baz::baz(int)
 explicit baz(int){}
  ^~~
prog.cc:23:14: note:   candidate expects 1 argument, 2 provided
prog.cc:21:7: note: candidate: constexpr baz::baz(const baz&)
 class baz{
   ^~~
prog.cc:21:7: note:   candidate expects 1 argument, 2 provided
prog.cc:21:7: note: candidate: constexpr baz::baz(baz&&)
prog.cc:21:7: note:   candidate expects 1 argument, 2 provided
prog.cc:8:23: error: no matching function for call to 'qux::qux(int&, bool)'
 : Ts(t, us...)...{}
   ^~~
prog.cc:18:14: note: candidate: qux::qux(int)
 explicit qux(int){}
  ^~~
prog.cc:18:14: note:   candidate expects 1 argument, 2 provided
prog.cc:16:7: note: candidate: constexpr qux::qux(const qux&)
 class qux{
   ^~~
prog.cc:16:7: note:   candidate expects 1 argument, 2 provided
prog.cc:16:7: note: candidate: constexpr qux::qux(qux&&)
prog.cc:16:7: note:   candidate expects 1 argument, 2 provided

[Bug c++/97820] New: VLAs in function declarations fail to compile

[josephcsible at gmail dot com via Gcc-bugs]

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

Bug ID: 97820
   Summary: VLAs in function declarations fail to compile
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: josephcsible at gmail dot com
  Target Milestone: ---

Consider these 4 attempts at declaring a function:

void f1(int rows, int cols, int arr[rows][cols]);
void f2(int rows, int cols, int (*arr)[cols]);
void f3(int, int, int [*][*]);
void f4(int, int, int (*)[*]);

When I compile them with g++, they all have errors:

:1:41: error: use of parameter outside function body before ']' token
1 | void f1(int rows, int cols, int arr[rows][cols]);
  | ^
:1:47: error: use of parameter outside function body before ']' token
1 | void f1(int rows, int cols, int arr[rows][cols]);
  |   ^
:2:44: error: use of parameter outside function body before ']' token
2 | void f2(int rows, int cols, int (*arr)[cols]);
  |^
:3:25: error: expected primary-expression before ']' token
3 | void f3(int, int, int [*][*]);
  | ^
:3:28: error: expected primary-expression before ']' token
3 | void f3(int, int, int [*][*]);
  |^
:4:28: error: expected primary-expression before ']' token
4 | void f4(int, int, int (*)[*]);
  |^

Since we support VLAs in C++ as an extension, I expected that all of these
would work.

https://godbolt.org/z/Wca9ra

[Bug libstdc++/96322] 22_locale/numpunct/members/char/3.cc is outdated: expects grouping=0, actual=3

[slyfox at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Sergei Trofimovich  ---
Good point.

I tried pt_PT on FreeBSD to check if it's the same as in Linux and it's not:
there grouping=3 is used. +1 for custom locale.

[Bug middle-end/94527] RFE: Add an __attribute__ that marks a function as freeing an object

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #11 from Martin Sebor  ---
Patch: https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559053.html

[Bug middle-end/94527] RFE: Add an __attribute__ that marks a function as freeing an object

[msebor at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #12 from Martin Sebor  ---
David Malcolm: I went with "overloading" attribute malloc in my patch for the
reasons I explained my comments on your patch and in the patch submission
email.  I'm open to changing the name (or the association from the allocator to
the deallocator) so long as it's limited to pointers (with integers and other
handles handled by some other attribute), and provided it lets users specify
the position of the argument in the deallocation function's argument list.

David Howells: If/when you have a chance please comment on the design and let
us know if you have any concerns.

[Bug tree-optimization/97821] New: wrong code with -ftree-vectorize at -O1 on x86_64-pc-linux-gnu

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 97821
   Summary: wrong code with -ftree-vectorize at -O1 on
x86_64-pc-linux-gnu
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

The code is valid, but it is hard to reduce, so still quite large.

[509] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/suz-local/software/local/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/11.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--prefix=/local/suz-local/software/local/gcc-trunk --enable-languages=c,c++
--disable-werror --enable-multilib --with-system-zlib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.0 20201113 (experimental) [master revision
54896b10dbe:c3a97a9df4b:a514934a0565255276adaa4fbd4aa35579ec33c6] (GCC) 
[510] % 
[510] % gcctk -O1 small.c; ./a.out
5030-170
[511] % gcctk -O1 -ftree-vectorize small.c; ./a.out
5030-176
[512] % 
[512] % cat small.c
int printf (const char *, ...);

static unsigned a, f, v;
int b, h, aa, ab, ac, ad, ae, y, z, af;
static long c, m, t, ag, ah = 3;
static signed d;
static char e, ai;
static short g, j = 1, o, w;
int *i, *s;
long long l;
static int *n;
char p;
static int q;
static int r;
static int u;
short x;
long long *aj = &l;
static signed ak;
static volatile unsigned al = 5;
static volatile short am = 1;
int *an(int *ao, int *ap) { return ap; }
static int aq() {
  int ar[] = {2, 2, 2, 2, 2, 2};
  short *as = &x;
  int at[] = {0, 1, 0, 1};
  int au = ab = 0;
  for (; m <= 1; m++) {
int av = 0, k, aw = e && u, ax = aw || ag;
int **ay = &n;
for (; ab; ab++)
  ac = 0;
for (; ac; ac++)
  am;
u &&am;
short az = am || a ^ w;
unsigned bc = am & w | am || ag;
  ba:
aw = u;
i = 0;
for (; i; i++)
  b = a;
printf("0");
if (p) {
  printf("%ld", ag);
  continue;
}
if (ag) {
  printf("7");
  e = w | ag c < ax;
}
if (w) {
  printf("%d", u);
  goto bb;
}
if (u)
  printf("%d", e);
s = &k;
u = aw;
t = 0;
for (; t <= 1; t++)
  *ay = an(&au, &av);
e++;
  }
  for (; r >= 0;)
for (; ag <= 5;) {
  signed bd[6];
  int be = 0, bf = am % al;
  for (; be < 6; be++)
bd[0] = 9;
  h = 0;
  for (; h <= 5; h++)
*aj = *as = aa;
  for (; w; w = d)
;
  short bg = d + j ^ e + r;
  al % am;
  int bi = bg & al >> am;
  am ^ al;
  am / al;
  am &al;
  al;
  am / al;
  if (c)
if (q) {
  be = 0;
  for (; be; be++)
z = 0;
}
  am;
  int bj = 0;
  if (m || q) {
  bh:
l = ad = c;
int bm = al || q;
al;
al;
char bn = al || q;
al;
al;
bm = q;
ae = a;
  bk:
ai = h || q > d;
ag = d;
al;
al;
printf("%d", q);
if (a > 1)
  break;
if (q)
  printf("%d", d);
if (q) {
  printf("3");
  h = d | bm > q;
  goto bk;
}
if (!ai || al && 0) {
  printf("%d", d);
  al;
  printf("%d", a);
  goto bb;
}
d = al;
printf("%lld", l);
m = q;
if (ak) {
  printf("%ld", c);
  ad = c & q;
}
if (!ah) {
  printf("%d", q);
  goto bh;
}
  }
  if (c)
s = &bj;
  m = q = d && c;
  r = ~(e / j & al > r);
  f |= d = al;
  v |= am;
  al / al ^ am;
  ak = am + al | al;
  am / al + al ^ am;
  j = am;
  al;
bb:
  if (c)
g++;
  a = q || e & d;
  am || al;
  am;
  am;
  am;
  al &am;
  am;
  am;
bl:
  am;
  if (q) {
printf("%d", q);
a = q - am;
goto bl;
  }
  am;
  printf("%d", d);
  m = q & am;
  am;
  printf("%d", a);
  if (d < -41) {
printf("%ld", ag);
goto ba;
  }
  h = *n;
  printf("3");
  c = e / d;
  printf("%ld", m);
  d = d << q / ag;
  o = 2;
  for (; o; o++)
i = &be;
  x = m = e;
  printf("%d", r) && (ah = r) || (d = ak && e);
  printf("%d", ak);
  if (!bf) {
printf("%d", e);
*as = a;
i = n;
bi = ak / am > r;
*n = 0;
for (; n; n++)
  ;
  }
  y = bi;
}
  return 0;
}
int main() {
  for (; af < 6; af++) {
d = 8;
aq();
  }
  printf("%d\n", h);
  return 0;
}

[Bug c++/63287] __STDCPP_THREADS__ is not defined

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-5017-g1d9a8675d379f02f5e39639f469ae8dfcf33fea9
Author: Jakub Jelinek 
Date:   Fri Nov 13 23:23:33 2020 +0100

c++: Predefine __STDCPP_THREADS__ in the compiler if thread model is not
single [PR63287]

The following patch predefines __STDCPP_THREADS__ macro to 1 if c++11 or
later and thread model (e.g. printed by gcc -v) is not single.
There are two targets not handled by this patch, those that define
THREAD_MODEL_SPEC.  In one case - QNX - it looks just like a mistake
to me, instead of setting thread_model=posix in config.gcc it uses
THREAD_MODEL_SPEC macro to set it unconditionally to posix.
The other is hpux10, which uses -threads option to decide if threads
are enabled or not, but that option isn't really passed to the compiler.
I think that is something that really should be solved in config/pa/
instead, e.g. in the config/xxx/xxx-c.c targets usually set their own
predefined macros and it could handle this, and either pass the option
also to the compiler, or say predefine __STDCPP_THREADS__ if _DCE_THREADS
macro is defined already (or -D_DCE_THREADS found on the command line),
or whatever else.

2020-11-13  Jakub Jelinek  

PR c++/63287
* c-cppbuiltin.c: Include configargs.h.
(c_cpp_builtins): For C++11 and later if THREAD_MODEL_SPEC is not
defined, predefine __STDCPP_THREADS__ to 1 unless thread_model is
"single".

[Bug c/97817] -Wformat-truncation=2 elicits invalid warning

[msebor at gcc dot gnu.org via Gcc-bugs]

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

Martin Sebor  changed:

   What|Removed |Added

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

--- Comment #3 from Martin Sebor  ---
Level 2 of the warning is documented to warn also about calls to bounded
functions whose return value is used and that might result in truncation given
an argument of sufficient length or magnitude.  The level is meant to help
write code with the least likelihood of truncation given unknown arguments.

In the test case, the output of the function will be truncated unless buflen is
at least 16.  It will also be truncated if buflen is 16 and errnum is either
negative or bigger than 9.  The note printed after the warning indicates the
minimum size of output (i.e., 16) and the maximum (26) beyond which truncation
is impossible.

[Bug c/97817] -Wformat-truncation=2 elicits invalid warning

[jim at meyering dot net via Gcc-bugs]

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

--- Comment #4 from jim at meyering dot net ---
Thanks for explaining. It would be nice if the diagnostic were to say something
along the lines of "... writing into a region whose size may be as low as N".
Given the wording of the current diagnostic, I initially went looking for a
caller whose buffer really did have length 2 (in the original it was 2, not 6).

It's only when I finally noticed that initial "if" block in the implementation
that I understood where the "2" (6 in this example) was coming from.

[Bug libstdc++/93421] futex.cc use of futex syscall is not time64-compatible

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-5022-g4d039cb9a1d0ffc6910fe09b726c3561b64527dc
Author: Jonathan Wakely 
Date:   Thu Sep 24 17:35:52 2020 +0100

libstdc++: Use custom timespec in system calls [PR 93421]

On 32-bit targets where userspace has switched to 64-bit time_t, we
cannot pass struct timespec to SYS_futex or SYS_clock_gettime, because
the userspace definition of struct timespec will not match what the
kernel expects.

We use the existence of the SYS_futex_time64 or SYS_clock_gettime_time64
macros to imply that userspace *might* have switched to the new timespec
definition.  This is a conservative assumption. It's possible that the
new syscall numbers are defined in the libc headers but that timespec
hasn't been updated yet (as is the case for glibc currently). But using
the alternative struct with two longs is still OK, it's just redundant
if userspace timespec still uses a 32-bit time_t.

We also check that SYS_futex_time64 != SYS_futex so that we don't try
to use a 32-bit tv_sec on modern targets that only support the 64-bit
system calls and define the old macro to the same value as the new one.

We could possibly check #ifdef __USE_TIME_BITS64 to see whether
userspace has actually been updated, but it's not clear if user code
is meant to inspect that or if it's only for libc internal use.

libstdc++-v3/ChangeLog:

PR libstdc++/93421
* src/c++11/chrono.cc [_GLIBCXX_USE_CLOCK_GETTIME_SYSCALL]
(syscall_timespec): Define a type suitable for SYS_clock_gettime
calls.
(system_clock::now(), steady_clock::now()): Use syscall_timespec
instead of timespec.
* src/c++11/futex.cc (syscall_timespec): Define a type suitable
for SYS_futex and SYS_clock_gettime calls.
(relative_timespec): Use syscall_timespec instead of timespec.
(__atomic_futex_unsigned_base::_M_futex_wait_until): Likewise.
(__atomic_futex_unsigned_base::_M_futex_wait_until_steady):
Likewise.

[Bug libstdc++/93456] No overflow check in __atomic_futex_unsigned_base::_M_futex_wait_until

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

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

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

commit r11-5021-gb8d36dcc917e8a06d8c20b9f5ecc920ed2b9e947
Author: Jonathan Wakely 
Date:   Fri Nov 13 20:57:15 2020 +

libstdc++: Remove redundant overflow check for futex timeout [PR 93456]

The relative_timespec function already checks for the case where the
specified timeout is in the past, so the difference can never be
negative. That means we dn't need to check if it's more negative than
the minimum time_t value.

libstdc++-v3/ChangeLog:

PR libstdc++/93456
* src/c++11/futex.cc (relative_timespec): Remove redundant check
negative values.
* testsuite/30_threads/future/members/wait_until_overflow.cc: Moved
to...
* testsuite/30_threads/future/members/93456.cc: ...here.

[Bug libstdc++/93421] futex.cc use of futex syscall is not time64-compatible

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to Rich Felker from comment #7)
> Indeed, the direct clock_gettime syscall stuff is just unnecessary on any
> modern system, certainly any time64 one. I read the patch briefly and I
> don't see anywhere it would break anything, but it also wouldn't produce a
> useful Y2038-ready configuration, so I don't think it makes sense. Configure
> or source-level assertions should just ensure that, if time_t is larger than
> long and there's a distinct time64 syscall, the direct syscall is never used.

I didn't get around to making use of the new syscalls for GCC 11, so I've
committed that patch. I'll keep this bug open to revisit it and do it properly
later.

[Bug libstdc++/93456] No overflow check in __atomic_futex_unsigned_base::_M_futex_wait_until

[redi at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from Jonathan Wakely  ---
Fixed on trunk by the patch above and a few other recent commits today.

[Bug target/97682] Miscompiled tail call with -fPIC

[cvs-commit at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jim Wilson :

https://gcc.gnu.org/g:207de83922bda8707aa33d6a2185e691116377e7

commit r11-5026-g207de83922bda8707aa33d6a2185e691116377e7
Author: Monk Chiang 
Date:   Fri Nov 13 19:35:11 2020 -0800

PR target/97682 - Fix to reuse t1 register between call address and
epilogue.

  - When expanding the call pattern, choose t1 register be a jump register.
Epilogue also uses a t1 register to adjust Stack point. The call
pattern
and epilogue will initial t1 twice, if both are generated in the same
function. The call pattern will emit 'la t1,symbol' and 'jalr
t1'instructions.
Epilogue also emits 'li t1,4096' and 'addi sp,sp,t1' instructions.
But li and addi instructions will be placed between la and jalr
instructions.
The la instruction will be removed by some optimizations,
because t1 register define twice, the first define instruction look
likes duplicate.

  - To resolve this issue, Prologue and Epilogue use the t0 register
be a temporary register, the call pattern use the t1 register be
a temporary register.

gcc/
2020-11-13  Monk Chiang  

PR target/97682
* config/riscv/riscv.h (RISCV_PROLOGUE_TEMP_REGNUM): Change
register
to t0.
(RISCV_CALL_ADDRESS_TEMP_REGNUM): New Marco, define t1 register.
(RISCV_CALL_ADDRESS_TEMP): Use it for call instructions.
* config/riscv/riscv.c (riscv_legitimize_call_address): Use
RISCV_CALL_ADDRESS_TEMP.
(riscv_compute_frame_info): Change temporary register to t0 form
t1.
(riscv_trampoline_init): Adjust comment.

gcc/testsuite/
2020-11-13  Monk Chiang  

PR target/97682
* g++.target/riscv/pr97682.C: New test.
* gcc.target/riscv/interrupt-3.c: Check register for t0.
* gcc.target/riscv/interrupt-4.c: Likewise.