[Bug rtl-optimization/110940] New: ICE at -O3 on x86_64-linux-gnu: in apply_scale, at profile-count.h:1180

[zhendong.su at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 110940
   Summary: ICE at -O3 on x86_64-linux-gnu: in apply_scale, at
profile-count.h:1180
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: zhendong.su at inf dot ethz.ch
  Target Milestone: ---

This appears to be a recent regression.

Compiler Explorer: https://godbolt.org/z/evGMc8xEW

[595] % gcctk -v
Using built-in specs.
COLLECT_GCC=gcctk
COLLECT_LTO_WRAPPER=/local/home/suz/suz-local/software/local/gcc-trunk/bin/../libexec/gcc/x86_64-pc-linux-gnu/14.0.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: ../gcc-trunk/configure --disable-bootstrap
--enable-checking=yes --prefix=/local/suz-local/software/local/gcc-trunk
--enable-sanitizers --enable-languages=c,c++ --disable-werror --enable-multilib
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 14.0.0 20230808 (experimental) (GCC) 
[596] % 
[596] % gcctk -O3 -c small.c
during GIMPLE pass: vect
small.c: In function ‘main’:
small.c:3:5: internal compiler error: in apply_scale, at profile-count.h:1180
3 | int main() {
  | ^~~~
0xab66c3 profile_count::apply_scale(profile_count, profile_count) const
../../gcc-trunk/gcc/profile-count.h:1180
0x10311cf fold_loop_internal_call(gimple*, tree_node*)
../../gcc-trunk/gcc/tree-cfg.cc:7738
0x12d2ef5 execute
../../gcc-trunk/gcc/tree-vectorizer.cc:1328
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.
[597] % 
[597] % cat small.c
int a, b[1], c, *d = , e, f, g, h, i, j;
extern int l();
int main() {
  if (l())
for (;;)
  for (; g;)
for (; e;)
  for (; a;)
for (; f;)
  for (; h;)
for (; i;)
  for (; c;)
for (; j;)
  ;
  l();
  for (; c; c++)
b[*d] = 0;
  return 0;
}

[Bug c++/109181] requires expression type requirement rejects valid type when it is a nested member template

[waffl3x at protonmail dot com via Gcc-bugs]

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

--- Comment #6 from waffl3x  ---
PR 110927 presents a similar use case that originally lead me to this bug, I
also posted the workarounds that I had since discovered there. If anyone coming
across this bug is looking for a solution you can find them there.

[Bug c++/110927] GCC fails to parse dependent type in concept through partial specialization

[waffl3x at protonmail dot com via Gcc-bugs]

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

waffl3x  changed:

   What|Removed |Added

 CC||waffl3x at protonmail dot com

--- Comment #2 from waffl3x  ---
(In reply to Andrew Pinski from comment #1)
> Confirmed, I suspect PR 109181 is the same (or rather reduced example).

Yes, I believe the case danakj wrote here is very close to my original use case
when I first submitted the bug. Since I never got around to recreating it and
posting it I'm thankful this report was made, I had mostly forgotten about it.
I found 2 workarounds so I ended up moving on.

I suspect that the bug isn't related to partial specializations given the
reduced case in PR 109181 doesn't have one, however, my original case also
involved partial specializations so perhaps I am wrong.

Here are the workarounds I mentioned just in case they are useful to danakj.

The first workaround is more modern, not resorting to older techniques.
```
template
concept HasTypeMemberTemplate1 = requires{
typename std::type_identity::template type<>>())>;
};
```

The second workaround uses older techniques.
```
template
struct specialization_has_type_member_template
  : std::false_type {};

template
struct specialization_has_type_member_template::template type<>>>
  : std::true_type {};

template
concept HasTypeMemberTemplate2 = has_valid_adapter_specialization::value;
```

You can see both workarounds in action here, hopefully you can get some use out
of them.
https://godbolt.org/z/Po1M4qc5P
I can't take credit for the modern workaround, someone named Raldryniorth in a
small community came up with it when I had the problem months back, so thanks
to him for that.

[Bug rtl-optimization/110939] [14 Regression] 14.0 ICE at rtl.h:2297 while bootstrapping on loongarch64

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||build, ice-on-valid-code
Summary|14.0 ICE at rtl.h:2297  |[14 Regression] 14.0 ICE at
   |while bootstrapping on  |rtl.h:2297 while
   |loongarch64 |bootstrapping on
   ||loongarch64
   Target Milestone|--- |14.0
  Component|bootstrap   |rtl-optimization

[Bug bootstrap/110939] New: 14.0 ICE at rtl.h:2297 while bootstrapping on loongarch64

[panchenghui at loongson dot cn via Gcc-bugs]

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

Bug ID: 110939
   Summary: 14.0 ICE at rtl.h:2297 while bootstrapping on
loongarch64
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: bootstrap
  Assignee: unassigned at gcc dot gnu.org
  Reporter: panchenghui at loongson dot cn
  Target Milestone: ---

since commit 7cdd0860949c6c3232e6cff1d7ca37bb5234074c, I get ICE at rtl.h:2297
when I try to bootstrap on loongarch64. 
I have seen the similar case in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110869 and try to build with the
latest commits in master branch but the problem still exists.

Configure:
../gcc/configure --prefix=/home/panchenghui/upstream-unmodded/build/install
--disable-libsanitizer --disable-gcov --disable-multilib

ICE output:
during RTL pass: combine
/home/panchenghui/upstream-unmodded/gcc/gcc/tree-cfgcleanup.cc: In function
'bool want_merge_blocks_p(basic_block, basic_block)':
/home/panchenghui/upstream-unmodded/gcc/gcc/tree-cfgcleanup.cc:761:1: internal
compiler error: in decompose, at rtl.h:2297
  761 | }
  | ^
0x1210c7997 wi::int_traits
>::decompose(long*, unsigned int, std::pair const&)
/home/panchenghui/upstream-unmodded/gcc/gcc/rtl.h:2297
0x1211478cb wide_int_ref_storage::wide_int_ref_storage
>(std::pair const&)
/home/panchenghui/upstream-unmodded/gcc/gcc/wide-int.h:1030
0x121146bab generic_wide_int
>::generic_wide_int >(std::pair const&)
/home/panchenghui/upstream-unmodded/gcc/gcc/wide-int.h:788
0x12177d13b simplify_const_unary_operation(rtx_code, machine_mode, rtx_def*,
machine_mode)
/home/panchenghui/upstream-unmodded/gcc/gcc/simplify-rtx.cc:2131
0x1217774e7 simplify_context::simplify_unary_operation(rtx_code, machine_mode,
rtx_def*, machine_mode)
/home/panchenghui/upstream-unmodded/gcc/gcc/simplify-rtx.cc:889
0x12177568f simplify_context::simplify_gen_unary(rtx_code, machine_mode,
rtx_def*, machine_mode)
/home/panchenghui/upstream-unmodded/gcc/gcc/simplify-rtx.cc:360
0x120f6e79f simplify_gen_unary(rtx_code, machine_mode, rtx_def*, machine_mode)
/home/panchenghui/upstream-unmodded/gcc/gcc/rtl.h:3520
0x12227818b simplify_comparison
/home/panchenghui/upstream-unmodded/gcc/gcc/combine.cc:13129
0x1222607c7 combine_simplify_rtx
/home/panchenghui/upstream-unmodded/gcc/gcc/combine.cc:6176
0x12225e30f subst
/home/panchenghui/upstream-unmodded/gcc/gcc/combine.cc:5609
0x12225df23 subst
/home/panchenghui/upstream-unmodded/gcc/gcc/combine.cc:5536
0x12225df23 subst
/home/panchenghui/upstream-unmodded/gcc/gcc/combine.cc:5536
0x122256ac7 try_combine
/home/panchenghui/upstream-unmodded/gcc/gcc/combine.cc:3369
0x1222506fb combine_instructions
/home/panchenghui/upstream-unmodded/gcc/gcc/combine.cc:1357
0x12227da6b rest_of_handle_combine
/home/panchenghui/upstream-unmodded/gcc/gcc/combine.cc:15063
0x12227db83 execute
/home/panchenghui/upstream-unmodded/gcc/gcc/combine.cc:15107

[Bug c++/110912] False assumption that constructors cannot alias any of their parameters

[de34 at live dot cn via Gcc-bugs]

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

Jiang An  changed:

   What|Removed |Added

 CC||de34 at live dot cn

--- Comment #1 from Jiang An  ---
The restriction agains aliasing was intended, see
https://cplusplus.github.io/CWG/issues/2271.html.

The status quo seems to be that in the body of `A::A(int )`, compilers can
assume that the value of `x` won't be changed by a modification on `*this`, but
not the other way around.

[Bug tree-optimization/43529] G++ doesn't optimize away empty loop when index is a double

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
   Target Milestone|--- |10.0
 Status|NEW |RESOLVED

--- Comment #6 from Andrew Pinski  ---
the 19 case was fixed in GCC 4.5.0 uptill somewhere between 200 and 2000.
2000 and 1e9 is fixed in GCC 10 for C++ by ... and r10-7522-g75efe9cb1f8938 .

[Bug target/99908] SIMD: negating logical + if_else has a suboptimal codegen.

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|--- |FIXED
 Status|NEW |RESOLVED
   Target Milestone|--- |12.0

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

[Bug target/99908] SIMD: negating logical + if_else has a suboptimal codegen.

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

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

--- Comment #9 from Andrew Pinski  ---
Created attachment 55704
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55704=edit
testcase

[Bug tree-optimization/14483] More aggressive compare insn elimination

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Component|rtl-optimization|tree-optimization
 CC||pinskia at gcc dot gnu.org

--- Comment #5 from Andrew Pinski  ---
What we could do in isel pass:
find a == 0 (in gimple_cond or in gimple_assign).
for gimple_cond see if either branch only has a == 1 in it. and change `a == 0`
to `(unsigned)a < 1`

This can be a generic part of isel even.
And then the RTL passes should be able to remove the comparison.

[Bug middle-end/100798] a?~t:t and (-(!!a))^t don't produce the same assembly code

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

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

--- Comment #3 from Andrew Pinski  ---
Patch posted:
https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626580.html

[Bug modula2/110779] SysClock can not read the clock

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

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

--- Comment #8 from Gaius Mulley  ---
Created attachment 55703
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55703=edit
Proposed fix (addendum)

Here is a patch which tests for all the functions and structs in wrapclock.cc.

[Bug c++/109761] [11/12 Regression] Nested class destructor's noexcept specification incorrectly considered as too loose compared to the outer class

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

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

--- Comment #10 from CVS Commits  ---
The releases/gcc-12 branch has been updated by Patrick Palka
:

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

commit r12-9804-gddf411e67cc15a80d635b512b812107985b361d4
Author: Patrick Palka 
Date:   Tue May 9 15:06:34 2023 -0400

c++: noexcept-spec from nested class confusion [PR109761]

When late processing a noexcept-spec from a nested class after completion
of the outer class (since it's a complete-class context), we pass the wrong
class context to noexcept_override_late_checks -- the outer class type
instead of the nested class type -- which leads to bogus errors in the
below test.

This patch fixes this by making noexcept_override_late_checks obtain the
class context directly via DECL_CONTEXT instead of via an additional
parameter.

PR c++/109761

gcc/cp/ChangeLog:

* parser.cc (cp_parser_class_specifier): Don't pass a class
context to noexcept_override_late_checks.
(noexcept_override_late_checks): Remove 'type' parameter
and use DECL_CONTEXT of 'fndecl' instead.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/noexcept78.C: New test.

(cherry picked from commit c13906f258fb34b3e0c90ddc8d9191dd72f3da0e)

[Bug c++/110197] [13 Regression] Empty constexpr object constructor erronously claims out of range access

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

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

--- Comment #9 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:61d24d3f40638326b4a24baadeb25a88610d76d8

commit r13-7693-g61d24d3f40638326b4a24baadeb25a88610d76d8
Author: Patrick Palka 
Date:   Thu Jul 27 09:10:07 2023 -0400

c++: constexpr empty subobject elision [PR110197]

Now that init_subob_ctx no longer sets new_ctx.ctor for a subobject of
empty type, it seems we need to ensure its callers also consistently
omit entries in the parent ctx->ctor for such subobjects.  We also need
to allow cxx_eval_array_reference to synthesize an empty subobject even
if the array CONSTRUCTOR has CONSTRUCTOR_NO_CLEARING set.

PR c++/110197

gcc/cp/ChangeLog:

* constexpr.cc (cxx_eval_array_reference): Allow synthesizing an
empty subobject even if CONSTRUCTOR_NO_CLEARING is set.
(cxx_eval_bare_aggregate): Set 'no_slot' to true more generally
whenever new_ctx.ctor is set to NULL_TREE by init_subob_ctx,
i.e. whenever initializing an subobject of empty type.
(cxx_eval_vec_init_1): Define 'no_slot' as above and use it
accordingly.

gcc/testsuite/ChangeLog:

* g++.dg/cpp0x/constexpr-empty18.C: New test.
* g++.dg/cpp0x/constexpr-empty19.C: New test.

(cherry picked from commit a426b91b27e28985f47d16827a532fbc28c09bd7)

[Bug c++/110566] [13 Regression] ICE when instantiating function template with template template parameter with 2 or more auto parameters with a dependent member template, ICE in tsubst, at cp/pt.cc:1

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

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

--- Comment #8 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:2c6e76ff039782401f705cacda60c11f8dfac3b1

commit r13-7692-g2c6e76ff039782401f705cacda60c11f8dfac3b1
Author: Patrick Palka 
Date:   Wed Jul 26 17:21:26 2023 -0400

c++: passing partially inst tmpl as ttp [PR110566]

Since the template arguments 'pargs' we pass to coerce_template_parms from
coerce_template_template_parms are always a full set, we need to make sure
we always pass the parameters of the most general template because if the
template is partially instantiated then the levels won't match up.  In the
testcase below during said call to coerce_template_parms the parameters are
{X, Y}, both level 1 rather than 2, and the arguments are {{int}, {N, M}},
which results in a crash during auto deduction for parameters' types.

PR c++/110566
PR c++/108179

gcc/cp/ChangeLog:

* pt.cc (coerce_template_template_parms): Simplify by using
DECL_INNERMOST_TEMPLATE_PARMS and removing redundant asserts.
Always pass the parameters of the most general template to
coerce_template_parms.

gcc/testsuite/ChangeLog:

* g++.dg/template/ttp38.C: New test.

(cherry picked from commit b3adcc60dcf3314f47f5409aecef40607f82b80b)

[Bug c++/108179] [11/12 regression] ICE related to template template parameters in tsubst, at cp/pt.cc:15782

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

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

--- Comment #12 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Patrick Palka
:

https://gcc.gnu.org/g:2c6e76ff039782401f705cacda60c11f8dfac3b1

commit r13-7692-g2c6e76ff039782401f705cacda60c11f8dfac3b1
Author: Patrick Palka 
Date:   Wed Jul 26 17:21:26 2023 -0400

c++: passing partially inst tmpl as ttp [PR110566]

Since the template arguments 'pargs' we pass to coerce_template_parms from
coerce_template_template_parms are always a full set, we need to make sure
we always pass the parameters of the most general template because if the
template is partially instantiated then the levels won't match up.  In the
testcase below during said call to coerce_template_parms the parameters are
{X, Y}, both level 1 rather than 2, and the arguments are {{int}, {N, M}},
which results in a crash during auto deduction for parameters' types.

PR c++/110566
PR c++/108179

gcc/cp/ChangeLog:

* pt.cc (coerce_template_template_parms): Simplify by using
DECL_INNERMOST_TEMPLATE_PARMS and removing redundant asserts.
Always pass the parameters of the most general template to
coerce_template_parms.

gcc/testsuite/ChangeLog:

* g++.dg/template/ttp38.C: New test.

(cherry picked from commit b3adcc60dcf3314f47f5409aecef40607f82b80b)

[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

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

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

--- Comment #12 from Steve Kargl  ---
On Mon, Aug 07, 2023 at 10:04:54PM +, kargl at gcc dot gnu.org wrote:
> 
> diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
> index 3cd470ddcca..b0bb8bc1471 100644
> --- a/gcc/fortran/resolve.cc
> +++ b/gcc/fortran/resolve.cc
> @@ -17966,7 +17966,9 @@ resolve_types (gfc_namespace *ns)
> 
>for (n = ns->contained; n; n = n->sibling)
>  {
> -  if (gfc_pure (ns->proc_name) && !gfc_pure (n->proc_name))
> +  if (gfc_pure (ns->proc_name)
> + && !gfc_pure (n->proc_name)
> + && !n->proc_name->attr.artificial)
> gfc_error ("Contained procedure %qs at %L of a PURE procedure must "
>"also be PURE", n->proc_name->name,
>>proc_name->declared_at);
> 
> pault, dos the above look correct?
> 

This patch passes a regression test with no new regressions
on x86_64-*-*freebsd.

[Bug c/108310] Some warnings that -Wtraditional-conversion causes to be emitted aren't actually controlled by it

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

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

--- Comment #5 from Eric Gallager  ---
(In reply to Jonathan Wakely from comment #4)
> void f(float);
> 
> void g()
> {
>   f(1.0);
> }
> 
> conv.c: In function ‘g’:
> conv.c:5:5: warning: passing argument 1 of ‘f’ as ‘float’ rather than
> ‘double’ due to prototype
> 5 |   f(1.0);
>   | ^~~

Thanks, which testsuite subdirectory would this go in?

[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

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

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

--- Comment #11 from Steve Kargl  ---
On Mon, Aug 07, 2023 at 10:04:54PM +, kargl at gcc dot gnu.org wrote:
> 
> Note final->attr.pure = 0 seems to contradict C1595 while constructing
> the wrapper.  I'm not too familiar with this portion of gfortran's
> internals.  Either the attribute should be set to 1 or the error
> message can be suppressed through inspection of final->attr.artificial.
> 

Whoops, I thought I included 

C1595 Any procedure referenced in a pure subprogram, including oner
  referenced via a defined operation, defined assignment, defined
  input/output, or finalization, shall be pure.

[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

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

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

kargl at gcc dot gnu.org changed:

   What|Removed |Added

 CC||kargl at gcc dot gnu.org
   Priority|P3  |P4

--- Comment #10 from kargl at gcc dot gnu.org ---
(In reply to Neil Carlson from comment #9)
> Bug is still present in 13.2.0.

class.cc(generate_finalization_wrapper) contains the following

  /* Set up the procedure symbol.  */
  name = xasprintf ("__final_%s", tname);
  gfc_get_symbol (name, sub_ns, );
  sub_ns->proc_name = final;
  final->attr.flavor = FL_PROCEDURE;
  final->attr.function = 1;
  final->attr.pure = 0;
  final->attr.recursive = 1;
  final->result = final;
  final->ts.type = BT_INTEGER;
  final->ts.kind = 4;
  final->attr.artificial = 1;


Note final->attr.pure = 0 seems to contradict C1595 while constructing
the wrapper.  I'm not too familiar with this portion of gfortran's
internals.  Either the attribute should be set to 1 or the error
message can be suppressed through inspection of final->attr.artificial.


diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 3cd470ddcca..b0bb8bc1471 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -17966,7 +17966,9 @@ resolve_types (gfc_namespace *ns)

   for (n = ns->contained; n; n = n->sibling)
 {
-  if (gfc_pure (ns->proc_name) && !gfc_pure (n->proc_name))
+  if (gfc_pure (ns->proc_name)
+ && !gfc_pure (n->proc_name)
+ && !n->proc_name->attr.artificial)
gfc_error ("Contained procedure %qs at %L of a PURE procedure must "
   "also be PURE", n->proc_name->name,
   >proc_name->declared_at);

pault, dos the above look correct?

[Bug c++/110938] [11/12/13/14 Regression] miscompile if implicit special member is deleted and mutable

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

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

--- Comment #2 from Andrew Pinski  ---
Note 4.8.5 (and before), seems to have the wrong ABI for non-mutable case too.

[Bug c++/110938] [11/12/13/14 Regression] miscompile if implicit special member is deleted and mutable

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.5
Summary|miscompile if implicit  |[11/12/13/14 Regression]
   |special member is deleted   |miscompile if implicit
   |and mutable |special member is deleted
   ||and mutable
  Known to work||4.7.1, 4.8.1
  Known to fail||4.9.0, 5.1.0, 7.1.0

[Bug c++/110938] miscompile if implicit special member is deleted and mutable

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|miscompile if implicit  |miscompile if implicit
   |special member is deleted   |special member is deleted
   |in a subtle way |and mutable

--- Comment #1 from Andrew Pinski  ---
Reduced:
```
struct X {
  X(X &) = delete;
  X(X&&) = delete;
  X(const X&) = default;
};

struct Y {
#if 1
  mutable
#endif
   X x;
  int n;
};

void print(int);

Y f();

void g() {
  print(f().n);
}
```

If we change `#if 1` to `#if 0` then GCC does the correct thing.

[Bug c++/110938] New: miscompile if implicit special member is deleted in a subtle way

[richard-gccbugzilla at metafoo dot co.uk via Gcc-bugs]

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

Bug ID: 110938
   Summary: miscompile if implicit special member is deleted in a
subtle way
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: richard-gccbugzilla at metafoo dot co.uk
  Target Milestone: ---

Testcase: https://godbolt.org/z/rKG8c166f

```
template struct Error {
  //static_assert(false);
  using type = T;
};

template using ArbitraryComputation = typename Error::type;

struct X {
  template X(ArbitraryComputation &) = delete;
  X(const X&) = default;
  X(X&&) = delete;
};

struct Y {
#if 0
  Y(const Y&) = default;
  Y(Y&&) = default;
#endif
  mutable X x;
  int n;
};

void print(int);

Y f();

void g() {
  print(f().n);
}
```

Uncommenting the `static_assert`, we can see that GCC never instantiates
`Error` in this example. But it must! If `ArbitraryComputation` evaluates
to `T`, then the non-trivial, templated constructor in `X` is used to copy the
member `Y::x`, so `Y` is not trivially-copyable.

This issue affects both type traits (GCC incorrectly evaluates
`__is_trivially_copyable(Y)` to true) and code generation (GCC emits `f()` as
returning in registers, which is both non-compliant with the ABI and doesn't
follow the C++ language rules because `Y` has no trivial copy or move
constructor).

If the `#if 0` is changed to `#if 1`, the problem disappears.

[Bug libstdc++/110917] std::format_to(int*, ...) fails to compile because of _S_make_span

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r14-3068-gc5ea5aecac323e9094e4dc967f54090cb244bc6a
Author: Jonathan Wakely 
Date:   Mon Aug 7 14:37:25 2023 +0100

libstdc++: Constrain __format::_Iter_sink for contiguous iterators
[PR110917]

We can't write to a span<_CharT> if the contiguous iterator has a value
type that isn't _CharT.

libstdc++-v3/ChangeLog:

PR libstdc++/110917
* include/std/format (__format::_Iter_sink):
Constrain partial specialization for contiguous iterators to
require the value type to be CharT.
* testsuite/std/format/functions/format_to.cc: New test.

[Bug libstdc++/110860] std::format("{:f}",2e304) invokes undefined behaviour

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

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

--- Comment #5 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r14-3069-gbb3ceeb6520c13fc5ca08af7d43fbd3f975e72b0
Author: Jonathan Wakely 
Date:   Mon Aug 7 15:30:03 2023 +0100

libstdc++: Fix incorrect use of abs and log10 in std::format [PR110860]

The std::formatter implementation for floating-point types uses
__builtin_abs and __builtin_log10 to avoid including all of , but
those functions are not generic. The result of abs(2e304) is -INT_MIN
which is undefined, and then log10(INT_MIN) is NaN. As well as being
undefined, we fail to grow the buffer correctly, and then loop more
times than needed to allocate a buffer and try formatting the value into
it again.

We can use if-constexpr to choose the correct form of log10 to use for
the type, and avoid using abs entirely. This avoids the undefined
behaviour and should mean we only reallocate and retry std::to_chars
once.

libstdc++-v3/ChangeLog:

PR libstdc++/110860
* include/std/format (__formatter_fp::format): Do not use
__builtin_abs and __builtin_log10 with arbitrary floating-point
types.

[Bug libstdc++/110862] format out of bounds read on format string "{0:{0}"

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by Jonathan Wakely :

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

commit r14-3066-g5d87f71bb462ccb78dd3d9d810ea08d96869cb4b
Author: Jonathan Wakely 
Date:   Thu Aug 3 08:45:43 2023 +0100

libstdc++: Fix past-the-end increment in std::format [PR110862]

At the end of a replacement field we should check that the closing brace
is actually present before incrementing past it.

libstdc++-v3/ChangeLog:

PR libstdc++/110862
* include/std/format (_Scanner::_M_on_replacement_field):
Check for expected '}' before incrementing iterator.
* testsuite/std/format/string.cc: Check "{0:{0}" format string.

[Bug ipa/105990] Dead code elimination failed at -O3

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Hongtao.liu from comment #1)
> foo() also can be eliminated.

This one is similar to PR 105832 really.

```
 _2 = (int) a.2_1;
  _3 = 2 >> _2;
  if (_3 == 2)
goto ; [34.00%]
  else
goto ; [66.00%]

   [local count: 182536112]:
  _4 = 1 << _2;
  iftmp.1_10 = (char) _4;
  if (iftmp.1_10 == 0)
goto ; [33.00%]
  else
goto ; [67.00%]
```
`(2 >> _2) == 2` could be optimized to just `_2 == 0`.
And then `_4` becomes `1` and then the conditional is optimized away and such.

[Bug fortran/109684] compiling failure: complaining about a final subroutine of a type being not PURE (while it is indeed PURE)

[neil.n.carlson at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Neil Carlson  ---
Bug is still present in 13.2.0.

[Bug libstdc++/67791] [10 Regression] Crash using std::thread and iostream with dynamic loading of a shared library

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

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

--- Comment #17 from Jonathan Wakely  ---
GCC 9 hasn't changed, so it must be something in your Ubuntu environment or
your code.

I don't think the RTLD_xxx approach was ever robust, the libpthread.so library
needs to be loaded before the first __gthread_active_p() check in the whole
executable. That can be achieved by linking the executable to libpthread or
preloading it. Or using a newer glibc where libpthread.so is empty and all the
pthreads functions live in libc.so anyway.

[Bug middle-end/100798] a?~t:t and (-(!!a))^t don't produce the same assembly code

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
 Ever confirmed|0   |1
   Last reconfirmed||2023-08-07
 Status|UNCONFIRMED |ASSIGNED

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

[Bug tree-optimization/110937] (bool0 ? bool1^1 : bool1) is not optimized to bool0 ^ bool1

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

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

--- Comment #2 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #1)
> Created attachment 55702 [details]
> Patch which I am testing

Actually I am going to fix this with PR 100798.

[Bug tree-optimization/110937] (bool0 ? bool1^1 : bool1) is not optimized to bool0 ^ bool1

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

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

--- Comment #1 from Andrew Pinski  ---
Created attachment 55702
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55702=edit
Patch which I am testing

[Bug tree-optimization/110937] (bool0 ? bool1^1 : bool1) is not optimized to bool0 ^ bool1

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2023-08-07
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org

[Bug target/110908] [aarch64] Internal compiler error when using -ffixed-x30

[zach-gcc at cs dot stanford.edu via Gcc-bugs]

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

--- Comment #5 from zach-gcc at cs dot stanford.edu ---
I am implementing software fault isolation on top of GCC and would like for GCC
to only ever store addresses in x30. Use of x30 in its link register role is
desired (saving/restoring etc. is good), but I would not like GCC to use x30
for general-purpose arithmetic. I'm not even sure that GCC ever does that to
begin with, but LLVM does and the `-ffixed-x30` option prevents LLVM from doing
so (while retaining x30's role as the link register).

[Bug ipa/110378] IPA-SRA for destructors

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

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

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

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

commit r14-3038-gda1a888b524d620c7a17f368b69c46934b69495c
Author: Martin Jambor 
Date:   Mon Aug 7 19:13:41 2023 +0200

ipa-sra: Don't consider CLOBBERS as writes preventing splitting

When IPA-SRA detects whether a parameter passed by reference is
written to, it does not special case CLOBBERs which means it often
bails out unnecessarily, especially when dealing with C++ destructors.
Fixed by the obvious continue in the two relevant loops and by adding
a simple function that marks the clobbers in the transformation code
as statements to be removed.

gcc/ChangeLog:

2023-08-04  Martin Jambor  

PR ipa/110378
* ipa-param-manipulation.h (class ipa_param_body_adjustments): New
members get_ddef_if_exists_and_is_used and mark_clobbers_dead.
* ipa-sra.cc (isra_track_scalar_value_uses): Ignore clobbers.
(ptr_parm_has_nonarg_uses): Likewise.
* ipa-param-manipulation.cc
(ipa_param_body_adjustments::get_ddef_if_exists_and_is_used): New.
(ipa_param_body_adjustments::mark_dead_statements): Move initial
checks to get_ddef_if_exists_and_is_used.
(ipa_param_body_adjustments::mark_clobbers_dead): New.
(ipa_param_body_adjustments::common_initialization): Call
mark_clobbers_dead when splitting.

gcc/testsuite/ChangeLog:

2023-07-31  Martin Jambor  

PR ipa/110378
* g++.dg/ipa/pr110378-1.C: New test.

[Bug modula2/110779] SysClock can not read the clock

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

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

Rainer Orth  changed:

   What|Removed |Added

 CC||ro at gcc dot gnu.org
 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #7 from Rainer Orth  ---
This patch broke Solaris bootstrap:

/vol/gcc/src/hg/master/local/libgm2/libm2iso/wrapclock.cc: In function 'long
int m2iso_wrapclock_timezone()':
/vol/gcc/src/hg/master/local/libgm2/libm2iso/wrapclock.cc:77:21: error: 'struct
std::tm' has no member named 'tm_gmtoff'
   77 |   return result.tm_gmtoff;
  | ^
make[5]: *** [Makefile:914: wrapclock.lo] Error 1

[Bug tree-optimization/110937] New: (bool0 ? bool1^1 : bool1) is not optimized to bool0 ^ bool1

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

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

Bug ID: 110937
   Summary: (bool0 ? bool1^1 : bool1) is not optimized to bool0 ^
bool1
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
```
_Bool f2(_Bool a, _Bool b)
{
if (a)
  return !b;
return b;
}
```
This should be optimized to just:
```
_Bool f2_(_Bool a, _Bool b)
{
  return a ^ b;
}
```

[Bug libstdc++/67791] [10 Regression] Crash using std::thread and iostream with dynamic loading of a shared library

[colin.davidson at codeplay dot com via Gcc-bugs]

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

colin.davidson at codeplay dot com changed:

   What|Removed |Added

 CC||colin.davidson at codeplay dot 
com

--- Comment #16 from colin.davidson at codeplay dot com ---
I've started seeing this throw error in the last few days (both in dockers and
locally on ubuntu 20.04). This was in previously working code which used dlopen
on a library with pthreads. We used RTLD_LAZY | RTLD_GLOBAL to work around
previous crashes but now we can't get the code to work unless we LD_PRELOAD the
pthreads library first.

I'm on libstdc++.so.6.0.28,  gcc (Ubuntu 9.4.0-1ubuntu1~20.04.1) 9.4.0

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

[mikpelinux at gmail dot com via Gcc-bugs]

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

Mikael Pettersson  changed:

   What|Removed |Added

 CC||mikpelinux at gmail dot com

--- Comment #4 from Mikael Pettersson  ---
I can reproduce with m68k-unknown-linux-gnu-gcc -Os -fzero-call-used-regs=all
-fPIC.

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

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

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

--- Comment #9 from Michael Matz  ---
(In reply to Florian Weimer from comment #8)
> (In reply to Michael Matz from comment #7)
> > > > Does the clang implementation take into account the various problematic
> > > > cases that arise when calling a normal function from a (say) 
> > > > preserve_all
> > > > function
> > > > (hint: such call can't usually be done)?
> > > 
> > > How so? We need to version the __preserve_most__ attribute with the ISA
> > > level, of course.
> > 
> > I don't see how that helps.  Imagine a preserve_all function foo that calls
> > printf.  How do you propose that 'foo' saves all parts of the SSE registers,
> > even those that aren't invented yet, or those that can't be touched by the
> > current ISA?  (printf might clobber all of these)
> 
> Vector registers are out of scope for this.

Why do you say that?  From clang: "Furthermore it also preserves all
floating-point registers (XMMs/YMMs)."  (for preserve_all, but this bugreport
does
include that variant of the attribute).

> But lets look at APX. If printf is recompiled to use APX, then it will
> clobber the extended register file. If we define __preserve_most__ the way
> we do in my psABI proposal (i.e., *not* as everything but %r11), the
> extended APX registers are still caller-saved.

Right, for preserve_most _with your wording_ it works out.  preserve_all
or preserve_most with clang wording doesn't.

> (These details are the main reason why I want this in the psABI
> documentation. This stuff is out there and will be used, so let's make sure
> that it's somewhat reasonable.)

I agree with that.  I just want a little hashing-out-the-details before
putting anything in the psABI.

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

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

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

--- Comment #8 from Florian Weimer  ---
(In reply to Michael Matz from comment #7)
> > > Does the clang implementation take into account the various problematic
> > > cases that arise when calling a normal function from a (say) preserve_all
> > > function
> > > (hint: such call can't usually be done)?
> > 
> > How so? We need to version the __preserve_most__ attribute with the ISA
> > level, of course.
> 
> I don't see how that helps.  Imagine a preserve_all function foo that calls
> printf.  How do you propose that 'foo' saves all parts of the SSE registers,
> even those that aren't invented yet, or those that can't be touched by the
> current ISA?  (printf might clobber all of these)

Vector registers are out of scope for this.

But lets look at APX. If printf is recompiled to use APX, then it will clobber
the extended register file. If we define __preserve_most__ the way we do in my
psABI proposal (i.e., *not* as everything but %r11), the extended APX registers
are still caller-saved. We will have to introduce a __preserve_most_apx__
attribute and a different psABI specification that says that the new APX
registers are callee-saved, too.

(These details are the main reason why I want this in the psABI documentation.
This stuff is out there and will be used, so let's make sure that it's somewhat
reasonable.)

[Bug tree-optimization/110931] [14 Regression] Dead Code Elimination Regression since r14-2890-gcc2003cd875

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

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

--- Comment #3 from Andrew Pinski  ---
Here is one that has always failed due to a similar issue where the inner cast
was removed:
```
void foo(void);
int l=1000;

int main(void)
{
  short t = l;
  int t1 = t;
  if (t1 == 0) {
signed char b = t1;
if (b != 1) __builtin_unreachable();
foo();
  }
}
```

[Bug sanitizer/110936] New: if constexpr: member function pointers cannot be checked with ubsan

[jeanmichael.celerier at gmail dot com via Gcc-bugs]

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

Bug ID: 110936
   Summary: if constexpr: member function pointers cannot be
checked with ubsan
   Product: gcc
   Version: 13.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: sanitizer
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jeanmichael.celerier at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin at 
gcc dot gnu.org
  Target Milestone: ---

Repro:

struct foo {
  void bar() { }
};

void process(auto f) {
  if constexpr((f)::bar);
}

int main() {
  process(foo{});
}


Works fine in normal compilation mode as expected, however with
-fsanitize=undefined it does not work: https://gcc.godbolt.org/z/9qvz89na8

:6:3: error: '(foo::bar != 0)' is not a constant expression
  if constexpr((f)::bar);

I tested as far back as g++ 7.1 and it did not work either back then, and prior
versions did not have if constexpr.

It would be less of a problem if there was any way to do #if
defined(__SANITIZE_UNDEFINED__) or something similar but while asan has it,
ubsan does not seem to have any macro to enable detection of it.

[Bug analyzer/110933] Add warnings to detect wrapping happening inside a loop (an infinite loop)

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

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

Andrew Pinski  changed:

   What|Removed |Added

Summary|Add warning flags to check  |Add warnings to detect
   |against integer overflow|wrapping happening inside a
   ||loop (an infinite loop)
   Assignee|unassigned at gcc dot gnu.org  |dmalcolm at gcc dot 
gnu.org
   Severity|normal  |enhancement
  Component|c++ |analyzer

--- Comment #4 from Andrew Pinski  ---
So -Wconversion does not warn in this case as there is the conversion is being
promoted rather than a truncation.
That is
i < n
is being done in uint64_t.

> find common integer overflow bugs.
Again in this case there is NO integer overflow. There is only unsigned integer
wrapping happening which is well defined C/C++ behavior.
Just the programmer was not expecting them and maybe should be warned about but
I always get the feeling this should be a -fanalyzer option as there needs to
be some extra static analysis to make sure if the programmer checks for the
wrapping we don't warn about it always ...

[Bug c++/110930] Fix-it hints suggest wrong header for names in the global namespace

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

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

--- Comment #5 from Jonathan Wakely  ---
Ah yes, this is a dup of the second half of that one, but maybe worth keeping
it separate.

[Bug c++/110930] Fix-it hints suggest wrong header for names in the global namespace

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

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

--- Comment #4 from Andrew Pinski  ---
I see Jonathan had mentioned this issue in bug 85690 comment #1 too.

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

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

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

--- Comment #7 from Michael Matz  ---
(In reply to Florian Weimer from comment #5)
> > It also makes argument registers be callee-saved, which is very
> > unconventional.
> 
> Isn't this done for the this pointer in some C++ ABIs?

There are some, yes.  But those are then incompatible with the normal
definition of C++ calling conventions in terms of the ones for C (where 'this'
is simply
the first pointer argument).

The sense of that deviation lies in observing that 'this' usually isn't changed
by the callee.  For arbitrary arguments this doesn't hold, they belong to the
called function and so using a call-clobbered reg makes most sense.  It's
possible to do different of course, but it's very unusual.

> > Does the clang implementation take into account the various problematic
> > cases that arise when calling a normal function from a (say) preserve_all
> > function
> > (hint: such call can't usually be done)?
> 
> How so? We need to version the __preserve_most__ attribute with the ISA
> level, of course.

I don't see how that helps.  Imagine a preserve_all function foo that calls
printf.  How do you propose that 'foo' saves all parts of the SSE registers,
even those that aren't invented yet, or those that can't be touched by the
current ISA?  (printf might clobber all of these)

[Bug c++/110930] Fix-it hints suggest wrong header for names in the global namespace

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

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

Andrew Pinski  changed:

   What|Removed |Added

 CC||pinskia at gcc dot gnu.org

--- Comment #3 from Andrew Pinski  ---
I had noticed this too.

[Bug target/110926] [14 regression] Bootstrap failure (matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_m

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #11 from Andrew Pinski  ---
.

[Bug tree-optimization/110931] [14 Regression] Dead Code Elimination Regression since r14-2890-gcc2003cd875

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

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

--- Comment #2 from Andrew Pinski  ---
Basically there is a missing VRP happening here:
l.0_1   [irange] int [-INF, -65536][0, 0][65536, +INF]
Partial equiv (b_6 pe8 l.0_1)
 :
b_6 = (char) l.0_1;
...
Obvious that b_6 will have the range [0,0] as the other parts of l.0_1 is
outside of that range. But for some reason VRP didn't figure that out here ...

I don't understand how this is supposed to work

[Bug tree-optimization/110931] [14 Regression] Dead Code Elimination Regression since r14-2890-gcc2003cd875

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-08-07
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Reduced testcase:
```
void foo(void);
int l=1000;

int main(void)
{
  short t = l;
  unsigned t1 = t;
  if (t1 == 0) {
#if 1
char b = t1;
#else
char b = l;
#endif
if (b != 1) __builtin_unreachable();
foo();
  }
}
```

Changing 1 to 0 in the #if, shows the missed optimization too.

[Bug tree-optimization/110931] [14 Regression] Dead Code Elimination Regression since r14-2890-gcc2003cd875

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||missed-optimization
   Target Milestone|--- |14.0

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

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=108640,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=80786
 Status|WAITING |UNCONFIRMED
  Component|rtl-optimization|target
 Ever confirmed|1   |0

[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

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

[Bug tree-optimization/109959] `(a > 1) ? 0 : (a == 1)` is not optimized when spelled out at -O2+

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

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

--- Comment #12 from CVS Commits  ---
The trunk branch has been updated by Andrew Pinski :

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

commit r14-3036-gb57bd27cb68fdbe5d9dcd571b1cb66f72b841290
Author: Andrew Pinski 
Date:   Sun Aug 6 13:57:35 2023 -0700

MATCH: [PR109959] `(uns <= 1) & uns` could be optimized to `uns == 1`

I noticed while looking into some code generation of
bitmap_single_bit_set_p,
that sometimes:
```
  if (uns > 1)
return 0;
  return uns == 1;
```
Would not optimize down to just:
```
return uns == 1;
```

In this case, VRP likes to change `a == 1` into `(bool)a` if
a has a range of [0,1] due to `a <= 1` side of the branch.
We might end up with this similar code even without VRP,
in the case of builtin-sprintf-warn-23.c (and Wrestrict.c), we had:
```
if (s < 0 || 1 < s)
  s = 0;
```
Which is the same as `s = ((unsigned)s) <= 1 ? s : 0`;
So we should be able to catch that also.

This adds 2 patterns to catch `(uns <= 1) & uns` and
`(uns > 1) ? 0 : uns` and convert those into:
`(convert) uns == 1`.

OK? Bootstrapped and tested on x86_64-linux-gnu with no regressions.

PR tree-optimization/109959

gcc/ChangeLog:

* match.pd (`(a > 1) ? 0 : (cast)a`, `(a <= 1) & (cast)a`):
New patterns.

gcc/testsuite/ChangeLog:

* gcc.dg/tree-ssa/builtin-sprintf-warn-23.c: Remove xfail.
* c-c++-common/Wrestrict.c: Update test and remove some xfail.
* gcc.dg/tree-ssa/cmpeq-1.c: New test.
* gcc.dg/tree-ssa/cmpeq-2.c: New test.
* gcc.dg/tree-ssa/cmpeq-3.c: New test.

[Bug libstdc++/110917] std::format_to(int*, ...) fails to compile because of _S_make_span

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

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

--- Comment #3 from Jonathan Wakely  ---
It fails for non-contrived cases like this too:

char8_t buf[32];
std::format_to(buf, "");

[Bug c/24542] potential unwanted truncation of operation overflow should be warned on assignment to wider variable

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

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

--- Comment #16 from Andrew Pinski  ---
(In reply to Niklas Hambüchen from comment #15)
> Another common integer overflow bug type is the "for (u32 i = 0; i < u64;
> ++i)" pattern, as well as general widening comparisons.
> 
> I filed bug 110933 for those; just linking it here for people interested in
> integer overflows.

There is no integer overflow here rather there has been wrapping happening. Yes
there is a huge difference between the two. Wrapping is defined behavior while
overflow is undefined behavior.

[Bug libstdc++/110917] std::format_to(int*, ...) fails to compile because of _S_make_span

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

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

--- Comment #2 from Arthur O'Dwyer  ---
> Alternatively, we could replace the contiguous_iterator<_OutIter> constraint 
> with constructible_from, _OutIter, iter_difference_t<_OutIter>>.

I think `is_same` is preferable to `constructible_from<...>` just because it's
simpler; I wouldn't recommend the hairier thing unless there was a known reason
for it. Doing the hairier thing would immediately trigger a search for the
corner case where it would fail. ;)  (Suppose the author of _OutIter arranges
that sentinel_for — maybe that'd do the trick...)


Btw, even though my reduced test case was contrived, it originates from an
actually realistic use-case AFAIK: using `format` to format ASCII text
automatically into an array of char16_t or char32_t (presumably on a platform
with unsigned plain char).

[Bug c++/110933] Add warning flags to check against integer overflow

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

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

--- Comment #3 from Andrew Pinski  ---
Try -Wconversion.

Also there is no overflow here as unsigned is always defined as wrapping.

[Bug modula2/110779] SysClock can not read the clock

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

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

--- Comment #6 from CVS Commits  ---
The releases/gcc-13 branch has been updated by Gaius Mulley
:

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

commit r13-7691-g4f8d84955dd5c9d2882d09e9c249240efe3a02aa
Author: Gaius Mulley 
Date:   Mon Aug 7 15:08:49 2023 +0100

PR modula2/110779 SysClock can not read the clock

This patch completes the implementation of the ISO module
SysClock.mod.  Three new testcases are provided.  wrapclock.{cc,def}
are new support files providing access to clock_settime, clock_gettime
and glibc timezone variables.

gcc/m2/ChangeLog:

PR modula2/110779
* gm2-libs-iso/SysClock.mod: Re-implement using wrapclock.
* gm2-libs-iso/wrapclock.def: New file.

libgm2/ChangeLog:

PR modula2/110779
* config.h.in: Regenerate.
* configure: Regenerate.
* configure.ac (GM2_CHECK_LIB): Check for clock_gettime
and clock_settime.
* libm2iso/Makefile.am (M2DEFS): Add wrapclock.def.
* libm2iso/Makefile.in: Regenerate.
* libm2iso/wraptime.cc: Replace HAVE_TIMEVAL with
HAVE_STRUCT_TIMEVAL.
* libm2iso/wrapclock.cc: New file.

gcc/testsuite/ChangeLog:

PR modula2/110779
* gm2/iso/run/pass/m2date.mod: New test.
* gm2/iso/run/pass/testclock.mod: New test.
* gm2/iso/run/pass/testclock2.mod: New test.

Signed-off-by: Gaius Mulley 

[Bug libstdc++/110853] [c++-concepts] Bad interaction between deduction guide with decay and constraints

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

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

Patrick Palka  changed:

   What|Removed |Added

 CC||ppalka at gcc dot gnu.org

--- Comment #1 from Patrick Palka  ---
Since as you mention a member function body is a complete-class context,
libstdc++'s std::pair implementation strategy does seem non-conforming in this
case.

Clang seems to not propagate constructor constraints to the implicit deduction
guide, according to the following example, and is probably the reason why it
accepts your reduced example.

template
struct A {
  A(T) requires false; // #1
  A(...); // #2
};

auto a = A(0); // GCC rejects, Clang incorrectly(?) selects #2 with T=int.

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

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

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

Jan Hubicka  changed:

   What|Removed |Added

 CC||hubicka at gcc dot gnu.org

--- Comment #6 from Jan Hubicka  ---
This may be interesting option for string functions. If block is small one can
do copying without clobbering (many) registers. If block is large there is
enough time to save all registers used.

But indeed preserving even the registers holding function parameters is bit odd
IMO.

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

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

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

--- Comment #5 from Florian Weimer  ---
(In reply to Michael Matz from comment #3)
> For ABIs you generally want a good mix between caller- and callee-saved
> registers. The x86-64 psABI didn't do that on the SSE regs for conscious, but
> meanwhile irrelevant, reasons, so my approach above tried to rectify this.
> 
> The clang attributes seem to go against that general idea, they move all regs
> (or all general regs) into being callee-saved (except, strangely for
> aarch64?).

This is intended for functions that are called conditionally, but rarely, such
as debug logging. It's not a generally useful calling convention.

> It also makes argument registers be callee-saved, which is very
> unconventional.

Isn't this done for the this pointer in some C++ ABIs?

> Does the clang implementation take into account the various problematic
> cases that arise when calling a normal function from a (say) preserve_all
> function
> (hint: such call can't usually be done)?

How so? We need to version the __preserve_most__ attribute with the ISA level,
of course.

[Bug middle-end/110869] [14 regression] ICE in decompose, at rtl.h:2297

[stefansf at linux dot ibm.com via Gcc-bugs]

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

--- Comment #18 from Stefan Schulze Frielinghaus  ---
Thanks again for testing.  Very much appreciated!

I like the idea of a comment and posted a patch:

https://gcc.gnu.org/pipermail/gcc-patches/2023-August/626514.html

[Bug target/110908] [aarch64] Internal compiler error when using -ffixed-x30

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

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

Richard Earnshaw  changed:

   What|Removed |Added

   Last reconfirmed||2023-08-07
 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
 Ever confirmed|0   |1

--- Comment #4 from Richard Earnshaw  ---
Why would you ever want to fix x30?  Because of the way it is used by the
architecture, there's no possible value in doing so.  The compiler may insert
instructions that must clobber this value at any point in the program (to
handle libfuncs, for example), so it would be unsafe to store any useful value
in it.

I think it would be far more useful to make the compiler reject this option
than to give the appearance that it is possible, when frankly, it isn't.

Although it isn't technically, an ICE on invalid code, it's about as close to
that as you can get.

[Bug tree-optimization/110935] Missed BB reduction vectorization because of missed eliding of a permute

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||x86_64-*-*
  Known to fail||13.2.1, 14.0
 CC||rsandifo at gcc dot gnu.org
   Keywords||missed-optimization

--- Comment #1 from Richard Biener  ---
I didn't find where we make sure to elide the "outgoing" permute of a
reduction, but I think we only have testcases for the loop vectorization case. 
Can you suggest where we'd do this?  Note we do not represent the plus
reduction
operation but the whole SLP instance has just a single node (with load
permutation)

[Bug tree-optimization/110935] New: Missed BB reduction vectorization because of missed eliding of a permute

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

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

Bug ID: 110935
   Summary: Missed BB reduction vectorization because of missed
eliding of a permute
   Product: gcc
   Version: 13.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

double vals[16];
double test ()
{
  vals[0]++;
  return vals[2] + vals[4] + vals[1] + vals[3];
}

has the reduction not vectorized with -ffast-math because

t.c:5:38: note:   === vect_slp_analyze_operations ===
t.c:5:38: note:   ==> examining statement: _8 = vals[3];
t.c:5:38: missed:   BB vectorization with gaps at the end of a load is not
supported
t.c:5:44: missed:   not vectorized: relevant stmt not supported: _8 = vals[3];
t.c:5:38: note:   removing SLP instance operations starting from: _11 = _7 +
_8;
t.c:5:38: missed:  not vectorized: bad operation in basic block.

we fail to elide the load permutation (BB vect allows a consecutive
sub-set):

t.c:5:38: note:   Final SLP tree for instance 0x51c8d60:
t.c:5:38: note:   node 0x5285860 (max_nunits=2, refcnt=2) vector(2) double
t.c:5:38: note:   op template: _8 = vals[3];
t.c:5:38: note: stmt 0 _8 = vals[3];
t.c:5:38: note: stmt 1 _6 = vals[1];
t.c:5:38: note: stmt 2 _3 = vals[2];
t.c:5:38: note: stmt 3 _4 = vals[4];
t.c:5:38: note: load permutation { 3 1 2 4 }
t.c:5:38: note:=== vect_match_slp_patterns ===
t.c:5:38: note:Analyzing SLP tree 0x5285860 for patterns
t.c:5:38: note:  SLP optimize permutations:
t.c:5:38: note:1: { 2, 0, 1, 3 }
t.c:5:38: note:  SLP optimize partitions:
t.c:5:38: note:-
t.c:5:38: note:partition 0 (layout 0):
t.c:5:38: note:  nodes:
t.c:5:38: note:- 0x5285860:
t.c:5:38: note:weight: 1.00
t.c:5:38: note:op template: _8 = vals[3];
t.c:5:38: note:  edges:
t.c:5:38: note:  layout 0: (*)
t.c:5:38: note:  {depth: 0.00, total: 0.00}
t.c:5:38: note:+ {depth: 1.00, total: 1.00}
t.c:5:38: note:+ {depth: 0.00, total: 0.00}
t.c:5:38: note:= {depth: 1.00, total: 1.00}
t.c:5:38: note:  layout 1:
t.c:5:38: note:  {depth: 0.00, total: 0.00}
t.c:5:38: note:+ {depth: 1.00, total: 1.00}
t.c:5:38: note:+ {depth: 0.00, total: 0.00}
t.c:5:38: note:= {depth: 1.00, total: 1.00}
t.c:5:38: note:  recording new base alignment for 
  alignment:32
  misalignment: 0
  based on: _1 = vals[0];
t.c:5:38: note:   === vect_slp_analyze_instance_alignment ===

[Bug target/110901] -march does not override -mcpu (big.little on aarch64

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

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

Richard Earnshaw  changed:

   What|Removed |Added

   Last reconfirmed||2023-08-07
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #4 from Richard Earnshaw  ---
I think this is a driver bug.  The MCPU_TO_MARCH_SPEC should be wrapped with 

%{!march=*:...} 

so that the CPU architecture is ignored if -march has been explicitly
specified.

[Bug target/110926] [14 regression] Bootstrap failure (matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_m

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #10 from Hongtao.liu  ---
Fixed in GCC14.

[Bug target/110926] [14 regression] Bootstrap failure (matmul_i1.c:1781:1: internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w' (rtx const_int) in vpternlog_redundant_operand_m

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

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

--- Comment #9 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

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

commit r14-3034-gaf6cfd7b663909688c6ca55b6e9f859cdde4310f
Author: liuhongt 
Date:   Mon Aug 7 11:10:52 2023 +0800

Fix ICE in rtl check when bootstrap.

   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/generated/matmul_i1.c:
In function âmatmul_i1_avx512fâ:
   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/libgfortran/generated/matmul_i1.c:1781:1:
internal compiler error: RTL check: expected elt 0 type 'i' or 'n', have 'w'
(rtx const_int) in vpternlog_redundant_operand_mask, at
config/i386/i386.cc:19460
 1781 | }
  | ^
0x5559de26dc2d rtl_check_failed_type2(rtx_def const*, int, int, int, char
const*, int, char const*)
   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/rtl.cc:761
0x5559de340bfe vpternlog_redundant_operand_mask(rtx_def**)
   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/config/i386/i386.cc:19460
0x5559dfec67a6 split_44
   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/config/i386/sse.md:12730
0x5559dfec67a6 split_63
   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/config/i386/sse.md:28428
0x5559deb8a682 try_split(rtx_def*, rtx_insn*, int)
   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/emit-rtl.cc:3800
0x5559deb8adf2 try_split(rtx_def*, rtx_insn*, int)
   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/emit-rtl.cc:3972
0x5559def69194 split_insn
   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/recog.cc:3385
0x5559def70c57 split_all_insns()
   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/recog.cc:3489
0x5559def70d0c execute
   
/var/tmp/portage/sys-devel/gcc-14.0.0_pre20230806/work/gcc-14-20230806/gcc/recog.cc:4413

Use INTVAL (imm_op) instead of XINT (imm_op, 0).

gcc/ChangeLog:

PR target/110926
* config/i386/i386-protos.h
(vpternlog_redundant_operand_mask): Adjust parameter type.
* config/i386/i386.cc (vpternlog_redundant_operand_mask): Use
INTVAL instead of XINT, also adjust parameter type from rtx*
to rtx since the function only needs operands[4] in vpternlog
pattern.
(substitute_vpternlog_operands): Pass operands[4] instead of
operands to vpternlog_redundant_operand_mask.
* config/i386/sse.md: Ditto.

[Bug libstdc++/110432] macOS: Segmentation fault when using stdlibc++ from gcc 13.1 in combination with clang-16

[sascha.scandella at dentsplysirona dot com via Gcc-bugs]

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

--- Comment #19 from Sascha Scandella  ---
(In reply to Jonathan Wakely from comment #17)
> The fix has been backported to gcc-13 now. There should be a release
> candidate for 13.2 in the next day or so, please try it out on macOS to make
> sure the fix works.

@Jonathan: I could have tested now at the earliest. It seems that 13.2 has
already been released. I could do a test as soon as the Homebrew version has
been released.

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

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

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

--- Comment #4 from Michael Matz  ---
(In reply to Florian Weimer from comment #2)
> I tried to write up something for the x86-64 psABI:
> 
> Document the ABI for __preserve_most__ function calls
> 
> 
> This should match what Clang implements (but not what it documents).

Shouldn't we first discuss whether any of this, or particular aspects of it,
are
a good idea at all, before specifying behaviour that a random compiler happened
to implement?

[Bug target/110921] Relax _tzcnt_u32 support x86, all x86 arch support for this instrunction

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #11 from Hongtao.liu  ---
(In reply to 罗勇刚(Yonggang Luo) from comment #10)
> (In reply to Hongtao.liu from comment #9)
> 
> > > Without `-mbmi` option, gcc can not compile and all other three compiler
> > > can compile.
> > 
> > As long as it keeps semantics(respect zero input), I think this is
> > acceptable.
> 
> Yeap, it's acceptable, but consistence with Clang/MSVC/ICL would be better.
> That would makes the cross-platform code easier, besides, GCC also works for
> WIN32, that's needs GCC to be consistence with MSVC

Sorry for confusion, I meant generating codes like

f(int, int): # @f(int, int)
testedi, edi
je  .LBB0_2
rep   bsf eax, edi
ret
.LBB0_2:
mov eax, 32
ret

w/o mbmi is acceptable as long as it respect zero input.

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

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

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

--- Comment #3 from Michael Matz  ---
Huh, since when does clang implement this?  See also 
  https://gcc.gnu.org/pipermail/gcc-patches/2023-July/624004.html
where I asked for comments about a similar, but not same, mechanism.  I came
from
the angle of preserving a couple of SSE registers on x86-64.

For ABIs you generally want a good mix between caller- and callee-saved
registers. The x86-64 psABI didn't do that on the SSE regs for conscious, but
meanwhile irrelevant, reasons, so my approach above tried to rectify this.

The clang attributes seem to go against that general idea, they move all regs
(or all general regs) into being callee-saved (except, strangely for aarch64?).
It also makes argument registers be callee-saved, which is very unconventional.

Does the clang implementation take into account the various problematic cases
that arise when calling a normal function from a (say) preserve_all function
(hint: such call can't usually be done)?  Does exception handling,
setjmp/longjmp
and make/swapcontext interact with the clang attributes?

That said: the implementation itself (after a more detailed spec) can be
implemented in the same framework like the above patch.  (It's possible that
something more needs doing for the unusual situation that argument regs are
then
callee-saved).

[Bug target/110921] Relax _tzcnt_u32 support x86, all x86 arch support for this instrunction

[luoyonggang at gmail dot com via Gcc-bugs]

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

--- Comment #10 from 罗勇刚(Yonggang Luo)  ---
(In reply to Hongtao.liu from comment #9)

> > Without `-mbmi` option, gcc can not compile and all other three compiler
> > can compile.
> 
> As long as it keeps semantics(respect zero input), I think this is
> acceptable.

Yeap, it's acceptable, but consistence with Clang/MSVC/ICL would be better.
That would makes the cross-platform code easier, besides, GCC also works for
WIN32, that's needs GCC to be consistence with MSVC

[Bug middle-end/110869] [14 regression] ICE in decompose, at rtl.h:2297

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

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

--- Comment #17 from ro at CeBiTec dot Uni-Bielefeld.DE  ---
> --- Comment #16 from Stefan Schulze Frielinghaus  ibm.com> ---
> Turns out that my dejagnu foo is weak ;-) I came up with a wrong target
> selector. Should be fixed in the new attachment.

Right: DejaGnu selector syntax is tricky indeed ;-(

Now tested on sparc-sun-solaris2.11 and amd-64-pc-solaris2.11: works as
expected.

One suggestion: in case you exclude a particular target by triple, it's
helpful to add a short comment explaining why this was done.  This way,
if the test later is discovered to FAIL on a different target, it's
easier to see if this is the same issue.  When using effective-target
keywords instead, the semantics of the exclusion is easier to
understand.

[Bug target/110899] RFE: Attributes preserve_most and preserve_all

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

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

Florian Weimer  changed:

   What|Removed |Added

 CC||fw at gcc dot gnu.org

--- Comment #2 from Florian Weimer  ---
I tried to write up something for the x86-64 psABI:

Document the ABI for __preserve_most__ function calls


This should match what Clang implements (but not what it documents).

[Bug c++/110930] Fix-it hints suggest wrong header for names in the global namespace

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

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

--- Comment #2 from Jonathan Wakely  ---
Yeah, that using-directive complicates things.

[Bug c++/110930] Fix-it hints suggest wrong header for names in the global namespace

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2023-08-07

--- Comment #1 from Richard Biener  ---
Confirmed.  Maybe still OK for code using 'using std'?  I wonder if we can
check for that somehow.

[Bug tree-optimization/110932] [14 Regression] Dead Code Elimination Regression since r14-2230-g7e904d6c7f2

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |14.0
 CC||hubicka at gcc dot gnu.org
   Keywords||missed-optimization

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

[wbx at openadk dot org via Gcc-bugs]

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

--- Comment #2 from Waldemar Brodkorb  ---
Created attachment 55701
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55701=edit
bsd-closefrom preprocessed

[Bug c++/110933] Add warning flags to check against integer overflow

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

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

--- Comment #2 from Richard Biener  ---
I think there should be specific warnings for the specific cases, not one that
tries to be general.

The example you give might be -Wiv-bound-conversion?

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

[wbx at openadk dot org via Gcc-bugs]

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

--- Comment #3 from Waldemar Brodkorb  ---
Is this correct to use -E to generate the file?

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

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

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

Richard Biener  changed:

   What|Removed |Added

 Target||m68k
  Component|c   |rtl-optimization
 Ever confirmed|0   |1
   Last reconfirmed||2023-08-07
   Keywords||ice-on-valid-code
 Status|UNCONFIRMED |WAITING

--- Comment #1 from Richard Biener  ---
Can you please provide preprocessed source?

[Bug target/110762] [11/12/13 Regression] inappropriate use of SSE (or AVX) insns for v2sf mode operations

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

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

--- Comment #24 from CVS Commits  ---
The master branch has been updated by hongtao Liu :

https://gcc.gnu.org/g:831017d5e72173f2c58e5475b7fcd35ee07a601f

commit r14-3032-g831017d5e72173f2c58e5475b7fcd35ee07a601f
Author: liuhongt 
Date:   Fri Aug 4 15:35:54 2023 +0800

i386: Clear upper bits of XMM register for V4HFmode/V2HFmode operations
[PR110762]

Similar like r14-2786-gade30fad6669e5, the patch is for V4HF/V2HFmode.

gcc/ChangeLog:

PR target/110762
* config/i386/mmx.md (3): Changed from define_insn
to define_expand and break into ..
(v4hf3): .. this.
(divv4hf3): .. this.
(v2hf3): .. this.
(divv2hf3): .. this.
(movd_v2hf_to_sse): New define_expand.
(movq__to_sse): Extend to V4HFmode.
(mmxdoublevecmode): Ditto.
(V2FI_V4HF): New mode iterator.
* config/i386/sse.md (*vec_concatv4sf): Extend to hanlde V8HF
by using mode iterator V4SF_V8HF, renamed to ..
(*vec_concat): .. this.
(*vec_concatv4sf_0): Extend to handle V8HF by using mode
iterator V4SF_V8HF, renamed to ..
(*vec_concat_0): .. this.
(*vec_concatv8hf_movss): New define_insn.
(V4SF_V8HF): New mode iterator.

gcc/testsuite/ChangeLog:

* gcc.target/i386/pr110762-v4hf.c: New test.

[Bug target/110921] Relax _tzcnt_u32 support x86, all x86 arch support for this instrunction

[crazylht at gmail dot com via Gcc-bugs]

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

--- Comment #9 from Hongtao.liu  ---

> There is a redundant xor instrunction,
There's false dependence issue on some specific processors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62011

> Without `-mbmi` option, gcc can not compile and all other three compiler
> can compile.

As long as it keeps semantics(respect zero input), I think this is acceptable.

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

[wbx at openadk dot org via Gcc-bugs]

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

Bug ID: 110934
   Summary: m68k: ICE with -fzero-call-used-regs=all compiling
openssh 9.3p2
   Product: gcc
   Version: 13.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: wbx at openadk dot org
  Target Milestone: ---

Hi,

following ICE is generated when using Buildroot to compile OpenSSH 9.3p2 for
m68k.

 /home/browa22-ext/openssh/output/host/bin/m68k-buildroot-linux-uclibc-gcc
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64  -Os -g0 
-pipe -Wno-error=format-truncation -Wall -Wpointer-arith -Wuninitialized
-Wsign-compare -Wformat-security -Wsizeof-pointer-memaccess -Wno-pointer-sign
-Wno-unused-result -Wimplicit-fallthrough -Wmisleading-indentation
-fno-strict-aliasing -D_FORTIFY_SOURCE=2 -ftrapv -fzero-call-used-regs=all
-ftrivial-auto-var-init=zero -fno-builtin-memset   -fPIC -I. -I.. -I. -I./..
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64
-D_XOPEN_SOURCE=600 -D_BSD_SOURCE -D_DEFAULT_SOURCE -D_GNU_SOURCE
-DHAVE_CONFIG_H -c bsd-closefrom.c
during RTL pass: zero_call_used_regs
bsd-closefrom.c: In function ‘closefrom’:
bsd-closefrom.c:151:1: internal compiler error: in change_address_1, at
emit-rtl.cc:2287
  151 | }
  | ^
0x7f5f7d66f189 __libc_start_call_main
../sysdeps/nptl/libc_start_call_main.h:58
0x7f5f7d66f244 __libc_start_main_impl
../csu/libc-start.c:381
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.

Using -fzero-call-used-regs=used fixes the build issue.

gcc -v:
/home/browa22-ext/openssh/output/host/bin/m68k-buildroot-linux-uclibc-gcc -v
Using built-in specs.
COLLECT_GCC=/home/browa22-ext/openssh/output/host/bin/m68k-buildroot-linux-uclibc-gcc.br_real
COLLECT_LTO_WRAPPER=/home/browa22-ext/openssh/output/host/libexec/gcc/m68k-buildroot-linux-uclibc/13.2.0/lto-wrapper
Target: m68k-buildroot-linux-uclibc
Configured with: ./configure --prefix=/home/browa22-ext/openssh/output/host
--sysconfdir=/home/browa22-ext/openssh/output/host/etc --enable-static
--target=m68k-buildroot-linux-uclibc
--with-sysroot=/home/browa22-ext/openssh/output/host/m68k-buildroot-linux-uclibc/sysroot
--enable-__cxa_atexit --with-gnu-ld --disable-libssp --disable-multilib
--disable-decimal-float --enable-plugins --enable-lto
--with-gmp=/home/browa22-ext/openssh/output/host
--with-mpc=/home/browa22-ext/openssh/output/host
--with-mpfr=/home/browa22-ext/openssh/output/host --with-pkgversion='Buildroot
2023.08-rc1-23-g3693462a1f' --with-bugurl=http://bugs.buildroot.net/
--without-zstd --disable-libquadmath --disable-libquadmath-support
--disable-libsanitizer --enable-tls --enable-threads --without-isl
--without-cloog --with-cpu=68040 --enable-languages=c
--with-build-time-tools=/home/browa22-ext/openssh/output/host/m68k-buildroot-linux-uclibc/bin
--enable-shared --disable-libgomp
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 13.2.0 (Buildroot 2023.08-rc1-23-g3693462a1f) 
COMPILER_PATH=/home/browa22-ext/openssh/output/host/libexec/gcc/m68k-buildroot-linux-uclibc/13.2.0/:/home/browa22-ext/openssh/output/host/libexec/gcc/m68k-buildroot-linux-uclibc/13.2.0/:/home/browa22-ext/openssh/output/host/libexec/gcc/m68k-buildroot-linux-uclibc/:/home/browa22-ext/openssh/output/host/lib/gcc/m68k-buildroot-linux-uclibc/13.2.0/:/home/browa22-ext/openssh/output/host/lib/gcc/m68k-buildroot-linux-uclibc/:/home/browa22-ext/openssh/output/host/lib/gcc/m68k-buildroot-linux-uclibc/13.2.0/../../../../m68k-buildroot-linux-uclibc/bin/
LIBRARY_PATH=/home/browa22-ext/openssh/output/host/lib/gcc/m68k-buildroot-linux-uclibc/13.2.0/:/home/browa22-ext/openssh/output/host/lib/gcc/m68k-buildroot-linux-uclibc/13.2.0/../../../../m68k-buildroot-linux-uclibc/lib/:/home/browa22-ext/openssh/output/host/m68k-buildroot-linux-uclibc/sysroot/lib/:/home/browa22-ext/openssh/output/host/m68k-buildroot-linux-uclibc/sysroot/usr/lib/
COLLECT_GCC_OPTIONS='--sysroot=/home/browa22-ext/openssh/output/host/m68k-buildroot-linux-uclibc/sysroot'
'-v' '-mcpu=68040' '-dumpdir' 'a.'

/home/browa22-ext/openssh/output/host/libexec/gcc/m68k-buildroot-linux-uclibc/13.2.0/collect2
-plugin
/home/browa22-ext/openssh/output/host/libexec/gcc/m68k-buildroot-linux-uclibc/13.2.0/liblto_plugin.so
-plugin-opt=/home/browa22-ext/openssh/output/host/libexec/gcc/m68k-buildroot-linux-uclibc/13.2.0/lto-wrapper
-plugin-opt=-fresolution=/tmp/cclgUbWV.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
--sysroot=/home/browa22-ext/openssh/output/host/m68k-buildroot-linux-uclibc/sysroot
--eh-frame-hdr -m m68kelf -dynamic-linker 

[Bug ipa/106116] Missed optimization: in no_reorder-attributed functions, tail calls to the subsequent function could just be function-to-function fallthrough

[pskocik at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Petr Skocik  ---
It would be interesting to do this at the assembler level, effectively
completely turning what's equivalent to `jmp 1f; 1:` to nothing. This would
also be in line with the GNU assembler's apparent philosophy that jmp is a
high-level variadic-length instruction (either jmp, or jmpq, whichever is
possible first => this could become: nothing, jmp, or jmpq).

I have a bunch of multiparam functions such with supporting functions
structured
as follows:

void func_A(int A){ func_AB(DEFAULT_C); }
void func_AB(int A, int B){ func_ABC(A,B,DEFAULT_C); }
void func_ABC(int A, int B, int C){ func_ABCD(A,B,C,DEFAULT_D); }
void func_ABC(int A, int B, int C, int D){
   //...
}
which could size-wise benefit from eliding the jumps, turning them into
fallthrus this way, but yeah, probably not worth the effort (unless somebody
knows how to easily hack gas to do it).

[Bug c/24542] potential unwanted truncation of operation overflow should be warned on assignment to wider variable

[mail+gcc at nh2 dot me via Gcc-bugs]

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

--- Comment #15 from Niklas Hambüchen  ---
Another common integer overflow bug type is the "for (u32 i = 0; i < u64; ++i)"
pattern, as well as general widening comparisons.

I filed bug 110933 for those; just linking it here for people interested in
integer overflows.

[Bug c++/110933] Add warning flags to check against integer overflow

[mail+gcc at nh2 dot me via Gcc-bugs]

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

--- Comment #1 from Niklas Hambüchen  ---
A tangentially related issue is bug 24542 which is about another common
overflow bug, the pattern "u64 = u32 * u32".

Just linking it here because people interested in solving integer overflow
issues may find it relevant.

[Bug c++/110933] New: Add warning flags to check against integer overflow

[mail+gcc at nh2 dot me via Gcc-bugs]

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

Bug ID: 110933
   Summary: Add warning flags to check against integer overflow
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mail+gcc at nh2 dot me
  Target Milestone: ---

GCC currently lacks good compile-time warnings that help find common integer
overflow bugs.

For example, the code

#include 

void f(uint64_t n)
{
for (uint32_t i = 0; i < n; ++i) {
}
}

will loop forever if `n` happens to be around 5 billion.

This is a mistake many programmers make (I've had to fix multiple instances of
this in common Free Software programs, and similar instances in the Linux
kernel).
The bug is not easy to spot because this standard incrementing-loop construct
looks "very terminating", and it gets much harder when typedefs, macros, or C++
type templates are involved.

(I would like to file this feature request both for C and C++, but Bugzilla
doesn't allow that, so I'm picking C++.)

Existing warnings such as `-Wsign-compare` are of the right spirit, but do not
help with e.g. simple unsigned integers.

In 
https://stackoverflow.com/questions/76840686/how-can-i-get-a-warning-when-comparing-unsigned-integers-of-different-size-in-c/

I asked for current ways to find such issues. The best current approaches are a
non-trivial clang-query invocation, and closed-source tools such as PVS Studio.

It would be better if GCC itself had better warnings to help with this.

In the above case, we have a binary operator between a wider and a narrower
integer type, and implicit (invisible) upcasting (widening) happens.

Having a flag to warn about such implictly-converting binary ops would go a
long way, but maybe there's a more general approach to this.

The implementation of such flag should probably consider some common benign
special cases, such as comparing with an integer literal that gets upcast (`x >
0` vs `0ul` -- safe since this constant exists in both domains).

It is clear that such warning would likely not be on by default, but it could
help tremendously for modernising software projects that e.g. weren't written
with a 64-bit mindset.

[Bug tree-optimization/110932] New: [14 Regression] Dead Code Elimination Regression since r14-2230-g7e904d6c7f2

[theodort at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 110932
   Summary: [14 Regression] Dead Code Elimination Regression since
r14-2230-g7e904d6c7f2
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

https://godbolt.org/z/fs5obnhPP

Given the following code:

void foo(void);
static short a;
static int b, c, f, h, i, k;
static char d, m;
static int *j, *o = 
static int **l = , **n = 
static unsigned p(short g, short) { return g; }
static short(q)(unsigned e) {
if (!(((e) >= 1) && ((e) <= 65531))) {
__builtin_unreachable();
}
return 0;
}
static short r() {
q( != 0 | f);
*l = o;
return h;
}
static int *s() {
m = c ?: d ?: m;
b = b ?: a;
a = 0;
return *l;
}
int main() {
char t = 0;
for (; t <= 4; t = t + 2) {
int *u = 
if (p(~(r() <= t), *u) > i == i) {
**n = -5L;
if (*u) continue;
**n = 0;
if (t) foo();
break;
}
s();
*u = u != 0;
}
s();
h = 0;
}

gcc-trunk -O3 does not eliminate the call to foo:

main:
subq$8, %rsp
movlh(%rip), %ecx
xorl%edx, %edx
movli(%rip), %eax
movq$f, j(%rip)
testw   %cx, %cx
setle   %dl
notl%edx
movswl  %dx, %edx
cmpl%edx, %eax
setb%dl
movzbl  %dl, %edx
cmpl%eax, %edx
jne .L22
testl   %eax, %eax
jne .L23
xorl%edx, %edx
movl%edx, f(%rip)
jmp .L14
.L22:
xorl%eax, %eax
calls.isra.0
movl$1, %eax
movl$1, i(%rip)
.L6:
movq$f, j(%rip)
xorl%edx, %edx
cmpw$2, %cx
setle   %dl
notl%edx
movswl  %dx, %edx
cmpl%edx, %eax
setb%dl
movzbl  %dl, %edx
cmpl%edx, %eax
je  .L8
xorl%eax, %eax
calls.isra.0
movl$1, %eax
movl$1, i(%rip)
.L9:
movq$f, j(%rip)
xorl%edx, %edx
cmpw$4, %cx
setle   %dl
notl%edx
movswl  %dx, %edx
cmpl%edx, %eax
setb%dl
movzbl  %dl, %edx
cmpl%edx, %eax
jne .L11
testl   %eax, %eax
je  .L10
movl$-5, f(%rip)
jmp .L14
.L8:
testl   %eax, %eax
jne .L24
.L10:
xorl%eax, %eax
movl%eax, f(%rip)
callfoo
.L14:
xorl%eax, %eax
calls.isra.0
xorl%eax, %eax
movl$0, h(%rip)
addq$8, %rsp
ret
.L11:
xorl%eax, %eax
calls.isra.0
movl$1, i(%rip)
jmp .L14
.L23:
movl$-5, f(%rip)
jmp .L6
.L24:
movl$-5, f(%rip)
jmp .L9

gcc-13.2.0 -O3 eliminates the call to foo:

main:
xorl%eax, %eax
cmpw$0, h(%rip)
movli(%rip), %edx
movq$f, j(%rip)
setle   %al
notl%eax
cwtl
cmpl%eax, %edx
setb%al
movzbl  %al, %eax
cmpl%edx, %eax
jne .L11
testl   %edx, %edx
jne .L6
.L7:
xorl%eax, %eax
movl%edx, f(%rip)
calls.isra.0
xorl%eax, %eax
movl$0, h(%rip)
ret
.L11:
xorl%eax, %eax
calls.isra.0
movl$1, i(%rip)
.L6:
movq$f, j(%rip)
movl$-5, %edx
jmp .L7

Bisects to r14-2230-g7e904d6c7f2

[Bug target/110921] Relax _tzcnt_u32 support x86, all x86 arch support for this instrunction

[luoyonggang at gmail dot com via Gcc-bugs]

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

--- Comment #8 from 罗勇刚(Yonggang Luo)  ---
(In reply to Hongtao.liu from comment #7)
> No, I think what clang does is correct,

Thanks, yeap, according to https://github.com/llvm/llvm-project/issues/64477
I think clang did it well.

GCC also needs handling the following code properly

```c
#ifdef _MSC_VER
#include 
__forceinline void
unreachable() {__assume(0);}
#else
#include 
inline __attribute__((always_inline)) void
unreachable() {
#if defined(__INTEL_COMPILER)
__assume(0);
#else
__builtin_unreachable();
#endif
}
#endif

int f(int a)
{
if (a == 0) {
  unreachable();
}
return _tzcnt_u32   (a);
}

```
According to https://godbolt.org/z/T9axzaPqj

gcc with `-O2 -mbmi -m32` option compiled to
```asm
f(int):
xor eax, eax
tzcnt   eax, DWORD PTR [esp+4]
ret
```

There is a redundant xor instrunction,
Without `-mbmi` option, gcc can not compile and all other three compiler
can compile.
This issue still make sense, gcc can fixes it in Clang's way

[Bug tree-optimization/110931] New: [14 Regression] Dead Code Elimination Regression since r14-2890-gcc2003cd875

[theodort at inf dot ethz.ch via Gcc-bugs]

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

Bug ID: 110931
   Summary: [14 Regression] Dead Code Elimination Regression since
r14-2890-gcc2003cd875
   Product: gcc
   Version: 14.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: theodort at inf dot ethz.ch
  Target Milestone: ---

https://godbolt.org/z/zPTeo8Mj9

Given the following code:

void foo(void);
static int a = 7, c;
static int *d = , *e;
static int **f = 
static short g;
static char(h)(char b) {
if (!(((b) >= 1) && ((b) <= 1))) {
__builtin_unreachable();
}
return 0;
}
static void k(unsigned i) {
short j = i;
if (j)
;
else {
h(i);
if ((e && i) <= 0)
;
else
foo();
*f = 
}
h(0 >= 0);
}
int main() {
int l = *d;
g = l;
k(g);
}

gcc-trunk -O3 does not eliminate the call to foo:

main:
cmpw$0, a(%rip)
jne .L5
cmpq$0, e(%rip)
je  .L6
pushq   %rax
callfoo
xorl%eax, %eax
movq$c, e(%rip)
popq%rdx
ret
.L6:
movq$c, e(%rip)
.L5:
xorl%eax, %eax
ret

gcc-13.2.0 -O3 eliminates the call to foo:

main:
xorl%eax, %eax
ret

Bisects to r14-2890-gcc2003cd875

[Bug target/110696] RISC-V: -march doesn't imply correctly

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

JuzheZhong  changed:

   What|Removed |Added

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

--- Comment #3 from JuzheZhong  ---
Fixed

[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

Bug 110897 Summary: RISC-V: Fail to vectorize shift
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110897

   What|Removed |Added

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

[Bug tree-optimization/110897] RISC-V: Fail to vectorize shift

[juzhe.zhong at rivai dot ai via Gcc-bugs]

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

JuzheZhong  changed:

   What|Removed |Added

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

--- Comment #20 from JuzheZhong  ---
Fixed by this patch:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=c5f673dbc252e35e6b66e9b8abd30a4027193e0b

[Bug c++/110930] New: Fix-it hints suggest wrong header for names in the global namespace

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

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

Bug ID: 110930
   Summary: Fix-it hints suggest wrong header for names in the
global namespace
   Product: gcc
   Version: 13.1.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: redi at gcc dot gnu.org
  Target Milestone: ---

Given:

uint32_t i = 0;

We say:

dcl.cc:1:1: error: 'uint32_t' does not name a type
1 | uint32_t i = 0;
  | ^~~~
dcl.cc:1:1: note: 'uint32_t' is defined in header ''; this is probably
fixable by adding '#include '
  +++ |+#include 
1 | uint32_t i = 0;


But this is wrong. uint32_t is declared in , std::uint32_t is
declared in .

We should not be encouraging reliance on the non-portable property that some
implementations of  leak the name into the global namespace as well as
namespace std.

This is the case for every name in the C++ stdlib that comes from the C stdlib.

[Bug c++/99404] Diagnostics for undeclared members of a namespace don't say "namespace"

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

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
 Ever confirmed|0   |1
   Last reconfirmed||2023-08-07