[Bug ada/100486] Ada build fails for 32bit Windows

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

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

--- Comment #6 from Eric Botcazou  ---
Thanks.

> '--with-bugurl=https://github.com/msys2/MINGW-packages/issues'
> '--with-gnu-as' '--with-gnu-ld' '--with-boot-ldflags=-pipe
> -Wl,--dynamicbase,--nxcompat,--no-seh -Wl,--large-address-aware
> -Wl,--disable-dynamicbase -static-libstdc++ -static-libgcc'
> 'LDFLAGS_FOR_TARGET=-pipe -Wl,--dynamicbase,--nxcompat,--no-seh
> -Wl,--large-address-aware'
> '--enable-linker-plugin-flags=LDFLAGS=-static-libstdc++\\ -static-libgcc\\
> -pipe\\ -Wl,--dynamicbase,--nxcompat,--no-seh\\ -Wl,--large-address-aware\\
> -Wl,--stack,12582912' '--disable-sjlj-exceptions' '--with-dwarf2'
> 'build_alias=i686-w64-mingw32' 'host_alias=i686-w64-mingw32'
> 'target_alias=i686-w64-mingw32' 'CC=gcc' 'CFLAGS=-march=i686 -mtune=generic
> -O2 -pipe' 'LDFLAGS=-pipe -Wl,--dynamicbase,--nxcompat,--no-seh
> -Wl,--large-address-aware -Wl,--disable-dynamicbase'
> 'CPPFLAGS=-D__USE_MINGW_ANSI_STDIO=1' 'CXX=g++' 'CXXFLAGS=-march=i686
> -mtune=generic -O2 -pipe'
> '--enable-languages=c,ada,c++,fortran,jit,lto,objc,obj-c++'"

AFAICS the failure occurs during stage #2 so the stage #1 compiler might be
miscompiled by the base compiler.  Could you change the -O2 into -O1 above?
If this still does not work, could you change it into -O0?

[Bug tree-optimization/101301] Improving sparse switch statement

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

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

--- Comment #1 from Thomas Koenig  ---
Here's the assembly for the switch statement with -O3:

cmpl$5, %edi
je  .L6
jle .L18
movl$8, %eax
cmpl$8, %edi
je  .L1
jle .L19
xorl%eax, %eax
cmpl$9, %edi
sete%al
leal(%rax,%rax,8), %eax
ret
.p2align 4,,10
.p2align 3
.L18:
movl$3, %eax
cmpl$3, %edi
je  .L1
jle .L20
xorl%eax, %eax
cmpl$4, %edi
sete%al
sall$2, %eax
ret
.p2align 4,,10
.p2align 3
.L19:
movl$6, %eax
cmpl$6, %edi
je  .L1
xorl%eax, %eax
movl$7, %edx
cmpl$7, %edi
cmove   %edx, %eax
ret
.p2align 4,,10
.p2align 3
.L6:
movl$5, %eax
.L1:
ret
.p2align 4,,10
.p2align 3
.L20:
movl$1, %eax
cmpl$1, %edi
je  .L1
xorl%eax, %eax
cmpl$2, %edi
sete%al
addl%eax, %eax
ret

and here for the if statement version:

cmpl$4, %edi
jle .L2
cmpl$6, %edi
jle .L3
cmpl$7, %edi
je  .L6
cmpl$8, %edi
je  .L7
xorl%eax, %eax
cmpl$9, %edi
sete%al
leal(%rax,%rax,8), %eax
ret
.p2align 4,,10
.p2align 3
.L3:
cmpl$5, %edi
je  .L9
xorl%eax, %eax
movl$6, %edx
cmpl$6, %edi
cmove   %edx, %eax
ret
.p2align 4,,10
.p2align 3
.L2:
cmpl$2, %edi
jle .L5
cmpl$3, %edi
je  .L11
xorl%eax, %eax
cmpl$4, %edi
sete%al
sall$2, %eax
ret
.p2align 4,,10
.p2align 3
.L5:
movl$1, %eax
cmpl$1, %edi
je  .L1
xorl%eax, %eax
cmpl$2, %edi
sete%al
addl%eax, %eax
ret
.p2align 4,,10
.p2align 3
.L11:
movl$3, %eax
.L1:
ret
.p2align 4,,10
.p2align 3
.L7:
movl$8, %eax
ret
.p2align 4,,10
.p2align 3
.L9:
movl$5, %eax
ret
.p2align 4,,10
.p2align 3
.L6:
movl$7, %eax
ret

