[Bug ipa/95558] [9/10/11/12 Regression] Invalid IPA optimizations based on weak definition

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||4.7.1
  Known to work||4.5.3, 4.6.4
   Target Milestone|--- |9.5
Summary|Invalid IPA optimizations   |[9/10/11/12 Regression]
   |based on weak definition|Invalid IPA optimizations
   ||based on weak definition

--- Comment #5 from Andrew Pinski  ---
Note you need -fno-inline to produce the issue these days.
Plus it is a regression from GCC 4.6.

[Bug other/102440] Uinteger Opt/Param but the underlying type is signed

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |other

--- Comment #2 from Andrew Pinski  ---
The other option handling bug report I saw dealing with the awk script was
recorded as other.

[Bug c++/102326] ICE in tree_to_uhwi, at tree.c:4520

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
  Component|target  |c++

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

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

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

--- Comment #16 from Andrew Pinski  ---
(In reply to AJ D from comment #15)
> Is it fixed in GCC-9.4?  
> 
> Didn't find PR99334 in
> https://gcc.gnu.org/bugzilla/buglist.
> cgi?bug_status=RESOLVED=FIXED_milestone=9.4
> 
> If not, which GCC9.* release can we expect a fix for it?

So the target milestone only says the earliest GCC version where it is fixed. 
I updated the "known to work" field on which release the patch in comment #10,
#11, #12, and #13 were committed to.  Also updated the target milestone to the
correct one.

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to work||10.3.0, 11.1.0, 8.5.0,
   ||9.4.0
   Target Milestone|8.2 |8.5

[Bug target/102326] ICE in tree_to_uhwi, at tree.c:4520

[pc.wang at linux dot alibaba.com via Gcc-bugs]

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

Pengcheng Wang  changed:

   What|Removed |Added

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

--- Comment #3 from Pengcheng Wang  ---
Patch has been applied.

[Bug debug/99334] Generated DWARF unwind table issue while on instructions where rbp is pointing to callers stack frame

[aatsnps at gmail dot com via Gcc-bugs]

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

--- Comment #15 from AJ D  ---
Is it fixed in GCC-9.4?  

Didn't find PR99334 in
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED=FIXED_milestone=9.4

If not, which GCC9.* release can we expect a fix for it?

[Bug middle-end/102440] Uinteger Opt/Param but the underlying type is signed

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

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

Kewen Lin  changed:

   What|Removed |Added

 CC||segher at gcc dot gnu.org
   Severity|normal  |enhancement
  Component|tree-optimization   |middle-end

--- Comment #1 from Kewen Lin  ---
Not sure which component I should mark this with, put middle-end temporarily.

[Bug tree-optimization/102440] New: Uinteger Opt/Param but the underlying type is signed

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

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

Bug ID: 102440
   Summary: Uinteger Opt/Param but the underlying type is signed
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: linkw at gcc dot gnu.org
  Target Milestone: ---

The UInteger type in Opt/Param declaration can easily confuse people that the
variable for this option/parameter is unsigned.  But actually the internal
implementation uses signed for it, it requires users to add explicit type
conversion for some cases, otherwise the bootstrapping fails due to -Werror.
I guess the "UInteger" is mainly to restrict the value range of
option/parameter.  But I think we still can improve it? Like using one
anonymous union with uinteger and integer instead of a single integer, then
name the corresponding member as signedness?

File this as Segher's suggestion from patch reviewing.

[Bug target/102438] [x86-64] Failure to optimize out spill in vector code when a cast is used

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #3)
> currently the i386 backend doesn't support V1DFmode, and it's treated as a
> DImode (an equal-size integer type) and passed by stack.
typo, moved through stack.

[Bug target/102438] [x86-64] Failure to optimize out spill in vector code when a cast is used

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #3 from Hongtao.liu  ---
currently the i386 backend doesn't support V1DFmode, and it's treated as a
DImode (an equal-size integer type) and passed by stack.

Shall we support V1DFmode?

[Bug target/102404] Loop vectorized with 32 byte vectors actually uses 16 byte vectors

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Hongtao.liu  ---
(In reply to Hongtao.liu from comment #5)
> (In reply to Freddie Witherden from comment #4)
> > Created attachment 51485 [details]
> > Clang assembly.
> 
> It seems to be because the current GCC loop vectorizer does not support
> different vector sizes, and here the index vector is 256bit. Change
> tripcount to 16 successfully generate zmm.

Define index type from const int* to const long long * also can generate zmm.


.i.e.

void intcflux(int _nx, const double* __restrict__ magnl_v, const double*
__restrict__ nl_v, double* __restrict__ ul_v, const long long* __restrict__
ul_vix, double* __restrict__ ur_v, const long long* __restrict__ ur_vix)
{

[Bug target/102404] Loop vectorized with 32 byte vectors actually uses 16 byte vectors

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #5 from Hongtao.liu  ---
(In reply to Freddie Witherden from comment #4)
> Created attachment 51485 [details]
> Clang assembly.

It seems to be because the current GCC loop vectorizer does not support
different vector sizes, and here the index vector is 256bit. Change tripcount
to 16 successfully generate zmm.

[Bug target/102107] protocol register (r12) corrupted before a tail call

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

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

--- Comment #22 from Segher Boessenkool  ---
Backported to 11 and 10.  Not doing GCC 9; the problem is older than that,
and the backport wouldn't be completely trivial.  Paul, please close if
everything is okay now?

[Bug target/102347] "fatal error: target specific builtin not available" with MMA and LTO

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

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

--- Comment #7 from Peter Bergner  ---
(In reply to Martin Liška from comment #6)
> Quickly looking at the rs6000 code, it fails here:
> 
> #1  0x11a0993c in rs6000_invalid_builtin
> (fncode=MMA_BUILTIN_DISASSEMBLE_ACC_INTERNAL) at
> ../../gcc/config/rs6000/rs6000-call.c:11643
> #2  0x11a13134 in rs6000_builtin_decl (code=1603, initialize_p=true)
> at ../../gcc/config/rs6000/rs6000-call.c:13870
> #3  0x115c3900 in unpack_ts_function_decl_value_fields
> (bp=0x3fffe2f0, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:361
> #4  0x115c4790 in streamer_read_tree_bitfields (ib=0x3fffe6a0,
> data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/tree-streamer-in.c:528
> #5  0x10deaa28 in lto_read_tree_1 (ib=0x3fffe6a0,
> data_in=0x132d1910, expr=0x3fffaf195700) at ../../gcc/lto-streamer-in.c:1697
> 
> which relies on rs6000_builtin_mask. Note the mask is set here:
> rs6000_builtin_mask = rs6000_builtin_mask_calculate ();
> 
> where rs6000_builtin_mask_calculate is based on TARGET_* values.

Is that really the issue though?  In a non-lto compile, handle_pragma_target()
ends up calling rs6000_option_override_internal which sets the TARGET_* flags
for the function given the pragma options.  Where does LTO do that?  I think I
see lto read in the default options that were set on the command line, but
where and when does LTO set the options defined by the pragma?  Are they even
streamed out to the fat obj file?  They could be there, but I'm not seeing it.

[Bug c++/102434] [11/12 Regression] ICE in output_constructor_regular_field, at varasm.c:5514

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.3

[Bug c++/102434] [11/12 Regression] ICE in output_constructor_regular_field, at varasm.c:5514

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-21
 Status|UNCONFIRMED |NEW
   Keywords||ice-on-invalid-code
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.
Note clang also ICEs :).

[Bug c++/102439] New: deprecated attributes do not work on struct/class if type is auto deduced

[spaun2002 at protonmail dot com via Gcc-bugs]

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

Bug ID: 102439
   Summary: deprecated attributes do not work on struct/class if
type is auto deduced
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: spaun2002 at protonmail dot com
  Target Milestone: ---

The following code compiles with no warnings/errors by all gcc versions that
support std=c++14.
The same code does not compile by clang or msvc compilers (the latter was run
with /W4 /WX arguments and without __attribute__ part).

If I uncomment type_v1 const a = type_v1{10}; then gcc properly fails to
compile.

Expected behavior: gcc emits warning on `auto a = type_v1{10}` line.

// gcc -Wall --pedantic -std=c++14 -Wattributes -Wdeprecated-declarations
-Werror

#include 

struct [[deprecated]] type_v1 {
  int a;
} __attribute__ ((__deprecated__));

int main() {
  auto a = type_v1{10};   // this one should not compile
  //type_v1 a = type_v1{10};  // rightfully fails to compile
  std::cout << a.a << std::endl;
  return 0;
}

[Bug target/102107] protocol register (r12) corrupted before a tail call

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

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

--- Comment #21 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Segher Boessenkool
:

https://gcc.gnu.org/g:14b7e8ace8236bd341a182dc3ef044fe98de5525

commit r10-10144-g14b7e8ace8236bd341a182dc3ef044fe98de5525
Author: Segher Boessenkool 
Date:   Wed Sep 8 13:10:30 2021 +

rs6000: Fix ELFv2 r12 use in epilogue

We cannot use r12 here, it is already in use as the GEP (for sibling
calls).

2021-09-08  Segher Boessenkool  
PR target/102107
* config/rs6000/rs6000-logue.c (rs6000_emit_epilogue): For ELFv2
use
r11 instead of r12 for restoring CR.

(cherry picked from commit 86e6268cff328e27ee6f90e2afc35b6f437a25cd)

[Bug target/102107] protocol register (r12) corrupted before a tail call

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

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

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

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

commit r10-10143-g5a989ccd3cbc31cb0e5fecd9423fc1577f3694b0
Author: Segher Boessenkool 
Date:   Thu Sep 2 16:38:24 2021 +

rs6000: Don't use r12 for CR save on ELFv2 (PR102107)

CR is saved and/or restored on some paths where GPR12 is already live
since it has a meaning in the calling convention in the ELFv2 ABI.

It is not completely clear to me that we can always use r11 here, but
it does seem save, there is checking code (to detect conflicts here),
and it is stage 1.  So here goes.

2021-09-03  Segher Boessenkool 

PR target/102107
* config/rs6000/rs6000-logue.c (rs6000_emit_prologue): On ELFv2 use
r11
instead of r12 for CR save, in all cases.

(cherry picked from commit 2484f7a4b0f52e6ed04754be336f1fa6fde47f6b)

[Bug target/102107] protocol register (r12) corrupted before a tail call

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

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

--- Comment #19 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Segher Boessenkool
:

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

commit r11-9022-gda0a5628d47ee59320dac9787f3232b0911fbc14
Author: Segher Boessenkool 
Date:   Wed Sep 8 13:10:30 2021 +

rs6000: Fix ELFv2 r12 use in epilogue

We cannot use r12 here, it is already in use as the GEP (for sibling
calls).

2021-09-08  Segher Boessenkool  
PR target/102107
* config/rs6000/rs6000-logue.c (rs6000_emit_epilogue): For ELFv2
use
r11 instead of r12 for restoring CR.

(cherry picked from commit 86e6268cff328e27ee6f90e2afc35b6f437a25cd)

[Bug target/102107] protocol register (r12) corrupted before a tail call

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

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

--- Comment #18 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Segher Boessenkool
:

https://gcc.gnu.org/g:5210f05c6eba12561914cb0fdf7aec149b28f179

commit r11-9021-g5210f05c6eba12561914cb0fdf7aec149b28f179
Author: Segher Boessenkool 
Date:   Thu Sep 2 16:38:24 2021 +

rs6000: Don't use r12 for CR save on ELFv2 (PR102107)

CR is saved and/or restored on some paths where GPR12 is already live
since it has a meaning in the calling convention in the ELFv2 ABI.

It is not completely clear to me that we can always use r11 here, but
it does seem save, there is checking code (to detect conflicts here),
and it is stage 1.  So here goes.

2021-09-03  Segher Boessenkool 

PR target/102107
* config/rs6000/rs6000-logue.c (rs6000_emit_prologue): On ELFv2 use
r11
instead of r12 for CR save, in all cases.

(cherry picked from commit 2484f7a4b0f52e6ed04754be336f1fa6fde47f6b)

[Bug target/102438] [x86-64] Failure to optimize out spill in vector code when a cast is used

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

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

--- Comment #2 from Andrew Pinski  ---
There might be a dup of this bug too.

[Bug target/102438] [x86-64] Failure to optimize out spill in vector code when a cast is used

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-21
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Severity|normal  |enhancement

--- Comment #1 from Andrew Pinski  ---
There is an ABI difference between GCC and clang here 

But I suspect this is the one of the standard return/argument issues with
respect to gcc.

[Bug target/102438] New: [x86-64] Failure to optimize out random extra store+load in vector code when memcpy is used

[gabravier at gmail dot com via Gcc-bugs]

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

Bug ID: 102438
   Summary: [x86-64] Failure to optimize out random extra
store+load in vector code when memcpy is used
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gabravier at gmail dot com
  Target Milestone: ---

#include 

typedef double simde_float64x1_t __attribute__((__vector_size__(8)));

simde_float64x1_t simde_vabs_f64(simde_float64x1_t a) {
simde_float64x1_t r;
r[0] = -a[0];
return (simde_float64x1_t)r;
}

On AMD64 with -O3, this is outputted:

simde_vabs_f64(double __vector(1)):
movsd   xmm0, QWORD PTR [rsp+8]
xorpd   xmm0, XMMWORD PTR .LC0[rip]
mov rax, rdi
movsd   QWORD PTR [rsp-24], xmm0
mov rdx, QWORD PTR [rsp-24]
mov QWORD PTR [rdi], rdx
ret

If we instead just return `r` (without the cast) this is instead outputted:

simde_vabs_f64(double __vector(1)):
movsd   xmm0, QWORD PTR [rsp+8]
xorpd   xmm0, XMMWORD PTR .LC0[rip]
mov rax, rdi
movsd   QWORD PTR [rdi], xmm0
ret

It seems as though the presence of a cast (to the same type, no less) confuses
GCC into spilling the result into memory.

The GIMPLE optimized output is different for the two, so idk how much this
target-specific to x86, but I haven't been able to reproduce it anywhere else,
so ¯\_(ツ)_/¯. 

PS: The same bug can also be reproduced with -m32

[Bug c++/102049] Extend attribute deprecated to allow optional 2nd argument

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

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

Marek Polacek  changed:

   What|Removed |Added

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

[Bug fortran/102371] Error for type spec in FORALL statement

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

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

--- Comment #3 from Steve Kargl  ---
On Tue, Sep 21, 2021 at 08:05:02PM +, anlauf at gcc dot gnu.org wrote:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102371
> 
> anlauf at gcc dot gnu.org changed:
> 
>What|Removed |Added
> 
>  Status|NEW |RESOLVED
>  Resolution|--- |DUPLICATE
>  CC||anlauf at gcc dot gnu.org
> 
> --- Comment #2 from anlauf at gcc dot gnu.org ---
> It is indeed a duplicate of pr78219.
> 
> Unfortunately the patch provided there fails on the present testcase with:
> 
> pr102371.f90:7:27:
> 
> 7 |   forall(integer(long) :: i=1:very_large, j=1:2)
>   |   1
> Error: Symbol 'i' at (1) has no IMPLICIT type
> pr102371.f90:7:43:

Ugh, I forgot that one could chain forall iterators like above.
The patch is in match_forall_iterator(), which is called multiple
times in match_forall_header().  Specifically,  lines 2428-2443.

  m = match_forall_iterator (_iter);   < grabs typespec
  if (m == MATCH_ERROR)
goto cleanup;
  if (m == MATCH_NO)
goto syntax;

  head = tail = new_iter;

  for (;;)
{
  if (gfc_match_char (',') != MATCH_YES)
break;

  m = match_forall_iterator (_iter);  < typespec gone
  if (m == MATCH_ERROR)
goto cleanup;


The patch can likely to be right before line 2428 and then
after if "(m == MATCH_YES and seen_ts)" fix-up the new_iter
typespec.

[Bug driver/102437] [11/12 Regression] gcc-11 and later started recognising -R option

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #1)
> common.opt lists -R since r0-104214-g6d721f6786362871895a36e4f26f09ded82d55ec
> so for quite a while as a driver option.

I think r11-635-g6232d02b4fce4c67d398 changed how driver options are processed
which allows "-R aa" always now rather than when just processed by the specs.

[Bug driver/102437] [11/12 Regression] gcc-11 and later started recognising -R option

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
common.opt lists -R since r0-104214-g6d721f6786362871895a36e4f26f09ded82d55ec
so for quite a while as a driver option.

[Bug driver/102437] [11/12 Regression] gcc-11 and later started recognising -R option

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||accepts-invalid
Summary|[11 Regression] gcc-11 and  |[11/12 Regression] gcc-11
   |later started recognising   |and later started
   |-R option   |recognising -R option
   Target Milestone|--- |11.3

[Bug driver/102437] New: [11 Regression] gcc-11 and later started recognising -R option

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

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

Bug ID: 102437
   Summary: [11 Regression] gcc-11 and later started recognising
-R option
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: slyfox at gcc dot gnu.org
  Target Milestone: ---

x86_64-pc-linux-gnu target:

$ gcc-12.0.0 a.c -o a -R /foo
$ gcc-11.1.0 a.c -o a -R /foo
$ gcc-10.3.0 a.c -o a -R /foo
gcc-10.3.0: error: unrecognized command-line option ‘-R’
$ gcc-9.3.0 a.c -o a -R /foo
gcc-9.3.0: error: unrecognized command line option ‘-R’

It's not immediately causing problems, but it's not documented in the manual
and might not be intended.

[Bug preprocessor/102432] [11/12 Regression] ICE in _cpp_lex_direct with function like macro without arguments within "pragma omp" statement

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2021-09-21

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > I just saw a related bug which is much older and dates from around 4.4 time
> > frame.
> 
> Actually I am wrong.  Anyways this is related to PR 97471 Which I suspect
> was caused by the same patch.

Or rather caused by the patch for that bug :).

Confirmed.

[Bug preprocessor/102432] [11/12 Regression] ICE in _cpp_lex_direct, at libcpp/lex.c:2949

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.3
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=97471

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> I just saw a related bug which is much older and dates from around 4.4 time
> frame.

Actually I am wrong.  Anyways this is related to PR 97471 Which I suspect was
caused by the same patch.

[Bug lto/102426] [12 regression] Fix for PR 49664 breaks Solaris bootstrap with gld

[ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs]

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

--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #2 from Andrew Pinski  ---
> It seems like only this feature which libtool gets wrong.
>
> There are other places where lt_cv_prog_gnu_ld/with_gnu_ld is checked.
> So it should not be hard to add this check there.
>
> I might come up with a patch which adds the check but it might not for a week.

No need to hurry: I only bootstrap with gld once a week anyway and can
easily backout the patch locally until you've got something ready.

[Bug tree-optimization/102436] New: [11/12 Regression] Lost Load/Store Motion

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

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

Bug ID: 102436
   Summary: [11/12 Regression] Lost Load/Store Motion
   Product: gcc
   Version: 11.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: law at gcc dot gnu.org
  Target Milestone: ---

Created attachment 51492
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51492=edit
Testcase

So consider this loop (-O2, lim2 dump, trunk, x86_64):



;;   basic block 3, loop depth 1
;;pred:   2
;;10
  # target_8 = PHI 
  _4 = board[target_8];
  if (_4 == 13)
goto ; [94.50%]
  else
goto ; [5.50%]
;;succ:   4
;;7

;;   basic block 4, loop depth 1
;;pred:   3
  if (captures.32_5 == 0)
goto ; [33.00%]
  else
goto ; [67.00%]
;;succ:   5
;;6

;;   basic block 5, loop depth 1
;;pred:   4
  numb_moves.1_21 = numb_moves;
  _22 = (long unsigned int) numb_moves.1_21;
  _23 = _22 * 24;
  _24 = (struct move_s *) _23;
  _24->from = gfrom.30_1;
  _24->target = target_8;
  _24->captured = 13;
  _24->castled = 0;
  _24->promoted = 0;
  _24->ep = 0;
  _26 = numb_moves.1_21 + 1;
  numb_moves = _26;
;;succ:   6

;;   basic block 6, loop depth 1
;;pred:   4
;;5
  target_17 = target_8 + offset_14;
  _7 = board[target_17];
  if (_7 != 0)
goto ; [94.50%]
  else
goto ; [5.50%]
;;succ:   10
;;9

;;   basic block 10, loop depth 1
;;pred:   6
  goto ; [100.00%]
;;succ:   3

In particular note the load from and store to numb_moves in block #5 within the
loop.  I don't immediately see an aliasing issue that would prevent LSM.  The
bigger problem is control flow, obviously the load/store may not be executed,
but I thought our LIM/LSM code handled that correctly.

If we look at gcc-10 we get something like this:


;;   basic block 3, loop depth 1
;;pred:   2
;;10
  # target_9 = PHI 
  # numb_moves_lsm.43_6 = PHI 
  # numb_moves_lsm_flag.44_20 = PHI 
  _4 = board[target_9];
  if (_4 == 13)
goto ; [94.50%]
  else
goto ; [5.50%]
;;succ:   4
;;7

;;   basic block 4, loop depth 1
;;pred:   3
  if (captures.32_5 == 0)
goto ; [33.00%]
  else
goto ; [67.00%]
;;succ:   5
;;6

;;   basic block 5, loop depth 1
;;pred:   4
  numb_moves.1_21 = numb_moves_lsm.43_6;
  _22 = (long unsigned int) numb_moves.1_21;
  _23 = _22 * 24;
  _24 = (struct move_s *) _23;
  _24->from = gfrom.30_1;
  _24->target = target_9;
  _24->captured = 13;
  _24->castled = 0;
  _24->promoted = 0;
  _24->ep = 0;
  _26 = numb_moves.1_21 + 1;
  numb_moves_lsm.43_37 = _26;
  numb_moves_lsm_flag.44_38 = 1;
;;succ:   6

;;   basic block 6, loop depth 1
;;pred:   4
;;5
  # numb_moves_lsm.43_2 = PHI 
  # numb_moves_lsm_flag.44_18 = PHI 
  target_19 = target_9 + offset_15;
  _8 = board[target_19];
  if (_8 != 0)
goto ; [94.50%]
  else
goto ; [5.50%]
;;succ:   10
;;11

[ ... ]
;;   basic block 10, loop depth 1
;;pred:   6
  goto ; [100.00%]
;;succ:   3


Obviously with the load before the loop and the store after.

[Bug fortran/78219] [F08] specifying the kind of a FORALL index in the header

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||longb at cray dot com

--- Comment #10 from anlauf at gcc dot gnu.org ---
*** Bug 102371 has been marked as a duplicate of this bug. ***

[Bug fortran/102371] Error for type spec in FORALL statement

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE
 CC||anlauf at gcc dot gnu.org

--- Comment #2 from anlauf at gcc dot gnu.org ---
It is indeed a duplicate of pr78219.

Unfortunately the patch provided there fails on the present testcase with:

pr102371.f90:7:27:

7 |   forall(integer(long) :: i=1:very_large, j=1:2)
  |   1
Error: Symbol 'i' at (1) has no IMPLICIT type
pr102371.f90:7:43:

7 |   forall(integer(long) :: i=1:very_large, j=1:2)
  |   1
Error: Symbol 'j' at (1) has no IMPLICIT type
pr102371.f90:7:44:

7 |   forall(integer(long) :: i=1:very_large, j=1:2)
  |1
Error: Cannot convert INTEGER(4) to UNKNOWN at (1)
pr102371.f90:7:46:

7 |   forall(integer(long) :: i=1:very_large, j=1:2)
  |  1
Error: Cannot convert INTEGER(4) to UNKNOWN at (1)
pr102371.f90:7:47:

7 |   forall(integer(long) :: i=1:very_large, j=1:2)
  |   1
Error: Cannot convert INTEGER(4) to UNKNOWN at (1)

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

[Bug fortran/78219] [F08] specifying the kind of a FORALL index in the header

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #9 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #7)
> diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c

The patch unfortunately seems incomplete.  It fails when using IMPLICIT NONE
or -fimplicit-none with:

pr78219.f90:3:30:

3 |   forall (integer(kind=4) :: i = 1:10)
  |  1
Error: Symbol 'i' at (1) has no IMPLICIT type

and similarly for pr102371.

[Bug c/54192] -fno-trapping-math by default?

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #8 from joseph at codesourcery dot com  ---
On Tue, 21 Sep 2021, rguenther at suse dot de via Gcc-bugs wrote:

> Yes, as said in other contexts GCC happily _removes_ traps if trapping
> is the only side-effect.  _Unless_ you also have -fnon-call-exceptions
> enabled which is the only way to observe traps.  So we consider
> a trap invoking undefined behavior unless you make them well-defined
> via -fnon-call-exceptions.

That might be relevant to traps in the sense of changing control flow when 
a floating-point exception is signaled.  -fnon-call-exceptions doesn't 
seem very relevant to the -ftrapping-math effects on transformations that 
might affect the set of floating-point exception flags raised by some 
code.  As per my previous comment, -ftrapping-math currently affects (or 
might affect if fully implemented) several different things:

* Disallowing code transformations that cause some code to raise more 
exception flags than it would have before.

* Disallowing code transformations that cause some code to raise fewer 
exception flags than it would have before.

* Ensuring the code generated allows for possible non-local control flow 
from exception traps raised by floating-point operations (this is the part 
where -fnon-call-exceptions might be relevant).

* Disallowing code transformations that might affect whether an exact 
underflow exception occurs in some code (not observable through exception 
flags, is observable through trap handlers).

* Ensuring floating-point operations that might raise exception flags are 
not removed, or moved past code (asms or function calls) that might read 
or modify the exception flag state (not implemented, modulo Marc Glisse's 
-ffenv-access patches from August 2020)

[Bug c++/102419] [11/12 Regression][concepts] [regression] return-type-requirement of "Y" does not check that T::type actually exists

[arthur.j.odwyer at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Arthur O'Dwyer  ---
> IMHO Clang/MSVC are clearly misbehaving here -- when evaluating the 
> concept-id X, they appear to be substituting {int} into X's 
> constraint-expression instead of into the normal form of X's 
> constraint-expression.

Isn't this situation exactly analogous to `std::void_t`?

  template using void_t = void;
  template auto foo(T t) -> void_t;  // SFINAEs away
  template auto foo(T t) -> int;  // this is the only viable candidate
  static_assert(std::same_as);

The language has definitely decided that you can't preemptively fold
`void_t` down to `void`; I don't think you should be
allowed to preemptively fold `Y` down to `true`,
either.
I don't know for sure that Clang/MSVC have been authoritatively dubbed
righteous, but their behavior certainly seems, to me, more consistent and
useful than GCC's.

[Bug tree-optimization/102435] New: gcc 9: aarch64 -ftree-loop-vectorize results in wrong code

[dimitry--- via Gcc-bugs]

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

Bug ID: 102435
   Summary: gcc 9: aarch64 -ftree-loop-vectorize results in wrong
code
   Product: gcc
   Version: 9.4.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: dimi...@unified-streaming.com
  Target Milestone: ---

We noticed a problem with a loop optimization enabled by -O3 on a program
targeting AArch64. It turns out that this problem is specifically caused by
-ftree-loop-vectorize, and has actually been fixed by (or as a side-effect of)
commit https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=c89366b12ff4f362
("[AArch64] Support vectorising with multiple vector sizes") by Richard
Sandiford.

However, this commit was made on master when it was gcc-10, so while the
problem does not occur with gcc 10.x and 11.x, it *does* occur with 9.x. In our
particular instance, this is the default version on Ubuntu 20.04 for arm64,
e.g. gcc version 9.3.0 (Ubuntu 9.3.0-17ubuntu1~20.04).

Reduced test case:

// g++ -std=c++17 -O2 -ftree-loop-vectorize testcase.cpp
// or
// g++ -std=c++17 -O3 testcase.cpp

#include 
#include 
#include 
#include 

struct sample_t
{
  sample_t(uint64_t dts, uint32_t duration)
  : dts_(dts)
  , duration_(duration)
  , cto_(0)
  , sample_description_index_(0)
  , pos_(0)
  , size_(0)
  , flags_(0)
  , aux_pos_(0)
  , aux_size_(0)
  {
  }

  uint64_t dts_;
  uint32_t duration_;
  int32_t cto_;
  uint32_t sample_description_index_;
  uint64_t pos_;
  uint32_t size_;
  uint32_t flags_;
  uint64_t aux_pos_;
  uint32_t aux_size_;
};

typedef std::vector samples_t;

__attribute__((__noinline__))
samples_t get_result(samples_t&& samples)
{
  uint64_t base_media_decode_time = ~0;

  auto first = samples.begin();
  auto last = samples.end();
  if(first != last)
  {
base_media_decode_time = first->dts_;

uint32_t duration = 0;
for(--last; first != last; ++first)
{
  duration = static_cast(first[1].dts_ - first->dts_);

  first->duration_ = duration;
}

first->duration_ = duration;
  }

  return samples;
}

int main(void)
{
  samples_t samples_in = { {0, 3}, {3, 3}, {6, 3}, {9, 1}, {10, 2} };
  samples_t samples_out = get_result(std::move(samples_in));

  for(sample_t sample : samples_out)
  {
std::cout << sample.dts_ << ", " << sample.duration_ << '\n';
  }

  // Expected output:
  // 0, 3
  // 3, 3
  // 6, 3
  // 9, 1
  // 10, 1
  //
  // Bad output:
  // 0, 3
  // 3, 0
  // 6, 0
  // 9, 0
  // 10, 0

  return 0;
}

Not that it appears vital that the struct sample_t is pretty large, e.g.
removing all of the members after the first two makes the output correct, even
with gcc 9 and -ftree-loop-vectorize. I have not determined precisely what the
cutoff size is.

[Bug c++/102432] [11/12 Regression] ICE in _cpp_lex_direct, at libcpp/lex.c:2949

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

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

--- Comment #1 from Andrew Pinski  ---
I just saw a related bug which is much older and dates from around 4.4 time
frame.

[Bug c++/102434] New: [11/12 Regression] ICE in output_constructor_regular_field, at varasm.c:5514

[gscfq--- via Gcc-bugs]

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

Bug ID: 102434
   Summary: [11/12 Regression] ICE in
output_constructor_regular_field, at varasm.c:5514
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20201018 and 20201108 :
(derived from initlist-deduce3.C)


$ cat z1.cc
using size_t = decltype(sizeof 0);
namespace std {
  template union initializer_list {
const T *ptr;
size_t n;
  };
}
template
void Task() {}
auto b = {  };


$ g++-12-20210919 -c z1.cc
z1.cc:10:24: internal compiler error: in output_constructor_regular_field, at
varasm.c:5514
   10 | auto b = {  };
  |^
0x1025b84 output_constructor_regular_field
../../gcc/varasm.c:5514
0x1025b84 output_constructor
../../gcc/varasm.c:5826
0x1025ecf output_constant
../../gcc/varasm.c:5172
0x1025ecf assemble_variable_contents
../../gcc/varasm.c:2235
0x102dcad assemble_variable(tree_node*, int, int, int)
../../gcc/varasm.c:2414
0x102ffaa varpool_node::assemble_decl()
../../gcc/varpool.c:595
0x96ac1f output_in_order
../../gcc/cgraphunit.c:2135
0x96ac1f symbol_table::compile()
../../gcc/cgraphunit.c:2353
0x96d54f symbol_table::compile()
../../gcc/cgraphunit.c:2540
0x96d54f symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.c:2537

[Bug fortran/85130] Substrings out of range are not rejected

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #11 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

[Bug c++/102433] New: [11/12 Regression] ICE in ~saved_token_sentinel, at cp/parser.c:1293

[gscfq--- via Gcc-bugs]

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

Bug ID: 102433
   Summary: [11/12 Regression] ICE in ~saved_token_sentinel, at
cp/parser.c:1293
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20210404 and 20210411 :
(gcc configured with --enable-checking=yes)


$ cat z1.cc
void f ()
{
  #pragma omp task depend(in:this)
  ;
}


$ g++-12-20210919 -c z1.cc -fopenmp
z1.cc: In function 'void f()':
z1.cc:3:29: error: invalid use of 'this' in non-member function
3 |   #pragma omp task depend(in:this)
  | ^
z1.cc:4:3: internal compiler error: in ~saved_token_sentinel, at
cp/parser.c:1293
4 |   ;
  |   ^
0x8f2770 saved_token_sentinel::~saved_token_sentinel()
../../gcc/cp/parser.c:1293
0x8f2770 cp_parser_statement
../../gcc/cp/parser.c:12062
0x8f2894 cp_parser_statement_seq_opt
../../gcc/cp/parser.c:12713
0x8f2977 cp_parser_compound_statement
../../gcc/cp/parser.c:12662
0x9182f0 cp_parser_function_body
../../gcc/cp/parser.c:24893
0x9182f0 cp_parser_ctor_initializer_opt_and_function_body
../../gcc/cp/parser.c:24944
0x91896a cp_parser_function_definition_after_declarator
../../gcc/cp/parser.c:31066
0x919be4 cp_parser_function_definition_from_specifiers_and_declarator
../../gcc/cp/parser.c:30982
0x919be4 cp_parser_init_declarator
../../gcc/cp/parser.c:22427
0x8ef1c2 cp_parser_simple_declaration
../../gcc/cp/parser.c:15133
0x920d5e cp_parser_declaration
../../gcc/cp/parser.c:14819
0x921985 cp_parser_translation_unit
../../gcc/cp/parser.c:4978
0x921985 c_parse_file()
../../gcc/cp/parser.c:47694
0xaa4682 c_common_parse_file()
../../gcc/c-family/c-opts.c:1236

[Bug fortran/85130] Substrings out of range are not rejected

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-9 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:0fabf86a52c46db19026a956cf386da46fa4d0be

commit r9-9738-g0fabf86a52c46db19026a956cf386da46fa4d0be
Author: Harald Anlauf 
Date:   Mon Sep 13 19:26:35 2021 +0200

Fortran - fix handling of substring start and end indices

gcc/fortran/ChangeLog:

PR fortran/85130
* expr.c (find_substring_ref): Handle given substring start and
end indices as signed integers, not unsigned.

gcc/testsuite/ChangeLog:

PR fortran/85130
* gfortran.dg/substr_6.f90: Revert commit r8-7574, adding again
test that was erroneously considered as illegal.

(cherry picked from commit 8d93ba93d3b13ac3d3c34404cad87732c809605b)

[Bug c++/102432] New: [11/12 Regression] ICE in _cpp_lex_direct, at libcpp/lex.c:2949

[gscfq--- via Gcc-bugs]

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

Bug ID: 102432
   Summary: [11/12 Regression] ICE in _cpp_lex_direct, at
libcpp/lex.c:2949
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started between 20201018 and 20201108 :


$ cat z1.cc
#define loop(x)
#pragma omp loop


$ cat z2.cc
#define loop(x)
#pragma acc loop


$ g++-12-20210919 -c z1.cc -fopenmp
z1.cc:2:9: internal compiler error: in _cpp_lex_direct, at libcpp/lex.c:2949
2 | #pragma omp loop
  | ^~~
0x19c3cf6 _cpp_lex_direct
../../libcpp/lex.c:2949
0x19c407d _cpp_lex_token
../../libcpp/lex.c:2810
0x19cb04f cpp_get_token_1
../../libcpp/macro.c:2898
0x8c18ad c_lex_with_flags(tree_node**, unsigned int*, unsigned char*, int)
../../gcc/c-family/c-lex.c:483
0x7b4fb6 cp_lexer_get_preprocessor_token
../../gcc/cp/parser.c:864
0x7fa14d cp_lexer_new_main
../../gcc/cp/parser.c:663
0x7fa14d c_parse_file()
../../gcc/cp/parser.c:47690
0x8cb652 c_common_parse_file()
../../gcc/c-family/c-opts.c:1236

[Bug fortran/102431] New: [12 Regression] ICE in lower_gimple_bind, at gimple-low.c:439

[gscfq--- via Gcc-bugs]

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

Bug ID: 102431
   Summary: [12 Regression] ICE in lower_gimple_bind, at
gimple-low.c:439
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20210530 and 20210606 :


$ cat z1.f90
program p
   integer :: i, a(2)
   !$omp parallel loop reduction(+:a)
   do i = 1, 8
   end do
end


$ gfortran-12-20210919 -c z1.f90 -fopenmp
during GIMPLE pass: lower
z1.f90:3:37:

3 |!$omp parallel loop reduction(+:a)
  | ^
internal compiler error: in lower_gimple_bind, at gimple-low.c:439
0x1732df3 lower_gimple_bind
../../gcc/gimple-low.c:439
0x173301c lower_stmt
../../gcc/gimple-low.c:255
0x173301c lower_sequence
../../gcc/gimple-low.c:217
0x1732d38 lower_gimple_bind
../../gcc/gimple-low.c:475
0x173301c lower_stmt
../../gcc/gimple-low.c:255
0x173301c lower_sequence
../../gcc/gimple-low.c:217
0x1732d38 lower_gimple_bind
../../gcc/gimple-low.c:475
0x173301c lower_stmt
../../gcc/gimple-low.c:255
0x173301c lower_sequence
../../gcc/gimple-low.c:217
0x1732f6c lower_omp_directive
../../gcc/gimple-low.c:231
0x1732f6c lower_stmt
../../gcc/gimple-low.c:399
0x1732f6c lower_sequence
../../gcc/gimple-low.c:217
0x1732d38 lower_gimple_bind
../../gcc/gimple-low.c:475
0x173301c lower_stmt
../../gcc/gimple-low.c:255
0x173301c lower_sequence
../../gcc/gimple-low.c:217
0x1732fbc lower_stmt
../../gcc/gimple-low.c:286
0x1732fbc lower_sequence
../../gcc/gimple-low.c:217
0x1732d38 lower_gimple_bind
../../gcc/gimple-low.c:475
0x1733b01 lower_function_body
../../gcc/gimple-low.c:110
0x1733b01 execute
../../gcc/gimple-low.c:195

[Bug fortran/102430] New: ICE in fold_convert_loc, at fold-const.c:2554

[gscfq--- via Gcc-bugs]

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

Bug ID: 102430
   Summary: ICE in fold_convert_loc, at fold-const.c:2554
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r7 :


$ cat z1.f90
program p
   integer :: a(2)
   !$omp parallel do linear(a)
   do i = 1, 8
  a = a + 1
   end do
end


$ gfortran-12-20210919 -c z1.f90 -fopenmp
during GIMPLE pass: ompexp
z1.f90:5:15:

5 |   a = a + 1
  |   ^
internal compiler error: in fold_convert_loc, at fold-const.c:2554
0x998563 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.c:2554
0x180bcc8 expand_omp_for_static_nochunk
../../gcc/omp-expand.c:5260
0x1814bec expand_omp_for
../../gcc/omp-expand.c:8044
0x181518a expand_omp
../../gcc/omp-expand.c:10232
0x1815706 expand_omp
../../gcc/omp-expand.c:10218
0x181744d execute_expand_omp
../../gcc/omp-expand.c:10467

[Bug fortran/85130] Substrings out of range are not rejected

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-10142-ga1591a283767168982ff60414ee01aaa1400fbf8
Author: Harald Anlauf 
Date:   Mon Sep 13 19:26:35 2021 +0200

Fortran - fix handling of substring start and end indices

gcc/fortran/ChangeLog:

PR fortran/85130
* expr.c (find_substring_ref): Handle given substring start and
end indices as signed integers, not unsigned.

gcc/testsuite/ChangeLog:

PR fortran/85130
* gfortran.dg/substr_6.f90: Revert commit r8-7574, adding again
test that was erroneously considered as illegal.

(cherry picked from commit 8d93ba93d3b13ac3d3c34404cad87732c809605b)

[Bug fortran/101330] [openmp]ICE in free_expr0(): Bad expr type

[gscfq--- via Gcc-bugs]

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

--- Comment #3 from G. Steinmetz  ---

A better test case :

$ cat z2.f90
!$omp task affinity (iterator(j=1:2:))
!$omp task affinity (iterator(j=1:2::))
!$omp task affinity (iterator(j=1:-2:))
!$omp task depend (iterator(j=1:2:))
!$omp task depend (iterator(j=1:2::))
end

[Bug fortran/102287] optional allocatable array arguments (intent out) of derived types with allocatable components are not properly passed to subroutines.

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Fixed on all open branches.  Closing.

Thanks for the report!

[Bug fortran/102287] optional allocatable array arguments (intent out) of derived types with allocatable components are not properly passed to subroutines.

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

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

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

https://gcc.gnu.org/g:4210c6c62f6938cd70d768b1bd1ea98d13e3b805

commit r9-9737-g4210c6c62f6938cd70d768b1bd1ea98d13e3b805
Author: Harald Anlauf 
Date:   Thu Sep 16 20:12:21 2021 +0200

Fortran - fix handling of optional allocatable DT arguments with
INTENT(OUT)

gcc/fortran/ChangeLog:

PR fortran/102287
* trans-expr.c (gfc_conv_procedure_call): Wrap deallocation of
allocatable components of optional allocatable derived type
procedure arguments with INTENT(OUT) into a presence check.

gcc/testsuite/ChangeLog:

PR fortran/102287
* gfortran.dg/intent_out_14.f90: New test.

(cherry picked from commit cfea7b86f2430b9cb8018379b071f4004233119c)

[Bug c++/94673] [concepts] What is the return type of local parameters of requires expressions?

[gcc-bugs at marehr dot dialup.fu-berlin.de via Gcc-bugs]

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

gcc-bugs at marehr dot dialup.fu-berlin.de changed:

   What|Removed |Added

 Resolution|--- |WORKSFORME
 Status|UNCONFIRMED |RESOLVED

--- Comment #5 from gcc-bugs at marehr dot dialup.fu-berlin.de ---
(In reply to Patrick Palka from comment #4)
> Don't we already do this with -fconcepts-diagnostics-depth=2 ?

You are right, sorry! Haven't checked that again thoroughly, and it seems that
you do. 

> -fconcepts-diagnostics-depth=2

will produce

```
:18:15: error: static assertion failed
   18 | static_assert(foo); // fails with clang
  |   ^~~
:18:15: note: constraints not satisfied
:9:9:   required by the constraints of 'template concept foo'
:9:15:   in requirements with 't v' [with t = int&&]
:11:6: note: 'v' does not satisfy return-type-requirement, because
   11 | {v} -> std::same_as;
  | ~^~~
:11:6: error: deduced expression type does not satisfy placeholder
constraints
:11:6: note: constraints not satisfied
In file included from
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/compare:39,
 from
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/bits/stl_pair.h:65,
 from
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/utility:70,
 from :1:
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/concepts:57:15:   required
for the satisfaction of '__same_as<_Tp, _Up>' [with _Tp = int&&; _Up = int&]
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/concepts:62:13:   required
for the satisfaction of 'same_as, t&>], t&>' [with decltype(auto) [requires
std::same_as<, t&>] = int&&; t = int&&]
/opt/compiler-explorer/gcc-11.1.0/include/c++/11.1.0/concepts:57:32: note: the
expression 'is_same_v<_Tp, _Up> [with _Tp = int&&; _Up = int&]' evaluated to
'false'
   57 |   concept __same_as = std::is_same_v<_Tp, _Up>;
  | 
```

It seems that the behaviour changed again in gcc-11:

```
template 
concept foo = requires(t v)
{
{v} -> same_as;
};

static_assert(foo); // true in gcc-10, false in gcc-11
```

Thank you again, from my POV can be closed.

[Bug fortran/102287] optional allocatable array arguments (intent out) of derived types with allocatable components are not properly passed to subroutines.

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:216a4be1cc18119a83df562f7abb3dcebd9ce512

commit r10-10141-g216a4be1cc18119a83df562f7abb3dcebd9ce512
Author: Harald Anlauf 
Date:   Thu Sep 16 20:12:21 2021 +0200

Fortran - fix handling of optional allocatable DT arguments with
INTENT(OUT)

gcc/fortran/ChangeLog:

PR fortran/102287
* trans-expr.c (gfc_conv_procedure_call): Wrap deallocation of
allocatable components of optional allocatable derived type
procedure arguments with INTENT(OUT) into a presence check.

gcc/testsuite/ChangeLog:

PR fortran/102287
* gfortran.dg/intent_out_14.f90: New test.

(cherry picked from commit cfea7b86f2430b9cb8018379b071f4004233119c)

[Bug fortran/102366] [10/11/12 Regression] large arrays no longer become static

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #18 from anlauf at gcc dot gnu.org ---
Fixed on all affected branches.  Closing.

Thanks for the report!

[Bug fortran/102366] [10/11/12 Regression] large arrays no longer become static

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

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

--- Comment #17 from CVS Commits  ---
The releases/gcc-10 branch has been updated by Harald Anlauf
:

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

commit r10-10140-gd3db5b1d23cbe4e4569e688a6dbc8b5b2c38588e
Author: Harald Anlauf 
Date:   Fri Sep 17 21:45:33 2021 +0200

Fortran - (large) arrays in the main shall be static

gcc/fortran/ChangeLog:

PR fortran/102366
* trans-decl.c (gfc_finish_var_decl): Disable the warning message
for variables moved from stack to static storange if they are
declared in the main, but allow the move to happen.

gcc/testsuite/ChangeLog:

PR fortran/102366
* gfortran.dg/pr102366.f90: New test.

(cherry picked from commit 51166eb2c534692c3c7779def24f83c8c3811b98)

[Bug fortran/102366] [10/11/12 Regression] large arrays no longer become static

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

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

--- Comment #16 from CVS Commits  ---
The releases/gcc-11 branch has been updated by Harald Anlauf
:

https://gcc.gnu.org/g:7fbab3afca910c055676ebc566bf87c4d5a7372f

commit r11-9020-g7fbab3afca910c055676ebc566bf87c4d5a7372f
Author: Harald Anlauf 
Date:   Fri Sep 17 21:45:33 2021 +0200

Fortran - (large) arrays in the main shall be static

gcc/fortran/ChangeLog:

PR fortran/102366
* trans-decl.c (gfc_finish_var_decl): Disable the warning message
for variables moved from stack to static storange if they are
declared in the main, but allow the move to happen.

gcc/testsuite/ChangeLog:

PR fortran/102366
* gfortran.dg/pr102366.f90: New test.

(cherry picked from commit 51166eb2c534692c3c7779def24f83c8c3811b98)

[Bug middle-end/102415] [12 Regression] ICE in bb_seq_addr, at gimple.h:1786

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

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

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

Untested fix.

[Bug target/102429] New: nvptx: ICE with expand_GOMP_SIMT_XCHG_BFLY : in expand_insn, at optabs.c:7947

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

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

Bug ID: 102429
   Summary: nvptx: ICE with expand_GOMP_SIMT_XCHG_BFLY : in
expand_insn, at optabs.c:7947
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: vries at gcc dot gnu.org
  Target Milestone: ---

Created attachment 51490
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51490=edit
testcase, compile with nvptx offloading enabled with: gfortran -fopenmp -O1

That's with several OvO Fortran testcases, the smallest is:
https://github.com/TApplencourt/OvO/blob/master/test_src/fortran/hierarchical_parallelism/reduction_add-double_complex/target_simd.F90

The testcase (also attached) fails with:

  gfortran -fopenmp example.f90 -O1

with:

during RTL pass: expand
example.f90: In function 'MAIN__._omp_fn.0':
example.f90:23:32: internal compiler error: in expand_insn, at optabs.c:7947
   23 | counter_N0 = counter_N0 + 1.
  |^
0xb21933 expand_insn(insn_code, unsigned int, expand_operand*)
   
/net/build5-trusty-cs.sje.mentorg.com/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/optabs.c:7947
0x9761ad expand_GOMP_SIMT_XCHG_BFLY
   
/net/build5-trusty-cs.sje.mentorg.com/scratch/tburnus/openacc.x86_64-linux-gnu-openacc-mainline/src/gcc-mainline/gcc/internal-fn.c:375
0x700897 expand_call_stmt

Namely:

expand_insn (icode=CODE_FOR_omp_simt_xchg_bfly, nops=nops@entry=3,
ops=ops@entry=0x7fffda80)

fails at:

7946  if (!maybe_expand_insn (icode, nops, ops))
7947gcc_unreachable ();

(gdb) p *ops
$4 = {type = EXPAND_OUTPUT, unsigned_p = 0, target = 0, unused = 0, mode =
E_DCmode, value = 0x773fcc78, int_value = {> =
{coeffs = {0}}, }}

[Bug d/102428] New: d: Set TREE_NOTHROW for nothrow functions and library calls

[ibuclaw at gdcproject dot org via Gcc-bugs]

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

Bug ID: 102428
   Summary: d: Set TREE_NOTHROW for nothrow functions and library
calls
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: ibuclaw at gdcproject dot org
  Target Milestone: ---

Related to pr94496.  This in particular prevents us from using RAII when
-fno-exceptions is in effect.

i.e:
---
int test(int i) nothrow
{
int j = i ? S(3).i : 3; // generates __builtin_unwind_resume()
return j;
}

struct S
{
int i;
this(int i) nothrow { this.i += i; }
~this() nothrow { i = 0; }
}
---

Prevents the tests in the upstream D2 testsuite from being merged in, which are
expected to link without any D run-time.

gdc.test/runnable/bcraii.d
gdc.test/runnable/bcraii2.d
gdc.test/runnable/test20734.d

[Bug c++/81157] If constexpr does not support Short-circuit evaluation

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #2 from Patrick Palka  ---
Agreed.

If you need short-circuiting evaluation inside a constexpr if, just encode the
condition as a nested-requirement:

  if constexpr (requires { requires IsContainer && Same; })
...

[Bug c++/94673] [concepts] What is the return type of local parameters of requires expressions?

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #4 from Patrick Palka  ---
(In reply to gcc-bugs from comment #3)
> I think this bug should be changed to a request to improve the diagnostics.
> 
> The diagnostic says:
> 
> ```
> :13:15: note: constraints not satisfied
> :8:9:   required by the constraints of 'template concept
> foo'
> :8:15:   in requirements with 't v' [with t = int]
> :10:6: note: 'v' does not satisfy return-type-requirement
>10 | {v} -> same_as;
>   |  ^
> ```
> 
> If you don't know that `{v}` should be read as `{(v)}`, it is confusing that
> the diagnostic says that `'t v' [with t = int]` does not satisfy that the
> type of the expression `{ v }` is `t`.
> 
> I think the diagnostic for the return-type-requirement should add the reason
> / diagnostic why it isn't fulfilled, so basically the same reason that
> `static_assert(std::same_as);` would give.
> 
> > note: the expression 'is_same_v<_Tp, _Up> [with _Tp = int&; _Up = int]' 
> > evaluated to 'false'
> >   57 |   concept __same_as = std::is_same_v<_Tp, _Up>;
> >  |   ~^~~

Don't we already do this with -fconcepts-diagnostics-depth=2 ?

[Bug lto/102426] [12 regression] Fix for PR 49664 breaks Solaris bootstrap with gld

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-21
   Keywords||build
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
It seems like only this feature which libtool gets wrong.

There are other places where lt_cv_prog_gnu_ld/with_gnu_ld is checked.
So it should not be hard to add this check there.

I might come up with a patch which adds the check but it might not for a week.

[Bug middle-end/102427] -Woverflow only works in constant expressions

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

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

Martin Sebor  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||diagnostic
  Component|c   |middle-end
 Ever confirmed|0   |1
   Last reconfirmed||2021-09-21
Version|unknown |12.0
 Status|UNCONFIRMED |NEW
 CC||msebor at gcc dot gnu.org

--- Comment #3 from Martin Sebor  ---
There is some support for issuing overflow warnings in the middle end under
-Wstrict-overflow but that option is documented to only trigger in cases when
GCC makes codegen decisions based on the absence of overflow, which it doesn't
in this case (the overflow wraps around zero).

That no warning is issued here is partly a bug/limitation of the implementation
of the folder as indicated by the FIXME in wi::mul_internal() in wide-int.cc:

  if (sgn == SIGNED)
{
  if ((HOST_WIDE_INT) r != sext_hwi (r, prec))
/* FIXME: Signed overflow type is not implemented yet.  */
*overflow = OVF_UNKNOWN;

and partly also a consequence of simply discarding it when it is set above, by
calling drop_tree_overflow().  I don't know why that function is called.  But
preserving the overflow there still doesn't result in a warning.

I do agree that the constness of local variables shouldn't matter and issuing
the warning regardless would be helpful.  So confirmed as an enhancement
request.

[Bug target/102024] [12 Regression] zero width bitfields and ABIs

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

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

--- Comment #15 from Bill Schmidt  ---
Jakub, could you add a note with a section ID in
https://gcc.gnu.org/gcc-12/changes.html as was done for the similar case in GCC
10?  This allowed us to specify a URL in the informational diagnostic, like so:

const char *url = CHANGES_ROOT_URL "gcc-10/changes.html#empty_base";

inform (input_location,
"parameter passing for argument of type %qT "
"when C++17 is enabled changed to match C++14 "
"%{in GCC 10.1%}", type, url);

[Bug c/102427] -Woverflow only works in constant expressions

[david at westcontrol dot com via Gcc-bugs]

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

--- Comment #2 from David Brown  ---
Runtime detection is good - compile-time detection is much, much better when it
is possible.  (IMHO, of course.)

[Bug c/102427] -Woverflow only works in constant expressions

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

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

--- Comment #1 from Andrew Pinski  ---
You can use -fsanitize=undefined to detect overflow at runtime.

[Bug c/102427] New: -Woverflow only works in constant expressions

[david at westcontrol dot com via Gcc-bugs]

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

Bug ID: 102427
   Summary: -Woverflow only works in constant expressions
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: david at westcontrol dot com
  Target Milestone: ---

The "-Woverflow" warning only works with constant expressions.  Should it not
also work in cases where the compiler knows the value at compile time, even if
it is not a constant expression?

int foo(void) {
const int a = 534567891;
int b = a * 6;
return b;
} 

(With gcc -O2 -Wall -Wextra)

When "a" is declared "const", the compiler warns about the overflow.  If the
"const" is removed, the compiler still does the same calculations at compile
time, but does not give a warning even though it knows there was a signed
integer overflow.

Could "-Woverflow" be changed to warn here, when there is clearly undefined
behaviour?

[Bug lto/102426] [12 regression] Fix for PR 49664 breaks Solaris bootstrap with gld

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

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

--- Comment #1 from Andrew Pinski  ---
So libtool has been broken for over 15 years for this option and we are only
noticing now. G.

[Bug c++/102419] [11/12 Regression][concepts] [regression] return-type-requirement of "Y" does not check that T::type actually exists

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

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

--- Comment #3 from Patrick Palka  ---
And similarly for:

  template concept Y = true;
  template concept X = Y;
  static_assert(!X);

GCC rejects and Clang/MSVC accept.  IMHO Clang/MSVC are clearly misbehaving
here -- when evaluating the concept-id X, they appear to be substituting
{int} into X's constraint-expression instead of into the normal form of X's
constraint-expression.

[Bug c++/101597] [12 Regression] ICE in pretty-printer formatting an OBJ_TYPE_REF since r12-2132-ga110855667782dac

[philip.herron at embecosm dot com via Gcc-bugs]

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

Philip Herron  changed:

   What|Removed |Added

 CC||philip.herron at embecosm dot 
com

--- Comment #2 from Philip Herron  ---
I tested this bug out again on git-sha commit
e87789f197e47259c94349821d3446f7d959e08f (HEAD -> master, gcc/trunk, gcc/master

./gcc/cc1plus test.cc -fdump-tree-original -fdump-tree-gimple -fno-checking
-Warray-bounds -O3

Seems to be working for me.

[Bug c++/102419] [11/12 Regression][concepts] [regression] return-type-requirement of "Y" does not check that T::type actually exists

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

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

--- Comment #2 from Patrick Palka  ---
Note that you can make GCC effectively behave like Clang/MSVC here changing Y's
constraint-expression to trivially depend on its template parameter:

  template concept Y = requires { typename U; };

[Bug c++/102419] [11/12 Regression][concepts] [regression] return-type-requirement of "Y" does not check that T::type actually exists

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
The behavior of this testcase was changed with r11-7454 (the testcase
concepts-return-req2.C added there is essentially identical to this one). 
Before this commit, we'd substitute template arguments into the
return-type-requirement before checking satisfaction, and now we substitute
template arguments as part of satisfaction (into the normal form of the
constraint, which is just 'true (with an empty parameter mapping)'), which
explains the behavior change.

AFAICT, the standard is inconsistent about whether a separate substitution
should be performed here.  On the one hand, [expr.prim.req.compound] says

  - Substitution of template arguments (if any) into the
return-type-requirement is performed.

which suggests a separate substitution should be performed.  On the other hand,
the example in that same section says a compound-requirement is equivalent to a
simple-requirement & nested-requirement:

  Given concepts C and D,

requires {
  { E1 } -> C;
  { E2 } -> D;
};

  is equivalent to

  requires {
E1; requires C;
E2; requires D;
  };

and we certainly shouldn't be doing a separate substitution when checking a
nested-requirement.  IIUC, GCC's behavior is consistent with the example.

Generally GCC tries to avoid doing a separate substitution into a constraint
whenever we can get away with it and instead perform the substitution as part
of satisfaction.  This e.g. also occurs for the type-constraint of a 
placeholder type:

  template concept Y = true;
  template void f() {
Y auto y = 0;
  }
  template void f(); // GCC accepts, Clang/MSVC reject

[Bug libstdc++/102425] std::error_code() does not compare equal to std::error_condition()

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Last reconfirmed||2021-09-21
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #1 from Jonathan Wakely  ---
The switch in system_category().default_error_condition(int) needs to treat 0
as a known value.

[Bug libstdc++/95989] Segmentation fault compiling with static libraries and using jthread::request_stop

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

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

Eric Botcazou  changed:

   What|Removed |Added

 CC||ebotcazou at gcc dot gnu.org

--- Comment #19 from Eric Botcazou  ---
The test fails on a SPARC64/Linux box with:

GNU C Library (Debian GLIBC 2.32-4) stable release version 2.32.
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A
PARTICULAR PURPOSE.
Compiled by GNU CC version 10.3.0.
libc ABIs: UNIQUE IFUNC ABSOLUTE
For bug reporting instructions, please see:
.

It looks like we have the same problem with pthread_join now:

Thread 1 "95989" received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x00105670 in __gthread_join (
__value_ptr=, 
__threadid=)
at
/home/ebotcazou/build/sparc64-linux-gnu/libstdc++-v3/include/sparc64-linux-gnu/bits/gthr-default.h:669
#2  std::thread::join (this=0x7fef0b0)
at /home/ebotcazou/src/libstdc++-v3/src/c++11/thread.cc:112
#3  0x00103164 in std::jthread::join (this=0x7fef0a8)
at /home/ebotcazou/install/include/c++/12.0.0/thread:160
#4  0x001030e8 in std::jthread::~jthread (this=0x7fef0a8, 
__in_chrg=)
at /home/ebotcazou/install/include/c++/12.0.0/thread:130
#5  0x00100d88 in test01 () at 95989.cc:33
#6  0x00100ea8 in main () at 95989.cc:52

[Bug lto/102426] [12 regression] Fix for PR 49664 breaks Solaris bootstrap with gld

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

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

Rainer Orth  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug lto/102426] New: [12 regression] Fix for PR 49664 breaks Solaris bootstrap with gld

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

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

Bug ID: 102426
   Summary: [12 regression] Fix for PR 49664 breaks Solaris
bootstrap with gld
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ro at gcc dot gnu.org
CC: marxin at gcc dot gnu.org, pinskia at gcc dot gnu.org
  Target Milestone: ---
  Host: *-*-solaris2.11

By rev 48b3caffcacc99adf72ba1be189a7d9ebc4190be, master bootstrap is broken on 
Solaris when configured to use GNU ld:

The failure occurs trying to link lto-plugin.so:

libtool: link:
   /var/gcc/regression/master/11.4-gcc-gas-gld/build/./prev-gcc/xgcc
-B/var/gcc/regression/master/11.4-gcc-gas-gld/build/./prev-gcc/
-B/vol/gcc/i386-pc-solaris2.11/bin/ -B/vol/gcc/i386-pc-solaris2.11/bin/
-B/vol/gcc/i386-pc-solaris2.11/lib/ -isystem
/vol/gcc/i386-pc-solaris2.11/include -isystem
/vol/gcc/i386-pc-solaris2.11/sys-include   -fno-checking -shared -Wl,-z
-Wl,text -Wl,-M -Wl,.libs/liblto_plugin.so.exp -Wl,-h -Wl,liblto_plugin.so -o
.libs/liblto_plugin.so  .libs/lto-plugin.o-static-libgcc -static-libstdc++
-static-libgcc ../libiberty/pic/libiberty.a
/vol/gcc/bin/gld-2.37:.libs/liblto_plugin.so.exp: file format not recognized;
treating as linker script
/vol/gcc/bin/gld-2.37:.libs/liblto_plugin.so.exp:1: syntax error
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:466: liblto_plugin.la] Error 1

liblto_plugin.so.exp contains

{ global:
onload;
local: *; };

AFAICT, the issue is caused by libtool assuming that gcc on Solaris always
uses the native linker, which is wrong: I regularly test both ld and gld
configurations and this is also documented in install.texi.

The invocation above stems from libtool.m4 after l.5035:

solaris*)
  _LT_TAGVAR(no_undefined_flag, $1)=' -z defs'
  if test "$GCC" = yes; then
wlarc='${wl}'
_LT_TAGVAR(archive_cmds, $1)='$CC -shared ${wl}-z ${wl}text ${wl}-h
${wl}$soname -o $lib $libobjs $deplibs $compiler_flags'
_LT_TAGVAR(archive_expsym_cmds, $1)='echo "{ global:" > $lib.exp~cat
$export_symbols | $SED -e "s/\(.*\)/\1;/" >> $lib.exp~echo "local: *; };" >>
$lib.exp~
  $CC -shared ${wl}-z ${wl}text ${wl}-M ${wl}$lib.exp ${wl}-h
${wl}$soname -o $lib $libobjs $deplibs $compiler_flags~$RM $lib.exp'

The question is how to deal with this: libtool is unmaintained for 2 1/2 years
now.

[Bug libstdc++/102425] New: std::error_code() does not compare equal to std::error_condition()

[pdimov at gmail dot com via Gcc-bugs]

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

Bug ID: 102425
   Summary: std::error_code() does not compare equal to
std::error_condition()
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pdimov at gmail dot com
  Target Milestone: ---

As the title says. https://godbolt.org/z/er7qsjvoo.

[Bug middle-end/102424] New: OpenACC 'reduction' with outer 'loop seq', inner 'loop gang'

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

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

Bug ID: 102424
   Summary: OpenACC 'reduction' with outer 'loop seq', inner 'loop
gang'
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Keywords: openacc
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: tschwinge at gcc dot gnu.org
CC: frederik at gcc dot gnu.org
  Target Milestone: ---

Working on OpenACC 'kernels', Frederik noticed that
'libgomp.oacc-fortran/kernels-acc-loop-reduction-2.f90'
()
misbehaves if put into OpenACC 'parallel' form as follows:

@@ -16,13 +17,13 @@ subroutine bar(vol)
   INTEGER :: vol
   INTEGER :: j,k

-  !$ACC KERNELS
-  !$ACC LOOP REDUCTION(+:vol)
+  !$ACC PARALLEL
+  !$ACC LOOP SEQ REDUCTION(+:vol)
   DO k=1,2
- !$ACC LOOP REDUCTION(+:vol)
+ !$ACC LOOP GANG VECTOR REDUCTION(+:vol)
  DO j=1,2
vol = vol + 1
  ENDDO
   ENDDO
-  !$ACC END KERNELS
+  !$ACC END PARALLEL
 end subroutine bar

(Unusual here is the outer 'loop' with 'seq' clause.)
GCC accepts this without diagnostic -- but produces unexpected (wrong?) results
at runtime! (Though, not 100 %...)

It seems that generally this can be cured by avoiding gang parallelism in the
inner loop.

The problem can also be cured by putting a explicit 'reduction(+:vol)' clause
onto the compute construct itself (instead of implicit 'copy(vol)' clause per
current GCC implementation) -- and I can see how that triggers different
("proper") handling of 'var' as a reduction variable at the top-level in the
compute region.

In  (only visible to
members of the GitHub OpenACC organization) I'm discussing whether this is a
quality of implementation issue or a specification issue.

[Bug target/102255] target uses STABS by default

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.

[Bug target/102256] target uses STABS by default

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

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

Richard Biener  changed:

   What|Removed |Added

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

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

[Bug c++/102423] False accept of virtual methods with deduced return type

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||accepts-invalid
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2021-09-21

[Bug other/102408] [OpenACC] omp-oacc-neuter-broadcast.cc: random() not available on all platforms

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

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

Thomas Schwinge  changed:

   What|Removed |Added

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

--- Comment #3 from Thomas Schwinge  ---
Fixed.

[Bug other/102408] [OpenACC] omp-oacc-neuter-broadcast.cc: random() not available on all platforms

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

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

--- Comment #2 from CVS Commits  ---
The master branch has been updated by Thomas Schwinge :

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

commit r12-3726-ge87789f197e47259c94349821d3446f7d959e08f
Author: Thomas Schwinge 
Date:   Tue Sep 21 08:54:49 2021 +0200

Evaluate 'random ()' to '0' in 'pass_omp_oacc_neuter_broadcast'

Julian Brown,
:

| [...] the randomness shouldn't be necessary for the
| correctness of the patch (i.e. it could just be "base = bounds_lo", or
| indeed folded into the line after).
|
| The "ar.invalid ()" case happens when we fail to allocate a block of
| memory in LDS space for broadcasting a particular set of variables,
| and trigger a fall-back path in the broadcasting code that adds extra
| barriers around the broadcast in question. I imagine I was thinking
| that adding randomness could mean we can "get lucky" sometimes and
| avoid needing those barriers in some cases, but in fact I don't think
| that was implemented, so the randomness is useless. (Or it could just
| have been leftover debug code... oops).

gcc/
PR other/102408
* omp-oacc-neuter-broadcast.cc (oacc_do_neutering): Evaluate
'random ()' to '0'.

[Bug rtl-optimization/93007] [10/11/12 regression] pr77698.c testcase fails due to block commoning

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Target||arm-none-linux-gnueabihf
 Ever confirmed|0   |1
   Last reconfirmed||2021-09-21
   Keywords||missed-optimization

--- Comment #4 from Andrew Pinski  ---
Confirmed, basic block commoning should not really be touching the loop header
...

[Bug tree-optimization/94335] [10/11/12 Regression] False positive -Wstringop-overflow warning with -O2

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=102216

--- Comment #13 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #12)
> The warning for the testcase in comment #6 is gone in GCC 11.1.0.

But that looks like on accident (there is some early inlining differences) and
not really fixing the problem and there becomes a missing optimization.  I Have
a patch for the missed optimization (it is the same as PR 102216).

[Bug target/102421] [12 Regression] ICE with -march=armv8.2-a+sve -O3

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

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #14 from Richard Biener  ---
Fixed.

[Bug target/102421] [12 Regression] ICE with -march=armv8.2-a+sve -O3

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

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

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

https://gcc.gnu.org/g:55b989de7679a486ad674fb154408de26ac96467

commit r12-3724-g55b989de7679a486ad674fb154408de26ac96467
Author: Richard Biener 
Date:   Tue Sep 21 09:39:12 2021 +0200

tree-optimization/102421 - copy alignment info when splitting groups

This makes sure to copy and adjust alignment info when we are splitting
DR groups after alignment analysis.

2021-09-21  Richard Biener  

PR tree-optimization/102421
* tree-vect-loop.c (vect_dissolve_slp_only_groups): Copy and
adjust alignment info.

* g++.dg/vect/pr102421.cc: New testcase.

[Bug tree-optimization/94335] [10/11/12 Regression] False positive -Wstringop-overflow warning with -O2

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

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

--- Comment #12 from Andrew Pinski  ---
The warning for the one in comment #0 is gone on the trunk
The warning for the testcase in comment #6 is gone in GCC 11.1.0.

[Bug tree-optimization/86613] missing -Warray-bounds on a wide string access due to ccp folding

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=84050

--- Comment #2 from Andrew Pinski  ---
I suspect this is a dup of bug 84050.

[Bug target/102421] [12 Regression] ICE with -march=armv8.2-a+sve -O3

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

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

--- Comment #12 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #11)
> (In reply to Richard Biener from comment #10)
> > Going to use the following for g++.dg/vect/
> > 
> > /* { dg-do compile } */
> > /* { dg-additional-options "-O3" } */
> > /* { dg-additional-options "-march=armv8.2-a+sve" { target aarch64-*-* } } 
> > */
> 
> Add:
> // { dg-require-effective-target c++11 }

or change auto to std::vector.  either one "works".

[Bug target/102421] [12 Regression] ICE with -march=armv8.2-a+sve -O3

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

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

--- Comment #11 from Andrew Pinski  ---
(In reply to Richard Biener from comment #10)
> Going to use the following for g++.dg/vect/
> 
> /* { dg-do compile } */
> /* { dg-additional-options "-O3" } */
> /* { dg-additional-options "-march=armv8.2-a+sve" { target aarch64-*-* } } */

Add:
// { dg-require-effective-target c++11 }

[Bug tree-optimization/84050] [9/10/11/12 Regression] missing -Warray-bounds accessing a struct array member

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||marco.morandini at polimi dot 
it

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

[Bug tree-optimization/102422] Missing -Warray-bounds

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Dup of bug 84050.

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

[Bug tree-optimization/84050] [9/10/11/12 Regression] missing -Warray-bounds accessing a struct array member

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

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

--- Comment #10 from Andrew Pinski  ---
reduced testcase:
static int b[3] = { 1, 2, 3 };

int fstatic_array (void)
{
  return b[7];   // missing -Warray-bounds
}

[Bug target/102421] [12 Regression] ICE with -march=armv8.2-a+sve -O3

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

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

--- Comment #10 from Richard Biener  ---
Going to use the following for g++.dg/vect/

/* { dg-do compile } */
/* { dg-additional-options "-O3" } */
/* { dg-additional-options "-march=armv8.2-a+sve" { target aarch64-*-* } } */

[Bug target/102421] [12 Regression] ICE with -march=armv8.2-a+sve -O3

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

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

--- Comment #9 from Andrew Pinski  ---
Unincluded testcase:
#include 

template
struct BasicVector
{
ValueType& operator[](int i) { return x_[i]; }
ValueType operator[](int i) const { return x_[i]; }
ValueType x_[3];
};
typedef int ivec1[3];
typedef BasicVector RVec1;
void foo (
   std::vector _,
   std::vector _,
   int homenr,
   unsigned short* cFREEZE,
   const ivec1* nFreeze)
{
auto xp = xp_;
auto x = x_;
for (int i = 0; i < homenr; i++)
{
const int g = cFREEZE[i];
for (int d = 0; d < 3; d++)
{
if (nFreeze[g][d] == 0)
x[i][d] = xp[i][d];
}
}
}

[Bug tree-optimization/102422] Missing -Warray-bounds

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||diagnostic
  Component|c   |tree-optimization

--- Comment #1 from Andrew Pinski  ---
Visiting statement:
_1 = enc_cntr[3];
which is likely CONSTANT
Lattice value changed to CONSTANT 0.  Adding SSA edges to worklist.
marking stmt to be not simulated again

[Bug target/102421] [12 Regression] ICE with -march=armv8.2-a+sve -O3

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

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

--- Comment #8 from Richard Biener  ---
On x86 get_group_load_store_type ends up with VMAT_ELEMENTWISE because

  /* As a last resort, trying using a gather load or scatter store.

 ??? Although the code can handle all group sizes correctly,
 it probably isn't a win to use separate strided accesses based
 on nearby locations.  Or, even if it's a win over scalar code,
 it might not be a win over vectorizing at a lower VF, if that
 allows us to use contiguous accesses.  */
  if (*memory_access_type == VMAT_ELEMENTWISE
  && single_element_p
  && loop_vinfo
  && vect_use_strided_gather_scatters_p (stmt_info, loop_vinfo,
 masked_p, gs_info))
*memory_access_type = VMAT_GATHER_SCATTER;

doesn't trigger since vect_use_strided_gather_scatters_p only supports
gather IFNs, not builtins.  And then we end up in

  if (*memory_access_type == VMAT_ELEMENTWISE
  && !STMT_VINFO_STRIDED_P (first_stmt_info)
  && !(stmt_info == DR_GROUP_FIRST_ELEMENT (stmt_info)
   && !DR_GROUP_NEXT_ELEMENT (stmt_info)
   && !pow2p_hwi (DR_GROUP_SIZE (stmt_info
{
  if (dump_enabled_p ())
dump_printf_loc (MSG_MISSED_OPTIMIZATION, vect_location,
 "not falling back to elementwise accesses\n");
  return false;
}

now, vect_dissolve_slp_only_groups seems to compute wrong DR_GROUP_SIZE
for the !STMT_VINFO_STRIDED_P case.  It does

  DR_GROUP_SIZE (vinfo) = 1;
  if (STMT_VINFO_STRIDED_P (first_element))
DR_GROUP_GAP (vinfo) = 0;
  else
DR_GROUP_GAP (vinfo) = group_size - 1;

and for strided accesses we shouldn't really keep a grouped load.

I really wonder if we have enough test coverage here to assess correctness,
esp. DR_GROUP_SIZE == 1 looks awfully wrong.  IMHO it should be

   if (STMT_VINFO_STRIDED_P (first_element))
 /* No longer a grouped access.  */
 DR_GROUP_FIRST_ELEMENT (vinfo) = NULL;
   else
 {
   DR_GROUP_SIZE (vinfo) = group_size;
   DR_GROUP_GAP (vinfo) = group_size - 1;
 }

see vect_analyze_group_access_1.  For strided the current settings
might work out fine.