[Bug testsuite/44922] undefined variable in execute/921202-1.c

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #2 from Vittorio Zecca  ---
This issue is a corner case and will never be resolved.
So I am closing it.

[Bug fortran/50549] should detect different type parameters in structure constructors (r178939)

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Vittorio Zecca  ---
Still present on version 11.
NAG nagfor compiler detecs it.
nagfor -S gfbug87.f -w
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug87.f, line 13: Wrong character length (1 instead of 2) for pointer
component P2 in constructor for type T
Error: gfbug87.f, line 14: Wrong character length (1 instead of 2) for pointer
component P2 in constructor for type T
[NAG Fortran Compiler error termination, 2 errors]

[Bug testsuite/44798] inconsistent interfaces

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #4 from Vittorio Zecca  ---
This issue has been resolved by adjusting the array bounds.

[Bug fortran/50535] transformational intrinsic functions not allowed in statement functions

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Vittorio Zecca  ---
Still in version 11.
Both Intel ifort and NAG nagfor detect the issue.

ifort -S gfbug73.f -w
gfbug73.f(5): error #6736: This transformational intrinsic function is invalid
in this context; statement functions cannot contain transformational intrinsic
functions.   [ALL]
  g(x)=all(l)
---^
compilation aborted for gfbug73.f (code 1)
[vitti f95]$nagfor -S gfbug73.f -w
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug73.f, line 5: Reference to transformational intrinsic ALL in
statement function
[NAG Fortran Compiler error termination, 1 error]

[Bug fortran/50377] gfortran must not accept an external formal argument not declared external

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Vittorio Zecca  ---
Still present at version 11.
The Intel ifort and NAG nagfor compilers decet the issue.

nagfor -S gfbug158.f -w
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug158.f, line 3: External procedure SUB used as actual argument but
does not have the EXTERNAL attribute
[NAG Fortran Compiler error termination, 1 error]

[vitti f95]$ifort -S gfbug158.f
gfbug158.f(3): error #7898: If an external or dummy procedure name is used as
an actual argument, its interface shall be explicit or it shall be explicitly 
declared to have the EXTERNAL attribute.   [SUB]
  call sub(sub)
---^
compilation aborted for gfbug158.f (code 1)

[Bug middle-end/94442] [10/11 regression] Redundant loads/stores emitted at -O3

[xiezhiheng at huawei dot com via Gcc-bugs]

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

