[Bug c++/111712] New: Syntax error when passing function parameter as NTTP in requires-clause

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 111712
   Summary: Syntax error when passing function parameter as NTTP
in requires-clause
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

Regardless of whether the code is well-formed or not, this should be valid
syntax

https://godbolt.org/z/4qM9nG4WP

#include 

template
void f(std::bool_constant b)
  requires requires { typename std::bool_constant; };

int main() {
  f(std::true_type{});
}

However, GCC givs

:5:54: error: template argument 1 is invalid
:5:37: error: invalid use of template-name 'std::bool_constant' without
an argument list
5 |   requires requires { typename std::bool_constant; };
  | ^
In file included from :1:
/opt/compiler-explorer/gcc-trunk-20231005/include/c++/14.0.0/type_traits:120:11:
note: 'template using std::bool_constant = std::__bool_constant<__v>'
declared here
  120 | using bool_constant = __bool_constant<__v>;
  |   ^
:5:50: error: expected '(' before '<' token
5 |   requires requires { typename std::bool_constant; };
  |  ^
  |  (
:5:55: error: expected primary-expression before ';' token
5 |   requires requires { typename std::bool_constant; };
  |   ^

[Bug target/111260] arm: ice in maybe_legitimize_operand, at optabs.cc:8054

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #4 from Zdenek Sojka  ---
(In reply to Andrew Pinski from comment #3)
> (In reply to Zdenek Sojka from comment #2)

...

> > ...
> 
> That is 100% a different bug and should be filed separately.

Than you for checking, I've created PR111711 for that

[Bug rtl-optimization/111711] New: [14 Regression] ICE: in maybe_legitimize_operand, at optabs.cc:8046 at -O1 with division by zero

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 111711
   Summary: [14 Regression] ICE: in maybe_legitimize_operand, at
optabs.cc:8046 at -O1 with division by zero
   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: aarch64-unknown-linux-gnu

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

Compiler output:
$ aarch64-unknown-linux-gnu-gcc -O testcase.c
testcase.c: In function 'bar':
testcase.c:4:15: warning: division by zero [-Wdiv-by-zero]
4 |   x *= x == 0 / 0;
  |   ^
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:11:10: internal compiler error: in maybe_legitimize_operand, at
optabs.cc:8046
   11 |   return bar (822920);
  |  ^~~~
0x7ff794 maybe_legitimize_operand
/repo/gcc-trunk/gcc/optabs.cc:8046
0x7ff794 maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
/repo/gcc-trunk/gcc/optabs.cc:8194
0x1104c69 maybe_gen_insn(insn_code, unsigned int, expand_operand*)
/repo/gcc-trunk/gcc/optabs.cc:8213
0x1106789 maybe_expand_insn(insn_code, unsigned int, expand_operand*)
/repo/gcc-trunk/gcc/optabs.cc:8268
0x1106789 emit_conditional_move_1
/repo/gcc-trunk/gcc/optabs.cc:5242
0x1106b5c emit_conditional_move(rtx_def*, rtx_comparison, rtx_def*, rtx_def*,
machine_mode, int)
/repo/gcc-trunk/gcc/optabs.cc:5155
0xe646e3 expand_cond_expr_using_cmove
/repo/gcc-trunk/gcc/expr.cc:9099
0xe50ebd expand_expr_real_2(separate_ops*, rtx_def*, machine_mode,
expand_modifier)
/repo/gcc-trunk/gcc/expr.cc:10520
0xe5713f expand_expr_real_1(tree_node*, rtx_def*, machine_mode,
expand_modifier, rtx_def**, bool)
/repo/gcc-trunk/gcc/expr.cc:10821
0xd190c4 expand_expr(tree_node*, rtx_def*, machine_mode, expand_modifier)
/repo/gcc-trunk/gcc/expr.h:310
0xd190c4 expand_return
/repo/gcc-trunk/gcc/cfgexpand.cc:3809
0xd190c4 expand_gimple_stmt_1
/repo/gcc-trunk/gcc/cfgexpand.cc:3918
0xd190c4 expand_gimple_stmt
/repo/gcc-trunk/gcc/cfgexpand.cc:4044
0xd1f4fe expand_gimple_basic_block
/repo/gcc-trunk/gcc/cfgexpand.cc:6100
0xd20fb6 execute
/repo/gcc-trunk/gcc/cfgexpand.cc:6835
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.

aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-20231006111028-gf05b68b8f00-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-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-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-20231006111028-gf05b68b8f00-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231006 (experimental) (GCC)

[Bug target/111260] arm: ice in maybe_legitimize_operand, at optabs.cc:8054

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Zdenek Sojka from comment #2)
> Different testcase:
> $ cat testcase.c
> long
> bar (long x)
> {
>   x *= x == 0 / 0;
>   return (x);
> }
> 
> long
> foo (void)
> {
>   return bar (822920);
> }
> 
> $ aarch64-unknown-linux-gnu-gcc -O testcase.c 
> testcase.c: In function 'bar':
> testcase.c:4:15: warning: division by zero [-Wdiv-by-zero]
> 4 |   x *= x == 0 / 0;
>   |   ^
> during RTL pass: expand
> testcase.c: In function 'foo':
> testcase.c:11:10: internal compiler error: in maybe_legitimize_operand, at
> optabs.cc:8046
>11 |   return bar (822920);
>   |  ^~~~
> 0x7ff794 maybe_legitimize_operand
> /repo/gcc-trunk/gcc/optabs.cc:8046
> 0x7ff794 maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
> expand_operand*)
> /repo/gcc-trunk/gcc/optabs.cc:8194
> ...

That is 100% a different bug and should be filed separately.

[Bug target/111260] arm: ice in maybe_legitimize_operand, at optabs.cc:8054

[zsojka at seznam dot cz via Gcc-bugs]

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

Zdenek Sojka  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #2 from Zdenek Sojka  ---
Different testcase:
$ cat testcase.c
long
bar (long x)
{
  x *= x == 0 / 0;
  return (x);
}

long
foo (void)
{
  return bar (822920);
}

$ aarch64-unknown-linux-gnu-gcc -O testcase.c 
testcase.c: In function 'bar':
testcase.c:4:15: warning: division by zero [-Wdiv-by-zero]
4 |   x *= x == 0 / 0;
  |   ^
during RTL pass: expand
testcase.c: In function 'foo':
testcase.c:11:10: internal compiler error: in maybe_legitimize_operand, at
optabs.cc:8046
   11 |   return bar (822920);
  |  ^~~~
0x7ff794 maybe_legitimize_operand
/repo/gcc-trunk/gcc/optabs.cc:8046
0x7ff794 maybe_legitimize_operands(insn_code, unsigned int, unsigned int,
expand_operand*)
/repo/gcc-trunk/gcc/optabs.cc:8194
...

[Bug ipa/111672] Inappropriate function splitting during pass_split_functions

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

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

--- Comment #12 from Andrew Pinski  ---
(In reply to Hanke Zhang from comment #11)
> But I have never seen this '_FORTIFY_SOURCE' before. So I'm a confused as
> well. And when I try gcc@11.4 built in the default ubuntu 22.04, it's the
> same. So I don't know how to describe now. Thanks for your help anyway.

Well Ubuntu's compiler defaults to defining _FORTIFY_SOURCE while the upstream
GCC does not. Ubuntu's compiler also defaults to building PIE applications too.

[Bug ipa/111672] Inappropriate function splitting during pass_split_functions

[hkzhang455 at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Hanke Zhang  ---
(In reply to Andrew Pinski from comment #10)
> The difference between the 2 is the costing of the __printf_chk/puts:
> _FORTIFY_SOURCE case:
>   freq:0.20 size:  3 time:2.43 __printf_chk (1, "Object code generation not
> active! Forgot to call quantum_objcode_start?\n");
> 
> vs without:
>   freq:0.20 size:  2 time:2.23 puts (&"Object code generation not active!
> Forgot to call quantum_objcode_start?"[0]);

But I have never seen this '_FORTIFY_SOURCE' before. So I'm a confused as well.
And when I try gcc@11.4 built in the default ubuntu 22.04, it's the same. So I
don't know how to describe now. Thanks for your help anyway.

[Bug c++/100825] function signature constraints are not a part of mangled name

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

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

Jason Merrill  changed:

   What|Removed |Added

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

[Bug middle-end/111632] gcc fails to bootstrap when using libc++

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|gcc's C++ components fail   |gcc fails to bootstrap when
   |to compile against recent   |using libc++
   |libc++ headers  |
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-10-05
 Ever confirmed|0   |1

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

[Bug c++/111703] [12/13/14 Regression] [C++20]Compiler fails when using generic lambda in specific situation

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-05
 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1

--- Comment #2 from Andrew Pinski  ---
I should have marked this as Confirmed yesterday.

[Bug middle-end/111699] [14 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||patch
URL||https://gcc.gnu.org/piperma
   ||il/gcc-patches/2023-October
   ||/632128.html

--- Comment #5 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632128.html

[Bug c++/67343] C++ mangler does not follow ABI for unresolved names in expressions

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

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

Jason Merrill  changed:

   What|Removed |Added

 CC||yedeng.yd at linux dot 
alibaba.com

--- Comment #9 from Jason Merrill  ---
*** Bug 109887 has been marked as a duplicate of this bug. ***

[Bug c++/109887] Different mangled name for template specialization for clang and gcc

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

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

Jason Merrill  changed:

   What|Removed |Added

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

--- Comment #4 from Jason Merrill  ---
This is unresolved ABI issue 38.  I'm going to try to push it along again.

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

[Bug c++/100135] [modules] ICE when using constants in a module

[nicolas.werner at hotmail dot de via Gcc-bugs]

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

--- Comment #2 from Nicolas Werner  ---
Possibly the gcc behaviour here is correct. There is a clang bug open for it
not rejecting calls to functions with default parameters, when the default
parameter is not exported: https://github.com/llvm/llvm-project/issues/57459

However possibly that should only be an error at the call site instead of when
compiling the module with that function declaration, when the function
parameter can be legally specified at the call site. For example for foo(int i
= unexported_constant) a call to foo(5) could be legal, even if only foo but
not unexported_constant is exported? Not sure what the standard says on that,
it sounds similar to CWG2631.

[Bug regression/111709] [13 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #8 from joseph at codesourcery dot com  ---
Typically these sorts of issues result from floating-point operations 
being moved past environment manipulation (fesetround, feupdateenv, 
feholdexcept, etc.) - in either direction.  This might be a compiler 
issue, or it might well be a bug in the glibc function implementation 
(insufficient use of math_opt_barrier / math_force_eval to prevent such 
movement).  If the latter, make sure to fix it in all similar 
implementations of fma functions, not just the dbl-64 one.

[Bug c++/100135] [modules] ICE when using constants in a module

[nicolas.werner at hotmail dot de via Gcc-bugs]

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

Nicolas Werner  changed:

   What|Removed |Added

 CC||nicolas.werner at hotmail dot 
de

--- Comment #1 from Nicolas Werner  ---
A more minimal example of the issue here, I think:

export module internalname;

constexpr int radix_16 = 16;

export {
  int foo(int in = radix_16) {
return in;
  }
}

I *think* this is legal module code and MSVC as well as clang do accept it.
However it is a weird edge case. This also isn't exclusive to default function
arguments, you can trigger the same issue with templates:

export module internalname;

constexpr int radix_16 = 16;

template 
inline auto do_from_chars() -> T {
  if (Param > 4) {
return 5;
  }
  else {
return 4;
  }
}

export {
  template  struct parse_number {
auto operator()() -> T {
  return do_from_chars();
}
  };
}

Specifically gcc seems to be overly strict here in how it handles internal
linkage entities, that are required on the call site for default parameters or
template instantiations.

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

[muecker at gwdg dot de via Gcc-bugs]

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

--- Comment #48 from Martin Uecker  ---
Indicating a null terminated string should certainly use a different attribute
name.

[Bug c/108896] provide "element_count" attribute to give more context to __builtin_dynamic_object_size() and -fsanitize=bounds

[tg at mirbsd dot org via Gcc-bugs]

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

Thorsten Glaser  changed:

   What|Removed |Added

 CC||tg at mirbsd dot org

--- Comment #47 from Thorsten Glaser  ---
Regarding the proposed attribute: it would also be really great if I could do…

struct foo {
int type;
char name[] __attribute__((__element_count__(0)));
};

… to denote name[] is a NUL-terminated string.

This also allows, although not static, bounds checking for most of the use
cases not covered by a counting member (optionally multiplied by an extra
factor).

[Bug libstdc++/111685] Segfault while sorting on array element address

[knoepfel at fnal dot gov via Gcc-bugs]

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

Kyle Knoepfel  changed:

   What|Removed |Added

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

--- Comment #11 from Kyle Knoepfel  ---
@Xi Ruoyao's comment above re. strict weak ordering of values and not object
addresses is persuasive.  Thank you for your time and for clarifying my
misconceptions.

[Bug middle-end/111699] [14 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #4 from Andrew Pinski  ---
I have a patch.

[Bug c++/111710] [modules] ICE when compiling module where a lambda is assigned to a field in an exported class

[nicolas.werner at hotmail dot de via Gcc-bugs]

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

--- Comment #2 from Nicolas Werner  ---
I don't really have sufficient knowledge to push this patch forward, since that
currently exceeds my skillset. As such I have no confidence this patch is
actually doing something beneficial, which is why I didn't submit it to the
mailing list, so that I could gather either more knowledge about that issue or
someone else might know how to fix it. Should I still submit it to the mailing
list in this case?

[Bug c++/111710] [modules] ICE when compiling module where a lambda is assigned to a field in an exported class

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

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

--- Comment #1 from Andrew Pinski  ---
Patches should be sent to gcc-patches@ after reading
https://gcc.gnu.org/contribute.html .

[Bug c++/111710] New: [modules] ICE when compiling module where a lambda is assigned to a field in an exported class

[nicolas.werner at hotmail dot de via Gcc-bugs]

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

Bug ID: 111710
   Summary: [modules] ICE when compiling module where a lambda is
assigned to a field in an exported class
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nicolas.werner at hotmail dot de
  Target Milestone: ---

Created attachment 56063
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56063=edit
Patch which prevents the ICE when assigning a lambda to a field inside an
exported entity

Reduced minimal example:

export module argparse;

export {

  struct Argument {
int (*i)(int) = 
  [](int value) { return value; };
  };

}


When compiling this example with "g++ -std=c++23  -fmodules-ts  -x c++ -o
argparse.ixx.o -c argparse.ixx" it produces the following crash:

0x5583c3e758bb crash_signal
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231001/gcc-14-20231001/gcc/toplev.cc:314
0x7f2a9658041f ???
   
/usr/src/debug/sys-libs/glibc-2.38-r5/glibc-2.38/signal/../sysdeps/unix/sysv/linux/x86_64/libc_sigaction.c:0
0x5583c3627ea5 trees_out::key_mergeable(int, merge_kind, tree_node*,
tree_node*, tree_node*, depset*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231001/gcc-14-20231001/gcc/cp/module.cc:10651
0x5583c36220e8 trees_out::decl_value(tree_node*, depset*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231001/gcc-14-20231001/gcc/cp/module.cc:7786
0x5583c362abd2 depset::hash::find_dependencies(module_state*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231001/gcc-14-20231001/gcc/cp/module.cc:13328
0x5583c362ba29 module_state::write_begin(elf_out*, cpp_reader*,
module_state_config&, unsigned int&)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231001/gcc-14-20231001/gcc/cp/module.cc:17895
0x5583c362d0b4 finish_module_processing(cpp_reader*)
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231001/gcc-14-20231001/gcc/cp/module.cc:20241
0x5583c35af85d c_parse_final_cleanups()
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231001/gcc-14-20231001/gcc/cp/decl2.cc:5255
0x5583c381d2fd c_common_parse_file()
   
/usr/src/debug/sys-devel/gcc-14.0.0_pre20231001/gcc-14-20231001/gcc/c-family/c-opts.cc:1296

This is because the lambda is treated as a field by trees_out::get_merge_kind,
but the corresponding case in trees_out::key_mergeable can't find such a field
and then runs over the end of the linked list and dereferences a nullptr.

I am not sure, what the proper mergeable kind is for such a lambda. I tried
changing it to be MK_unique, which seems to fix the crash, but I don't know
what the consequences of that would be. I would assume MK_keyed to be the right
value, however I couldn't make that work. Alternatively possibly the
key_mergeable needs to be adapted to handle such fields properly, but since
this is my first time touching the gcc codebase, I find that part of the code
to be a bit hard to wrap my head around.

I have attached the patch, which changes the mergekind  to demonstrate the
problem area as well as included a test case in that patch. Maybe that can help
solving that issue properly.

I tested this with 13.2.1_p20230826 and 14.0.0_pre20231001.

[Bug regression/111709] [13 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c

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

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

John David Anglin  changed:

   What|Removed |Added

 CC||jsm28 at gcc dot gnu.org

--- Comment #7 from John David Anglin  ---
Joseph, is there a way to simplify the glibc test to the failing cases?

Maybe you have a clue as to what has changed.

[Bug c/111708] Calling external global function instead of local static function.

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

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

--- Comment #2 from Andrew Pinski  ---
Note ICC rejects this as invalid:
```
(14): error #172: external/internal linkage conflict with previous
declaration at line 10
  int f(int);
  ^
```

Which is what I had expected to happen similar to variables as PR 90472 rejects
variable declarations too.

[Bug c/111708] Calling external global function instead of local static function.

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90472#c3

[Bug regression/111709] [13 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c

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

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

--- Comment #6 from John David Anglin  ---
Created attachment 56062
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56062=edit
Diff between s_fma_12.s and s_fma_13.s

[Bug regression/111709] [13 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c

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

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

--- Comment #5 from John David Anglin  ---
Created attachment 56061
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56061=edit
non pic .s file for s_fma.c generated using gcc-13 without debug info

[Bug target/108396] [12/13 Regression] PPCLE: vec_vsubcuq missing since r12-5752-gd08236359eb229

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

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

Carl Love  changed:

   What|Removed |Added

 CC||carll at gcc dot gnu.org

--- Comment #9 from Carl Love  ---
I made a copy of rs6000-overload.def and then with a series of emacs macros
converted the list of builtins to a script to grep for the builtins in the test
directory.  Specifically from rs6000-overload.def:

[BCDADD, __builtin_bcdadd, __builtin_vec_bcdadd]
  vsq __builtin_vec_bcdadd (vsq, vsq, const int);
BCDADD_V1TI
  vuc __builtin_vec_bcdadd (vuc, vuc, const int);
BCDADD_V16QI

[BCDADD_EQ, __builtin_bcdadd_eq, __builtin_vec_bcdadd_eq]
  signed int __builtin_vec_bcdadd_eq (vsq, vsq, const int);
BCDADD_EQ_V1TI
  signed int __builtin_vec_bcdadd_eq (vuc, vuc, const int);
BCDADD_EQ_V16QI



Was converted to the bash script:

rm -f ../test1_not_found 

NOT_FOUND='0   0   0'
check_name () {
  str1=$(grep -r  $1 * | wc)

#  echo " output of command: $str1"

  if [[ "$str1" == *"$NOT_FOUND"* ]]; then
echo "$1 not found" >> ../test1_not_found
  fi
}

check_name "__builtin_bcdadd" "__builtin_vec_bcdadd"

check_name "__builtin_bcdadd_eq" "__builtin_vec_bcdadd_eq"



The script is passed the user built-in name ($str1) and the internal built-in
name ($str2).  I ran the script in directory gcc/testsuite/gcc.target/powerpc
and it identified two tests ($str1) as not showing up in a test file.  The
tests were:  __builtin_bcdsub_ge and __builtin_bcdsub_le.

I figure if the first builtin name has a test associated with it that should be
sufficient.  I will create a patch to add testcases for the two missing
builtin-names.

I did add to the script to see how many definitions have a test for the
built-in name $1 but not the built-in name $2 doesn't show up in a test file. 
My script identified 86 of these cases.  Not sure that we really need to add
test cases for the internal builtin name ($str).  Thoughts?

[Bug regression/111709] [13 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c

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

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

--- Comment #4 from John David Anglin  ---
Created attachment 56060
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56060=edit
non pic .s file for s_fma.c generated using gcc-12 without debug info

[Bug regression/111709] [13 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c

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

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

--- Comment #3 from John David Anglin  ---
Created attachment 56059
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56059=edit
.s file for s_fma.c generated using gcc-13

[Bug regression/111709] [13 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c

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

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

--- Comment #2 from John David Anglin  ---
Created attachment 56058
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56058=edit
.s file for s_fma.c generated using gcc-12

[Bug regression/111709] [13 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c

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

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

--- Comment #1 from John David Anglin  ---
Created attachment 56057
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56057=edit
Preprocessed source generated using gcc-13

[Bug middle-end/111699] [14 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #3 from Andrew Pinski  ---
this was exposed by my commit (r14-3350-g47b833a9abe1) which added:
/* Likewise for view_convert of nop_conversions. */
(simplify
 (view_convert (vec_cond:s @0 @1 @2))
 (if (VECTOR_TYPE_P (type) && VECTOR_TYPE_P (TREE_TYPE (@1))
  && known_eq (TYPE_VECTOR_SUBPARTS (type),
   TYPE_VECTOR_SUBPARTS (TREE_TYPE (@1)))
  && tree_nop_conversion_p (TREE_TYPE (type), TREE_TYPE (TREE_TYPE (@1
  (vec_cond @0 (view_convert! @1) (view_convert! @2

Before we have a VIEW_CONVERT around the vec_cond which prevented the infinite
loop but now we don't ...

[Bug regression/111709] New: [13 Regression] Miscompilation of sysdeps/ieee754/dbl-64/s_fma.c

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

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

Bug ID: 111709
   Summary: [13 Regression] Miscompilation of
sysdeps/ieee754/dbl-64/s_fma.c
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: danglin at gcc dot gnu.org
  Target Milestone: ---
  Host: hppa*-*-linux*
Target: hppa*-*-linux*
 Build: hppa*-*-linux*

Created attachment 56056
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56056=edit
Preproccessed source generated using gcc-12

This fail occurs with gcc version 13.1.0 (Debian 13.1.0-8) in the .

dave@mx3210:~/gnu/glibc/objdir$ make test t=math/test-double-fma
make -r PARALLELMFLAGS="" -C ../glibc objdir=`pwd` test
make[1]: Entering directory '/home/dave/gnu/glibc/glibc'
make subdir=math -C math/ ..=../
/home/dave/gnu/glibc/objdir/math/test-double-fma.out
make[2]: Entering directory '/home/dave/gnu/glibc/glibc/math'
gcc -o /home/dave/gnu/glibc/objdir/math/test-double-fma -nostdlib -nostartfiles
-Wl,-z,relro  /home/dave/gnu/glibc/objdir/csu/crt1.o
/home/dave/gnu/glibc/objdir/csu/crti.o `gcc  --print-file-name=crtbegin.o`
/home/dave/gnu/glibc/objdir/math/test-double-fma.o
/home/dave/gnu/glibc/objdir/support/libsupport_nonshared.a
/home/dave/gnu/glibc/objdir/math/libm-test-support-double.o
/home/dave/gnu/glibc/objdir/math/libm.so.6  -Wl,-dynamic-linker=/lib/ld.so.1
-Wl,-rpath-link=/home/dave/gnu/glibc/objdir:/home/dave/gnu/glibc/objdir/math:/home/dave/gnu/glibc/objdir/elf:/home/dave/gnu/glibc/objdir/dlfcn:/home/dave/gnu/glibc/objdir/nss:/home/dave/gnu/glibc/objdir/nis:/home/dave/gnu/glibc/objdir/rt:/home/dave/gnu/glibc/objdir/resolv:/home/dave/gnu/glibc/objdir/mathvec:/home/dave/gnu/glibc/objdir/support:/home/dave/gnu/glibc/objdir/crypt:/home/dave/gnu/glibc/objdir/nptl
-lgcc -Wl,--as-needed -lgcc_s  -Wl,--no-as-needed
/home/dave/gnu/glibc/objdir/libc.so.6
/home/dave/gnu/glibc/objdir/libc_nonshared.a -Wl,--as-needed
/home/dave/gnu/glibc/objdir/elf/ld.so -Wl,--no-as-needed -lgcc -Wl,--as-needed
-lgcc_s  -Wl,--no-as-needed `gcc  --print-file-name=crtend.o`
/home/dave/gnu/glibc/objdir/csu/crtn.o
env GCONV_PATH=/home/dave/gnu/glibc/objdir/iconvdata
LOCPATH=/home/dave/gnu/glibc/objdir/localedata LC_ALL=C  
/home/dave/gnu/glibc/objdir/elf/ld.so.1 --library-path
/home/dave/gnu/glibc/objdir:/home/dave/gnu/glibc/objdir/math:/home/dave/gnu/glibc/objdir/elf:/home/dave/gnu/glibc/objdir/dlfcn:/home/dave/gnu/glibc/objdir/nss:/home/dave/gnu/glibc/objdir/nis:/home/dave/gnu/glibc/objdir/rt:/home/dave/gnu/glibc/objdir/resolv:/home/dave/gnu/glibc/objdir/mathvec:/home/dave/gnu/glibc/objdir/support:/home/dave/gnu/glibc/objdir/crypt:/home/dave/gnu/glibc/objdir/nptl
/home/dave/gnu/glibc/objdir/math/test-double-fma  >
/home/dave/gnu/glibc/objdir/math/test-double-fma.out; \
../scripts/evaluate-test.sh math/test-double-fma $? false false >
/home/dave/gnu/glibc/objdir/math/test-double-fma.test-result
make[2]: Leaving directory '/home/dave/gnu/glibc/glibc/math'
FAIL: math/test-double-fma
original exit status 1
testing double (without inline functions)
Failure: fma (-0x7.p-1024, 0x8.8p-4, -0x4p-1076):
Exception "Underflow" set
Failure: fma (0x7.p-1024, 0x8.8p-4, 0x4p-1076):
Exception "Underflow" set
Failure: fma_downward (-0x4p-1076, 0x8.8p-4, -0x3.cp-1024):
Exception "Underflow" set
Failure: fma_downward (-0x7.p-1024, 0x8.8p-4,
-0x4p-1076): Exception "Underflow" set
Failure: Test: fma_upward (-0x3.ep-712, 0x3.ep-276,
0x3.fcffep-984)
Result:
 is:  1.8348707892449242e-296   0x1.7e7ffp-983
 should be:   1.8348707892449245e-296   0x1.7e800p-983
 difference:  2.7161546124355486e-312   0x0.00080p-1022
 ulp   :  1.
 max.ulp   :  0.
Failure: fma_upward (0x4p-1076, 0x8.8p-4, 0x3.cp-1024): Exception
"Underflow" set
Failure: fma_upward (0x7.p-1024, 0x8.8p-4, 0x4p-1076):
Exception "Underflow" set

Test suite completed:
  2524 test cases plus 2520 tests for exception flags and
2520 tests for errno executed.
  7 errors occurred.
make[1]: Leaving directory '/home/dave/gnu/glibc/glibc'

Test doesn't fail with gcc-12.

Similar fails:
FAIL: math/test-double-ldouble-fma
FAIL: math/test-float32x-float64-fma
FAIL: math/test-float32x-fma
FAIL: math/test-float64-fma
FAIL: math/test-ldouble-fma

If s_fma.c is compiled with gcc-12, these fma fails don't occur.

This is glibc BZ 30664.

This is compile command for s_fma.c:

gcc-13 ../sysdeps/ieee754/dbl-64/s_fma.c -c -std=gnu11 -fgnu89-inline  -g -O2
-Wall -Wwrite-strings -Wundef -Werror -fmerge-all-constants -frounding-math
-fno-stack-protector -fno-common -Wp,-U_FORTIFY_SOURCE -Wstrict-prototypes
-Wold-style-definition -fno-math-errno

[Bug libstdc++/92798] -fshort-enums can break iterators of std::map

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

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

--- Comment #5 from Andrew Pinski  ---
(In reply to Joseph Tilahun from comment #4)
> Is there a reason why the _Rb_tree_color
> enum does not have an explicit underlying type?

Yes because it has to work with C++98 while enums with underlying types was
only added for C++11.

Again -fshort-enums changes the ABI so you can't use that option unless you
compile everything with it.

[Bug c/111708] New: Calling external global function instead of local static function.

[k.frolov at samsung dot com via Gcc-bugs]

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

Bug ID: 111708
   Summary: Calling external global function instead of local
static function.
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: k.frolov at samsung dot com
  Target Milestone: ---

I have a test case, in which as I believe GCC compiler must call local static
function but not external function instead. This test case work as I expect
with clang compiler, with gcc in C++ mode, but in C mode I have strange
behaviour when gcc tries to call external function instead of already defined
local function with same name.

The problem is reproducible with any available GCC version, starting from GCC
4.1 and ending with current trunk.

The problem is independend from the target platform and reproducible when
generating code for any platform. In following examples aarch64 is used as
target platform.

The problem depends on optimization options: with option "-O0" compiler
behaviour changes (see below).

/ Test code (.c source):

static int f(int);

int main(int argc, const char *argv[])
{
(void)argv;
return f(argc);
}

static int f(int f)
{
int x = f;
{
int f(int);

if (x < 1)
return 0;
else
return f(x - 1);
}
}

 end of test source.

Code compiled with the following compiler options: 

-std=c99 -Wall -Wextra -fstrict-aliasing -Wcast-align -Os

With the following compilator options clang and gcc in C++ mode (with command
line option "-x c") produces same output:

main:
mov w0, 0
ret

GCC in C mode produces following output:

main:
cmp w0, 0
ble .L2
sub w0, w0, #1
b   f
.L2:
mov w0, 0
ret

Where "f" is some unknown and global symbol.

With optimization turned off, following code is generated by GCC in C-mode:

.global main
.type   main, %function
main:
stp x29, x30, [sp, -32]!
mov x29, sp
str w0, [sp, 28]
str x1, [sp, 16]
ldr w0, [sp, 28]
bl  f
ldp x29, x30, [sp], 32
ret

.type   f, %function
f:
stp x29, x30, [sp, -48]!
mov x29, sp
str w0, [sp, 28]
ldr w0, [sp, 28]
str w0, [sp, 44]
ldr w0, [sp, 44]
cmp w0, 0
bgt .L4
mov w0, 0
b   .L5
.L4:
ldr w0, [sp, 44]
sub w0, w0, #1
bl  f
.L5:
ldp x29, x30, [sp], 48
ret


As you see, external symbol "f" is not referenced anymore, as compiler defines
"f" function by itself. Please note, there is neither ".local" nor ".global"
instruction for fuction "f". 

Code generated with "-O0" in C mode is (almost, differencies exist due to
symbol mangling) same as code generated with "-O0" in C++ mode. 

Link to godbolt site demonstrating the effect: https://godbolt.org/z/7d9GG8KvY

[Bug libstdc++/92798] -fshort-enums can break iterators of std::map

[josephttilahun at gmail dot com via Gcc-bugs]

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

Joseph Tilahun  changed:

   What|Removed |Added

 CC||josephttilahun at gmail dot com

--- Comment #4 from Joseph Tilahun  ---
I encountered this same bug when using -fshort-enums with std::map iterators.

The fact that -fshort-enums breaks std::map iterators implies that there's an
enum somewhere without an explicit underlying type. In
/usr/include/c++/9/bits/stl_tree.h, there's an enum that enumerates the
possible colors of a node of a red-black tree:

  enum _Rb_tree_color { _S_red = false, _S_black = true };

  struct _Rb_tree_node_base
  {
typedef _Rb_tree_node_base* _Base_ptr;
typedef const _Rb_tree_node_base* _Const_Base_ptr;

_Rb_tree_color  _M_color;
_Base_ptr   _M_parent;
_Base_ptr   _M_left;
_Base_ptr   _M_right;

// Other code that's not relevant
  }

The _Rb_tree_color enum does not have an explicit underlying type. I tried
modifying this to:

  enum _Rb_tree_color : int { _S_red = false, _S_black = true };

  struct _Rb_tree_node_base
  {
typedef _Rb_tree_node_base* _Base_ptr;
typedef const _Rb_tree_node_base* _Const_Base_ptr;

_Rb_tree_color  _M_color;
_Base_ptr   _M_parent;
_Base_ptr   _M_left;
_Base_ptr   _M_right;

// Other code that's not relevant
  }

and -fshort-enums does not break this. I also tried modifying this to:

  enum _Rb_tree_color { _S_red = false, _S_black = true };

  struct _Rb_tree_node_base
  {
typedef _Rb_tree_node_base* _Base_ptr;
typedef const _Rb_tree_node_base* _Const_Base_ptr;

int _M_color;
_Base_ptr   _M_parent;
_Base_ptr   _M_left;
_Base_ptr   _M_right;

// Other code that's not relevant
  }

and -fshort-enums does not break this.

It seems to me that the _Rb_tree_color enum is the real problem. -fshort-enums
simply exposes the fact that the _Rb_tree_color enum does not have an explicit
underlying type. Is there a reason why the _Rb_tree_color enum does not have an
explicit underlying type?

[Bug middle-end/111699] [14 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

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

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

--- Comment #2 from Andrew Pinski  ---
(simplify
 (vec_cond (vec_cond:s @0 @3 integer_zerop) @1 @2)
 (if (optimize_vectors_before_lowering_p () && types_match (@0, @3))
  (vec_cond (bit_and @0 @3) @1 @2)))

goes into an infinite loop with fold_build3 as the fold_build2:BIT_AND of:
(gdb) p debug_generic_expr(captures[1])
v == { 0, 0, 0, 0, 0, 0, 0, 0 }
$9 = void
(gdb) p debug_generic_expr(captures[2])
{ 0, -1, -1, -1, -1, -1, -1, -1 }

Creates a vec_cond ...

[Bug libgomp/111707] New: omp_target_alloc and omp_target_is_present - corner case handling & spec conformance

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

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

Bug ID: 111707
   Summary: omp_target_alloc and omp_target_is_present - corner
case handling & spec conformance
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: documentation, 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
  Target Milestone: ---

To be checked / updated.

Besides fixing the code, also libgomp.texi needs to be updated.

omp_target_alloc:
  For size == 0, the spec meanwhile requires that NULL is returned.

  However, we call 'malloc' on the host which might return a
  a non-NULL pointer that can be passed to 'free'.
  And on the device side, an GOMP_error diagnostic is printed
  to stderr for nvptx and gcn if the allocation fails.
  Both the HSA and CUDA documentation imply that size==0 is
  an error.

omp_target_is_present
  OpenMP states that this functions checks whether the pointer is
  mapped.
  In GCC, we also return 'true' for shared memory systems and
  for the device_num being the host.
  The question is whether that's OK or not.
  Does a SELF MAP qualify or not?
  (self map - A mapping operation that, when corresponding storage is not
   already present, results in corresponding storage that is the same as
   its original storage.)

  [The current behavior is about to be documented, but we can
   change it.]

[Bug middle-end/111699] [14 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2023-10-05
 Target|aarch64-unknown-linux-gnu   |
 Status|UNCONFIRMED |NEW
   Host|x86_64-pc-linux-gnu |
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Here is a testcase which fails everywhere:
```
typedef unsigned char __attribute__((__vector_size__ (8))) V;

V
foo (V v)
{
  return (V) 0x107B9A7FF >= (v <= 0);
}
```

AARCH64 defaults to unsigned char which is why it fails there with the original
testcase.

[Bug target/111704] ICE in extract_insn, at recog.cc:2791 on aarch64-linux-gnu during RTL pass: cprop_hardreg

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #1 from Andrew Pinski  ---
Dup of bug 111411.

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

[Bug target/111411] [14 regression] ICE when building opus-1.4, unrecognizable insn with -fstack-protector-strong

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||Simon.Richter at hogyros dot de

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

[Bug ipa/111283] [14 Regression] gnat profilebootstrap broken on trunk 20230902 on 32bit targets

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |slyfox at gcc dot 
gnu.org

--- Comment #11 from Sergei Trofimovich  ---
Should be fixed in master.

Thank you for the report!

[Bug c/110368] Incorrect "is used uninitialized" warning message

[clugstj at gmail dot com via Gcc-bugs]

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

--- Comment #6 from Jon Clugston  ---
So, "undefined behavior" gives the compiler license to output any warning it
wants?

The warning message is utterly wrong and completely misleading.

[Bug gcov-profile/111559] [14 regression] ICE when building Python with PGO

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

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

Sergei Trofimovich  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED
   Assignee|unassigned at gcc dot gnu.org  |slyfox at gcc dot 
gnu.org

--- Comment #10 from Sergei Trofimovich  ---
Fixed in master.

Thanks for the report!

[Bug gcov-profile/111559] [14 regression] ICE when building Python with PGO

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by Sergei Trofimovich :

https://gcc.gnu.org/g:043a6fcbc27f8721301eb2f72a7839f54f393003

commit r14-4421-g043a6fcbc27f8721301eb2f72a7839f54f393003
Author: Sergei Trofimovich 
Date:   Wed Sep 27 14:29:12 2023 +0100

ipa-utils: avoid uninitialized probabilities on ICF [PR111559]

r14-3459-g0c78240fd7d519 "Check that passes do not forget to define
profile"
exposed check failures in cases when gcc produces uninitialized profile
probabilities. In case of PR/111559 uninitialized profile is generated
by edges executed 0 times reported by IPA profile:

$ gcc -O2 -fprofile-generate pr111559.c -o b -fopt-info
$ ./b
$ gcc -O2 -fprofile-use -fprofile-correction pr111559.c -o b -fopt-info

pr111559.c: In function 'rule1':
pr111559.c:6:13: error: probability of edge 3->4 not initialized
6 | static void rule1(void) { if (p) edge(); }
  | ^
during GIMPLE pass: fixup_cfg
pr111559.c:6:13: internal compiler error: verify_flow_info failed

The change conservatively ignores updates with zero execution counts and
uses initially assigned probabilities (`always` probability in case of
the example).

PR ipa/111283
PR gcov-profile/111559

gcc/
* ipa-utils.cc (ipa_merge_profiles): Avoid producing
uninitialized probabilities when merging counters with zero
denominators.

gcc/testsuite/
* gcc.dg/tree-prof/pr111559.c: New test.

[Bug ipa/111283] [14 Regression] gnat profilebootstrap broken on trunk 20230902 on 32bit targets

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

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

--- Comment #10 from CVS Commits  ---
The master branch has been updated by Sergei Trofimovich :

https://gcc.gnu.org/g:043a6fcbc27f8721301eb2f72a7839f54f393003

commit r14-4421-g043a6fcbc27f8721301eb2f72a7839f54f393003
Author: Sergei Trofimovich 
Date:   Wed Sep 27 14:29:12 2023 +0100

ipa-utils: avoid uninitialized probabilities on ICF [PR111559]

r14-3459-g0c78240fd7d519 "Check that passes do not forget to define
profile"
exposed check failures in cases when gcc produces uninitialized profile
probabilities. In case of PR/111559 uninitialized profile is generated
by edges executed 0 times reported by IPA profile:

$ gcc -O2 -fprofile-generate pr111559.c -o b -fopt-info
$ ./b
$ gcc -O2 -fprofile-use -fprofile-correction pr111559.c -o b -fopt-info

pr111559.c: In function 'rule1':
pr111559.c:6:13: error: probability of edge 3->4 not initialized
6 | static void rule1(void) { if (p) edge(); }
  | ^
during GIMPLE pass: fixup_cfg
pr111559.c:6:13: internal compiler error: verify_flow_info failed

The change conservatively ignores updates with zero execution counts and
uses initially assigned probabilities (`always` probability in case of
the example).

PR ipa/111283
PR gcov-profile/111559

gcc/
* ipa-utils.cc (ipa_merge_profiles): Avoid producing
uninitialized probabilities when merging counters with zero
denominators.

gcc/testsuite/
* gcc.dg/tree-prof/pr111559.c: New test.

[Bug target/111657] Memory copy with structure assignment from named address space should be improved

[ubizjak at gmail dot com via Gcc-bugs]

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

Uroš Bizjak  changed:

   What|Removed |Added

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

--- Comment #7 from Uroš Bizjak  ---
Fixed.

[Bug target/111657] Memory copy with structure assignment from named address space should be improved

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

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

--- Comment #6 from CVS Commits  ---
The master branch has been updated by Uros Bizjak :

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

commit r14-4418-gc6bff80d786919f2f64e8a9f3179d6d36888bdb3
Author: Uros Bizjak 
Date:   Thu Oct 5 17:40:37 2023 +0200

i386: Improve memory copy from named address space [PR111657]

The stringop strategy selection algorithm falls back to a libcall strategy
when it exhausts its pool of available strategies.  The memory area copy
function (memcpy) is not availabe from the system library for non-default
address spaces, so the compiler emits the most trivial byte-at-a-time
copy loop instead.

The compiler should instead emit an optimized copy loop as a fallback for
non-default address spaces.

PR target/111657

gcc/ChangeLog:

* config/i386/i386-expand.cc (alg_usable_p): Reject libcall
strategy for non-default address spaces.
(decide_alg): Use loop strategy as a fallback strategy for
non-default address spaces.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr111657.c: New test.

[Bug c++/111703] [12/13/14 Regression] [C++20]Compiler fails when using generic lambda in specific situation

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||c++-lambda

--- Comment #1 from Andrew Pinski  ---
Note I reduced a related testcase into PR 111705 but that fails even for
template functions rather than templated lamdbas (which is what generic lamdbas
are really).

[Bug c++/111703] [12/13/14 Regression] [C++20]Compiler fails when using generic lambda in specific situation

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.4

[Bug c++/111705] [12/13/14 Regression] use of concepted copy constructored struct inside a template function messes up with -fchecking=2

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|13.3|12.4

[Bug c++/111705] [13/14 Regression] use of concepted copy constructored struct inside a template function messes up with -fchecking=2

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||13.1.0
  Known to work||12.3.0
Summary|use of concepted copy   |[13/14 Regression] use of
   |constructored struct inside |concepted copy
   |a template function messes  |constructored struct inside
   |up with -fchecking=2|a template function messes
   ||up with -fchecking=2
   Target Milestone|--- |13.3

[Bug c++/111705] use of concepted copy constructored struct inside a template function messes up with -fchecking=2

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

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

--- Comment #2 from Andrew Pinski  ---
Actually this is rejected in previous versions of GCC via -fchecking=2 option
...

[Bug c++/111705] use of concepted copy constructored struct inside a template function messes up with -fchecking=2

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|14.0|---
Summary|[14 Regression] use of  |use of concepted copy
   |concepted copy  |constructored struct inside
   |constructored struct inside |a template function messes
   |a template function messes  |up with -fchecking=2
   |up  |

[Bug c++/111705] [14 Regression] use of concepted copy constructored struct inside a template function messes up

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |14.0

--- Comment #1 from Andrew Pinski  ---
Note changing f1 to a non-template, also allows the code to be accepted.

[Bug c++/111705] New: [14 Regression] use of concepted copy constructored struct inside a template function messes up

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

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

Bug ID: 111705
   Summary: [14 Regression] use of concepted copy constructored
struct inside a template function messes up
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
template concept c = true;
template
struct ts
{
  template
   requires(c)
ts(const ts&);
  template
   requires(!c)
ts(const ts&) = delete;
  ts() = default;
};


using P = ts;
void (*f)(P);
template
void f1()
{  
  P x;
  f(x);
}
```
This gets rejected with the following (bogus) error message:
```
: In substitution of 'template  requires !(c)
ts::ts(const ts&) [with T1 = int]':
:21:5:   required from here
   21 |   f(x);
  | ^
:10:3:   required by the constraints of 'template
template  requires !(c) ts::ts(const ts&)'
:9:12: error: satisfaction value of atomic constraint '!(c) [with
T1 = int]' changed from '' to 'false'
9 |   requires(!c)
  |   ~^~~
:21:5: note: satisfaction value first evaluated to ''
from here
   21 |   f(x);
  | ^
```

This was reduced from PR 111703 (but is different since this was accepted
before  in GCC 13)

[Bug target/111704] New: ICE in extract_insn, at recog.cc:2791 on aarch64-linux-gnu during RTL pass: cprop_hardreg

[Simon.Richter at hogyros dot de via Gcc-bugs]

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

Bug ID: 111704
   Summary: ICE in extract_insn, at recog.cc:2791 on
aarch64-linux-gnu during RTL pass: cprop_hardreg
   Product: gcc
   Version: 12.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: Simon.Richter at hogyros dot de
  Target Milestone: ---

While [building GHDL 3.0.0]() on Debian, using gcc 12 as a base, we get an ICE:

aarch64-linux-gnu-gcc-12 -c -I./ -I../../src -I../../src/vhdl -I../../src/synth
-I../../src/grt -I../../src/psl -I../../src/vhdl/translate -I../../src/ghdldrv
-I../../src/ortho -I../../src/ortho/llvm6 -I../../src/synth -I../../src/ghdldrv
-gnat12 -gnaty3befhkmr -g -gnatwa -gnatwC -gnatf -g -O2
-ffile-prefix-map=/<>=. -fstack-protector-strong
-fstack-clash-protection -mbranch-protection=standard -gno-record-gcc-switches
-gnata -I- /<>/src/synth/synth-disp_vhdl.adb
/<>/src/ghdldrv/ghdldrv.adb: In function ‘Ghdldrv.Gen_Makefile’:
/<>/src/ghdldrv/ghdldrv.adb:2022:8: error: unrecognizable insn:
(insn 1387 147 204 13 (parallel [
(set (mem/c:SI (plus:DI (reg/f:DI 29 x29)
(const_int -260 [0xfefc])) [36 files_it+4
S4 A32])
(reg:SI 2 x2 [244]))
(set (mem/c:SI (plus:DI (reg/f:DI 29 x29)
(const_int -256 [0xff00])) [36 files_it+8
S4 A64])
(reg:SI 1 x1 [604]))
]) "/<>/src/ghdldrv/ghdldrv.adb":1926:19 -1
 (expr_list:REG_DEAD (reg:SI 2 x2 [244])
(expr_list:REG_DEAD (reg:SI 1 x1 [604])
(nil
during RTL pass: cprop_hardreg
+===GNAT BUG DETECTED==+
| 12.3.0 (aarch64-linux-gnu) in extract_insn, at recog.cc:2791 |
| Error detected around /<>/src/ghdldrv/ghdldrv.adb:2022:8|
| Compiling /<>/src/ghdldrv/ghdldrv.adb|
| Please submit a bug report; see https://gcc.gnu.org/bugs/ .  |
| Use a subject line meaningful to you and us to track the bug.|
| Include the entire contents of this bug box in the report.   |
| Include the exact command that you entered.  |
| Also include sources listed below.   |
+==+

Full build log is at
https://buildd.debian.org/status/fetch.php?pkg=ghdl=arm64=3.0.0%2Bdfsg2-1=1696130520=0

I have access to a test machine and an interest to get this package to work, so
if there are things I can do to help triaging this, please tell me.

[Bug c++/111703] New: [C++20]Compiler fails when using generic lambda in specific situation

[watanabemakoto.math at gmail dot com via Gcc-bugs]

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

Bug ID: 111703
   Summary: [C++20]Compiler fails when using generic lambda in
specific situation
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: watanabemakoto.math at gmail dot com
  Target Milestone: ---

Consider the example:

```
#include 
using P = std::pair;
void (*f)(P);

int main(){
[](auto) {
P x;
f(x);
};
}
```

GCC 13.2.0 fails to compile the example. Compile option is `-std=c++20` .

Godbolt playground: https://godbolt.org/z/nPMb38ond

[Bug rtl-optimization/111702] New: [14 Regression] ICE: in insert_regs, at cse.cc:1114 with -O2 -fstack-protector-all -frounding-math

[zsojka at seznam dot cz via Gcc-bugs]

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

Bug ID: 111702
   Summary: [14 Regression] ICE: in insert_regs, at cse.cc:1114
with -O2 -fstack-protector-all -frounding-math
   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: aarch64-unknown-linux-gnu

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

Compiler output:
$ aarch64-unknown-linux-gnu-gcc -O2 -fstack-protector-all -frounding-math
testcase.c -w
during RTL pass: cse2
testcase.c: In function 'foo':
testcase.c:108:1: internal compiler error: in insert_regs, at cse.cc:1114
  108 | }
  | ^
0xb01a00 insert_regs
/repo/gcc-trunk/gcc/cse.cc:1114
0x1e0237e merge_equiv_classes
/repo/gcc-trunk/gcc/cse.cc:1758
0x1e08d85 cse_insn
/repo/gcc-trunk/gcc/cse.cc:4780
0x1e0ca53 cse_extended_basic_block
/repo/gcc-trunk/gcc/cse.cc:6557
0x1e0ca53 cse_main
/repo/gcc-trunk/gcc/cse.cc:6702
0x1e0d470 rest_of_handle_cse2
/repo/gcc-trunk/gcc/cse.cc:7600
0x1e0d470 execute
/repo/gcc-trunk/gcc/cse.cc:7655
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.

$ aarch64-unknown-linux-gnu-gcc -v
Using built-in specs.
COLLECT_GCC=/repo/gcc-trunk/binary-latest-aarch64/bin/aarch64-unknown-linux-gnu-gcc
COLLECT_LTO_WRAPPER=/repo/gcc-trunk/binary-trunk-r14-4413-20231005141000-g1f7295af602-checking-yes-rtl-df-extra-aarch64/bin/../libexec/gcc/aarch64-unknown-linux-gnu/14.0.0/lto-wrapper
Target: aarch64-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-sysroot=/usr/aarch64-unknown-linux-gnu --build=x86_64-pc-linux-gnu
--host=x86_64-pc-linux-gnu --target=aarch64-unknown-linux-gnu
--with-ld=/usr/bin/aarch64-unknown-linux-gnu-ld
--with-as=/usr/bin/aarch64-unknown-linux-gnu-as --disable-libstdcxx-pch
--prefix=/repo/gcc-trunk//binary-trunk-r14-4413-20231005141000-g1f7295af602-checking-yes-rtl-df-extra-aarch64
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 14.0.0 20231005 (experimental) (GCC)

[Bug ipa/111157] [14 Regression] 416.gamess fails with a run-time abort when compiled with -O2 -flto after r14-3226-gd073e2d75d9ed4

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

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

--- Comment #9 from Martin Jambor  ---
I have proposed a fix on the mailing list consisting of:
  - https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632042.html and
  - https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632044.html

and an (optional) RFC one
https://gcc.gnu.org/pipermail/gcc-patches/2023-October/632043.html

[Bug ipa/108007] [11/12/13/14 Regression] wrong code at -Os and above with "-fno-dce -fno-tree-dce" on x86_64-linux-gnu

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

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

Martin Jambor  changed:

   What|Removed |Added

 Resolution|FIXED   |---
 Status|RESOLVED|REOPENED

--- Comment #18 from Martin Jambor  ---
I had to revert the patch because it broke bootstrap on ppc64le (see PR
111688).  I'll re visit after I address that failure.

[Bug bootstrap/111688] [14 regression] bootstrap failure after r14-4382-g1be18ea110a2d6

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

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

Martin Jambor  changed:

   What|Removed |Added

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

--- Comment #8 from Martin Jambor  ---
I have reverted the offending commit, ppc64le bootstrap should be restored
(which I also tested, though only with C and C++ to speed it up).  Sorry for
the breakage.

[Bug bootstrap/111688] [14 regression] bootstrap failure after r14-4382-g1be18ea110a2d6

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by Martin Jambor :

https://gcc.gnu.org/g:1f7295af6029b6497e9928fe279fd166b94ce2c2

commit r14-4413-g1f7295af6029b6497e9928fe279fd166b94ce2c2
Author: Martin Jambor 
Date:   Thu Oct 5 14:08:47 2023 +0200

Revert "ipa: Self-DCE of uses of removed call LHSs (PR 108007)"

This reverts commit 1be18ea110a2d69570dbc494588a7c73173883be.

As reported in PR bootstrap/111688, it broke ppc64le bootstrap because
of a debug-compare failure.

[Bug target/111698] Narrow memory access of compare to byte width

[ubizjak at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Uroš Bizjak  ---
(In reply to Richard Biener from comment #1)
> I guess we could do this even on GIMPLE and in general to aligned sub-word
> accesses (where byte accesses are always aligned).
> 
> It might be also a good fit for RTL forwprop or that mem-offset pass in
> development.

I don't think this optimization should be universally enabled. According to
Agner Fog, older x86 cores suffer from store forwarding stall when smaller read
doesn't start at the same address. Intel Sandybridge and AMD Steamroller
families relaxed this constraint.

[Bug bootstrap/111688] [14 regression] bootstrap failure after r14-4382-g1be18ea110a2d6

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

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

Martin Jambor  changed:

   What|Removed |Added

Summary|[14 regression] bootstrap   |[14 regression] bootstrap
   |failure after   |failure after
   |r14-4383-g14d0c509898b03|r14-4382-g1be18ea110a2d6

--- Comment #6 from Martin Jambor  ---
As expected, it is an -fcompare-debug failure:

jamborm@gcc120:/run/user/61070/obj/powerpc64le-unknown-linux-gnu/libstdc++-v3/src$
/run/user/61070/obj/./gcc/xgcc -shared-libgcc -B/run/user/61070/obj/./gcc
-nostdinc++
-L/run/user/61070/obj/powerpc64le-unknown-linux-gnu/libstdc++-v3/src
-L/run/user/61070/obj/powerpc64le-unknown-linux-gnu/libstdc++-v3/src/.libs
-L/run/user/61070/obj/powerpc64le-unknown-linux-gnu/libstdc++-v3/libsupc++/.libs
-B/home/jamborm/gcc/mine/inst/powerpc64le-unknown-linux-gnu/bin/
-B/home/jamborm/gcc/mine/inst/powerpc64le-unknown-linux-gnu/lib/ -isystem
/home/jamborm/gcc/mine/inst/powerpc64le-unknown-linux-gnu/include -isystem
/home/jamborm/gcc/mine/inst/powerpc64le-unknown-linux-gnu/sys-include
-I/run/user/61070/obj/powerpc64le-unknown-linux-gnu/libstdc++-v3/include/powerpc64le-unknown-linux-gnu
-I/run/user/61070/obj/powerpc64le-unknown-linux-gnu/libstdc++-v3/include
-I/run/user/61070/src/libstdc++-v3/libsupc++ -std=gnu++98 -fPIC -DPIC
-fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2
-fdiagnostics-show-location=once -ffunction-sections -fdata-sections
-frandom-seed=compatibility-ldbl.lo -mno-gnu-attribute -g -O2 -D_GNU_SOURCE
-mlong-double-64 -mno-gnu-attribute -c
/run/user/61070/src/libstdc++-v3/src/c++98/compatibility-ldbl.cc  -fPIC -DPIC
-D_GLIBCXX_SHARED -o .libs/compatibility-ldbl.o -fcompare-debug
xgcc: error: /run/user/61070/src/libstdc++-v3/src/c++98/compatibility-ldbl.cc:
‘-fcompare-debug’ failure

[Bug libstdc++/111553] Incorrect visibility of std::format

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

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

--- Comment #2 from Jonathan Wakely  ---
This is now documented as not-a-bug:
https://gcc.gnu.org/bugs/#nonbugs_cxx

[Bug ipa/111643] __attribute__((flatten)) with -O1 runs out of memory (killed cc1)

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

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

Richard Biener  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #8 from Richard Biener  ---
I've amended the documentation, similar to the other duplicates we do not
intend to fix this (or rather we can't), even less so when LTO isn't involved.

[Bug target/104338] RISC-V: Subword atomics result in library calls

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

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

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|--- |13.2

[Bug ipa/111643] __attribute__((flatten)) with -O1 runs out of memory (killed cc1)

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

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

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

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

commit r14-4404-gffbd7c3d0fd1b9b10ef5a0f2b2e64bd234620167
Author: Richard Biener 
Date:   Wed Oct 4 11:19:10 2023 +0200

ipa/111643 - clarify flatten attribute documentation

The following clarifies the flatten attribute documentation to mention
the inlining applies also to calls formed as part of inlining earlier
calls but not calls to the function itself.

PR ipa/111643
* doc/extend.texi (attribute flatten): Clarify.

[Bug middle-end/111701] New: [11/12/13/14 Regression] wrong code for __builtin_signbit(x*x)

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

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

Bug ID: 111701
   Summary: [11/12/13/14 Regression] wrong code for
__builtin_signbit(x*x)
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Keywords: wrong-code
  Severity: normal
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: amonakov at gcc dot gnu.org
CC: amonakov at gcc dot gnu.org, eggert at cs dot ucla.edu,
rguenth at gcc dot gnu.org, unassigned at gcc dot gnu.org
Depends on: 111655
  Target Milestone: ---
Target: x86_64-linux-gnu

+++ This bug was initially created as a clone of Bug #111655 +++

See bug 111655 comment 11: we incorrectly deduce nonnegative_p for
floating-point 'x * x', and the following aborts:

__attribute__((noipa))
static int f(float *x)
{
*x *= *x;
return __builtin_signbit(*x);
}

int main()
{
float x = -__builtin_nan("");
int s = f();
if (s != __builtin_signbit(x))
__builtin_abort();
}


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111655
[Bug 111655] [11/12/13/14 Regression] wrong code generated for
__builtin_signbit and 0./0. on x86-64 -O2

[Bug middle-end/111699] [14 Regression] ICE: SIGSEGV: infinite recursion in fold_build3_loc/fold_ternary_loc/generic_simplify_VEC_COND_EXPR

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

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

Richard Biener  changed:

   What|Removed |Added

   Keywords||needs-bisection
   Target Milestone|--- |14.0

[Bug target/111698] Narrow memory access of compare to byte width

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
I guess we could do this even on GIMPLE and in general to aligned sub-word
accesses (where byte accesses are always aligned).

It might be also a good fit for RTL forwprop or that mem-offset pass in
development.

[Bug tree-optimization/111697] Sub optimal code gen for initialising vector using loop

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

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

--- Comment #3 from Richard Biener  ---
(In reply to Richard Biener from comment #2)
> We have quite some code doing vector CTOR stuff in tree-ssa-forwprop.cc and
> this should be optimized to
> 
>  v_2 = { x_6(D), x_6(D), x_6(D), x_6(D) };
> 
> note SLP vectorization can do this but it fails because it doesn't handle
> a default def insert - it handles a group of BIT_INSERT_EXPRs as
> vector CTOR and SLP discovery doesn't know how to start from external defs
> (it needs actual definition stmts).
> 
> A more general approach would be to try to track vector construction through
> symbolic execution like we form bswap in the bswap pass.

You could "steal" the code in vect_slp_check_for_roots,

  else if (code == BIT_INSERT_EXPR
   && VECTOR_TYPE_P (TREE_TYPE (rhs))
   && TYPE_VECTOR_SUBPARTS (TREE_TYPE (rhs)).is_constant ()
   && TYPE_VECTOR_SUBPARTS (TREE_TYPE (rhs)).to_constant () > 1
   && integer_zerop (gimple_assign_rhs3 (assign))
   && useless_type_conversion_p
(TREE_TYPE (TREE_TYPE (rhs)),
 TREE_TYPE (gimple_assign_rhs2 (assign)))
   && bb_vinfo->lookup_def (gimple_assign_rhs2 (assign)))
{
  /* We start to match on insert to lane zero but since the
 inserts need not be ordered we'd have to search both
 the def and the use chains.  */
...

and put it into tree-ssa-forwprop.cc, explicitly creating the vector CTOR.

[Bug tree-optimization/111697] Sub optimal code gen for initialising vector using loop

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

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

--- Comment #2 from Richard Biener  ---
We have quite some code doing vector CTOR stuff in tree-ssa-forwprop.cc and
this should be optimized to

 v_2 = { x_6(D), x_6(D), x_6(D), x_6(D) };

note SLP vectorization can do this but it fails because it doesn't handle
a default def insert - it handles a group of BIT_INSERT_EXPRs as
vector CTOR and SLP discovery doesn't know how to start from external defs
(it needs actual definition stmts).

A more general approach would be to try to track vector construction through
symbolic execution like we form bswap in the bswap pass.

[Bug middle-end/111696] [11/12/13/14 Regression] Spurious -Wstringop-overflow

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |11.5
 Blocks||88443


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88443
[Bug 88443] [meta-bug] bogus/missing -Wstringop-overflow warnings

[Bug tree-optimization/111694] [13/14 Regression] Wrong behavior for signbit of negative zero when optimizing

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

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

Richard Biener  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com
   Priority|P3  |P2
  Known to work||12.3.0

--- Comment #3 from Richard Biener  ---
Looks like some frange / relation mistake then.

[Bug tree-optimization/98138] BB vect fail to SLP one case

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

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

--- Comment #13 from Richard Biener  ---
(In reply to Jiangning Liu from comment #12)
> Hi Richi,
> 
> > That said, "failure" to identify the common (vector) load is known
> > and I do have experimental patches trying to address that but did
> > not yet arrive at a conclusive "best" approach.
> 
> It was long time ago, so do you have the "best" approach now?

I do have ideas but how it will play out is unknown.  Also the current
priority is to improve maintainability of the code with getting rid of
the non-SLP data structure using paths in the vectorizer.

Next would be to redo loop SLP discovery from scratch which would include
possibly fixing this issue.

> Thanks,
> -Jiangning

[Bug middle-end/111669] bogus -Wnonnull in conditionally executed code

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

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

Xi Ruoyao  changed:

   What|Removed |Added

   Severity|normal  |enhancement

--- Comment #7 from Xi Ruoyao  ---
(In reply to Zeb Figura from comment #6)
> It is my impression that gcc is interested in avoiding false positives for
> its warnings.

Correct, but we are also interested in avoiding false negatives.  Without extra
information provided by something like __builtin_unreachable, any change
decreasing false positives will increase false negatives (unless the false
positive is completely stupid: for the simplified test case I think the false
positive not completely stupid, but maybe it is completely stupid for your
original program).

> It is also my impression that -Wnonnull is not *supposed* to emit warnings
> for cases where, from the compiler's point of view, NULL might be passed,
> but some high-level invariant prevents this. Compare -Wmaybe-uninitialized,
> where the documentation clearly specifies otherwise.

Maybe we can separate -Wnonnull into -Wmaybe-nonnull and -Wnonnull, or just
make -Wnonnull not to emit warnings for conditional paths and tell users
expecting a nonnull warning in conditional paths to use the analyzer (it's very
supposed to warn even in conditional paths) instead.

> If both of these impressions are incorrect, this bug report can be closed as
> WONTFIX.

I'll keep it open but make it an enhancement.

[Bug middle-end/111669] bogus -Wnonnull in conditionally executed code

[zfigura at codeweavers dot com via Gcc-bugs]

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

--- Comment #6 from Zeb Figura  ---
It is my impression that gcc is interested in avoiding false positives for its
warnings. This isn't to say that there aren't some number of false positives in
existence, but it is my impression that gcc is interested in reducing that
number.

It is also my impression that -Wnonnull is not *supposed* to emit warnings for
cases where, from the compiler's point of view, NULL might be passed, but some
high-level invariant prevents this. Compare -Wmaybe-uninitialized, where the
documentation clearly specifies otherwise.

If both of these impressions are incorrect, this bug report can be closed as
WONTFIX.


(In reply to Xi Ruoyao from comment #5)
> And you can tell the compiler some fact about the semantics of the Windoge
> API functions if you really need -Werror=nonnull (though I cannot see any
> reason you must use -Werror here):

If it makes a difference, please feel free to pretend I said -Wnonnull, rather
than -Werror=nonnull. It was merely a debugging aid, meant to help me try to
narrow down the conditions causing this error.