date:20241010

[Bug libstdc++/117085] New: chrono formatting: %c does not honor locale after expansion

2024-10-10 Thread xu2k3l4 at outlook dot com via Gcc-bugs

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

Bug ID: 117085
   Summary: chrono formatting: %c does not honor locale after
expansion
   Product: gcc
   Version: 14.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: xu2k3l4 at outlook dot com
  Target Milestone: ---

## issue description

how to reproduce:

```cpp
#include 
#include 
#include 
constexpr const char *localename = "zh_CN.UTF-8";
int main()
{
std::locale locale(localename);
std::locale::global(locale);
auto timepoint = std::chrono::system_clock::from_time_t(0);
std::println("{:L%c}", timepoint);
}
```

output (x86_64-pc-linux-gnu gcc 14.2.0), note that "Thursday" is not localized:

```plaintext
1970年01月01日 Thursday 00时00分00秒
```

expected output, i.e. `TZ= LANG=zh_CN.UTF-8 date +'%c' --date='@0'` produces:
```plaintext
1970年01月01日 星期四 00时00分00秒
```

(same issue exists for many other locales, like fr_FR outputting "Thu 01 Jan
1970 00:00:00" instead of expected "jeu. 01 janv. 1970 00:00:00")

## analysis

`__formatter_chrono::_M_c` passes local time format ("%Y年%m月%d日 %A %H时%M分%S秒"
for zh_CN) to sub-`vformat_to`, but without "L" format specifier the
sub-`vformat_to` will not format the "%A" with requested locale.

code link:

`__formatter_chrono::_M_c` construction of format string.
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/include/bits/chrono_io.h;h=652e88ffe3abbfa78b769c70c3efbae9207a9804;hb=HEAD#l904

## possible solution

in `__formatter_chrono::_M_c`, `__fmt.insert` 'L' if needed.

[Bug tree-optimization/117043] missed vectorization opportunity: data[i] = data[i - a[i]] + 1; (a[i]=0)

2024-10-10 Thread 652023330028 at smail dot nju.edu.cn via Gcc-bugs

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

--- Comment #2 from Yi <652023330028 at smail dot nju.edu.cn> ---
When the size of the array is 20:
https://godbolt.org/z/EKfrWYTGb

int data[20];
void f()
{
int a[20];
for(int i = 0; i < 20; i++){
a[i] = 0;
}
for(int i = 0; i < 20; i++){
data[i] = data[i - a[i]] + 1;
}
}

clang works as expected:
f():
movdqa  xmm0, xmmword ptr [rip + data]
pcmpeqd xmm1, xmm1
psubd   xmm0, xmm1
movdqa  xmmword ptr [rip + data], xmm0
movdqa  xmm0, xmmword ptr [rip + data+16]
psubd   xmm0, xmm1
movdqa  xmmword ptr [rip + data+16], xmm0
movdqa  xmm0, xmmword ptr [rip + data+32]
psubd   xmm0, xmm1
movdqa  xmmword ptr [rip + data+32], xmm0
movdqa  xmm0, xmmword ptr [rip + data+48]
psubd   xmm0, xmm1
movdqa  xmmword ptr [rip + data+48], xmm0
movdqa  xmm0, xmmword ptr [rip + data+64]
psubd   xmm0, xmm1
movdqa  xmmword ptr [rip + data+64], xmm0
ret

but gcc:
f():
xor eax, eax
.L2:
movsx   rdx, eax
mov edx, DWORD PTR data[0+rdx*4]
add edx, 1
mov DWORD PTR data[0+rax*4], edx
add rax, 1
cmp rax, 20
jne .L2
ret

:8:22: missed: couldn't vectorize loop
:9:32: missed: possible alias involving gather/scatter between data[_2]
and data[i_20]
:6:14: missed: statement clobbers memory: __builtin_memset (&a, 0, 80);
ASM generation compiler returned: 0
:8:22: missed: couldn't vectorize loop
:9:32: missed: possible alias involving gather/scatter between data[_2]
and data[i_20]
:6:14: missed: statement clobbers memory: __builtin_memset (&a, 0, 80);

[Bug ada/116945] Valgrind reports uninitialized memory use in sem_ch12.adb (sem_ch12__instance_context__save_and_reset)

2024-10-10 Thread pjfloyd at wanadoo dot fr via Gcc-bugs

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

Paul Floyd  changed:

   What|Removed |Added

 CC||pjfloyd at wanadoo dot fr

--- Comment #11 from Paul Floyd  ---
I’m a bit surprised that this is allowed.

In C++ (and C) reading uninitialized data is Undefined Behaviour. Which means
you are in the Twilight Zone with nasal demons and all that. The compiler would
be perfectly justified in optimizing away the check.

[Bug target/80881] Implement Windows native TLS

2024-10-10 Thread ubizjak at gmail dot com via Gcc-bugs

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

--- Comment #48 from Uroš Bizjak  ---
Comment on attachment 59315
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59315
Candidate patch

>+static rtx
>+ix86_tls_index (void)
>+{
>+  if (!ix86_tls_index_symbol)
>+ix86_tls_index_symbol = gen_rtx_SYMBOL_REF (Pmode, "_tls_index");
>+
>+  if (flag_pic)
>+{
>+  rtx unspec = gen_rtx_UNSPEC (Pmode, gen_rtvec (1, 
>ix86_tls_index_symbol),
>+ UNSPEC_PCREL);
>+  return gen_rtx_CONST (Pmode, unspec);

Please note that RIP-relative addresses are one byte shorter than absolute
addresses and are interchangeable on x86_64 Linux. If this is also true on
Windows (UNSPEC_PCREL was introduced for PE linkers) then the above should also
be emitted without flag_pic. Looking through the i386.cc, there are some
(flag_pic) asserts w/ UNSPEC_PCREL), but perhaps these can be relaxed to also
support RIP-relative addresses without -fPIC.

[Bug target/117069] [15 Regression] gcc.target/i386/apx-ndd-tls-1b.c

2024-10-10 Thread hjl.tools at gmail dot com via Gcc-bugs

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

H.J. Lu  changed:

   What|Removed |Added

Summary|[14/15 Regression]  |[15 Regression]
   |gcc.target/i386/apx-ndd-tls |gcc.target/i386/apx-ndd-tls
   |-1b.c   |-1b.c
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-10-10

--- Comment #1 from H.J. Lu  ---
It is only GCC 15 regression.

[Bug c++/113798] [C++26] P2662R3 - Pack indexing

2024-10-10 Thread mpolacek at gcc dot gnu.org via Gcc-bugs

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #4 from Marek Polacek  ---
I have a patch that, so far, compiles this correctly:

```
// P2662R3 - Pack Indexing
// PR c++/113798
// { dg-do compile { target c++17 } }
// { dg-options "" }

template
using Type = Ts...[I]; // { dg-warning "pack indexing only available with" "" {
target c++23_down } }

template
constexpr auto Var = Ts...[I]; // { dg-warning "pack indexing only available
with" "" { target c++23_down } }

template 
decltype(Ts...[I])  // { dg-warning "pack indexing only available with" "" {
target c++23_down } }
foo ()
{
  return Ts...[I]; // { dg-warning "pack indexing only available with" "" {
target c++23_down } }
}

void
g ()
{
  using U = Type<1, char, int, float>;
  using U = int;

  constexpr auto V = Var<2, 0, 1, 42>;
  static_assert (V == 42);

  int r = foo<2, 0, 1, 42>();
}
```

[Bug fortran/117070] Procedure target error with parameter structure constructor

2024-10-10 Thread ivan.pribec at gmail dot com via Gcc-bugs

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

--- Comment #1 from Ivan Pribec  ---
This is supposed to work already with the F2008 standard:

> nagfor -f2008 dispatch_test.f90 
NAG Fortran Compiler Release 7.2(Shin-Urayasu) Build 7203
Evaluation trial version of NAG Fortran Compiler Release 7.2(Shin-Urayasu)
Build 7203
[NAG Fortran Compiler normal termination]
> ./a.out
 PASS

[Bug target/117079] [15 Regression] FAIL: gcc.target/i386/pr105493.c since r15-2820-gab18785840d7b8

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/659911.html

[Bug target/117079] [15 Regression] FAIL: gcc.target/i386/pr105493.c since r15-2820-gab18785840d7b8

2024-10-10 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

 CC||cmuellner at gcc dot gnu.org,
   ||ptomsich at gcc dot gnu.org,
   ||tsamismanolis at gmail dot com
Summary|[15 Regression] FAIL:   |[15 Regression] FAIL:
   |gcc.target/i386/pr105493.c  |gcc.target/i386/pr105493.c
   ||since
   ||r15-2820-gab18785840d7b8

--- Comment #2 from Sam James  ---
https://inbox.sourceware.org/gcc-patches/202408081706.478h6my51198...@shliclel4214.sh.intel.com/

[Bug tree-optimization/117080] [15 Regression] FAIL: gcc.target/i386/pr88531-2b.c and FAIL: gcc.target/i386/pr88531-2c.c

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|target  |tree-optimization
 Blocks||53947

--- Comment #2 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662523.html


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug target/117081] [15 Regression] FAIL: gcc.target/i386/pr91384.c since r15-1619-g3b9b8d6cfdf593

2024-10-10 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

 CC||jskumari at gcc dot gnu.org
Summary|[15 Regression] FAIL:   |[15 Regression] FAIL:
   |gcc.target/i386/pr91384.c   |gcc.target/i386/pr91384.c
   ||since
   ||r15-1619-g3b9b8d6cfdf593

--- Comment #3 from Sam James  ---
https://gcc.gnu.org/pipermail/gcc-regression/2024-June/080148.html

[Bug target/117081] [15 Regression] FAIL: gcc.target/i386/pr91384.c since r15-1619-g3b9b8d6cfdf593

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Sam James from comment #2)
> I mentioned it in PR115673 which may help with bisection range.

https://gcc.gnu.org/pipermail/gcc-patches/2024-June/655721.html

[Bug c/117083] New: ICE: in get_expr_operands, at tree-ssa-operands.cc:939

2024-10-10 Thread iamanonymous.cs at gmail dot com via Gcc-bugs

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

Bug ID: 117083
   Summary: ICE: in get_expr_operands, at tree-ssa-operands.cc:939
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: iamanonymous.cs at gmail dot com
  Target Milestone: ---
Target: x86_64

***
The compiler produces an internal error during
operands_scanner::get_expr_operands when compiling the provided code with the
specified options. 
The issue can also be reproduced on Compiler Explorer.

***
OS and Platform:
# uname -a
Linux ubuntu 4.15.0-213-generic #224-Ubuntu SMP Mon Jun 19 13:30:12 UTC 2023
x86_64 x86_64 x86_64 GNU/Linux
***
# gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/root/gdbtest/gcc/gcc-241009/libexec/gcc/x86_64-pc-linux-gnu/15.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc/configure --prefix=/root/gdbtest/gcc/gcc-241009
--enable-languages=c,c++ --disable-multilib --disable-bootstrap
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241009 (experimental) (GCC) 
***
Program:
# cat bugreport_0_1.c

void foo (unsigned *);
void bar (const unsigned char *block)
{
  unsigned buf[4];
  __builtin_memcpy (buf +  0, block +  0, 4);
  __builtin_memcpy (buf +  1, block +  4, 4);
  __builtin_memcpy (buf +  2, block +  8, 4);
  __builtin_memcpy (buf +  3, block + 12, 4);
  foo (buf);
}

void __GIMPLE (ssa,guessed_local(1073741824))
bar (const unsigned char * block)
{
  vector(4) unsigned int vect__3.5;
  unsigned int buf[4];

  __BB(2,guessed_local(1073741824)):
  vect__3.5_14 = __MEM  ((char *
{ref-all})block_2(D));
  __MEM  ((char * {ref-all})&buf) = vect__3.5_14;
  foo (&buf);
  buf ={v} _Literal (unsigned int[4]) {CLOBBER(eol)};
  return;
}

***
Command Lines:
# gcc bugreport_0_1.c  -O3 -fno-omit-frame-pointer -fstrict-overflow
-frename-registers -fno-delete-null-pointer-checks
bugreport_0_1.c:12:6: error: ‘__GIMPLE’ only valid with ‘-fgimple’
   12 | void __GIMPLE (ssa,guessed_local(1073741824))
  |  ^~~~
bugreport_0_1.c:13:1: error: redefinition of ‘bar’
   13 | bar (const unsigned char * block)
  | ^~~
bugreport_0_1.c:2:6: note: previous definition of ‘bar’ with type ‘void(const
unsigned char *)’
2 | void bar (const unsigned char *block)
  |  ^~~
bugreport_0_1.c: In function ‘bar’:
bugreport_0_1.c:15:3: error: implicit declaration of function ‘vector’
[-Wimplicit-function-declaration]
   15 |   vector(4) unsigned int vect__3.5;
  |   ^~
bugreport_0_1.c:15:13: error: expected ‘=’ before ‘unsigned’
   15 |   vector(4) unsigned int vect__3.5;
  | ^~~~
bugreport_0_1.c:16:3: error: expected expression before ‘unsigned’
   16 |   unsigned int buf[4];
  |   ^~~~
bugreport_0_1.c:19:10: error: invalid suffix "_14" on floating constant
   19 |   vect__3.5_14 = __MEM  ((char *
{ref-all})block_2(D));
  |  ^
bugreport_0_1.c:19:10: error: base variable or SSA name undeclared before
numeric constant
bugreport_0_1.c:20:10: error: expected specifier-qualifier-list before ‘vector’
   20 |   __MEM  ((char * {ref-all})&buf) =
vect__3.5_14;
  |  ^~
bugreport_0_1.c:20:42: error: expected ‘)’ before ‘{’ token
   20 |   __MEM  ((char * {ref-all})&buf) =
vect__3.5_14;
  |  ^~
  |  )