--- Comment #9 from xiezhiheng at huawei dot com ---
(In reply to Jakub Jelinek from comment #8)
> So, is this fixed by any of the
> r11-2190-gbf592b2ff776aef71c91924cdb5e0d10488496cf
> r11-2448-g072a8b8fb6e861d8ac2db847bcc81dbcb1ef1b35
> r11-2554-g35ffd4d16d7e3dbba297da788414a673530b7817
> r11-2874-ge3684bcbf88b438ca1f0749de8843ddd5b72ad59
> r11-2901-gd7738d4fde5b248b6814f5dd20617eecd33601df
> r11-2902-g795944c4563b4d9abf6d4bd9963f41fa1249d9d9
> r11-3844-gca4938fa8e0e72fd59307f1f058db800c1e4a8f3
> r11-4131-g4fb0ee84ad8c9b789e2465c85ea048e3320365b0
> r11-4384-g2d5aad691f5bd605cfc27ce16a1f2d023cd21f75
> r11-4565-gc517003e719cb045d755dd4b074a1306d5567be4
> r11-4665-gc229693ba6f5abb245fc71ebef4b8f7720e8ccf5
> r11-4666-g60be12c32cb3a07a64efdab1f0ee6fd74536cc93
> r11-4875-g1900707e56ae8c913f1d16426065e128b1abbb14
> commits that refer to this PR number but none of them referred to it in
> ChangeLog entry, or not?

Not yet.  We fixed part of the intrinsics.
But like saturating intrinsics (used in this PR), because GCC does not
model fpsr register but tests it in some test cases, simply setting
the FLAG of saturating intrinsics to none would cause these test cases to fail.
So it need take further considerations for saturating intrinsics.

[Bug libgcc/67379] libgcc2.c negation of -2147483648 cannot be represented in type 'int'

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #3 from Vittorio Zecca  ---
Fixed in bug 99236.

[Bug c/99297] New: wrong diagnostic style in rx.c

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 99297
   Summary: wrong diagnostic style in rx.c
   Product: gcc
   Version: 11.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: ---

rx.c says:
> "invalid control register for mvtc : %d - using 'psw'"

This should rather be:
> "invalid control register %d for mvtc; using %"

[Bug fortran/50536] an input item shall not appear as the do-variable of any io-implied-do

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Vittorio Zecca  ---
Still present in version 11.

Detected by NAG nagfor and Intel ifort.

[vitti f95]$nagfor -S -w gfbug74.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug74.f, line 4: Input item L cannot also be an I/O implied DO
variable
[NAG Fortran Compiler error termination, 1 error]
[vitti f95]$ifort -S -w gfbug74.f
gfbug74.f(4): error #8251: An input item must not appear as the implied-DO
variable of any implied-DO loop that contains the input item.   [L]
  read *,(l,l=1,2) 
--^
compilation aborted for gfbug74.f (code 1)

[Bug target/93353] ICE: in final_scan_insn_1, at final.c:3073 (error: could not split insn)

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #6 from Jakub Jelinek  ---
I can reproduce #c0 with an older trunk and -m32 -mcpu=e300c3 in a cross, but
it has been fixed with
r11-3606-g4c69e61f4307865b95151006e480ae2022b30454
So maybe that fix needs backporting?
As for #c3-#c5, please file a separate bug, a rs6000 backend bug certainly has
nothing to do with completely unrelated aarch64 ICE.

[Bug ada/99264] latest glibc release breaks Ada buildr on Linux

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

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

Eric Botcazou  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ebotcazou at gcc dot 
gnu.org
 CC|ebotcazou at gcc dot gnu.org   |
 Status|NEW |ASSIGNED
 Target||*-*-linux-gnu
Summary|Ada doesn't build against   |latest glibc release breaks
   |latest glibc|Ada buildr on Linux

--- Comment #6 from Eric Botcazou  ---
> However, there is little that we can do. The hardware requirements have
> changed under us, so even the kernel does not have much choice here.
> Applications really have to adapt to the massively increased size of the
> register file, there really is no way around that.

Providing a new constant minimal default would have been better IMO, even if it
would have been significantly larger than the current one, than breaking a long
established practice.

[Bug fortran/50542] gfortran should detect violation of Fortran 95 R536 (r178939)

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Vittorio Zecca  ---
Still present in version 11.

The compilers NAG nagfor and Intel ifort detect the issue.

ifort -S -w gfbug82.f -warn stderrors
gfbug82.f(9): error #8252: A DATA implied-DO variable must be an array element
or scalar structure component that has at least one subscript list.
  data (u%g,j=1,1) /1/! violates R536: data-i-do-object cannot be a scalar
^
gfbug82.f(10): error #8252: A DATA implied-DO variable must be an array element
or scalar structure component that has at least one subscript list.
  data (ii,j=1,1) /1/ ! ditto
^
compilation aborted for gfbug82.f (code 1)
[vitti f95]$nagfor -S -w gfbug82.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug82.f, line 10: Syntax error
   detected at II@,
[NAG Fortran Compiler pass 1 error termination, 1 error]

[Bug fortran/50538] formal argument cannot be same as procedure name in ENTRY

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Vittorio Zecca  ---
Still present in current trunk.

The compilers NAG nagfor and Intel ifort detect the issue.

nagfor -S -w gfbug78.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug78.f, line 4: Dummy argument SUB has the same name as the
subprogram
   detected at (@SUB
[NAG Fortran Compiler pass 1 error termination, 1 error]
[vitti f95]$ifort -S -w gfbug78.f
gfbug78.f(4): error #6406: Conflicting attributes or multiple declaration of
name.   [SUB]
  entry e(sub)
--^
compilation aborted for gfbug78.f (code 1)

[Bug target/93353] ICE: in final_scan_insn_1, at final.c:3073 (error: could not split insn)

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

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

--- Comment #7 from Jakub Jelinek  ---
And to explain what was happening,
rs6000_legitimize_address has been called on x
(plus:SI (reg/f:SI 117)
(const_int 2147483647 [0x7fff]))
and mode QImode, oldx == x.
((0x7fff & 0x) ^ 0x8000) - 0x8000
is low_int -1 and
  if (low_int >= 0x8000 - extra)
is not true and 0x7fff - -1 is 0x8000 (with UB on the compiler side).
So maybe the above mentioned commit wasn't sufficient and
we should
-  high_int = INTVAL (XEXP (x, 1)) - low_int;
+  high_int = UINTVAL (XEXP (x, 1)) - low_int;
But also
  && ((unsigned HOST_WIDE_INT) (INTVAL (XEXP (x, 1)) + 0x8000)
can invoke UB in the compiler, shouldn't it be just
  && ((UINTVAL (XEXP (x, 1)) + 0x8000)
?

[Bug fortran/50402] ICE in gfc_conv_expr_descriptor

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Vittorio Zecca  ---
Still in current trunk.

The compilers NAG nagfor and Intel ifort correctly detect a syntax error.

nagfor -S -w gfbug43.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug43.f, line 12: Scalar value for array pointer component P of type T
[NAG Fortran Compiler error termination, 1 error]

[vitti f95]$ifort -S -w gfbug43.f
gfbug43.f(12): error #6594: The rank of a component in a structure constructor
differs from the rank of the component of the derived type.   [F]
  u=t(f())
--^
compilation aborted for gfbug43.f (code 1)

[Bug libfortran/81986] sanitizer detects negation of large number in string.c

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

  Component|sanitizer   |libfortran

--- Comment #4 from Vittorio Zecca  ---
On current trunk with sanitized libgfortran.so.5 I get

gfortran gfbug142.f
ldd ./a.out

libgfortran.so.5 =>
/home/vitti/gcc-150221-undefined/x86_64-pc-linux-gnu/libgfortran/.libs/libgfortran.so.5
(0x14a739133000)
libubsan.so.1 =>
/home/vitti/local/gcc-150221-undefined/lib/../lib64/libubsan.so.1
(0x14a738293000)
libstdc++.so.6 =>
/home/vitti/local/gcc-150221-undefined/lib/../lib64/libstdc++.so.6


./a.out
../../../gcc-150221/libgfortran/io/write.c:835:7: runtime error: negation of
0x8000 cannot be represented in type '__int128';
cast to an unsigned type to negate this value to itself
../../../gcc-150221/libgfortran/runtime/string.c:199:11: runtime error:
negation of 0x8000 cannot be represented in type
'__int128'; cast to an unsigned type to negate this value to itself
8000

[Bug tree-optimization/62058] Undefined behaviour in tree-data-ref.c with options -O1 -ftree-loop-vectorize

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #7 from Vittorio Zecca  ---
Fixed in current runk.

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

[zeccav at gmail dot com via Gcc-bugs]

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

Bug 62058 Summary: Undefined behaviour in tree-data-ref.c with options -O1 
-ftree-loop-vectorize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62058

   What|Removed |Added

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

[Bug middle-end/67486] ira-color.c sanitizer detects signed integer overflow

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #8 from Vittorio Zecca  ---
Fixed in current trunk.

[Bug fortran/50525] gfortran should not allow early reference to entry dummy argument (r178939)

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Vittorio Zecca  ---
Still in trunk.

The NAG nagfor and Intel ifort compilers detect the issue.

ifort -S -w gfbug72.f
gfbug72.f(4): error #6482: An ENTRY dummy argument is referenced in an
executable statement before it appears in any ENTRY statement.   [X]
  f(y)=x ! this is wrong
---^
compilation aborted for gfbug72.f (code 1)

[vitti f95]$nagfor -S -w gfbug72.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug72.f, line 4: Dummy arg X used before first occurrence in an
argument list
[NAG Fortran Compiler error termination, 1 error]

[Bug other/99288] xgettext does not get HOST_WIDE_INT_PRINT_UNSIGNED

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

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

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

https://gcc.gnu.org/g:652623f7c68594b1825a333bf8e83e87d1c3f523

commit r11-7426-g652623f7c68594b1825a333bf8e83e87d1c3f523
Author: Jakub Jelinek 
Date:   Sat Feb 27 10:43:28 2021 +0100

gcse, ipa-devirt: Use %wd/%wu instead of HOST_WIDE_INT_PRINT* in
diagnostics [PR99288]

HOST_WIDE_INT_PRINT* in the string literals of warning/error/inform etc.
make those messages non-translatable, and we have a perfectly fine
alternative when not using system *printf - %w{d,u}.

2021-02-27  Jakub Jelinek  

PR other/99288
* gcse.c (gcse_or_cprop_is_too_expensive): Use %wu instead of
HOST_WIDE_INT_PRINT_UNSIGNED in warning format string.
* ipa-devirt.c (ipa_odr_read_section): Use %wd instead of
HOST_WIDE_INT_PRINT_DEC in inform format string.  Fix comment
typos.

[Bug middle-end/82083] sanitizer detects signed integer overflow in tree-data-ref.c with -O3

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #6 from Vittorio Zecca  ---
Fixed in version 10.

[Bug fortran/58224] -fcheck=pointer should detect that an unallocated allocatable data-target is forbidden

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Vittorio Zecca  ---
Still in trunk.

The NAG nagfor compiler detects the issue at compile time.

nagfor gfbug103.f 
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Warning: gfbug103.f, line 8: Pointer Q never dereferenced
Error: gfbug103.f, line 8: ALLOCATABLE variable QQ used but never ALLOCATEd
[NAG Fortran Compiler pass 1 error termination, 1 error, 1 warning]

[Bug fortran/50541] gfortran should not accept a pointer as a generic-name (r178939)

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #7 from Vittorio Zecca  ---
The NAG nagfor and Intel ifort detect the issue.

gfortran -S gfbug81.f

[vitti f95]$nagfor -S gfbug81.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug81.f, line 4: Multiply defined symbol S
   detected at INTERFACE@S
Warning: gfbug81.f, line 10: Unused local variable S

[NAG Fortran Compiler pass 1 error termination, 1 error, 1 warning]
[vitti f95]$ifort -S gfbug81.f
gfbug81.f(3): error #6449: This name has already been used as a generic
procedure name   [S]
  pointer s! gfortran should complain here
--^
compilation aborted for gfbug81.f (code 1)

[Bug rtl-optimization/85789] Signed integer overflow with nonzero optimization in cse.c

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Vittorio Zecca  ---
Still in trunk:

~/local/gcc-150221-undefined/bin/gcc -S gccerr67.c -O
../../gcc-150221/gcc/cse.c:2204:34: runtime error: signed integer overflow: 1 -
-9223372036854775807 cannot be represented in type 'long int'

[Bug c++/99298] New: diagnostic in name-lookup.c embeds part-of-speech

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 99298
   Summary: diagnostic in name-lookup.c embeds part-of-speech
   Product: gcc
   Version: 11.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: ---

gcc/cp/name-lookup.c says:
> error_at (loc, "%s namespace %qD conflicts with reachable definition",
>   inline_p ? "inline" : "non-inline", decl);
> inform (DECL_SOURCE_LOCATION (decl), "reachable %s definition here",
> inline_p ? "non-inline" : "inline");

The word "non-inline" cannot be translated into other languages since it is
provided as a string literal. Depending on the language, the "non" might even
change the complete structure of the message.

https://gcc.gnu.org/codingconventions.html#Diagnostics says:
> All diagnostics should be full sentences without English
> fragments substituted in them, to facilitate translation.

[Bug fortran/80774] [8/9/10/11 Regression][Coarray] ICE in gfc_conv_descriptor_data_get, at fortran/trans-array.c

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Vittorio Zecca  ---
Still in current trunk.

gfortran -S gfbug132.f -fcoarray=single
gfbug132.f:18:72:

   18 |   deallocate(obj%link)
  |   
1
internal compiler error: in gfc_get_descriptor_field, at
fortran/trans-array.c:140
0x623c3e gfc_get_descriptor_field
../../gcc-150221/gcc/fortran/trans-array.c:140
0x90990a gfc_conv_descriptor_data_get(tree_node*)
../../gcc-150221/gcc/fortran/trans-array.c:159
0x9078a4 gfc_deallocate_with_status(tree_node*, tree_node*, tree_node*,
tree_node*, tree_node*, bool, gfc_expr*, int, tree_node*, tree_node*)
../../gcc-150221/gcc/fortran/trans.c:1433
0x91bcad structure_alloc_comps
../../gcc-150221/gcc/fortran/trans-array.c:9031
0x91c93a gfc_deallocate_alloc_comp(gfc_symbol*, tree_node*, int, int)
../../gcc-150221/gcc/fortran/trans-array.c:9821
0x908132 gfc_deallocate_scalar_with_status(tree_node*, tree_node*, tree_node*,
bool, gfc_expr*, gfc_typespec, bool)
../../gcc-150221/gcc/fortran/trans.c:1652
0x992c69 gfc_trans_deallocate(gfc_code*)
../../gcc-150221/gcc/fortran/trans-stmt.c:7379
0x9042a7 trans_code
../../gcc-150221/gcc/fortran/trans.c:2098
0x932f53 gfc_generate_function_code(gfc_namespace*)
../../gcc-150221/gcc/fortran/trans-decl.c:6880
0x8afaae translate_all_program_units
../../gcc-150221/gcc/fortran/parse.c:6351
0x8afaae gfc_parse_file()
../../gcc-150221/gcc/fortran/parse.c:6620
0x9010ef gfc_be_parse_file
../../gcc-150221/gcc/fortran/f95-lang.c:212
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug target/81319] ICE in output_operand_lossage at final.c

[zeccav at gmail dot com via Gcc-bugs]

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

Vittorio Zecca  changed:

   What|Removed |Added

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

--- Comment #4 from Vittorio Zecca  ---
Fixed in 10.1.1-1.

[Bug fortran/50551] Argumentless NULL() cannot be used with assumed-length dummy (r178939)

[zeccav at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Vittorio Zecca  ---
Still in trunk.
The NAG nagfor and Intel ifort compilers detect the issue.

gfortran -S gfbug89.f

[vitti f95]$nagfor -S -w gfbug89.f
NAG Fortran Compiler Release 7.0(Yurakucho) Build 7042
Error: gfbug89.f, line 10: Argumentless NULL() cannot be used with
assumed-length dummy
[NAG Fortran Compiler error termination, 1 error]

[vitti f95]$ifort -S -w gfbug89.f
gfbug89.f(10): error #8613: Intrinsic NULL() must have the MOLD argument if it
is an actual argument corresponding to a dummy argument with assumed type
parameters.
  call sub(null())  ! null() cannot be used with assumed length dummy
argument
---^
compilation aborted for gfbug89.f (code 1)

[Bug fortran/98979] [11 regression] ICE in several tests cases after r11-7112

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

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

--- Comment #12 from Iain Sandoe  ---
the failures are resolved on Darwin too.

[Bug c/99299] New: Need a recoverable version of __builtin_trap()

[christophe.leroy at csgroup dot eu via Gcc-bugs]

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

Bug ID: 99299
   Summary: Need a recoverable version of __builtin_trap()
   Product: gcc
   Version: 10.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: christophe.leroy at csgroup dot eu
  Target Milestone: ---

Linux kernel implements WARN() and WARN_ON() asserts using trap instructions.

Because gcc __builtin_trap() is not recoverable, Linux Kernel has hand code the
trap, at the moment using 'twnei'. This leads to sub-optimal code generation.

As the powerpc trap instruction is recoverable as it generated a recoverable
exception, it would be extremely usefull to also have a recoverable version of
__builtin_trap() in gcc. Maybe call it __buitin_recoverable_trap()

[Bug c++/53431] C++ preprocessor ignores #pragma GCC diagnostic

[noloader at gmail dot com via Gcc-bugs]

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

--- Comment #40 from Jeffrey Walton  ---
Still a problem in 2021.

[Bug fortran/99300] New: double space in diagnostic

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 99300
   Summary: double space in diagnostic
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

fortran-passes.c says:
> "value inside loop  beginning at %L as "

The double space between "loop  beginning" should be reduced to a single space.

While here, there is a little inconsistency in where the spaces in multi-line
string literals are placed.  If possible, please search for ^\s+"\s and move
these spaces to the end of the string literals, to follow the style of the
other string literals.

[Bug libstdc++/99301] New: [11 Regression]: cast conversions in chrono require uint32_t to be unsigned int

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

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

Bug ID: 99301
   Summary: [11 Regression]: cast conversions in chrono require
uint32_t to be unsigned int
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hp at gcc dot gnu.org
CC: redi at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-linux
Target: cris-elf

Since 97d6161f6a7fa712 / r11-7370 "libstdc++: More efficient
days from date" I see an additional 81 testsuite-errors for
cris-elf, with this in g++.log for one randomly picked
regressing test:

FAIL: g++.dg/cpp1y/pr57640.C  -std=c++2a (test for excess errors)
Excess errors:
/x/gccobj/cris-elf/libstdc++-v3/include/chrono:2483:25: error: invalid
'static_cast' from type 'const std::chrono::month' to type 'uint32_t' {aka
'long unsigned int'}
/x/gccobj/cris-elf/libstdc++-v3/include/chrono:2484:25: error: invalid
'static_cast' from type 'const std::chrono::day' to type 'uint32_t' {aka 'long
unsigned int'}
/x/gccobj/cris-elf/libstdc++-v3/include/chrono:2496:69: error: no matching
function for call to 'std::chrono::duration
>::duration()'

The commit shows conversions to uint32_t, which for
e.g. x86_64-linux is "unsigned int", and there are explicit
conversions to unsigned int for month and day (see patch
context).

But, "newlib ILP32 targets" have an uint32_t that is
effectively typedef'd "long unsigned int" (see
newlib-stdint.h UINT32_TYPE).

[Bug libstdc++/99301] [11 Regression]: cast conversions in chrono require uint32_t to be unsigned int

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

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

Hans-Peter Nilsson  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2021-02-27
 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |hp at gcc dot gnu.org

[Bug fortran/99302] New: untranslated diagnostic from gfc_compare_interfaces

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 99302
   Summary: untranslated diagnostic from gfc_compare_interfaces
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

gfc_compare_interfaces formats several error messages into (errmsg, err_len).

gfc_compare_interfaces does not translate them into the user's language (such
as German or French), and check_against_globals cannot translate these since at
that point, the placeholders have already been replaced with actual
identifiers.

https://gcc.gnu.org/codingconventions.html#Diagnostics says:
> All diagnostics should be full sentences without English
> fragments substituted in them, to facilitate translation.

[Bug fortran/99303] New: OpenMP: typo in diagnostic

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 99303
   Summary: OpenMP: typo in diagnostic
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: roland.illig at gmx dot de
  Target Milestone: ---

fortran/openmp.c says:
> not set at for the

This should be "not set for the".
The "at" is probably a copy-and-paste mistake from the usual "at %L".

[Bug fortran/99303] OpenMP: typo in diagnostic

[roland.illig at gmx dot de via Gcc-bugs]

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

--- Comment #1 from Roland Illig  ---
This typo appears 2 times.

[Bug fortran/99303] OpenMP: typo in diagnostic

[roland.illig at gmx dot de via Gcc-bugs]

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

--- Comment #2 from Roland Illig  ---
same file, other typo:
> "clauses on the same construct %L"

The "at %L" is missing.

[Bug libstdc++/99301] [11 Regression]: cast conversions in chrono require uint32_t to be unsigned int

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

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

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

https://gcc.gnu.org/g:699672d4dccfb5579dbe48977bda86f6836225a0

commit r11-7427-g699672d4dccfb5579dbe48977bda86f6836225a0
Author: Jonathan Wakely 
Date:   Sat Feb 27 12:50:53 2021 +

libstdc++: Fix conversions from date types to integers [PR 99301]

The conversions to integer types are explicit, so need to use the
correct type. Converting to uint32_t only works if that is the same type
as unsigned.

libstdc++-v3/ChangeLog:

PR libstdc++/99301
* include/std/chrono (year_month_day::_M_days_since_epoch()):
Convert chrono::month and chrono::day to unsigned before
converting to uint32_t.

[Bug c/99304] New: typo in diagnostic: refernced

[roland.illig at gmx dot de via Gcc-bugs]

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

Bug ID: 99304
   Summary: typo in diagnostic: refernced
   Product: gcc
   Version: 11.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: ---

gcc/c-family/c-attribs.c says:
> "refernced symbol declared here"

That should be "referenced" instead.
A test to trigger this diagnostic is:

~~~c
/* { dg-do compile } */
/* { dg-options "-O2 -Wall" } */

void invalid_free(/* no prototype */); /* { dg-message "referenced" } */

void *invalid_malloc(void) __attribute__((
  malloc(invalid_free) /* { dg-warning "must take a pointer" } */
));
~~~

A test to trigger the closely related diagnostic is:

~~~c
/* { dg-do compile } */
/* { dg-options "-O2 -Wall" } */

void invalid_free(int); /* { dg-message "referenced" } */

void *invalid_malloc(void) __attribute__((
  malloc(invalid_free) /* { dg-warning "must take a pointer" } */
));
~~~

[Bug libstdc++/99301] [11 Regression]: cast conversions in chrono require uint32_t to be unsigned int

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #2 from Jonathan Wakely  ---
Sorry about that, I did consider the case where uint32_t was unsigned long, but
only in the context of the arithmetic in that function. I forgot the explicit
conversion operators wouldn't work.

It should be fixed now.

[Bug c/99304] typo in diagnostic: refernced

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-02-27
   Keywords||diagnostic

[Bug c/99304] [11 Regression] typo in diagnostic: refernced

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

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

Jonathan Wakely  changed:

   What|Removed |Added

  Known to work||10.2.1
  Known to fail||11.0
   Target Milestone|--- |11.0
Summary|typo in diagnostic: |[11 Regression] typo in
   |refernced   |diagnostic: refernced

[Bug fortran/99303] OpenMP: typo in diagnostic

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-02-27
   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

[Bug fortran/99300] double space in diagnostic

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||diagnostic
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-02-27

[Bug c++/99298] diagnostic in name-lookup.c embeds part-of-speech

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||diagnostic
   Last reconfirmed||2021-02-27
 Ever confirmed|0   |1

[Bug target/99297] wrong diagnostic style in rx.c

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-02-27
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

[Bug c/99295] [11 Regression] documentation on __attribute__((malloc)) is wrong

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Keywords||documentation
  Known to work||10.2.1
   Last reconfirmed||2021-02-27
 Status|UNCONFIRMED |NEW
 CC||msebor at gcc dot gnu.org
Summary|documentation on|[11 Regression]
   |__attribute__((malloc)) is  |documentation on
   |wrong   |__attribute__((malloc)) is
   ||wrong
 Ever confirmed|0   |1
   Target Milestone|--- |11.0
  Known to fail||11.0

--- Comment #2 from Jonathan Wakely  ---
This changed in dce6c58db87ebf7f4477bd3126228e73e497

[Bug c/99291] maybe_warn_pass_by_reference uses outdated format string

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||diagnostic
   Last reconfirmed||2021-02-27
 Ever confirmed|0   |1

[Bug rtl-optimization/99305] New: [11 Regression] range condition simplification after inlining

[nok.raven at gmail dot com via Gcc-bugs]

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

Bug ID: 99305
   Summary: [11 Regression] range condition simplification after
inlining
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nok.raven at gmail dot com
  Target Milestone: ---

bool foo(char c)
{
return c >= '0' && c <= '9';
}

bool bar(char c)
{
return c != '\0' && foo(c);
}

bool foobar(char c)
{
return c != '\0' && c >= '0' && c <= '9';
}

// GCC 10
bar(char):
  sub edi, 48
  cmp dil, 9
  setbe al
  ret

// GCC 11
bar(char):
  xor eax, eax
  test dil, dil
  je .L3
  sub edi, 48
  cmp dil, 9
  setbe al
.L3:
  ret

https://godbolt.org/z/z4r9cv

[Bug fortran/98979] [11 regression] ICE in several tests cases after r11-7112

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

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

Tobias Burnus  changed:

   What|Removed |Added

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

--- Comment #13 from Tobias Burnus  ---
Expected to be fixed by the mentioned patches – confirmed to be fixed – well,
then we can also mark as as FIXED!

Thanks for Julian for the commits – and thanks to all for reporting the bug &
checking that it is indeed fixed :-)

[Bug c/99304] [11 Regression] typo in diagnostic: refernced

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 50266
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50266&action=edit
gcc11-pr99304.patch

Untested fix.

[Bug fortran/99300] double space in diagnostic

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug fortran/99303] OpenMP: typo in diagnostic

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

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

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

--- Comment #20 from Iain Sandoe  ---
still failing on Darwin at r11-7425 - is that expected (i.e. patches pending)
or more analysis needed?

long_double.cc:83: test01()::)>:
Assertion '!strcmp(begin, printf_buffer+strlen("0x"))' failed.

