date:20240119

[Bug target/95112] i686 procedures have prolog endbr32

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

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

Sam James  changed:

   What|Removed |Added

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

--- Comment #3 from Sam James  ---
(In reply to Alexander Kobets from comment #2)
> Yes, that it.
> I am not sure, that CF must be enabled by default, at your discretion.
> Thank you.

I believe this is Ubuntu's patching of the specs, it doesn't happen upstream by
default.

It is possible (without making a commitment/official statement on it at all)
that one day --enable-standard-branch-protection might allow configuring this
for CET too but it doesn't right now.

[Bug tree-optimization/113520] ICE when building swi-prolog-9.1.2 with LTO (tree check: expected array_type, have integer_type in array_ref_low_bound)

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

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

--- Comment #5 from Andrew Pinski  ---
https://github.com/SWI-Prolog/packages-xpce/commit/641bbb1d83416be2fb910dbffcd6ba32db1c0b8e

Was the commit which "fixed" compiling with GCC 4.0 but really it is broken.
I suspect the fix is to use s/struct name/struct bname/ here might work. but
this is all messy pre-ANSI C code.

[Bug tree-optimization/113520] ICE when building swi-prolog-9.1.2 with LTO (tree check: expected array_type, have integer_type in array_ref_low_bound)

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

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

--- Comment #4 from Sam James  ---
Yeah, after you asked, I just realised the original does ICE differently. Let's
retitle this one and I'll reduce it properly again for the original (but it is
similar)

[Bug tree-optimization/113520] ICE when building swi-prolog-9.1.2 with LTO (tree check: expected array_type, have integer_type in array_ref_low_bound)

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

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

--- Comment #3 from Andrew Pinski  ---
The code has:
```
struct bname builtin_names[] =
{
...
};
```


header file:
```
extern struct name builtin_names[]; /* object-array of built-in's */
```

Wich is underfined but in a different way than the reduced testcase.

[Bug tree-optimization/113520] ICE when building swi-prolog-9.1.2 with LTO (tree check: expected array_type, have integer_type in array_ref_low_bound)

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

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

--- Comment #2 from Andrew Pinski  ---
This code is definitely undefined.

Is builtin_names really defined as an array in one TU but an int in another
one?

[Bug debug/113519] [14 Regression] ICE: in replace_child, at dwarf2out.cc:5704 with -g -fdebug-types-section -fsso-struct=big-endian (or little-endian if the target is big-endian)

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2024-01-20
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Keywords||needs-bisection

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

Note the assert is NOT a checking assert so it is not just masked due to
release checking ...

[Bug debug/113519] [14 Regression] ICE: in replace_child, at dwarf2out.cc:5704 with -g -fdebug-types-section -fsso-struct=big-endian (or little-endian if the target is big-endian)

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|ICE: in replace_child, at   |[14 Regression] ICE: in
   |dwarf2out.cc:5704 with -g   |replace_child, at
   |-mbig-endian|dwarf2out.cc:5704 with -g
   |-fsso-struct=little-endian  |-fdebug-types-section
   |-fdebug-types-section   |-fsso-struct=big-endian (or
   ||little-endian if the target
   ||is big-endian)
 Target|riscv64-unknown-linux-gnu   |x86_64-pc-linux-gnu
   Target Milestone|--- |14.0

--- Comment #1 from Andrew Pinski  ---
Can be reproduced on x86_64-linux with just ` -g -fsso-struct=big-endian
-fdebug-types-section`

[Bug tree-optimization/113520] ICE when building swi-prolog-9.1.2 with LTO (tree check: expected array_type, have integer_type in array_ref_low_bound)

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

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

--- Comment #1 from Sam James  ---
10/11/12/13/14 all reproduce it for me

[Bug tree-optimization/113520] New: ICE when building swi-prolog-9.1.2 with LTO (tree check: expected array_type, have integer_type in array_ref_low_bound)

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

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

Bug ID: 113520
   Summary: ICE when building swi-prolog-9.1.2 with LTO (tree
check: expected array_type, have integer_type in
array_ref_low_bound)
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sjames at gcc dot gnu.org
CC: arsen at gcc dot gnu.org
  Target Milestone: ---

Arsen mentioned this to me earlier so I looked at reducing it.

ICEs when building swi-prolog-9.1.2 with LTO.

passing.c.i:
```
typedef void Any;
int get_table, getGetMethodClass_class;
extern int builtin_names[];
Any getResolveGetMethodClass();
static Any getGetMethodClass(int *name) {
  getResolveGetMethodClass(get_table);
  getResolveGetMethodClass(getGetMethodClass_class, name);
}
void pceResolveImplementation() { getGetMethodClass(_names[1]); }
```

name.c.i
```
int builtin_names;
```

```
$ gcc -flto -O3  passing.c.i name.c.i -shared
during GIMPLE pass: alias
passing.c.i: In function ‘pceResolveImplementation’:
passing.c.i:9:6: internal compiler error: tree check: expected array_type, have
integer_type in array_ref_low_bound, at tree.cc:12851
9 | void pceResolveImplementation() { getGetMethodClass(_names[1]);
}
  |  ^
0x5653e7eb8b8c tree_check_failed(tree_node const*, char const*, int, char
const*, ...)
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree.cc:8952
0x5653e71ee414 tree_check(tree_node*, char const*, int, char const*, tree_code)
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree.h:3612
0x5653e71ee414 array_ref_low_bound(tree_node*)
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree.cc:12851
0x5653e88640b8 get_ref_base_and_extent(tree_node*, poly_int<1u, long>*,
poly_int<1u, long>*, poly_int<1u, long>*, bool*)
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-dfa.cc:497
0x5653e8973a07 get_constraint_for_component_ref
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-ssa-structalias.cc:3319
0x5653e8973a07 get_constraint_for_1(tree_node*, vec*, bool, bool) [clone .isra.0]
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-ssa-structalias.cc:3634
0x5653e89738aa get_constraint_for_address_of
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-ssa-structalias.cc:3502
0x5653e89738aa get_constraint_for_1(tree_node*, vec*, bool, bool) [clone .isra.0]
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-ssa-structalias.cc:3570
0x5653e89ca9d7 get_constraint_for_rhs
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-ssa-structalias.cc:3719
0x5653e89ca9d7 make_constraint_to
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-ssa-structalias.cc:3848
0x5653e89ca9d7 handle_call_arg
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-ssa-structalias.cc:4100
0x5653e89a7bcc handle_rhs_call
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-ssa-structalias.cc:4344
0x5653e8971603 find_func_aliases_for_call
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-ssa-structalias.cc:5018
0x5653e8971603 find_func_aliases
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-ssa-structalias.cc:5121
0x5653e896b1d7 compute_points_to_sets
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-ssa-structalias.cc:7573
0x5653e896b1d7 compute_may_aliases()
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/tree-ssa-structalias.cc:8027
0x5653e8722af3 execute_function_todo
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/passes.cc:2063
0x5653e8722af3 do_per_function
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/passes.cc:1687
0x5653e8722af3 execute_todo
   
/usr/src/debug/sys-devel/gcc-14.0.1./gcc-14.0.1./gcc/passes.cc:2142
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.
lto-wrapper: fatal error: gcc returned 1 exit status
compilation terminated.
/usr/lib/gcc/x86_64-pc-linux-gnu/14/../../../../x86_64-pc-linux-gnu/bin/ld:
error: lto-wrapper failed
collect2: error: ld returned 1 exit status
```

[Bug c/113492] [14 Regression] ICE: in composite_type_internal, at c/c-typeck.cc:557 with -std=c2x -funsigned-bitfields since r14-6808

2024-01-19 Thread zsojka at seznam dot cz via Gcc-bugs

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

--- Comment #3 from Zdenek Sojka  ---
(In reply to uecker from comment #2)
> 
> I agree that "int:3" with -funsigned-bitfields should produce a type which
> is compatible to one  with "unsigned:3" and that forming a composite type
> has to work.
> 
> I am not entirely sure this should be considered a regression as this C23
> feature did not exist before (but was rejected and did not ICE).  Anyway, I
> will look at this and post a patch. Thanks for reporting.

Thank you for having a look.

The "regression" part is for the ICEing.

[Bug debug/113519] New: ICE: in replace_child, at dwarf2out.cc:5704 with -g -mbig-endian -fsso-struct=little-endian -fdebug-types-section

2024-01-19 Thread zsojka at seznam dot cz via Gcc-bugs

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

Bug ID: 113519
   Summary: ICE: in replace_child, at dwarf2out.cc:5704 with -g
-mbig-endian -fsso-struct=little-endian
-fdebug-types-section
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu

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

Compiler output:
$ riscv64-unknown-linux-gnu-gcc -g -mbig-endian -fsso-struct=little-endian
-fdebug-types-section testcase.c 
testcase.c:4:1: internal compiler error: in replace_child, at dwarf2out.cc:5704
4 | } s;
  | ^
0xa15089 replace_child
/repo/gcc-trunk/gcc/dwarf2out.cc:5704
0x123fd37 remove_child_or_replace_with_skeleton
/repo/gcc-trunk/gcc/dwarf2out.cc:8625
0x123fd37 break_out_comdat_types
/repo/gcc-trunk/gcc/dwarf2out.cc:8772
0x126da3d dwarf2out_early_finish
/repo/gcc-trunk/gcc/dwarf2out.cc:33096
0x11cb11f symbol_table::finalize_compilation_unit()
/repo/gcc-trunk/gcc/cgraphunit.cc:2579
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.

$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8284-20240119180625-g54519030b05-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/14.0.1/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-isa-spec=2.2
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8284-20240119180625-g54519030b05-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240119 (experimental) (GCC)

[Bug tree-optimization/113518] New: ICE: in gimplify_expr, at gimplify.cc:18596 with atomic_fetch_or_explicit() on _BitInt()

2024-01-19 Thread zsojka at seznam dot cz via Gcc-bugs

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

Bug ID: 113518
   Summary: ICE: in gimplify_expr, at gimplify.cc:18596 with
atomic_fetch_or_explicit() on _BitInt()
   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 57170
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57170=edit
reduced testcase (from gcc.target/i386/pr102566-2.c)

Compiler output:
$ x86_64-pc-linux-gnu-gcc testcase.c
In file included from testcase.c:1:
testcase.c: In function 'foo':
testcase.c:8:34: internal compiler error: in gimplify_expr, at
gimplify.cc:18596
8 |   atomic_fetch_or_explicit(, 1 << 31, memory_order_relaxed);
  |  ^