Stepping through the code with a debugger, here is a table on the number
of conditional jumps for all special values and in all relevant intervals:

 5000  5  3
 1 5  3
 15000 5  3
 2 5  3
 25000 5  3
 3 3  3
 35000 4  3
 4 4  3
 5 4  3
 5 1  3
 6 5  3
 6 5  3
 7 5  3
 7 5  3
 8 5  4
 8 3  4
 9 4  4
 9 4  4
10 4  4

If one assumes each case as equally likely, the number of conditional jumps
goes down from 81 to 62.

Assuming each case statement is reached once, the total number of
conditional jumps executed goes from 35 to 29.

[Bug d/101273] d: missed RVO optimization with non-pod structs

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

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

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

https://gcc.gnu.org/g:152f4d0e4d3b524ce30d05f20e23a44b0dd29765

commit r12-1995-g152f4d0e4d3b524ce30d05f20e23a44b0dd29765
Author: Iain Buclaw 
Date:   Sat Jul 3 02:42:14 2021 +0200

d: Missed RVO optimization with non-POD structs

The D front-end semantic pass sometimes declares a temporary inside a
return expression.  This is now detected with the RESULT_DECL replacing
the temporary, allowing for RVO to be done.

PR d/101273

gcc/d/ChangeLog:

* toir.cc (IRVisitor::visit (ReturnStatement *)): Detect returns
that
use a temporary, and replace with return value.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr101273.d: New test.

[Bug libstdc++/101306] New: positioning at line anchors is disturbed by the navigation bar

[giecrilj at stegny dot 2a.pl via Gcc-bugs]

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

Bug ID: 101306
   Summary: positioning at line anchors is disturbed by the
navigation bar
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: giecrilj at stegny dot 2a.pl
  Target Milestone: ---

When I navigate to a line anchor like #l02373, the following things happen:
1. The source file opens.
2. The source file scrolls to the anchor.
3. The navigation bar opens.
4. The source file scrolls to the beginning.

Workaround:
1. Change the anchor to #l02372!
2. Press ⏎!
3. Change the anchor to #l02373!
4. Press ⏎!

(Steps 1 and 2 are necessary, at least in Chrome, because without them ⏎
reloads the page—which recreates the bug.)

[Bug d/101273] d: missed RVO optimization with non-pod structs

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

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

--- Comment #3 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Iain Buclaw
:

https://gcc.gnu.org/g:46d1cb4c218ff1fb73b391a28218ee1f362e8ca1

commit r11-8688-g46d1cb4c218ff1fb73b391a28218ee1f362e8ca1
Author: Iain Buclaw 
Date:   Sat Jul 3 02:42:14 2021 +0200

d: Missed RVO optimization with non-POD structs

The D front-end semantic pass sometimes declares a temporary inside a
return expression.  This is now detected with the RESULT_DECL replacing
the temporary, allowing for RVO to be done.

PR d/101273

gcc/d/ChangeLog:

* toir.cc (IRVisitor::visit (ReturnStatement *)): Detect returns
that
use a temporary, and replace with return value.

gcc/testsuite/ChangeLog:

* gdc.dg/torture/pr101273.d: New test.

(cherry picked from commit 152f4d0e4d3b524ce30d05f20e23a44b0dd29765)

[Bug libstdc++/101306] positioning at line anchors is disturbed by the navigation bar

[giecrilj at stegny dot 2a.pl via Gcc-bugs]

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

--- Comment #1 from Christopher Yeleighton  ---
Interestingly enough, the problem does not affect https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-api.20210701.html/a00209_source.html#l00060
>.  It may be a timing issue—the latter document is way smaller.

[Bug libstdc++/101306] positioning at line anchors is disturbed by the navigation bar

[giecrilj at stegny dot 2a.pl via Gcc-bugs]

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