[Bug libstdc++/98384] [11 Regression] new test case 20_util/to_chars/long_double.cc in r11-6249 fails on powerpc64 BE

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

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

--- Comment #21 from David Edelsohn  ---
It similarly continues to fail on AIX:

long_double.cc:192: void test02(): Assertion '!memcmp(printf_buffer,
to_chars_buffer, output_length)' failed.

[Bug libstdc++/99306] New: bootstrap failure on msdosdjgpp: error: alignment of 'm' is greater than maximum object file alignment 16

[unlvsur at live dot com via Gcc-bugs]

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

Bug ID: 99306
   Summary: bootstrap failure on msdosdjgpp: error: alignment of
'm' is greater than maximum object file alignment 16
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: unlvsur at live dot com
  Target Milestone: ---

../../../../../gcc/libstdc++-v3/src/c++11/shared_ptr.cc:39:14: error: alignment
of 'm' is greater than maximum object file alignment 16
   39 | static M m[mask + 1];
  |  ^
make[5]: *** [Makefile:648: shared_ptr.lo] Error 1
make[5]: *** Waiting for unfinished jobs
../../../../../gcc/libstdc++-v3/src/c++11/cow-locale_init.cc: In member
function 'void std::locale::_Impl::_M_init_extra(void*, void*, const char*,
const char*)':
../../../../../gcc/libstdc++-v3/src/c++11/cow-locale_init.cc:140:50: warning:
unused parameter 'clocm' [-Wunused-parameter]
  140 |   locale::_Impl::_M_init_extra(void* cloc, void* clocm,
  |~~^
../../../../../gcc/libstdc++-v3/src/c++11/cow-locale_init.cc:141:61: warning:
unused parameter '__smon' [-Wunused-parameter]
  141 |const char* __s, const char* __smon)
  | ^~
