[Bug libgcc/107026] [13 Regression] gcc_assert (in_shutdown || ob); build failure for i586-msdosdjgpp target

[tneumann at users dot sourceforge.net via Gcc-bugs]

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

--- Comment #6 from Thomas Neumann  ---
I have a patch ready, I am waiting for approval:

https://gcc.gnu.org/pipermail/gcc-patches/2022-September/602130.html

When using the atomic fast path deregistering can fail during
program shutdown if the lookup structures are already destroyed.
The assert in __deregister_frame_info_bases takes that into
account. In the non-fast-path case however is not aware of
program shutdown, which caused a compiler error on such platforms.
We fix that by introducing a constant for in_shutdown in
non-fast-path builds.

libgcc/ChangeLog:
* unwind-dw2-fde.c: Introduce a constant for in_shutdown
for the non-fast-path case.
---
 libgcc/unwind-dw2-fde.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/libgcc/unwind-dw2-fde.c b/libgcc/unwind-dw2-fde.c
index d237179f4ea..0bcd5061d76 100644
--- a/libgcc/unwind-dw2-fde.c
+++ b/libgcc/unwind-dw2-fde.c
@@ -67,6 +67,8 @@ static void
 init_object (struct object *ob);

 #else
+/* Without fast path frame deregistration must always succeed.  */
+static const int in_shutdown = 0;

 /* The unseen_objects list contains objects that have been registered
but not yet categorized in any way.  The seen_objects list has had
-- 
2.34.1

[Bug target/96072] [10/11/12 Regression] ICE: Segmentation fault (in add_reg_note)

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

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

--- Comment #8 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

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

commit r13-2846-g5be0950d22209f5ba69d244387228e12389a8470
Author: Kewen Lin 
Date:   Mon Sep 26 00:33:18 2022 -0500

rs6000: Fix the condition with frame_pointer_needed_indeed [PR96072]

As PR96072 shows, the code adding REG_CFA_DEF_CFA reg note
makes one assumption that we have emitted one insn which
restores the frame pointer previously.  That part of code
was guarded with flag frame_pointer_needed before, it was
consistent, but it was replaced with flag
frame_pointer_needed_indeed since commit r10-7981.  It
caused ICE due to unexpected NULL insn.

PR target/96072

gcc/ChangeLog:

* config/rs6000/rs6000-logue.cc (rs6000_emit_epilogue): Update the
condition for adding REG_CFA_DEF_CFA reg note with
frame_pointer_needed_indeed.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr96072.c: New test.

[Bug target/94962] Suboptimal AVX2 code for _mm256_zextsi128_si256(_mm_set1_epi8(-1))

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r13-2845-g9c9cf4f087f28dc3bf8dfa769380b3b58728a0f7
Author: Hu, Lin1 
Date:   Mon Sep 26 10:15:08 2022 +0800

testsuite: Fix up avx256-unaligned-store-3.c test.

gcc/testsuite/ChangeLog:

PR target/94962
* gcc.target/i386/avx256-unaligned-store-3.c: Add -mno-avx512f

[Bug target/53346] [4.6/4.7/4.8 Regression] Bad if conversion in cptrf2 of rnflow.f90

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

 CC||crazylht at gmail dot com

--- Comment #26 from Hongtao.liu  ---
(In reply to CVS Commits from comment #25)
> The master branch has been updated by hongtao Liu :
> 
> https://gcc.gnu.org/g:3db8e9c2422d924a958336fd0871b24cce3e65d1
> 
> commit r13-2843-g3db8e9c2422d924a958336fd0871b24cce3e65d1
> Author: liuhongt 
> Date:   Wed Sep 21 14:56:08 2022 +0800
> 
> Support 2-instruction vector shuffle for V4SI/V4SF in
> ix86_expand_vec_perm_const_1.
> 
> 2022-09-23  Hongtao Liu  
> Liwei Xu  
> 
> gcc/ChangeLog:
> 
> PR target/53346
> * config/i386/i386-expand.cc (expand_vec_perm_shufps_shufps):
> New function.
> (ix86_expand_vec_perm_const_1): Insert
> expand_vec_perm_shufps_shufps at the end of 2-instruction
> expand sequence.
> 
> gcc/testsuite/ChangeLog:
> 
> * gcc.target/i386/pr53346-1.c: New test.
> * gcc.target/i386/pr53346-2.c: New test.
> * gcc.target/i386/pr53346-3.c: New test.
> * gcc.target/i386/pr53346-4.c: New test.

Sorry, it should be PR54346

[Bug target/100645] ICE in related_vector_mode, at stor-layout.c:537

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

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

--- Comment #3 from CVS Commits  ---
The master branch has been updated by Kewen Lin :

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

commit r13-2844-gbfad7069b74c97000b698191c1945f07a6192db5
Author: Kewen Lin 
Date:   Sun Sep 25 22:01:50 2022 -0500

rs6000: Fix condition of define_expand vec_shr_ [PR100645]

PR100645 exposes one latent bug in define_expand vec_shr_
that the current condition TARGET_ALTIVEC is too loose.  The
mode iterator VEC_L contains a few modes, they are not always
supported as vector mode, VECTOR_UNIT_ALTIVEC_OR_VSX_P should
be used like some other VEC_L usages.

PR target/100645

gcc/ChangeLog:

* config/rs6000/vector.md (vec_shr_): Replace condition
TARGET_ALTIVEC with VECTOR_UNIT_ALTIVEC_OR_VSX_P.

gcc/testsuite/ChangeLog:

* gcc.target/powerpc/pr100645.c: New test.

[Bug target/53346] [4.6/4.7/4.8 Regression] Bad if conversion in cptrf2 of rnflow.f90

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

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

--- Comment #25 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r13-2843-g3db8e9c2422d924a958336fd0871b24cce3e65d1
Author: liuhongt 
Date:   Wed Sep 21 14:56:08 2022 +0800

Support 2-instruction vector shuffle for V4SI/V4SF in
ix86_expand_vec_perm_const_1.

2022-09-23  Hongtao Liu  
Liwei Xu  

gcc/ChangeLog:

PR target/53346
* config/i386/i386-expand.cc (expand_vec_perm_shufps_shufps):
New function.
(ix86_expand_vec_perm_const_1): Insert
expand_vec_perm_shufps_shufps at the end of 2-instruction
expand sequence.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr53346-1.c: New test.
* gcc.target/i386/pr53346-2.c: New test.
* gcc.target/i386/pr53346-3.c: New test.
* gcc.target/i386/pr53346-4.c: New test.

[Bug lto/107036] New: Emitted binary code changes when -g is enabled at -O1 -flto and optimize attribute

[tlwang at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 107036
   Summary: Emitted binary code changes when -g is enabled at -O1
-flto and optimize attribute
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tlwang at uwaterloo dot ca
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

This occurs when compiling attributes_program0_preprocessed.c as shown below:

$ cat attributes_program0_preprocessed.c
struct {
  volatile short a;
  int b;
} c = {1};
void d() { short e = c.b; }
void f() {}
void g() { c.a; }
__attribute__((optimize(0))) int main() {
  f(g);
  d();
}
$ gcc-trunk -v
Using built-in specs.
COLLECT_GCC=gcc-trunk
COLLECT_LTO_WRAPPER=/scratch/software/gcc-trunk/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.KbBz3lKFoo-gcc-builder/gcc/configure
--enable-languages=c,c++,lto --enable-checking-yes --enable-multiarch
--prefix=/scratch/software/gcc-trunk --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.0.0 20220925 (experimental) [master -g28a61ecdc] (GCC)
tlwang@cartesian:~/inline_asm_bugs/3966721184$ gcc-trunk -w -flto -O1
attributes_program0_preprocessed.c -o a.out ; objdump --disassemble
--section=.text a.out > no_dbg.txt
$ gcc-trunk -w -flto -O1 attributes_program0_preprocessed.c -g -o a.out ;
objdump --disassemble --section=.text a.out > dbg.txt
$ diff no_dbg.txt dbg.txt
98,100c98,101
<   401113: 0f b7 05 ee 0e 00 00movzwl 0xeee(%rip),%eax# 402008

<   40111a: c3  retq
<   40111b: 0f 1f 44 00 00  nopl   0x0(%rax,%rax,1)
---
>   401113: c3  retq
>   401114: 66 2e 0f 1f 84 00 00nopw   %cs:0x0(%rax,%rax,1)
>   40111b: 00 00 00
>   40111e: 66 90   xchg   %ax,%ax

[Bug c++/99631] decltype of non-type template-parameter shouldn't be const

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Johel Ernesto Guerrero Peña  ---
> But wrong-code isn't really right either [...]

Oh, you already mentioned them. I suggest 'non-conforming-result', or something
more appropriate than "result" to indicate the metaprogrammingness of it.

[Bug c++/99631] decltype of non-type template-parameter shouldn't be const

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Johel Ernesto Guerrero Peña  ---
Would the existing 'wrong-code' work?

> Generates incorrect code. Has to be able to compile and link.

[Bug libfortran/107031] endfile truncates file at wrong position

[sgk at troutmask dot apl.washington.edu via Gcc-bugs]

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

--- Comment #5 from Steve Kargl  ---
On Sun, Sep 25, 2022 at 08:56:22PM +, kargl at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031
> 
> --- Comment #4 from kargl at gcc dot gnu.org ---
> (In reply to anlauf from comment #3)
> > (In reply to kargl from comment #2)
> > > gfortran's current behavior is correct.
> > > 
> > > 
> > >12.3.4.4 File position after data transfer
> > > 
> > >In all other cases, the file is positioned after the record just
> > >read or written and that record becomes the preceding record.
> > > 
> > >12.8.3 ENDFILE statement
> > > 
> > >Execution of an ENDFILE statement for a file connected for sequential
> > >access writes an endfile record as the next record of the file.
> > > 
> > > After reading '5', the file is position at the record that contains '6'.
> > > So, ENDIFLE writes the endfile record after the record with '6'.
> > 
> > Hmm, interpretation of text?
> > 
> > I read "as the next record", not "after the next record".
> > 
> > gfortran differs here from Intel, NAG, Nvidia, AMD Flang, Crayftn.
> 
> If the current record contain '6', the next record contains '7'.
> 'next' does not mean 'current' in the English language.  It means
> something that 'follows'.
> 

Further confusion, maybe?

12.3.4 File position

12.3.4.1 General
...
Let n be the number of records in the file.
...
If 1 <= i < n and a file is positioned within the ith record or
between the ith and (i + 1)th record, the (i + 1)th record is the
next record.

[Bug libgcc/107026] [13 Regression] gcc_assert (in_shutdown || ob); build failure for i586-msdosdjgpp target

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

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

Tamar Christina  changed:

   What|Removed |Added

 CC||tneumann at users dot 
sourceforge.
   ||net

--- Comment #5 from Tamar Christina  ---
CC'ing author.

[Bug libgcc/107026] [13 Regression] gcc_assert (in_shutdown || ob); build failure for i586-msdosdjgpp target

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

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

Tamar Christina  changed:

   What|Removed |Added

 Target|i586-msdosdjgpp |i586-msdosdjgpp,
   ||aarch64-none-elf
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=107018
 CC||tnfchris at gcc dot gnu.org

--- Comment #4 from Tamar Christina  ---
Also broken on AArch64

[Bug target/107035] [avr] internal compiler error: in add_clobbers, at config/avr/avr-dimode.md

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 105753.

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

[Bug target/105753] [avr] ICE: in add_clobbers, at config/avr/avr-dimode.md:2705

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||kovy3 at seznam dot cz

--- Comment #6 from Andrew Pinski  ---
*** Bug 107035 has been marked as a duplicate of this bug. ***

[Bug c++/107035] New: [avr] internal compiler error: in add_clobbers, at config/avr/avr-dimode.md

[kovy3 at seznam dot cz via Gcc-bugs]

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

Bug ID: 107035
   Summary: [avr] internal compiler error: in add_clobbers, at
config/avr/avr-dimode.md
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kovy3 at seznam dot cz
  Target Milestone: ---

Created attachment 53626
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53626=edit
Preprocessed source, compiler command lines and err. output

Hello, I would like to report an repeatable internal compiler error outputs
with AVR-GCC 12.2.0 (and 12.1.0 too):



during RTL pass*: combine

Print.cpp: In function print.constprop.isra

Print.cpp:112: internal compiler error  in add_clobbers, at
config\avr\avr-dimode.md
   112 | }
   | ^
   libbacktrace could not find executable to open
   Please submit a full bug report, with preprocessed source (by using
-freport-bug)
   gcc.gnu.org\bugs\> for instructions

lto-wrapper.exe*: fatal error:
C:\Users\kovar\AppData\Local\arduino15\packages\arduino\tools\avr-gcc\avr-gcc-12.2.0-x86-windows\bin\avr-gcc
returned 1 exit status
   compilation terminated




In opposite, I tested AVR-GCC 11.1 on the same source code with NO ERROR
result.



I'm attaching preprocessed source code and command line invocations with
compiler output.



Development env. platform: Windows 11
Target: AVR

avr-gcc -v  output:

Using built-in specs.
Reading specs from
c:/users/kovar/appdata/local/arduino15/packages/arduino/tools/avr-gcc/avr-gcc-12.2.0-x86-windows/bin/../lib/gcc/avr/12.2.0/device-specs/specs-avr2
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=c:/users/kovar/appdata/local/arduino15/packages/arduino/tools/avr-gcc/avr-gcc-12.2.0-x86-windows/bin/../libexec/gcc/avr/12.2.0/lto-wrapper.exe
Target: avr
Configured with: ../configure --prefix=/omgwtfbbq/avr-gcc-12.2.0-x86-windows
--target=avr --enable-languages=c,c++ --disable-nls --disable-libssp
--disable-libada --with-dwarf2 --disable-shared --enable-static
--enable-mingw-wildcard --enable-plugin --with-gnu-as --host=i686-w64-mingw32
--build=x86_64-pc-linux-gnu
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 12.2.0 (GCC)



Thanks,


Petr

[Bug c++/107034] SIGSEGV in code using c style array

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
The array is on the stack and the stack space is limited.
You can fix this via not using the stack or increase the stack size.

[Bug fortran/100029] ICE on subroutine call with allocatable polymorphic assumed-rank argument

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Rebased patch pinged here:

https://gcc.gnu.org/pipermail/fortran/2022-September/058247.html

[Bug libfortran/107031] endfile truncates file at wrong position

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

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

--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to anlauf from comment #3)
> (In reply to kargl from comment #2)
> > gfortran's current behavior is correct.
> > 
> > 
> >12.3.4.4 File position after data transfer
> > 
> >In all other cases, the file is positioned after the record just
> >read or written and that record becomes the preceding record.
> > 
> >12.8.3 ENDFILE statement
> > 
> >Execution of an ENDFILE statement for a file connected for sequential
> >access writes an endfile record as the next record of the file.
> > 
> > After reading '5', the file is position at the record that contains '6'.
> > So, ENDIFLE writes the endfile record after the record with '6'.
> 
> Hmm, interpretation of text?
> 
> I read "as the next record", not "after the next record".
> 
> gfortran differs here from Intel, NAG, Nvidia, AMD Flang, Crayftn.

If the current record contain '6', the next record contains '7'.
'next' does not mean 'current' in the English language.  It means
something that 'follows'.

[Bug c++/107034] New: SIGSEGV in code using c style array

[menkaur at gmail dot com via Gcc-bugs]

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

Bug ID: 107034
   Summary: SIGSEGV in code using c style array
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: menkaur at gmail dot com
  Target Milestone: ---

Created attachment 53625
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53625=edit
c++ code to reproduce the bug

Attached code will result in address boundary error or similar issues at the
first line in any method that contains it.

To get it to work, run `g++ -O0 main.cpp -o test && ./test`

I had a bug where I was passing arguments into method that contained similar
code, and, when examined in gdb, I was passing valid arguments and receiving
invalid arguments inside.

Bug only became apparent to me when using large enough array

[Bug fortran/41453] use INTENT(out) for optimization

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

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

--- Comment #16 from Thomas Koenig  ---
(In reply to Mikael Morin from comment #15)
> Status update:

A lot of progress :-)

> (In reply to Thomas Koenig from comment #5)
> > Still missing: To clobber
> > 
> > - variables passed by reference to the caller
> > - saved variables
> > - associated variables (there are passed as pointers to
> >   the associate blocsk)
> These have been done now.
> 
> Still missing: pointer or allocatable dummy.
> Seems doable, probably a low hanging fruit.

For an allocatable dummy, we have to deallocate on intent(out)
anyway, and we do this on the caller's side, so we should not clobber. 
For pointers, it could be an advantage.

> > - intent(out) variables on entry to the procedure.
> This remains to do.

Again, sounds doable


> Another case that could be handled is the case of arrays:
> when the full array is passed as argument, and it is contiguous, and maybe
> some other condition, we can clobber its decl.  The hard part is the "maybe
> some other condition".

Not sure what that other condition could be.  If we have a full array ref, as
per gfc_full_array_ref_p, and we pass this to an intent(out) argument,
then that should be enough.

> Not sure it's worth keeping this PR open.
> Surely the initial test works as expected, and has been working for a long
> time.

There are still a few open points in relation to this.  I would be in
favor of keeping this open (to not lose the discussion) until we have
them all fixed, or decide not to fix some or all of them.

[Bug libfortran/107031] endfile truncates file at wrong position

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

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

--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #2)
> gfortran's current behavior is correct.
> 
> 
>12.3.4.4 File position after data transfer
> 
>In all other cases, the file is positioned after the record just
>read or written and that record becomes the preceding record.
> 
>12.8.3 ENDFILE statement
> 
>Execution of an ENDFILE statement for a file connected for sequential
>access writes an endfile record as the next record of the file.
> 
> After reading '5', the file is position at the record that contains '6'.
> So, ENDIFLE writes the endfile record after the record with '6'.

Hmm, interpretation of text?

I read "as the next record", not "after the next record".

gfortran differs here from Intel, NAG, Nvidia, AMD Flang, Crayftn.

[Bug lto/107014] flatten+lto fails the kernel build

[andi-gcc at firstfloor dot org via Gcc-bugs]

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

Andi Kleen  changed:

   What|Removed |Added

 CC||andi-gcc at firstfloor dot org

--- Comment #9 from Andi Kleen  ---
I suspect what happens is that it hits in some kernel initialization function.
If they don't use initcall the LTO build can all inline them into each other
(because they are only called once) creating a single big initialization
function. With flatten that will create an extremely large function that takes
a long time to process.

I suspect any use of flatten is better using always_inline, since that affects
only a single function. Should probably be fixed upstream in the kernel.

[Bug libfortran/107031] endfile truncates file at wrong position

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
 Status|NEW |WAITING

--- Comment #2 from kargl at gcc dot gnu.org ---
gfortran's current behavior is correct.


   12.3.4.4 File position after data transfer

   In all other cases, the file is positioned after the record just
   read or written and that record becomes the preceding record.

   12.8.3 ENDFILE statement

   Execution of an ENDFILE statement for a file connected for sequential
   access writes an endfile record as the next record of the file.

After reading '5', the file is position at the record that contains '6'.
So, ENDIFLE writes the endfile record after the record with '6'.

[Bug target/106972] internal compiler error: in extract_insn, at recog.c:2770 on ARMeb when building gcc itself

[thomas.petazzoni--- via Gcc-bugs]

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

Thomas Petazzoni  changed:

   What|Removed |Added

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

--- Comment #7 from Thomas Petazzoni  ---
Thanks for the feedback. We have disabled support for iwmmxt in Buildroot, so
this issue is no longer a problem for us. I will therefore close, marking as
WONTFIX, as it was indicated that this would not be fixed.

[Bug target/101989] Fail to optimize (a & b) | (c & ~b) to vpternlog instruction.

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

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

ak at gcc dot gnu.org changed:

   What|Removed |Added

 CC||rth at gcc dot gnu.org

--- Comment #8 from ak at gcc dot gnu.org ---
*** Bug 93768 has been marked as a duplicate of this bug. ***

[Bug target/93768] Use vpternlog for composite logical operations

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

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

ak at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #2 from ak at gcc dot gnu.org ---
Most of it is already done as part of PR101989

One issue is that it is only for suitable vector types, it doesn't really work
for scalars because the compiler has no idea that a conversion might be
profitable. Perhaps that would be an interesting (but likely) separate feature
to define some frame work to figure out if switching to the vector ISA is worth
it.

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

[Bug libfortran/107031] endfile truncates file at wrong position

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

  Component|fortran |libfortran
 Ever confirmed|0   |1
   Keywords||wrong-code
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-09-25

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

It appears that this issue exists since 2005.

[Bug c++/106826] [13 Regression] [modules] Variable template of type trait via importable header gives wrong result

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #8 from Johel Ernesto Guerrero Peña  ---
The original reproducer now ICEs. I opened Bug 107033 for this. The tests added
in https://gcc.gnu.org/g:32d8123cd6ce87acb557aec230e8359051316f9f uses a named
module. My reproducer uses an importable header.

[Bug c++/107033] [13 Regression] [modules] ICE using span as a range

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Johel Ernesto Guerrero Peña  ---
This is actually Bug 106826.

Simplest: https://godbolt.org/z/oKT4x9r4G.

```C++
template constexpr bool is = false;
template constexpr bool is = true;
```

```C++
export module mod;
import "std.hpp";
static_assert(is);
```

```
mod.cpp:1:8: internal compiler error: Segmentation fault
1 | export module mod;
  |^~
0x234bd6e internal_error(char const*, ...)
???:0
0xc84cfe walk_specializations(bool, void (*)(bool, spec_entry*, void*), void*)
???:0
0xbead4c depset::hash::add_specializations(bool)
???:0
0xbfb5a8 module_state::write_begin(elf_out*, cpp_reader*, module_state_config&,
unsigned int&)
???:0
0xbfcd45 finish_module_processing(cpp_reader*)
???:0
0xb89d2e c_parse_final_cleanups()
???:0
0xdb0cc8 c_common_parse_file()
???:0
```

[Bug fortran/41453] use INTENT(out) for optimization

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

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

Mikael Morin  changed:

   What|Removed |Added

 CC||mikael at gcc dot gnu.org

--- Comment #15 from Mikael Morin  ---
Status update:

(In reply to Thomas Koenig from comment #5)
> Still missing: To clobber
> 
> - variables passed by reference to the caller
> - saved variables
> - associated variables (there are passed as pointers to
>   the associate blocsk)
These have been done now.

Still missing: pointer or allocatable dummy.
Seems doable, probably a low hanging fruit.

> - intent(out) variables on entry to the procedure.
This remains to do.

(In reply to Thomas Koenig from comment #7)
> Also still to do: Do some more precise clobbering for
> the case of PR88364, i.e. for
> 
> call foo(a)
> 
> clobber a%x, which is currently not done.

This is impossible for now on the caller side because of lack of middle-end
support: only full variable declarations can be clobbered, or pointer targets.
There was a patch to handle the case above, but it was dropped for that reason.
See: https://gcc.gnu.org/pipermail/fortran/2022-September/058181.html
Maybe part of that patch can be resurrected, but restricted to the case of
allocatable or pointer components.

Another case that could be handled is the case of arrays:
when the full array is passed as argument, and it is contiguous, and maybe some
other condition, we can clobber its decl.  The hard part is the "maybe some
other condition".

Not sure it's worth keeping this PR open.
Surely the initial test works as expected, and has been working for a long
time.

[Bug c++/107033] [13 Regression] [modules] ICE using span as a range

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Johel Ernesto Guerrero Peña  ---
Simplified: https://godbolt.org/z/3Ys316aeE.

```C++
export module mod;
import "std.hpp";
int x[2];
export auto _ = std::ranges::begin(x);
```

[Bug c++/107033] [13 Regression] [modules] ICE converting to span

[johelegp at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Johel Ernesto Guerrero Peña  ---
Does it count as a regression if rejects-valid becomes ice-on-valid-code? IIRC,
~3 weeks ago the lvalue case was rejects-valid, like GCC12.

[Bug c++/107033] [13 Regression] [modules] ICE converting to span

[johelegp at gmail dot com via Gcc-bugs]

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

Johel Ernesto Guerrero Peña  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Known to fail||11.3.0, 12.2.0

--- Comment #1 from Johel Ernesto Guerrero Peña  ---
Simplified. GCC12 only accepts when the span is an lvalue, and otherwise is
rejects-valid. GCC11 and GCC13 are ice-on-valid-code with different backtraces.

GCC11: https://godbolt.org/z/ev5Wb4d3v
GCC12: https://godbolt.org/z/bo6f5nT7Y
GCC13: https://godbolt.org/z/qGdWq4383
GCC12 lvalue: https://godbolt.org/z/zoz69ener

GCC11:
```
In file included from /app/std.hpp:2,
of module /app/std.hpp, imported at /app/mod.cpp:2:
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/span: In instantiation of
'class std::span':
mod.cpp:3:51:   required from here
/opt/compiler-explorer/gcc-11.3.0/include/c++/11.3.0/span:155:9: internal
compiler error: Segmentation fault
  155 | span(_It __first, size_type __count)
  | ^~~~
0x17888c9 internal_error(char const*, ...)
???:0
0x7da897 tsubst(tree_node*, tree_node*, int, tree_node*)
???:0
0x7f6feb instantiate_class_template(tree_node*)
???:0
0x82a7f3 complete_type(tree_node*)
???:0
0x806c31 finish_compound_literal(tree_node*, tree_node*, int, fcl_t)
???:0
0x7c123b c_parse_file()
???:0
0x894042 c_common_parse_file()
???:0
```

GCC12:
```
mod.cpp:3:35: error: no match for call to '(const
std::ranges::__cust_access::_Begin) (std::span)'
3 | export auto _ = std::ranges::begin(std::span{});
  | ~~^~
In file included from
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/string_view:50,
 from
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/basic_string.h:47,
 from
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/string:53,
 from
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/locale_classes.h:40,
 from
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/ios_base.h:41,
 from
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/streambuf:41,
 from
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/streambuf_iterator.h:35,
 from
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/iterator:66,
 from
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/ranges:43,
 from /app/std.hpp:1,
of module /app/std.hpp, imported at /app/mod.cpp:2:
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/ranges_base.h:114:9:
note: candidate: 'template  requires (__maybe_borrowed_range<_Tp>)
&& ((is_array_v::type>) ||
(__member_begin<_Tp>) || (__adl_begin<_Tp>)) constexpr auto
std::ranges::__cust_access::_Begin::operator()(_Tp&&) const'
  114 | operator()[[nodiscard]](_Tp&& __t) const
noexcept(_S_noexcept<_Tp&>())
  | ^~~~
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/ranges_base.h:114:9:
note:   template argument deduction/substitution failed:
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/ranges_base.h:114:9:
note: constraints not satisfied
mod.cpp: In substitution of 'template  requires
(__maybe_borrowed_range<_Tp>) && ((is_array_v::type>) || (__member_begin<_Tp>) ||
(__adl_begin<_Tp>)) constexpr auto
std::ranges::__cust_access::_Begin::operator()(_Tp&&) const [with _Tp =
std::span]':
mod.cpp:3:35:   required from here
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/ranges_base.h:83:15: 
 required for the satisfaction of '__maybe_borrowed_range<_Tp>' [with _Tp =
std::span]
/opt/compiler-explorer/gcc-12.2.0/include/c++/12.2.0/bits/ranges_base.h:85:11:
note: no operand of the disjunction is satisfied
   84 | = is_lvalue_reference_v<_Tp>
  |   ~~
   85 |   || enable_borrowed_range>;
  |   ^
cc1plus: note: set '-fconcepts-diagnostics-depth=' to at least 2 for more
detail
mod.cpp:1:8: warning: not writing module 'mod' due to errors
1 | export module mod;
  |^~
```

GCC13:
```
mod.cpp:1:8: internal compiler error: Segmentation fault
1 | export module mod;
  |^~
0x234bd6e internal_error(char const*, ...)
???:0
0xc84cfe walk_specializations(bool, void (*)(bool, spec_entry*, void*), void*)
???:0
0xbead4c depset::hash::add_specializations(bool)
???:0
0xbfb5a8 module_state::write_begin(elf_out*, cpp_reader*, module_state_config&,
unsigned int&)
???:0
0xbfcd45 finish_module_processing(cpp_reader*)
???:0
0xb89d2e c_parse_final_cleanups()
???:0
0xdb0cc8 c_common_parse_file()
???:0
```

[Bug c++/107033] New: [13 Regression] [modules] ICE converting to span

[johelegp at gmail dot com via Gcc-bugs]

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

Bug ID: 107033
   Summary: [13 Regression] [modules] ICE converting to span
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: johelegp at gmail dot com
CC: johelegp at gmail dot com
  Target Milestone: ---

See GCC trunk: https://godbolt.org/z/KoP5qo1Ks.
See GCC 12: https://godbolt.org/z/EfGjdcYaW.


```sh
CXX=/home/johel/root/gcc/bin/g++
echo "./std.hpp std.gcm
mod mod.gcm" > mm.txt
echo "#include 
#include " > std.hpp
echo "export module mod;
import \"std.hpp\";
constexpr std::array a = {};
export constexpr std::span s   = a;" > mod.cpp
$CXX -std=c++23 -fmodules-ts -fmodule-mapper=mm.txt -x c++-header -c std.hpp
$CXX -std=c++23 -fmodules-ts -fmodule-mapper=mm.txt -c mod.cpp
```

Output:
```
mod.cpp:1:8: internal compiler error: Segmentation fault
1 | export module mod;
  |^~
0x22c23ec internal_error(char const*, ...)
???:0
0xba7787 walk_specializations(bool, void (*)(bool, spec_entry*, void*), void*)
???:0
0xafa362 depset::hash::add_specializations(bool)
???:0
0xb0ab3c module_state::write_begin(elf_out*, cpp_reader*, module_state_config&,
unsigned int&)
???:0
0xb0c044 finish_module_processing(cpp_reader*)
???:0
0xa95334 c_parse_final_cleanups()
???:0
0xccde92 c_common_parse_file()
???:0
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.
```

[Bug tree-optimization/107029] [13 Regression] ice during GIMPLE pass: reassoc

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

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

--- Comment #1 from Jakub Jelinek  ---
Created attachment 53624
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=53624=edit
gcc13-pr107029.patch

Untested fix.

[Bug fortran/41453] use INTENT(out) for optimization

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

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

--- Comment #13 from CVS Commits  ---
The master branch has been updated by Mikael Morin :

https://gcc.gnu.org/g:95375ffb3dd59f51e79408dd3b2b620dc1af71b1

commit r13-2840-g95375ffb3dd59f51e79408dd3b2b620dc1af71b1
Author: Mikael Morin 
Date:   Thu Sep 1 11:27:36 2022 +0200

fortran: Support clobbering of allocatables and pointers [PR41453]

This adds support for clobbering of allocatable and pointer scalar
variables passed as actual argument to a subroutine when the associated
dummy has the INTENT(OUT) attribute.
Support was explicitly disabled (since the beginning for pointers, since
r11-7315-g2df374b337a5f6cf5528e91718e4e12e4006b7ae for allocatables),
but the clobber generation code seems to support it well, as
demonstrated by the newly added testcase.

PR fortran/41453
PR fortran/99169

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Remove conditions
on ALLOCATABLE and POINTER attributes guarding clobber
generation.

gcc/testsuite/ChangeLog:

* gfortran.dg/intent_optimize_9.f90: New test.

[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Mikael Morin :

https://gcc.gnu.org/g:95375ffb3dd59f51e79408dd3b2b620dc1af71b1

commit r13-2840-g95375ffb3dd59f51e79408dd3b2b620dc1af71b1
Author: Mikael Morin 
Date:   Thu Sep 1 11:27:36 2022 +0200

fortran: Support clobbering of allocatables and pointers [PR41453]

This adds support for clobbering of allocatable and pointer scalar
variables passed as actual argument to a subroutine when the associated
dummy has the INTENT(OUT) attribute.
Support was explicitly disabled (since the beginning for pointers, since
r11-7315-g2df374b337a5f6cf5528e91718e4e12e4006b7ae for allocatables),
but the clobber generation code seems to support it well, as
demonstrated by the newly added testcase.

PR fortran/41453
PR fortran/99169

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Remove conditions
on ALLOCATABLE and POINTER attributes guarding clobber
generation.

gcc/testsuite/ChangeLog:

* gfortran.dg/intent_optimize_9.f90: New test.

[Bug fortran/87401] [9 Regression] Runtime segfault with associated intent(out) variable

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Mikael Morin :

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

commit r13-2839-gd5e1935b09fa05093e31d7ce5e21b7e71957c103
Author: Mikael Morin 
Date:   Wed Aug 31 11:58:08 2022 +0200

fortran: Support clobbering of ASSOCIATE variables [PR41453]

This is in spirit a revert of:
r9-3051-gc109362313623d83fe0a5194bceaf994cf0c6ce0

That commit added a condition to avoid generating ICE with clobbers
of ASSOCIATE variables.
The test added at that point continues to pass if we remove that
condition now.

PR fortran/41453
PR fortran/87401

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Remove condition
disabling clobber generation for ASSOCIATE variables.

gcc/testsuite/ChangeLog:

* gfortran.dg/intent_optimize_8.f90: New test.

[Bug fortran/87395] [9 Regression] ICE in in lookup_field_for_decl with whizard

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Mikael Morin :

https://gcc.gnu.org/g:467ef2c40dbaf9d1219d9642e90df77dc61f4fae

commit r13-2838-g467ef2c40dbaf9d1219d9642e90df77dc61f4fae
Author: Mikael Morin 
Date:   Wed Aug 31 11:54:47 2022 +0200

fortran: Support clobbering of SAVE variables [PR41453]

This removes a condition added in:
r9-3032-gee7fb0588c6361b4d77337ab0f7527be64fcdde2.

That commit added a condition to avoid generating ICE with clobbers
of variables with the SAVE attribute.
The test added at that point continues to pass if we remove that
condition now.

PR fortran/41453
PR fortran/87395

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Remove condition
on SAVE attribute guarding clobber generation.

gcc/testsuite/ChangeLog:

* gfortran.dg/intent_optimize_7.f90: New test.

[Bug fortran/41453] use INTENT(out) for optimization

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

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

--- Comment #14 from CVS Commits  ---
The master branch has been updated by Mikael Morin :

https://gcc.gnu.org/g:77bbf69d2981dafc2ef3e59bfbefb645d88bab9d

commit r13-2841-g77bbf69d2981dafc2ef3e59bfbefb645d88bab9d
Author: Mikael Morin 
Date:   Thu Sep 1 12:35:07 2022 +0200

fortran: Support clobbering of derived types [PR41453]

This adds support for clobbering of non-polymorphic derived type
variables, when they are passed as actual argument whose associated
dummy has the INTENT(OUT) attribute.

We avoid to play with non-constant type sizes or class descriptors by
requiring that the types are derived (not class) and strictly matching,
and by excluding parameterized derived types.

Types that are used in the callee are also excluded: they are types with
allocatable components (the components will be deallocated), and
finalizable types or types with finalizable components (they will be
passed to finalization routines).

PR fortran/41453

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Allow strictly
matching derived types.

gcc/testsuite/ChangeLog:

* gfortran.dg/intent_optimize_10.f90: New test.

[Bug fortran/41453] use INTENT(out) for optimization

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

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

--- Comment #12 from CVS Commits  ---
The master branch has been updated by Mikael Morin :

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

commit r13-2839-gd5e1935b09fa05093e31d7ce5e21b7e71957c103
Author: Mikael Morin 
Date:   Wed Aug 31 11:58:08 2022 +0200

fortran: Support clobbering of ASSOCIATE variables [PR41453]

This is in spirit a revert of:
r9-3051-gc109362313623d83fe0a5194bceaf994cf0c6ce0

That commit added a condition to avoid generating ICE with clobbers
of ASSOCIATE variables.
The test added at that point continues to pass if we remove that
condition now.

PR fortran/41453
PR fortran/87401

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Remove condition
disabling clobber generation for ASSOCIATE variables.

gcc/testsuite/ChangeLog:

* gfortran.dg/intent_optimize_8.f90: New test.

[Bug fortran/41453] use INTENT(out) for optimization

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Mikael Morin :

https://gcc.gnu.org/g:51c9480f9f0a80ef112ba2aed040b0b2ad0fc2a2

commit r13-2837-g51c9480f9f0a80ef112ba2aed040b0b2ad0fc2a2
Author: Mikael Morin 
Date:   Mon Aug 29 13:27:02 2022 +0200

fortran: Support clobbering of reference variables [PR41453]

This adds support for clobbering of variables passed by reference,
when the reference is forwarded to a subroutine as actual argument
whose associated dummy has the INTENT(OUT) attribute.
This was explicitly disabled by a condition added with
r9-3032-gee7fb0588c6361b4d77337ab0f7527be64fcdde2 and removing that
condition seems to work, as demonstrated by the new testcase.

PR fortran/41453
PR fortran/87395

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Remove condition
disabling clobber generation for dummy variables.  Remove
obsolete comment.

gcc/testsuite/ChangeLog:

* gfortran.dg/intent_optimize_6.f90: New test.

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

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

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

--- Comment #33 from CVS Commits  ---
The master branch has been updated by Mikael Morin :

https://gcc.gnu.org/g:20aa1eb6cb84e6a0487b47b28b00109c5f46a7e2

commit r13-2836-g20aa1eb6cb84e6a0487b47b28b00109c5f46a7e2
Author: Harald Anlauf 
Date:   Wed Aug 31 11:50:35 2022 +0200

fortran: Support clobbering with implicit interfaces [PR105012]

Before procedure calls, we clobber actual arguments whose associated
dummy is INTENT(OUT).  This only applies to procedures with explicit
interfaces, as the knowledge of the interface is necessary to know
whether an argument has the INTENT(OUT) attribute.

This change also enables clobber generation for procedure calls without
explicit interface, when the procedure has been defined in the same
file because we can use the dummy arguments' characteristics from the
procedure definition in that case.

The knowledge of the dummy characteristics is directly available through
gfc_actual_arglistâs associated_dummy pointers which have been populated
as a side effect of calling gfc_check_externals.

PR fortran/105012

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Use dummy
information from associated_dummy if there is no information
from the procedure interface.

gcc/testsuite/ChangeLog:

* gfortran.dg/intent_optimize_5.f90: New test.

Co-Authored-By: Mikael Morin 

[Bug fortran/87395] [9 Regression] ICE in in lookup_field_for_decl with whizard

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Mikael Morin :

https://gcc.gnu.org/g:51c9480f9f0a80ef112ba2aed040b0b2ad0fc2a2

commit r13-2837-g51c9480f9f0a80ef112ba2aed040b0b2ad0fc2a2
Author: Mikael Morin 
Date:   Mon Aug 29 13:27:02 2022 +0200

fortran: Support clobbering of reference variables [PR41453]

This adds support for clobbering of variables passed by reference,
when the reference is forwarded to a subroutine as actual argument
whose associated dummy has the INTENT(OUT) attribute.
This was explicitly disabled by a condition added with
r9-3032-gee7fb0588c6361b4d77337ab0f7527be64fcdde2 and removing that
condition seems to work, as demonstrated by the new testcase.

PR fortran/41453
PR fortran/87395

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Remove condition
disabling clobber generation for dummy variables.  Remove
obsolete comment.

gcc/testsuite/ChangeLog:

* gfortran.dg/intent_optimize_6.f90: New test.

[Bug fortran/41453] use INTENT(out) for optimization

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

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

--- Comment #11 from CVS Commits  ---
The master branch has been updated by Mikael Morin :

https://gcc.gnu.org/g:467ef2c40dbaf9d1219d9642e90df77dc61f4fae

commit r13-2838-g467ef2c40dbaf9d1219d9642e90df77dc61f4fae
Author: Mikael Morin 
Date:   Wed Aug 31 11:54:47 2022 +0200

fortran: Support clobbering of SAVE variables [PR41453]

This removes a condition added in:
r9-3032-gee7fb0588c6361b4d77337ab0f7527be64fcdde2.

That commit added a condition to avoid generating ICE with clobbers
of variables with the SAVE attribute.
The test added at that point continues to pass if we remove that
condition now.

PR fortran/41453
PR fortran/87395

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Remove condition
on SAVE attribute guarding clobber generation.

gcc/testsuite/ChangeLog:

* gfortran.dg/intent_optimize_7.f90: New test.

[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Mikael Morin :

https://gcc.gnu.org/g:29919bf3b6449bafd02e795abbb1966e3990c1fc

commit r13-2835-g29919bf3b6449bafd02e795abbb1966e3990c1fc
Author: Mikael Morin 
Date:   Sat Sep 3 11:58:47 2022 +0200

fortran: Move clobbers after evaluation of all arguments [PR106817]

For actual arguments whose dummy is INTENT(OUT), we used to generate
clobbers on them at the same time we generated the argument reference
for the function call.  This was wrong if for an argument coming
later, the value expression was depending on the value of the just-
clobbered argument, and we passed an undefined value in that case.

With this change, clobbers are collected separatedly and appended
to the procedure call preliminary code after all the arguments have been
evaluated.

PR fortran/106817

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Collect all clobbers
to their own separate block.  Append the block of clobbers to
the procedure preliminary block after the argument evaluation
codes for all the arguments.

gcc/testsuite/ChangeLog:

* gfortran.dg/intent_optimize_4.f90: New test.

[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9

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

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

--- Comment #32 from CVS Commits  ---
The master branch has been updated by Mikael Morin :

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

commit r13-2834-gedaf1e005c90b311c39b46d85cea17befbece112
Author: Mikael Morin 
Date:   Mon Aug 29 11:19:29 2022 +0200

fortran: Fix invalid function decl clobber ICE [PR105012]

The fortran frontend, as result symbol for a function without
declared result symbol, uses the function symbol itself.  This caused
an invalid clobber of a function decl to be emitted, leading to an
ICE, whereas the intended behaviour was to clobber the function result
variable.  This change fixes the problem by getting the decl from the
just-retrieved variable reference after the call to
gfc_conv_expr_reference, instead of copying it from the frontend symbol.

PR fortran/105012

gcc/fortran/ChangeLog:

* trans-expr.cc (gfc_conv_procedure_call): Retrieve variable
from the just calculated variable reference.

gcc/testsuite/ChangeLog:

* gfortran.dg/intent_out_15.f90: New test.

[Bug target/107032] New: ARM: libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here

[thomas.petazzoni--- via Gcc-bugs]

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

Bug ID: 107032
   Summary: ARM: libgcc2.c:2174:1: error: r7 cannot be used in
'asm' here
   Product: gcc
   Version: 11.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thomas.petazz...@free-electrons.com
  Target Milestone: ---

When building gcc 10.4.0 or 11.3.0 for Cortex-M3 or M7, the build fails with:

../../../libgcc/libgcc2.c: In function '__clear_cache':
../../../libgcc/libgcc2.c:2174:1: error: r7 cannot be used in 'asm' here
 2174 | }
  | ^
Makefile:501: recipe for target '_clear_cache.o' failed

GCC was configured like this:


(cd
/home/buildroot/autobuild/instance-0/output-1/build/host-gcc-initial-10.4.0/build
&& rm -rf config.cache;
PATH="/home/buildroot/autobuild/instance-0/output-1/host/bin:/home/buildroot/autobuild/instance-0/output-1/host/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"
PKG_CONFIG="/home/buildroot/autobuild/instance-0/output-1/host/bin/pkg-config"
PKG_CONFIG_SYSROOT_DIR="/" PKG_CONFIG_ALLOW_SYSTEM_CFLAGS=1
PKG_CONFIG_ALLOW_SYSTEM_LIBS=1
PKG_CONFIG_LIBDIR="/home/buildroot/autobuild/instance-0/output-1/host/lib/pkgconfig:/home/buildroot/autobuild/instance-0/output-1/host/share/pkgconfig"
AR="/usr/bin/ar" AS="/usr/bin/as" LD="/usr/bin/ld" NM="/usr/bin/nm"
CC="/usr/bin/gcc" GCC="/usr/bin/gcc" CXX="/usr/bin/g++" CPP="/usr/bin/cpp"
OBJCOPY="/usr/bin/objcopy" RANLIB="/usr/bin/ranlib"
CPPFLAGS="-I/home/buildroot/autobuild/instance-0/output-1/host/include"
CFLAGS="-O2 -I/home/buildroot/autobuild/instance-0/output-1/host/include"
CXXFLAGS="-O2 -I/home/buildroot/autobuild/instance-0/output-1/host/include"
LDFLAGS="-L/home/buildroot/autobuild/instance-0/output-1/host/lib
-Wl,-rpath,/home/buildroot/autobuild/instance-0/output-1/host/lib"
INTLTOOL_PERL=/usr/bin/perl CFLAGS="-O2
-I/home/buildroot/autobuild/instance-0/output-1/host/include"
LDFLAGS="-L/home/buildroot/autobuild/instance-0/output-1/host/lib
-Wl,-rpath,/home/buildroot/autobuild/instance-0/output-1/host/lib"
MAKEINFO=missing CFLAGS_FOR_TARGET="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64  -O0 -g0   -Wl,-elf2flt=-r -static"
CXXFLAGS_FOR_TARGET="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-D_FILE_OFFSET_BITS=64  -O0 -g0   -Wl,-elf2flt=-r -static  -Wl,-elf2flt=-r
-static" AR_FOR_TARGET=gcc-ar NM_FOR_TARGET=gcc-nm RANLIB_FOR_TARGET=gcc-ranlib
CONFIG_SITE=/dev/null ./configure
--prefix="/home/buildroot/autobuild/instance-0/output-1/host"
--sysconfdir="/home/buildroot/autobuild/instance-0/output-1/host/etc"
--localstatedir="/home/buildroot/autobuild/instance-0/output-1/host/var"
--enable-shared --disable-static --disable-gtk-doc --disable-gtk-doc-html
--disable-doc --disable-docs --disable-documentation --disable-debug
--with-xmlto=no --with-fop=no --disable-nls --disable-dependency-tracking 
--target=arm-buildroot-uclinux-uclibcgnueabi
--with-sysroot=/home/buildroot/autobuild/instance-0/output-1/host/arm-buildroot-uclinux-uclibcgnueabi/sysroot
--enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
--disable-decimal-float
--with-gmp=/home/buildroot/autobuild/instance-0/output-1/host
--with-mpc=/home/buildroot/autobuild/instance-0/output-1/host
--with-mpfr=/home/buildroot/autobuild/instance-0/output-1/host
--with-pkgversion="Buildroot 2022.05-439-g18f6e4bf70"
--with-bugurl="http://bugs.buildroot.net/; --without-zstd --disable-libquadmath
--disable-libquadmath-support --disable-libsanitizer --disable-tls
--enable-threads --without-isl --without-cloog --with-float=soft
--with-abi="aapcs-linux" --with-cpu=cortex-m3 --with-float=soft
--with-mode=thumb --enable-languages=c --disable-shared --without-headers
--disable-threads --with-newlib --disable-largefile  )

Full build log of GCC 10.4.0 for Cortex-M3:
 
http://autobuild.buildroot.net/results/e91/e91fa76142cf50e514d5fe4791a06f3c3c014b5a/build-end.log

Full build log of GCC 11.3.0 for Cortex-M7:
 
http://autobuild.buildroot.net/results/9f7/9f7a43a375d476f47702cd7848eba53b76fcd386/build-end.log

[Bug c++/106921] [11/12/13 Regression] -O1 and -fipa-icf -fpartial-inlining causes wrong code since r11-4987-g602c6cfc79ce4ae6

[lutztonineubert at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Toni Neubert  ---
Any update on this? Which compiler flag triggers this bug exactly? Or is it a
complex combination multiple?

[Bug lto/107030] Emitted binary code changes when -g is enabled at -O2 -flto and optimize attribute

[schwab--- via Gcc-bugs]

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

--- Comment #2 from Andreas Schwab  ---
But -g is supposed to never change the generated code.

[Bug fortran/107031] New: endfile truncates file at wrong position

[kishore96 at gmail dot com via Gcc-bugs]

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

Bug ID: 107031
   Summary: endfile truncates file at wrong position
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: kishore96 at gmail dot com
  Target Milestone: ---

SUMMARY
---
When `endfile` is used to truncate a file after a read statement, gfortran
wrongly inserts end-of-file after the next line, rather than after the current
line.

STEPS TO REPRODUCE
--
1. create the following program, truncate.f90:
```fortran
program test_truncate
integer :: num_rec, tmp, i, ioerr

open(1, file="in.dat", action='readwrite')

num_rec = 5
i = 1
ioerr = 0
do while (i <= num_rec .and. ioerr == 0)
read(1, *, iostat=ioerr) tmp
i = i+1
enddo

!backspace(1)
endfile(1)
close(1)
end program test_truncate
```

2. Create the following text file, `in.dat`
```
1
2
3
4
5
6
7
8
9
10
```

3. Compile the program: `gfortran truncate.f90`

4. Run the program: `./a.out`

OBSERVED RESULTS

```bash
$cat in.dat
1
2
3
4
5
6
```

EXPECTED RESULTS

```bash
$cat in.dat
1
2
3
4
5
```

Since after the end of the loop, the current record is `5`, one would expect
endfile to write an end-of-file record as the next record (e.g.
), leading
to the result above.

SOFTWARE VERSIONS
-
OS: Arch Linux
gfortran: 12.2.0


ADDITIONAL INFORMATION
--
Intel ifort (version 19.0.5.281 20190815) produces the expected result.

May be related to https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52387, but I
think not, since my example program doesn't use nonadvancing reads anywhere.

Uncommenting the `backspace(1)` gives output
```bash
$cat in.dat
1
2
3
4
```

[Bug libgcc/107026] [13 Regression] gcc_assert (in_shutdown || ob); build failure for i586-msdosdjgpp target

[unlvsur at live dot com via Gcc-bugs]

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

--- Comment #3 from cqwrteur  ---
(In reply to Andrew Pinski from comment #2)
> Introduced by r13-2801-g94ccaf62c378c3.
> 
> 
> The use in_shutdown is not inside the #ifdef ATOMIC_FDE_FAST_PATH
>  case.

this also happens with x86_64-w64-mingw32 target

btw it is weird why --disable-sjlj-exceptions is not working any more for
x86_64-w64-mingw32 target