[Bug target/110027] [11/12/13/14 regression] Misaligned vector store on detect_stack_use_after_return

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

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

--- Comment #13 from Hongtao Liu  ---
So the stack is like

--- stack top

-32

- (offset -32)

-64 (32 bytes redzone)

- (offset -64)

-128 (64 bytes __m512)

 (offset -128)

 (32-bytes redzone)

---(offset -160)   <--- __asan_stack_malloc_128 try to allocate an buffer 


  /* Emit the prologue sequence.  */
  if (asan_frame_size > 32 && asan_frame_size <= 65536 && pbase
  && param_asan_use_after_return)
{
  use_after_return_class = floor_log2 (asan_frame_size - 1) - 5;
  /* __asan_stack_malloc_N guarantees alignment
 N < 6 ? (64 << N) : 4096 bytes.  */
  if (alignb > (use_after_return_class < 6
? (64U << use_after_return_class) : 4096U))
use_after_return_class = -1;
  else if (alignb > ASAN_RED_ZONE_SIZE && (asan_frame_size & (alignb - 1)))
base_align_bias = ((asan_frame_size + alignb - 1)
   & ~(alignb - HOST_WIDE_INT_1)) - asan_frame_size;
}

  /* Align base if target is STRICT_ALIGNMENT.  */
  if (STRICT_ALIGNMENT)
{
  const HOST_WIDE_INT align
= (GET_MODE_ALIGNMENT (SImode) / BITS_PER_UNIT) << ASAN_SHADOW_SHIFT;
  base = expand_binop (Pmode, and_optab, base, gen_int_mode (-align,
Pmode),
   NULL_RTX, 1, OPTAB_DIRECT);
}

  if (use_after_return_class == -1 && pbase)