make[4]: *** [Makefile:764: all-recursive] Error 1
make[3]: *** [Makefile:568: all-recursive] Error 1
make[2]: *** [Makefile:493: all] Error 2
make[1]: *** [Makefile:11838: all-target-libstdc++-v3] Error 2
make: *** [Makefile:970: all] Error 2

[Bug middle-end/80208] DJGPP max object file alignment regression

[unlvsur at live dot com via Gcc-bugs]

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

cqwrteur  changed:

   What|Removed |Added

 CC||unlvsur at live dot com

--- Comment #3 from cqwrteur  ---
Created attachment 50267
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50267&action=edit
shared_ptr optional no alignment patch

[Bug middle-end/80208] DJGPP max object file alignment regression

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #4 from cqwrteur  ---
(In reply to cqwrteur from comment #3)
> Created attachment 50267 [details]
> shared_ptr optional no alignment patch

sorry. Wrong place

[Bug libstdc++/99306] cross compiler bootstrap failure on msdosdjgpp: error: alignment of 'm' is greater than maximum object file alignment 16

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #1 from cqwrteur  ---
Created attachment 50268
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50268&action=edit
shared_ptr optional no alignment patch

i586 msdosdjgpp compiler ICE

[sotrdg sotrdg via Gcc-bugs]

$ i586-pc-msdosdjgpp-g++ -o a a.cc -Ofast -std=c++20 -s -flto
In file included from 
d:\msys64\i586-pc-msdosdjgpp\lib\gcc\i586-pc-msdosdjgpp\11.0.1\include\immintrin.h:43,
 from ../include/fast_io_core_impl/intrinsics.h:5,
 from ../include/fast_io_core.h:28,
 from ../include/fast_io_freestanding.h:5,
 from ../include/fast_io_hosted.h:9,
 from ../include/fast_io.h:3,
 from fast_io.cc:1:
d:\msys64\i586-pc-msdosdjgpp\lib\gcc\i586-pc-msdosdjgpp\11.0.1\include\avxintrin.h:
 In function '__m256 _mm256_cvtepi32_ps(__m256i)':
d:\msys64\i586-pc-msdosdjgpp\lib\gcc\i586-pc-msdosdjgpp\11.0.1\include\avxintrin.h:463:58:
 internal compiler error: canonical types differ for identical types '__v8si' 
and '__vector(8) int'
  463 |   return (__m256)__builtin_ia32_cvtdq2ps256 ((__v8si) __A);
  |  ^
libbacktrace could not find executable to open
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

Sent from Mail for Windows 10

[Bug c++/94546] [10 Regression] unimplemented: unexpected AST of kind nontype_argument_pack

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

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

--- Comment #7 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jason Merrill
:

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

commit r10-9393-gf98a3c8a58b3cb39d4073e8a5b2671a5d68b8ce4
Author: Jason Merrill 
Date:   Thu Feb 11 19:45:22 2021 -0500

c++: variadic lambda template and empty pack [PR97246]

In get<0>, Is is empty, so the first parameter pack of the lambda is empty,
but after the fix for PR94546 we were wrongly associating it with the
partial instantiation of 'v'.

gcc/cp/ChangeLog:

PR c++/97246
PR c++/94546
* pt.c (extract_fnparm_pack): Check DECL_PACK_P here.
(register_parameter_specializations): Not here.

gcc/testsuite/ChangeLog:

PR c++/97246
* g++.dg/cpp2a/lambda-generic-variadic21.C: New test.

[Bug c++/97246] [10 regression] mismatched argument pack lengths since r10-7865-gaedd04caa945260e

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jason Merrill
:

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

commit r10-9393-gf98a3c8a58b3cb39d4073e8a5b2671a5d68b8ce4
Author: Jason Merrill 
Date:   Thu Feb 11 19:45:22 2021 -0500

c++: variadic lambda template and empty pack [PR97246]

In get<0>, Is is empty, so the first parameter pack of the lambda is empty,
but after the fix for PR94546 we were wrongly associating it with the
partial instantiation of 'v'.

gcc/cp/ChangeLog:

PR c++/97246
PR c++/94546
* pt.c (extract_fnparm_pack): Check DECL_PACK_P here.
(register_parameter_specializations): Not here.

gcc/testsuite/ChangeLog:

PR c++/97246
* g++.dg/cpp2a/lambda-generic-variadic21.C: New test.

[Bug c++/90333] [9/10/11 Regression] Can't apply attributes to lambdas with trailing returns

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

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

--- Comment #13 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Jason Merrill
:

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

commit r10-9394-gf6b1c08e3783bbc3420d95a0357935250d61a29d
Author: Jason Merrill 
Date:   Fri Feb 26 05:45:02 2021 -0500

c++: Allow GNU attributes before lambda -> [PR90333]

In my 9.3/10 patch for 90333 I allowed attributes between [] and (), and
after the trailing return type, but not in the place that GCC 8 expected
them, and we've gotten several bug reports about that.  So let's allow them
there, as well.

gcc/cp/ChangeLog:

PR c++/90333
* parser.c (cp_parser_lambda_declarator_opt): Accept GNU attributes
between () and ->.

gcc/testsuite/ChangeLog:

PR c++/90333
* g++.dg/ext/attr-lambda3.C: New test.

[Bug c++/90333] [9/10/11 Regression] Can't apply attributes to lambdas with trailing returns

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

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

--- Comment #14 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Jason Merrill
:

https://gcc.gnu.org/g:74d34ca781cf94c8b4979c524dbbfbe95863678a

commit r9-9254-g74d34ca781cf94c8b4979c524dbbfbe95863678a
Author: Jason Merrill 
Date:   Fri Feb 26 05:45:02 2021 -0500

c++: Allow GNU attributes before lambda -> [PR90333]

In my 9.3/10 patch for 90333 I allowed attributes between [] and (), and
after the trailing return type, but not in the place that GCC 8 expected
them, and we've gotten several bug reports about that.  So let's allow them
there, as well.

gcc/cp/ChangeLog:

PR c++/90333
* parser.c (cp_parser_lambda_declarator_opt): Accept GNU attributes
between () and ->.

gcc/testsuite/ChangeLog:

PR c++/90333
* g++.dg/ext/attr-lambda3.C: New test.

[Bug c++/90333] [9/10/11 Regression] Can't apply attributes to lambdas with trailing returns

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

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

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

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

commit r11-7430-g5d9d6c1cd8d9f0e057b4a7a849bc765e2109137c
Author: Jason Merrill 
Date:   Fri Feb 26 05:45:02 2021 -0500

c++: Allow GNU attributes before lambda -> [PR90333]

In my 9.3/10 patch for 90333 I allowed attributes between [] and (), and
after the trailing return type, but not in the place that GCC 8 expected
them, and we've gotten several bug reports about that.  So let's allow them
there, as well.

gcc/cp/ChangeLog:

PR c++/90333
* parser.c (cp_parser_lambda_declarator_opt): Accept GNU attributes
between () and ->.

gcc/testsuite/ChangeLog:

PR c++/90333
* g++.dg/ext/attr-lambda3.C: New test.

[Bug target/93353] ICE: in final_scan_insn_1, at final.c:3073 (error: could not split insn)

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

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

--- Comment #8 from Segher Boessenkool  ---
(In reply to Arseny Solokha from comment #5)
> (In reply to Segher Boessenkool from comment #4)
> > I cannot get the reduced testcase to fail.  Are any special options needed?
> 
> If you've been asking me:

Well you reported this, so probably?  :-)

> no, the compiler invocation posted in comment 0 is
> explicit, but maybe you need -m32 -f{,no-}PIC -f{,no-}stack-protector which
> one often does for reproducing my PRs because of the configuration I use.

Maybe that is why I so often cannot reproduce your PRs?  Please always state
the
exact compiler configuration / invocation needed.

> I'll certainly test the current snapshot, but I won't be able to do so at
> least one more week.

Jakub in comment 7 seems to have found the problem.  I cc:ed Alan, who did
4c69e61f4307, which seems to have fixed it on trunk (there is no PR for that
so far?)

[Bug target/93353] ICE: in final_scan_insn_1, at final.c:3073 (error: could not split insn)

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

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

--- Comment #9 from Segher Boessenkool  ---
(In reply to Jakub Jelinek from comment #7)
>   if (low_int >= 0x8000 - extra)
> is not true and 0x7fff - -1 is 0x8000 (with UB on the compiler side).

These are HWIs, so there is no UB.

> But also
>   && ((unsigned HOST_WIDE_INT) (INTVAL (XEXP (x, 1)) + 0x8000)
> can invoke UB in the compiler, shouldn't it be just
>   && ((UINTVAL (XEXP (x, 1)) + 0x8000)
> ?

That sounds right, yes.

[Bug middle-end/99299] Need a recoverable version of __builtin_trap()

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

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

Segher Boessenkool  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-02-27
 Ever confirmed|0   |1

--- Comment #1 from Segher Boessenkool  ---
[ Do we not have a keyword for feature requests, btw?  I don't see one. ]

The only thing needed for GCC is to have a __builtin_trap_no_noreturn (or
something with a less horrible name ;-) ), that does exactly that: it's the
same as __builtin_trap, just not noreturn.  This is useful on most
architectures, not just PowerPC.

[Bug middle-end/99299] Need a recoverable version of __builtin_trap()

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #2 from Andrew Pinski  ---
(In reply to Segher Boessenkool from comment #1)
> [ Do we not have a keyword for feature requests, btw?  I don't see one. ]

Usually enhancement is enough to mark it as a feature request.

[Bug fortran/99307] New: FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test

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

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

Bug ID: 99307
   Summary: FAIL: gfortran.dg/class_assign_4.f90   -O0  execution
test
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa-unknown-linux-gnu
Target: hppa-unknown-linux-gnu
 Build: hppa-unknown-linux-gnu

spawn -ignore SIGHUP
/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran1/../../gfo
rtran -B/home/dave/gnu/gcc/objdir/gcc/testsuite/gfortran1/../../
-B/home/dave/gn
u/gcc/objdir/hppa-linux-gnu/./libgfortran/
/home/dave/gnu/gcc/gcc/gcc/testsuite/
gfortran.dg/class_assign_4.f90 -fdiagnostics-plain-output
-fdiagnostics-plain-ou
tput -O0 -pedantic-errors
-B/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortr
an/.libs -L/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs
-L/home/
dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs
-L/home/dave/gnu/gcc/objd
ir/hppa-linux-gnu/./libatomic/.libs -lm -o ./class_assign_4.exe
PASS: gfortran.dg/class_assign_4.f90   -O0  (test for excess errors)
Setting LD_LIBRARY_PATH to
.:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfort
ran/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs:/home/dav
e/gnu/gcc/objdir/hppa-linux-gnu/./libatomic/.libs:/home/dave/gnu/gcc/objdir/gcc/
testsuite/gfortran1/../..:.:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortr
an/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/./libgfortran/.libs:/home/dave
/gnu/gcc/objdir/hppa-linux-gnu/./libatomic/.libs:/home/dave/gnu/gcc/objdir/gcc/t
estsuite/gfortran1/../..:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libphobos/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libstdc++-v3/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libssp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libphobos/src/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libgomp/.libs:/home/dave/gnu/gcc/objdir/hppa-linux-gnu/libatomic/.libs:/home/dave/gnu/gcc/objdir/./gcc:/home/dave/gnu/gcc/objdir/./prev-gcc
Execution timeout is: 300
spawn [open ...]
corrupted size vs. prev_size

Program received signal SIGABRT: Process abort signal.

Backtrace for this error:
FAIL: gfortran.dg/class_assign_4.f90   -O0  execution test

[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 -O0 execution test

[dominiq at lps dot ens.fr via Gcc-bugs]

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

Dominique d'Humieres  changed:

   What|Removed |Added

   Last reconfirmed||2021-02-27
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Dominique d'Humieres  ---
Also seen on Darwin; the runtime error is

a.out(22702,0x10db51e00) malloc: Incorrect checksum for freed object
0x7ff344406fc0: probably modified after being freed.
Corrupt value: 0x41f7
a.out(22702,0x10db51e00) malloc: *** set a breakpoint in malloc_error_break to
debug

Program received signal SIGABRT: Process abort signal.

Reduced test

module m
  implicit none
  type :: t1
integer :: i
  CONTAINS
  end type
  type, extends(t1) :: t2
real :: r
  end type

  interface operator(+)
module procedure add_t1
  end interface

contains
  function add_t1 (a, b) result (c)
class(t1), intent(in) :: a(:), b(:)
class(t1), allocatable :: c(:)
allocate (c, source = a)
c%i = a%i + b%i
select type (c)
  type is (t2)
  select type (b)
type is (t2)
  c%r = c%r + b%r
  end select
end select
  end function add_t1

end module m

subroutine test_t1
  use m
  implicit none

  class(t1), dimension(:), allocatable :: x, y

  x = [t2(1,10.0),t2(2,20.0),t2(3,30.0)]
  y = x
  x = realloc_t1 (y)
  x = realloc_t1 (x)
  x = x(3:1:-1) + y
  x = [t2(1,10.0),t2(2,20.0),t2(3,30.0)]

contains

  function realloc_t1 (arg) result (res)
class(t1), dimension(:), allocatable :: arg
class(t1), dimension(:), allocatable :: res
select type (arg)
  type is (t2)
allocate (res, source = [t1 (arg(3)%i), t1 (arg(2)%i), t1 (arg(1)%i)])
  type is (t1)
allocate (res, source = [t1 (arg(2)%i), t1 (arg(1)%i), t1 (arg(3)%i)])
end select
  end function realloc_t1

end subroutine test_t1

  call test_t1
end

[Bug c++/98432] [coroutine] leaked frame created using await_transform

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

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

--- Comment #2 from Iain Sandoe  ---
(In reply to Tomáš Hering from comment #1)
> Created attachment 49839 [details]
> preprocessed file that triggers the bug

please could you attach the un-preprocessed source?
I cannot reproduce this with the preprocessed source (I don't have a mingw pc
setup available).

[Bug libfortran/99210] X editing for reading file with encoding='utf-8'

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

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

--- Comment #3 from Jerry DeLisle  ---
Here is the real issue. The X format specifier is a position modifier. UTF-8 is
a variable character length encoding so moving one character could mean move 1,
2, 3, or 4 bytes depending on the content of the file.

Up to now we have chosen to move "position" by 1 byte.

13.8.1.1 Position editing

1 The position edit descriptors T, TL, TR, and X, specify the position at which
the next character will be transmitted to or from the record. If any character
skipped by a position edit descriptor is of type nondefault character,
and the unit is a default character internal file or an external non-Unicode
file, the result of that position editing is processor dependent.

Our interpretation of this has been that the example provided in this PR is
processor dependent. However, the file is opened as encoding='UTF-8'.

So, we have to use UTF-8 based skips for READs.  The following patch does this:

diff --git a/libgfortran/io/read.c b/libgfortran/io/read.c
index 7515d912c51..30ff0e0deb7 100644
--- a/libgfortran/io/read.c
+++ b/libgfortran/io/read.c
@@ -1255,6 +1255,23 @@ read_x (st_parameter_dt *dtp, size_t n)

   if (n == 0)
 return;
+
+  if (dtp->u.p.current_unit->flags.encoding == ENCODING_UTF8)
+{
+  gfc_char4_t c;
+  size_t nbytes, j;
+
+  /* Proceed with decoding one character at a time.  */
+  for (j = 0; j < n; j++)
+   {
+ c = read_utf8 (dtp, &nbytes);
+
+ /* Check for a short read and if so, break out.  */
+ if (nbytes == 0 || c == (gfc_char4_t)0)
+   break;
+   }
+  return;
+}

   length = n;

The remaining part of this is what to do for end of file conditions.  So, I am
doing a little mor testing.

[Bug c++/90333] [9/10/11 Regression] Can't apply attributes to lambdas with trailing returns

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #16 from Jason Merrill  ---
Fixed better for 9.4/10.3/11.

[Bug middle-end/99299] Need a recoverable version of __builtin_trap()

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

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

--- Comment #3 from Segher Boessenkool  ---
Ah, thank you.  Well except there is no keyword called that?