[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32

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

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

--- Comment #4 from Christophe Lyon  ---
Indeed my patch aimed at catching such inconsistencies.
I guess before that the build had a 'strange' behavior? (with a missing
dirname, some parts of the shell genmultilib shell script would expand into
empty values, probably leading to unintended behaviour)

[Bug analyzer/108003] [13 Regression] ICE in bitmap_check_index, at sbitmap.h:105

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug ipa/108000] Assert during ipa-cp with AutoFDO

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

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

Richard Biener  changed:

   What|Removed |Added

   Assignee|unassigned at gcc dot gnu.org  |erozen at microsoft dot 
com
 Status|WAITING |ASSIGNED

[Bug tree-optimization/108002] Throwing exception when compiling third-parties(ZSTD) libraries with optimization option

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

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

--- Comment #5 from Richard Biener  ---
Btw, you can always try to bisect what GCC change fixed the issue and try
backporting this yourself.

[Bug target/108004] x-form logical operations with dot instructions are not emitted.

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

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

--- Comment #3 from HaoChen Gui  ---
(In reply to Andrew Pinski from comment #2)
> Especially when it comes to signed comparisons.

>From the ISA,
For all fixed-point instructions in which Rc=1, and for
addic., andi., and andis., the first three bits of CR Field
0 (bits 32:34 of the Condition Register) are set by
signed comparison of the result to zero, and the fourth
bit of CR Field 0 (bit 35 of the Condition Register) is
copied from the SO field of the XER.

[Bug target/105523] Wrong warning array subscript [0] is outside array bounds

[ahmad at a3f dot at via Gcc-bugs]

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

Ahmad Fatoum  changed:

   What|Removed |Added

 CC||ahmad at a3f dot at

--- Comment #14 from Ahmad Fatoum  ---
Does param=min-pagesize=0 solely influence warnings or could it now or in the
future affect code generation/optimization?

I ask because barebox (https://barebox.org) also has this problem as on i.MX8,
where it calls into ROM code, which starts at address 0. After that's done, it
maps the NULL page there and normal accesses are unexpected. So if it's just
about the warning, I'd prefer hiding pointer value via a compiler barrier where
appliable instead of disabling the warning altogether.

[Bug target/108004] x-form logical operations with dot instructions are not emitted.

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

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

--- Comment #2 from Andrew Pinski  ---
Especially when it comes to signed comparisons.

[Bug target/108004] x-form logical operations with dot instructions are not emitted.

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

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

--- Comment #1 from Andrew Pinski  ---
>From what I remember and. Only sets eq bit correctly.

[Bug target/108004] New: x-form logical operations with dot instructions are not emitted.

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

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

Bug ID: 108004
   Summary: x-form logical operations with dot instructions are
not emitted.
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: guihaoc at gcc dot gnu.org
  Target Milestone: ---

//test case
int foo (int a, int b, int c, int d)
{
  return (a & b) > 0 ? c : d;
}

//assemble on P9
and 3,3,4
cmpwi 0,3,0
isel 5,5,6,1
extsw 3,5

The "and" and "cmpwi" can be optimized to "and." instruction. The same as "or"
and "xor".

[Bug testsuite/105095] gcc.dg/vect/complex/fast-math-complex-* tests are not executed

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |11.4
  Known to work||11.3.1, 12.0
  Known to fail||11.3.0

[Bug c/104822] -Wscalar-storage-order warning for initialization from NULL seems useless

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

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

--- Comment #3 from Andrew Pinski  ---
(In reply to Andrew Pinski from comment #2)
> Mine, I think this patch will fix the issue:
Which is similar to the check above dealing with named address spaces.

[Bug c/104822] -Wscalar-storage-order warning for initialization from NULL seems useless

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #2 from Andrew Pinski  ---
Mine, I think this patch will fix the issue:
diff --git a/gcc/c/c-typeck.cc b/gcc/c/c-typeck.cc
index f1a1752782a..43b9793e339 100644
--- a/gcc/c/c-typeck.cc
+++ b/gcc/c/c-typeck.cc
@@ -7480,6 +7480,7 @@ convert_for_assignment (location_t location, location_t
expr_loc, tree type,

   /* See if the pointers point to incompatible scalar storage orders.  */
   if (warn_scalar_storage_order
+ && !null_pointer_constant_p (rhs)
  && (AGGREGATE_TYPE_P (ttl) && TYPE_REVERSE_STORAGE_ORDER (ttl))
 != (AGGREGATE_TYPE_P (ttr) && TYPE_REVERSE_STORAGE_ORDER (ttr)))
{

[Bug tree-optimization/105043] Documentation for __builtin_object_size and other Object Size checking builtin functions should mention - D_FORTIFY_SOURCE

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Resolution|MOVED   |---
Summary|Please document |Documentation for
   |-D_FORTIFY_SOURCE   |__builtin_object_size and
   ||other Object Size checking
   ||builtin functions should
   ||mention - D_FORTIFY_SOURCE
   Severity|normal  |enhancement
 Status|RESOLVED|NEW

--- Comment #7 from Andrew Pinski  ---
I do think we should mention in the section about __builtin_object_size that
this used in connection with the -D_FORTIFY_SOURCE feature of some libc's.

That is on this page:
https://gcc.gnu.org/onlinedocs/gcc/Object-Size-Checking.html#Object-Size-Checking

Mention that the libc feature -D_FORTIFY_SOURCE uses these builtins.
I am not 100% sure on the exact wording but that should give a hint to the user
of GCC to look into glibc/libc documentation for -D_FORTIFY_SOURCE.

[Bug tree-optimization/108002] Throwing exception when compiling third-parties(ZSTD) libraries with optimization option

[pefy19950714 at gmail dot com via Gcc-bugs]

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

--- Comment #4 from Grant Li  ---
(In reply to Andrew Pinski from comment #3)
> #  pragma GCC optimize("-O2")
> 
> The bugs that related to this pragma were fixed in GCC 4.8.0 (a few were
> fixed before).
> There were many changes that helped fix it.
> You could always build a newer GCC yourself but with an over 10 year release
> is not going to be really supported.
> There is nothing GCC bug report can do to help you.
> 
> RHEL5 is just not supported.

Thanks! I will discuss it with my team, appreciate your prompt reply.

[Bug analyzer/108003] New: [13 Regression] ICE in bitmap_check_index, at sbitmap.h:105

[asolokha at gmx dot com via Gcc-bugs]

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

Bug ID: 108003
   Summary: [13 Regression] ICE in bitmap_check_index, at
sbitmap.h:105
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: analyzer
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: asolokha at gmx dot com
  Target Milestone: ---

gcc 13.0.0 20221204 snapshot (g:24b9337d1f1b5197b6498dceb9074319be003449) ICEs
when compiling the following testcase, reduced from
libstdc++-v3/testsuite/27_io/basic_filebuf/seekoff/wchar_t/9875_seekoff.cc, w/
-O1 -fanalyzer --param analyzer-max-svalue-depth=5:

struct locale {
  class _Impl;
  _Impl *_M_impl;

  template 
  locale (const locale &, _Facet *);

  static locale
  classic ();
};

struct locale::_Impl {
  _Impl (_Impl, int);
};

template 
locale::locale (const locale &, _Facet *)
{
  new _Impl (*_M_impl, 1);
}

struct codecvt {
  virtual void do_max_lengththrow ();
};

void
test01 ()
{
  locale (locale::classic (), new codecvt);
}

% g++-13 -O1 -fanalyzer --param analyzer-max-svalue-depth=5 -c nsbergsz.cc
during IPA pass: analyzer
nsbergsz.cc: In constructor 'locale::locale(const locale&, _Facet*) [with
_Facet = codecvt]':
nsbergsz.cc:19:3: internal compiler error: in bitmap_check_index, at
sbitmap.h:105
   19 |   new _Impl (*_M_impl, 1);
  |   ^~~
0x8a6707 bitmap_check_index
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/sbitmap.h:105
0x8a6707 bitmap_set_bit
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/sbitmap.h:133
0x8a6707 ana::region_model::get_referenced_base_regions(auto_sbitmap&) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/region-model.cc:4908
0x15b0692 ana::region_model::get_or_create_region_for_heap_alloc(ana::svalue
const*, ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/region-model.cc:4879
0x15c1a49 ana::kf_operator_new::impl_call_pre(ana::call_details const&) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/region-model-impl-calls.cc:996
0x15ac579 ana::region_model::on_call_pre(gcall const*,
ana::region_model_context*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/region-model.cc:1477
0x157b634 ana::feasibility_state::maybe_update_for_edge(ana::logger*,
ana::exploded_edge const*, ana::rejected_constraint**)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/engine.cc:4832
0x21e7ef1 ana::epath_finder::process_worklist_item(ana::feasible_worklist*,
ana::trimmed_graph const&, ana::feasible_graph*, ana::exploded_node const*,
unsigned int, std::unique_ptr >*) const
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/diagnostic-manager.cc:498
0x21e8848 ana::epath_finder::explore_feasible_paths(ana::exploded_node const*,
char const*, unsigned int)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/diagnostic-manager.cc:418
0x21e8f31 ana::epath_finder::get_best_epath(ana::exploded_node const*, char
const*, unsigned int, std::unique_ptr >*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/diagnostic-manager.cc:164
0x21e905c ana::saved_diagnostic::calc_best_epath(ana::epath_finder*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/diagnostic-manager.cc:811
0x21ed7cf ana::dedupe_winners::add(ana::logger*, ana::epath_finder*,
ana::saved_diagnostic*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/diagnostic-manager.cc:1178
0x21ea5a3 ana::diagnostic_manager::emit_saved_diagnostics(ana::exploded_graph
const&)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/diagnostic-manager.cc:1328
0x15878ec ana::impl_run_checkers(ana::logger*)
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/engine.cc:6112
0x15888c6 ana::run_checkers()
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/engine.cc:6186
0x15771e8 execute
   
/var/tmp/portage/sys-devel/gcc-13.0.0_p20221204/work/gcc-13-20221204/gcc/analyzer/analyzer-pass.cc:87

[Bug tree-optimization/108002] Throwing exception when compiling third-parties(ZSTD) libraries with optimization option

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

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

Andrew Pinski  changed:

   What|Removed |Added

   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=50602,
   ||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=47011
 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |WONTFIX

--- Comment #3 from Andrew Pinski  ---
#  pragma GCC optimize("-O2")

The bugs that related to this pragma were fixed in GCC 4.8.0 (a few were fixed
before).
There were many changes that helped fix it.
You could always build a newer GCC yourself but with an over 10 year release is
not going to be really supported.
There is nothing GCC bug report can do to help you.

RHEL5 is just not supported.

[Bug tree-optimization/108002] Throwing exception when compiling third-parties(ZSTD) libraries with optimization option

[pefy19950714 at gmail dot com via Gcc-bugs]

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

--- Comment #2 from Grant Li  ---
(In reply to Andrew Pinski from comment #1)
> 4.4.3 is over 12 years old now. Is there any way to move to something newer?

I already tried gcc 4.4.7 and 4.4.4... but also had same error.
We need to compatible gcc with our RHEL5 environment, so it is the reason why I
can't move to more higher gcc version.
Can I know is it a known issue or is it fixed on any higher gcc version?

[Bug tree-optimization/108002] Throwing exception when compiling third-parties(ZSTD) libraries with optimization option

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

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

--- Comment #1 from Andrew Pinski  ---
4.4.3 is over 12 years old now. Is there any way to move to something newer?

[Bug c/108002] New: Throwing exception when compiling third-parties(ZSTD) libraries with optimization option

[pefy19950714 at gmail dot com via Gcc-bugs]

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

Bug ID: 108002
   Summary: Throwing exception when compiling third-parties(ZSTD)
libraries with optimization option
   Product: gcc
   Version: 4.4.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pefy19950714 at gmail dot com
  Target Milestone: ---

I got below exception when I was compiling zstd libraries with any g++
optimization options(O1, O2, O3, etc).
But, the compilation can be passed if I remove the optimization option.
-
.//src/extern/zstd/src/zstd.c: In function ‘ZSTD_bounds 
ZSTD_cParam_getBounds(ZSTD_cParameter)’:
.//src/extern/zstd/src/zstd.c:18062: internal compiler error: in tree_nrv, at
tree-nrv.c:143
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.

-

There are some required information for your reference with gcc -v.
We are using redhat-release-5Client-5.9.0.2.

-

Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../gcc-4.4.3/configure --prefix=/mu/dev/gcc/4.4.3-rhel5-64
--with-local-prefix=/mu/mtsdk/corplib/gcc443-rhel5-64 --with-as=/mu/bin/gas
--with-ar=/mu/bin/gar --with-ld=/mu/bin/gld --with-nm=/mu/bin/gnm
--enable-bootstrap --enable-targets=x86_64,i686 --build=x86_64-redhat-linux
Thread model: posix
gcc version 4.4.3 (GCC)

-

The command we used to compile zstd lib:
g++ -O3 zstd.c -c -o zstd.o

-

ZSTD lib can be downloaded from here: 
https://github.com/facebook/zstd

-
Thanks for your help, and hope I can get the updates soon!

[Bug go/107992] m68k-linux-gnu bootstap error in gofrontend

[ian at airs dot com via Gcc-bugs]

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

--- Comment #1 from Ian Lance Taylor  ---
Thanks.  This is happening because the data structures that Go's garbage
collector uses require that all pointers be aligned on their natural
boundaries.  Unfortunately m68k only provides 2-byte alignment for 4-byte
pointers, not 4-byte alignment.  I don't know if there will be a simple fix. 
We could probably adjust the alignment for data structures defined in Go, which
would fix this case, but that wouldn't help with C interoperability.

[Bug c++/108001] New: unamed struct extension is documented for C++

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

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

Bug ID: 108001
   Summary: unamed struct extension is documented for C++
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Keywords: documentation
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Even though this extension is documented for C
(https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Unnamed-Fields.html) . The
documentation there does not even say it works for C++.
There are other interactions with standard C++ which is not mentioned, See PR
105059 for that even.

[Bug c++/18474] Unary plus/minus lvalueness not diagnosed in templates

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

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

--- Comment #2 from Andrew Pinski  ---
Note this is only invalid as n (if declared correctly) was not depedent so the
operator lookup would be bound at definition time.

That is the following needs to be accepted still:
template 
void g(void)
{
  T n;
  -n = 0;
  +n = 0;
}

[Bug target/106708] [rs6000] 64bit constant generation with oris xoris

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

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

--- Comment #1 from Jiu Fu Guo  ---
PR93178 also mentioned the "li,oris" case.

[Bug c++/105059] Inconsistency between paren- and brace-initialization of a union with anonymous struct

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|accepts-invalid |documentation
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-12-07

--- Comment #1 from Andrew Pinski  ---
With -pedantic:
:2:12: warning: ISO C++ prohibits anonymous structs [-Wpedantic]
2 | struct {
  |^


So I think this is just a documentation issue of what anonymous struct means
with each of the initializers.

Yes there is an inconsitancy with respect to () vs {} here though.

Confirmed.

[Bug middle-end/104975] ICE in execute, at gimple-harden-conditionals.cc:577 and returns_twice and pure attributes on the same function

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug tree-optimization/105049] [12 Regression] ICE: in build_vector_from_val, at tree.cc:2119 with -O -fno-tree-forwprop

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0
Summary|ICE: in |[12 Regression] ICE: in
   |build_vector_from_val, at   |build_vector_from_val, at
   |tree.cc:2119 with -O|tree.cc:2119 with -O
   |-fno-tree-forwprop  |-fno-tree-forwprop

[Bug target/103302] wrong code with -fharden-compares

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

--- Comment #18 from Andrew Pinski  ---
(In reply to Alexandre Oliva from comment #17)
> The patch went in on 2022-03-02, commit
> 12f8dc0b642db5edc702f252af1a5231606b29db, but I failed to tag this PR in the
> commit message.

r12-7453-g12f8dc0b642db5edc702f

[Bug c++/105047] invalid non-dependent call to non-static member of the current instantiation not rejected ahead of time

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-12-07
   Keywords||diagnostic
 Ever confirmed|0   |1

--- Comment #1 from Andrew Pinski  ---
Confirmed. Note clang only rejects the call in g.
MSVC acts like GCC here.

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

[caiyinyu at loongson dot cn via Gcc-bugs]

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

--- Comment #10 from caiyinyu  ---
(In reply to Jakub Jelinek from comment #9)
> Created attachment 54029 [details]
> gcc13-pr107967.patch
> 
> Untested fix.  Deferring the mode_composite stuff for later.

There are still some fails and errors are almost all about "Exception "Divide
by zero" not set".

cat math/test-float64-lgamma.out:
testing _Float64 (without inline functions)
Failure: lgamma (-3): Exception "Divide by zero" not set
Failure: lgamma_downward (-3): Exception "Divide by zero" not set
Failure: lgamma_towardzero (-3): Exception "Divide by zero" not set
Failure: lgamma_upward (-3): Exception "Divide by zero" not set

Test suite completed:
  7880 test cases plus 5260 tests for exception flags and
5260 tests for errno executed.
  4 errors occurred.


FAIL: math/test-double-lgamma
FAIL: math/test-double-log1p
FAIL: math/test-float-lgamma
FAIL: math/test-float-log1p
FAIL: math/test-float128-catan
FAIL: math/test-float128-catanh
FAIL: math/test-float128-lgamma
FAIL: math/test-float128-log
FAIL: math/test-float128-log1p
FAIL: math/test-float128-y0
FAIL: math/test-float128-y1
FAIL: math/test-float32-lgamma
FAIL: math/test-float32-log1p
FAIL: math/test-float32x-lgamma
FAIL: math/test-float32x-log1p
FAIL: math/test-float64-lgamma
FAIL: math/test-float64-log1p
FAIL: math/test-float64x-lgamma
FAIL: math/test-ldouble-lgamma

[Bug target/107970] [13 Regression] ICE in extract_insn, at recog.cc:2791 since r13-2730-gd0c73b6c85677e67

[crazylht at gmail dot com via Gcc-bugs]

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

Hongtao.liu  changed:

   What|Removed |Added

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

--- Comment #3 from Hongtao.liu  ---
Fixed in GCC13.

[Bug target/107970] [13 Regression] ICE in extract_insn, at recog.cc:2791 since r13-2730-gd0c73b6c85677e67

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

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

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

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

commit r13-4532-gda7fb32d403759daefefc79dc251d2437c1b638c
Author: liuhongt 
Date:   Tue Dec 6 13:21:04 2022 +0800

Fix ICE due to condition mismatch between expander and define_insn.

ice.i:7:1: error: unrecognizable insn:
7 | }
  | ^
(insn 7 6 8 2 (set (reg:V2SF 84 [ vect__3.8 ])
(unspec:V2SF [
(reg:V2SF 86 [ vect__1.7 ])
(const_int 11 [0xb])
] UNSPEC_ROUND)) "ice.i":5:14 -1
 (nil))
during RTL pass: vregs

gcc/ChangeLog:

PR target/107970
* config/i386/mmx.md (btruncv2sf2): Add TARGET_MMX_WITH_SSE to
the condition.

gcc/testsuite/ChangeLog:

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

[Bug c++/105050] error: expression '' is not a constant expression

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug c++/105050] error: expression '' is not a constant expression

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

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

--- Comment #7 from Andrew Pinski  ---
I think clang still gives a better error message here though:
:43:15: error: static assertion expression is not an integral constant
expression
static_assert(test_swap());
  ^~~
:18:17: note: non-constexpr function '_M_swap_val' cannot be used in a
constant expression
  this->_M_swap_val(__x);
^
:38:6: note: in call to '&e1->swap(e2)'
  e1.swap(e2);
 ^
:43:15: note: in call to 'test_swap()'
static_assert(test_swap());
  ^
:4:10: note: declared here
void _M_swap_val(expected&) { }
 ^

[Bug ipa/108000] Assert during ipa-cp with AutoFDO

[erozen at microsoft dot com via Gcc-bugs]

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

--- Comment #2 from Eugene Rozenfeld  ---
I actually have a fix for this, just wanted to file a simple test case. I
initially ran into this failure while reviving autoprofiledbootstrap build. The
failure happens while using the profile and the bug is an incorrect count
comparison. 

Here is the patch:
https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606935.html

I will add this test to the patch before submitting it.

[Bug ipa/108000] Assert during ipa-cp with AutoFDO

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-07
 Status|UNCONFIRMED |WAITING
 Ever confirmed|0   |1

[Bug ipa/108000] Assert during ipa-cp with AutoFDO

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

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

--- Comment #1 from Andrew Pinski  ---
Can you provide the exact command lines being used and does it fail during
while using the profile or before?

[Bug c/107980] va_start does not warn about an arbitrary number of arguments in C2x mode

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #12 from joseph at codesourcery dot com  ---
The standard rule about not using extra arguments means that any warnings 
would need to avoid even converting those arguments from pp-tokens to 
tokens; it's OK for them to contain pp-tokens that cannot be converted to 
tokens.

I think the accepted change to the standard was entirely clear about 
ignoring the extra arguments; it wasn't some obscure non-obvious 
consequence that such code would become valid.

[Bug ipa/108000] New: Assert during ipa-cp with AutoFDO

[erozen at microsoft dot com via Gcc-bugs]

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

Bug ID: 108000
   Summary: Assert during ipa-cp with AutoFDO
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: ipa
  Assignee: unassigned at gcc dot gnu.org
  Reporter: erozen at microsoft dot com
CC: marxin at gcc dot gnu.org
  Target Milestone: ---

The test case below fails with

during IPA pass: cp
/home/erozen/gcc4/gcc/testsuite/gcc.dg/tree-prof/pr1.c:93:1: internal
compiler error: in good_cloning_opportunity_p, at ipa-cp.cc:3545
0x1d7ee83 good_cloning_opportunity_p
/home/erozen/gcc4_objdir/../gcc4/gcc/ipa-cp.cc:3545
0x1d7fa66 estimate_local_effects
/home/erozen/gcc4_objdir/../gcc4/gcc/ipa-cp.cc:3752
0x1d8098d propagate_constants_topo
/home/erozen/gcc4_objdir/../gcc4/gcc/ipa-cp.cc:4080
0x1d80fa5 ipcp_propagate_stage
/home/erozen/gcc4_objdir/../gcc4/gcc/ipa-cp.cc:4267
0x1d86fc5 ipcp_driver
/home/erozen/gcc4_objdir/../gcc4/gcc/ipa-cp.cc:6574
0x1d87192 execute
/home/erozen/gcc4_objdir/../gcc4/gcc/ipa-cp.cc:6651

#include 

volatile int flag;
const int array_size = 10;
int* array;
int iterations = 1000;

#define BAR(num) \
int __attribute__((noinline)) \
bar##num (int i, int j) \
{ \
  if (i == 0) \
return 2*num - 1; \
  else \
return 2*num; \
}

BAR(1)
BAR(2)
BAR(3)
BAR(4)
BAR(5)
BAR(6)
BAR(7)
BAR(8)
BAR(9)
BAR(10)
BAR(11)
BAR(12)
BAR(13)
BAR(14)
BAR(15)
BAR(16)
BAR(17)
BAR(18)
BAR(19)

int __attribute__((noinline))
foo ()
{
  switch (flag)
  {
case 1:
return bar1 (0, 0);
case 2:
return bar2 (0, 0);
case 3:
return bar3 (0, 0);
case 4:
return bar4 (0, 0);
case 5:
return bar5 (0, 0);
case 6:
return bar6 (0, 0);
case 7:
return bar7 (0, 0);
case 8:
return bar8 (0, 0);
case 9:
return bar9 (0, 0);
case 10:
return bar10 (0, 0);
case 11:
return bar11 (0, 0);
case 12:
return bar12 (0, 0);
case 13:
return bar13 (0, 0);
case 14:
return bar14 (0, 0);
case 15:
return bar15 (0, 0);
case 16:
return bar16 (0, 0);
case 17:
return bar17 (0, 0);
case 18:
return bar18 (0, 0);
default:
return bar19(0, 0);
  }
}

int
main ()
{
  flag = 0;
  array = calloc(array_size, sizeof(int));
  for (int i = 0, j = 0; i < iterations; ++i, j = (j + 1) % 10)
array[j] = foo ();
}

[Bug testsuite/107999] [13 Regression] test-error-array-bounds.c now fails because [-Warray-bounds] was updated to [-Warray-bounds=] in error messages after r13-4410-g7c01d029fca669263b9c2

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
Summary|test-error-array-bounds.c   |[13 Regression]
   |now fails because   |test-error-array-bounds.c
   |[-Warray-bounds] was|now fails because
   |updated to  |[-Warray-bounds] was
   |[-Warray-bounds=] in error  |updated to
   |messages|[-Warray-bounds=] in error
   ||messages after
   ||r13-4410-g7c01d029fca669263
   ||b9c2

[Bug jit/107770] Comparison of vectors of float doesn't work

[bouanto at zoho dot com via Gcc-bugs]

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

Antoni  changed:

   What|Removed |Added

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

--- Comment #2 from Antoni  ---
Fixed by commit d2e782cb99c3116c389d6a9565678c4ffe26.

[Bug c/107954] Support -std=c23/gnu23 as aliases of -std=c2x/gnu2x

[joseph at codesourcery dot com via Gcc-bugs]

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

--- Comment #3 from joseph at codesourcery dot com  ---
Editorial review before the CD ballot slipped the schedule.  Second-round 
editorial review after a huge number of changes in the editorial review 
slipped the schedule.  Getting a final draft with all the changes into the 
CD ballot process slipped the schedule.  The January meeting is two weeks 
later than originally planned because of the schedule delays.  I just sent 
206 comments on the CD to BSI for submission to ISO as the UK comments and 
if other NBs have similar numbers of comments, (a) it wouldn't surprise me 
if there's difficulty in getting through all of them in a single week's 
meeting (even if we find a way not to need to discuss all the editorial 
comments individually in the meeting) and (b) there could easily be 
further delays getting all the changes into the working draft and reviewed 
for being correctly applied.  So despite the 56-day "ISO editing" period 
on the schedule before the DIS ballot (which may be meant to deal with all 
the editorial issues ISO comes up with at the last minute), it's entirely 
plausible there could be schedule slip for the DIS ballot - even supposing 
we don't need any extra ballot stages (CD2 or FDIS).

So while it's possible that the new standard will be published in 2023 - 
or with a __STDC_VERSION__ value from 2023 even if published in 2024 - 
there is plenty of scope for the schedule to slip given the amount of work 
that still needs to be done on the draft.

[Bug jit/107999] New: test-error-array-bounds.c now fails because [-Warray-bounds] was updated to [-Warray-bounds=] in error messages

[bouanto at zoho dot com via Gcc-bugs]

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

Bug ID: 107999
   Summary: test-error-array-bounds.c now fails because
[-Warray-bounds] was updated to [-Warray-bounds=] in
error messages
   Product: gcc
   Version: 12.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

The error message needs to be updated to make this test pass again.

[Bug jit/107770] Comparison of vectors of float doesn't work

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Antoni Boucher :

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

commit r13-4531-gd2e782cb99c3116c389d6a9565678c4ffe26
Author: Antoni Boucher 
Date:   Sun Nov 20 10:22:53 2022 -0500

libgccjit: Fix float vector comparison

Fix float vector comparison and add comparison tests to include float and
vectors.

gcc/testsuite:
PR jit/107770
* jit.dg/harness.h: Add new macro to to perform vector
comparisons
* jit.dg/test-expressions.c: Extend comparison tests to add float
types and vectors

gcc/jit:
PR jit/107770
* jit-playback.cc: Fix vector float comparison
* jit-playback.h: Update comparison function signature
* jit-recording.cc: Update call for "new_comparison" function
* jit-recording.h: Fix vector float comparison

Co-authored-by: Guillaume Gomez 
Signed-off-by: Guillaume Gomez 

[Bug libstdc++/106611] std::is_nothrow_copy_constructible returns wrong result

[nikolasklauser at berlin dot de via Gcc-bugs]

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

--- Comment #6 from Nikolas Klauser  ---
Is there any update on this?

[Bug tree-optimization/107997] [13 Regression] fd8dd6c03849691 probably uncovered an issue building the Linux kernel

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||ice-on-valid-code
  Component|regression  |tree-optimization
Summary|fd8dd6c03849691 probably|[13 Regression]
   |uncovered an issue building |fd8dd6c03849691 probably
   |the Linux kernel|uncovered an issue building
   ||the Linux kernel
   Target Milestone|--- |13.0
 Target||powerpc64-linux

[Bug target/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Target Milestone|--- |13.0
  Component|bootstrap   |target
 CC||clyon at gcc dot gnu.org

--- Comment #3 from Andrew Pinski  ---
MULTILIB_OPTIONS = m64/m32
MULTILIB_DIRNAMES = 64
MULTILIB_OSDIRNAMES = ../lib ../lib32

Hmmm, the fix is obviously just add 32 to MULTILIB_DIRNAMES .

https://gcc.gnu.org/pipermail/gcc-patches/2022-November/606887.html

[Bug c++/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32

[mckelvey at maskull dot com via Gcc-bugs]

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

--- Comment #2 from James McKelvey  ---
Configured with:

./configure --enable-languages=c,c++ --enable-threads=posix

[Bug analyzer/107882] [13 Regression] ICE in get_last_bit_offset, at analyzer/store.h:255 since 13-2582-g0ea5e3f4542832b8

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

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

David Malcolm  changed:

   What|Removed |Added

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

--- Comment #5 from David Malcolm  ---
Should be fixed by the above patch.

[Bug c++/107998] [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32

[mckelvey at maskull dot com via Gcc-bugs]

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

--- Comment #1 from James McKelvey  ---
Created attachment 54032
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54032&action=edit
Config log

[Bug analyzer/107882] [13 Regression] ICE in get_last_bit_offset, at analyzer/store.h:255 since 13-2582-g0ea5e3f4542832b8

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

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

--- Comment #4 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r13-4529-gdfe2ef7f2b6cac7017f32a0a04f74e1b6d9f1311
Author: David Malcolm 
Date:   Tue Dec 6 18:24:16 2022 -0500

analyzer: don't create bindings or binding keys for empty regions
[PR107882]

PR analyzer/107882 reports an ICE, due to trying to get a compound svalue
for this binding:

  cluster for: a:
key:   {bytes 0-3}
value:  {UNKNOWN()}
key:   {empty}
value:  {UNKNOWN()}
key:   {bytes 4-7}
value:  {UNKNOWN()}

where there's an binding to the unknown value of zero bits in size
"somewhere" within "a" (perhaps between bits 3 and 4?)

This makes no sense, so this patch adds an assertion that we never
attempt to create a binding key for an empty region, and adds early
rejection of attempts to get or set the values of such regions, fixing
the ICE.

gcc/analyzer/ChangeLog:
PR analyzer/107882
* region-model.cc (region_model::get_store_value): Return an
unknown value for empty regions.
(region_model::set_value): Bail on empty regions.
* region.cc (region::empty_p): New.
* region.h (region::empty_p): New decl.
* state-purge.cc (same_binding_p): Bail if either region is empty.
* store.cc (binding_key::make): Assert that a concrete binding's
bit_size must be > 0.
(binding_cluster::mark_region_as_unknown): Bail on empty regions.
(binding_cluster::get_binding): Likewise.
(binding_cluster::remove_overlapping_bindings): Likewise.
(binding_cluster::on_unknown_fncall): Don't conjure values for
empty regions.
(store::fill_region): Bail on empty regions.
* store.h (class concrete_binding): Update comment to reflect that
the range of bits must be non-empty.
(concrete_binding::concrete_binding): Assert that bit range is
non-empty.

gcc/testsuite/ChangeLog:
PR analyzer/107882
* gcc.dg/analyzer/memcpy-pr107882.c: New test.

Signed-off-by: David Malcolm 

[Bug c++/107998] New: [13 Regression] gcc-13-20221204 failure to build on Cygwin No dirname for option: m32

[mckelvey at maskull dot com via Gcc-bugs]

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

Bug ID: 107998
   Summary: [13 Regression] gcc-13-20221204 failure to build on
Cygwin No dirname for option: m32
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: mckelvey at maskull dot com
  Target Milestone: ---

Created attachment 54031
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54031&action=edit
Build log

This worked two snapshots ago.

make[3]: Entering directory
'/home/McKelvey/gcc-13-20221204/host-x86_64-pc-cygwin/gcc'
if test yes = yes \
   || test -n "../lib ../lib32"; then \
  /bin/sh ../.././gcc/genmultilib \
"m64/m32" \
"64" \
"" \
"" \
"" \
"" \
"../lib ../lib32" \
"" \
"" \
"" \
"yes" \
> tmp-mlib.h; \
else \
  /bin/sh ../.././gcc/genmultilib '' '' '' '' '' '' '' '' \
"" '' no \
> tmp-mlib.h; \
fi
Error calling ../.././gcc/genmultilib: No dirname for option: m32
make[3]: *** [Makefile:2241: s-mlib] Error 1
make[3]: Leaving directory
'/home/McKelvey/gcc-13-20221204/host-x86_64-pc-cygwin/gcc'
make[2]: *** [Makefile:4934: all-stage1-gcc] Error 2
make[2]: Leaving directory '/home/McKelvey/gcc-13-20221204'
make[1]: *** [Makefile:23894: stage1-bubble] Error 2
make[1]: Leaving directory '/home/McKelvey/gcc-13-20221204'
make: *** [Makefile:1063: all] Error 2

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/x86_64-pc-cygwin/13.0.0/lto-wrapper.exe
Target: x86_64-pc-cygwin
Configured with: ./configure --enable-languages=c,c++ --enable-threads=posix
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.0.0 20221118 (experimental) (GCC)


$ uname
CYGWIN_NT-10.0-19044

[Bug regression/107997] New: fd8dd6c03849691 probably uncovered an issue building the Linux kernel

[jbglaw--- via Gcc-bugs]

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

Bug ID: 107997
   Summary: fd8dd6c03849691 probably uncovered an issue building
the Linux kernel
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: regression
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jbg...@lug-owl.de
  Target Milestone: ---

Hi!

Starting with commit fd8dd6c0384969170e594be34da278a072d5eb76, I see
Linux kernel build errors for the skiroot_defconfig:

[mk all 2022-12-05 19:50:10]   powerpc64-linux-gcc
-Wp,-MMD,drivers/dma-buf/.dma-fence-array.o.d -nostdinc
-I./arch/powerpc/include -I./arch/powerpc/include/generated  -I./include
-I./arch/po
werpc/include/uapi -I./arch/powerpc/include/generated/uapi -I./include/uapi
-I./include/generated/uapi -include ./include/linux/compiler-version.h -include
./include/linux/kconfig.h -include 
./include/linux/compiler_types.h -D__KERNEL__ -I ./arch/powerpc
-DHAVE_AS_ATHIGH=1 -fmacro-prefix-map=./= -Wall -Wundef
-Werror=strict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-comm
on -fshort-wchar -fno-PIE -Werror=implicit-function-declaration
-Werror=implicit-int -Werror=return-type -Wno-format-security -std=gnu11
-mlittle-endian -m64 -msoft-float -pipe -mtraceback=no
 -mabi=elfv2 -mcmodel=medium -mno-pointers-to-nested-functions -mcpu=power8
-mtune=power10 -mno-prefixed -mno-pcrel -mno-altivec -mno-vsx -mno-mma
-fno-asynchronous-unwind-tables -mno-string 
-Wa,-maltivec -Wa,-mpower4 -Wa,-many -mno-strict-align -mlittle-endian
-mstack-protector-guard=tls -mstack-protector-guard-reg=r13
-fno-delete-null-pointer-checks -Wno-frame-address -Wno-form
at-truncation -Wno-format-overflow -Wno-address-of-packed-member -Os
-fno-allow-store-data-races -Wframe-larger-than=2048 -fstack-protector-strong
-Wno-main -Wno-unused-but-set-variable -Wno-
unused-const-variable -Wno-dangling-pointer -fomit-frame-pointer
-ftrivial-auto-var-init=zero -fno-stack-clash-protection
-Wdeclaration-after-statement -Wvla -Wno-pointer-sign -Wcast-function
-type -Wno-stringop-truncation -Wno-stringop-overflow -Wno-restrict
-Wno-maybe-uninitialized -Wno-alloc-size-larger-than -Wimplicit-fallthrough=5
-fno-strict-overflow -fno-stack-check -fconse
rve-stack -Werror=date-time -Werror=incompatible-pointer-types
-Werror=designated-init -Wno-packed-not-aligned
-mstack-protector-guard-offset=2800   
-DKBUILD_MODFILE='"drivers/dma-buf/dma-fe
nce-array"' -DKBUILD_BASENAME='"dma_fence_array"'
-DKBUILD_MODNAME='"dma_fence_array"' -D__KBUILD_MODNAME=kmod_dma_fence_array -c
-o drivers/dma-buf/dma-fence-array.o drivers/dma-buf/dma-fenc
e-array.c   
[mk all 2022-12-05 19:50:10] drivers/dma-buf/dma-fence-array.c: In function
'dma_fence_array_create':   
[mk all 2022-12-05 19:50:10] drivers/dma-buf/dma-fence-array.c:154:25: error:
control flow in the middle of basic block 12
[mk all 2022-12-05 19:50:10]   154 | struct dma_fence_array
*dma_fence_array_create(int num_fences, 
[mk all 2022-12-05 19:50:10]   |
^~  
[mk all 2022-12-05 19:50:10] during GIMPLE pass: ivopts 
[mk all 2022-12-05 19:50:10] drivers/dma-buf/dma-fence-array.c:154:25: internal
compiler error: verify_flow_info failed 
[mk all 2022-12-05 19:50:10] 0x19ea876 internal_error(char const*, ...) 
[mk all 2022-12-05 19:50:10]???:0   
[mk all 2022-12-05 19:50:10] 0x94b00e verify_flow_info()
[mk all 2022-12-05 19:50:10]???:0   
[mk all 2022-12-05 19:50:10] Please submit a full bug report, with preprocessed
source (by using -freport-bug). 
[mk all 2022-12-05 19:50:10] Please include the complete backtrace with any bug
report. 
[mk all 2022-12-05 19:50:10] See  for instructions.  


(Cf. https://gcc.gnu.org/pipermail/gcc-patches/2022-December/607874.html)

I'll add the preprocessed sources.

[Bug fortran/106856] [12/13 Regression][OOP] CLASS attribute handling / ICE in gfc_conv_expr_present, at fortran/trans-expr.cc:1977 since r12-4346-geb92cd57a1ebe7cd

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

 CC||anlauf at gcc dot gnu.org

--- Comment #3 from anlauf at gcc dot gnu.org ---
Created attachment 54030
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54030&action=edit
Incremental patch

The above patch on top of Tobias' initial one fixes some minor issues with
it and improves the behavior for testcase class_75.f90 modified as follows:

! { dg-do compile }
! { dg-additional-options "-fcoarray=single" }
!
! PR fortran/106856
!
!
!
subroutine foo(x,y)
  class(*), optional :: x, y
  optional:: x! { dg-error "Duplicate OPTIONAL attribute" }
  target  :: x
  allocatable :: x
  target  :: x! { dg-error "Duplicate TARGET attribute" }
  allocatable :: x! { dg-error "Duplicate ALLOCATABLE attribute" }
  pointer :: y
  contiguous  :: y
  pointer :: y! { dg-error "Duplicate POINTER attribute" }
  contiguous  :: y! { dg-error "Duplicate CONTIGUOUS attribute" }
  dimension   :: x(:,:)
  dimension   :: y(:,:,:)
  codimension :: x[:]
! < duplicat error for dimension/codimension: TODO add decl.

  ! Currently gives an ICE :-(
end


Note that these patches "regress" as follows:

- gfortran.dg/interface_41.f90 - this had a bogus error on valid code!
  (Removing the dg-error fixes it.)

- gfortran.dg/pr69398.f90 - this ICEs due to the duplicate DIMENSION attribute

I tried to modify restore_old_symbol() to handle CLASS arrays, but then
we ICE along a different path.  Not sure if this is the right approach.

Nevertheless, the patch as is already appears to be a great step forward!

[Bug libstdc++/107871] _Iter_sink:: _M_overflow missing some difference type casting

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
Oh yes, I wonder why I bothered handling it there :-)

It should be fixed now, thanks for the report.

[Bug libstdc++/107979] [13 regression] r13-4391-g0ded30b361d2b1 causes excess errors in 17_intro/names.cc on big endian

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

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

Jonathan Wakely  changed:

   What|Removed |Added

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

--- Comment #7 from Jonathan Wakely  ---
This should be fixed now, I hope. Please reopen if not.

[Bug libstdc++/107979] [13 regression] r13-4391-g0ded30b361d2b1 causes excess errors in 17_intro/names.cc on big endian

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

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

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

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

commit r13-4528-g2a23b93f944fa78d4284eb5687051c224e5ab08f
Author: Jonathan Wakely 
Date:   Mon Dec 5 21:44:26 2022 +

libstdc++: Fix test that fails due to name clash with old glibc [PR107979]

This test was recently modified to check that the library doesn't use
__unused anywhere, because that's a macro in newlib. But it's also a
macro in old versions of glibc, so the test now fails for those targets.
Disable that check for those targets as well as for newlib.

libstdc++-v3/ChangeLog:

PR libstdc++/107979
* testsuite/17_intro/names.cc: Do not check __unused on old
Glibc versions.

[Bug libstdc++/107871] _Iter_sink:: _M_overflow missing some difference type casting

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

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

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

https://gcc.gnu.org/g:9cce91a63dcc40cb39e68f6a771e891e51c51946

commit r13-4527-g9cce91a63dcc40cb39e68f6a771e891e51c51946
Author: Jonathan Wakely 
Date:   Mon Dec 5 21:38:53 2022 +

libstdc++: Add casts for integer-like difference type [PR107871]

libstdc++-v3/ChangeLog:

PR libstdc++/107871
* include/std/format (_Iter_sink::_M_overflow): Add cast to
size_t.
(_Iter_sink::_M_make_span): Use
typedef instead of decltype.
* testsuite/std/format/functions/107871.cc: New test.

[Bug c++/106434] [12/13 Regression] Spurious -Wnull-dereference when using std::unique_copy() since r12-5187-g1ae8edf5f73ca5c3

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

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

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

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

commit r13-4525-g4ba94abf147fe7778a7541849ce27cafee74df9b
Author: Jonathan Wakely 
Date:   Mon Dec 5 12:53:42 2022 +

libstdc++: Add hint to compiler about vector invariants [PR106434]

The PR shows a bogus warning where jump threading generates code for the
undefined case that the insertion point is a value-initialized iterator
but _M_finish and _M_end_of_storage are unequal (so at least one must be
non-null). Using __builtin_unreachable() removes the bogus warning. Also
add an assertion to diagnose undefined misuses of a null iterator here,
so we don't just silently optimize that undefined code to something
unsafe.

libstdc++-v3/ChangeLog:

PR c++/106434
* include/bits/vector.tcc (insert(const_iterator, const T&)):
Add assertion and optimization hint that the iterator for the
insertion point must be non-null.

[Bug analyzer/107882] [13 Regression] ICE in get_last_bit_offset, at analyzer/store.h:255 since 13-2582-g0ea5e3f4542832b8

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

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

David Malcolm  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED

--- Comment #3 from David Malcolm  ---
I'm working on an alternate fix for this, which rejects creating bindings and
binding keys for empty bit ranges, as they're meaningless.  Testing it now.

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

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

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

--- Comment #9 from Jakub Jelinek  ---
Created attachment 54029
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54029&action=edit
gcc13-pr107967.patch

Untested fix.  Deferring the mode_composite stuff for later.

[Bug c/107994] [12/13 Regression] ICE in fold_convert_loc, at fold-const.cc:2606

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

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

--- Comment #2 from Andrew Pinski  ---
This should fix the issue (have not tested it yet):
diff --git a/gcc/gimplify.cc b/gcc/gimplify.cc
index 02415cb1b5c..ae13f9fd9e6 100644
--- a/gcc/gimplify.cc
+++ b/gcc/gimplify.cc
@@ -17098,6 +17098,9 @@ gimplify_expr (tree *expr_p, gimple_seq *pre_p,
gimple_seq *post_p,
 memcmp for them would be very inefficient at best, and is
 plain wrong if bitfields are involved.  */
{
+ if (error_operand_p (TREE_OPERAND (*expr_p, 1))
+   return GS_ERROR;
+
  tree type = TREE_TYPE (TREE_OPERAND (*expr_p, 1));

  /* Vector comparisons need no boolification.  */

[Bug analyzer/106325] -Wanalyzer-null-dereference false positive due to analyzer not making assumptions for `__attribute__((nonnull))`

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

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

--- Comment #8 from David Malcolm  ---
Should be fixed on trunk for GCC 13 by the above patch.

Still affects GCC 12, GCC 11, and GCC 10.

[Bug c/107993] ICE: tree check: expected string_cst, have integer_cst in get_target_clone_attr_len, at tree.cc:14872

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   See Also||https://gcc.gnu.org/bugzill
   ||a/show_bug.cgi?id=100504
   Last reconfirmed||2022-12-06

--- Comment #1 from Andrew Pinski  ---
So the fix for PR 100504 only checks the first arg and missed the rest ...

Confirmed.

[Bug fortran/107441] optional arguments are identified as "present" when missing

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

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

anlauf at gcc dot gnu.org changed:

   What|Removed |Added

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

--- Comment #12 from anlauf at gcc dot gnu.org ---
Fixed on mainline for gcc-13.  Closing.

Thanks for the report!

[Bug analyzer/106325] -Wanalyzer-null-dereference false positive due to analyzer not making assumptions for `__attribute__((nonnull))`

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

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

--- Comment #7 from CVS Commits  ---
The master branch has been updated by David Malcolm :

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

commit r13-4520-gdcfc7ac94dbcf6c86c0c58ce6dc1d8bd853e4093
Author: David Malcolm 
Date:   Tue Dec 6 13:26:57 2022 -0500

analyzer: use __attribute__((nonnull)) at top level of analysis [PR106325]

PR analyzer/106325 reports false postives from
-Wanalyzer-null-dereference on code like this:

__attribute__((nonnull))
void foo_a (Foo *p)
{
  foo_b (p);

  switch (p->type)
{
  /* ... */
}
}

where foo_b (p) has a:

  g_return_if_fail (p);

that expands to:

  if (!p)
{
  return;
}

The analyzer "sees" the comparison against NULL in foo_b, and splits the
analysis into the NULL and not-NULL cases; later, back in foo_a,  at
  switch (p->type)
it complains that p is NULL.

Previously we were only using __attribute__((nonnull)) as something to
complain about when it was violated; we weren't using it as a source of
knowledge.

This patch fixes things by making the analyzer respect
__attribute__((nonnull)) at the top-level of the analysis: any such
params are now assumed to be non-NULL, so that the analyzer assumes the
g_return_if_fail inside foo_b doesn't fail when called from foo_a

Doing so fixes the false positives.

gcc/analyzer/ChangeLog:
PR analyzer/106325
* region-model-manager.cc
(region_model_manager::get_or_create_null_ptr): New.
* region-model-manager.h
(region_model_manager::get_or_create_null_ptr): New decl.
* region-model.cc (region_model::on_top_level_param): Add
"nonnull" param and make use of it.
(region_model::push_frame): When handling a top-level entrypoint
to the analysis, determine which params __attribute__((nonnull))
applies to, and pass to on_top_level_param.
* region-model.h (region_model::on_top_level_param): Add "nonnull"
param.

gcc/testsuite/ChangeLog:
PR analyzer/106325
* gcc.dg/analyzer/attr-nonnull-pr106325.c: New test.
* gcc.dg/analyzer/attribute-nonnull.c (test_6): New.
(test_7): New.

Signed-off-by: David Malcolm 

[Bug target/107843] error: incompatible type for argument in ___bpf_ctx_cast2

[david.faust at oracle dot com via Gcc-bugs]

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

--- Comment #1 from David Faust  ---
Looks like this is an issue with passing void* where an enum type is
expected in a function call. This is not specific to the BPF backend.

Not entirely clear to me whether this is expected or a bug, but it
does differ from llvm behavior.

Reproducer below, tried with a few gccs, same behavior:
today (6 Dec 2022)'s master 81476bc4f4a20bcf3af7ac2548c2322d48499402
gcc-12 (Debian 12.2.0-9) 12.2.0
gcc-10 (Debian 10.4.0-5) 10.4.0
gcc-8 (Debian 8.4.0-7) 8.4.0

$ cat enumcast.c
enum E {
  E_FOO = 0,
  E_BAR = 1,
};

int foo_enum (enum E e);

int bar_enum (enum E e) {
  return foo_enum ((void *) e);
}

int foo_int (int x);

int bar_int (int x) {
  return foo_int ((void *) x);
}


$ gcc -c enumcast.c -o enumcast.o
enumcast.c: In function ‘bar_enum’:
enumcast.c:10:20: error: incompatible type for argument 1 of ‘foo_enum’
   10 |   return foo_enum ((void *) e);
  |^~
  ||
  |void *
enumcast.c:7:22: note: expected ‘enum E’ but argument is of type ‘void *’
7 | int foo_enum (enum E e);
  |   ~~~^
enumcast.c: In function ‘bar_int’:
enumcast.c:16:19: warning: cast to pointer from integer of different size
[-Wint-to-pointer-cast]
   16 |   return foo_int ((void *) x);
  |   ^
enumcast.c:16:19: warning: passing argument 1 of ‘foo_int’ makes integer from
pointer without a cast [-Wint-conversion]
   16 |   return foo_int ((void *) x);
  |   ^~
  |   |
  |   void *
enumcast.c:13:18: note: expected ‘int’ but argument is of type ‘void *’
   13 | int foo_int (int x);
  |  ^


$ clang -c enumcast.c -o enumcast.o
enumcast.c:10:20: warning: incompatible pointer to integer conversion passing
'void *' to parameter of type 'enum E' [-Wint-conversion]
  return foo_enum ((void *) e);
   ^~
enumcast.c:7:22: note: passing argument to parameter 'e' here
int foo_enum (enum E e);
 ^
enumcast.c:16:19: warning: cast to 'void *' from smaller integer type 'int'
[-Wint-to-void-pointer-cast]
  return foo_int ((void *) x);
  ^~
enumcast.c:16:19: warning: incompatible pointer to integer conversion passing
'void *' to parameter of type 'int' [-Wint-conversion]
  return foo_int ((void *) x);
  ^~
enumcast.c:13:18: note: passing argument to parameter 'x' here
int foo_int (int x);
 ^
3 warnings generated.

[Bug c/107994] [12/13 Regression] ICE in fold_convert_loc, at fold-const.cc:2606

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-12-06
 Ever confirmed|0   |1
   Assignee|unassigned at gcc dot gnu.org  |pinskia at gcc dot 
gnu.org
   Keywords||error-recovery
   Target Milestone|--- |12.3
 Status|UNCONFIRMED |ASSIGNED

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

[Bug fortran/107996] ICE in gfc_walk_array_ref, at fortran/trans-array.cc:11429

[gscfq--- via Gcc-bugs]

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

G. Steinmetz  changed:

   What|Removed |Added

   Keywords||ice-on-invalid-code,
   ||rejects-valid

--- Comment #1 from G. Steinmetz  ---

Moreover, this valid code should print 'a' :


$ cat z2.f90
program p
   associate (a => [1])
  print *, [character(size(a(:))) :: 'a']
   end associate
end

$ cat z3.f90
program p
   associate (a => [1])
  print *, [character(size(a)) :: 'a']
   end associate
end


$ gfortran-13-20221204 -c z3.f90
z3.f90:3:42:

3 |   print *, [character(size(a)) :: 'a']
  |  ^
Error: size of variable 'A.1' is too large

[Bug fortran/107996] New: ICE in gfc_walk_array_ref, at fortran/trans-array.cc:11429

[gscfq--- via Gcc-bugs]

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

Bug ID: 107996
   Summary: ICE in gfc_walk_array_ref, at
fortran/trans-array.cc:11429
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.f90
program p
   associate (a => 1)
  print *, [character(size(a(:))) :: 'a']
   end associate
end


$ gfortran-13-20221204 -c z1.f90
z1.f90:3:45:

3 |   print *, [character(size(a(:))) :: 'a']
  | 1
internal compiler error: in gfc_walk_array_ref, at fortran/trans-array.cc:11429
0x8dfa84 gfc_walk_array_ref(gfc_ss*, gfc_expr*, gfc_ref*)
../../gcc/fortran/trans-array.cc:11429
0x8eba60 gfc_walk_expr(gfc_expr*)
../../gcc/fortran/trans-array.cc:11791
0x910cf3 gfc_conv_procedure_call(gfc_se*, gfc_symbol*, gfc_actual_arglist*,
gfc_expr*, vec*)
../../gcc/fortran/trans-expr.cc:6325
0x917a9a gfc_conv_expr(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.cc:9461
0x91aba3 gfc_conv_expr_val(gfc_se*, gfc_expr*)
../../gcc/fortran/trans-expr.cc:9514
0x91bc00 gfc_conv_expr_type(gfc_se*, gfc_expr*, tree_node*)
../../gcc/fortran/trans-expr.cc:9528
0x8e1ec2 trans_array_constructor
../../gcc/fortran/trans-array.cc:2783
0x8e1ec2 gfc_add_loop_ss_code
../../gcc/fortran/trans-array.cc:3181
0x8e2225 gfc_conv_loop_setup(gfc_loopinfo*, locus*)
../../gcc/fortran/trans-array.cc:5478
0x950df5 gfc_trans_transfer(gfc_code*)
../../gcc/fortran/trans-io.cc:2671
0x8cedc7 trans_code
../../gcc/fortran/trans.cc:2170
0x94e542 build_dt
../../gcc/fortran/trans-io.cc:2051
0x8cede7 trans_code
../../gcc/fortran/trans.cc:2142
0x97980f gfc_trans_block_construct(gfc_code*)
../../gcc/fortran/trans-stmt.cc:2315
0x8ceee7 trans_code
../../gcc/fortran/trans.cc:2046
0x905e19 gfc_generate_function_code(gfc_namespace*)
../../gcc/fortran/trans-decl.cc:7674
0x87817e translate_all_program_units
../../gcc/fortran/parse.cc:6721
0x87817e gfc_parse_file()
../../gcc/fortran/parse.cc:7027
0x8c653f gfc_be_parse_file
../../gcc/fortran/f95-lang.cc:229

[Bug fortran/107995] New: ICE: Segmentation fault, without backtrace

[gscfq--- via Gcc-bugs]

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

Bug ID: 107995
   Summary: ICE: Segmentation fault, without backtrace
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Affects versions down to at least r5 :


$ cat z1.f90
program p
   implicit none
   integer :: n
   n(n) = 1
   print *, n(n)
end

$ cat z2.f90
program p
   n(n) = 1
   print *, n(n)
end


$ gfortran-13-20221204 -c z1.f90
z1.f90:3:15:

3 |integer :: n
  |   1
Error: Self-referential argument 'n' at (1) is not allowed
z1.f90:5:14:

5 |print *, n(n)
  |  1
Error: Statement function 'n' at (1) is not allowed as an actual argument
gfortran: internal compiler error: Segmentation fault signal terminated program
f951
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
See  for instructions.

[Bug c/107994] New: [12/13 Regression] ICE in fold_convert_loc, at fold-const.cc:2606

[gscfq--- via Gcc-bugs]

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

Bug ID: 107994
   Summary: [12/13 Regression] ICE in fold_convert_loc, at
fold-const.cc:2606
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Changed between 20210822 and 20210905 :


$ cat z1.c
typedef V __attribute__ ((__vector_size__ (32)));
int g;
void foo (V v)
{
  g == v;
  int v;
}


$ cat z2.c
typedef V __attribute__ ((__vector_size__ (32)));
int g;
V foo (V v)
{
  g == v;
  int v;
}


$ gcc-13-20221204 -c z1.c
z1.c:1:9: warning: type defaults to 'int' in declaration of 'V'
[-Wimplicit-int]
1 | typedef V __attribute__ ((__vector_size__ (32)));
  | ^
z1.c: In function 'foo':
z1.c:6:7: error: 'v' redeclared as different kind of symbol
6 |   int v;
  |   ^
z1.c:3:13: note: previous definition of 'v' with type 'V' {aka '__vector(8)
int'}
3 | void foo (V v)
  |   ~~^
z1.c:5:5: internal compiler error: in fold_convert_loc, at fold-const.cc:2606
5 |   g == v;
  |   ~~^~~~
0xafb891 fold_convert_loc(unsigned int, tree_node*, tree_node*)
../../gcc/fold-const.cc:2606
0xb9ebd7 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:17113
0xb9dca2 gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:17153
0xba1ff8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7219
0xb9d41b gimplify_statement_list
../../gcc/gimplify.cc:2019
0xb9d41b gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16805
0xba1ff8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7219
0xba2912 gimplify_bind_expr
../../gcc/gimplify.cc:1430
0xb9d92a gimplify_expr(tree_node**, gimple**, gimple**, bool (*)(tree_node*),
int)
../../gcc/gimplify.cc:16561
0xba1ff8 gimplify_stmt(tree_node**, gimple**)
../../gcc/gimplify.cc:7219
0xba399e gimplify_body(tree_node*, bool)
../../gcc/gimplify.cc:17620
0xba3f95 gimplify_function_tree(tree_node*)
../../gcc/gimplify.cc:17819
0x9bdab7 cgraph_node::analyze()
../../gcc/cgraphunit.cc:676
0x9c0de6 analyze_functions
../../gcc/cgraphunit.cc:1240
0x9c1f5d symbol_table::finalize_compilation_unit()
../../gcc/cgraphunit.cc:2514

[Bug tree-optimization/104475] [12/13 Regression] Wstringop-overflow + atomics incorrect warning on dynamic object

[thiago at kde dot org via Gcc-bugs]

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

--- Comment #19 from Thiago Macieira  ---
(In reply to Richard Biener from comment #15)
> Thanks, it's still the same reason - we isolate a nullptr case and end up
> with
> 
> __atomic_or_fetch_4 (184B, 64, 0); [tail call]
> 
> The path we isolate is d->m_mutex == nullptr && !enable in
> 
> void QFutureInterfaceBase::setThrottled(bool enable)
> {
> QMutexLocker lock(&d->m_mutex);

Thank you for the analysis, Richard. But do note that it's &d->m_mutex, not
d->m_mutex that is passed to the locker. C++ says that if you do d-> then d !=
nullptr, so &d->m_mutex can't be nullptr either.

However, I guess GCC thinks it can be because the offset of m_mutex in QFIBP is
zero. pahole says:

public:
void QFutureInterfaceBasePrivate(class QFutureInterfaceBasePrivate *,
enum State);
void ~QFutureInterfaceBasePrivate(class QFutureInterfaceBasePrivate *,
int);

class QMutex  m_mutex;   /* 0 8 */
class QBasicMutex continuationMutex; /* 8 8 */

So there's a missed optimisation here. But it doesn't look like GCC is the only
one to miss it, see https://gcc.godbolt.org/z/WW5hbW6sW. Maybe it's an
intentional choice?

> we predict the path to be unlikely but the adjustment to the threader
> covered probably never executed paths (with probability zero).  The
> threading opportunity arises because the DTOR calls
> 
> inline void unlock() noexcept
> {   
> if (!isLocked)
> return;
> m->unlock();
> isLocked = false;
> }
> 
> and we know isLocked on the nullptr path.

We know it can't be true.

> I thought we could maybe enhance prediction to look for nullptr based
> accesses but at the time we estimate probabilities the QMutexLocker
> CTOR isn't yet inlined (the DTOR is partially inlined, exposing the
> isLocked check).
> 
> Note the "impossible" path is actually in the sources - so there might
> be a missing conditional somewhere.

I don't see it, but that's probably because I'm looking at it from the C++
side. If the mutex pointer that was passed is null, then isLocked is never set
to true. What you're saying is that the unlock() function above was inlined and
that GCC knew m to be nullptr, but didn't know isLocked's value... which makes
no sense to me. If the constructor wasn't inlined, it couldn't know the value
of m either. If the constructor was inlined, then it should know the value of
both.

Anyway, this discussion made me realise there's a series of changes to
QMutexLocker ending in "QMutexLocker: strenghten the locking operations"
(https://code.qt.io/cgit/qt/qtbase.git/commit/?id=1b1456975347b044c11169458b53c9f6083dbc59).
This probably did change how the optimiser works, explaining why the warnings
went away.

But it shouldn't have. We went from

inline ~QMutexLocker() {
unlock();
}
inline void unlock() noexcept
{
if (!isLocked)
return;
m->unlock();
isLocked = false;
}

to

inline ~QMutexLocker()
{
if (m_isLocked)
unlock();
}
inline void unlock() noexcept
{
Q_ASSERT(m_isLocked);
m_mutex->unlock();
m_isLocked = false;
}

with the Q_ASSERT expanding to nothing in release builds, it should be
effectively identical code.

[Bug c/107993] New: ICE: tree check: expected string_cst, have integer_cst in get_target_clone_attr_len, at tree.cc:14872

[gscfq--- via Gcc-bugs]

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

Bug ID: 107993
   Summary: ICE: tree check: expected string_cst, have integer_cst
in get_target_clone_attr_len, at tree.cc:14872
   Product: gcc
   Version: 13.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: gs...@t-online.de
  Target Milestone: ---

Started with r6 :
(gcc configured with --enable-checking=yes)


$ cat z1.c
typedef union {} u;
__attribute__((target_clones("arch=alderlake",!"default")))
int f (u *x) {}


$ gcc-13-20221204 -c z1.c
z1.c:3:1: internal compiler error: tree check: expected string_cst, have
integer_cst in get_target_clone_attr_len, at tree.cc:14872
3 | int f (u *x) {}
  | ^~~
0x6b3c56 tree_check_failed(tree_node const*, char const*, int, char const*,
...)
../../gcc/tree.cc:8822
0x121b83e tree_check(tree_node*, char const*, int, char const*, tree_code)
../../gcc/tree.h:3528
0x121b83e get_target_clone_attr_len(tree_node*)
../../gcc/tree.cc:14872
0x8fbf87 handle_target_clones_attribute
../../gcc/c-family/c-attribs.cc:5594
0x7b4a87 decl_attributes(tree_node**, tree_node*, int, tree_node*)
../../gcc/attribs.cc:878
0x7db93d start_function(c_declspecs*, c_declarator*, tree_node*)
../../gcc/c/c-decl.cc:10089
0x852e8e c_parser_declaration_or_fndef
../../gcc/c/c-parser.cc:2751
0x85e30f c_parser_external_declaration
../../gcc/c/c-parser.cc:1925
0x85ec4d c_parser_translation_unit
../../gcc/c/c-parser.cc:1779
0x85ec4d c_parse_file()
../../gcc/c/c-parser.cc:24596
0x8d85e1 c_common_parse_file()
../../gcc/c-family/c-opts.cc:1248

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

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

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

--- Comment #8 from Jakub Jelinek  ---
Actually, looking at:
288   // Be extra careful if there may be discrepancies between the
289   // compile and runtime results.
290   if ((mode_composite || (real_isneg (&inf) ? real_less (&result,
&value)
291   : !real_less (&value, &result)))
292   && (inexact || !real_identical (&result, &value)))
I wonder if we didn't get it exactly wrong.
value is what is computed by real_arithmetic and result is that rounded to the
desired TYPE_MODE.
So, for non-mode_composite, if inf is negative, we want to find a low boundary.
Now, the value -> result conversion can round downward or upward or result can
be identical to value.
If real_less (&result, &value), it rounded it downward, if real_less (&value,
&result),
it rounded it upwards.
If we want low boundary and it was already rounded downward, we don't need to
round further.  So, I think we want
- if ((mode_composite || (real_isneg (&inf) ? real_less (&result,
&value)
+ if ((mode_composite || (real_isneg (&inf) ? !real_less (&result,
&value)
  : !real_less (&value, &result)))
  && (inexact || !real_identical (&result, &value)))
which fixes the thinko/inconsistency.  Say on:
double
foo (void)
{
  const double huge = 1.0e+300;
  return huge * huge;
}

double
bar (void)
{
  const double huge = 1.0e+300;
  return huge * -huge;
}
current trunk optimizes foo to return Inf; but doesn't optimize bar to return
-Inf.

Now, at least for -fno-trapping-math -fno-rounding-math, I'd say we actually
want
return Inf; and return -Inf;, for -ftrapping-math per PR107608 resolution
compute
[Inf, Inf] or [-Inf, -Inf] ranges and only for -frounding-math use [DBL_MAX,
Inf]
and [-Inf, -DBL_MAX] ranges.
For that I guess we might want to special case
real_isinf (&result) && !real_isinf (&value) && !flag_rounding_math
cases or even just a subset of those when in round to even mode the computation
would
always round to infinity by far.

And another thing is mode_composite, if frange_nextafter is the right thing to
do
from infinity.  But I think (but can't find now where we say it) that double
double
is only supported in round to nearest mode, at least:
#include 
#include 

void
foo ()
{
  volatile double huge = 1.0e+308;
  volatile double inf = __builtin_inf ();
  fesetround (FE_DOWNWARD);
  volatile double r1 = huge + huge;
  volatile double r2 = huge * huge;
  volatile double r3 = huge + inf;
  volatile double r4 = r2 + huge;
  volatile double r5 = inf - 1.0;
  volatile double r6 = inf - huge;
  fesetround (FE_TONEAREST);
  printf ("%e %e %e %e %e %e\n", r1, r2, r3, r4, r5, r6);
}

void
bar ()
{
  volatile long double huge = 1.0e+308L;
  volatile long double inf = __builtin_infl ();
  fesetround (FE_DOWNWARD);
  volatile long double r1 = huge + huge;
  volatile long double r2 = huge * huge;
  volatile long double r3 = huge + inf;
  volatile long double r4 = r2 + huge;
  volatile long double r5 = inf - 1.0;
  volatile long double r6 = inf - huge;
  fesetround (FE_TONEAREST);
  printf ("%Le %Le %Le %Le %Le %Le\n", r1, r2, r3, r4, r5, r6);
}

int
main ()
{
  foo ();
  bar ();
  return 0;
}
goes wild on ppc64 and prints
1.797693e+308 1.797693e+308 inf 1.797693e+308 inf inf
1.797693e+308 -inf inf -inf inf inf
The -inf is quite far from +inf or LDBL_MAX.
Anyway, what I found is in libgcc/config/rs6000/ibm-ldouble-format is:
"Addition and subtraction are performed using library routines.  They
are not at present performed perfectly accurately, the result produced
will be within 1ulp of the range generated by adding or subtracting
1ulp from the input values, where a 'ulp' is 2^(e-106) given the
exponent 'e'.  In the presence of cancellation, this may be
arbitrarily inaccurate.  Subtraction is done by negation and addition.

Multiplication is also performed using a library routine.  Its result
will be within 2ulp of the correct result.

Division is also performed using a library routine.  Its result will
be within 3ulp of the correct result."
so for frange_arithmetics mode_composite we probably need to account for that
extra ulp on +-, 2ulps for * and 3ulps for /.

[Bug tree-optimization/107985] [13 Regression] ICE in as_a, at value-range.h:393

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

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

--- Comment #5 from Aldy Hernandez  ---
(In reply to Andrew Macleod from comment #4)
> the gimple_range_op_handler constructor should check the operands for
> supported types as well before setting m_valid.
> 
> There is also a ripple effect in gimple_ranger::prefill_stmt_dependencies
> where the assumption is that a supported LHS must ave a handler.

Heh heh. I saw the ripple effect when I tried a quick fix, hence why I left it
alone and went back to my vacation.

Thanks for taking care of this.

[Bug middle-end/107991] [10/11/12/13 Regression] Extra mov instructions with ternary on x86

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||8.1.0
  Component|rtl-optimization|middle-end

--- Comment #2 from Andrew Pinski  ---
The huge difference comes from the middle-end:
Trunk (and not working):
(insn 12 11 13 4 (parallel [
(set (reg/v:SI 85 [ i ])
(minus:SI (reg/v:SI 85 [ i ])
(reg/v:SI 86 [ j ])))
(clobber (reg:CC 17 flags))
]) "/app/example.cpp":2:14 discrim 1 -1
 (nil))

vs 7.5 (working case):
(insn 13 12 22 4 (parallel [
(set (reg:SI 87 [  ])
(minus:SI (reg/v:SI 90 [ i ])
(reg/v:SI 91 [ j ])))
(clobber (reg:CC 17 flags))
]) "/app/example.cpp":2 -1
 (nil))

that is coalescing the PHI node:
  # iftmp.0_1 = PHI 

to i rather than inserting a setting on the other branch.

[Bug target/107988] [13 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) on aarch64-unknown-linux-gnu

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

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

Richard Biener  changed:

   What|Removed |Added

   Target Milestone|--- |13.0

[Bug rtl-optimization/107991] [10/11/12/13 Regression] Extra mov instructions with ternary on x86

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

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

Richard Biener  changed:

   What|Removed |Added

 Ever confirmed|0   |1
Version|unknown |12.2.0
   Keywords||missed-optimization,
   ||needs-bisection, ra
 Status|UNCONFIRMED |NEW
 Target||x86_64-*-*
Summary|Extra mov instructions with |[10/11/12/13 Regression]
   |ternary on x86  |Extra mov instructions with
   ||ternary on x86
  Known to work||7.5.0
   Last reconfirmed||2022-12-06
   Target Milestone|--- |10.5

--- Comment #1 from Richard Biener  ---
Confirmed.  Argument setup related I guess.

[Bug c/107980] va_start does not warn about an arbitrary number of arguments in C2x mode

[aaron at aaronballman dot com via Gcc-bugs]

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

--- Comment #11 from Aaron Ballman  ---
(In reply to Jakub Jelinek from comment #10)
> That again is completely valid in C2X.

Yes, it is. And again, it's still something worth diagnosing (IMO) because it's
utter nonsense code that is invalid with C17 and earlier as well as C++.

I don't believe WG14 intended to make this invalid code valid for C2x.

[Bug tree-optimization/107967] [13 regression] The gcc commit r13-3923 caused the glibc make check fails.

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

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

--- Comment #7 from Jakub Jelinek  ---
Ok, I can reproduce this, disabling all the +-*/ handlers fixes it.
It isn libm.so.6 that matters for the failures, not the tests themselves.
So far I've looked at the expm1 stuff, the failures are:
Failure: expm1 (0x1.86ap+16): Exception "Overflow" not set
Failure: expm1 (0x2.c5c4p+12): Exception "Overflow" not set
Failure: expm1 (0xf.8p+1020): Exception "Overflow" not set
Failure: expm1 (0xf.fp+124): Exception "Overflow" not set
Failure: expm1_downward (0x1.86ap+16): Exception "Overflow" not set
Failure: Test: expm1_downward (0x1.86ap+16)
Result:
 is:  inf   inf
 should be:   1.7976931348623157e+308   0x1.fp+1023
Failure: expm1_downward (0x2.c5c4p+12): Exception "Overflow" not set
Failure: Test: expm1_downward (0x2.c5c4p+12)
Result:
 is:  inf   inf
 should be:   1.7976931348623157e+308   0x1.fp+1023
...
Failure: expm1_upward (0x1.86ap+16): Exception "Overflow" not set
Failure: expm1_upward (0x2.c5c4p+12): Exception "Overflow" not set
Failure: expm1_upward (0xf.8p+1020): Exception "Overflow" not set
Failure: expm1_upward (0xf.fp+124): Exception "Overflow" not set

For all the arguments >= 710.0 or so (non-inf/nan), the path in the source is:
static const double
  huge = 1.0e+300,
  tiny = 1.0e-300,
  o_threshold = 7.09782712893383973096e+02;  /* 0x40862E42, 0xFEFA39EF */
...
  if (x > o_threshold)
{
  __set_errno (ERANGE);
  return huge * huge;   /* overflow */
}
and the file is compiled with -frounding-math.
So the reduced testcase for at least part of this PR is:
double
foo (void)
{
  const double huge = 1.0e+300;
  return huge * huge;
}
GCC 12 would compile this into return __builtin_inf (); only with
-fno-trapping-math,
not without it nor with -frounding-math.
Now, GCC trunk compiles this into return __builtin_inf (); with all of
-fno-trapping-math, default or -frounding-math.  For the default case, the
problem is the same as in 
PR107608.  But with -frounding-math, we have an extra problem with the value,
which
actually shouldn't be +INF but DBL_MAX.
E.g.
#include 
#include 

int
main ()
{
  volatile double huge = 1.0e+308;
  volatile double inf = __builtin_inf ();
  fesetround (FE_DOWNWARD);
  volatile double r1 = huge + huge;
  volatile double r2 = huge * huge;
  volatile double r3 = huge + inf;
  volatile double r4 = r2 + huge;
  volatile double r5 = inf - 1.0;
  volatile double r6 = inf - huge;
  fesetround (FE_TONEAREST);
  printf ("%e %e %e %e %e %e\n", r1, r2, r3, r4, r5, r6);
}
prints 1.797693e+308 1.797693e+308 inf 1.797693e+308 inf inf, so the behavior
seems to be if either operand is already inf, then the result should be inf
even when rounding to -inf (except special cases when it is nan), but if
neither operand is inf, when rounding downward it shouldn't be +inf but max
representable (or when rounding upward not -inf but min representable).
So I assume we should tweak frange_arithmetics for this behavior when
flag_rounding_math.

[Bug c/107980] va_start does not warn about an arbitrary number of arguments in C2x mode

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

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

--- Comment #10 from Jakub Jelinek  ---
That again is completely valid in C2X.

[Bug tree-optimization/107985] [13 Regression] ICE in as_a, at value-range.h:393

[amacleod at redhat dot com via Gcc-bugs]

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

--- Comment #4 from Andrew Macleod  ---
the gimple_range_op_handler constructor should check the operands for supported
types as well before setting m_valid.

There is also a ripple effect in gimple_ranger::prefill_stmt_dependencies where
the assumption is that a supported LHS must ave a handler.

Patch in testing...

[Bug c/107980] va_start does not warn about an arbitrary number of arguments in C2x mode

[aaron at aaronballman dot com via Gcc-bugs]

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

--- Comment #9 from Aaron Ballman  ---
Btw, a similar issue in this area is that GCC no longer diagnoses when the user
passes a second argument to va_start in C2x mode and the argument is not the
parameter before the ellipsis. e.g.,
```
#include 

void diag(int a, int b, ...) {
  va_list list;
  va_start(list, a);
  va_end(list);
}
```
https://godbolt.org/z/daeYbPv6z

[Bug tree-optimization/107985] [13 Regression] ICE in as_a, at value-range.h:393

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

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

--- Comment #3 from Aldy Hernandez  ---
Another alternative would be to add an is_a/as_a handler for unsupported_type's
in value-range.h and a corresponding entry for unsupported types in
range_operator:

virtual bool fold_range (irange &r, tree type, const unsupported_range &lh,
...);

with a default definition of:

   r.set_varying (type);
   return true;

Finally, add the corresponding dispatch in range_op_handler::fold_range().

Then we could handle any unsupported range's that creep in.

Or...we could fix the range_op_handler code...

[Bug c/107980] va_start does not warn about an arbitrary number of arguments in C2x mode

[aaron at aaronballman dot com via Gcc-bugs]

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

--- Comment #8 from Aaron Ballman  ---
(Sorry, I meant __VA_ARGS__ and not __VA_OPT__; C23 on the brain!)

(In reply to Andrew Pinski from comment #6)
> Maybe add a _Static_warn builtin instead which is like _Static_assert but
> instead of an error, it is a warning.
> 
> That is:
> #define va_start(ap, ...) (_Static_warn(__builtin_va_opt_count(__VA_OPT__)
> <= 1, "More than one argument supplied to the macro va_start"),
> __builtin_va_start(ap, 0))
> 
> 
> THe only issue is that message does not get translated.

Huh, that's a really neat idea to consider! But _Static_assert is a
declaration, not an expression, so we'd have to use a statement expression
there instead of rely on the comma operator. But I could use that for both
diagnosing passing > 2 args as well as passing < 2 args (we sometimes like to
warn "this feature is incompatible with standards before " in Clang).


(In reply to Jakub Jelinek from comment #7)
> Why do you need a builtin for counting number of arguments in __VA_OPT__?
> That can be done in the preprocessor.  All one needs is 1, 2 or more
> arguments.

Yes, you can beat the preprocessor into doing this for you, but a builtin that
counts the number of arguments in __VA_ARGS__ would solve a problem users have
(https://stackoverflow.com/questions/2124339/c-preprocessor-va-args-number-of-arguments),
so I figured it was better than preprocessor games.

[Bug tree-optimization/107985] [13 Regression] ICE in as_a, at value-range.h:393

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

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

Aldy Hernandez  changed:

   What|Removed |Added

 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW
   Last reconfirmed||2022-12-06

--- Comment #2 from Aldy Hernandez  ---
The dispatch code in range_op_handler::fold_range() is ICEing because LHS is an
irange, whereas op1 is an unsupported type:

(gdb) p debug(r)
[irange] UNDEFINED
(gdb) p debug(lh)
[unsupported_range] UNDEFINED

Going up to range_of_range_op we see:

(gdb) up
#3  0x02ec054f in fold_using_range::range_of_range_op
(this=0x7fffcb7f, r=warning: RTTI symbol not found for class
'int_range<255u>'
..., handler=..., src=...) at /home/aldyh/src/gcc/gcc/gimple-range-fold.cc:565
(gdb) p debug(s)
pfd.0_1 = (sizetype) pfb_5;

(gdb) p debug_tree(lhs)
 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffe9e26000 precision:64 min  max >
visited
def_stmt pfd.0_1 = (sizetype) pfb_5;
version:1>
$7 = void
(gdb) p debug_tree(op1)
 
unit-size 
align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffe9e265e8 precision:32 min  max

pointer_to_this >
sizes-gimplified public DI
size 
unit-size 
align:64 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type
0x7fffe9fca150 basetype >
visited var 
def_stmt pfb_5 = 0;
version:5>
$8 = void

So we're trying to cast from an offset_type (unsupported) to an integer_type
(irange).  It looks like range_op_handler should have set m_valid to false for
this combination, but m_valid is set from set_op_handler() which only looks at
the LHS.

[Bug target/106719] [10/11/12/13 Regression] '-fcompare-debug' failure w/ -O2 since r10-6038-ge5e07b68187b9a

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #2 from Jakub Jelinek  ---
The problem happens during split3.
After the splitting but before find_many_sub_basic_blocks we have:
...
(jump_insn 10027 10026 10021 2 (set (pc)
(if_then_else (ne (reg:SI 2 x2 [100])
(const_int 0 [0]))
(label_ref:DI 10022)
(pc))) "pr106719.c":7:3 31 {*cbnesi1}
 (int_list:REG_BR_PROB 536868 (nil))
 -> 10022)

(note 10021 10027 10016 2 NOTE_INSN_EPILOGUE_BEG)

(insn 10016 10021 10017 2 (use (reg:DI 30 x30)) "pr106719.c":9:1 -1
 (nil))

(jump_insn 10017 10016 10018 2 (return) "pr106719.c":9:1 28 {*do_return}
 (nil)
 -> return)

(barrier 10018 10017 10012)

(note 10012 10018 10013 NOTE_INSN_DELETED)

(note 10013 10012 0 NOTE_INSN_DELETED)
at the end for -g0 (--param min-nondebug-insn-uid=1), while for -g:
(jump_insn 10027 10026 4 2 (set (pc)
(if_then_else (ne (reg:SI 2 x2 [100])
(const_int 0 [0]))
(label_ref:DI 10022)
(pc))) "pr106719.c":7:3 31 {*cbnesi1}
 (int_list:REG_BR_PROB 536868 (nil))
 -> 10022)

(debug_insn 4 10027 5 2 (debug_marker) "pr106719.c":8:3 -1
 (nil))

(debug_insn 5 4 10021 2 (var_location:DI psi (const:DI (plus:DI (symbol_ref:DI
("easi") [flags 0xc0] )
(const_int 1 [0x1] "pr106719.c":8:7 -1
 (nil))

(note 10021 5 10016 2 NOTE_INSN_EPILOGUE_BEG)

(insn 10016 10021 10017 2 (use (reg:DI 30 x30)) "pr106719.c":9:1 -1
 (nil))

(jump_insn 10017 10016 10018 2 (return) "pr106719.c":9:1 28 {*do_return}
 (nil)
 -> return)

(barrier 10018 10017 10012)

(note 10012 10018 10013 NOTE_INSN_DELETED)

(note 10013 10012 0 NOTE_INSN_DELETED)
where jump_insn 10027 is the last one from splitting of
(insn:TI 10009 10008 4 2 (parallel [
(set (mem/v:HI (reg/f:DI 0 x0 [94]) [-1  S2 A16])
(unspec_volatile:HI [
(not:HI (and:HI (mem/v:HI (reg/f:DI 0 x0 [94]) [-1  S2
A16])
(reg:HI 1 x1 [orig:98 esi ] [98])))
(const_int 0 [0])
] UNSPECV_ATOMIC_OP))
(clobber (reg:CC 66 cc))
(clobber (reg:HI 3 x3 [99]))
(clobber (reg:SI 2 x2 [100]))
]) "pr106719.c":7:3 4459 {atomic_nandhi}
 (expr_list:REG_DEAD (reg:HI 1 x1 [orig:98 esi ] [98])
(expr_list:REG_DEAD (reg/f:DI 0 x0 [94])
(expr_list:REG_UNUSED (reg:CC 66 cc)
(expr_list:REG_UNUSED (reg:HI 3 x3 [99])
(expr_list:REG_UNUSED (reg:SI 2 x2 [100])
(nil)))

So, I guess find_many_sub_basic_blocks doesn't ignore DEBUG_INSNs in decisions
where to split the basic blocks or something, because we get:
(jump_insn 10027 10026 10021 3 (set (pc)
(if_then_else (ne (reg:SI 2 x2 [100])
(const_int 0 [0]))
(label_ref:DI 10022)
(pc))) "pr106719.c":7:3 31 {*cbnesi1}
 (int_list:REG_BR_PROB 536868 (nil))
 -> 10022)

(note 10021 10027 10029 NOTE_INSN_EPILOGUE_BEG)

(note 10029 10021 10016 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
...
in the -g0 case and
(jump_insn 10027 10026 10029 3 (set (pc)
(if_then_else (ne (reg:SI 2 x2 [100])
(const_int 0 [0]))
(label_ref:DI 10022)
(pc))) "pr106719.c":7:3 31 {*cbnesi1}
 (int_list:REG_BR_PROB 536868 (nil))
 -> 10022)

(note 10029 10027 4 4 [bb 4] NOTE_INSN_BASIC_BLOCK)

(debug_insn 4 10029 5 4 (debug_marker) "pr106719.c":8:3 -1
 (nil))

(debug_insn 5 4 10021 4 (var_location:DI psi (const:DI (plus:DI (symbol_ref:DI
("easi") [flags 0xc0] )
(const_int 1 [0x1] "pr106719.c":8:7 -1
 (nil))

(note 10021 5 10016 4 NOTE_INSN_EPILOGUE_BEG)
with -g, i.e. appart from the DEBUG_INSNs NOTE_INSN_EPILOGUE_BEG and
NOTE_INSN_BASIC_BLOCK notes got swapped.

[Bug c/107980] va_start does not warn about an arbitrary number of arguments in C2x mode

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

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

--- Comment #7 from Jakub Jelinek  ---
Why do you need a builtin for counting number of arguments in __VA_OPT__?
That can be done in the preprocessor.  All one needs is 1, 2 or more arguments.

[Bug c/107980] va_start does not warn about an arbitrary number of arguments in C2x mode

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

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

--- Comment #6 from Andrew Pinski  ---
Maybe add a _Static_warn builtin instead which is like _Static_assert but
instead of an error, it is a warning.

That is:
#define va_start(ap, ...) (_Static_warn(__builtin_va_opt_count(__VA_OPT__) <=
1, "More than one argument supplied to the macro va_start"),
__builtin_va_start(ap, 0))


THe only issue is that message does not get translated.

[Bug c/107980] va_start does not warn about an arbitrary number of arguments in C2x mode

[aaron at aaronballman dot com via Gcc-bugs]

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

--- Comment #5 from Aaron Ballman  ---
(In reply to Andrew Pinski from comment #3)
> I think we should warn but how to warn is going to have to special case the
> macro I think.

I was contemplating a perhaps terrible idea of adding some new builtins:
```
unsigned __builtin_va_opt_count(...);
void __builtin_c23_va_start(va_list list, unsigned arg_count);
```
and then doing something along these lines in stdarg.h:
```
#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 202000L
#define va_start(ap, ...) __builtin_c23_va_start(ap,
__builtin_va_opt_count(__VA_OPT__))
#else
...
#endif
```
but I've not put enough thought into it yet. WDYT about something along those
lines?

(In reply to Andrew Pinski from comment #4)
> (In reply to Andrew Pinski from comment #3)
> > I think we should warn but how to warn is going to have to special case the
> > macro I think.
> 
> But saying that I do think it is valid C2X code if you take the C2X standard
> seperately from the older standards.

I'm sad I noticed this after the NB comment period closed for the US NB because
otherwise I'd leave a comment to make it a constraint violation to pass more
than two arguments to the macro (or at least a recommended practice to
diagnose). Because I agree with you that the letter of the standard makes this
valid in C2x, but given that the extra arguments are not expanded or evaluated,
there is no reason to accept more than two arguments in any C standard version.

[Bug middle-end/106323] [Suboptimal] memcmp(s1, s2, n) == 0 expansion on AArch64 compare to llvm

[zhongyunde at huawei dot com via Gcc-bugs]

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

--- Comment #4 from vfdff  ---
Now, llvm use 4 loads and CMP+CCMP, https://gcc.godbolt.org/z/PM3jxEM9M

[Bug go/107992] New: m68k-linux-gnu bootstap error in gofrontend

[bernd.edlinger at hotmail dot de via Gcc-bugs]

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

Bug ID: 107992
   Summary: m68k-linux-gnu bootstap error in gofrontend
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: bernd.edlinger at hotmail dot de
  Target Milestone: ---

Hi, I don't know if that is expected,
but I got a boot-strap error with r13-4502-ga0ee2e52252
.../configure --target=m68k-linux-gnu --prefix=... --enable-languages=all

libtool: compile:  /home/ed/gnu/gcc-build-m68k/./gcc/gccgo
-B/home/ed/gnu/gcc-build-m68k/./gcc/
-B/home/ed/gnu/m68k-linux-gnu/m68k-linux-gnu/bin/
-B/home/ed/gnu/m68k-linux-gnu/m68k-linux-gnu/lib/ -isystem
/home/ed/gnu/m68k-linux-gnu/m68k-linux-gnu/include -isystem
/home/ed/gnu/m68k-linux-gnu/m68k-linux-gnu/sys-include -O2 -g -mcpu=68040 -I .
-c -fgo-pkgpath=image/color/palette
../../../../gcc-trunk/libgo/go/image/color/palette/generate.go
../../../../gcc-trunk/libgo/go/image/color/palette/palette.go  -fPIC -o
image/color/.libs/palette.o
go1: internal compiler error: in set_from, at go/gofrontend/types.cc:2851
0x692aaf Ptrmask::set_from(Gogo*, Type*, long, long)
../../gcc-trunk/gcc/go/gofrontend/types.cc:2851
0x92f9a0 Ptrmask::set_from(Gogo*, Type*, long, long)
../../gcc-trunk/gcc/go/gofrontend/types.cc:2825
0x92f9a0 Ptrmask::set_from(Gogo*, Type*, long, long)
../../gcc-trunk/gcc/go/gofrontend/types.cc:2884
0x92fdcb Ptrmask::set_from(Gogo*, Type*, long, long)
../../gcc-trunk/gcc/go/gofrontend/types.cc:2825
0x92fdcb Type::gc_ptrmask_var(Gogo*, long, long)
../../gcc-trunk/gcc/go/gofrontend/types.cc:3030
0x930b09 Type::make_gc_symbol_var(Gogo*)
../../gcc-trunk/gcc/go/gofrontend/types.cc:2710
0x930c9a Type::gc_symbol_pointer(Gogo*)
../../gcc-trunk/gcc/go/gofrontend/types.cc:2660
0x88290a Struct_construction_expression::do_get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/expressions.cc:15689
0x88290a Struct_construction_expression::do_get_backend(Translate_context*)
../../gcc-trunk/gcc/go/gofrontend/expressions.cc:15689
0x92973c Type::make_type_descriptor_var(Gogo*)
../../gcc-trunk/gcc/go/gofrontend/types.cc:1432
0x929cad Type::type_descriptor_pointer(Gogo*, Location)
../../gcc-trunk/gcc/go/gofrontend/types.cc:1308
0x8befdd Named_object::get_backend(Gogo*, std::vector >&, std::vector >&,
std::vector >&)
../../gcc-trunk/gcc/go/gofrontend/gogo.cc:8868
0x8c80f9 Gogo::write_globals()
../../gcc-trunk/gcc/go/gofrontend/gogo.cc:1560
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.
make[8]: *** [Makefile:3043: runtime.lo] Error 1
make[8]: *** Waiting for unfinished jobs

[Bug target/107988] [13 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) on aarch64-unknown-linux-gnu

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

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

Tamar Christina  changed:

   What|Removed |Added

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

--- Comment #2 from Tamar Christina  ---
how did a mem get in there..

[Bug rtl-optimization/107991] New: Extra mov instructions with ternary on x86

[denis.campredon at gmail dot com via Gcc-bugs]

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

Bug ID: 107991
   Summary: Extra mov instructions with ternary on x86
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: denis.campredon at gmail dot com
  Target Milestone: ---

Compiled with -O2 on x86, gcc trunk produces 3 mov instructions for each of the
following functions:

int foo(bool b, int i, int j) {
return b ? i - j : i;
}

int bar(bool b, int i, int j) {
return i + (b ? -j : 0);
}

int baz(bool b, int i, int j) {
return i - (b ? j : 0);
}

-

Whearas with gcc 7.5, only 1 mov was produced for foo and bar, and two for baz

[Bug target/107987] [12/13 Regression] MVE vcmpq vector-scalar can trigger ICE

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

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

--- Comment #1 from CVS Commits  ---
The master branch has been updated by Andre Simoes Dias Vieira
:

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

commit r13-4506-ged34c3bc3428bce663d42e9eeda10bc0c5d56d5c
Author: Andre Vieira 
Date:   Tue Dec 6 12:06:33 2022 +

arm: Fix MVE's vcmp vector-scalar patterns [PR107987]

This patch surrounds the scalar operand of the MVE vcmp patterns with a
vec_duplicate to ensure both operands of the comparision operator have the
same
(vector) mode.

gcc/ChangeLog:

PR target/107987
* config/arm/mve.md (mve_vcmpq_n_,
@mve_vcmpq_n_f): Apply vec_duplicate to scalar
operand.

gcc/testsuite/ChangeLog:

* gcc.target/arm/mve/pr107987.c: New test.

[Bug tree-optimization/107975] [13 Regression] frange ICE since r13-4492

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||zsojka at seznam dot cz

--- Comment #5 from Jakub Jelinek  ---
*** Bug 107989 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/107989] [13 Regression] ICE: in lower_bound, at value-range.h:350 with -fsanitize=float-cast-overflow

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

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

Jakub Jelinek  changed:

   What|Removed |Added

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

--- Comment #3 from Jakub Jelinek  ---
Dup then.

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

[Bug target/107988] [13 Regression] ICE: in extract_insn, at recog.cc:2791 (unrecognizable insn) on aarch64-unknown-linux-gnu

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

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

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Last reconfirmed||2022-12-06
 Ever confirmed|0   |1
 CC||ktkachov at gcc dot gnu.org,
   ||tnfchris at gcc dot gnu.org
 Status|UNCONFIRMED |NEW

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Confirmed. Looks related to the recent div-by-special-constant changes but ICEs
only at -O0

[Bug tree-optimization/107989] [13 Regression] ICE: in lower_bound, at value-range.h:350 with -fsanitize=float-cast-overflow

[zsojka at seznam dot cz via Gcc-bugs]

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

--- Comment #2 from Zdenek Sojka  ---
(In reply to Jakub Jelinek from comment #1)
> Is this with r13-4501-g0525a7fad2a5b1d or later?  If not, it is a dup of
> PR107975.

Thank you for the reply. This is with r13-4497, so a dup of PR107975.

[Bug tree-optimization/107989] [13 Regression] ICE: in lower_bound, at value-range.h:350 with -fsanitize=float-cast-overflow

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek  ---
Is this with r13-4501-g0525a7fad2a5b1d or later?  If not, it is a dup of
PR107975.