0x78cb81 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:18596
0x11a66a6 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:18085
0x11a62ef gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:18568
0x11bcae5 gimplify_modify_expr
/repo/gcc-trunk/gcc/gimplify.cc:6405
0x11a6489 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:17780
0x11b4b29 gimplify_target_expr
/repo/gcc-trunk/gcc/gimplify.cc:7399
0x11a66e0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:18177
0x11a8b76 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:7480
0x11a74e0 gimplify_statement_list
/repo/gcc-trunk/gcc/gimplify.cc:
0x11a74e0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:18225
0x11b4ced gimplify_target_expr
/repo/gcc-trunk/gcc/gimplify.cc:7393
0x11a66e0 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:18177
0x11a8b76 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:7480
0x11a9c79 gimplify_bind_expr
/repo/gcc-trunk/gcc/gimplify.cc:1614
0x11a71f7 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
/repo/gcc-trunk/gcc/gimplify.cc:17981
0x11bde24 gimplify_stmt(tree_node**, gimple**)
/repo/gcc-trunk/gcc/gimplify.cc:7480
0x11bde24 gimplify_body(tree_node*, bool)
/repo/gcc-trunk/gcc/gimplify.cc:19047
0x11be24a gimplify_function_tree(tree_node*)
/repo/gcc-trunk/gcc/gimplify.cc:19246
0xfcd037 cgraph_node::analyze()
/repo/gcc-trunk/gcc/cgraphunit.cc:685
0xfcf957 analyze_functions
/repo/gcc-trunk/gcc/cgraphunit.cc:1248
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-8284-20240119180625-g54519030b05-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 --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8284-20240119180625-g54519030b05-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240119 (experimental) (GCC)

[Bug libstdc++/107603] checking for ld that supports -Wl,--gc-sections... configure: error: Link tests are not allowed after GCC_NO_EXECUTABLES. for i686-w64-mingw32 target at canadian compilation

2024-01-19 Thread nightstrike at gmail dot com via Gcc-bugs

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #2 from nightstrike  ---
That config.log output isn't in the attached file.  I think you attached the
top level config.log and not the libstdc++ config.log.  Can you try again?

[Bug target/113517] New: vector SLP cost model should be improved

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

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

Bug ID: 113517
   Summary: vector SLP cost model should be improved
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---
Target: aarch64

Take:
```
void f(short *a, signed int *b)
{
int sum = 0;
sum += a[0];
sum += a[1];
sum += a[2];
sum += a[3];
*b = sum;
}
```

Right now by default this produces:
```
ldrsh   w3, [x0]
ldrsh   w4, [x0, 2]
ldrsh   w2, [x0, 4]
add w3, w3, w4
ldrsh   w0, [x0, 6]
add w2, w2, w3
add w0, w0, w2
str w0, [x1]
```

But disabling the cost model we get:
```
ldr d31, [x0]
saddlv  s31, v31.4h
str s31, [x1]
ret
```

(note this is better code generation than what LLVM produces as that uses
sshll/addv ).

For most cores, doing a float (vector) load and one vector instruction and one
vector store is better than doing 4 scalar loads and 3 scalar instructions and
one scalar store.  This is true on even ThunderX 1 and Cortex-A57.

[Bug target/59425] ICE - seg fault building ISL on Windows

2024-01-19 Thread nightstrike at gmail dot com via Gcc-bugs

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

nightstrike  changed:

   What|Removed |Added

 CC||nightstrike at gmail dot com

--- Comment #2 from nightstrike  ---
The preprocessed source works for me in 13.  Can you verify if this is still an
issue?

[Bug ada/113516] New: POLLPRI redefined on windows building ada

2024-01-19 Thread nightstrike at gmail dot com via Gcc-bugs

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

Bug ID: 113516
   Summary: POLLPRI redefined on windows building ada
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ada
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nightstrike at gmail dot com
CC: dkm at gcc dot gnu.org
  Target Milestone: ---

g:r11-4313-gd08d481912b9a2 defined POLLPRI to zero on Windows, stating in the
commit message "Define POLLPRI as zero on Windows as it is not supported
there."  However, it is defined on mingw-w64 targets, resulting in a build
warning:

/tmp/gcc/src/gcc-git/gcc/ada/s-oscons-tmplt.c:1871:9: warning: "POLLPRI"
redefined
 1871 | #define POLLPRI 0
  | ^~~
In file included from /tmp/gcc/src/gcc-git/gcc/ada/gsocket.h:83,
 from /tmp/gcc/src/gcc-git/gcc/ada/s-oscons-tmplt.c:103:
/tmp/rt/mingw14/x86_64-w64-mingw32/include/winsock2.h:1182:9: note: this is the
location of the previous definition
 1182 | #define POLLPRI0x0400
  | ^~~

[Bug c/102998] Wrong documentation for -Warray-parameter

2024-01-19 Thread sandra at gcc dot gnu.org via Gcc-bugs

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

--- Comment #4 from sandra at gcc dot gnu.org ---
Hmmm, I ran into PR113515 with this example.

[Bug c/113515] New: Wrong documentation for -Wstringop-overflow

2024-01-19 Thread sandra at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 113515
   Summary: Wrong documentation for -Wstringop-overflow
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: sandra at gcc dot gnu.org
  Target Milestone: ---

This is essentially the example for -Warray-parameter=1 in the manual (see
PR102998):

#include 

void f (int[static 4]);
void f (int[]);  // warning 1

void g (void)
{
  int *p = (int *) malloc (1 * sizeof(int));
  f (p);   // warning 2
}

Warning 2 is:

example.c: In function 'g':
example.c:9:3: warning: 'f' accessing 16 bytes in a region of size 4
[-Wstringop-overflow=]
9 |   f (p);
  |   ^
example.c:9:3: note: referencing argument 1 of type 'int[4]'
example.c:4:6: note: in a call to function 'f'
4 | void f (int[]);
  |  ^

It's correct to warn here, but the manual is not helpful in explaining what
-Wstringop-overflow has to do with it.

The documentation for -Wstringop-overflow says:

Warn for calls to string manipulation functions such as @code{memcpy} and
@code{strcpy} that are determined to overflow the destination buffer.

There are no string manipulation functions in this example.  I presume
additional kinds of object-size checking, beyond calls to string/byte array
manipulation functions from the standard library, were overloaded onto this
option without updating its description.  Can we get a better summary of what
it does now?

[Bug middle-end/113514] Wrong __builtin_dynamic_object_size when using a set local variable

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

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

--- Comment #4 from Sam James  ---
Siddhesh, there's some discussion at
https://github.com/llvm/llvm-project/pull/78526 as to what the GCC behaviour is
supposed to be vs documented.

[Bug middle-end/113514] Wrong __builtin_dynamic_object_size when using a set local variable

2024-01-19 Thread isanbard at gmail dot com via Gcc-bugs

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