emit_move_insn (pbase, base);

  base = expand_binop (Pmode, add_optab, base,
   gen_int_mode (base_offset - base_align_bias, Pmode),
   NULL_RTX, 1, OPTAB_DIRECT); -- suspicious add

  orig_base = NULL_RTX;
  if (use_after_return_class != -1)
{
  ...
  ret = emit_library_call_value (ret, NULL_RTX, LCT_NORMAL, ptr_mode,
 GEN_INT (asan_frame_size
  + base_align_bias),
 TYPE_MODE (pointer_sized_int_node));
  /* __asan_stack_malloc_[n] returns a pointer to fake stack if succeeded
 and NULL otherwise.  Check RET value is NULL here and jump over the
 BASE reassignment in this case.  Otherwise, reassign BASE to RET.  */
  emit_cmp_and_jump_insns (ret, const0_rtx, EQ, NULL_RTX,
   VOIDmode, 0, lab,
   profile_probability:: very_unlikely ());
  ret = convert_memory_address (Pmode, ret);
  emit_move_insn (base, ret);
  emit_label (lab);
  emit_move_insn (pbase, expand_binop (Pmode, add_optab, base,
   gen_int_mode (base_align_bias
 - base_offset, Pmode),
   NULL_RTX, 1, OPTAB_DIRECT));


base_align_bias is calculated to make (asan_frame_size(128) +
base_align_bias(0)) be multiple of alignb (64),  but didn't make `base_offset
(160) - base_align_bias (0)` be multiple of 64, so when __asan_stack_malloc_128
return an address aligned to 64, and then plus (base_offset (160) -
base_align_bias (0)), it's misaligned.

[Bug driver/114314] ICE: in common_handle_option, at opts.cc:3356 with -fno-multiflags

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
Fixed.

[Bug driver/114314] ICE: in common_handle_option, at opts.cc:3356 with -fno-multiflags

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

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

--- Comment #5 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Andrew Pinski
:

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

commit r13-8419-g4bd9d097197334e786690ba1566ccf79396da730
Author: Andrew Pinski 
Date:   Mon Mar 11 17:40:08 2024 -0700

Reject -fno-multiflags [PR114314]

When -fmultiflags option support was added in r13-3693-g6b1a2474f9e422,
it accidently allowed -fno-multiflags which then would pass on to cc1.
This fixes that oversight.

Committed as obvious after bootstrap/test on x86_64-linux-gnu.

gcc/ChangeLog:

PR driver/114314
* common.opt (fmultiflags): Add RejectNegative.

Signed-off-by: Andrew Pinski 
(cherry picked from commit c4e5789cede6974b6483c0f82069ff80b5a547e4)

[Bug driver/114314] ICE: in common_handle_option, at opts.cc:3356 with -fno-multiflags

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

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

--- Comment #4 from GCC Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r14-9434-gc4e5789cede6974b6483c0f82069ff80b5a547e4
Author: Andrew Pinski 
Date:   Mon Mar 11 17:40:08 2024 -0700

Reject -fno-multiflags [PR114314]

When -fmultiflags option support was added in r13-3693-g6b1a2474f9e422,
it accidently allowed -fno-multiflags which then would pass on to cc1.
This fixes that oversight.

Committed as obvious after bootstrap/test on x86_64-linux-gnu.

gcc/ChangeLog:

PR driver/114314
* common.opt (fmultiflags): Add RejectNegative.

Signed-off-by: Andrew Pinski 

[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e

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

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

--- Comment #10 from Andrew Pinski  ---
Created attachment 57678
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57678=edit
testcase that fails all the way back to GCC 4.8.x

This one fails until GCC 4.8.1, works in GCC 4.7.4 but that is because the
outer loop is unrolled in GCC 4.7.4.

[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #8)
> Note with the reduced testcase in comment #7, -fno-tree-vrp has no effect on
> it any more so it might make sense to do another bisection on that testcase.

I am suspecting r7-104-gfc9cf6da84a899 exposed the issue now. in GCC 6,
_mm_storeu_pd/_mm_loadu_pd were still builtins, but in GCC 7, they become
directly unaligned loads (starting with r7-104-gfc9cf6da84a899 ).

I suspect if manually change _mm_storeu_pd/_mm_loadu_pd to be similar to what
GCC 7 had, then we might even up with this failing before GCC 7.

[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|needs-reduction |

--- Comment #8 from Andrew Pinski  ---
Note with the reduced testcase in comment #7, -fno-tree-vrp has no effect on it
any more so it might make sense to do another bisection on that testcase.

[Bug middle-end/111683] [11/12/13/14 Regression] Incorrect answer when using SSE2 intrinsics with -O3 since r7-3163-g973625a04b3d9351f2485e37f7d3382af2aed87e

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

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

--- Comment #7 from Andrew Pinski  ---
Created attachment 57677
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57677=edit
Slightly more reduced

Removes the extra induction variables and manually unroll the inner loop.

What I am seeing is the first store is being removed.

[Bug libfortran/105456] Child I/O does not propage iostat

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

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

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #8 from Jerry DeLisle  ---
Not planning any backport on this. Closing.

[Bug fortran/20585] [meta-bug] Fortran 2003 support

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

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

Bug 105456 Summary: Child I/O does not propage iostat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456

   What|Removed |Added

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

[Bug libfortran/105361] Incorrect end-of-file condition for derived-type I/O

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

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

Bug 105456 Summary: Child I/O does not propage iostat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456

   What|Removed |Added

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

[Bug tree-optimization/114277] [11/12/13/14 Regression] Missed optimization: x*(x||b) => x

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #6 from Andrew Pinski  ---
I will implement this part of the Canonicalization .

[Bug driver/114314] ICE: in common_handle_option, at opts.cc:3356 with -fno-multiflags

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Status|NEW |ASSIGNED

--- Comment #3 from Andrew Pinski  ---
And yes adding RejectNegative fixes the ICE.

[Bug driver/114314] ICE: in common_handle_option, at opts.cc:3356 with -fno-multiflags

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-12
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
case OPT_fmultiflags:
  gcc_checking_assert (lang_mask == CL_DRIVER);
  break;

Yes it is a checking assert.

[Bug target/114310] [11/12/13/14 Regression] [aarch64] __sync_val_compare_and_swap fails on __int128_t with newval = 0

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Jeffrey A. Law from comment #2)
> !?!  That doesn't make any sense to me Andrew.   This is a failure to match
> the insn, not a constraint error.  And given the existence of a zero
> register, isn't zero valid anywhere a general purpose register is valid?

Then the issue is with the other side of UNSPECV_ATOMIC_CMPSW for the isns part
rather than the expand part.  I had only quickly looked the MD file and what
was done to fix the other bug.

[Bug target/114310] [11/12/13/14 Regression] [aarch64] __sync_val_compare_and_swap fails on __int128_t with newval = 0

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 CC||law at gcc dot gnu.org

--- Comment #2 from Jeffrey A. Law  ---
!?!  That doesn't make any sense to me Andrew.   This is a failure to match the
insn, not a constraint error.  And given the existence of a zero register,
isn't zero valid anywhere a general purpose register is valid?

[Bug c++/114315] New: Attributes should be diagnosed when placed in the middle of declaration specifiers

[luigighiron at gmail dot com via Gcc-bugs]

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

Bug ID: 114315
   Summary: Attributes should be diagnosed when placed in the
middle of declaration specifiers
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: luigighiron at gmail dot com
  Target Milestone: ---

GCC will accept programs that use attribute specifiers in the middle of
declaration specifiers, for example:

int[[]]signed main(){}

Attribute specifiers are not allowed inside of the declaration specifiers. I
would expect a warning or an error here, at least when
-pedantic/-pedantic-errors. Here is a link to the grammar of declaration
specifiers: https://eel.is/c++draft/dcl.spec.general#nt:decl-specifier-seq. The
attribute specifier is required to be at the end of the declaration specifiers.

[Bug tree-optimization/114277] [11/12/13/14 Regression] Missed optimization: x*(x||b) => x

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

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

--- Comment #5 from Andrew Pinski  ---
Thinking about this a little more.

((convert)boolean)*a is not Canonical

But `boolean?a:0` is. Due to one expression vs 2.

But `zero_one * a` is still Canonical if there is no cast from the boolean
type.

That will fix this issue but not the other.

[Bug target/114175] [13/14] RISC-V: Execution test failures on gcc.dg/c23-stdarg-6.c

[ewlu at rivosinc dot com via Gcc-bugs]

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

--- Comment #19 from Edwin Lu  ---
While debugging, I found that this testcase also breaks on x86_64 when
optimizations are enabled (-O1 -> -O3). 

Godbolt: https://godbolt.org/z/ecs5MPds8 

There may be other targets that fail as well. I haven't tested any others
though

[Bug driver/114314] ICE: in common_handle_option, at opts.cc:3356 with -fno-multiflags

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|middle-end  |driver
Summary|[14 Regression] ICE: in |ICE: in
   |common_handle_option, at|common_handle_option, at
   |opts.cc:3356 with   |opts.cc:3356 with
   |-fno-multiflags |-fno-multiflags

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2022-June/597419.html


Looks a missing rejects negative and it should not be passed from the driver to
cc1 either.

Maybe the rejects negative will fix the issue in general.


Oh this was added in gcc 13 and not just 14; maybe just ice checking.

[Bug c/114314] New: [14 Regression] ICE: in common_handle_option, at opts.cc:3356 with -fno-multiflags

[patrick at rivosinc dot com via Gcc-bugs]

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

Bug ID: 114314
   Summary: [14 Regression] ICE: in common_handle_option, at
opts.cc:3356 with -fno-multiflags
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: patrick at rivosinc dot com
  Target Milestone: ---

Testcase:
int square(int num) {
return num * num;
}

Backtrace:
> /scratch/tc-testing/tc-mar-11/build-rv64gcv/bin/riscv64-unknown-linux-gnu-gcc 
> -fno-multiflags red.c -freport-bug
cc1: internal compiler error: in common_handle_option, at opts.cc:3356
0xbfd174 common_handle_option(gcc_options*, gcc_options*, cl_decoded_option
const*, unsigned int, int, unsigned int, cl_option_handlers const*,
diagnostic_context*, void (*)())
../../../gcc/gcc/opts.cc:3356
0x2c40a93 handle_option
../../../gcc/gcc/opts-common.cc:1297
0x2c40c0c read_cmdline_option(gcc_options*, gcc_options*, cl_decoded_option*,
unsigned int, unsigned int, cl_option_handlers const*, diagnostic_context*)
../../../gcc/gcc/opts-common.cc:1627
0x11f126c read_cmdline_options
../../../gcc/gcc/opts-global.cc:242
0x11f126c decode_options(gcc_options*, gcc_options*, cl_decoded_option*,
unsigned int, unsigned int, diagnostic_context*, void (*)())
../../../gcc/gcc/opts-global.cc:324
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

Godbolt: https://godbolt.org/z/e3qevc464

I'm not sure what component parses the args, so I'm choosing the c frontend
since it's the earliest component I know.

[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'

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

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

--- Comment #33 from Jerry DeLisle  ---
(In reply to Tobias Burnus from comment #32)
> See PR114304 for an issue that was caused by the fix in comment 27.

Reverted portion of offending commit to fix.

[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

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

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

--- Comment #13 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jerry DeLisle
:

https://gcc.gnu.org/g:824a71f609b37a8121793075b175e2bbe14fdb82

commit r13-8417-g824a71f609b37a8121793075b175e2bbe14fdb82
Author: Jerry DeLisle 
Date:   Mon Mar 11 15:15:34 2024 -0700

libgfortran: [PR114304] Revert portion of PR105347 change.

PR libfortran/105437
PR libfortran/114304

libgfortran/ChangeLog:

* io/list_read.c (eat_separator): Remove check for decimal
point mode and semicolon used as a seprator. Removes
the regression.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr105473.f90: Add additional checks to address
the case of semicolon at the end of a line.

(cherry picked from commit 0c179654c3170749f3fb3232f2442fcbc99bffbb)

[Bug tree-optimization/105437] [11 Regression] ICE on GIMPLE pass slp when vectorizer is enabled since r11-1801-g9e5508c2d006f2d4

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

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

--- Comment #8 from GCC Commits  ---
The releases/gcc-13 branch has been updated by Jerry DeLisle
:

https://gcc.gnu.org/g:824a71f609b37a8121793075b175e2bbe14fdb82

commit r13-8417-g824a71f609b37a8121793075b175e2bbe14fdb82
Author: Jerry DeLisle 
Date:   Mon Mar 11 15:15:34 2024 -0700

libgfortran: [PR114304] Revert portion of PR105347 change.

PR libfortran/105437
PR libfortran/114304

libgfortran/ChangeLog:

* io/list_read.c (eat_separator): Remove check for decimal
point mode and semicolon used as a seprator. Removes
the regression.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr105473.f90: Add additional checks to address
the case of semicolon at the end of a line.

(cherry picked from commit 0c179654c3170749f3fb3232f2442fcbc99bffbb)

[Bug tree-optimization/105437] [11 Regression] ICE on GIMPLE pass slp when vectorizer is enabled since r11-1801-g9e5508c2d006f2d4

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Jerry DeLisle :

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

commit r14-9432-g0c179654c3170749f3fb3232f2442fcbc99bffbb
Author: Jerry DeLisle 
Date:   Mon Mar 11 15:15:34 2024 -0700

libgfortran: [PR114304] Revert portion of PR105347 change.

PR libfortran/105437
PR libfortran/114304

libgfortran/ChangeLog:

* io/list_read.c (eat_separator): Remove check for decimal
point mode and semicolon used as a seprator. Removes
the regression.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr105473.f90: Add additional checks to address
the case of semicolon at the end of a line.

[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

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

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

--- Comment #12 from GCC Commits  ---
The master branch has been updated by Jerry DeLisle :

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

commit r14-9432-g0c179654c3170749f3fb3232f2442fcbc99bffbb
Author: Jerry DeLisle 
Date:   Mon Mar 11 15:15:34 2024 -0700

libgfortran: [PR114304] Revert portion of PR105347 change.

PR libfortran/105437
PR libfortran/114304

libgfortran/ChangeLog:

* io/list_read.c (eat_separator): Remove check for decimal
point mode and semicolon used as a seprator. Removes
the regression.

gcc/testsuite/ChangeLog:

* gfortran.dg/pr105473.f90: Add additional checks to address
the case of semicolon at the end of a line.

[Bug c++/109946] [c++modules] linker error undefined reference to `vtable for std::bad_expected_access'

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

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

Patrick Palka  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |14.0
 CC||ppalka at gcc dot gnu.org
 Status|UNCONFIRMED |RESOLVED

--- Comment #1 from Patrick Palka  ---
This seems to work with recent GCC trunk.

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 109946 Summary: [c++modules] linker error undefined reference to `vtable 
for std::bad_expected_access'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109946

   What|Removed |Added

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

[Bug sanitizer/111057] [11/12/13 only] build error: libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.cpp:180:10: fatal error: crypt.h: No such file or directory

[romain.geissler at amadeus dot com via Gcc-bugs]

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

Romain Geissler  changed:

   What|Removed |Added

 CC||romain.geissler at amadeus dot 
com

--- Comment #6 from Romain Geissler  ---
@Chris the gcc maintainers don't really review patches send in bug reports,
they expect it to be sent on the mailing list (gcc-patc...@gcc.gnu.org). Do you
want to post it there so this gets integrated ?

[Bug testsuite/114307] [ARM] GCC generates instruction that assembler rejects

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||arm-linux-gnueabihf
  Component|target  |testsuite

--- Comment #3 from Andrew Pinski  ---
>From testsuite/gcc.dg/vect/tree-vect.h:
```
  {
/* On some processors without NEON support, this instruction may
   be a no-op, on others it may trap, so check that it executes
   correctly.  */
long long a = 0, b = 1;
asm ("vorr %P0, %P1, %P2"
 : "=w" (a)
 : "0" (a), "w" (b));
if (a != 1)
  exit (0);
  }
```
Hmm, what is the correct way of testing this here?


Also the other thing is maybe:
/* { dg-do run } */

Should be removed ...

The testcases in vect default to run if it is on HW that supports the SIMD
registers; otherwise it defaults to compile.

The only cases where specifying run is needed is if dg-additional-sources is
used.

Anyways this is a still a testsuite issue either way.

[Bug c++/99573] ICE in module: internal compiler error: tree check: expected class ‘type’, have ‘exceptional’ (error_mark) in start_enum, at cp/decl.c:15663

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||unlvsur at live dot com

--- Comment #5 from Patrick Palka  ---
*** Bug 101093 has been marked as a duplicate of this bug. ***

[Bug c++/101093] C++20 Module ICE cannot define 'enum class std::align_val_t' in different module

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #1 from Patrick Palka  ---
dup

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

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 101093 Summary: C++20 Module ICE cannot define 'enum class 
std::align_val_t' in different module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101093

   What|Removed |Added

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

[Bug fortran/110826] Fortran array of derived type with a pointer to function with dimensional arguments fails

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |anlauf at gcc dot 
gnu.org
   Priority|P3  |P4

--- Comment #2 from anlauf at gcc dot gnu.org ---
Submitted: https://gcc.gnu.org/pipermail/fortran/2024-March/060314.html

[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

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

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

--- Comment #11 from Jerry DeLisle  ---
Created attachment 57676
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57676=edit
Proposed patch

This patch fixes the issue by reverting the troublesome hunk and regression
tests OK on x86_64. The test case added for pr105473 still passes. I will add
the test attached already to this PR to our test suite.

[Bug c++/103754] [11,12][ice][modules] import bits/stdc++.h and map

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org
   Target Milestone|--- |13.0
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED

--- Comment #6 from Patrick Palka  ---
This seems fixed in GCC 13/trunk.

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 103754 Summary: [11,12][ice][modules] import bits/stdc++.h and map
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103754

   What|Removed |Added

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

[Bug c++/103524] [meta-bug] modules issue

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

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

Bug 102525 Summary: error: failed to read compiled module: Bad file data when 
trying to use modules possible 98944 regression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102525

   What|Removed |Added

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

[Bug c++/102525] error: failed to read compiled module: Bad file data when trying to use modules possible 98944 regression

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

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

Patrick Palka  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC||ppalka at gcc dot gnu.org
   Target Milestone|--- |13.0
 Resolution|--- |FIXED

--- Comment #1 from Patrick Palka  ---
This seems fixed in GCC 13/trunk.

[Bug c++/114311] Possibly wrong "error: ‘this’ is not a constant expression" with consteval member function

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

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

--- Comment #4 from Andrew Pinski  ---
I thought I saw this before ...

[Bug middle-end/114313] ICE: in limb_access_type, at gimple-lower-bitint.cc:591 with _BitInt() in a bitfield

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-03-11
  Component|tree-optimization   |middle-end
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed.

Easier testcase:
```
#define size 129
struct
{
  _BitInt(size) a : size;
  _BitInt(size) b : size;
} bf;

int
foo (void)
{
  return bf.b;
}
```

Note changing the bitfield size down to below 128 allows the above not to ICE.

[Bug middle-end/114312] ICE: SIGSEGV: infinite recursion in chrec_fold_plus_1 (tree-chrec.cc:336) at -O3 with _BitInt()

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-11
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed.

I thought there might be a way to hit this without _BitInt but even changing
`_BitInt(64)` to `long` causes the ICE/infinite loop to go away.

[Bug fortran/110826] Fortran array of derived type with a pointer to function with dimensional arguments fails

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #1 from anlauf at gcc dot gnu.org ---
The following patch appears to fix the ICE and produce working code:

diff --git a/gcc/fortran/array.cc b/gcc/fortran/array.cc
index 3a6e3a7c95b..0cb636b22c4 100644
--- a/gcc/fortran/array.cc
+++ b/gcc/fortran/array.cc
@@ -2597,6 +2597,13 @@ gfc_array_dimen_size (gfc_expr *array, int dimen, mpz_t
*result)
 case EXPR_FUNCTION:
   for (ref = array->ref; ref; ref = ref->next)
{
+ /* Ultimate component is a procedure pointer.  */
+ if (ref->type == REF_COMPONENT
+ && !ref->next
+ && ref->u.c.component->attr.function
+ && IS_PROC_POINTER (ref->u.c.component))
+   return false;
+
  if (ref->type != REF_ARRAY)
continue;

[Bug c++/114311] Possibly wrong "error: ‘this’ is not a constant expression" with consteval member function

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

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

--- Comment #3 from Jonathan Wakely  ---
MSVC compiles it but Clang and EDG agree with GCC:

$ clang++ c.cc -std=c++2b
c.cc:12:22: error: non-type template argument is not a constant expression
return SymbolRefid_>{};
 ^
c.cc:12:22: note: use of 'this' pointer is only allowed within the evaluation
of a call to a 'constexpr' member function
c.cc:20:29: error: call to consteval function 'Symbol::operator SymbolRef<1>'
is not a constant expression
  static_cast>(x);
^
c.cc:13:3: note: control reached end of constexpr function
  }
  ^
c.cc:20:29: note: in call to '>operator SymbolRef()'
  static_cast>(x);
^
c.cc:20:3: warning: expression result unused [-Wunused-value]
  static_cast>(x);
  ^~~~
1 warning and 2 errors generated.


$ edg --c++20 c.cc
"c.cc", line 12: error: expression must have a constant value
  return SymbolRefid_>{};
   ^
"c.cc", line 12: note: the value of *this cannot be used as a constant
  return SymbolRefid_>{};
   ^

"c.cc", line 12: error: class "SymbolRef<1>" has no suitable copy constructor
  return SymbolRefid_>{};
 ^
  detected during instantiation of "Symbol::operator SymbolRef()
const [with Id=1]" at line 20

2 errors detected in the compilation of "c.cc".

[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291

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

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

Thomas Neumann  changed:

   What|Removed |Added

  Attachment #57669|0   |1
is obsolete||

--- Comment #14 from Thomas Neumann  ---
Created attachment 57675
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57675=edit
updated patch

updated patch without single line blocks

[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

[rguenther at suse dot de via Gcc-bugs]

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

--- Comment #10 from rguenther at suse dot de  ---
> Am 11.03.2024 um 20:03 schrieb jvdelisle at gcc dot gnu.org 
> :
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
> 
> --- Comment #9 from Jerry DeLisle  ---
> Patch on comment #8 breaks all sorts of things. Not so obvious. I will try
> reverting the original hunk from pr105473 and then work from there.

Just to add, I think rejecting something we accepted before and when this
doesn’t fix a rejects-valid shouldn’t be done on branches and given it affects
the standard library, when it’s SONAME is not altered as it might affect
programs compiled with older libgfortran (maybe there’s the argument for
something like a LIBGFORTRAN_STRICT environment to control such if really
needed?)

> --
> You are receiving this mail because:
> You reported the bug.

[Bug c++/114311] Possibly wrong "error: ‘this’ is not a constant expression" with consteval member function

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

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

--- Comment #2 from Carlo Wood  ---
I meant `constexpr Symbol x;` inside main - with the same error.

[Bug tree-optimization/114313] New: ICE: in limb_access_type, at gimple-lower-bitint.cc:591 with _BitInt() in a bitfield

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 114313
   Summary: ICE: in limb_access_type, at
gimple-lower-bitint.cc:591 with _BitInt() in a
bitfield
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
CC: jakub at gcc dot gnu.org
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: x86_64-pc-linux-gnu

Created attachment 57674
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57674=edit
reduced testcase

Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.c
during GIMPLE pass: bitintlower0
testcase.c: In function 'foo':
testcase.c:8:1: internal compiler error: in limb_access_type, at
gimple-lower-bitint.cc:591
8 | foo (void)
  | ^~~
0xd748bf limb_access_type
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:591
0x264c8d4 limb_access_type
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:587
0x264c8d4 limb_access
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:606
0x265c659 handle_load
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:1857
0x265c659 handle_stmt
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:2066
0x265e1f4 lower_mergeable_stmt
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:2610
0x26625dc lower_stmt
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:5560
0x2665699 gimple_lower_bitint
/repo/gcc-trunk/gcc/gimple-lower-bitint.cc:6860
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.

$ x86_64-pc-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-amd64/bin/x86_64-pc-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-9425-2024032226-g119f5ae0455-checking-yes-rtl-df-extra-nobootstrap-amd64/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--disable-bootstrap --with-cloog --with-ppl --with-isl
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9425-2024032226-g119f5ae0455-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240311 (experimental) (GCC)

[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

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

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

--- Comment #9 from Jerry DeLisle  ---
Patch on comment #8 breaks all sorts of things. Not so obvious. I will try
reverting the original hunk from pr105473 and then work from there.

[Bug middle-end/114312] New: ICE: SIGSEGV: infinite recursion in chrec_fold_plus_1 (tree-chrec.cc:336) at -O3 with _BitInt()

[zsojka at seznam dot cz via Gcc-bugs]

get=x86_64-pc-linux-gnu --with-ld=/usr/bin/x86_64-pc-linux-gnu-ld
--with-as=/usr/bin/x86_64-pc-linux-gnu-as --enable-libsanitizer
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-9425-2024032226-g119f5ae0455-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240311 (experimental) (GCC)

[Bug c++/114311] Possibly wrong "error: ‘this’ is not a constant expression" with consteval member function

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

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

Carlo Wood  changed:

   What|Removed |Added

Summary|wrong "error: ‘this’ is not |Possibly wrong "error:
   |a constant expression" with |‘this’ is not a constant
   |consteval member function   |expression" with consteval
   ||member function

--- Comment #1 from Carlo Wood  ---
I stand corrected. When adding `this->` it is still giving an error when trying
to instantiate the template member function.

For example:

```
template
struct SymbolRef { };

struct Symbol {
  int const id_;

  consteval Symbol() : id_(1) { }

  template
  consteval operator SymbolRef() const
  {
return SymbolRefid_>{};
  }
};

int main()
{
  Symbol x;

  static_cast>(x);
}
```

Gives an equivalent error, despite the `this->`.
I am not certain anymore if this is a wrong error.

[Bug c++/114311] New: wrong "error: ‘this’ is not a constant expression" with consteval member function

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

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

Bug ID: 114311
   Summary: wrong "error: ‘this’ is not a constant expression"
with consteval member function
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: carlo at gcc dot gnu.org
  Target Milestone: ---

The following snippet:

```
template
struct SymbolRef { };

struct Symbol {
  int const id_;

  consteval Symbol() : id_(1) { }

  template
  consteval operator SymbolRef() const
  {
return SymbolRef{};
  }
};
```

fails with error:

```
source>: In member function 'consteval Symbol::operator SymbolRef() const':
:12:22: error: '*(const Symbol*)this' is not a constant expression
   12 | return SymbolRef{};
  |  ^~~
:12:22: note: in template argument for type 'int'
```

Not a regression.

DOES compile with using `this->id_`.

[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

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

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

Jerry DeLisle  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #8 from Jerry DeLisle  ---
This gets around the bogus error and makes sense to me.  However with your
reduced test case I get and EOF error later.  I also get this EOF witt gfortran
9. I have not checked 10, 11, or 12 yet.

If I can build lapack cleanly I will push this as sort of obvious.

$ git diff
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index e38e9a84976..c23c2bb2048 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -481,10 +481,10 @@ eat_separator (st_parameter_dt *dtp)
   break;

 case ';':
-  if (dtp->u.p.current_unit->decimal_status == DECIMAL_POINT)
+ if (dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
{
  generate_error (>common, LIBERROR_READ_VALUE,
-  "Semicolon not allowed as separator with DECIMAL='point'");
+  "Semicolon not allowed as separator with DECIMAL='comma'");
  unget_char (dtp, c);
  break;
}

[Bug c++/114309] Undesirable warning with [[unlikely]]

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

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

--- Comment #10 from Jonathan Wakely  ---
(In reply to Andrew Pinski from comment #6)
> Maybe it should have its own enable/disable and not tied to -Wattribute
> though.

Yes, -Wattributes is going to keep covering more and more different things as
new attributes get added. It doesn't really make sense to group them together.

[Bug c++/114309] Undesirable warning with [[unlikely]]

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

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

--- Comment #9 from Jonathan Wakely  ---
(In reply to M Welinder from comment #0)
> The standard, quoted from
> https://en.cppreference.com/w/cpp/language/attributes/likely, clearly
> contemplates this case:

N.B. cppreference is not the standard, and the text you quote is paraphrasing a
note from the standard, it's not the standard's actual wording.

> Note that the standard expressions itself in terms of "paths of execution"
> whereas g++ appears to have a narrower "branches of `if'" world view.  I am
> not sure whether that's relevant.

I don't think it's relevant, no. The "paths of execution" case covers switch
cases and things that aren't `if`, but since your code uses `if` that's what
GCC's warning refers to.

Anyway, in GCC's testcase we have:

   9   if (a == 123)
  10 [[likely]] c = 5;   // { dg-warning "both" }
  11   else
  12 [[likely]] b = 77;

Here we have two possible paths, and the attributes tell the compiler that the
first is more likely than the second, and the second is more likely than the
first. Obviously that's suspicious.

But code in comment 0 is more like:

  if (a)
;
  else if (b) [[unlikely]]
;
  else [[unlikely]]
;

In this case, not all paths through the function are marked unlikely. A
compiler treats the code above as:

  if (a)
;
  else {
if (b) [[unlikely]]
  ;
else [[unlikely]]
  ;
  }

And here it's certainly true that both branches of the second `if` are marked.
But many users do not think of it like this, they consider a series of if-else
branches to all be alternatives to each other. GCC seems to be thinking too
locally and not considering the surrounding context. There are paths through
the function that never even reach the second `if` and so there are paths of
execution that the compiler should consider to be more likely than any that
reach the second `if`. So I do think this is a bug.


Maybe the compiler should treat that code like:

  if (a)
;
  else {
[[unlikely]] if (b)
  ;
else
  ;
  }

i.e. if both branches are [[unlikely]] then "hoist" the attribute to before the
`if`. That doesn't warn, because now the compiler sees that there's another
branch not marked unlikely.

Aside: It might make more sense to mark the crash function as [[gnu::cold]]
instead of marking calls to it as unlikely.

[Bug target/114310] [11/12/13/14 Regression] [aarch64] __sync_val_compare_and_swap fails on __int128_t with newval = 0

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.5
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-03-11
 Ever confirmed|0   |1
Summary|[aarch64]   |[11/12/13/14 Regression]
   |__sync_val_compare_and_swap |[aarch64]
   |fails on __int128_t with|__sync_val_compare_and_swap
   |newval = 0  |fails on __int128_t with
   ||newval = 0
  Known to work||8.2.0
  Known to fail||8.5.0

--- Comment #1 from Andrew Pinski  ---
Most likely:
[apinski@xeond2 aarch64]$ git diff atomics.md
diff --git a/gcc/config/aarch64/atomics.md b/gcc/config/aarch64/atomics.md
index 32a0a723732..759e280468a 100644
--- a/gcc/config/aarch64/atomics.md
+++ b/gcc/config/aarch64/atomics.md
@@ -98,8 +98,8 @@ (define_insn_and_split "@aarch64_compare_and_swap"
 (match_operand:JUST_TI 1 "aarch64_sync_memory_operand" "+Q")) ;; memory
(set (match_dup 1)
 (unspec_volatile:JUST_TI
-  [(match_operand:JUST_TI 2 "aarch64_reg_or_zero" "rZ");; expect
-   (match_operand:JUST_TI 3 "aarch64_reg_or_zero" "rZ");; desired
+  [(match_operand:JUST_TI 2 "aarch64_reg_or_zero" "r") ;; expect
+   (match_operand:JUST_TI 3 "aarch64_reg_or_zero" "r") ;; desired
(match_operand:SI 4 "const_int_operand");;
is_weak
(match_operand:SI 5 "const_int_operand");;
mod_s
(match_operand:SI 6 "const_int_operand")]   ;; mod_f

[Bug libgcc/111731] [13/14 regression] gcc_assert is hit at libgcc/unwind-dw2-fde.c#L291

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #13 from Jakub Jelinek  ---
(In reply to Thomas Neumann from comment #11)
> Created attachment 57669 [details]
> patch to handle overlapping ranges
> 
> Does this patch fix the problem for you? I think it should, but I would
> really like to have a reproducer to make sure.

Note, the formatting is wrong, single statements shouldn't be wrapped in
between { and } in if/else/while/do/for etc. subblocks.

[Bug c++/109966] [13/14 Regression] ICE in gimplify_var_or_parm_decl, à gimplify.cc:3058

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

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

--- Comment #6 from Marek Polacek  ---
This looks like a failure of potential_prvalue_result_of to notice that there's
copy elision taking place (when initializing a field of the array arr).

[Bug analyzer/114285] Use of uninitialized value when copying a struct field by field

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #7 from Jakub Jelinek  ---
Note, if all you want is just to avoid the -Wuninitialized warnings for Rust
copies from uninitialized, just wrap the memcpy into some noipa wrapper, then
the compiler won't know whether the data isn't initialized in there etc.
Or set no warning flag on the unitialized var (but that will turn off that
warning on all uses).

[Bug c++/114309] Undesirable warning with [[unlikely]]

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7)
> Also this works just fine to disable the warning around the unlikely:
> #define push_warning _Pragma("GCC diagnostic push")
> #define pop_warning _Pragma("GCC diagnostic pop")
> #define disable_warning _Pragma("GCC diagnostic ignored  \"-Wattributes\"")
> 
> #define barf(msg) do { push_warning disable_warning [[unlikely]] crash(msg);
> pop_warning } while(0)

Actually you don't even need the push/pop/disable.

This is enough to disable the warning:

#define barf(msg) do {  [[unlikely]] crash(msg); } while(0)

[Bug c/114310] New: [aarch64] __sync_val_compare_and_swap fails on __int128_t with newval = 0

[p.nguyen at yahooinc dot com via Gcc-bugs]

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

Bug ID: 114310
   Summary: [aarch64] __sync_val_compare_and_swap fails on
__int128_t with newval = 0
   Product: gcc
   Version: 8.5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: p.nguyen at yahooinc dot com
  Target Milestone: ---

I am encountering a compiler error when __sync_val_compare_and_swap is passed
__int128_t types and newval = 0. It does not occur when newval is not zero, or
a const volatile variable with the value of 0 is passed to it. This only fails
when using built-in aarch64 LSE instructions, enabled with -march=armv8.1-a or
greater. It does not have problems with -march=armv8-a. 

I have been able to replicate the issue on GCC 8.5.0, 10.3.1, 11.2.1, 11.4.0,
12.2.1 and 13.1.1 on linux-aarch64. 

I have attached a trivial test case, and also have a small result set on
godbolt: https://godbolt.org/z/ex9adPTPc

I am showing the output from Ubuntu 22.04.4 LTS with gcc 11.4.0

The command line options are: gcc -v -march=armv8.1-a -save-temps test.c

The complete compiler output is: 

Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/aarch64-linux-gnu/11/lto-wrapper
Target: aarch64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu
11.4.0-1ubuntu1~22.04' --with-bugurl=file:///usr/share/doc/gcc-11/README.Bugs
--enable-languages=c,ada,c++,go,d,fortran,objc,obj-c++,m2 --prefix=/usr
--with-gcc-major-version-only --program-suffix=-11
--program-prefix=aarch64-linux-gnu- --enable-shared --enable-linker-build-id
--libexecdir=/usr/lib --without-included-gettext --enable-threads=posix
--libdir=/usr/lib --enable-nls --enable-bootstrap --enable-clocale=gnu
--enable-libstdcxx-debug --enable-libstdcxx-time=yes
--with-default-libstdcxx-abi=new --enable-gnu-unique-object
--disable-libquadmath --disable-libquadmath-support --enable-plugin
--enable-default-pie --with-system-zlib --enable-libphobos-checking=release
--with-target-system-zlib=auto --enable-objc-gc=auto --enable-multiarch
--enable-fix-cortex-a53-843419 --disable-werror --enable-checking=release
--build=aarch64-linux-gnu --host=aarch64-linux-gnu --target=aarch64-linux-gnu
--with-build-config=bootstrap-lto-lean --enable-link-serialization=2
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.4.0 (Ubuntu 11.4.0-1ubuntu1~22.04) 
COLLECT_GCC_OPTIONS='-v' '-march=armv8.1-a' '-save-temps' '-mlittle-endian'
'-mabi=lp64' '-dumpdir' 'a-'
 /usr/lib/gcc/aarch64-linux-gnu/11/cc1 -E -quiet -v -imultiarch
aarch64-linux-gnu test.c -march=armv8.1-a -mlittle-endian -mabi=lp64
-fpch-preprocess -fasynchronous-unwind-tables -fstack-protector-strong -Wformat
-Wformat-security -fstack-clash-protection -o a-test.i
ignoring nonexistent directory "/usr/local/include/aarch64-linux-gnu"
ignoring nonexistent directory
"/usr/lib/gcc/aarch64-linux-gnu/11/include-fixed"
ignoring nonexistent directory
"/usr/lib/gcc/aarch64-linux-gnu/11/../../../../aarch64-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/aarch64-linux-gnu/11/include
 /usr/local/include
 /usr/include/aarch64-linux-gnu
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-march=armv8.1-a' '-save-temps' '-mlittle-endian'
'-mabi=lp64' '-dumpdir' 'a-'
 /usr/lib/gcc/aarch64-linux-gnu/11/cc1 -fpreprocessed a-test.i -quiet -dumpdir
a- -dumpbase test.c -dumpbase-ext .c -march=armv8.1-a -mlittle-endian
-mabi=lp64 -version -fasynchronous-unwind-tables -fstack-protector-strong
-Wformat -Wformat-security -fstack-clash-protection -o a-test.s
GNU C17 (Ubuntu 11.4.0-1ubuntu1~22.04) version 11.4.0 (aarch64-linux-gnu)
compiled by GNU C version 11.4.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C17 (Ubuntu 11.4.0-1ubuntu1~22.04) version 11.4.0 (aarch64-linux-gnu)
compiled by GNU C version 11.4.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 52ed857e9cd110e5efaa797811afcfbb
test.c: In function ‘main’:
test.c:6:1: error: unrecognizable insn:
6 | }
  | ^
(insn 12 11 13 2 (parallel [
(set (reg:TI 92 [ _1 ])
(mem/v:TI (reg:DI 99) [-1  S16 A128]))
(set (mem/v:TI (reg:DI 99) [-1  S16 A128])
(unspec_volatile:TI [
(reg:TI 92 [ _1 ])
(const_int 0 [0])
(const_int 32773 [0x8005])
] UNSPECV_ATOMIC_CMPSW))
]) "test.c":4:31 -1
 (nil))
during RTL pass: vregs
test.c:6:1: internal compiler error: in extract_insn, at recog.c:2770
0xaeb1c7 

[Bug c++/114309] Undesirable warning with [[unlikely]]

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

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

--- Comment #7 from Andrew Pinski  ---
Also this works just fine to disable the warning around the unlikely:
#define push_warning _Pragma("GCC diagnostic push")
#define pop_warning _Pragma("GCC diagnostic pop")
#define disable_warning _Pragma("GCC diagnostic ignored  \"-Wattributes\"")

#define barf(msg) do { push_warning disable_warning [[unlikely]] crash(msg);
pop_warning } while(0)

[Bug middle-end/111126] Not always using czero.eqz

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

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

--- Comment #5 from Jeffrey A. Law  ---
Multiply as a canonical form of a conditional move/zero seems fairly
non-obvious relative to a conditional expression.

But I don't mind going with consensus on a canonical form.  After all we just
need to define one.

The bigger question is fixing the expansion.

We can expand as a multiply, x&-y or with a conditional-move like sequence.

[Bug c++/114309] Undesirable warning with [[unlikely]]

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

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

--- Comment #6 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #4)
> I think the warning is very much desirable.  It is not an error, just a
> warning that the code does something weird.

Maybe it should have its own enable/disable and not tied to -Wattribute though.

[Bug target/114307] [ARM] GCC generates instruction that assembler rejects

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

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

--- Comment #2 from Richard Earnshaw  ---
Note that it's clear from the .syntax markers that this is inline assembler
that's the source of the invalid instructions.

[Bug target/114307] [ARM] GCC generates instruction that assembler rejects

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

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

Richard Earnshaw  changed:

   What|Removed |Added

   Last reconfirmed||2024-03-11
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #1 from Richard Earnshaw  ---
>From a full assembler dump:

.syntax divided
@ 71 "/home/rearnsha/gnusrc/gcc/master/gcc/testsuite/gcc.dg/vect/tree-vect.h" 1
vorr d6, d6, d7
@ 0 "" 2
.arm
.syntax unified

So this is a problem with the test; it shouldn't be enabled for this target.

[Bug tree-optimization/114277] [11/12/13/14 Regression] Missed optimization: x*(x||b) => x

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Raphael M Zinsly from comment #3)
> Created attachment 57670 [details]
> proposed patch
> 
> I created this patch using the approach Jeff mentioned, I tested and it
> fixes this bug.

As I mentioned in the other issue, there is an open question about which is
more Canonical.

I don't have this one listed on
https://gcc.gnu.org/wiki/GimpleCanonical#preview yet but I will add it. Because
there are 3 different ways of representing it.

[Bug c++/114309] Undesirable warning with [[unlikely]]

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

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

--- Comment #5 from Andrew Pinski  ---
Speficially this email:
https://gcc.gnu.org/pipermail/gcc-patches/2018-November/511208.html

[Bug c++/114309] Undesirable warning with [[unlikely]]

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #4 from Jakub Jelinek  ---
I think the warning is very much desirable.  It is not an error, just a warning
that the code does something weird.

[Bug c++/114309] Undesirable warning with [[unlikely]]

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

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

--- Comment #3 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2018-November/510776.html

```
Would you please consider an error diagnostics for situations written in
test4.C?
Such situation is then silently ignored in profile_estimate pass:

Predictions for bb 2
  hot label heuristics of edge 2->4 (edge pair duplicate): 85.00%
  hot label heuristics of edge 2->3 (edge pair duplicate): 85.00%
```

[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

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

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

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-03-11
 Ever confirmed|0   |1

--- Comment #7 from Jerry DeLisle  ---
I suppose we can put this error behind a -std= option. Just my luck it is
discovered right after I backport to 13. The semi-colon in this case is
intended to indicate the end of the line I think.

I will have to did through the standards a but.  If one is desperate to fix
this and we need to revert on 13, let me know.

[Bug c++/114309] Undesirable warning with [[unlikely]]

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

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

--- Comment #2 from Andrew Pinski  ---
The warning was added when this attribute was added in r9-4186-g2674fa47de9ecf
and even added a testcase for this warning g++.dg/cpp2a/attr-likely4.C .

[Bug c++/114309] Undesirable warning with [[unlikely]]

[terra at gnome dot org via Gcc-bugs]

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

--- Comment #1 from M Welinder  ---
Created attachment 57672
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57672=edit
Preprocessed source code

[Bug middle-end/111126] Not always using czero.eqz

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Raphael M Zinsly from comment #3)
> Created attachment 57671 [details]
> proposed patch
> 
> This is the same patch I posted in PR114277, it fixes this bug as well.

The question is which is more Canonical on gimple. the multiply or the
cond_expr.
I say the multiply.

Since the multiply is.
then  you just need to add the case to 
"/* Expand X*Y as X&-Y when Y must be zero or one.  */"
instead in expr.cc.

Though it does some costing which also needs/should be handled too.

[Bug c++/114309] New: Undesirable warning with [[unlikely]]

[terra at gnome dot org via Gcc-bugs]

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

Bug ID: 114309
   Summary: Undesirable warning with [[unlikely]]
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: terra at gnome dot org
  Target Milestone: ---

g++ warns over the following program which uses [[unlikely]] for aborting error
reporting and conditionally chooses between two error messages:

# /usr/local/products/gcc/13.1.0/bin/g++ -O2 -c ttt-if-dual-unlikely.C
ttt-if-dual-unlikely.C: In function ‘void if_dual_warning(int)’:
ttt-if-dual-unlikely.C:3:19: warning: both branches of ‘if’ statement marked as
‘unlikely’ [-Wattributes]
3 | #define barf(msg) [[unlikely]] crash(msg)
  |   ^~~~
ttt-if-dual-unlikely.C:22:5: note: in expansion of macro ‘barf’
   22 | barf("foo");
  | ^~~~

g++ is correct that both branches have [[unlikely]].  What is not correct is to
warn over it.  g++ should instead simply infer that the second "if" is itself
unlikely to be reached.

The standard, quoted from
https://en.cppreference.com/w/cpp/language/attributes/likely, clearly
contemplates this case:

"Applies to a statement to allow the compiler to optimize for the case where
paths of execution including that statement are less likely than any
alternative path of execution that does not include such a statement."

Note that the standard expressions itself in terms of "paths of execution"
whereas g++ appears to have a narrower "branches of `if'" world view.  I am not
sure whether that's relevant.

Issuing this warning is a made a bit worse by the lack of a simple, local way
to suppress the warning in the same way that "if ((var = val)) { ... }" is a
way to suppress the warning about assignment in condition.


# cat ttt-if-dual-unlikely.C
#include 

#define barf(msg) [[unlikely]] crash(msg)

void
crash (const char*msg)
{
  std::cerr << msg << std::endl;
  abort ();
}


void
if_dual_warning (int i)
{
  bool runtime_cond0 = i > 0;
  bool runtime_cond1 = i > 1;

  if (runtime_cond0) {
std::cerr << "Something\n";
  } else if (runtime_cond1) {
barf("foo");
  } else {
barf("bar");
  }
}

[Bug testsuite/113428] [14 regression] gcc.dg/gomp/bad-array-section-c-3.c fails after r14-7158-gb5476e4c881b0d

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

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

Richard Earnshaw  changed:

   What|Removed |Added

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

--- Comment #8 from Richard Earnshaw  ---
Fixed

[Bug middle-end/111126] Not always using czero.eqz

[rzinsly at ventanamicro dot com via Gcc-bugs]

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

--- Comment #3 from Raphael M Zinsly  ---
Created attachment 57671
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57671=edit
proposed patch

This is the same patch I posted in PR114277, it fixes this bug as well.

[Bug tree-optimization/114277] [11/12/13/14 Regression] Missed optimization: x*(x||b) => x

[rzinsly at ventanamicro dot com via Gcc-bugs]

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

--- Comment #3 from Raphael M Zinsly  ---
Created attachment 57670
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57670=edit
proposed patch

I created this patch using the approach Jeff mentioned, I tested and it fixes
this bug.

[Bug libfortran/114304] [14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"

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

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

--- Comment #6 from Tobias Burnus  ---
[For completeness: The LAPACK testsuite change Richard mentioned in comment 2
is
https://github.com/Reference-LAPACK/lapack/commit/64e8a7500d817869e5fcde35afd39af8bc7a8086
- That's for g95 and was applied 2020.]

[Bug fortran/114308] ICE in fold_convert_loc, at fold-const.cc:2627

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

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

--- Comment #1 from Andrew Pinski  ---
GCC before 7 didn't support this feature:
Error: Assignment to an allocatable polymorphic variable at (1) is not yet
supported

[Bug middle-end/114198] [14] RISC-V fixed-length vector -flto ICE: in vectorizable_load, at tree-vect-stmts.cc:10570

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

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

--- Comment #4 from Patrick O'Neill  ---
Fixed on tip-of-tree!

[Bug rtl-optimization/114261] [13/14 Regression] Scheduling takes excessive time (97%)

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

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

Alexander Monakov  changed:

   What|Removed |Added

 CC||mkuvyrkov at gcc dot gnu.org

--- Comment #5 from Alexander Monakov  ---
It appears sched-deps is O(N*M) given N reg_pending_barriers and M distinct
pseudos in a region (or even a basic block). For instance, on the following
testcase

#define x10(x) x x x x x x x x x x
#define x100(x) x10(x10(x))
#define x1(x) x100(x100(x))

void f(int);

void g(int *p)
{
#if 1
x1(f(*p++);)
#else
x1(asm("" :: "r"(*p++));)
#endif
}

gcc -O -fschedule-insns invokes add_dependence 2 times for each asm/call
after the first. There is a loop

  for (i = 0; i < (unsigned)deps->max_reg; i++)
{
  struct deps_reg *reg_last = >reg_last[i];
  reg_last->sets = alloc_INSN_LIST (insn, reg_last->sets);
  SET_REGNO_REG_SET (>reg_last_in_use, i);
}

that registers the insn with reg_pending_barrier != 0 in reg_last->sets of each
pseudo, and then all those reg_last->sets will be inspected on the next
reg_pending_barrier insn.

[Bug middle-end/114198] [14] RISC-V fixed-length vector -flto ICE: in vectorizable_load, at tree-vect-stmts.cc:10570

[patrick at rivosinc dot com via Gcc-bugs]

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

--- Comment #3 from Patrick O'Neill  ---
Fixed!

[Bug middle-end/114195] [14] RISC-V vector ICE: in vectorizable_store, at tree-vect-stmts.cc:8690

[patrick at rivosinc dot com via Gcc-bugs]

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

Patrick O'Neill  changed:

   What|Removed |Added

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

--- Comment #5 from Patrick O'Neill  ---
Fixed - Thank you!

[Bug fortran/114308] New: ICE in fold_convert_loc, at fold-const.cc:2627

[asiancorporator at yahoo dot de via Gcc-bugs]

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

Bug ID: 114308
   Summary: ICE in fold_convert_loc, at fold-const.cc:2627
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: asiancorporator at yahoo dot de
  Target Milestone: ---

I am getting an error when I tried to extend an array that is supposed to
contain instances inherited from abstract classes. Ran on macOS Sonoma 14.2.1
(M1) with gfortran 13.2.1.

module my_module
  implicit none
  private

  type, abstract, public :: a
  end type

  type, extends(a), public :: b
  end type
end

program main
  use my_module
  implicit none

  class(a), allocatable :: a_array(:)
  type(b) :: b_instance

  a_array = [b_instance] ! This line works
  a_array = [a_array, b_instance] ! This one throws an ICE
end program

Output:

main.f90   failed.
[ 50%] Compiling...
app/main.f90:20:58:

   20 |   a_array = [a_array, b_instance] ! This one throws an ICE
  |  1
internal compiler error: in fold_convert_loc, at fold-const.cc:2627
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.
 Compilation failed for object " app_main.f90.o "
 stopping due to failed compilation
STOP 1

[Bug target/114307] New: [ARM] GCC generates instruction that assembler rejects

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

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

Bug ID: 114307
   Summary: [ARM] GCC generates instruction that assembler rejects
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mkuvyrkov at gcc dot gnu.org
  Target Milestone: ---

Recently added vectorization test "gcc.dg/vect/pr113576.c" fails to build for
arm-linux-gnueabihf with:
===
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/bin/arm-linux-gnueabihf-gcc
--sysroot=/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/builds/destdir/x86_64-pc-linux-gnu/arm-linux-gnueabihf/libc
/home/tcwg-buildslave/workspace/tcwg_gnu_1/abe/snapshots/gcc.git~master/gcc/testsuite/gcc.dg/vect/pr113576.c
-fdiagnostics-plain-output -O3 -lm -o ./pr113576.exe
/tmp/ccRWeLpQ.s: Assembler messages:
/tmp/ccRWeLpQ.s:37: Error: selected FPU does not support instruction -- `vorr
d6,d6,d7'
compiler exited with status 1
output is:
/tmp/ccRWeLpQ.s: Assembler messages:
/tmp/ccRWeLpQ.s:37: Error: selected FPU does not support instruction -- `vorr
d6,d6,d7'

comp_output (pruned) is:
/tmp/ccRWeLpQ.s: Assembler messages:
/tmp/ccRWeLpQ.s:37: Error: selected FPU does not support instruction -- `vorr
d6,d6,d7'

FAIL: gcc.dg/vect/pr113576.c (test for excess errors)
===

The toolchain uses tip-of-trunk binutils for the build.

The relevant configure flags are: --with-float=hard --with-fpu=vfpv3-d16
--with-mode=thumb --with-tune=cortex-a9 --with-arch=armv7-a

Full configure options are at
https://ci.linaro.org/job/tcwg_gnu_cross_check_gcc--master-arm-build/lastSuccessfulBuild/artifact/artifacts/notify/configure-make.txt/*view*/

[Bug testsuite/113428] [14 regression] gcc.dg/gomp/bad-array-section-c-3.c fails after r14-7158-gb5476e4c881b0d

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Richard Earnshaw :

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

commit r14-9430-gc27b30552e6cc789425d3628d294dafc5f3a0861
Author: Richard Earnshaw 
Date:   Wed Mar 6 13:41:02 2024 +

gomp: testsuite: improve compatibility of bad-array-section-3.c [PR113428]

This test generates different warnings on ilp32 targets because the size
of an integer matches the size of a pointer.  Avoid this by using
signed char.

gcc/testsuite:

PR testsuite/113428
* gcc.dg/gomp/bad-array-section-c-3.c: Use signed char instead
of int.

[Bug modula2/114295] incorrect error location if attempting to compile implementation module without a definition module

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

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

Gaius Mulley  changed:

   What|Removed |Added

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

--- Comment #3 from Gaius Mulley  ---
Closing now the patch has been applied.

[Bug modula2/114295] incorrect error location if attempting to compile implementation module without a definition module

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Gaius Mulley :

https://gcc.gnu.org/g:8410402272038aae7e4b2bd76df38607a78cad95

commit r14-9429-g8410402272038aae7e4b2bd76df38607a78cad95
Author: Gaius Mulley 
Date:   Mon Mar 11 15:21:42 2024 +

PR modula2/114295 Incorrect location if compiling implementation without
definition

This patch fixes a bug which occurred if gm2 was asked to compile an
implementation module and could not find the definition module.  The error
location would be set to the SYSTEM module.  The bug occurred as the
module sym was created during the peep phase after which the few tokens are
destroyed and recreated during parsing.  The bug fix is to call
PutDeclared when the module is encountered during parsing which updates
the tokenno associated with the module.

gcc/m2/ChangeLog:

PR modula2/114295
* gm2-compiler/M2Batch.mod (MakeProgramSource): Call PutDeclared
if the module is known.
(MakeDefinitionSource): Ditto.
(MakeImplementationSource): Ditto.
* gm2-compiler/M2Comp.mod (ExamineHeader): New procedure.
(ExamineCompilationUnit): Rewrite.
(PeepInto): Rewrite.
* gm2-compiler/M2Error.mod (NewError): Remove default call to
GetTokenNo.
* gm2-compiler/M2Quads.mod (callRequestDependant): Push tokno with
Adr.
(BuildStringAdrParam): Ditto.
(doBuildBinaryOp): Push OperatorPos on the bool stack.
(BuildRelOp): Ditto.
* gm2-compiler/P2Build.bnf (SetType): Pass set token pos to
BuildSetType.
(PointerType): Pass pointer token pos to BuildPointerType.
* gm2-compiler/P2SymBuild.def (BuildPointerType): Add parameter
pointerpos.
(BuildSetType): Add parameter setpos.
* gm2-compiler/P2SymBuild.mod (BuildPointerType): Add parameter
pointerpos.  Build combined token and use it when creating a
pointer type.
(BuildSetType): Add parameter setpos.  Build combined token and
use it when creating a set type.
* gm2-compiler/SymbolTable.mod (DebugUnknownToken): New constant.
(CheckTok): New procedure function.
(MakeProcedure): Call CheckTok.
(MakeRecord): Ditto.
(MakeVarient): Ditto.
(MakeEnumeration): Ditto.
(MakeHiddenType): Ditto.
(MakeConstant): Ditto.
(MakeConstStringCnul): Ditto.
(MakeSubrange): Ditto.
(MakeTemporary): Ditto.
(MakeVariableForParam): Ditto.
(MakeParameterHeapVar): Ditto.
(MakePointer): Ditto.
(MakeSet): Ditto.
(MakeUnbounded): Ditto.
(MakeProcType): Ditto.

Signed-off-by: Gaius Mulley 

[Bug middle-end/96564] [11/12/13/14 Regression] New maybe use of uninitialized variable warning since r11-959

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #15 from Andrew Macleod  ---
(In reply to Richard Biener from comment #13)
> (In reply to Jeffrey A. Law from comment #12)
> > So I think we could solve this with a bit of help from the alias oracle.  We
> > have  the routine ptrs_compare_unequal, but points-to-null is going to get
> > in the way.
> > 
> > I think VRP and DOM have enough information to rule out NULL for both
> > objects in question.  So if we could query the points-to information,
> > ignoring NULL then we could likely solve this particular bug.
> > 
> > Essentially VRP or DOM would prove NULL isn't in the set of possible values
> > at the comparison point.  Then we query the alias information ignoring NULL.
> > Voila we compute a static result for the comparison of the two pointers and
> > the problematical block becomes unreachable and the bogus warning goes away.
> > 
> > Richi, any thoughts in viability of such an API?
> 
> We now treat pt.null conservatively and track non-null-ness derived from
> range-info in it.  That means when VRP/DOM can prove a pointer is always
> not NULL they can do set_ptr_nonnull (p) on it.
> 
> This means the
> 
>   /* ???  We'd like to handle ptr1 != NULL and ptr1 != ptr2
>  but those require pt.null to be conservatively correct.  */
> 
> is no longer true and we could finally implement it, like with
> 
> diff --git a/gcc/tree-ssa-alias.cc b/gcc/tree-ssa-alias.cc
> index e7c1c1aa624..5b6d9e0aa6a 100644
> --- a/gcc/tree-ssa-alias.cc
> +++ b/gcc/tree-ssa-alias.cc
> @@ -479,9 +479,25 @@ ptrs_compare_unequal (tree ptr1, tree ptr2)
> }
>return !pt_solution_includes (>pt, obj1);
>  }
> -
> -  /* ???  We'd like to handle ptr1 != NULL and ptr1 != ptr2
> - but those require pt.null to be conservatively correct.  */
> +  else if (TREE_CODE (ptr1) == SSA_NAME)
> +{
> +  struct ptr_info_def *pi1 = SSA_NAME_PTR_INFO (ptr1);
> +  if (!pi1
> + || pi1->pt.vars_contains_restrict
> + || pi1->pt.vars_contains_interposable)
> +   return false;
> +  if (integer_zerop (ptr2) && !pi1->pt.null)
> +   return true;
> +  if (TREE_CODE (ptr2) == SSA_NAME)
> +   {
> + struct ptr_info_def *pi2 = SSA_NAME_PTR_INFO (ptr2);
> + if (!pi2
> + || pi2->pt.vars_contains_restrict
> + || pi2->pt.vars_contains_interposable)
> + if (!pi1->pt.null || !pi2->pt.null)
> +   return !pt_solutions_intersect (>pt, >pt);
> +   }
> +}
>  
>return false;
>  }
> 
> 
> but the testcase shows the non-null-ness is only conditional which means
> we'd have to use a range query above which necessarily falls back to
> the global ranges given we don't have any context available here.  The
> old EVRP adjusted global ranges during the walk but this is no longer done.
> 
You mean it lied?  because x_1 is not NULL until after _8 = *x_1(D); executes. 
It can still be NULL on that stmt can it not?   Did it reset the global value
afterwards?

Contextually ranger knows both are non-null at EVRP time:
a.0_27 : [irange] int[0:D.] * [1, +INF]
2->3  (T) x_1(D) : [irange] int * [1, +INF]
2->3  (T) a.0_27 :  [irange] int[0:D.] * [1, +INF]
2->4  (F) x_1(D) : [irange] int * [1, +INF]
2->4  (F) a.0_27 :  [irange] int[0:D.] * [1, +INF]

So we know x_1 is non-NULL after the de-reference for the rest of the block
(and function).  It also sets a.0_27 globally to be [1, +INF].


> Note it's enough that one pointer is nonnull, so for your idea the
> API could be extended with a bool one_ptr_nonnull parameter.

ranger currently sets a.0 globally to be non-null in EVRP.

[Bug c++/111284] [11/12/13/14 Regression] Some passing-by-value parameters are mishandled since GCC 9, affecting libstdc++'s constexpr std::string

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

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

--- Comment #9 from Patrick Palka  ---
(In reply to Jakub Jelinek from comment #8)
> Created attachment 57648 [details]
> gcc14-pr111284.patch
> 
> So, I've tried to fix this by constexpr evaluating the arguments passed to
> PARM_DECLs with TREE_ADDRESSABLE types in the caller as lvalues rather than
> rvaluea and later, if we try to evaluate the PARM_DECL in the callee as lval,
> lookup the value and use that, if it is rval constexpr evaluate again as
> rvalue.
> There is a complication for qualified type, say if the argument is const in
> the callee and caller is passing reference to non-const, adjust_temp_type
> can't handle that when it isn't a rvalue.
Interesting, hopefully this fixes the std::string testcases in PR111258 and
related PRs?

And perhaps the following augmented testcase from this PR with a constexpr dtor
that checks valid():

void non_constant();

struct self_locator {
self_locator() = default;
constexpr self_locator(const self_locator&) noexcept : this_{this} {}
constexpr self_locator& operator=(const self_locator&) noexcept { return
*this; }

constexpr bool valid() const noexcept { return this_ == this; }
constexpr ~self_locator() { if (!valid()) non_constant(); }

self_locator *this_ = this;
};

constexpr bool demonstrator(self_locator x) noexcept
{
return x.valid();
}

static_assert(demonstrator(self_locator{}), "");
static_assert([](self_locator x){ return x.valid(); }(self_locator{}), "");

[Bug testsuite/96109] [11 Regression] gcc.dg/vect/slp-47.c etc. FAIL

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

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

--- Comment #18 from Rainer Orth  ---
SPARC testsuite failures fixed for GCC 14.0.1.

[Bug tree-optimization/113557] gcc.dg/vect/vect-multi-peel-gaps.c FAILs

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

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-March/6
   ||47558.html
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org

--- Comment #4 from Rainer Orth  ---
Fixed for GCC 14.0.1.

[Bug tree-optimization/114071] gcc.dg/vect/pr37027.c etc. FAIL

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

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

Rainer Orth  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-March/6
   ||47558.html
   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org
   Target Milestone|--- |14.0

--- Comment #3 from Rainer Orth  ---
Fixed for GCC 14.0.1.

[Bug tree-optimization/98238] gcc.dg/vect/vect-cost-model-1.c etc. FAIL

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

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

Rainer Orth  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |ro at gcc dot gnu.org
   Target Milestone|11.5|14.0
 Resolution|--- |FIXED
 Status|UNCONFIRMED |RESOLVED
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-March/6
   ||47559.html

--- Comment #8 from Rainer Orth  ---
Fixed for GCC 14.0.1.

[Bug tree-optimization/98238] gcc.dg/vect/vect-cost-model-1.c etc. FAIL

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Rainer Orth :

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

commit r14-9428-g4e1fcf44bdc582e71408175d75e025f5be8b0e55
Author: Rainer Orth 
Date:   Mon Mar 11 15:46:30 2024 +0100

testsuite: vect: Require vect_hw_misalign in
gcc.dg/vect/vect-cost-model-1.c etc. [PR98238]

Several gcc.dg/vect/vect-cost-model-?.c tests FAIL on 32 and 64-bit
Solaris/SPARC:

FAIL: gcc.dg/vect/vect-cost-model-1.c -flto -ffat-lto-objects
scan-tree-dump vect "LOOP VECTORIZED"
FAIL: gcc.dg/vect/vect-cost-model-1.c scan-tree-dump vect "LOOP VECTORIZED"
FAIL: gcc.dg/vect/vect-cost-model-3.c -flto -ffat-lto-objects
scan-tree-dump vect "LOOP VECTORIZED"
FAIL: gcc.dg/vect/vect-cost-model-3.c scan-tree-dump vect "LOOP VECTORIZED"
FAIL: gcc.dg/vect/vect-cost-model-5.c -flto -ffat-lto-objects
scan-tree-dump vect "LOOP VECTORIZED"
FAIL: gcc.dg/vect/vect-cost-model-5.c scan-tree-dump vect "LOOP VECTORIZED"

The dumps show

   
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-cost-model-1.c:7:30:
note: ==> examining statement: _3 = *_2;
   
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-cost-model-1.c:7:30:
missed: unsupported unaligned access
   
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/vect-cost-model-1.c:8:6:
missed: not vectorized: relevant stmt not supported: _3 = *_2;

so I think the tests need to require vect_hw_misalign.  This is what
this patch does.

Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11.

2024-02-22  Rainer Orth  

gcc/testsuite:
PR tree-optimization/98238
* gcc.dg/vect/vect-cost-model-1.c (scan-tree-dump): Also require
vect_hw_misalign.
* gcc.dg/vect/vect-cost-model-3.c: Likewise.
* gcc.dg/vect/vect-cost-model-5.c: Likewise.

[Bug testsuite/96109] [11 Regression] gcc.dg/vect/slp-47.c etc. FAIL

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

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

--- Comment #17 from GCC Commits  ---
The master branch has been updated by Rainer Orth :

https://gcc.gnu.org/g:96b63fa255e343bb9b3e7f77302213a91ce96293

commit r14-9427-g96b63fa255e343bb9b3e7f77302213a91ce96293
Author: Rainer Orth 
Date:   Mon Mar 11 15:45:17 2024 +0100

testsuite: vect: Require vect_perm in several tests [PR114071, PR113557,
PR96109]

Several vectorization tests FAIL on 32 and 64-bit Solaris/SPARC:

FAIL: gcc.dg/vect/pr37027.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/pr37027.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/pr37027.c scan-tree-dump-times vect "vectorized 1 loops"
1
FAIL: gcc.dg/vect/pr37027.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 1
FAIL: gcc.dg/vect/pr67790.c -flto -ffat-lto-objects scan-tree-dump vect
"vectorizing stmts using SLP"
FAIL: gcc.dg/vect/pr67790.c scan-tree-dump vect "vectorizing stmts using
SLP"
FAIL: gcc.dg/vect/slp-47.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorizing stmts using SLP" 2
FAIL: gcc.dg/vect/slp-47.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 2
FAIL: gcc.dg/vect/slp-48.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorizing stmts using SLP" 2
FAIL: gcc.dg/vect/slp-48.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 2
FAIL: gcc.dg/vect/slp-reduc-1.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-reduc-1.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-1.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-reduc-1.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-2.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-reduc-2.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-2.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-reduc-2.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-7.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-reduc-7.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-7.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-reduc-7.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-8.c -flto -ffat-lto-objects scan-tree-dump vect
"vectorized 1 loops"
FAIL: gcc.dg/vect/slp-reduc-8.c scan-tree-dump vect "vectorized 1 loops"
FAIL: gcc.dg/vect/vect-multi-peel-gaps.c -flto -ffat-lto-objects
scan-tree-dump vect "LOOP VECTORIZED"
FAIL: gcc.dg/vect/vect-multi-peel-gaps.c scan-tree-dump vect "LOOP
VECTORIZED"

The dumps show variations of

/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
note: ==> examining statement: _4 = a[i_19].f2;
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
missed: unsupported vect permute { 1 0 3 2 5 4 }
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
missed: unsupported load permutation
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:27:17:
missed: not vectorized: relevant stmt not supported: _4 = a[i_19].f2;

so I think the tests should require vect_perm.  This is what this patch
does

Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11.

2024-02-22  Rainer Orth  

gcc/testsuite:
PR tree-optimization/114071
* gcc.dg/vect/pr37027.c: Require vect_perm.
* gcc.dg/vect/pr67790.c: Likewise.
* gcc.dg/vect/slp-reduc-1.c: Likewise.
* gcc.dg/vect/slp-reduc-2.c: Likewise.
* gcc.dg/vect/slp-reduc-7.c: Likewise.
* gcc.dg/vect/slp-reduc-8.c: Likewise.

PR tree-optimization/113557
* gcc.dg/vect/vect-multi-peel-gaps.c (scan-tree-dump): Also
require vect_perm.

PR testsuite/96109
* gcc.dg/vect/slp-47.c: Require vect_perm.
* gcc.dg/vect/slp-48.c: Likewise.

[Bug tree-optimization/114071] gcc.dg/vect/pr37027.c etc. FAIL

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

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Rainer Orth :

https://gcc.gnu.org/g:96b63fa255e343bb9b3e7f77302213a91ce96293

commit r14-9427-g96b63fa255e343bb9b3e7f77302213a91ce96293
Author: Rainer Orth 
Date:   Mon Mar 11 15:45:17 2024 +0100

testsuite: vect: Require vect_perm in several tests [PR114071, PR113557,
PR96109]

Several vectorization tests FAIL on 32 and 64-bit Solaris/SPARC:

FAIL: gcc.dg/vect/pr37027.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/pr37027.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/pr37027.c scan-tree-dump-times vect "vectorized 1 loops"
1
FAIL: gcc.dg/vect/pr37027.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 1
FAIL: gcc.dg/vect/pr67790.c -flto -ffat-lto-objects scan-tree-dump vect
"vectorizing stmts using SLP"
FAIL: gcc.dg/vect/pr67790.c scan-tree-dump vect "vectorizing stmts using
SLP"
FAIL: gcc.dg/vect/slp-47.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorizing stmts using SLP" 2
FAIL: gcc.dg/vect/slp-47.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 2
FAIL: gcc.dg/vect/slp-48.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorizing stmts using SLP" 2
FAIL: gcc.dg/vect/slp-48.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 2
FAIL: gcc.dg/vect/slp-reduc-1.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-reduc-1.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-1.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-reduc-1.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-2.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-reduc-2.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-2.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-reduc-2.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-7.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-reduc-7.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-7.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-reduc-7.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-8.c -flto -ffat-lto-objects scan-tree-dump vect
"vectorized 1 loops"
FAIL: gcc.dg/vect/slp-reduc-8.c scan-tree-dump vect "vectorized 1 loops"
FAIL: gcc.dg/vect/vect-multi-peel-gaps.c -flto -ffat-lto-objects
scan-tree-dump vect "LOOP VECTORIZED"
FAIL: gcc.dg/vect/vect-multi-peel-gaps.c scan-tree-dump vect "LOOP
VECTORIZED"

The dumps show variations of

/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
note: ==> examining statement: _4 = a[i_19].f2;
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
missed: unsupported vect permute { 1 0 3 2 5 4 }
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
missed: unsupported load permutation
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:27:17:
missed: not vectorized: relevant stmt not supported: _4 = a[i_19].f2;

so I think the tests should require vect_perm.  This is what this patch
does

Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11.

2024-02-22  Rainer Orth  

gcc/testsuite:
PR tree-optimization/114071
* gcc.dg/vect/pr37027.c: Require vect_perm.
* gcc.dg/vect/pr67790.c: Likewise.
* gcc.dg/vect/slp-reduc-1.c: Likewise.
* gcc.dg/vect/slp-reduc-2.c: Likewise.
* gcc.dg/vect/slp-reduc-7.c: Likewise.
* gcc.dg/vect/slp-reduc-8.c: Likewise.

PR tree-optimization/113557
* gcc.dg/vect/vect-multi-peel-gaps.c (scan-tree-dump): Also
require vect_perm.

PR testsuite/96109
* gcc.dg/vect/slp-47.c: Require vect_perm.
* gcc.dg/vect/slp-48.c: Likewise.

[Bug tree-optimization/113557] gcc.dg/vect/vect-multi-peel-gaps.c FAILs

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

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

--- Comment #3 from GCC Commits  ---
The master branch has been updated by Rainer Orth :

https://gcc.gnu.org/g:96b63fa255e343bb9b3e7f77302213a91ce96293

commit r14-9427-g96b63fa255e343bb9b3e7f77302213a91ce96293
Author: Rainer Orth 
Date:   Mon Mar 11 15:45:17 2024 +0100

testsuite: vect: Require vect_perm in several tests [PR114071, PR113557,
PR96109]

Several vectorization tests FAIL on 32 and 64-bit Solaris/SPARC:

FAIL: gcc.dg/vect/pr37027.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/pr37027.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/pr37027.c scan-tree-dump-times vect "vectorized 1 loops"
1
FAIL: gcc.dg/vect/pr37027.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 1
FAIL: gcc.dg/vect/pr67790.c -flto -ffat-lto-objects scan-tree-dump vect
"vectorizing stmts using SLP"
FAIL: gcc.dg/vect/pr67790.c scan-tree-dump vect "vectorizing stmts using
SLP"
FAIL: gcc.dg/vect/slp-47.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorizing stmts using SLP" 2
FAIL: gcc.dg/vect/slp-47.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 2
FAIL: gcc.dg/vect/slp-48.c -flto -ffat-lto-objects scan-tree-dump-times
vect "vectorizing stmts using SLP" 2
FAIL: gcc.dg/vect/slp-48.c scan-tree-dump-times vect "vectorizing stmts
using SLP" 2
FAIL: gcc.dg/vect/slp-reduc-1.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-reduc-1.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-1.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-reduc-1.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-2.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-reduc-2.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-2.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-reduc-2.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-7.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorized 1 loops" 1
FAIL: gcc.dg/vect/slp-reduc-7.c -flto -ffat-lto-objects
scan-tree-dump-times vect "vectorizing stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-7.c scan-tree-dump-times vect "vectorized 1
loops" 1
FAIL: gcc.dg/vect/slp-reduc-7.c scan-tree-dump-times vect "vectorizing
stmts using SLP" 1
FAIL: gcc.dg/vect/slp-reduc-8.c -flto -ffat-lto-objects scan-tree-dump vect
"vectorized 1 loops"
FAIL: gcc.dg/vect/slp-reduc-8.c scan-tree-dump vect "vectorized 1 loops"
FAIL: gcc.dg/vect/vect-multi-peel-gaps.c -flto -ffat-lto-objects
scan-tree-dump vect "LOOP VECTORIZED"
FAIL: gcc.dg/vect/vect-multi-peel-gaps.c scan-tree-dump vect "LOOP
VECTORIZED"

The dumps show variations of

/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
note: ==> examining statement: _4 = a[i_19].f2;
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
missed: unsupported vect permute { 1 0 3 2 5 4 }
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:24:17:
missed: unsupported load permutation
/vol/gcc/src/hg/master/local/gcc/testsuite/gcc.dg/vect/pr37027.c:27:17:
missed: not vectorized: relevant stmt not supported: _4 = a[i_19].f2;

so I think the tests should require vect_perm.  This is what this patch
does

Tested on sparc-sun-solaris2.11 and i386-pc-solaris2.11.

2024-02-22  Rainer Orth  

gcc/testsuite:
PR tree-optimization/114071
* gcc.dg/vect/pr37027.c: Require vect_perm.
* gcc.dg/vect/pr67790.c: Likewise.
* gcc.dg/vect/slp-reduc-1.c: Likewise.
* gcc.dg/vect/slp-reduc-2.c: Likewise.
* gcc.dg/vect/slp-reduc-7.c: Likewise.
* gcc.dg/vect/slp-reduc-8.c: Likewise.

PR tree-optimization/113557
* gcc.dg/vect/vect-multi-peel-gaps.c (scan-tree-dump): Also
require vect_perm.

PR testsuite/96109
* gcc.dg/vect/slp-47.c: Require vect_perm.
* gcc.dg/vect/slp-48.c: Likewise.

[Bug c++/114303] [11/12/13/14 Regression] ICE with constexpr if and accessing captures across nested generic lambdas

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

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

Patrick Palka  changed:

   What|Removed |Added

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

--- Comment #3 from Patrick Palka  ---
Started with r13-6452 (which has been backported to 11/12).