--- Comment #2 from Christopher Yeleighton  ---
(In reply to Christopher Yeleighton from comment #1)
> Interestingly enough, the problem does not affect  https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-api.20210701.html/
> a00209_source.html#l00060 >.  It may be a timing issue—the latter document
> is way smaller.

I am sorry, that was just an illusion.  Wrong there too.

[Bug libstdc++/57840] ::std ::result_of is undocumented

[giecrilj at stegny dot 2a.pl via Gcc-bugs]

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

--- Comment #5 from Christopher Yeleighton  ---
(In reply to Jonathan Wakely from comment #4)
> It shows up in the latest docs:
> https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-api.20210701.html/a03925.
> html
> 
> But several other classes don't appear on the type traits page:
> https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-api.20210701.html/a01565.
> html
> 
> That seems to be due to 
> https://github.com/doxygen/doxygen/issues/8638

I am no Doxygen guru but the source at https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-api.20210701.html/a00209_source.html
> has 2 @{ (#l00051, #l00237) but only 1 @} (#l00266).

[Bug middle-end/101294] [12 Regression] ICE: in maybe_legitimize_operand, at optabs.c:7614 with -mavx since r12-1958-gedafb35bdadf309e

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by H.J. Lu :

https://gcc.gnu.org/g:52c3fdf3e4780f75297515d3c2a3dae9b36586ba

commit r12-1996-g52c3fdf3e4780f75297515d3c2a3dae9b36586ba
Author: H.J. Lu 
Date:   Fri Jul 2 10:03:48 2021 -0700

Don't use vec_duplicate on vector in CTOR expansion

Since vec_duplicate only works on scalar, don't use it on vector in
store constructor expansion.

gcc/

PR middle-end/101294
* expr.c (store_constructor): Don't use vec_duplicate on vector.

gcc/testsuite/

PR middle-end/101294
* gcc.dg/pr101294.c: New test.

[Bug libstdc++/57840] ::std ::result_of is undocumented

[giecrilj at stegny dot 2a.pl via Gcc-bugs]

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

--- Comment #6 from Christopher Yeleighton  ---
(In reply to Jonathan Wakely from comment #3)
> I'm not sure why the comment on the primary template doesn't show up (maybe
> doxygen is only interested in a definition) and adding comments to the
> partial specialization doesn't show up in the generated HTML either.

There is no comment as of https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-api.20210701.html/a00221_source.html#l02373
>, so there is nothing to show up, and neither was there any at https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-api-4.5/a00875_source.html#l00176
>.

[Bug middle-end/101294] [12 Regression] ICE: in maybe_legitimize_operand, at optabs.c:7614 with -mavx since r12-1958-gedafb35bdadf309e

[hjl.tools at gmail dot com via Gcc-bugs]

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

H.J. Lu  changed:

   What|Removed |Added

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

--- Comment #6 from H.J. Lu  ---
Fixed.

[Bug libstdc++/101307] New: Variable templates for type traits—corrections

[giecrilj at stegny dot 2a.pl via Gcc-bugs]

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

Bug ID: 101307
   Summary: Variable templates for type traits—corrections
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: giecrilj at stegny dot 2a.pl
  Target Milestone: ---

1. Please remove the trailing comma from the title: Variable templates for type
traits.
2. The general description (is_foovalue) should be (is_foo ::value) (or,
preferably, equal to the constant value defined in the class is_foo).

[Bug libstdc++/101307] Variable templates for type traits—corrections

[giecrilj at stegny dot 2a.pl via Gcc-bugs]

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

--- Comment #1 from Christopher Yeleighton  ---
(In reply to Christopher Yeleighton from comment #0)
> 1. Please remove the trailing comma from the title: Variable templates for
> type traits.

The trailing full stop, of course.

[Bug libstdc++/101268] Refer manual readers to cppreference.com for API details

[giecrilj at stegny dot 2a.pl via Gcc-bugs]

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

--- Comment #3 from Christopher Yeleighton  ---
(In reply to Jonathan Wakely from comment #1)
> (In reply to Christopher Yeleighton from comment #0)
> > (I mean patches are not welcome)
> 
> Have you actually tried submitting any? I only see bug reports from you, not
> patches.

I have—the need to rebuild the whole thing before submitting had me in the
first half, not gonna lie :-(  It is so much easier in MSDN where the
documentation is completely separate.  

What I wanted to say is: resolving an issue as WONTFIX normally means that
patches would not be accepted.

[Bug libstdc++/97001] API documentation should mention the minimum dialect

[giecrilj at stegny dot 2a.pl via Gcc-bugs]

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

--- Comment #3 from Christopher Yeleighton  ---
The problem with a module-level @since is that std:: symbols are easiest to
locate in the std namespace (which provides a huge index of everything).  Items
that are undocumented (there is a lot of them) in the namespace index are not
attributed to any module and the definition line is not available for them
either, so the reader needs a priori knowledge of which symbols belong to which
module.  While it is possible to guess the matching module with some
experience, just adding dummy documentation to those symbols (as a few of other
symbols have) would help navigating the API (also because the definition
sometimes is readable enough to be used instead of documentation).  Of course,
the fact that Doxygen bugs prevent some of the symbols from appearing in the
corresponding modules only adds to the general feeling of helplessness.

[Bug fortran/101308] New: Bind(C): gfortran does not create C descriptors for scalar pointer/allocatable arguments

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

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

Bug ID: 101308
   Summary: Bind(C): gfortran does not create C descriptors for
scalar pointer/allocatable arguments
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

gfortran is completely failing to create C descriptors for scalar arguments to
bind(c) functions that have the POINTER or ALLOCATABLE attribute.  E.g. for
this trivial test case

subroutine f ()
  use iso_c_binding

  interface
subroutine ctest (pp) bind (c)
  use iso_c_binding
  integer(C_INT), pointer :: pp
end subroutine
  end interface

  integer(C_INT), pointer :: p
  p => NULL ()

  call ctest (p)
end subroutine

-fdump-tree-original produces this output:

__attribute__((fn spec (". ")))
void f ()
{
  integer(kind=4) * p;

  p = 0B;
  ctest (&p);
}

showing that it is passing a raw pointer by reference instead.

The 2018 Fortran standard is clear that pointers/allocatables are passed as
pointers to C descriptors; it's item (5) in section 18.3.6.

This bug is causing many failures in my WIP TS29113 testsuite, posted at

https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574115.html

interoperability/fc-descriptor-3.f90
interoperability/fc-out-descriptor-3.f90
interoperability/typecodes-scalar.f90
interoperability/typecodes-scalar-ext.f90
procedures/allocatable-dummy.f90

Is it an accident that the related tests passing descriptors from C to Fortran
functions for pointer/allocatable scalars appear to work?  The called Fortran
function expects a pointer to a pointer to the effective argument, and the C
function is passing a pointer to a descriptor structure whose first element
happens to be a pointer to the effective argument.

[Bug d/101273] d: missed RVO optimization with non-pod structs

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Iain Buclaw  changed:

   What|Removed |Added

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

--- Comment #4 from Iain Buclaw  ---
Fixed.

[Bug tree-optimization/101301] Improving sparse switch statement

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

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

Thomas Koenig  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org

--- Comment #2 from Thomas Koenig  ---
Some benchmarks are interesting, and it seems that things are a lot less clear
than I thought.

a.c contains the code in the original test. bench.c has


#include 
#include 
#include 

#define N 1024
#define TIMES (1024*1024)

int foo(int);
int foo2(int);

const int nums[] =
#ifdef FULL
  {  5000, 1, 15000, 2, 25000, 3, 35000, 4, 5,
5, 6, 6, 7, 7, 8, 8, 9, 9,
 10};
#else
  {  1, 2, 3, 4, 5, 6, 7, 8, 9 };
#endif

double this_time ()
{
  struct timeval tv;
  gettimeofday (&tv, NULL);
  return tv.tv_sec + tv.tv_usec * 1e-6;
}

int main()
{
  double t1, t2;
  int *x;
  int r;
  int s;
  x = malloc(N * sizeof(*x));
  for (int i=0; i:
  e0:   ce 56 83 2c cmpwi   cr1,r3,2
  e4:   00 00 80 3c lis r4,0
  e8:   00 00 a0 38 li  r5,0
  ec:   02 00 c0 38 li  r6,2
  f0:   01 00 e0 38 li  r7,1
  f4:   01 00 00 3d lis r8,1
  f8:   67 2b 83 2a cmplwi  cr5,r3,1
  fc:   9c ad 03 28 cmplwi  r3,4
 100:   35 82 89 60 ori r9,r4,3
 104:   04 00 40 39 li  r10,4
 108:   6a 04 08 61 ori r8,r8,1130
 10c:   03 d9 84 60 ori r4,r4,5
 110:   9e 29 c6 7c iselr6,r6,r5,6
 114:   35 82 03 2b cmplwi  cr6,r3,3
 118:   00 48 83 7c cmpwcr1,r3,r9
 11c:   9e 35 c7 7c iselr6,r7,r6,22
 120:   03 00 e0 38 li  r7,3
 124:   01 00 69 6c xoris   r9,r3,1
 128:   9e 28 4a 7d iseleq  r10,r10,r5
 12c:   40 40 03 7c cmplw   r3,r8
 130:   66 2b 08 39 addir8,r8,0
 134:   d1 2f 89 2a cmplwi  cr5,r9,12241
 138:   9e 56 e7 7c iselr7,r7,r10,26
 13c:   06 00 40 39 li  r10,6
 140:   9f 86 09 2b cmplwi  cr6,r9,34463
 144:   38 5b 89 2b cmplwi  cr7,r9,23352
 148:   08 00 20 39 li  r9,8
 14c:   9e 28 4a 7d iseleq  r10,r10,r5
 150:   00 40 03 7c cmpwr3,r8
 154:   09 00 00 39 li  r8,9
 158:   9e 2f a9 7c iselr5,r9,r5,30
 15c:   1e 39 c6 7c iselr6,r6,r7,4
 160:   05 00 e0 38 li  r7,5
 164:   03 d9 83 28 cmplwi  cr1,r3,5
 168:   9e 2e a8 7c iselr5,r8,r5,26
 16c:   07 00 00 39 li  r8,7
 170:   9e 51 e7 7c iselr7,r7,r10,6
 174:   00 20 83 7c cmpwcr1,r3,r4
 178:   9e 2d a8 7c iselr5,r8,r5,22
 17c:   5e 38 65 7c iselgt  r3,r5,r7
 180:   1e 19 66 7c iselr3,r6,r3,4
 184:   20 00 63 78 clrldi  r3,r3,32
 188:   20 00 80 4e blr

I don't have any recent Intel hardware to test.

So, things are less clear then when just looking at the assembler code,
and the behavior of branch predictors is not easy to predict.

A small (up to 5% advantage) x86_64 could be a big disadvantage or
advantage on POWER, depending on how it is compiled...

[Bug libstdc++/57840] ::std ::result_of is undocumented

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

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

--- Comment #7 from Jonathan Wakely  ---
Like 2371 is a comment using doxygen syntax. That comment was there in 2014
when I wrote comment 3 here.

[Bug tree-optimization/101301] Improving sparse switch statement

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

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

--- Comment #3 from Segher Boessenkool  ---
What CPU is in your Power system, and what -mcpu= did you compile with?
What is the ABI you are using?  (That last one doesn't seem to matter in
this particular case, but :-) )

[Bug libstdc++/57840] ::std ::result_of is undocumented

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

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

--- Comment #8 from Jonathan Wakely  ---
(In reply to Christopher Yeleighton from comment #5)
> I am no Doxygen guru but the source at  https://gcc.gnu.org/onlinedocs/libstdc++/libstdc++-api.20210701.html/
> a00209_source.html > has 2 @{ (#l00051, #l00237) but only 1 @} (#l00266).

Already fixed in r12-1964

You know doxygen output isn't the only way to look at the code, right?

[Bug libstdc++/101306] positioning at line anchors is disturbed by the navigation bar

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

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

--- Comment #3 from Jonathan Wakely  ---
You should report this to doxygen then. The html is produced by doxygen, not
GCC.

[Bug fortran/101309] New: Bind(C): gfortran creates invalid C descriptor for result of TRANSPOSE intrinsic

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

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

Bug ID: 101309
   Summary: Bind(C): gfortran creates invalid C descriptor for
result of TRANSPOSE intrinsic
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

The description of CFI_cdesc_t in section 18.5.3 of the 2018 Fortran standard
includes this constraint:

There shall be an ordering of the dimensions such that the absolute value of
the sm member of the first dimension is not less than the elem_len member of
the C descriptor and the absolute value of the sm member of each subsequent
dimension is not less than the absolute value of the sm member of the previous
dimension multiplied by the extent of the previous dimension.

In the WIP TS 29113 testsuite posted here

https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574115.html

the testcase interoperability/fc-descriptor-7.f90 passes the result of the
TRANSPOSE intrinsic to a C function with an assumed-shape array argument, and
the descriptor it receives does not satisfy this constraint.  It dumps as

,
   ]>

[Bug libstdc++/97001] API documentation should mention the minimum dialect

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

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

--- Comment #4 from Jonathan Wakely  ---
Just use cppreference.com

[Bug fortran/101309] Bind(C): gfortran creates invalid C descriptor for result of TRANSPOSE intrinsic

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

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

--- Comment #1 from sandra at gcc dot gnu.org ---
BTW, I did not test any other intrinsics that rearrange the elements of their
input array arguments.  TRANPOSE seemed like the most obvious one to try first.

[Bug libstdc++/101306] positioning at line anchors is disturbed by the navigation bar

[giecrilj at stegny dot 2a.pl via Gcc-bugs]

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

Christopher Yeleighton  changed:

   What|Removed |Added

 Resolution|--- |MOVED
 Status|UNCONFIRMED |RESOLVED

--- Comment #4 from Christopher Yeleighton  ---
(In reply to Jonathan Wakely from comment #3)
> You should report this to doxygen then. The html is produced by doxygen, not
> GCC.

I reported at https://github.com/doxygen/doxygen/issues/8648 >.  Please
go there and fill in the version details as requested.  I tried to resolve this
one as UPSTREAM but there is no such resolution available.

[Bug libfortran/101310] New: Bind(C): CFI_section seems confused by pointer arrays

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

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

Bug ID: 101310
   Summary: Bind(C): CFI_section seems confused by pointer arrays
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

Many of the unit tests for CFI_section included in the WIP TS 29113 testsuite
are failing.

https://gcc.gnu.org/pipermail/gcc-patches/2021-July/574115.html

At least some of the problems seem to be related to handling pointer arrays
where the lower bound may be nonzero; e.g. section-1p and section-2p fail, but
the corresponding non-pointer cases sharing the same C code pass.

The set of tests that seem affected by this bug are:

library/section-1p.f90
library/section-2p.f90
library/section-3.f90
library/section-3p.f90

and also

interoperability/fc-out-descriptor-7.f90

which tries to pass the result of CFI_section back to Fortran via an
intent(out) argument (the unit tests only manipulate it in C code).

[Bug target/101311] New: GCC refuses to use SSE registers to carry out an explicit XOR on a float.

[the4naves at gmail dot com via Gcc-bugs]

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

Bug ID: 101311
   Summary: GCC refuses to use SSE registers to carry out an
explicit XOR on a float.
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: the4naves at gmail dot com
  Target Milestone: ---

// ---
int func(float a, float b) {
float tmp = a * b;
*reinterpret_cast(&tmp) ^= 0x8000;

return tmp;
}

int main() {
return func(2, 4);
}
// ---

Compiling this with `g++ test.cpp -O3 -Wall -Wextra -fno-strict-aliasing
-fwrapv -fno-aggressive-loop-optimizations -fsanitize=undefined` (removing the
various strict flags achieves the same thing) gives no compile warnings and
successfully returns `248` (-8) when run.

Looking at the assembly for `func`, GCC generates:
# ---
mulss  xmm0, xmm1
moveax, -2147483648
movd   DWORD PTR [rsp-20], xmm0
addeax, DWORD PTR [rsp-20]
moved  xmm0, eax
cvttss2si  eax, xmm0
ret
# ---

I find a couple of things odd with this:
  - Memory is used as a temporary buffer. There shouldn't be any latency
between the write and read due to store forwarding, but that cache line is
going to have to be written to memory at some point.
 - Necessitating the previous point, GCC uses eax to carry out the XOR,
requiring a move to and from the register.
  - GCC seems to favor an `add` instead of `xor`. I've seen it mentioned that
an add should be slightly faster due to consecutive instructions not being
blocked in the pipeline, but I'm don't see why a `xor` would be (don't quote me
on this though).

Replacing the explicit XOR with a negation (`tmp = -tmp`) generates much more
sensible assembly (.LC0 contains the xor constant):
# ---
mulss  xmm0, xmm1
xorps  xmm0, XMMWORD PTR .LC0[rip]
cvttss2si  eax, xmm0
ret
# ---

To be fair, in my example, negation is easily just the better method, but it
seems silly that GCC goes to such lengths in the first snippet as to not use
`xorps` (which as far as I can tell is just as fast as `add`). It looks like
maybe GCC is confused by the cast to int (and as such doesn't want to use the
xmm regs)?

Exact version is 11.1.0 under x86_64-linux-gnu, but I was able to reproduce
this as far back as 4.9.

[Bug target/101311] GCC refuses to use SSE registers to carry out an explicit XOR on a float.

[the4naves at gmail dot com via Gcc-bugs]

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

--- Comment #1 from Josh Nave  ---
Additionally, other instructions could have been used (such as `pxor`) which
are less float-centric (and maybe faster?).

[Bug target/101311] GCC refuses to use SSE registers to carry out an explicit XOR on a float.

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
   Last reconfirmed||2021-07-03
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
So for aarch64 it is xor:
(insn 7 4 8 2 (set (reg:SF 101)
(mult:SF (reg/v:SF 98 [ a ])
(reg/v:SF 99 [ b ]))) "t66.c":2:19 966 {mulsf3}
 (expr_list:REG_DEAD (reg/v:SF 99 [ b ])
(expr_list:REG_DEAD (reg/v:SF 98 [ a ])
(nil
(insn 8 7 9 2 (set (reg:SI 102)
(xor:SI (subreg:SI (reg:SF 101) 0)
(const_int -2147483648 [0x8000]))) "t66.c":3:35 490
{xorsi3}
 (expr_list:REG_DEAD (reg:SF 101)
(nil)))

But on x86_64 it is plus:
(insn 8 7 9 2 (parallel [
(set (reg:SI 92)
(plus:SI (subreg:SI (reg:SF 91) 0)
(const_int -2147483648 [0x8000])))
(clobber (reg:CC 17 flags))
]) "t87.c":3:35 207 {*addsi_1}
 (expr_list:REG_DEAD (reg:SF 91)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil

It is xor until fwprop1 on x86_64.

Where it changes:
(insn 8 7 9 2 (parallel [
(set (reg:SI 92)
(xor:SI (subreg:SI (reg:SF 91) 0)
(const_int -2147483648 [0x8000])))
(clobber (reg:CC 17 flags))
]) "t87.c":3:35 529 {*xorsi_1}
 (nil))

into:
(insn 8 7 9 2 (parallel [
(set (reg:SI 92)
(plus:SI (subreg:SI (reg:SF 91) 0)
(const_int -2147483648 [0x8000])))
(clobber (reg:CC 17 flags))
]) "t87.c":3:35 207 {*addsi_1}
 (expr_list:REG_DEAD (reg:SF 91)
(expr_list:REG_UNUSED (reg:CC 17 flags)
(nil

But even if I change 0x8000 to 0x8001 (to force it to stay XOR), I
still don't get the SSE instruction.

Note aarch64 gets it right though:
.cfi_startproc
fmuls0, s0, s1
moviv1.2s, 0x80, lsl 24
eor v0.8b, v0.8b, v1.8b
fcvtzs  w0, s0
ret

[Bug tree-optimization/101301] Improving sparse switch statement

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

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

--- Comment #4 from Thomas Koenig  ---
(In reply to Segher Boessenkool from comment #3)
> What CPU is in your Power system, and what -mcpu= did you compile with?
> What is the ABI you are using?  (That last one doesn't seem to matter in
> this particular case, but :-) )

The machine is gcc135 from the gcc compile farm. cat /proc/cpuinfo says

processor   : 0
cpu : POWER9, altivec supported
clock   : 3800.00MHz
revision: 2.2 (pvr 004e 1202)

...

I compiled without -mcpu.

With -mcpu=native, the times are

[tkoenig@gcc135 ~]$ gcc -mcpu=native -O3  bench.c a.c && ./a.out
foo: 5.679413
foo2: 6.799938

[tkoenig@gcc135 ~]$ gcc -mcpu=native -O3 -DFULL bench.c a.c && ./a.out
foo: 5.713161
foo2: 6.137598

so -mcpu=native makes a difference there.  The version of the compiler is

gcc-Version 12.0.0 20210701 (experimental) (GCC) 

HTH.

[Bug ada/100486] Ada build fails for 32bit Windows

[ofv at wanadoo dot es via Gcc-bugs]

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

--- Comment #7 from ofv at wanadoo dot es ---
make BOOT_CFLAGS='-O1' V=1 all

make BOOT_CFLAGS='-O0' V=1

both fails the same way as the initial report.


export CFLAGS="-march=i686 -mtune=generic -O0 -pipe"
export CXXFLAGS="-march=i686 -mtune=generic -O0 -pipe"
make BOOT_CFLAGS='-O0' V=1

fails on

 configure: error: unsupported system, cannot find sizeof (omp_lock_t)
 make[2]: *** [Makefile:24035: configure-stage1-target-libgomp] Error 1

(this is before the build reaches the failure point discussed on this bug
report).


Finally, trying to reduce as much as possible the optimization passes:

export CFLAGS="-march=i686 -mtune=generic -Og -pipe"
export CXXFLAGS="-march=i686 -mtune=generic -Og -pipe"
make BOOT_CFLAGS='-Og' V=1

fails the same way as the initial report.

[Bug c/101312] New: ICE with -g: ‘verify_type’ failed, verify_type(tree_node const*), gen_type_die_with_usage

[cnsun at uwaterloo dot ca via Gcc-bugs]

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

Bug ID: 101312
   Summary: ICE with -g: ‘verify_type’ failed,
verify_type(tree_node const*), gen_type_die_with_usage
   Product: gcc
   Version: tree-ssa
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: cnsun at uwaterloo dot ca
  Target Milestone: ---

$ 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/12.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /tmp/tmp.KJbG2ovrlV-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 12.0.0 20210704 (experimental) [master revision
:03198a1af:e6f3adc899aa9c4d925406974b446634e0db9cd2] (GCC)

$ cat mutant.c
const b[] __attribute__((may_alias));

$ gcc-trunk -w -g mutant.c
mutant.c:1:1: error: ‘TYPE_CANONICAL’ of main variant is not main variant
1 | const b[] __attribute__((may_alias));
  | ^
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f7f47b4de70 precision:32 min  max
>
BLK
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f7f47b4df18>
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f7f47a325e8 precision:32 min  max

pointer_to_this >
BLK
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f7f47b4ddc8>
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f7f47b4de70 precision:32 min  max
>
BLK
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7f7f47b4df18
attributes >>
mutant.c:1:1: internal compiler error: ‘verify_type’ failed
0x1243008 verify_type(tree_node const*)
/tmp/tmp.KJbG2ovrlV-gcc-builder/gcc/gcc/tree.c:13796
0xb20ac4 gen_type_die_with_usage
/tmp/tmp.KJbG2ovrlV-gcc-builder/gcc/gcc/dwarf2out.c:25960
0xb22826 gen_type_die
/tmp/tmp.KJbG2ovrlV-gcc-builder/gcc/gcc/dwarf2out.c:26191
0xb3bdfb gen_decl_die
/tmp/tmp.KJbG2ovrlV-gcc-builder/gcc/gcc/dwarf2out.c:26869
0xb3cdc6 dwarf2out_decl
/tmp/tmp.KJbG2ovrlV-gcc-builder/gcc/gcc/dwarf2out.c:27385
0xb3cff0 dwarf2out_early_global_decl
/tmp/tmp.KJbG2ovrlV-gcc-builder/gcc/gcc/dwarf2out.c:27035
0x8f639b finish_decl(tree_node*, unsigned int, tree_node*, tree_node*,
tree_node*)
/tmp/tmp.KJbG2ovrlV-gcc-builder/gcc/gcc/c/c-decl.c:5537
0x95a52b c_parser_declaration_or_fndef
/tmp/tmp.KJbG2ovrlV-gcc-builder/gcc/gcc/c/c-parser.c:2370
0x962f93 c_parser_external_declaration
/tmp/tmp.KJbG2ovrlV-gcc-builder/gcc/gcc/c/c-parser.c:1777
0x9639f9 c_parser_translation_unit
/tmp/tmp.KJbG2ovrlV-gcc-builder/gcc/gcc/c/c-parser.c:1650
0x9639f9 c_parse_file()
/tmp/tmp.KJbG2ovrlV-gcc-builder/gcc/gcc/c/c-parser.c:22121
0x9c5a95 c_common_parse_file()
/tmp/tmp.KJbG2ovrlV-gcc-builder/gcc/gcc/c-family/c-opts.c:1219
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug c/101312] ICE with -g and may_alias and const array type with no bounds

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE with -g: ‘verify_type’  |ICE with -g and may_alias
   |failed, |and const array type with
   |verify_type(tree_node   |no bounds
   |const*),|
   |gen_type_die_with_usage |
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=35980

--- Comment #1 from Andrew Pinski  ---
Most likely related to PR 35980.