--- Comment #3 from Bill Wendling  ---
(In reply to Andrew Pinski from comment #1)
> The answer is not really and it is complex.
> 
Okay. It just seems counter-intuitive.

> So I will note that clang/LLVM returns 48 for `f.bar[argc], 1` and 0 for
> `,3`.

Yeah. I'm trying to fix that, but the consensus is that returning the maximum
value of the whole object (not sub-object) when the LSB is set is okay due to
this in the documentation:

> If there are multiple objects ptr can point to and all of them are known at 
> compile time, the returned number is the maximum of remaining byte counts in 
> those objects if type & 2 is 0 and minimum if nonzero.

Note, I don't agree with that viewpoint.

[Bug c/102998] Wrong documentation for -Warray-parameter

2024-01-19 Thread sandra at gcc dot gnu.org via Gcc-bugs

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

sandra at gcc dot gnu.org changed:

   What|Removed |Added

 CC||sandra at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |sandra at gcc dot 
gnu.org

--- Comment #3 from sandra at gcc dot gnu.org ---
The argument to malloc is 4, but it's given in bytes, not array elements.  I
can tweak this example to make it more clear that the array is too small.

There are other problems here too; -Warray-parameter isn't listed in the
Options Summary section, it doesn't say what N defaults to if you omit it, or 
that the negative form is equivalent to -Warray-parameter=0.

[Bug target/113458] Missed SLP for reduction of multiplication/addition with promotion

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

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

--- Comment #9 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #8)
> (In reply to Andrew Pinski from comment #7) 
> > But the load is still using inserts and tbl. I have not figured out why
> > though.
> 
> Looks like I have to support const PERMs.

Which I have enough supported.  Now on to the cost model.
I do get some testsuite failures which means I need to add more support
instruction for the V4QI mode but it is a good start too.

[Bug middle-end/113514] Wrong __builtin_dynamic_object_size when using a set local variable

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

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

--- Comment #2 from Andrew Pinski  ---
In the case of the constant proping into `[argc][0]`, it is not know if
you are doing an offset of the original struct or an offset into the array.
GCC's internal IR changes into the former as it is more canonical form while
with the constant already there is known at front-end time.

With respect of a non-constant one, GCC's IR keeps the array form address
around which allows the answer of still 40.

I can't explain clang/LLVM's behavior for `,3` though.

[Bug middle-end/113514] Wrong __builtin_dynamic_object_size when using a set local variable

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

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

--- Comment #1 from Andrew Pinski  ---
The answer is not really and it is complex.

So I will note that clang/LLVM returns 48 for `f.bar[argc], 1` and 0 for `,3`.

[Bug c/113514] New: Wrong __builtin_dynamic_object_size when using a set local variable

2024-01-19 Thread isanbard at gmail dot com via Gcc-bugs

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

Bug ID: 113514
   Summary: Wrong __builtin_dynamic_object_size when using a set
local variable
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: isanbard at gmail dot com
  Target Milestone: ---

There appears to be an issue with __builtin_dynamic_object_size() when using a
local variable. The following code should output 40 for each __bdos call:

$ cat test.c
#include 

struct s {
int a, b, c, d;
int  foo;
#define IDX 2
int blue;
char bar[IDX][40];
int  baz;
int  qux;
};

int main(int argc, char **argv) {
struct s f;

#define report(x) fprintf(stderr, #x ": %zu\n", x)

report(__builtin_dynamic_object_size(f.bar[1], 1));
report(__builtin_dynamic_object_size(f.bar[1], 3));

report(__builtin_dynamic_object_size(f.bar[argc], 1));
report(__builtin_dynamic_object_size(f.bar[argc], 3));

argc = 1;
report(__builtin_dynamic_object_size(f.bar[argc], 1));
report(__builtin_dynamic_object_size(f.bar[argc], 3));

return 0;
}

However, the last two print 48:

$ gcc -O2 test.c && a.out
__builtin_dynamic_object_size(f.bar[1], 1): 40
__builtin_dynamic_object_size(f.bar[1], 3): 40
__builtin_dynamic_object_size(f.bar[argc], 1): 40
__builtin_dynamic_object_size(f.bar[argc], 3): 40
__builtin_dynamic_object_size(f.bar[argc], 1): 48
__builtin_dynamic_object_size(f.bar[argc], 3): 48

[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes

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

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

--- Comment #13 from Marek Polacek  ---
*** Bug 59 has been marked as a duplicate of this bug. ***

[Bug c++/111159] [13/14 Regression] False positive -Wdangling-reference

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #2 from Marek Polacek  ---
I think so too; I'm afraid there's no heuristic I could implement.  You can
disable the warning for this class using:

#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdangling-reference"
struct A {
  int * i;
  int & b() { return *i; }
};
#pragma GCC diagnostic pop

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

[Bug libgomp/113513] New: [OpenMP] libgomp: cuCtxGetDevice error with OMP_DISPLAY_ENV=true OMP_TARGET_OFFLOAD="mandatory" for libgomp.c/target-52.c

2024-01-19 Thread burnus at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 113513
   Summary: [OpenMP] libgomp: cuCtxGetDevice error with
OMP_DISPLAY_ENV=true OMP_TARGET_OFFLOAD="mandatory"
for libgomp.c/target-52.c
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: openmp, wrong-code
  Severity: normal
  Priority: P3
 Component: libgomp
  Assignee: unassigned at gcc dot gnu.org
  Reporter: burnus at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, tschwinge at gcc dot gnu.org
  Target Milestone: ---

When using both OMP_DISPLAY_ENV=true and OMP_TARGET_OFFLOAD="mandatory", the
device has to be initiated early as OMP_DEFAULT_DEVICE (either 0 or -4 =
omp_invalid_device) needs to be known before printing the ICVs.

On my system, this causes
  libgomp: cuCtxGetDevice error: unknown cuda error.

That's with "CUDA Version: 12.3" and "NVIDIA RTX A1000 6GB" with
--with-arch=sm_80.

I am somewhat sure that I have manually tested it before; our tester wasn't
able to remotely set the env vars, hence, I don't know whether it did work
there or not - nor whether it is a regression, depends on CUDA, sm_xx, my card
or ...

[Bug target/108640] ICE compiling busybox for m68k in change_address_1, at emit-rtl.cc:2283

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||law at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #9 from Jeffrey A. Law  ---
Fixed on the trunk.  No plans to backport.

[Bug target/110934] m68k: ICE with -fzero-call-used-regs=all compiling openssh 9.3p2

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

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

Jeffrey A. Law  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 CC||law at gcc dot gnu.org
 Status|NEW |RESOLVED

--- Comment #14 from Jeffrey A. Law  ---
Fixed on the trunk.  No plans to backport.

[Bug target/110934] m68k: ICE with -fzero-call-used-regs=all compiling openssh 9.3p2

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

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

--- Comment #13 from GCC Commits  ---
The master branch has been updated by Jeff Law :

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

commit r14-8299-gf1dea0fed946ba40bd6bbe40ad1386aa9303418c
Author: Mikael Pettersson 
Date:   Fri Jan 19 16:23:34 2024 -0700

[PATCH] Avoid ICE on m68k -fzero-call-used-regs -fpic [PR110934]

PR110934 is a problem on m68k where -fzero-call-used-regs -fpic ICEs
when clearing an FP register.

The generic code generates an XFmode move of zero to that register,
which becomes an XFmode load from initialized data, which due to -fpic
uses a non-constant address, which the backend rejects.  The
zero-call-used-regs pass runs very late, after register allocation and
frame layout, and at that point we can't allow new uses of the PIC
register or new pseudos.

To clear an FP register on m68k it's enough to do the move in SFmode,
but the generic code can't be told to do that, so this patch updates
m68k to use its own TARGET_ZERO_CALL_USED_REGS.

Bootstrapped and regression tested on m68k-linux-gnu.

Ok for master? (I don't have commit rights.)

gcc/

PR target/110934
* config/m68k/m68k.cc (m68k_zero_call_used_regs): New function.
(TARGET_ZERO_CALL_USED_REGS): Define.

gcc/testsuite/

PR target/110934
* gcc.target/m68k/pr110934.c: New test.

[Bug libstdc++/113512] Incorrect results for std::format("{:#.3g}", flt)

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org
   Last reconfirmed||2024-01-19
 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Target Milestone|--- |13.3

[Bug libstdc++/113512] New: Incorrect results for std::format("{:#.3g}", flt)

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

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

Bug ID: 113512
   Summary: Incorrect results for std::format("{:#.3g}", flt)
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

std::format("{:#.3g}", 0.02) should give 3 significant figures, i.e. "0.0200"

But libstdc++ counts the leading zeros as significant, so gives "0.02"

std::format("{:#.3g}", 0.025) should give "0.0250" but instead throws an
exception!

[Bug modula2/113511] New: lack of libm2 ABI compatibility on powerpc platforms

2024-01-19 Thread gaius at gcc dot gnu.org via Gcc-bugs

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

Bug ID: 113511
   Summary: lack of libm2 ABI compatibility on powerpc platforms
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: modula2
  Assignee: gaius at gcc dot gnu.org
  Reporter: gaius at gcc dot gnu.org
  Target Milestone: ---

Following on from PR111956 gm2 can generate objects using -mabi=ibmlongdouble
and -mabi=ieeelongdouble.  However it only links to the libgm2 generated using
the
--with-long-double-128 and --with-long-double-format flags selected during
configure.

[Bug target/108640] ICE compiling busybox for m68k in change_address_1, at emit-rtl.cc:2283

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

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

--- Comment #8 from GCC Commits  ---
The master branch has been updated by Jeff Law :

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

commit r14-8298-ga834414794d80f21550dd0591e260fc833f49eb9
Author: Mikael Pettersson 
Date:   Fri Jan 19 16:05:34 2024 -0700

[PATCH] Avoid ICE in single-bit logical RMWs on m68k-uclinux [PR108640]

When generating RMW logical operations on m68k, the backend
recognizes single-bit operations and rewrites them as bit
instructions on operands adjusted to address the intended byte.
When offsetting the addresses the backend keeps the modes as
SImode, even though the actual access will be in QImode.

The uclinux target defines M68K_OFFSETS_MUST_BE_WITHIN_SECTIONS_P
which adds a check that the adjusted operand is within the bounds
of the original object.  Since the address has been offset it is
not, and the compiler ICEs.

The bug is that the modes of the adjusted operands should have been
narrowed to QImode, which is that this patch does.  Nearby code
which narrows to HImode gets that right.

Bootstrapped and regression tested on m68k-linux-gnu.

Ok for master? (Note: I don't have commit rights.)

gcc/

PR target/108640
* config/m68k/m68k.cc (output_andsi3): Use QImode for
address adjusted for 1-byte RMW access.
(output_iorsi3): Likewise.
(output_xorsi3): Likewise.

gcc/testsuite/

PR target/108640
* gcc.target/m68k/pr108640.c: New test.

[Bug rtl-optimization/113510] [ARM Thumb] ICE in extract_constrain_insn with CPU cortex-m23

2024-01-19 Thread thiago.bauermann at linaro dot org via Gcc-bugs

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

Thiago Jung Bauermann  changed:

   What|Removed |Added

 CC||thiago.bauermann at linaro dot 
org

--- Comment #2 from Thiago Jung Bauermann  
---
Created attachment 57169
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57169=edit
Testsuite log from today's trunk with both testcases failing.

I said I was going to send gcc.sum but on second thought, I think gcc.log is
sufficient.

[Bug rtl-optimization/113510] [ARM Thumb] ICE in extract_constrain_insn with CPU cortex-m23

2024-01-19 Thread thiago.bauermann at linaro dot org via Gcc-bugs

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

--- Comment #1 from Thiago Jung Bauermann  
---
Created attachment 57168
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57168=edit
Preprocessed version of pr71494.c

[Bug target/113458] Missed SLP for reduction of multiplication/addition with promotion

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

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

--- Comment #8 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #7) 
> But the load is still using inserts and tbl. I have not figured out why
> though.

Looks like I have to support const PERMs.

[Bug rtl-optimization/113510] New: [ARM Thumb] ICE in extract_constrain_insn with CPU cortex-m23

2024-01-19 Thread thiago.bauermann at linaro dot org via Gcc-bugs

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

Bug ID: 113510
   Summary: [ARM Thumb] ICE in extract_constrain_insn with CPU
cortex-m23
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: thiago.bauermann at linaro dot org
  Target Milestone: ---

Created attachment 57167
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57167=edit
Preprocessed version of nested-3.c

After commit a729b6e002fe ("[PR112918][LRA]: Fixing IRA ICE on m68k"), the
following failures started appearing on --target=arm-none-eabi
--with-mode=thumb --with-cpu=cortex-m23:

=== gcc tests ===

Running gcc:gcc.c-torture/compile/compile.exp ...
FAIL: gcc.c-torture/compile/nested-3.c -O2  (internal compiler error: in
extract_constrain_insn, at recog.cc:2713)
FAIL: gcc.c-torture/compile/nested-3.c -O2  (test for excess errors)
FAIL: gcc.c-torture/compile/nested-3.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error: in extract_constrain_insn, at
recog.cc:2713)
FAIL: gcc.c-torture/compile/nested-3.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
FAIL: gcc.c-torture/compile/nested-3.c -O3 -g  (internal compiler error: in
extract_constrain_insn, at recog.cc:2713)
FAIL: gcc.c-torture/compile/nested-3.c -O3 -g  (test for excess errors)
FAIL: gcc.c-torture/compile/nested-3.c -Os  (internal compiler error: in
extract_constrain_insn, at recog.cc:2713)
FAIL: gcc.c-torture/compile/nested-3.c -Os  (test for excess errors)

Running gcc:gcc.c-torture/execute/execute.exp ...
FAIL: gcc.c-torture/execute/pr71494.c -O2  (internal compiler error: in
extract_constrain_insn, at recog.cc:2713)
FAIL: gcc.c-torture/execute/pr71494.c -O2  (test for excess errors)
UNRESOLVED: gcc.c-torture/execute/pr71494.c -O2  compilation failed to produce
executable
FAIL: gcc.c-torture/execute/pr71494.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (internal compiler error: in extract_constrain_insn, at
recog.cc:2713)
FAIL: gcc.c-torture/execute/pr71494.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none  (test for excess errors)
UNRESOLVED: gcc.c-torture/execute/pr71494.c -O2 -flto -fno-use-linker-plugin
-flto-partition=none  compilation failed to produce executable
FAIL: gcc.c-torture/execute/pr71494.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (internal compiler error: in extract_constrain_insn, at
recog.cc:2713)
FAIL: gcc.c-torture/execute/pr71494.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  (test for excess errors)
UNRESOLVED: gcc.c-torture/execute/pr71494.c -O2 -flto -fuse-linker-plugin
-fno-fat-lto-objects  compilation failed to produce executable
FAIL: gcc.c-torture/execute/pr71494.c -O3 -g  (internal compiler error: in
extract_constrain_insn, at recog.cc:2713)
FAIL: gcc.c-torture/execute/pr71494.c -O3 -g  (test for excess errors)
UNRESOLVED: gcc.c-torture/execute/pr71494.c -O3 -g  compilation failed to
produce executable
FAIL: gcc.c-torture/execute/pr71494.c -Os  (internal compiler error: in
extract_constrain_insn, at recog.cc:2713)
FAIL: gcc.c-torture/execute/pr71494.c -Os  (test for excess errors)
UNRESOLVED: gcc.c-torture/execute/pr71494.c -Os  compilation failed to produce
executable

I tested on today's trunk (commit 07b392550f37) and the failures are still
present. I'm attaching the gcc.{sum,log} files, and also the .i file that
causes the ICE.

Here's how to reproduce on an x86_64-linux machine:

1. First, create a combined tree:

$ mkdir /tmp/combined-tree-src /tmp/combined-tree-build
$ cd ~/src/newlib-cygwin && find . -print | cpio -pdlm /tmp/combined-tree-src
$ cd ~/src/binutils-gdb && find . -print | cpio -pdlmu /tmp/combined-tree-src
$ cd ~/src/gcc && find . -print | cpio -pdlmu /tmp/combined-tree-src

2. Then build and install the cross GCC:

$ cd /tmp/combined-tree-build
$ /tmp/combined-tree-src/configure \
SHELL=/bin/bash \
--with-gnu-as \
--with-gnu-ld \
--disable-libmudflap \
--enable-lto \
--enable-shared \
--without-included-gettext \
--enable-nls \
--with-system-zlib \
--disable-sjlj-exceptions \
--enable-gnu-unique-object \
--enable-linker-build-id \
--disable-libstdcxx-pch \
--enable-c99 \
--enable-clocale=gnu \
--enable-libstdcxx-debug \
--enable-long-long \
--with-cloog=no \
--with-ppl=no \
--with-isl=no \
--enable-threads=no \
--disable-multiarch \
--disable-multilib \
--with-mode=thumb \
--with-cpu=cortex-m23 \
--with-float=soft \
--with-newlib \
--with-headers=yes \
--with-native-system-header-dir=/include \
--enable-checking=yes \
--disable-bootstrap \
--enable-languages=c,lto \
--prefix=/tmp/arm-none-eabi \
--build=x86_64-pc-linux-gnu \
--host=x86_64-pc-linux-gnu \

[Bug fortran/113471] [14 regression] wrong array bound check failure on valid code

2024-01-19 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #6 from anlauf at gcc dot gnu.org ---
Fixed.  Sorry for the breakage!

[Bug target/113458] Missed SLP for reduction of multiplication/addition with promotion

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

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

--- Comment #7 from Andrew Pinski  ---
I have a patch which implements V4QI for many operations (extends and
widden_sum) (though I need to fix the cost model).

I am able to get:
```
sshll   v30.4h, v30.8b, #0
smull   v31.4s, v31.4h, v30.4h
addvs31, v31.4s

```

But the load is still using inserts and tbl. I have not figured out why though.

[Bug libstdc++/113500] Using std::format with float or double based std::chrono::time_point causes error: no match for 'operator<<'

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

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

--- Comment #8 from Jonathan Wakely  ---
I am testing a patch that allows writing floating-point utc_time, gps_time etc.
with any format string, and allows writing floating-point sys_time with a
non-empty spec.

[Bug fortran/113377] Wrong code passing optional dummy argument to elemental procedure with optional dummy

2024-01-19 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from anlauf at gcc dot gnu.org ---
Created attachment 57166
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57166=edit
Testcase exercising passing of integer optional dummy arguments

This testcase passes with NAG and ifx with strict checking.

[Bug fortran/113377] Wrong code passing optional dummy argument to elemental procedure with optional dummy

2024-01-19 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #6)
> (In reply to anlauf from comment #4)
> > 
> > Note that the following scalar example also fails:
> > 
> "Fortunately", it is invalid.  :-)
> 
> From 15.5.2.12 (Argument presence and restrictions on arguments not present):
> 
> An optional dummy argument that is not present is subject to the following
> restrictions.
> (...)
>   (8) If it is allocatable, it shall not be allocated, deallocated, or
> supplied as an actual argument corresponding to an optional nonallocatable
> dummy argument.
> 
> In comment #4, j from one is non-present, allocatable, optional and passed
> to j from two which is optional nonallocatable.

Thanks for clarifying this.  This helps to reduce the testcases I am looking
at.

For the next step, I've actually stepped back a little: it helps to fix
the non-elemental cases first.  I am currently working with:

diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 9dd1f4086f4..52fdbd5ca66 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -6526,6 +6648,10 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
gfc_init_se (, NULL);
argse.want_pointer = 1;
gfc_conv_expr (, e);
+   if (e->symtree->n.sym->attr.dummy
+   && POINTER_TYPE_P (TREE_TYPE (argse.expr)))
+ argse.expr = gfc_build_addr_expr (NULL_TREE,
+   argse.expr);
cond = fold_convert (TREE_TYPE (argse.expr),
 null_pointer_node);
cond = fold_build2_loc (input_location, NE_EXPR,
@@ -7256,6 +7382,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
  && e->symtree->n.sym->attr.optional
  && (((e->rank != 0 && elemental_proc)
   || e->representation.length || e->ts.type == BT_CHARACTER
+  || (e->rank == 0 && fsym && fsym->as == NULL)
   || (e->rank != 0
   && (fsym == NULL
   || (fsym->as

I'll attach a testcase exercising this for integer dummies, but I have a
full set for other types at hand.

[Bug middle-end/113508] widen_ssumm3 documentation needs to mention which mode is m here

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

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

--- Comment #1 from Andrew Pinski  ---
The current documentation reads:
```
Operands 0 and 2 are of the same mode, which is wider than the mode of operand
1. Add operand 1 to operand 2 and place the widened result in operand 0. (This
is used express accumulation of elements into an accumulator of a wider mode.)
```

The m mode here  is the smaller mode.

So it would be better if it read:
```
Operands 0 and 2 are of the same mode, which is wider than the mode (m) of
operand 1. Add operand 1 to operand 2 and place the widened result in operand
0. (This is used express accumulation of elements into an accumulator of a
wider mode.)
```

All of the other ones are still the smaller mode too.

[Bug analyzer/113509] New: ICE: SIGSEGV in c_tree_printer (c-objc-common.cc:341) with -fanalyzer -fanalyzer-verbose-state-changes

2024-01-19 Thread zsojka at seznam dot cz via Gcc-bugs

unk//binary-trunk-r14-8284-20240119180625-g54519030b05-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240119 (experimental) (GCC)

[Bug fortran/113471] [14 regression] wrong array bound check failure on valid code

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

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

--- Comment #5 from GCC Commits  ---
The master branch has been updated by Harald Anlauf :

https://gcc.gnu.org/g:94b2e6cb1cc4feb122bf77f19a657c97bffa9b42

commit r14-8295-g94b2e6cb1cc4feb122bf77f19a657c97bffa9b42
Author: Harald Anlauf 
Date:   Fri Jan 19 21:20:44 2024 +0100

Fortran: fix wrong array bounds check [PR113471]

gcc/fortran/ChangeLog:

PR fortran/113471
* trans-array.cc (array_bound_check_elemental): Array bounds check
shall apply here to elemental dimensions of an array section only.

gcc/testsuite/ChangeLog:

PR fortran/113471
* gfortran.dg/bounds_check_24.f90: New test.

[Bug target/109929] profiledbootstrap failure on aarch64-linux-gnu with graphite optimization

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

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

--- Comment #3 from Xi Ruoyao  ---
Hmm, it seems no longer happening with current trunk.

[Bug middle-end/113508] widen_ssumm3 documentation needs to mention which mode is m here

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
 Ever confirmed|0   |1
   Last reconfirmed||2024-01-19

[Bug middle-end/113508] New: widen_ssumm3 documentation needs to mention which mode is m here

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

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

Bug ID: 113508
   Summary: widen_ssumm3 documentation needs to mention which mode
is m here
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: pinskia at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Reading the documentation for widen_[us]summ3 (and [us]dot_prodm, ssadm at
least) does not say which mode is going to be the m. Is it the wider mode or
the narrow mode.


Filing this so I keep track of the issue. Will add what I find when I finish
and submit a patch.

[Bug c++/67898] rejects-valid on overloaded function as non-type template argument of dependent type

2024-01-19 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

   Target Milestone|12.0|14.0

--- Comment #7 from Jason Merrill  ---
Apparently I was confused, and my patch was also needed for the original
testcase.

[Bug c++/55004] [meta-bug] constexpr issues

2024-01-19 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Bug 111357 Summary: [11/12/13/14 Regression] __integer_pack fails to work with 
values of dependent type convertible to integers in noexcept context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111357

   What|Removed |Added

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

[Bug c++/111357] [11/12/13/14 Regression] __integer_pack fails to work with values of dependent type convertible to integers in noexcept context

2024-01-19 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #14 from Jason Merrill  ---
The library pattern is fixed on all branches; the built-in doesn't need to be.

[Bug fortran/113377] Wrong code passing optional dummy argument to elemental procedure with optional dummy

2024-01-19 Thread mikael at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Mikael Morin  ---
(In reply to anlauf from comment #4)
> 
> Note that the following scalar example also fails:
> 
"Fortunately", it is invalid.  :-)

>From 15.5.2.12 (Argument presence and restrictions on arguments not present):

An optional dummy argument that is not present is subject to the following
restrictions.
(...)
  (8) If it is allocatable, it shall not be allocated, deallocated, or supplied
as an actual argument corresponding to an optional nonallocatable dummy
argument.

In comment #4, j from one is non-present, allocatable, optional and passed to j
from two which is optional nonallocatable.

[Bug c++/113498] [14 regression] ICE in GCC trunk: tree check: have using_decl in get_template_info, at cp/pt.cc:357 since r14-6064

2024-01-19 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #5 from Jason Merrill  ---
Fixed.

[Bug c++/113498] [14 regression] ICE in GCC trunk: tree check: have using_decl in get_template_info, at cp/pt.cc:357 since r14-6064

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

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

--- Comment #4 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

https://gcc.gnu.org/g:1338ad23ff3c1e4f552cdb64e36cef12eda2e050

commit r14-8294-g1338ad23ff3c1e4f552cdb64e36cef12eda2e050
Author: Jason Merrill 
Date:   Fri Jan 19 13:11:05 2024 -0500

c++: requires and using-decl [PR113498]

get_template_info was crashing because it assumed that any decl with
DECL_LANG_SPECIFIC could use DECL_TEMPLATE_INFO.  It's more complicated
than
that.

PR c++/113498

gcc/cp/ChangeLog:

* pt.cc (decl_template_info): New fn.
(get_template_info): Use it.

gcc/testsuite/ChangeLog:

* g++.dg/cpp2a/concepts-using4.C: New test.

[Bug libstdc++/108822] [C++23] Implement P2255R2, type trait to detect reference binding to temporary

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

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

--- Comment #7 from GCC Commits  ---
The master branch has been updated by Jonathan Wakely :

https://gcc.gnu.org/g:502a3c03e40e8920afb734c077b045f6c5efd087

commit r14-8292-g502a3c03e40e8920afb734c077b045f6c5efd087
Author: Jonathan Wakely 
Date:   Fri Jan 19 12:28:30 2024 +

libstdc++: Fix P2255R2 dangling checks for std::tuple in C++17 [PR108822]

I accidentally used && in a fold-expression instead of || which meant
that in C++17 the tuple(UElements&&...) constructor only failed its
debug assertion if all tuple elements were dangling references. Some
missing tests (noted as "TODO") meant this wasn't tested.

This fixes the fold expression and adds the missing tests.

libstdc++-v3/ChangeLog:

PR libstdc++/108822
* include/std/tuple (__glibcxx_no_dangling_refs) [C++17]: Fix
wrong fold-operator.
* testsuite/20_util/tuple/dangling_ref.cc: Check tuples with one
element and three elements. Check allocator-extended
constructors.

[Bug c++/87724] gcc allows narrowing conversions in converted constant expressions

2024-01-19 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

 Resolution|--- |INVALID
 CC||jason at gcc dot gnu.org
 Status|SUSPENDED   |RESOLVED

--- Comment #2 from Jason Merrill  ---
The standard has been corrected by P1401 to allow these conversions.

[Bug c++/95564] GCC rejects lambda expression with "noexcept(1+1)"

2024-01-19 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
(In reply to Jiang An from comment #3)
> (In reply to Andrew Pinski from comment #2)
> > GCC is inconsitent here. with static_assert and constexpr GCC accepts it (PR
> > 87724) while rejects it for noexcept.
> 
> Currently narrowing conversions are still forbidden in noexcept and explicit
> specifiers.
> 
> The inconsistency is acknowledged in C++23 (WG21-P1401R5), but it seems that
> P1401 is not a DR, as the related CWG 2320 is closed as extension. I don't
> know whether we should reject narrowing conversions in static_assert/if
> constexpr in earlier modes.

Narrowing conversions were fine in earlier standards, it was an accidental
change that made them ill-formed, which was fixed.

Clang now also rejects the testcase.

[Bug fortran/113377] Wrong code passing optional dummy argument to elemental procedure with optional dummy

2024-01-19 Thread mikael at gcc dot gnu.org via Gcc-bugs

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

--- Comment #5 from Mikael Morin  ---
(In reply to anlauf from comment #2)
> Note that adding a scalar call in function one:
> 
> r(1) = two (i(1), j)
> 
> generates sane code:
> 
>   *((integer(kind=4) *) __result.0 + (sizetype) ((offset.1 + NON_LVALUE_EXPR
> ) * 4)) = two (&(*i)[0], j != 0B ? *j : 0, j != 0B);
> 
> (...)
> 
> There is another observation: using the value attribute for j also in one,
> the scalar call from above becomes a straight
> 
>   *((integer(kind=4) *) __result.0 + (sizetype) ((offset.1 + NON_LVALUE_EXPR
> ) * 4)) = two (&(*i)[0], j, .j);
> 
> while the scalarizer produces:
> 
> integer(kind=4) * D.4340;
> ...
> D.4340 = 
> ...
>   *((integer(kind=4) *) __result.0 + (sizetype) ((S.3 * D.4342 +
> D.4339) * 4)) = two (&(*i)[S.3 + -1], *D.4340);
> 
> which looks more complicated (besides being wrong...)

Wrong I agree, but is it really more complicated?


(In reply to anlauf from comment #3)
> Created attachment 57108 [details]
> Patch to play with
> 
> This is a first attempt to outline code for handling scalar dummies with the
> VALUE attribute.
> 
> This fixes the following variants of the declaration of dummy argument j
> in function one:
> 
> integer, value,  optional :: j
> integer, intent(in), optional :: j
> integer, intent(in), optional :: j(4)
> integer, intent(in), optional :: j(:)
> 
Looks promising, maybe push a fix for just these cases as a first step?

> However,
> 
> integer, allocatable,optional :: j
> 
Allocatable AND optional?
The standard seems to accept those, but do we support them?
... (searches) ...
Alright, we have some in the testsuite.
... (searches) ...
The argument passing convention is a double pointer in this case.

> still does not work: the code *in* the generated loop looks fine to me, but
> the scalarizer dereferences j before the loop.
> 
> I think that this is correct F2018+, as ifx handles it fine.
> Not sure how to proceed here.
> 
> 
> Furthermore, the patch tries to cope (= prevent an ICE) with
> 
> integer, allocatable,optional :: j(:)
> 
> which I think might be invalid.  At least it also crashed with ifx...
> 
There is an error to report if it's invalid, but I doubt it is.

[Bug c++/104594] narrowing of -1 to unsigned char not detected with requires concepts

2024-01-19 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |14.0
   Assignee|ppalka at gcc dot gnu.org  |jason at gcc dot gnu.org

--- Comment #8 from Jason Merrill  ---
Fixed.

[Bug c++/67898] rejects-valid on overloaded function as non-type template argument of dependent type

2024-01-19 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

 CC||jason at gcc dot gnu.org
 Status|ASSIGNED|RESOLVED
   Target Milestone|--- |12.0
 Resolution|--- |FIXED

--- Comment #6 from Jason Merrill  ---
The original testcase was indeed fixed by the patch for 61355, and Patrick's
unrelated testcase in comment 4 is fixed by my commit just now.  Closing as
fixed in 12, but that only applies to the original testcase.

[Bug c++/112632] [14 Regression] Non-type template parameter created with converting constructor sometimes has original type

2024-01-19 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #3 from Jason Merrill  ---
Fixed for GCC 14.

[Bug c++/112594] Non-type template parameter created with converting constructor sometimes has original type

2024-01-19 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
Fixed for GCC 14.

[Bug c++/111357] [11/12/13/14 Regression] __integer_pack fails to work with values of dependent type convertible to integers in noexcept context

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

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

--- Comment #13 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r14-8291-gf1e5bf0d83ee4da81b6317c6d7f1278fe7eaa5a0
Author: Jason Merrill 
Date:   Wed Jan 17 17:29:33 2024 -0500

c++: alias template argument conversion [PR112632]

We've had a problem with lost conversions to template parameter types for a
while now; looking at this PR, it occurred to me that the problem is really
with alias (and concept) templates, since we do substitution of dependent
arguments into them in a way that we don't for other templates.  And fixing
that specific problem is a lot simpler than adding IMPLICIT_CONV_EXPR
around
all dependent template arguments the way I gave up on for 111357.

The other part of the fix was changing tsubst_expr to actually call
convert_nontype_argument instead of assuming it will eventually happen.

I waffled about stripping the forced conversion when !force_conv
vs. skipping them in iterative_hash_template_arg and
template_args_equal (like we already do for some other conversions) and
decided to go with the former, but that isn't a strong preference if it
turns out to be somehow problematic.

PR c++/112632
PR c++/112594
PR c++/111357
PR c++/104594
PR c++/67898

gcc/cp/ChangeLog:

* cp-tree.h (IMPLICIT_CONV_EXPR_FORCED): New.
* pt.cc (expand_integer_pack): Remove 111357 workaround.
(maybe_convert_nontype_argument): Add force parm.
(convert_template_argument): Handle alias template args
specially.
(tsubst_expr): Don't ignore IMPLICIT_CONV_EXPR_NONTYPE_ARG.
* error.cc (dump_expr) [CASE_CONVERT]: Handle null optype.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/alias-decl-nontype1.C: New test.
* g++.dg/cpp2a/concepts-narrowing1.C: New test.
* g++.dg/cpp2a/nontype-class63.C: New test.
* g++.dg/cpp2a/nontype-class63a.C: New test.

[Bug c++/113038] [14 regression] Excess errors for g++.dg/modules/hello-1_b.C after r14-6569-gfe54b57728c09a

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

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

--- Comment #11 from Andrew Pinski  ---
I can confirm it is also fixed on aarch64.

[Bug c++/112632] [14 Regression] Non-type template parameter created with converting constructor sometimes has original type

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

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

--- Comment #2 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r14-8291-gf1e5bf0d83ee4da81b6317c6d7f1278fe7eaa5a0
Author: Jason Merrill 
Date:   Wed Jan 17 17:29:33 2024 -0500

c++: alias template argument conversion [PR112632]

We've had a problem with lost conversions to template parameter types for a
while now; looking at this PR, it occurred to me that the problem is really
with alias (and concept) templates, since we do substitution of dependent
arguments into them in a way that we don't for other templates.  And fixing
that specific problem is a lot simpler than adding IMPLICIT_CONV_EXPR
around
all dependent template arguments the way I gave up on for 111357.

The other part of the fix was changing tsubst_expr to actually call
convert_nontype_argument instead of assuming it will eventually happen.

I waffled about stripping the forced conversion when !force_conv
vs. skipping them in iterative_hash_template_arg and
template_args_equal (like we already do for some other conversions) and
decided to go with the former, but that isn't a strong preference if it
turns out to be somehow problematic.

PR c++/112632
PR c++/112594
PR c++/111357
PR c++/104594
PR c++/67898

gcc/cp/ChangeLog:

* cp-tree.h (IMPLICIT_CONV_EXPR_FORCED): New.
* pt.cc (expand_integer_pack): Remove 111357 workaround.
(maybe_convert_nontype_argument): Add force parm.
(convert_template_argument): Handle alias template args
specially.
(tsubst_expr): Don't ignore IMPLICIT_CONV_EXPR_NONTYPE_ARG.
* error.cc (dump_expr) [CASE_CONVERT]: Handle null optype.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/alias-decl-nontype1.C: New test.
* g++.dg/cpp2a/concepts-narrowing1.C: New test.
* g++.dg/cpp2a/nontype-class63.C: New test.
* g++.dg/cpp2a/nontype-class63a.C: New test.

[Bug c++/67898] rejects-valid on overloaded function as non-type template argument of dependent type

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

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

--- Comment #5 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r14-8291-gf1e5bf0d83ee4da81b6317c6d7f1278fe7eaa5a0
Author: Jason Merrill 
Date:   Wed Jan 17 17:29:33 2024 -0500

c++: alias template argument conversion [PR112632]

We've had a problem with lost conversions to template parameter types for a
while now; looking at this PR, it occurred to me that the problem is really
with alias (and concept) templates, since we do substitution of dependent
arguments into them in a way that we don't for other templates.  And fixing
that specific problem is a lot simpler than adding IMPLICIT_CONV_EXPR
around
all dependent template arguments the way I gave up on for 111357.

The other part of the fix was changing tsubst_expr to actually call
convert_nontype_argument instead of assuming it will eventually happen.

I waffled about stripping the forced conversion when !force_conv
vs. skipping them in iterative_hash_template_arg and
template_args_equal (like we already do for some other conversions) and
decided to go with the former, but that isn't a strong preference if it
turns out to be somehow problematic.

PR c++/112632
PR c++/112594
PR c++/111357
PR c++/104594
PR c++/67898

gcc/cp/ChangeLog:

* cp-tree.h (IMPLICIT_CONV_EXPR_FORCED): New.
* pt.cc (expand_integer_pack): Remove 111357 workaround.
(maybe_convert_nontype_argument): Add force parm.
(convert_template_argument): Handle alias template args
specially.
(tsubst_expr): Don't ignore IMPLICIT_CONV_EXPR_NONTYPE_ARG.
* error.cc (dump_expr) [CASE_CONVERT]: Handle null optype.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/alias-decl-nontype1.C: New test.
* g++.dg/cpp2a/concepts-narrowing1.C: New test.
* g++.dg/cpp2a/nontype-class63.C: New test.
* g++.dg/cpp2a/nontype-class63a.C: New test.

[Bug c++/104594] narrowing of -1 to unsigned char not detected with requires concepts

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

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

--- Comment #7 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r14-8291-gf1e5bf0d83ee4da81b6317c6d7f1278fe7eaa5a0
Author: Jason Merrill 
Date:   Wed Jan 17 17:29:33 2024 -0500

c++: alias template argument conversion [PR112632]

We've had a problem with lost conversions to template parameter types for a
while now; looking at this PR, it occurred to me that the problem is really
with alias (and concept) templates, since we do substitution of dependent
arguments into them in a way that we don't for other templates.  And fixing
that specific problem is a lot simpler than adding IMPLICIT_CONV_EXPR
around
all dependent template arguments the way I gave up on for 111357.

The other part of the fix was changing tsubst_expr to actually call
convert_nontype_argument instead of assuming it will eventually happen.

I waffled about stripping the forced conversion when !force_conv
vs. skipping them in iterative_hash_template_arg and
template_args_equal (like we already do for some other conversions) and
decided to go with the former, but that isn't a strong preference if it
turns out to be somehow problematic.

PR c++/112632
PR c++/112594
PR c++/111357
PR c++/104594
PR c++/67898

gcc/cp/ChangeLog:

* cp-tree.h (IMPLICIT_CONV_EXPR_FORCED): New.
* pt.cc (expand_integer_pack): Remove 111357 workaround.
(maybe_convert_nontype_argument): Add force parm.
(convert_template_argument): Handle alias template args
specially.
(tsubst_expr): Don't ignore IMPLICIT_CONV_EXPR_NONTYPE_ARG.
* error.cc (dump_expr) [CASE_CONVERT]: Handle null optype.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/alias-decl-nontype1.C: New test.
* g++.dg/cpp2a/concepts-narrowing1.C: New test.
* g++.dg/cpp2a/nontype-class63.C: New test.
* g++.dg/cpp2a/nontype-class63a.C: New test.

[Bug c++/112594] Non-type template parameter created with converting constructor sometimes has original type

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

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

--- Comment #3 from GCC Commits  ---
The trunk branch has been updated by Jason Merrill :

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

commit r14-8291-gf1e5bf0d83ee4da81b6317c6d7f1278fe7eaa5a0
Author: Jason Merrill 
Date:   Wed Jan 17 17:29:33 2024 -0500

c++: alias template argument conversion [PR112632]

We've had a problem with lost conversions to template parameter types for a
while now; looking at this PR, it occurred to me that the problem is really
with alias (and concept) templates, since we do substitution of dependent
arguments into them in a way that we don't for other templates.  And fixing
that specific problem is a lot simpler than adding IMPLICIT_CONV_EXPR
around
all dependent template arguments the way I gave up on for 111357.

The other part of the fix was changing tsubst_expr to actually call
convert_nontype_argument instead of assuming it will eventually happen.

I waffled about stripping the forced conversion when !force_conv
vs. skipping them in iterative_hash_template_arg and
template_args_equal (like we already do for some other conversions) and
decided to go with the former, but that isn't a strong preference if it
turns out to be somehow problematic.

PR c++/112632
PR c++/112594
PR c++/111357
PR c++/104594
PR c++/67898

gcc/cp/ChangeLog:

* cp-tree.h (IMPLICIT_CONV_EXPR_FORCED): New.
* pt.cc (expand_integer_pack): Remove 111357 workaround.
(maybe_convert_nontype_argument): Add force parm.
(convert_template_argument): Handle alias template args
specially.
(tsubst_expr): Don't ignore IMPLICIT_CONV_EXPR_NONTYPE_ARG.
* error.cc (dump_expr) [CASE_CONVERT]: Handle null optype.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/alias-decl-nontype1.C: New test.
* g++.dg/cpp2a/concepts-narrowing1.C: New test.
* g++.dg/cpp2a/nontype-class63.C: New test.
* g++.dg/cpp2a/nontype-class63a.C: New test.

[Bug c/113492] [14 Regression] ICE: in composite_type_internal, at c/c-typeck.cc:557 with -std=c2x -funsigned-bitfields since r14-6808

2024-01-19 Thread uecker at gcc dot gnu.org via Gcc-bugs

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

uecker at gcc dot gnu.org changed:

   What|Removed |Added

 CC||uecker at gcc dot gnu.org

--- Comment #2 from uecker at gcc dot gnu.org ---


I agree that "int:3" with -funsigned-bitfields should produce a type which is
compatible to one  with "unsigned:3" and that forming a composite type has to
work.

I am not entirely sure this should be considered a regression as this C23
feature did not exist before (but was rejected and did not ICE).  Anyway, I
will look at this and post a patch. Thanks for reporting.

[Bug fortran/46244] gfc_compare_derived_types is buggy

2024-01-19 Thread mikael at gcc dot gnu.org via Gcc-bugs

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

Mikael Morin  changed:

   What|Removed |Added

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

--- Comment #21 from Mikael Morin  ---
(In reply to Thomas Koenig from comment #20)
> Mikael, are you still planning to work on this?

No, I'm not working on this any more.

[Bug target/113507] New: can't build a cross compiler to rs6000-ibm-aix7.2

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

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

Bug ID: 113507
   Summary: can't build a cross compiler to rs6000-ibm-aix7.2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hjl.tools at gmail dot com
  Target Milestone: ---
Target: rs6000-ibm-aix7.2

On Linux/x86-64, when building a cross compiler to rs6000-ibm-aix7.2,
I got

/usr/local/bin/ld: rs6000-c.o: in function `rs6000_target_modify_macros(bool,
long)':
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:584:(.text+0xe83):
undefined reference to `rs6000_builtin_types'
/usr/local/bin/ld: rs6000-c.o: in function
`rs6000_cpu_cpp_builtins(cpp_reader*)':
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:630:(.text+0x10b5):
undefined reference to `rs6000_builtin_types'
/usr/local/bin/ld:
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:632:(.text+0x10d2):
undefined reference to `rs6000_builtin_types'
/usr/local/bin/ld: rs6000-c.o: in function
`altivec_build_resolved_builtin(tree_node**, int, tree_node*, tree_node*,
rs6000_gen_builtins, rs6000_gen_builtins)':
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:878:(.text+0x190a):
undefined reference to `rs6000_builtin_decls'
/usr/local/bin/ld: rs6000-c.o: in function `resolve_vec_mul(resolution*,
tree_node**, tree_node**, unsigned int)':
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:983:(.text+0x1dae):
undefined reference to `rs6000_builtin_decls'
/usr/local/bin/ld:
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:990:(.text+0x1ded):
undefined reference to `rs6000_builtin_decls'
/usr/local/bin/ld: rs6000-c.o: in function `resolve_vec_cmpne(resolution*,
tree_node**, tree_node**, unsigned int)':
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:1049:(.text+0x2032):
undefined reference to `rs6000_builtin_decls'
/usr/local/bin/ld:
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:1058:(.text+0x2095):
undefined reference to `rs6000_builtin_decls'
/usr/local/bin/ld:
rs6000-c.o:/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:1113:
more undefined references to `rs6000_builtin_decls' follow
/usr/local/bin/ld: rs6000-c.o: in function `resolve_vec_splats(resolution*,
rs6000_gen_builtins, vec*, unsigned int)':
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:1284:(.text+0x2ad6):
undefined reference to `rs6000_builtin_types'
/usr/local/bin/ld:
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:1284:(.text+0x2adf):
undefined reference to `rs6000_builtin_types'
/usr/local/bin/ld:
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:1288:(.text+0x2afc):
undefined reference to `rs6000_builtin_types'
/usr/local/bin/ld:
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:1288:(.text+0x2b05):
undefined reference to `rs6000_builtin_types'
/usr/local/bin/ld:
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:1292:(.text+0x2b22):
undefined reference to `rs6000_builtin_types'
/usr/local/bin/ld:
rs6000-c.o:/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:1292:
more undefined references to `rs6000_builtin_types' follow
/usr/local/bin/ld: rs6000-c.o: in function `resolve_vec_extract(resolution*,
vec*, unsigned int, unsigned int)':
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:1380:(.text+0x2fb0):
undefined reference to `rs6000_builtin_decls'
/usr/local/bin/ld:
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:1384:(.text+0x2fc0):
undefined reference to `rs6000_builtin_decls'
/usr/local/bin/ld:
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:1388:(.text+0x2fd0):
undefined reference to `rs6000_builtin_decls'
/usr/local/bin/ld:
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:1392:(.text+0x2fe0):
undefined reference to `rs6000_builtin_decls'
/usr/local/bin/ld:
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:1397:(.text+0x3043):
undefined reference to `rs6000_builtin_decls'
/usr/local/bin/ld:
rs6000-c.o:/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:1402:
more undefined references to `rs6000_builtin_decls' follow
/usr/local/bin/ld: rs6000-c.o: in function `find_instance(bool*, ovlddata**,
rs6000_gen_builtins, rs6000_gen_builtins, tree_node**, tree_node**, int)':
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:1694:(.text+0x41e9):
undefined reference to `rs6000_builtin_info'
/usr/local/bin/ld:
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:1711:(.text+0x42e4):
undefined reference to `rs6000_builtin_decl(unsigned int, bool)'
/usr/local/bin/ld:
/export/gnu/import/git/sources/gcc/gcc/config/rs6000/rs6000-c.cc:1712:(.text+0x4301):
undefined reference to

[Bug c/110029] more precise documentation for cleanup attribute

2024-01-19 Thread ian at airs dot com via Gcc-bugs

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

--- Comment #4 from Ian Lance Taylor  ---
Thanks!

[Bug middle-end/111054] [14 Regression] ICE: in to_sreal, at profile-count.cc:472 with -O3 -fno-guess-branch-probability since r14-2967

2024-01-19 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[14 Regression] ICE: in |[14 Regression] ICE: in
   |to_sreal, at|to_sreal, at
   |profile-count.cc:472 with   |profile-count.cc:472 with
   |-O3 |-O3
   |-fno-guess-branch-probabili |-fno-guess-branch-probabili
   |ty  |ty since r14-2967
 CC||jakub at gcc dot gnu.org

--- Comment #5 from Jakub Jelinek  ---
Started with r14-2967-gd6ac3aae2a32869d9d37f3bc7783d9bbad27d72b

[Bug fortran/113503] [14 Regression] xtb test miscompilation starting with r14-870

2024-01-19 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #1)
> When trying to further reduce the code I get either an ICE or an
> uninitialized-warning for:

program xtb
  implicit none
  type :: TSolvInput
 character(len=:), allocatable :: solvent
  end type
  character(len=20) :: solvents(1) = 'h2o'
  type(TSolvInput)  :: x
! x = TSolvInput(solvent= solvents(1))  ! ICE
  x = TSolvInput(solvent=trim(solvents(1))) ! Warning
end


So it clearly comes from the constructor.

[Bug tree-optimization/113462] ICE: in handle_cast, at gimple-lower-bitint.cc:1539 at -O with _BitInt() in a struct

2024-01-19 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2024-01-19
 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED

--- Comment #2 from Jakub Jelinek  ---
Created attachment 57164
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57164=edit
gcc14-pr113462.patch

Untested fix.

[Bug c++/109642] False Positive -Wdangling-reference with std::span-like classes

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

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

Marek Polacek  changed:

   What|Removed |Added

 CC||lopresti at gmail dot com

--- Comment #12 from Marek Polacek  ---
*** Bug 109671 has been marked as a duplicate of this bug. ***

[Bug c++/109671] Spurious dangling reference warning in GCC 13

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

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

Marek Polacek  changed:

   What|Removed |Added

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

--- Comment #5 from Marek Polacek  ---
(In reply to Patrick J. LoPresti from comment #3)
> (In reply to Andrew Pinski from comment #1)
> > There is no way for GCC to know that get_foo_by_name does not store the
> > argument into what is returned so it warns about this case ...
> 
> To summarize:
> 
> GCC is warning because it does not and cannot know whether I am managing
> object lifetimes correctly.
> 
> The only way to silence the warning is to modify my code to make it uglier,
> into a form where GCC still does not and cannot know whether I am managing
> lifetimes correctly.
> 
> So is this a valid bug report, or not?

It's valid but also I don't think I can tweak the heuristic not to warn here. 
There ought to be a simpler way to suppress the warning, see bug 109642.

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

[Bug tree-optimization/113491] ICE: SIGSEGV in make_ssa_name_fn (tree-ssanames.cc:354) at -Os with _BitInt() used as switch control expression

2024-01-19 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |jakub at gcc dot gnu.org
   Last reconfirmed||2024-01-19
 Ever confirmed|0   |1

--- Comment #2 from Jakub Jelinek  ---
Created attachment 57163
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57163=edit
gcc14-pr113491.patch

Untested fix.

[Bug c++/110075] Bogus -Wdangling-reference

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

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

Marek Polacek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 CC||mpolacek at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-01-19

--- Comment #3 from Marek Polacek  ---
Confirmed, thanks for reporting.  I'm not certain I can devise a fix, but maybe
a new attribute to suppress the warning would help.  Like in bug 109642 as
mentioned.

[Bug c++/113498] [14 regression] ICE in GCC trunk: tree check: have using_decl in get_template_info, at cp/pt.cc:357 since r14-6064

2024-01-19 Thread jason at gcc dot gnu.org via Gcc-bugs

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug fortran/113503] [14 Regression] xtb test miscompilation starting with r14-870

2024-01-19 Thread anlauf at gcc dot gnu.org via Gcc-bugs

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

--- Comment #1 from anlauf at gcc dot gnu.org ---
When trying to further reduce the code I get either an ICE or an
uninitialized-warning for:

program xtb
  implicit none
  type :: TSolvInput
 character(len=:), allocatable :: solvent
  end type
  character(len=20) :: solvents(1) = 'h2o'

! call addSolvationModel(TSolvInput(solvent= solvents(1)))  ! ICE
  call addSolvationModel(TSolvInput(solvent=trim(solvents(1 ! Warning

contains
  subroutine addSolvationModel(input)
type(TSolvInput), intent(in) :: input
  end
end

[Bug target/112103] [14 regression] gcc.target/powerpc/rlwinm-0.c fails after r14-4941-gd1bb9569d70304

2024-01-19 Thread bergner at gcc dot gnu.org via Gcc-bugs

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

--- Comment #3 from Peter Bergner  ---
(In reply to Segher Boessenkool from comment #2)
> In all those cases the code is perfectly fine, but also in all of those
> cases the
> code is still suboptimal: the rldicl is just as superfluous as the second
> rlwinm
> was!  :-)

So the superfluous second instruction is not really a regression, correct?  All
that changed with Roger's patch is we replaced a superfluous rlwinm with a
superfluous rldicl, correct?

...which is what caused the testcase to FAIL given it was looking for the old
mnemonic and found the new one.

[Bug ipa/113478] -Os does not inline single instruction function

2024-01-19 Thread hubicka at ucw dot cz via Gcc-bugs

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

--- Comment #4 from Jan Hubicka  ---
> Possibly, at least when we know it doesn't expand to a libatomic call?  OTOH
> even then a function just wrapping such call should probably be inlined,
> so the question is whether the problem that
> is estimated as too big compared to the call calling the function
> (OTOH a1.test () has no arguments while __atomic_load_1 has two).

If we really want to optimize for size, calling function with one
parameter is shorter then calling function with two parameters.  The
code size model takes into account when the offline copy of the function
will disappear and it also has some biass towards understanding that a
lot of comdat functions are not really shared across units.

The testcase calls function 15 times and I guess wrapper function on
most architectures is shorter than 15 load zero instructions...

We now have -Os and -Oz and two-level optimize_size predicates. We may
make this less restrictive with lower size optimization level. But when
optimizing for size and if __atomic_load was ordinary function call, I
think the decision is correct.

[Bug other/113317] New test case libgomp.c++/ind-base-2.C fails with ICE

2024-01-19 Thread bergner at gcc dot gnu.org via Gcc-bugs

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

--- Comment #8 from Peter Bergner  ---
...unless the other P9 systems that were tested built with those "broken"
versions of the compilers.  If that's the case, then it points to something
else wrong on that system.

[Bug c++/113498] [14 regression] ICE in GCC trunk: tree check: have using_decl in get_template_info, at cp/pt.cc:357 since r14-6064

2024-01-19 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

Summary|[14 regression] ICE in GCC  |[14 regression] ICE in GCC
   |trunk: tree check: have |trunk: tree check: have
   |using_decl in   |using_decl in
   |get_template_info, at   |get_template_info, at
   |cp/pt.cc:357|cp/pt.cc:357 since r14-6064
 CC||jakub at gcc dot gnu.org,
   ||jason at gcc dot gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2024-01-19
   Priority|P3  |P1
 Status|UNCONFIRMED |NEW

--- Comment #3 from Jakub Jelinek  ---
Started with r14-6064-gc3f281a0c1ca50e4df5049923aa2f5d1c3c39ff6

[Bug c/113492] [14 Regression] ICE: in composite_type_internal, at c/c-typeck.cc:557 with -std=c2x -funsigned-bitfields since r14-6808

2024-01-19 Thread jakub at gcc dot gnu.org via Gcc-bugs

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

Jakub Jelinek  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2024-01-19
 CC||jakub at gcc dot gnu.org
   Priority|P3  |P1
Summary|[14 Regression] ICE: in |[14 Regression] ICE: in
   |composite_type_internal, at |composite_type_internal, at
   |c/c-typeck.cc:557 with  |c/c-typeck.cc:557 with
   |-std=c2x|-std=c2x
   |-funsigned-bitfields|-funsigned-bitfields since
   ||r14-6808

--- Comment #1 from Jakub Jelinek  ---
Started with r14-6808-g8c8d4b565cd7e08c6ec9ca5a4369d8ec5619cad8

[Bug analyzer/112705] FAIL: gcc.dg/analyzer/pr94688.c (test for excess errors)

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

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

--- Comment #1 from GCC Commits  ---
The master branch has been updated by John David Anglin :

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

commit r14-8286-g4eee04561a725fd1ef927f620daeddd11807ca26
Author: John David Anglin 
Date:   Fri Jan 19 16:01:43 2024 +

Skip gcc.dg/analyzer/pr94688.c on hppa*64*-*-*

2024-01-19  John David Anglin  

gcc/testsuite/ChangeLog:

PR analyzer/112705
* gcc.dg/analyzer/pr94688.c: Skip on hppa*64*-*-*.

[Bug c/112878] ICE: in ctf_add_slice, at ctfc.cc:499 with -std=c23 -gctf1

2024-01-19 Thread zsojka at seznam dot cz via Gcc-bugs

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

Zdenek Sojka  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org,
   ||zsojka at seznam dot cz

--- Comment #1 from Zdenek Sojka  ---
Also fails with a union:
$ cat testcase.c 
union {
  _BitInt(448) f2 : 1;
} b;
$ x86_64-pc-linux-gnu-gcc -gbtf testcase.c 
testcase.c:3:1: internal compiler error: in ctf_add_slice, at ctfc.cc:499
3 | } b;
  | ^
0xd60e19 ctf_add_slice(ctf_container*, unsigned int, unsigned long, unsigned
int, unsigned int, die_struct*)
/repo/gcc-trunk/gcc/ctfc.cc:499
0x101d9d0 gen_ctf_sou_type
/repo/gcc-trunk/gcc/dwarf2ctf.cc:617
0x101d177 gen_ctf_type
/repo/gcc-trunk/gcc/dwarf2ctf.cc:892
...

[Bug tree-optimization/113491] ICE: SIGSEGV in make_ssa_name_fn (tree-ssanames.cc:354) at -Os with _BitInt() used as switch control expression

2024-01-19 Thread zsojka at seznam dot cz via Gcc-bugs

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

--- Comment #1 from Zdenek Sojka  ---
Created attachment 57162
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57162=edit
shorter testcase (reduced from gcc.dg/torture/pr45830.c)

$ x86_64-pc-linux-gnu-gcc -Os pr45830.i -wrapper valgrind,-q
==7594== Invalid read of size 2
==7594==at 0x177D97A: make_ssa_name_fn(function*, tree_node*, gimple*,
unsigned int) (tree-ssanames.cc:354)
==7594==by 0x1610F62: make_ssa_name (tree-ssanames.h:98)
==7594==by 0x1610F62:
tree_switch_conversion::switch_conversion::build_arrays()
(tree-switch-conversion.cc:727)
==7594==by 0x1611346:
tree_switch_conversion::switch_conversion::expand(gswitch*) [clone .part.0]
(tree-switch-conversion.cc:1067)
==7594==by 0x161140A: expand (tree-switch-conversion.cc:2546)
==7594==by 0x161140A: (anonymous
namespace)::pass_convert_switch::execute(function*)
(tree-switch-conversion.cc:2564)
==7594==by 0x13CC0EA: execute_one_pass(opt_pass*) (passes.cc:2646)
==7594==by 0x13CC9DF: execute_pass_list_1(opt_pass*) (passes.cc:2755)
==7594==by 0x13CC9F1: execute_pass_list_1(opt_pass*) (passes.cc:2756)
==7594==by 0x13CCA18: execute_pass_list(function*, opt_pass*)
(passes.cc:2766)
==7594==by 0x13CD33C: do_per_function_toporder(void (*)(function*, void*),
void*) [clone .part.0] (passes.cc:1773)
==7594==by 0x13CD56E: do_per_function_toporder (passes.cc:1740)
==7594==by 0x13CD56E: execute_ipa_pass_list(opt_pass*) (passes.cc:3100)
==7594==by 0xFCDDE7: ipa_passes (cgraphunit.cc:2211)
==7594==by 0xFCDDE7: symbol_table::compile() [clone .part.0]
(cgraphunit.cc:2332)
==7594==by 0xFD0667: compile (cgraphunit.cc:2312)
==7594==by 0xFD0667: symbol_table::finalize_compilation_unit()
(cgraphunit.cc:2584)
==7594==  Address 0x0 is not stack'd, malloc'd or (recently) free'd
==7594== 
during GIMPLE pass: switchconv
pr45830.i: In function 'foo':
pr45830.i:19:1: internal compiler error: Segmentation fault
   19 | }
  | ^
0x150de9f crash_signal
/repo/gcc-trunk/gcc/toplev.cc:317
0x177d97a make_ssa_name_fn(function*, tree_node*, gimple*, unsigned int)
/repo/gcc-trunk/gcc/tree-ssanames.cc:354
0x1610f62 make_ssa_name(tree_node*, gimple*)
/repo/gcc-trunk/gcc/tree-ssanames.h:98
0x1610f62 tree_switch_conversion::switch_conversion::build_arrays()
/repo/gcc-trunk/gcc/tree-switch-conversion.cc:727
0x1611346 tree_switch_conversion::switch_conversion::expand(gswitch*)
/repo/gcc-trunk/gcc/tree-switch-conversion.cc:1067
0x161140a tree_switch_conversion::switch_conversion::expand(gswitch*)
/repo/gcc-trunk/gcc/tree-switch-conversion.cc:2546
0x161140a execute
/repo/gcc-trunk/gcc/tree-switch-conversion.cc:2564
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See  for instructions.

[Bug testsuite/109705] [14 regression] gcc.dg/vect/pr25413a.c fails after r14-333-g6d4b59a9356ac4

2024-01-19 Thread bergner at gcc dot gnu.org via Gcc-bugs

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

--- Comment #6 from Peter Bergner  ---
(In reply to GCC Commits from comment #5)
> commit r14-7270-g39fa71a0882928a25bd170580e3e9e89a69dce36
> Author: Kewen Lin 
> Date:   Mon Jan 15 20:55:40 2024 -0600
> 
> testsuite: Fix vect_long_mult on Power [PR109705]
> 
> As pointed out by the discussion in PR109705, the current
> vect_long_mult effective target check on Power is broken.
> This patch is to fix it accordingly.

Does this need backporting?

[Bug libstdc++/113504] High memory usage for parallel `std::sort`

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

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

--- Comment #1 from Jonathan Wakely  ---
The parallel algos are taken from
https://github.com/llvm/llvm-project/tree/main/pstl so I would file an issue
upstream rather than here. The Intel PSTL developers are the right people to
ask.

[Bug rtl-optimization/113506] New: ICE: RTL check: expected elt 2 type 'B', have '0' (rtx barrier) in BLOCK_FOR_INSN, at rtl.h:1495 with -Os -fno-tree-coalesce-vars -finline-stringops

2024-01-19 Thread zsojka at seznam dot cz via Gcc-bugs

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

Bug ID: 113506
   Summary: ICE: RTL check: expected elt 2 type 'B', have '0' (rtx
barrier) in BLOCK_FOR_INSN, at rtl.h:1495 with -Os
-fno-tree-coalesce-vars -finline-stringops
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zsojka at seznam dot cz
  Target Milestone: ---
  Host: x86_64-pc-linux-gnu
Target: riscv64-unknown-linux-gnu

Created attachment 57161
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57161=edit
reduced testcase (from gcc.dg/torture/pr69886.c)

RTL checking might need to be enabled.

Compiler output:
$ riscv64-unknown-linux-gnu-gcc -Os -fno-tree-coalesce-vars -finline-stringops
testcase.c
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:12:1: internal compiler error: RTL check: expected elt 2 type 'B',
have '0' (rtx barrier) in BLOCK_FOR_INSN, at rtl.h:1495
   12 | }
  | ^
0xad3d4c rtl_check_failed_type1(rtx_def const*, int, int, char const*, int,
char const*)
/repo/gcc-trunk/gcc/rtl.cc:751
0xa20a79 BLOCK_FOR_INSN(rtx_def*)
/repo/gcc-trunk/gcc/rtl.h:1495
0xa242a6 BLOCK_FOR_INSN(rtx_def*)
/repo/gcc-trunk/gcc/emit-rtl.cc:4384
0xa242a6 set_block_for_insn(rtx_insn*, basic_block_def*)
/repo/gcc-trunk/gcc/rtl.h:1500
0xa242a6 add_insn_before(rtx_insn*, rtx_insn*, basic_block_def*)
/repo/gcc-trunk/gcc/emit-rtl.cc:4379
0x127efd0 emit_pattern_before_noloc
/repo/gcc-trunk/gcc/emit-rtl.cc:4647
0x11a0d04 commit_one_edge_insertion(edge_def*)
/repo/gcc-trunk/gcc/cfgrtl.cc:2071
0x11a6011 commit_edge_insertions()
/repo/gcc-trunk/gcc/cfgrtl.cc:2133
0x11866e0 execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6956
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.

$ riscv64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-riscv64/bin/riscv64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-8284-20240119180625-g54519030b05-checking-yes-rtl-df-extra-riscv64/bin/../libexec/gcc/riscv64-unknown-linux-gnu/14.0.1/lto-wrapper
Target: riscv64-unknown-linux-gnu
Configured with: /repo/gcc-trunk//configure --enable-languages=c,c++
--enable-valgrind-annotations --disable-nls --enable-checking=yes,rtl,df,extra
--with-cloog --with-ppl --with-isl --with-isa-spec=2.2
--with-sysroot=/usr/riscv64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=riscv64-unknown-linux-gnu
--with-ld=/usr/bin/riscv64-unknown-linux-gnu-ld
--with-as=/usr/bin/riscv64-unknown-linux-gnu-as --disable-multilib
--disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8284-20240119180625-g54519030b05-checking-yes-rtl-df-extra-riscv64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240119 (experimental) (GCC)

[Bug analyzer/113505] New: ICE: SIGSEGV in tree_class_check (tree.h:3766) with -O -fdump-analyzer -fanalyzer

2024-01-19 Thread zsojka at seznam dot cz via Gcc-bugs

 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-8284-20240119180625-g54519030b05-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 --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-8284-20240119180625-g54519030b05-checking-yes-rtl-df-extra-nobootstrap-amd64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.1 20240119 (experimental) (GCC)

[Bug other/113317] New test case libgomp.c++/ind-base-2.C fails with ICE

2024-01-19 Thread bergner at gcc dot gnu.org via Gcc-bugs

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

--- Comment #7 from Peter Bergner  ---
(In reply to seurer from comment #6)
> I tried an older compiler (8.4) and it worked ok.
> 
> I just experimented a bit and it fails with the current gcc 11 and 12 used
> as the build compiler as well.  It works when I use gcc 13.

When you say current gcc 11 and 12, you mean the FSF release branches?  ...or
builds you had around?  If the current FSF release branches, then we'll want to
git bisect to figure out when it broke and when it got fixed (or just went
latent?).  What about gcc 9 and gcc 10?

[Bug target/112862] [14 regression] gfortran.dg coarray tests FAIL on macOS 12+

2024-01-19 Thread ro at CeBiTec dot Uni-Bielefeld.DE via Gcc-bugs

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

--- Comment #6 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #5 from Iain Sandoe  ---
>> > Now I have a concern that we have instances of -Bpath/to/libsomething/.libs
>> > that are present to allow for specs substitution and we also need them for
>> > providing run paths at test time.  BUT, we do not want duplicates
>> > (since, that
>> > triggers a different warning for some Xcode versions, and is
>> > inefficient anyway
>> > - albeit probably a very minor contribution to testing time).
>> 
>> Still there is going to be an impact, even on non-Darwin.  However, this
>> duplication of -B and -L options is present all over the testsuite
>> already, just nobody cared to do something about it so far.  Those Xcode
>> 15 ld warnings my change this, though...
>
> Actually, since -B produces a -L for every -B directory that exists, if we add
> -B we really ought to omit the -L if it's the same - otherwise we get useless
> duplicates on the link line.  Do you know of any exception to the B implies L?

No.  TBH I only really knew about -B to find e.g. library-specific spec
files, not for libraries themselves.

[Bug libstdc++/113504] New: High memory usage for parallel `std::sort`

2024-01-19 Thread ruben.laso at tuwien dot ac.at via Gcc-bugs

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

Bug ID: 113504
   Summary: High memory usage for parallel `std::sort`
   Product: gcc
   Version: 12.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: ruben.laso at tuwien dot ac.at
  Target Milestone: ---

The memory usage of parallel `std::sort` is very high compared to the
sequential version and even other parallel implementations.
The attached code is a simple test case to compare the memory usage of parallel
`std::sort`, `tbb::parallel_sort` and sequential `std::sort`.
The test case has been replicated in several systems with versions of GCC 10,
11 and 12.

An example of the results (and max. memory usage according to `/usr/bin/time`)
is shown in the following table:

| Executable | Size| Time | Max Resident Memory |
| -- | --- |  | --- |
| ./pstl_sort.out| 33554432| 0:00.23  | 423776k |
| ./tbb_sort.out | 33554432| 0:00.44  | 143952k |
| ./seq_sort.out | 33554432| 0:03.32  | 134836k |
| ./pstl_sort.out| 1073741824  | 0:05.68  | 14236656k   |
| ./tbb_sort.out | 1073741824  | 0:13.02  | 4207680k|
| ./seq_sort.out | 1073741824  | 2:07.38  | 4198124k|

In the example, the parallel `std::sort` (pstl_sort) uses ~3 times more memory
than the `tbb::parallel_sort` (tbb_sort) and the sequential `std::sort`
(seq_sort).
It also runs faster, though.

System specs in the example:
CPU: AMD EPYC 7551
RAM: 256 GB DDR4
OS: Debian 10.10

Compilation with:
g++ -std=c++17 -O3 -pedantic -Wall -Wextra -Werror -o pstl_sort.out main.cpp
-ltbb -DPSTL_SORT
g++ -std=c++17 -O3 -pedantic -Wall -Wextra -Werror -o tbb_sort.out main.cpp
-ltbb -DTBB_SORT
g++ -std=c++17 -O3 -pedantic -Wall -Wextra -Werror -o seq_sort.out main.cpp
-ltbb

Did I miss something in the code?
Is that high memory usage a deliberate trade-off for performance?
Is the algorithm still in development to improve memory usage?

[Bug target/113114] [14 Regression] ICE compiling gcc.c-torture/execute/pr59643.cwith -mabi=ilp32; in try_promote_writeback aarch64-ldp-fusion.cc

2024-01-19 Thread acoplan at gcc dot gnu.org via Gcc-bugs

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

Alex Coplan  changed:

   What|Removed |Added

URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2024-January
   ||/643460.html
   Keywords||patch

--- Comment #8 from Alex Coplan  ---
Patch submitted:
https://gcc.gnu.org/pipermail/gcc-patches/2024-January/643460.html

[Bug target/111677] [12/13/14 Regression] darktable build on aarch64 fails with unrecognizable insn due to -fstack-protector changes

2024-01-19 Thread costamagnagianfranco at yahoo dot it via Gcc-bugs

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

--- Comment #19 from Gianfranco  ---
looks like branch 14 is not FTBFS.

1 2 >

1 - 100 of 163 matches

Mail list logo