bugreport_0_1.c:20:54: error: ‘buf’ undeclared (first use in this function)
   20 |   __MEM  ((char * {ref-all})&buf) =
vect__3.5_14;
  |  ^~~
bugreport_0_1.c:20:54: note: each undeclared identifier is reported only once
for each function it appears in
bugreport_0_1.c:20:68: error: invalid suffix "_14" on floating constant
   20 |   __MEM  ((char * {ref-all})&buf) =
vect__3.5_14;
  |   
^
bugreport_0_1.c:20:68: error: base variable or SSA name undeclared before
numeric constant
bugreport_0_1.c:22:8: error: expected expression before ‘{’ token
   22 |   buf ={v} _Literal (unsigned int[4]) {CLOBBER(eol)};
  |^
unhandled expression in get_expr_operands():
 

bugreport_0_1.c:24:1: internal compiler error: in get_expr_operands, at
tree-ssa-operands.cc:939
   24 | }
  | ^
0x260066e internal_error(char const*, ...)
../../gcc/gcc/diagnostic-global-context.cc:517
0x9dc7a1 fancy_abort(char const*, int, char cons

[Bug tree-optimization/117086] New: [15 Regression] ICE in tree check: expected vector_type, have boolean_type in TYPE_VECTOR_SUBPARTS, at tree.h:4255

2024-10-10 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 117086
   Summary: [15 Regression] ICE in tree check: expected
vector_type, have boolean_type in
TYPE_VECTOR_SUBPARTS, at tree.h:4255
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

> ./cc1plus -quiet lra-constraints.ii -O2 -march=znver5 -o /dev/null
during GIMPLE pass: forwprop
../../src/gcc/gcc/lra-constraints.cc: In function ‘bool split_reg(bool, int,
rtx_insn*, rtx, rtx_insn*)’:
../../src/gcc/gcc/lra-constraints.cc:6111:1: internal compiler error: tree
check: expected vector_type, have boolean_type in TYPE_VECTOR_SUBPARTS, at
tree.h:4255
 6111 | split_reg (bool before_p, int original_regno, rtx_insn *insn,
  | ^
0x3a92dab internal_error(char const*, ...)
../../src/gcc/gcc/diagnostic-global-context.cc:517
0x20532ec tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../src/gcc/gcc/tree.cc:9003
0xe61611 tree_check(tree_node const*, char const*, int, char const*, tree_code)
../../src/gcc/gcc/tree.h:3921
0xe9aef1 TYPE_VECTOR_SUBPARTS(tree_node const*)
../../src/gcc/gcc/tree.h:4255
0x1c6f538 verify_gimple_assign_ternary
../../src/gcc/gcc/tree-cfg.cc:4380
0x1c71459 verify_gimple_assign
../../src/gcc/gcc/tree-cfg.cc:4866


forwprop creates a bogus VEC_COND_EXPR:

(gdb) p debug_gimple_stmt (stmt)
_513 = VEC_COND_EXPR ;
$1 = void
(gdb) p rhs1_type
$2 = 
(gdb) p lhs_type
$3 = 
(gdb) p gimple_assign_rhs2 (stmt)
$4 = (tree_node *) 0x768205a0
(gdb) p debug_tree ($4)
  constant
0>

[Bug tree-optimization/117086] [15 Regression] ICE in tree check: expected vector_type, have boolean_type in TYPE_VECTOR_SUBPARTS, at tree.h:4255

2024-10-10 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Richard Biener  ---
Created attachment 59317
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59317&action=edit
preprocessed source

[Bug tree-optimization/117086] [15 Regression] ICE in tree check: expected vector_type, have boolean_type in TYPE_VECTOR_SUBPARTS, at tree.h:4255

2024-10-10 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Keywords||needs-reduction

--- Comment #2 from Richard Biener  ---
Applying pattern match.pd:5713, gimple-match-9.cc:15362
Applying pattern match.pd:10489, gimple-match-9.cc:3970
gimple_simplified to _513 = VEC_COND_EXPR ;
if (_513 != 0)

so it looks like

 (simplify
  (op (vec_cond:s @0 @1 @2) @3)
  (if (TREE_CODE_CLASS (op) != tcc_comparison
   || types_match (type, TREE_TYPE (@1))
   || expand_vec_cond_expr_p (type, TREE_TYPE (@0), ERROR_MARK)
   || (optimize_vectors_before_lowering_p ()
   && !expand_vec_cond_expr_p (TREE_TYPE (@1),
   TREE_TYPE (@0), ERROR_MARK)))
   (vec_cond @0 (op! @1 @3) (op! @2 @3

goes wrong in the sense that expand_vec_cond_expr_p succeeds for scalar
'type'!?

[Bug ada/116945] Valgrind reports uninitialized memory use in sem_ch12.adb (sem_ch12__instance_context__save_and_reset)

2024-10-10 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs

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

--- Comment #12 from Eric Botcazou  ---
> In C++ (and C) reading uninitialized data is Undefined Behaviour. Which
> means you are in the Twilight Zone with nasal demons and all that. The
> compiler would be perfectly justified in optimizing away the check.

Unlike the C and C++ standards, the Ada standard is freely available at:
  http://www.ada-auth.org/standards/22rm/html/RM-TTL.html
and the 'Valid attribute is specified there:
  http://www.ada-auth.org/standards/22rm/html/RM-13-9-2.html

[Bug tree-optimization/117086] [15 Regression] ICE in tree check: expected vector_type, have boolean_type in TYPE_VECTOR_SUBPARTS, at tree.h:4255

2024-10-10 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Richard Biener  ---
  vect__ifc__9.3372_199 = VEC_COND_EXPR ;
  _327 = .REDUC_IOR (vect__ifc__9.3372_199);
  if (_327 == 0)

->

  _513 = VEC_COND_EXPR ;
  if (_513 != 0)

proper best simplification would be to _513 = mask__342.3367_293 != { 0,0,0..};

[Bug target/117073] New: [15 Regression] FAIL: gcc.target/i386/cond_op_fma_double-1.c

2024-10-10 Thread hjl.tools at gmail dot com via Gcc-bugs

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

Bug ID: 117073
   Summary: [15 Regression] FAIL:
gcc.target/i386/cond_op_fma_double-1.c
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
  Target Milestone: ---
Target: x86-64

On GCC 15 branch, I got

FAIL: gcc.target/i386/cond_op_fma_double-1.c scan-assembler-times vfmadd132pd[
\\t]+[^{\n]*%ymm[0-9]+{%k[1-7]}(?:\n|[ \\t]+#) 1
FAIL: gcc.target/i386/cond_op_fma_double-1.c scan-assembler-times vfnmadd132pd[
\\t]+[^{\n]*%ymm[0-9]+{%k[1-7]}(?:\n|[ \\t]+#) 1
FAIL: gcc.target/i386/cond_op_fma_double-1.c scan-assembler-times vfmsub132pd[
\\t]+[^{\n]*%ymm[0-9]+{%k[1-7]}(?:\n|[ \\t]+#) 1
FAIL: gcc.target/i386/cond_op_fma_double-1.c scan-assembler-times vfnmsub132pd[
\\t]+[^{\n]*%ymm[0-9]+{%k[1-7]}(?:\n|[ \\t]+#) 1

[Bug tree-optimization/116463] [15 Regression] fast-math-complex-mls-{double,float}.c fail after r15-3087-gb07f8a301158e5

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

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

[Bug target/117071] [15 Regression] FAIL: gcc.target/i386/avx512fp16-vector-complex-float.c

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup, PR 116463 has full analysis of the issue.

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

[Bug target/117072] [15 Regression] FAIL: gcc.target/i386/cond_op_fma_float-1.c

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

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

[Bug target/117073] [15 Regression] FAIL: gcc.target/i386/cond_op_fma_double-1.c

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug target/117074] New: [15 Regression] FAIL: gcc.target/i386/force-indirect-call-2.c

2024-10-10 Thread hjl.tools at gmail dot com via Gcc-bugs

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

Bug ID: 117074
   Summary: [15 Regression] FAIL:
gcc.target/i386/force-indirect-call-2.c
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
  Target Milestone: ---
Target: x86-64

On GCC 15 branch, I got

FAIL: gcc.target/i386/force-indirect-call-2.c scan-assembler-times
(?:call|jmp)[ \\t]+\\*% 3

[Bug target/117072] [15 Regression] FAIL: gcc.target/i386/cond_op_fma_float-1.c

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662523.html

d34cda720988674bcf8a24267c9e1ec61335d6de is the first bad commit
commit d34cda720988674bcf8a24267c9e1ec61335d6de
Author: Richard Biener 
Date:   Fri Sep 29 12:54:17 2023 +0200

Handle non-grouped stores as single-lane SLP

[Bug tree-optimization/117072] [15 Regression] FAIL: gcc.target/i386/cond_op_fma_{float,double,_Float16}-1.c

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Blocks||53947
   Keywords||missed-optimization
  Component|target  |tree-optimization
   Target Milestone|--- |15.0


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947
[Bug 53947] [meta-bug] vectorizer missed-optimizations

[Bug target/117068] bpf: add support for preserve_static_offset attribute

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
 Target||bpf

[Bug target/117068] bpf: add support for preserve_static_offset attribute

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from Andrew Pinski  ---
I can't think of a good way of solving this really. Having a specific pass
after register allocation might work but I am not 100% sure if it will work
always.

The other way of solving this is having special "variables"/"registers" where
you can't take their addresses but only load/store to. And then translate them
to the reg+offset after register allocator. This seems more reasonible way of
fixing this. Plus it hides it from the RA and other passes which might do CSE
or otherwise stuff for registers+offset.

[Bug fortran/117070] New: Procedure target error with parameter structure constructor

2024-10-10 Thread ivan.pribec at gmail dot com via Gcc-bugs

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

Bug ID: 117070
   Summary: Procedure target error with parameter structure
constructor
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ivan.pribec at gmail dot com
  Target Milestone: ---

Currently, a procedure target cannot be used in a structure constructor of a
constant:

Test case:

! dispatch_test.f90 --
!   Dispatch table using procedure pointers

module funcs
abstract interface
function retchar()
   character(len=1) :: retchar
end function
end interface
contains
function a()
character(len=1) :: a
a = 'a'
end function
function b()
character(len=1) :: b
b = 'b'
end function
function c()
character(len=1) :: c
c = 'c'
end function
end module

module dispatch_table
use funcs
implicit none
private

public :: table
public :: build_table, pc

! Procedure container
type :: pc
procedure(retchar), pointer, nopass :: rc => null()
end type

! Static dispatch table
type(pc), parameter :: table(3) = [pc(a),pc(b),pc(c)]  ! Doesn't work

! According to J2/24-007, section 7.5.10, a procedure target
! can be used in the structure constructor.

contains

! Dynamic dispatch table
function build_table() result(table)
type(pc) :: table(3)
table = [pc(a),pc(b),pc(c)]  ! This works
end function

end module

program test
use dispatch_table, only: pc, build_table
implicit none
type(pc) :: table(3)
table = build_table() ! Dynamic table
associate(abc => &
table(1)%rc()//table(2)%rc()//table(3)%rc())
if (abc /= 'abc') stop 1
end associate

block
use dispatch_table, only: table ! Static table
associate(abc => &
table(1)%rc()//table(2)%rc()//table(3)%rc())
if (abc /= 'abc') stop 2
end associate
end block

print *, 'PASS'
end program

[Bug target/117078] [15 Regression] FAIL: gcc.target/i386/pr101950-2.c

2024-10-10 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

 Resolution|--- |DUPLICATE
 Status|NEW |RESOLVED

--- Comment #2 from Sam James  ---
.

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

[Bug target/115028] [15 regression] gcc.target/i386/pr101950-2.c FAILs

2024-10-10 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #8 from Sam James  ---
*** Bug 117078 has been marked as a duplicate of this bug. ***

[Bug target/117082] [15 Regression] FAIL: gcc.target/i386/stack-check-17.c

2024-10-10 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

   Keywords||testsuite-fail
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-10-11

--- Comment #1 from Sam James  ---
I see it too.

[Bug target/117081] [15 Regression] FAIL: gcc.target/i386/pr91384.c

2024-10-10 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #2 from Sam James  ---
I mentioned it in PR115673 which may help with bisection range.

[Bug target/117082] [15 Regression] FAIL: gcc.target/i386/stack-check-17.c

2024-10-10 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #2 from Sam James  ---
I mentioned it in PR115673 which may help with bisection range.

[Bug target/117069] [15 Regression] gcc.target/i386/apx-ndd-tls-1b.c

2024-10-10 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=115028
   Keywords||testsuite-fail
   Target Milestone|--- |15.0

--- Comment #2 from Sam James  ---
It is mentioned in PR115028.

[Bug target/117074] [15 Regression] FAIL: gcc.target/i386/force-indirect-call-2.c

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

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

[Bug target/117074] [15 Regression] FAIL: gcc.target/i386/force-indirect-call-2.c

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |15.0
   Keywords||testsuite-fail

[Bug target/117074] [15 Regression] FAIL: gcc.target/i386/force-indirect-call-2.c

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Andrew Pinski  ---
See https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662257.html which
mentions this failure explicitly.

[Bug target/117075] New: [15 Regression] FAIL: gcc.target/i386/part-vect-complexhf.c

2024-10-10 Thread hjl.tools at gmail dot com via Gcc-bugs

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

Bug ID: 117075
   Summary: [15 Regression] FAIL:
gcc.target/i386/part-vect-complexhf.c
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
  Target Milestone: ---
Target: x86-64

On GCC 15 branch, I got

FAIL: gcc.target/i386/part-vect-complexhf.c scan-assembler-times vfmaddcph[
\\t] 1

[Bug target/117075] [15 Regression] FAIL: gcc.target/i386/part-vect-complexhf.c

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

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

[Bug tree-optimization/116463] [15 Regression] fast-math-complex-mls-{double,float}.c fail after r15-3087-gb07f8a301158e5

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

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

[Bug target/55212] [SH] Switch to LRA

2024-10-10 Thread olegendo at gcc dot gnu.org via Gcc-bugs

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

--- Comment #393 from Oleg Endo  ---
(In reply to Kazumoto Kojima from comment #392)
> Created attachment 59309 [details]
> a patch to fix pr55212-c384.C on devel/sh-lra

Thanks so much for looking into it.

Yes, insn matching order is important, there are some other cases already in
sh.md where insn order is important.

Adding a 
   !hard_reg_r0 (operands[1], SImode) 

while the operand itself is like
   (match_operand:SI 1 "arith_reg_operand" "^zr")

... looks a bit confusing, I think.  The constraint would allow R0 via "z", but
the"!hard_reg_r0 (operands[1], SImode)" would inhibit the pattern.

So for now I've opted to simply reorder the insn patterns on devel/sh-lra and
added a comment.  Confirmed that pr55212-c384.C is fixed by that.

[Bug target/117076] New: [15 Regression] FAIL: gcc.target/i386/pr101716.c

2024-10-10 Thread hjl.tools at gmail dot com via Gcc-bugs

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

Bug ID: 117076
   Summary: [15 Regression] FAIL: gcc.target/i386/pr101716.c
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
  Target Milestone: ---
Target: x86-64

On GCC 15 branch, I got

FAIL: gcc.target/i386/pr101716.c scan-assembler leal[\\t ][^\\n]*eax
FAIL: gcc.target/i386/pr101716.c scan-assembler-not movl[\\t ][^\\n]*eax

[Bug tree-optimization/117072] [15 Regression] FAIL: gcc.target/i386/cond_op_fma_{float,double,_Float16}-1.c

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
.

[Bug tree-optimization/117072] [15 Regression] FAIL: gcc.target/i386/cond_op_fma_{float,double,_Float16}-1.c

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Andrew Pinski  ---
See https://gcc.gnu.org/pipermail/gcc-patches/2024-September/662257.html which
mentions this failure explicitly.

[Bug fortran/117077] New: ICE due to allocatable component in hidden type

2024-10-10 Thread ivan.pribec at gmail dot com via Gcc-bugs

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

Bug ID: 117077
   Summary: ICE due to allocatable component in hidden type
   Product: gcc
   Version: 14.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ivan.pribec at gmail dot com
  Target Milestone: ---

The following program results in an ICE with gfortran 14.2:

module hidden
implicit none
public :: foo
contains
type(foo_type) function foo() result(f)
type :: foo_type
integer :: first
real(kind(1.0d0)) :: second
real, allocatable :: third(:)  ! ICE here.
end type
f = foo_type(42, 5.0d0)
end function
end module

program main
use hidden
associate(f => foo())
print *, f%first
print *, f%second
print *, allocated(f%third)
end associate
end program

The ICE disappears if the allocatable array component is removed. A pointer
array also works.

[Bug target/117076] [15 Regression] FAIL: gcc.target/i386/pr101716.c

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Keywords||missed-optimization
   Last reconfirmed||2024-10-11
   Target Milestone|--- |15.0
 Ever confirmed|0   |1

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

[Bug target/55212] [SH] Switch to LRA

2024-10-10 Thread olegendo at gcc dot gnu.org via Gcc-bugs

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

--- Comment #394 from Oleg Endo  ---
The patch https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665033.html
for PR 116550 might be relevant here, too.

[Bug target/117078] [15 Regression] FAIL: gcc.target/i386/pr101950-2.c

2024-10-10 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #1 from Sam James  ---
I see it too.

[Bug target/117074] [15 Regression] FAIL: gcc.target/i386/force-indirect-call-2.c

2024-10-10 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #3 from Sam James  ---
.

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

[Bug target/115673] [15 regression] gcc.target/i386/force-indirect-call-2.c test failure

2024-10-10 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

 CC||hjl.tools at gmail dot com

--- Comment #9 from Sam James  ---
*** Bug 117074 has been marked as a duplicate of this bug. ***

[Bug target/117081] [15 Regression] FAIL: gcc.target/i386/pr91384.c

2024-10-10 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Last reconfirmed||2024-10-11
   Target Milestone|--- |15.0
 Status|UNCONFIRMED |NEW

--- Comment #1 from Sam James  ---
I see it too.

[Bug target/117078] [15 Regression] FAIL: gcc.target/i386/pr101950-2.c

2024-10-10 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug target/117080] [15 Regression] FAIL: gcc.target/i386/pr88531-2b.c and FAIL: gcc.target/i386/pr88531-2c.c

2024-10-10 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

   Last reconfirmed||2024-10-11
 Ever confirmed|0   |1
   Target Milestone|--- |15.0
 Status|UNCONFIRMED |NEW

--- Comment #1 from Sam James  ---
I see it too.

[Bug target/117079] [15 Regression] FAIL: gcc.target/i386/pr105493.c

2024-10-10 Thread sjames at gcc dot gnu.org via Gcc-bugs

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

Sam James  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2024-10-11
   Target Milestone|--- |15.0
 Ever confirmed|0   |1

--- Comment #1 from Sam James  ---
I see it too.

[Bug rtl-optimization/117064] target hook HARD_REGNO_RENAME_OK is too limiting

2024-10-10 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #1 from Richard Biener  ---
Confirmed.  Maybe the hook can also be removed, it's documentation says

--
@defmac HARD_REGNO_RENAME_OK (@var{from}, @var{to})
A C expression that is nonzero if it is OK to rename a hard register
@var{from} to another hard register @var{to}. 

One common use of this macro is to prevent renaming of a register to
another register that is not saved by a prologue in an interrupt
handler.

The default is always nonzero.
--

but the RA must have enough information to avoid similar issues.  I noticed
sel-sched.cc also uses HARD_REGNO_RENAME_OK.

[Bug target/117082] [15 Regression] FAIL: gcc.target/i386/stack-check-17.c since r15-1619-g3b9b8d6cfdf593

2024-10-10 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |15.0

[Bug target/70989] [SH] Further improve utilization of zero-displacement conditional branches

2024-10-10 Thread olegendo at gcc dot gnu.org via Gcc-bugs

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

Oleg Endo  changed:

   What|Removed |Added

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

--- Comment #3 from Oleg Endo  ---
Conditional shifts could be useful, too ...

void bleh (bool val)
{
  *(volatile unsigned int*)12300 = 1 << (12 + (1u-val) * 16u);
}

currently compiles to:
extu.b  r4,r0
mov.w   .L9,r2
shll2   r0
shll2   r0
xor #16,r0
add #12,r0
mov #1,r1
shldr0,r1
mov.l   r1,@r2
rts 
nop
.L9:
.short  12300


possible ideal output:

mov.w   .L9,r2
mov.w   .L10,r0 // r0 = 1 << 12
tst r4,r4   // T = val == 0
bt  0f
shll16  r0
0:
mov.l   r0,@r2

[Bug c/117083] ICE: in get_expr_operands, at tree-ssa-operands.cc:939

2024-10-10 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||error-recovery

--- Comment #3 from Richard Biener  ---
foo (<<< error >>>);

error recovery isn't too great in the GIMPLE FE.

[Bug tree-optimization/117062] [15 regression] x86-64: ICE during GIMPLE pass: vect

2024-10-10 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from Richard Biener  ---
The attached testcase runs into PR117050 indeed.  I'll do a partial revert
instead of the fix as the fix takes some time due to dependence on a larger
issue.

[Bug target/80881] Implement Windows native TLS

2024-10-10 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs

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

--- Comment #50 from Eric Botcazou  ---
> Please note that RIP-relative addresses are one byte shorter than absolute
> addresses and are interchangeable on x86_64 Linux. If this is also true on
> Windows (UNSPEC_PCREL was introduced for PE linkers) then the above should
> also be emitted without flag_pic.

The crucial bits are these in config/i386/cygming.h:

/* Don't allow flag_pic to propagate since gas may produce invalid code
   otherwise.  */

#undef  SUBTARGET_OVERRIDE_OPTIONS
#define SUBTARGET_OVERRIDE_OPTIONS  \
do {\
  flag_pic = TARGET_64BIT ? 1 : 0;  \
} while (0)

so 64-bit code is always PIC whereas 32-bit code is never PIC.

[Bug tree-optimization/117062] [15 regression] x86-64: ICE during GIMPLE pass: vect

2024-10-10 Thread rguenther at suse dot de via Gcc-bugs

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

--- Comment #8 from rguenther at suse dot de  ---
On Thu, 10 Oct 2024, manuel.lauss at googlemail dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117062
> 
> --- Comment #5 from Manuel Lauss  ---
> Another one:
> 
> g++ -c -O2 -march=znver5 lra-constraints.ii 
> during GIMPLE pass: forwprop
> /tmp-ram/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/lra-constraints.cc:
> In function 'bool split_reg(bool, int, rtx_insn*, rtx, rtx_insn*)':
> /tmp-ram/portage/sys-devel/gcc-15.0./work/gcc-15.0./gcc/lra-constraints.cc:6111:1:
> internal compiler error: tree check: expected vector_type, have boolean_type 
> in
> TYPE_VECTOR_SUBPARTS, at tree.h:4255
>  6111 | split_reg (bool before_p, int original_regno, rtx_insn *insn,
>   | ^

This one looks different, I can reporduce and will split out to a
different bug.

[Bug c++/108953] inefficient codegen for trivial equality (defaulted operator==)

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Andrew Pinski  ---
LLVM has a full pass that does this:
https://reviews.llvm.org/D33987

[Bug target/117078] New: [15 Regression] FAIL: gcc.target/i386/pr101950-2.c

2024-10-10 Thread hjl.tools at gmail dot com via Gcc-bugs

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

Bug ID: 117078
   Summary: [15 Regression] FAIL: gcc.target/i386/pr101950-2.c
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
  Target Milestone: ---
Target: x86-64

On x86-64, I got

FAIL: gcc.target/i386/pr101950-2.c scan-assembler-times \txor[ql]\t 2

[Bug target/117079] New: [15 Regression] FAIL: gcc.target/i386/pr105493.c

2024-10-10 Thread hjl.tools at gmail dot com via Gcc-bugs

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

Bug ID: 117079
   Summary: [15 Regression] FAIL: gcc.target/i386/pr105493.c
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
  Target Milestone: ---

On x86-64, I got

FAIL: gcc.target/i386/pr105493.c scan-tree-dump-times slp1 "  MEM
 \\[[^]]*\\] = " 4

[Bug target/117080] New: [15 Regression] FAIL: gcc.target/i386/pr88531-2b.c and FAIL: gcc.target/i386/pr88531-2c.c

2024-10-10 Thread hjl.tools at gmail dot com via Gcc-bugs

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

Bug ID: 117080
   Summary: [15 Regression] FAIL: gcc.target/i386/pr88531-2b.c and
FAIL: gcc.target/i386/pr88531-2c.c
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
  Target Milestone: ---
Target: x86-64

On x86-64, I got

FAIL: gcc.target/i386/pr88531-2b.c scan-assembler-times vmulps 1
FAIL: gcc.target/i386/pr88531-2c.c scan-assembler-times vmulps 1

[Bug target/55212] [SH] Switch to LRA

2024-10-10 Thread glaubitz at physik dot fu-berlin.de via Gcc-bugs

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

--- Comment #396 from John Paul Adrian Glaubitz  ---
(In reply to Kazumoto Kojima from comment #392)
> Created attachment 59309 [details]
> a patch to fix pr55212-c384.C on devel/sh-lra

I can confirm that this patch fixes the bootstrap issue with Oleg's tree
mentioned in comment #388 for me.

[Bug libstdc++/93059] char and char8_t does not talk with each other with memcpy. std::copy std::copy_n, std::fill, std::fill_n, std::uninitialized_copy std::uninitialized_copy_n, std::fill, std::unin

2024-10-10 Thread redi at gcc dot gnu.org via Gcc-bugs

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Target Milestone|--- |15.0

[Bug tree-optimization/117060] internal compiler error: in as_a, at is-a.h:255

2024-10-10 Thread cvs-commit at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from GCC Commits  ---
The master branch has been updated by Richard Biener :

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

commit r15-4237-g7ce2229d54d575d788b016f941aafd0464ea77f7
Author: Richard Biener 
Date:   Thu Oct 10 14:15:13 2024 +0200

tree-optimization/117060 - fix oversight in vect_build_slp_tree_1

We are failing to match call vs. non-call when dealing with matching
loads or stores.

PR tree-optimization/117060
* tree-vect-slp.cc (vect_build_slp_tree_1): When comparing
calls also fail if the first isn't a call.

* gfortran.dg/pr117060.f90: New testcase.

[Bug tree-optimization/117060] internal compiler error: in as_a, at is-a.h:255

2024-10-10 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

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

--- Comment #3 from Richard Biener  ---
Fixed.  Thanks for reporting.

[Bug target/116887] Section type conflict on loongarch with .data.rel.ro section attribute

2024-10-10 Thread fw at gcc dot gnu.org via Gcc-bugs

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

--- Comment #21 from Florian Weimer  ---
(In reply to chenglulu from comment #20)
> (In reply to Florian Weimer from comment #18)
> > (In reply to chenglulu from comment #17)
> > > I don't think it can be completely avoided. But I don't understand why the
> > > public code does not set the SECTION_RELRO flag when putting decl into
> > > ".data.rel.ro" via __attribute__.
> > 
> > I'm not aware of a way to set the RELRO flag directly. We want to write to
> > these variables during initialization, so we cannot make them const. I
> > assume we could move the definition into a separate TU and only have the
> > section attribute on a definition. This would then rely on more relaxed
> > section merging in the linker. The particular instance that triggered this
> > bug report would be fairly straightforward to fix, but doing this for e.g.
> > _rtld_global_ro is more difficult.
> 
> Um, sorry. I don't quite understand the difference between _rtld_global_ro
> and __dlfo_main in this regard.

The definition of _rtld_global_ro with its initializer might not be as easily
moved to a separate file from any accesses. There's even an
architecture-dependent #include  right in the middle. So I'd
rather see proper GCC support for mixing RELRO definitions and code access,
whatever that means.

[Bug target/55212] [SH] Switch to LRA

2024-10-10 Thread kkojima at gcc dot gnu.org via Gcc-bugs

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

--- Comment #392 from Kazumoto Kojima  ---
Created attachment 59309
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59309&action=edit
a patch to fix pr55212-c384.C on devel/sh-lra

[Bug target/115789] gcc miscompile itself with CFLAGS -O3 -march=rv64gcv_zvl256b

2024-10-10 Thread law at gcc dot gnu.org via Gcc-bugs

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

Jeffrey A. Law  changed:

   What|Removed |Added

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

--- Comment #13 from Jeffrey A. Law  ---
This seems to be working on the trunk.  Given the time to build/test on the BPI
it's not really feasible to bisect this down to a particular change (which
would be necessary to consider backporting).

[Bug target/116242] [meta-bug] Tracker for zvl issues in RISC-V

2024-10-10 Thread law at gcc dot gnu.org via Gcc-bugs

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

Bug 115789 Summary: gcc miscompile itself with CFLAGS -O3 -march=rv64gcv_zvl256b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115789

   What|Removed |Added

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

[Bug target/80881] Implement Windows native TLS

2024-10-10 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs

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

Eric Botcazou  changed:

   What|Removed |Added

  Attachment #59298|0   |1
is obsolete||
  Attachment #59305|0   |1
is obsolete||

--- Comment #40 from Eric Botcazou  ---
Created attachment 59306
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59306&action=edit
WIP patch #2

[Bug c++/114571] -Wzero-as-null-pointer-constant does not complain about NULL

2024-10-10 Thread alx at kernel dot org via Gcc-bugs

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

--- Comment #7 from Alejandro Colomar  ---
See also:

[Bug middle-end/116926] [15 Regression] Recent changes in dot-product causing ICE on c6x port

2024-10-10 Thread victorldn at gcc dot gnu.org via Gcc-bugs

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

Victor Do Nascimento  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
 CC||victorldn at gcc dot gnu.org
   Last reconfirmed||2024-10-10

--- Comment #2 from Victor Do Nascimento  ---
Hi Jeff,

Thanks for running the testsuite for the c6x backend and highlighting the
issue. My apologies it's taken me this long to getting round to looking at it.

Yeah, I see the error locally.  Will get a fix upstream ASAP.

Many thanks,
Victor

[Bug c++/114571] -Wzero-as-null-pointer-constant does not complain about NULL

2024-10-10 Thread alx at kernel dot org via Gcc-bugs

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

Alejandro Colomar  changed:

   What|Removed |Added

 CC||alx at kernel dot org

--- Comment #4 from Alejandro Colomar  ---
If you want a diagnostic for that,
you should add (or ask for) -Wnull-as-null-pointer-constant
NULL is not zero.

I want to get warned for 0 but not for NULL.

[Bug target/116887] Section type conflict on loongarch with .data.rel.ro section attribute

2024-10-10 Thread xry111 at gcc dot gnu.org via Gcc-bugs

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

--- Comment #16 from Xi Ruoyao  ---
(In reply to chenglulu from comment #15)
> (In reply to chenglulu from comment #14)
> > (In reply to Xi Ruoyao from comment #13)
> > > Hmm I do think 2 is better.  It seems we are just "reinventing" the GOT 
> > > in 1.
> > > 
> > > So OK with your approach if it passes regtest.
> > 
> > I  agree, I'll test the patch
> 
> extern struct rtld_global _rtld_global;
> static struct dl_find_object_internal _dlfo_main __attribute__ ((section
> (".data.rel.ro")));
> extern void _dlfo_process_initial_noncontiguous_map (void);
> void
> _dlfo_process_initial (void)
> {
>   if ( _dlfo_main.map == &_rtld_global._dl_rtld_map)
> _dlfo_process_initial_noncontiguous_map ();
> }
> 
> 
> I've been looking at this code for the past two days, and I think the second
> modification is incomplete. The reason for the problem is:
> 
> If decls are put in ".data.rel.ro" or ".data.rel.ro.local" using the
> __attribute__ construct （_dlfo_main）, then the obtained section flags
> contain only SECTION_WRITE and not SECTION_RELRO.
> But labels are placed in the constant pool ("data.rel.ro" or  
> "data.rel.ro.local") (_rtld_global._dl_rtld_map), the section flags contain
> both SECTION_WRITE and SECTION_RELRO.
> Since two sections are the same, but the flags are set differently, then can
> cause a section conflicts.

So can we avoid putting labels into constant pool?  If not we'll have to use
patch 1 like hppa.

[Bug c++/91187] Is it possible to make -Wzero-as-null-pointer-constant learn about extern "C"?

2024-10-10 Thread alx at kernel dot org via Gcc-bugs

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

Alejandro Colomar  changed:

   What|Removed |Added

 CC||alx at kernel dot org

--- Comment #10 from Alejandro Colomar  ---
(In reply to Harald van Dijk from comment #9)
> (In reply to Jonathan Wakely from comment #8)
> > (In reply to Albert Astals Cid from comment #0)
> > > #define Z_NULL 0
> > 
> > N.B. this is actually a bug. Using Z_NULL where a null pointer is expected
> > might cause bugs e.g. execl("foo", "foo", Z_NULL) can pass a 32-bit int
> > where a 64-bit pointer is expected, leading to undefined behaviour.
> 
> Whether this is a bug in the definition of Z_NULL depends on how Z_NULL is
> meant to be used. If it is not supported as a variadic function argument,
> the fact that it does not work as a variadic function argument is not a bug.
> 
> zlib.h's definition contains a comment:
> 
>   #define Z_NULL  0  /* for initializing zalloc, zfree, opaque */
> 
> This does not include calling variadic functions.
> 
> > So maybe the warning should be taken as an opportunity to fix the code (or
> > report a bug to the library) to use something safer:
> > 
> > #if __cplusplus
> > #define Z_NULL nullptr
> > #else
> > #define Z_NULL 0L
> > #endif
> 
> If Z_NULL is meant to be usable as a variadic function argument, this is
> wrong too. There is no guarantee that 0L is the same size as a pointer
> (think W64). There is not even a guarantee that NULL is the same size as a
> pointer.

Maybe not a bug if you're sure it will never be used for variadic functions,
but that is still a bad definition of Z_NULL.  Why not this?

#ifdef __cplusplus
#define Z_NULL nullptr
#else
#define Z_NULL NULL
#endif

[Bug target/80881] Implement Windows native TLS

2024-10-10 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs

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

--- Comment #39 from Eric Botcazou  ---
Created attachment 59305
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59305&action=edit
WI

[Bug target/80881] Implement Windows native TLS

2024-10-10 Thread ebotcazou at gcc dot gnu.org via Gcc-bugs

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

--- Comment #38 from Eric Botcazou  ---
It's the legitimate_pic_operand_p hunk that I dropped earlier...

[Bug fortran/117060] New: internal compiler error: in as_a, at is-a.h:255

2024-10-10 Thread mario-baumann at web dot de via Gcc-bugs

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

Bug ID: 117060
   Summary: internal compiler error: in as_a, at is-a.h:255
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mario-baumann at web dot de
  Target Milestone: ---

Created attachment 59308
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=59308&action=edit
Fortran source file

Hi, following fortran source procudes ICE with -O2 and -O3, smaller
optimisation works fine.

> /opt/Gcc/15.0.0/bin/gfortran -O2 -c foo.F
during GIMPLE pass: vect
foo.F:1:20:

1 |   subroutine foo (out)
  |^
internal compiler error: in as_a, at is-a.h:255


---

> /opt/Gcc/15.0.0/bin/gfortran -v
Using built-in specs.
COLLECT_GCC=/opt/Gcc/15.0.0/bin/gfortran
COLLECT_LTO_WRAPPER=/opt/Gcc/15.0.0/libexec/gcc/x86_64-apple-darwin21/15.0.0/lto-wrapper
Target: x86_64-apple-darwin21
Configured with: /opt/Gcc/15.0.0/.src/configure --prefix=/opt/Gcc/15.0.0
--build=x86_64-apple-darwin21 --enable-languages=c,c++,fortran --enable-lto
--enable-stage1-checking --enable-libstdcxx-time --disable-nls
--disable-libquadmath --disable-libquadmath-support
--with-sysroot=/opt/Gcc/15.0.0/.sys --with-ld=/opt/local/bin/ld
--with-ar=/opt/local/bin/ar --with-as=/opt/local/bin/as --with-system-zlib
--with-pkgversion=git-revision-214303
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 15.0.0 20241010 (experimental) (git-revision-214303)

[Bug tree-optimization/117060] internal compiler error: in as_a, at is-a.h:255

2024-10-10 Thread rguenth at gcc dot gnu.org via Gcc-bugs

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
   Last reconfirmed||2024-10-10
  Component|fortran |tree-optimization
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1

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

[Bug target/55212] [SH] Switch to LRA

2024-10-10 Thread kkojima at gcc dot gnu.org via Gcc-bugs

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

--- Comment #390 from Kazumoto Kojima  ---
(In reply to Richard Sandiford from comment #389)
> (In reply to Oleg Endo from comment #304)
> > (define_insn "block_lump_real"
> >   [(set (mem:BLK (match_operand:SI 2 "sfunc_arg0_reg" "=r,r"))
> >(mem:BLK (match_operand:SI 3 "sfunc_arg1_reg" "=r,r")))
> >(use (match_operand:SI 0 "arith_reg_operand" "r,r"))
> >(use (match_operand 1 "" "Z,Ccl"))
> >(use (match_operand:SI 4 "sfunc_arg2_reg" "=r,r"))
> > 
> >(use (reg:SI R4_REG))<<
> >(use (reg:SI R5_REG))<<
> >(use (reg:SI R6_REG))<<
> > 
> >(clobber (match_dup 2))
> >(clobber (match_dup 3))
> >(clobber (match_dup 4))
> >(clobber (reg:SI PR_REG))
> 
> Sorry for the late reply, but I think this is somewhat dangerous, in that
> the constraints (r) are more general than the predicates (sfunc_arg0_reg
> etc.).
> 
> Do we know why the pattern in trunk doesn't work?  It looks correct to me,
> and I think it should work with LRA too.  Did Andrew P's patch (PR116058)
> not help?

Thanks for the comment!

The patch in PR110658 has already been applied to our base repo devel/sh-lra. 
It doesn't fix this issue, though the symptom that clobber doesn't work as
expected is very similar.  As discussed in c#308 and c#309,  it seems that LRA
doesn't handle the clobber reg pattern if that reg is recognized as the input
reg, unless it's call_insn.  This observation is based on my vague
understanding of LRA, though.

[Bug target/116887] Section type conflict on loongarch with .data.rel.ro section attribute

2024-10-10 Thread xry111 at gcc dot gnu.org via Gcc-bugs

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

--- Comment #19 from Xi Ruoyao  ---
Hmm interesting.  For x86 x86_64_elf_section_type_flags also does not give
SECTION_RELRO but the test case seems building fine...

[Bug target/55212] [SH] Switch to LRA

2024-10-10 Thread kkojima at gcc dot gnu.org via Gcc-bugs

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

--- Comment #391 from Kazumoto Kojima  ---
(In reply to John Paul Adrian Glaubitz from comment #388)
> (In reply to Oleg Endo from comment #387)
> > > Currently, I'm using the sh-lra-take3 branch with the patches 59216, 59219
> > > and 59286 which works best so far for all my tests, including WebKit.
> > 
> > Please push your branch version into some git repository and share it.  It
> > will make it easier to reproduce for others and figure out what is going on.
> 
> I'll look into it. But it's really just Kaz' most recent tree with the three
> additional patches.
> 
> I also just tried your latest tree and I'm still getting the subreg3 ICE
> there:

Sorry for the slow reply.  I'm having trouble with my physical condition right
now.

After syncing my local tree with the latest devel/sh-lra, pr55212-c384.C failed
at subreg3 pass again, although almost imported changes are simply cleanups. 
After bisecting, I found the change causing it.  *mov_store_mem_index is
moved after mov_store_mem_index on devel/sh-lra.  Order matters?!

I found that the recog function for those insns in insn-recog.cc is generated
like as

static int
recog_21 (rtx x1 ATTRIBUTE_UNUSED,
rtx_insn *insn ATTRIBUTE_UNUSED,
int *pnum_clobbers ATTRIBUTE_UNUSED)
{
  rtx * const operands ATTRIBUTE_UNUSED = &recog_data.operand[0];
  rtx x2, x3, x4, x5, x6;
  int res ATTRIBUTE_UNUSED;
  x2 = XEXP (x1, 0);
...
  switch (GET_MODE (x2))
{
case E_QImode:
  if (pnum_clobbers != NULL
  && arith_reg_operand (operands[1], E_SImode)
  && arith_reg_operand (operands[2], E_QImode)
  && 
#line 5411 "/git/gcc/gcc/config/sh/sh.md"
(TARGET_SH1 && ! TARGET_SH2A && sh_lra_p ()))
{
  *pnum_clobbers = 1;
  return 196; /* movqi_store_mem_index */
}
  if (!hard_reg_r0 (operands[1], E_SImode)
  || !arith_reg_operand (operands[2], E_QImode)
  || !
#line 5426 "/git/gcc/gcc/config/sh/sh.md"
(TARGET_SH1 && ! TARGET_SH2A && sh_lra_p ()))
return -1;
  return 198; /* *movqi_store_mem_index */

for devel/sh-lra.  The pattern of *movqi_store_mem_index is wrongly recognized
at the 1st if clause as movqi_store_mem_index.   It seems that this ends up in
that ICE.

The problem is that mov_store_mem_index can match even when operands[1]
is r0.  A quick fix would be to add !hard_reg_r0 (operands[1], SImode) to the
condition of mov_store_mem_index or define&use arith_reg_operand_not_r0
predicate.  I confirmed the former fixes the ICE.  Similar changes are needed
for movsf_ie_{load,store}_mem_index.

[Bug target/116887] Section type conflict on loongarch with .data.rel.ro section attribute

2024-10-10 Thread chenglulu at loongson dot cn via Gcc-bugs

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

--- Comment #20 from chenglulu  ---
(In reply to Florian Weimer from comment #18)
> (In reply to chenglulu from comment #17)
> > I don't think it can be completely avoided. But I don't understand why the
> > public code does not set the SECTION_RELRO flag when putting decl into
> > ".data.rel.ro" via __attribute__.
> 
> I'm not aware of a way to set the RELRO flag directly. We want to write to
> these variables during initialization, so we cannot make them const. I
> assume we could move the definition into a separate TU and only have the
> section attribute on a definition. This would then rely on more relaxed
> section merging in the linker. The particular instance that triggered this
> bug report would be fairly straightforward to fix, but doing this for e.g.
> _rtld_global_ro is more difficult.

Um, sorry. I don't quite understand the difference between _rtld_global_ro and
__dlfo_main in this regard.

[Bug target/116887] Section type conflict on loongarch with .data.rel.ro section attribute

2024-10-10 Thread xry111 at gcc dot gnu.org via Gcc-bugs

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

--- Comment #23 from Xi Ruoyao  ---
Anyway I'd like to know more info about PR47610 and PR52999.  In the old days
people didn't write rationales in ChangeLog so it's hard to understand the
rationales of the fixes.

And is there a test case for which patch 2 does not work?

[Bug target/116887] Section type conflict on loongarch with .data.rel.ro section attribute

2024-10-10 Thread xry111 at gcc dot gnu.org via Gcc-bugs

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

Xi Ruoyao  changed:

   What|Removed |Added

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

--- Comment #22 from Xi Ruoyao  ---
(In reply to Florian Weimer from comment #18)
> (In reply to chenglulu from comment #17)
> > I don't think it can be completely avoided. But I don't understand why the
> > public code does not set the SECTION_RELRO flag when putting decl into
> > ".data.rel.ro" via __attribute__.
> 
> I'm not aware of a way to set the RELRO flag directly. We want to write to
> these variables during initialization, so we cannot make them const. I
> assume we could move the definition into a separate TU and only have the
> section attribute on a definition. This would then rely on more relaxed
> section merging in the linker. The particular instance that triggered this
> bug report would be fairly straightforward to fix, but doing this for e.g.
> _rtld_global_ro is more difficult.

In PR47610 fix (r169855) SECTION_RELRO is (intentionally??) only applied for
decl == NULL.

So should we just extend it to cover decl != NULL, i.e. something like

--- a/gcc/varasm.cc
+++ b/gcc/varasm.cc
@@ -6863,6 +6863,9 @@ default_section_type_flags (tree decl, const char *name,
int reloc)

   if (decl && TREE_CODE (decl) == FUNCTION_DECL)
 flags = SECTION_CODE;
+  else if (strcmp (name, ".data.rel.ro") == 0
+  || strcmp (name, ".data.rel.ro.local") == 0)
+flags = SECTION_WRITE | SECTION_RELRO;
   else if (decl)
 {
   enum section_category category
@@ -6876,12 +6879,7 @@ default_section_type_flags (tree decl, const char *name,
int reloc)
flags = SECTION_WRITE;
 }
   else
-{
-  flags = SECTION_WRITE;
-  if (strcmp (name, ".data.rel.ro") == 0
- || strcmp (name, ".data.rel.ro.local") == 0)
-   flags |= SECTION_RELRO;
-}
+flags = SECTION_WRITE;

   if (decl && DECL_P (decl) && DECL_COMDAT_GROUP (decl))
 flags |= SECTION_LINKONCE;

???

[Bug target/116980] Fixed includes don’t work with XCode 16

2024-10-10 Thread iains at gcc dot gnu.org via Gcc-bugs

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

Iain Sandoe  changed:

   What|Removed |Added

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

--- Comment #2 from Iain Sandoe  ---
agreed with what FX says.


>From time to time Apple introduces changes in the SDK layout (IIRC last time
was sometime around 10.13) that mean fixed includes are no longer referring to
the same files (for example).

At present there is nothing we can do other than to try and minimise the use of
fixed includes (which reduces the chance of this happening).

Recommendation would be to build the compiler against the Xcode CLT
installation and make the SDK version specific (e.g. macOS14.sdk) then, when
updating to a new CLT version - so long as it contains the macOS14.sdk (which
is the case for XC16, for example) the compiler should continue to operate as
built.

Obviously, if you want to take advantage of new features in macOS15 / XC16,
you'd need to build the compiler for that anyway ..

I'm closing this as "WONTFIX" (it's more that we cannot change what Apple
ships).

[Bug c++/117061] New: Error on use of parameter in lambda outside function body

2024-10-10 Thread eczbek.void at gmail dot com via Gcc-bugs

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

Bug ID: 117061
   Summary: Error on use of parameter in lambda outside function
body
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eczbek.void at gmail dot com
  Target Milestone: ---

This code causes an error: https://godbolt.org/z/3EdfzMqr9


```
void foo(int x) noexcept(noexcept([&x] { x; })) {}

int main() {
foo(3);
}
```


: In lambda function:
:1:43: error: use of parameter outside function body before ';' token
1 | void foo(int x) noexcept(noexcept([&x] { x; })) {}
  |   ^
Compiler returned: 1

[Bug tree-optimization/112418] factor_out_conditional_operation could be done for more phis

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Andrew Pinski  ---
So looking into what LLVM does here (GVN-sink), The order inside the bb matter.

Example:
```
int g(int);
int f(int a, int b, int c, int l, int j)
{
int d, e;
if (c)
{
  e = b  >> 2;
  d = j / l;
} else
{
  d = a / l;
  e = b >> 1;
}
return g(d / e);
}

int g(int);
int f1(int a, int b, int c, int l, int j)
{
int d, e;
if (c)
{
  e = b  >> 2;
  d = j / l;
} else
{
  e = b >> 1;
  d = a / l;
}
return g(d + e);
}
```

They lockstep backwards on the 2 bbs that define e/d. But since the older is
different in f, they don't do anything. This is different from what I am doing.
So I can't learn from it at all.

[Bug target/117081] New: [15 Regression] FAIL: gcc.target/i386/pr91384.c

2024-10-10 Thread hjl.tools at gmail dot com via Gcc-bugs

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

Bug ID: 117081
   Summary: [15 Regression] FAIL: gcc.target/i386/pr91384.c
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
  Target Milestone: ---
Target: x86-64

On x86-64, I got

FAIL: gcc.target/i386/pr91384.c scan-assembler-not testl

[Bug target/117082] New: [15 Regression] FAIL: gcc.target/i386/stack-check-17.c

2024-10-10 Thread hjl.tools at gmail dot com via Gcc-bugs

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

Bug ID: 117082
   Summary: [15 Regression] FAIL: gcc.target/i386/stack-check-17.c
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
  Target Milestone: ---
Target: x86-64

On x86-64, I got

FAIL: gcc.target/i386/stack-check-17.c scan-assembler-not pop

[Bug jit/111396] Segfault when using -flto with libgccjit

2024-10-10 Thread egallager at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Eric Gallager  ---
(In reply to Antoni from comment #5)
> I believe so, but there might always be cases that we need to fix.
> Why do you ask? Did you get any issue?

I was just wondering if I could close it.

[Bug target/116887] Section type conflict on loongarch with .data.rel.ro section attribute

2024-10-10 Thread chenglulu at loongson dot cn via Gcc-bugs

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

--- Comment #25 from chenglulu  ---
(In reply to Xi Ruoyao from comment #22)
> (In reply to Florian Weimer from comment #18)
> > (In reply to chenglulu from comment #17)
> > > I don't think it can be completely avoided. But I don't understand why the
> > > public code does not set the SECTION_RELRO flag when putting decl into
> > > ".data.rel.ro" via __attribute__.
> > 
> > I'm not aware of a way to set the RELRO flag directly. We want to write to
> > these variables during initialization, so we cannot make them const. I
> > assume we could move the definition into a separate TU and only have the
> > section attribute on a definition. This would then rely on more relaxed
> > section merging in the linker. The particular instance that triggered this
> > bug report would be fairly straightforward to fix, but doing this for e.g.
> > _rtld_global_ro is more difficult.
> 
> In PR47610 fix (r169855) SECTION_RELRO is (intentionally??) only applied for
> decl == NULL.
> 
> So should we just extend it to cover decl != NULL, i.e. something like
> 


I think it should be like this.

[Bug target/117068] bpf: add support for preserve_static_offset attribute

2024-10-10 Thread pinskia at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from Andrew Pinski  ---
in the case of GCC, the attribute is lost early on for many accesses.
Especially a target specific one. In RTL mem has attributes but nothing like
preserve_static_offset . CE (ifcvt) could turn in theory turn a ? mem(reg+OFF0)
: mem(reg+OFF1) into off = a ? OFF0 : OFF1; mem(reg+off) . Because there is
nothing blocking mem here. I wonder if this was the best way of solving this
rather than turn the issue over to how to say these are special global
"registers" which get loaded/stored to and then turn that into load/stores.

[Bug target/116887] Section type conflict on loongarch with .data.rel.ro section attribute

2024-10-10 Thread chenglulu at loongson dot cn via Gcc-bugs

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

--- Comment #26 from chenglulu  ---
(In reply to Xi Ruoyao from comment #23)
> Anyway I'd like to know more info about PR47610 and PR52999.  In the old
> days people didn't write rationales in ChangeLog so it's hard to understand
> the rationales of the fixes.
> 
> And is there a test case for which patch 2 does not work?

I'll try it today.

[Bug target/117072] New: [15 Regression] FAIL: gcc.target/i386/cond_op_fma_float-1.c

2024-10-10 Thread hjl.tools at gmail dot com via Gcc-bugs

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

Bug ID: 117072
   Summary: [15 Regression] FAIL:
gcc.target/i386/cond_op_fma_float-1.c
   Product: gcc
   Version: 15.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
CC: liuhongt at gcc dot gnu.org
  Target Milestone: ---
Target: x86-64

On GCC 15 branch, I got

FAIL: gcc.target/i386/cond_op_fma_float-1.c scan-assembler-times vfmadd132ps[
\\t]+[^{\n]*%ymm[0-9]+{%k[1-7]}(?:\n|[ \\t]+#) 1
FAIL: gcc.target/i386/cond_op_fma_float-1.c scan-assembler-times vfnmadd132ps[
\\t]+[^{\n]*%ymm[0-9]+{%k[1-7]}(?:\n|[ \\t]+#) 1
FAIL: gcc.target/i386/cond_op_fma_float-1.c scan-assembler-times vfmsub132ps[
\\t]+[^{\n]*%ymm[0-9]+{%k[1-7]}(?:\n|[ \\t]+#) 1
FAIL: gcc.target/i386/cond_op_fma_float-1.c scan-assembler-times vfnmsub132ps[
\\t]+[^{\n]*%ymm[0-9]+{%k[1-7]}(?:\n|[ \\t]+#) 1

1 2 >

1 - 100 of 195 matches

Mail list logo