[Bug tree-optimization/104269] [12 Regression] Bogus -Wuse-after-free seen in xen

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

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

--- Comment #3 from Richard Biener  ---
The easiest would be to run _before_ uncprop.  uncprop is really part of
out-of-SSA to reduce the number of copies on edges (maybe it should be merged
into it instead of being visible as separate pass).

[Bug rtl-optimization/104153] [12 Regression] ICE due to recent ifcvt changes

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

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

--- Comment #5 from rdapp at linux dot ibm.com ---
I would speculate that some of the FAILs are due to the same problem seen in
the other PR (104198), i.e. that for the second seq I wrongly assumed that the
backend does not recreate the original comparison as well as not read from
possibly overwritten regs.
Regarding the test failures - in case you don't have anything yet, I could 
build a vanilla and a patched cross compiler and look and the differences for
some of them.

[Bug rtl-optimization/104198] [12 regression] ifcvt change breaks 64-bit SPARC bootstrap

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

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

--- Comment #13 from rdapp at linux dot ibm.com ---
I was away for some days, going to look into this again today.

[Bug tree-optimization/104297] New: MIN_EXPR is not detected for a >= -__INT_MAX__ ? -__INT_MAX__ : a

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

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

Bug ID: 104297
   Summary: MIN_EXPR is not detected for a >= -__INT_MAX__  ?
-__INT_MAX__  : a
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
int t(int a)
{
int b = -__INT_MAX__ ;
int c = a >= b ? b : a;
return c;
}

int t1(int a)
{
int c = a >= -__INT_MAX__  ? -__INT_MAX__  : a;
return c;
}

--- CUT ---
t1 should be detected to MIN_EXPR ;

[Bug c++/103341] [11 Regression] ICE type of variable instantiation constrained on template parameter

[asolokha at gmx dot com via Gcc-bugs]

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

--- Comment #6 from Arseny Solokha  ---
g++ 12.0.1 20220130 snapshot (g:baf98320ac6cd56da0c0b460fb94e3b87a79220d) still
ICEs on the testcase in comment 3.

[Bug middle-end/104296] New: MIN should simplify to unsigned != 0

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

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

Bug ID: 104296
   Summary: MIN should simplify to unsigned != 0
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: enhancement
  Priority: P3
 Component: middle-end
  Assignee: unassigned at gcc dot gnu.org
  Reporter: pinskia at gcc dot gnu.org
  Target Milestone: ---

Take:
unsigned t(unsigned a)
{
unsigned b = 1;
return a >= b ? b : a;
}

unsigned t1(unsigned a)
{
return a >= 1 ? 1 : a;
}

These two functions are the same but currently they do not optimize to the same
thing.

[Bug c++/98675] Accessing member of temporary outside its lifetime allowed in constexpr function

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

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

--- Comment #4 from Andrew Pinski  ---
(In reply to Tobias Schlüter from comment #3)
> Sorry, in my example, I think actually clang is wrong.

What is the order of destruction of tempories here in the following statement:
A() << 1

Is A() destoryed before the temp B that is returned from operator <<.

Note MSVC accepts the code so it might be a bug in clang.

[Bug c++/98675] Accessing member of temporary outside its lifetime allowed in constexpr function

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

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

--- Comment #3 from Tobias Schlüter  ---
Sorry, in my example, I think actually clang is wrong.

[Bug c++/98675] Accessing member of temporary outside its lifetime allowed in constexpr function

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

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

Tobias Schlüter  changed:

   What|Removed |Added

 CC||tobi at gcc dot gnu.org

--- Comment #2 from Tobias Schlüter  ---
Here's another testcase (derived from code in the Eigen library ) that seems to
illustrate the same issue. Please follow the compiler explorer link to see a
non-constexpr version and its gimple that makes clear that there indeed is a
lifetime issue and also clang's error message https://godbolt.org/z/4zoKaoKa5

struct B;

#define CONSTEXPR constexpr
#define CONSTEVAL consteval

struct A {
public:
CONSTEXPR A() { m_val = 1; }
CONSTEXPR A(const A& other) { m_val = other.m_val;}
CONSTEXPR ~A() {};

CONSTEXPR int val() { return m_val; }

int m_val;

CONSTEXPR B operator<<(int);
};

struct B {
A& m_a;
CONSTEXPR B(A& ref) : m_a(ref) {}
CONSTEXPR B& operator,(int i) { m_a.m_val = i; return *this; }
CONSTEXPR ~B() { finished(); }
CONSTEXPR A finished() { return m_a; }
};

CONSTEXPR B A::operator<<(int i) {
m_val = i;
return B(*this);
}

CONSTEVAL int f()
{
A a = (A() << 1, 2, 3, 4).finished();
return a.val();
}

int g()
{
return f();
}

[Bug c++/104295] ICE: tree check: expected template_decl, have error_mark in build_deduction_guide, at cp/pt.cc:29079

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

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

Andrew Pinski  changed:

   What|Removed |Added

  Known to fail||11.2.0, 7.1.0
   Keywords||error-recovery
   Severity|normal  |trivial
 Ever confirmed|0   |1
   Last reconfirmed||2022-01-31
 Status|UNCONFIRMED |NEW

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

[Bug c++/104295] New: ICE: tree check: expected template_decl, have error_mark in build_deduction_guide, at cp/pt.cc:29079

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 104295
   Summary: ICE: tree check: expected template_decl, have
error_mark in build_deduction_guide, at cp/pt.cc:29079
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

template
struct B;

template 
struct B {
  template
  struct C { C(T); };
};

int main() {
  B::C{0};
}

https://godbolt.org/z/5rxvbd3oe

Maybe dup of Bug 104294, but since their error message is different I opened
this one.

[Bug c++/104294] New: ICE: tree check: accessed elt 2 of 'tree_vec' with 1 elts in tsubst_pack_expansion, at cp/pt.cc:13130

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 104294
   Summary: ICE: tree check: accessed elt 2 of 'tree_vec' with 1
elts in tsubst_pack_expansion, at cp/pt.cc:13130
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

template
struct B;

template 
struct B {
  template
  struct C { C(T); };
};

int main() {
  B::C{0};
}

https://godbolt.org/z/h1jGhc5b4

Re: [PATCH] sh-linux fix target cpu

[Oleg Endo]

On Fri, 2022-01-28 at 15:18 -0700, Jeff Law via Gcc-patches wrote:
> 
> On 1/12/2022 2:02 AM, Yoshinori Sato wrote:
> > sh-linux not supported any SH1 and SH2a little-endian.
> > Add exceptios it.
> > 
> > gcc/ChangeLog:
> > 
> > * config/sh/t-linux (MULTILIB_EXCEPTIONS): Add m1, mb/m1 and m2a.
> Thanks.  Technically this is probably too late to make gcc-12 as we're 
> in stage4 (regression fixes only).  BUt it was posted during stage3 
> (general bugfixing) and is very very low risk.
> 
> I went ahead and committed it for you.
> 
> Thanks, and sorry for the delays.


Thanks, Jeff!

Cheers,
Oleg

[PATCH] libgccjit: Add support for setting the alignment [PR104293]

[Antoni Boucher via Gcc-patches]

Hi.
This patch adds support for setting the alignment of variables in
libgccjit.

I was wondering if I should change it so that it takes/returns bytes
instead of bits.
What do you think?

Thanks for the review.
From ebdb6905f23ddef28292a1d71081eebb7a2a9bb9 Mon Sep 17 00:00:00 2001
From: Antoni Boucher 
Date: Tue, 25 Jan 2022 21:12:32 -0500
Subject: [PATCH] libgccjit: Add support for setting the alignment [PR104293]

2022-01-30  Antoni Boucher 

gcc/jit/
	PR jit/104293
	* docs/topics/compatibility.rst (LIBGCCJIT_ABI_24): New ABI tag.
	* docs/topics/expressions.rst: Add documentation for the
	functions gcc_jit_lvalue_set_alignment and
	gcc_jit_lvalue_get_alignment.
	* jit-playback.h: New function (set_alignment).
	* jit-recording.cc: New function (set_alignment).
	* jit-recording.h: New functions (set_alignment, get_alignment)
	and new field (m_alignment).
	* libgccjit.cc: New functions (gcc_jit_lvalue_get_alignment,
	gcc_jit_lvalue_set_alignment)
	* libgccjit.h: New functions (gcc_jit_lvalue_get_alignment,
	gcc_jit_lvalue_set_alignment)
	* libgccjit.map (LIBGCCJIT_ABI_24): New ABI tag.

gcc/testsuite/
	PR jit/104293
	* jit.dg/all-non-failing-tests.h: Mention
	test-setting-alignment.
	* jit.dg/test-setting-alignment.c: New test.
---
 gcc/jit/docs/topics/compatibility.rst | 10 +++
 gcc/jit/docs/topics/expressions.rst   | 39 +++
 gcc/jit/jit-playback.h|  7 ++
 gcc/jit/jit-recording.cc  | 17 -
 gcc/jit/jit-recording.h   |  6 +-
 gcc/jit/libgccjit.cc  | 25 
 gcc/jit/libgccjit.h   | 19 ++
 gcc/jit/libgccjit.map | 18 ++
 gcc/testsuite/jit.dg/all-non-failing-tests.h  |  3 +
 gcc/testsuite/jit.dg/test-setting-alignment.c | 64 +++
 10 files changed, 205 insertions(+), 3 deletions(-)
 create mode 100644 gcc/testsuite/jit.dg/test-setting-alignment.c

diff --git a/gcc/jit/docs/topics/compatibility.rst b/gcc/jit/docs/topics/compatibility.rst
index 16cebe31a10..1957399dceb 100644
--- a/gcc/jit/docs/topics/compatibility.rst
+++ b/gcc/jit/docs/topics/compatibility.rst
@@ -302,3 +302,13 @@ thread-local storage model of a variable:
 section of a variable:
 
   * :func:`gcc_jit_lvalue_set_link_section`
+
+.. _LIBGCCJIT_ABI_24:
+
+``LIBGCCJIT_ABI_24``
+---
+``LIBGCCJIT_ABI_24`` covers the addition of functions to get and set the
+alignement of a variable:
+
+  * :func:`gcc_jit_lvalue_set_alignment`
+  * :func:`gcc_jit_lvalue_get_alignment`
diff --git a/gcc/jit/docs/topics/expressions.rst b/gcc/jit/docs/topics/expressions.rst
index 791a20398ca..0f5f5376d8c 100644
--- a/gcc/jit/docs/topics/expressions.rst
+++ b/gcc/jit/docs/topics/expressions.rst
@@ -738,6 +738,45 @@ where the rvalue is computed by reading from the storage area.
 
   #ifdef LIBGCCJIT_HAVE_gcc_jit_lvalue_set_link_section
 
+.. function:: void
+  gcc_jit_lvalue_set_alignment (gcc_jit_lvalue *lvalue,
+int alignment)
+
+   Set the alignment of a variable.
+   The parameter ``alignment`` is in bits. Analogous to:
+
+   .. code-block:: c
+
+ int variable __attribute__((aligned (16)));
+
+   in C, but in bits instead of bytes.
+
+   This entrypoint was added in :ref:`LIBGCCJIT_ABI_24`; you can test for
+   its presence using
+
+   .. code-block:: c
+
+  #ifdef LIBGCCJIT_HAVE_ALIGNMENT
+
+.. function:: int
+  gcc_jit_lvalue_get_alignment (gcc_jit_lvalue *lvalue)
+
+   Return the alignment of a variable set by ``gcc_jit_lvalue_set_alignment``, in bits.
+   Return 0 if the alignment was not set. Analogous to:
+
+   .. code-block:: c
+
+ _Alignof (variable)
+
+   in C, but in bits instead of bytes.
+
+   This entrypoint was added in :ref:`LIBGCCJIT_ABI_24`; you can test for
+   its presence using
+
+   .. code-block:: c
+
+  #ifdef LIBGCCJIT_HAVE_ALIGNMENT
+
 Global variables
 
 
diff --git a/gcc/jit/jit-playback.h b/gcc/jit/jit-playback.h
index c93d7055d43..4a3c4a6a09b 100644
--- a/gcc/jit/jit-playback.h
+++ b/gcc/jit/jit-playback.h
@@ -701,6 +701,13 @@ public:
 set_decl_section_name (as_tree (), name);
   }
 
+  void
+  set_alignment (int alignment)
+  {
+  SET_DECL_ALIGN (as_tree (), alignment);
+  DECL_USER_ALIGN (as_tree ()) = 1;
+  }
+
 private:
   bool mark_addressable (location *loc);
 };
diff --git a/gcc/jit/jit-recording.cc b/gcc/jit/jit-recording.cc
index 1e3fadfacd7..7176fb34734 100644
--- a/gcc/jit/jit-recording.cc
+++ b/gcc/jit/jit-recording.cc
@@ -3807,6 +3807,11 @@ void recording::lvalue::set_link_section (const char *name)
   m_link_section = new_string (name);
 }
 
+void recording::lvalue::set_alignment (int alignment)
+{
+  m_alignment = alignment;
+}
+
 /* The implementation of class gcc::jit::recording::param.  */
 
 /* Implementation of pure virtual hook recording::memento::replay_into
@@ -4673,6 +4678,9 @@ 

[Bug sanitizer/95137] Sanitizers seem to be missing support for coroutines

[pobrn at protonmail dot com via Gcc-bugs]

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

Barnabás Pőcze  changed:

   What|Removed |Added

 CC||pobrn at protonmail dot com

--- Comment #46 from Barnabás Pőcze  ---
(In reply to stream009 from comment #42)
> I got strange compile error when I use coroutine with UBSAN.
> 
> The weird thing is error is reported in compile time not runtime.
> The code compile fine without UBSAN.
> [...]
> === begin compile error ===
> : In function 'void _Z5errori.actor(error(int)::_Z5errori.frame*)':
> :21:9: warning: '' may be used uninitialized
> [-Wmaybe-uninitialized]
>21 | co_return;
>   | ^
> :21:9: note: '' was declared here
>21 | co_return;
>   | ^
> === end compile error ===

I am not familiar with the internals of gcc at all, but it appears that this is
due to incorrect code generation. When ubsan is not used, the generated gimple
looks like this:

if (_13 == 0) goto ; else goto ;
:
_14 = _ptr->__p;
result::promise_type::return_void (_14);
goto final.suspend;
:
_15 = _ptr->__p;
result::promise_type::return_void (_15);

when ubsan is used, however:

if (_8 == 0) goto ; else goto ;
:
D.9938 = _ptr->__p;
.UBSAN_NULL (D.9938, 4B, 0);
result::promise_type::return_void (D.9938);
goto final.suspend;
:
.UBSAN_NULL (D.9938, 4B, 0);
result::promise_type::return_void (D.9938);

`D.9938` is not initialized, and I guess hence the warning.

---

I have noticed that this does not happen on
f6f2d6cfec1c2fe9570b98211be58329d8d7749b, so out of curiosity I tried to bisect
gcc:

> git bisect start
> # new: [f6f2d6cfec1c2fe9570b98211be58329d8d7749b] Daily bump.
> git bisect new f6f2d6cfec1c2fe9570b98211be58329d8d7749b
> # old: [7ca388565af176bd4efd4f8db1e5e9e11e98ef45] Update ChangeLog and 
> version files for release
> git bisect old 7ca388565af176bd4efd4f8db1e5e9e11e98ef45
> # old: [250f234988b6231669a720c52101d3686d645072] testsuite: Fix up 
> gcc.target/s390/zero-scratch-regs-1.c
> git bisect old 250f234988b6231669a720c52101d3686d645072
> # old: [79513dc0b2d980bfd1b109d0d502de487c02b894] compiler: don't pad 
> zero-sized trailing field in results struct
> git bisect old 79513dc0b2d980bfd1b109d0d502de487c02b894
> # new: [1b62cddcf091fb8cadf575246a7d3ff778650a6b] Fix ipa-modref pure/const 
> discovery
> git bisect new 1b62cddcf091fb8cadf575246a7d3ff778650a6b
> # new: [247bac507e63b32d4dc23ef1c55f300aafea24c6] libstdc++: Simplify 
> std::basic_regex::assign
> git bisect new 247bac507e63b32d4dc23ef1c55f300aafea24c6
> # new: [d5f8abe1d3f718a75cbff0a453c1d961be5939b7] Use on-demand ranges in 
> ssa_name_has_boolean_range before querying nonzero bits.
> git bisect new d5f8abe1d3f718a75cbff0a453c1d961be5939b7
> # new: [7d79c3ebc3f3f6f8aecf83726c97474ae5cfe957] Don't record string 
> concatenation data for 'RESERVED_LOCATION_P'
> git bisect new 7d79c3ebc3f3f6f8aecf83726c97474ae5cfe957
> # new: [8137be3958be4e5421c283cce3e5b50dbb80b84e] mips: Fix macro typo
> git bisect new 8137be3958be4e5421c283cce3e5b50dbb80b84e
> # old: [caef5203d64e61da506909d58890035af32a6239] Fix internal error on 
> pointer-to-pointer binding in LTO mode
> git bisect old caef5203d64e61da506909d58890035af32a6239
> # new: [cc1e28878a228b6c4a0872e56d97ac88971b7725] libstdc++: Check for TLS 
> support on mingw cross-compilers
> git bisect new cc1e28878a228b6c4a0872e56d97ac88971b7725
> # new: [70ee703c479081ac2ea67eb67041551216e66783] coroutines: Make proxy vars 
> for the function arg copies.
> git bisect new 70ee703c479081ac2ea67eb67041551216e66783
> # old: [bd55fa102715c7442c050b193dadfdb5337e2377] Fix PR ada/101970
> git bisect old bd55fa102715c7442c050b193dadfdb5337e2377
> # old: [f008fd3a480e3718436156697ebe7eeb47841457] c++: Fix 
> __is_*constructible/assignable for templates [PR102305]
> git bisect old f008fd3a480e3718436156697ebe7eeb47841457
> # old: [de07cff96abd43f6f65dcf333958899c2ec42598] c++: empty union member 
> activation during constexpr [PR102163]
> git bisect old de07cff96abd43f6f65dcf333958899c2ec42598
> # skip: [c5a735fa9df7eca4666c8da5e51ed9c5ab7cc81a] coroutines: Expose 
> implementation state to the debugger.
> git bisect skip c5a735fa9df7eca4666c8da5e51ed9c5ab7cc81a
> # only skipped commits left to test
> # possible first new commit: [70ee703c479081ac2ea67eb67041551216e66783] 
> coroutines: Make proxy vars for the function arg copies.
> # possible first new commit: [c5a735fa9df7eca4666c8da5e51ed9c5ab7cc81a] 
> coroutines: Expose implementation state to the debugger.

Unfortunately, when I got to c5a735fa9df7eca4666c8da5e51ed9c5ab7cc81a, it did
not build; I am not sure where I had gone wrong:

> g++ -std=c++11  -fno-PIE -c  

[Bug jit/104293] New: Add support for setting the alignment of variables

[bouanto at zoho dot com via Gcc-bugs]

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

Bug ID: 104293
   Summary: Add support for setting the alignment of variables
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: bouanto at zoho dot com
  Target Milestone: ---

Hi.
I'm opening this issue to track my upcoming patch adding support for setting
the alignment of variables in libgccjit.

[Bug middle-end/78947] sub-optimal code for (bool)(int ? int : int)

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Mine for GCC 13.

gcc-12-20220130 is now available

[GCC Administrator via Gcc]

Snapshot gcc-12-20220130 is now available on
  https://gcc.gnu.org/pub/gcc/snapshots/12-20220130/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 12 git branch
with the following options: git://gcc.gnu.org/git/gcc.git branch master 
revision baf98320ac6cd56da0c0b460fb94e3b87a79220d

You'll find:

 gcc-12-20220130.tar.xz   Complete GCC

  SHA256=5e63ab057bc747ca17b47fa8b15afdcaf1919d38977e94ce788b181aa4ad237f
  SHA1=4928208590010b85e665bffb3c42e9c59bdb3f5a

Diffs from 12-20220123 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-12
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

[Bug tree-optimization/104292] [missed optimization] boolean addition generates suboptimal code

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

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

Andrew Pinski  changed:

   What|Removed |Added

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

--- Comment #3 from Andrew Pinski  ---
Found it, PR 101703.

[Bug target/104189] enable 64-bit compare-and-swap on SPARC/Linux with V9

[glaubitz at physik dot fu-berlin.de via Gcc-bugs]

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

--- Comment #8 from John Paul Adrian Glaubitz  ---
Any updates on this?

[Bug c++/104291] [12 Regression] gcc accepts template argument involves template parameter(s)

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

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

Andrew Pinski  changed:

   What|Removed |Added

 Ever confirmed|0   |1
   Keywords||needs-bisection
   Target Milestone|--- |12.0
Summary|gcc accepts template|[12 Regression] gcc accepts
   |argument involves template  |template argument involves
   |parameter(s)|template parameter(s)
   Last reconfirmed||2022-01-30
 Status|UNCONFIRMED |NEW

--- Comment #1 from Andrew Pinski  ---
Confirmed, this was rejected in GCC 11.1.0 and 11.2.0.

[Bug rtl-optimization/102446] [9/10/11/12 Regression] wrong code at -O3 on x86_64-linux-gnu

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords|needs-bisection |

--- Comment #12 from Andrew Pinski  ---
(In reply to Jakub Jelinek from comment #11)
> It still fails for me.  As I corrected in #c7, I didn't mean ICE but
> miscompilation (at -O3).

Yes it does still fail for me too, I don't know what I was doing wrong last
night.

[Bug c/104289] -fdiagnostics-parseable-fixits doesn't always generate fixit notes

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement

[Bug tree-optimization/104292] [missed optimization] boolean addition generates suboptimal code

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-01-30
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

--- Comment #2 from Andrew Pinski  ---
Confirmed, I thought I saw one which was asking about bool + bool == 2 also ...

[Bug tree-optimization/104292] [missed optimization] boolean addition generates suboptimal code

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Severity|normal  |enhancement
   Keywords||missed-optimization

Re: Bisecting

[David Malcolm via Gcc]

On Sun, 2022-01-30 at 01:09 +, Jonathan Wakely via Gcc wrote:
> On Sat, 29 Jan 2022, 20:25 Søren Holm via Gcc,  wrote:
> 
> > Hi
> > 
> > I believe I have found some kind of bug in GCC. The target is a
> > cortex-m7 CPU. I do not have an isolated test software so I'm
> > thinking
> > of bisecting GCC between GCC 9.4 and 10.1.
> > 
> > Are there any easy way do do a fast "change - compile - test"- cycle
> > -
> > and how do I do that? All the guide on building GCC is using huge
> > scripts with installs and such. I'm sure the main developers does not
> > do
> > that.
> > 
> 
> 
> 
> https://gcc.gnu.org/wiki/InstallingGCC is not a huge script, it's a
> very
> small number of commands.
> 
> You can use git bisect to simplify things, but if you don't have a
> small
> reproducer for the problem then I don't see how you can avoid doing a
> full
> build and install. With a simple reproducer, you can just great using
> the
> cc1 or cc1plus binary in the build tree, without installing anything.
> 

Indeed: try to come up with a minimal reproducer demonstrating the
issue (or its absence) deterministically, one that involves a simple
invocation of cc1 (or cc1plus if C++).

Some tips for speeding builds up:

* configure gcc with --disable-bootstrap
* configure gcc with --enable-languages containing just the languages
you need
* you may be able to get away with just "make cc1" in the BUILDDIR/gcc
subdirectory each time; you might need to rebuild BUILDDIR/libcpp
sometimes though, since the API/ABI exposed by BUILDDIR/libcpp to
BUILDDIR/gcc/cc1 changes in some commits
* do the build on a machine with plenty of cores and use an appropriate
-j option to "make"

Might be an idea to configure with --enable-checking=debug since the
versions you refer to straddle the boundaries between released versions
(where --enable-checking=release is the default) and development
versions (where --enable-checking=debug is the default).  --enable-
checking=debug adds lots of extra checking, which is likely to identify
problems in a more controlled fashion even though the built compiler
will be slower.

How deterministic is the failure?  If you're seeing randomness, it
could be an issue with garbage collector markings, in which case 
  --param=ggc-min-expand=0 --param=ggc-min-heapsize=0
will fully run the garbage collector at every GC opportunity (which is
*slow*, but very good at quickly pinpointing the problem if it's a
issue with the GC, which otherwise are a major pain to track down).

Hope this is helpful
Dave

[PATCH] fold-const: do not fold 'inf/inf' with -ftrapping-math [PR95115]

[Xi Ruoyao via Gcc-patches]

'inf/inf' should raise an invalid operation exception at runtime.  So it
should not be folded during compilation unless -fno-trapping-math is
used.

gcc/
PR middle-end/95115
* fold-const.cc (const_binop): Do not fold "inf/inf".

gcc/testsuite
* gcc.dg/pr95115.c: New test.
---
 gcc/fold-const.cc  |  8 
 gcc/testsuite/gcc.dg/pr95115.c | 25 +
 2 files changed, 33 insertions(+)
 create mode 100644 gcc/testsuite/gcc.dg/pr95115.c

diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index fd9c6352d4f..0e99d5a2e3d 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -1283,6 +1283,14 @@ const_binop (enum tree_code code, tree arg1, tree arg2)
  && (flag_trapping_math || ! MODE_HAS_INFINITIES (mode)))
return NULL_TREE;
 
+  /* Don't perform "inf/inf", because it would raise an invalid
+operation exception (IEEE 754 section 7.2 clause d).  */
+  if (code == RDIV_EXPR
+ && flag_trapping_math
+ && REAL_VALUE_ISINF (d1)
+ && REAL_VALUE_ISINF (d2))
+   return NULL_TREE;
+
   /* If either operand is a NaN, just return it.  Otherwise, set up
 for floating-point trap; we return an overflow.  */
   if (REAL_VALUE_ISNAN (d1))
diff --git a/gcc/testsuite/gcc.dg/pr95115.c b/gcc/testsuite/gcc.dg/pr95115.c
new file mode 100644
index 000..46a95dfb698
--- /dev/null
+++ b/gcc/testsuite/gcc.dg/pr95115.c
@@ -0,0 +1,25 @@
+/* { dg-do run } */
+/* { dg-options "-O2 -ftrapping-math" } */
+/* { dg-add-options ieee } */
+/* { dg-require-effective-target fenv_exceptions } */
+
+#include 
+#include 
+
+double
+x (void)
+{
+  double d = __builtin_inf ();
+  return d / d;
+}
+
+int
+main (void)
+{
+  double r = x ();
+  if (!__builtin_isnan (r))
+   abort ();
+  if (!fetestexcept (FE_INVALID))
+   abort ();
+  exit (0);
+}
-- 
2.35.1

[Bug tree-optimization/104292] [missed optimization] boolean addition generates suboptimal code

[avi at scylladb dot com via Gcc-bugs]

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

--- Comment #1 from Avi Kivity  ---
btw, I see that the equivalent bool_and generates optimal code.

bool_and(bool, bool):
movl%esi, %eax
andl%edi, %eax
ret

Perhaps bool is written with the expectation that any non-zero value is true?
But aren't non-zero values other than 1 undefined behavior?

[Bug tree-optimization/104292] New: [missed optimization] boolean addition generates suboptimal code

[avi at scylladb dot com via Gcc-bugs]

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

Bug ID: 104292
   Summary: [missed optimization] boolean addition generates
suboptimal code
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: avi at scylladb dot com
  Target Milestone: ---

bool bool_or(bool b1, bool b2) {
return b1 + b2;
}

generates

bool_or(bool, bool):
movzbl  %dil, %edi
movzbl  %sil, %esi
addl%esi, %edi
setne   %al
ret

Whereas it could generate

bool_or(bool, bool):
or   %edi, %esi
mov  %esi, %eax
ret

For a net gain of two instructions (and the final mov can often be elided, so
up to three).

I encountered this while using std::plus<> with boolean types. It could be
optimized as a specialization of std::plus, but I think a magic transformation
in the optimizer would make it apply in more places.

Re: [PATCH] libstdc++ testsuite: Don't run lwg3464.cc tests on simulators to 20

[Hans-Peter Nilsson via Gcc-patches]

> From: Jonathan Wakely 
> Date: Sun, 30 Jan 2022 18:06:28 +0100
> On Sun, 30 Jan 2022 at 16:54, Hans-Peter Nilsson  wrote:
> > > From: Jonathan Wakely 
> > > But there is nothing target-specific in that code, so it
> > > should be fine to disable them for simulators. They're
> > > already disabled for LP64 because overflowing the 64-bit
> > > counter would take forever.
> > >
> > > I think that would be better than letting them potentially
> > > run for 40 minutes even on real hardware.
> >
> > Ok.  Then this becomes obvious (except from the dejagnu
> > syntax, but that has an obvious progress path).  Also tested
> > that it still doesn't run nor gets some dejagnu error on
> > native x86_64-linux-gnu.
> >
> > Committed.
> 
> Thanks!

No reason, but thank *you* for the review and for the
biggest time win in test-cycle ever.  No, I didn't look, but
7% (720s*2)/5.5h - the total time; surely is unbeatable.

brgds, H-P

[Bug c++/104291] New: gcc accepts template argument involves template parameter(s)

[hewillk at gmail dot com via Gcc-bugs]

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

Bug ID: 104291
   Summary: gcc accepts template argument involves template
parameter(s)
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: hewillk at gmail dot com
  Target Milestone: ---

This should be rejected.

#include

template
struct S { };

template
struct S { };

S x;

https://godbolt.org/z/ecoGPWq3q

Re: [PATCH] libstdc++ testsuite: Don't run lwg3464.cc tests on simulators to 20

[Jonathan Wakely via Gcc-patches]

On Sun, 30 Jan 2022 at 16:54, Hans-Peter Nilsson  wrote:
>
> (I had to add separation between your reply and mine in the
> quoted parts; you may be aware.)
>
> > From: Jonathan Wakely 
> > Date: Sun, 30 Jan 2022 09:32:08 +0100
> > On Sun, 30 Jan 2022, 01:37 Hans-Peter Nilsson via Libstdc++, 
> > mailto:libstdc%2b...@gcc.gnu.org>> wrote:
> > > These tests have always been failing for my cris-elf
> > > autotester running a simulator; they take about 20 minutes
> > > each, compared to the timeout of 720 seconds, doubled
> > > because they timed out in another simulator setup.
> > >
> > > They are the *only* libstdc++ tests that timeout for my
> > > setup so I thought this'd be best fixed in the testsuite
> > > rather than a local timeout setting (in e.g. the baseboard
> > > file).  And, better make it an increase that counts.  Or,
> > > maybe they're actually needlessly excessive?
> >
> > They are testing behaviour when a counter overflows, so
> > they have to read that many bytes. Making them do less
> > work would not test that condition.
> >
> > But there is nothing target-specific in that code, so it
> > should be fine to disable them for simulators. They're
> > already disabled for LP64 because overflowing the 64-bit
> > counter would take forever.
> >
> > I think that would be better than letting them potentially
> > run for 40 minutes even on real hardware.
>
> Ok.  Then this becomes obvious (except from the dejagnu
> syntax, but that has an obvious progress path).  Also tested
> that it still doesn't run nor gets some dejagnu error on
> native x86_64-linux-gnu.
>
> Committed.

Thanks!


>
> 8<->8
> These tests have always been failing for my autotester running a
> cris-elf simulator; when unrestrained they take about 20 minutes each,
> compared to the (doubled) timeout of 720 seconds, of a total 2h40min
> for the whole of the libstdc++-v3 testsuite.  The tests cover counter
> overflow and are already disabled for LP64 targets.
>
> * testsuite/27_io/basic_istream/get/char/lwg3464.cc: Don't run on
> simulator targets.
> * testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc: Likewise.
> ---
>  libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc  | 2 +-
>  .../testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc 
> b/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc
> index f426ff7dd867..5d4de3d6cb54 100644
> --- a/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc
> +++ b/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc
> @@ -15,7 +15,7 @@
>  // with this library; see the file COPYING3.  If not see
>  // .
>
> -// { dg-do run { target { ! lp64 } } }
> +// { dg-do run { target { { ! lp64 } && { ! simulator } } } }
>  // { dg-timeout-factor 2 }
>
>  #include 
> diff --git 
> a/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc 
> b/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc
> index 4be6beb2310f..e2349df8c7d6 100644
> --- a/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc
> +++ b/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc
> @@ -15,7 +15,7 @@
>  // with this library; see the file COPYING3.  If not see
>  // .
>
> -// { dg-do run { target { ! lp64 } } }
> +// { dg-do run { target { { ! lp64 } && { ! simulator } } } }
>  // { dg-timeout-factor 2 }
>
>  #include 
> --
> 2.30.2
>
>

[PATCH] libstdc++ testsuite: Don't run lwg3464.cc tests on simulators to 20

[Hans-Peter Nilsson via Gcc-patches]

(I had to add separation between your reply and mine in the
quoted parts; you may be aware.)

> From: Jonathan Wakely 
> Date: Sun, 30 Jan 2022 09:32:08 +0100
> On Sun, 30 Jan 2022, 01:37 Hans-Peter Nilsson via Libstdc++, 
> mailto:libstdc%2b...@gcc.gnu.org>> wrote:
> > These tests have always been failing for my cris-elf
> > autotester running a simulator; they take about 20 minutes
> > each, compared to the timeout of 720 seconds, doubled
> > because they timed out in another simulator setup.
> >
> > They are the *only* libstdc++ tests that timeout for my
> > setup so I thought this'd be best fixed in the testsuite
> > rather than a local timeout setting (in e.g. the baseboard
> > file).  And, better make it an increase that counts.  Or,
> > maybe they're actually needlessly excessive?
> 
> They are testing behaviour when a counter overflows, so
> they have to read that many bytes. Making them do less
> work would not test that condition.
> 
> But there is nothing target-specific in that code, so it
> should be fine to disable them for simulators. They're
> already disabled for LP64 because overflowing the 64-bit
> counter would take forever.
> 
> I think that would be better than letting them potentially
> run for 40 minutes even on real hardware.

Ok.  Then this becomes obvious (except from the dejagnu
syntax, but that has an obvious progress path).  Also tested
that it still doesn't run nor gets some dejagnu error on
native x86_64-linux-gnu.

Committed.

8<->8
These tests have always been failing for my autotester running a
cris-elf simulator; when unrestrained they take about 20 minutes each,
compared to the (doubled) timeout of 720 seconds, of a total 2h40min
for the whole of the libstdc++-v3 testsuite.  The tests cover counter
overflow and are already disabled for LP64 targets.

* testsuite/27_io/basic_istream/get/char/lwg3464.cc: Don't run on
simulator targets.
* testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc: Likewise.
---
 libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc  | 2 +-
 .../testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc 
b/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc
index f426ff7dd867..5d4de3d6cb54 100644
--- a/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_istream/get/char/lwg3464.cc
@@ -15,7 +15,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-do run { target { ! lp64 } } }
+// { dg-do run { target { { ! lp64 } && { ! simulator } } } }
 // { dg-timeout-factor 2 }
 
 #include 
diff --git a/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc 
b/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc
index 4be6beb2310f..e2349df8c7d6 100644
--- a/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc
+++ b/libstdc++-v3/testsuite/27_io/basic_istream/get/wchar_t/lwg3464.cc
@@ -15,7 +15,7 @@
 // with this library; see the file COPYING3.  If not see
 // .
 
-// { dg-do run { target { ! lp64 } } }
+// { dg-do run { target { { ! lp64 } && { ! simulator } } } }
 // { dg-timeout-factor 2 }
 
 #include 
-- 
2.30.2

[Bug middle-end/95115] RISC-V 64: inf/inf division optimized out, invalid operation not raised

[xry111 at mengyan1223 dot wang via Gcc-bugs]

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

--- Comment #8 from Xi Ruoyao  ---
This is causing Glibc test failure on every port without hardware acos/asin
instruction.

[Bug libstdc++/92770] std::unordered_map requires both T and U to be fully declared

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

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

--- Comment #4 from Jonathan Wakely  ---
The relevant changes were r12-4258-g64acc43de1e336 and r12-4259-gd87105d697ced1

[Bug fortran/80524] [F03] Problematic behaviour with a finalization subroutine in gfortran

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

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

Paul Thomas  changed:

   What|Removed |Added

 CC||pault at gcc dot gnu.org

--- Comment #8 from Paul Thomas  ---
(In reply to Jürgen Reuter from comment #7)
> This is still present in the actual trunk.

I can confirm that Intel's interpretation is completely correct. I have a patch
in progress that issues the correct number of final calls but which is ordering
the evaluation of the function result and the finalization of the lhs in the
wrong order.

Paul

[Bug go/104290] New: [12 Regression] trunk 20220126 fails to build libgo on i686-gnu

[doko at debian dot org via Gcc-bugs]

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

Bug ID: 104290
   Summary: [12 Regression] trunk 20220126 fails to build libgo on
i686-gnu
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: go
  Assignee: ian at airs dot com
  Reporter: doko at debian dot org
CC: cmang at google dot com
  Target Milestone: ---

trunk 20220126 fails to build libgo on i686-gnu:

../../../src/libgo/go/net/unixsock_posix.go:116:56: error: reference to
undefined name 'readMsgFlags'
  116 | n, oobn, flags, sa, err = c.fd.readMsg(b, oob, readMsgFlags)
  |^
../../../src/libgo/go/net/unixsock_posix.go:117:12: error: reference to
undefined name 'readMsgFlags'
  117 | if readMsgFlags == 0 && err == nil && oobn > 0 {
  |^
../../../src/libgo/go/net/unixsock_posix.go:118:17: error: reference to
undefined name 'setReadMsgCloseOnExec'
  118 | setReadMsgCloseOnExec(oob[:oobn])
  | ^
Makefile:3026: recipe for target 'net.lo' failed
make[6]: *** [net.lo] Error 1

[Bug c/104289] New: -fdiagnostics-parseable-fixits doesn't always generate fixit notes

[eric.pouech at orange dot fr via Gcc-bugs]

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

Bug ID: 104289
   Summary: -fdiagnostics-parseable-fixits doesn't always generate
fixit notes
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: eric.pouech at orange dot fr
  Target Milestone: ---

[eric]$ cat b2.c
#include 

#define foo(x...) printf(x);

int main(void)
{
long l = 0;
foo("this is a"
"long line: %d\n", l);  
return 0;
}
[eric]$ LC_ALL=C gcc -Wall -fdiagnostics-parseable-fixits -c b2.c
b2.c: In function 'main':
b2.c:8:9: warning: format '%d' expects argument of type 'int', but argument 2
has type 'long int' [-Wformat=]
8 | foo("this is a"
  | ^~~
9 | "long line: %d\n", l);
  |~
  ||
  |long int
b2.c:3:26: note: in definition of macro 'foo'
3 | #define foo(x...) printf(x);
  |  ^

I'm expecting a fixit note to be present.
Note: the same snipnet without the multi line string, or the macro work as
expected.

[Bug libstdc++/92770] std::unordered_map requires both T and U to be fully declared

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

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

--- Comment #3 from Jonathan Wakely  ---
Intentionally, but it's not guaranteed to keeps working in future. The standard
still says it's undefined.

[Bug rtl-optimization/102446] [9/10/11/12 Regression] wrong code at -O3 on x86_64-linux-gnu

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

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

--- Comment #11 from Jakub Jelinek  ---
It still fails for me.  As I corrected in #c7, I didn't mean ICE but
miscompilation (at -O3).

[Bug ipa/103083] [10/11/12 Regression] Wrong code due to ipa-cp's bits value propagation since r10-5538-gc7ac9a0c7e3916f1

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

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

Martin Jambor  changed:

   What|Removed |Added

Summary|[10/11/12 Regression] Wrong |[10/11/12 Regression] Wrong
   |code due to ipa-cp's value  |code due to ipa-cp's bits
   |range propagation since |value propagation since
   |r10-5538-gc7ac9a0c7e3916f1  |r10-5538-gc7ac9a0c7e3916f1

--- Comment #4 from Martin Jambor  ---
The last proposal to fix this is in
https://gcc.gnu.org/pipermail/gcc-patches/2021-November/585668.html

I will have another look, re-test and ping it soon.

Re: Enquiry

[Jonathan Wakely via Gcc]

Meta-comment: a subject line of "Enquiry" is very vague, and most commonly
used by spammers and phishers. Your enquiry is about undefined behaviour
due to a missing return, which would have been a much better subject.




On Sun, 30 Jan 2022, 09:48 Theodore Papadopoulo, <
theodore.papadopo...@inria.fr> wrote:

> Before creating a bug report, I want to check with the GCC community
> (all the more that checking that the problem has not yet been reported
> is complicated at leat for me).
>
> The following (admitedly buggy) program generates a segmentation
> violation on fedora 35 (this is with g++ 11.2.1 20211203 (Red Hat
> 11.2.1-7) (GCC))
> when compiled with -O3 (other versions replacing unisgned by std::string
> may trigger the exception instead of the segv)
>
> bool assert_sthg(const unsigned s) {
>  if (s==123)
>  throw 1;
> }
>
> int main() {
>  assert_sthg(0);
>  return 0;
> }
>
> When compiling, we indeed get a warning:
>
> test.C:4:1: warning: control reaches end of non-void function
> [-Wreturn-type]
>
> I can well understand that the program being buggy that the optimizer is
> allowed to do anything including the observed segmentation violation.
> Yet the result is quite surprising
> The question is, in that case, wouldn't it be better to turn the warning
> into an error at -O3 ?
>
>  Thank's for any input.
>
>  Theo.
>
>

Re: Enquiry

[Jonathan Wakely via Gcc]

On Sun, 30 Jan 2022, 10:58 Jakub Jelinek,  wrote:

> On Sun, Jan 30, 2022 at 10:50:56AM +, Jonathan Wakely wrote:
> > We could put a trap instruction at the end of the function though, which
> > would make the result a bit less arbitrary.
> >
> > I've come around to thinking that's preferable for cases like this.
>
> Depends on which exact cases.
> Because for
> int foo (int s) { if (s == 123) return 1; }
> we want to optimize it into
> return 1;
> rather than if (s == 123) return 1; else __builtin_trap ();
> For debugging we have -fsanitize=undefined


What if we inserted the trap for -O0?

1. Not everybody uses ubsan even when they should use it.

2. The code can use unreachable annotations if it really needs to leave
some paths unhandled, but really can't live with the branch and trap
instructions. (The C++ standard is getting std::unreachable and std::assume
to do that in a portable way, so there is less excuse for not doing it).

[Bug tree-optimization/104288] [11/12 Regression] EVRP null pointer check removal for strcmp (and maybe others) is not flow senative

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

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

Jakub Jelinek  changed:

   What|Removed |Added

 CC||aldyh at gcc dot gnu.org,
   ||amacleod at redhat dot com,
   ||jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek  ---
Started with r11-3685-gfcae5121154d1c3382b056bcc2c563cedac28e74

Re: Enquiry

[Jakub Jelinek via Gcc]

On Sun, Jan 30, 2022 at 10:50:56AM +, Jonathan Wakely wrote:
> We could put a trap instruction at the end of the function though, which
> would make the result a bit less arbitrary.
> 
> I've come around to thinking that's preferable for cases like this.

Depends on which exact cases.
Because for
int foo (int s) { if (s == 123) return 1; }
we want to optimize it into
return 1;
rather than if (s == 123) return 1; else __builtin_trap ();
For debugging we have -fsanitize=undefined

Jakub

Re: Enquiry

[Jonathan Wakely via Gcc]

On Sun, 30 Jan 2022, 10:42 Jakub Jelinek via Gcc,  wrote:

> On Sun, Jan 30, 2022 at 10:47:41AM +0100, Theodore Papadopoulo wrote:
> > Before creating a bug report, I want to check with the GCC community (all
> > the more that checking that the problem has not yet been reported is
> > complicated at leat for me).
> >
> > The following (admitedly buggy) program generates a segmentation
> violation
> > on fedora 35 (this is with g++ 11.2.1 20211203 (Red Hat 11.2.1-7) (GCC))
> > when compiled with -O3 (other versions replacing unisgned by std::string
> may
> > trigger the exception instead of the segv)
> >
> > bool assert_sthg(const unsigned s) {
> > if (s==123)
> > throw 1;
> > }
> >
> > int main() {
> > assert_sthg(0);
> > return 0;
> > }
> >
> > When compiling, we indeed get a warning:
> >
> > test.C:4:1: warning: control reaches end of non-void function
> > [-Wreturn-type]
> >
> > I can well understand that the program being buggy that the optimizer is
> > allowed to do anything including the observed segmentation violation.
> > Yet the result is quite surprising
>
> Undefined behavior can have any kind of surprising behavior.
>
> > The question is, in that case, wouldn't it be better to turn the warning
> > into an error at -O3 ?
>
> No, it can't be an error by default, it is undefined behavior only at
> runtime, if you never call the function or always call it with
> assert_sthg(123), then the program can be valid.
>

We could put a trap instruction at the end of the function though, which
would make the result a bit less arbitrary.

I've come around to thinking that's preferable for cases like this.

Re: Enquiry

[Jakub Jelinek via Gcc]

On Sun, Jan 30, 2022 at 10:47:41AM +0100, Theodore Papadopoulo wrote:
> Before creating a bug report, I want to check with the GCC community (all
> the more that checking that the problem has not yet been reported is
> complicated at leat for me).
> 
> The following (admitedly buggy) program generates a segmentation violation
> on fedora 35 (this is with g++ 11.2.1 20211203 (Red Hat 11.2.1-7) (GCC))
> when compiled with -O3 (other versions replacing unisgned by std::string may
> trigger the exception instead of the segv)
> 
> bool assert_sthg(const unsigned s) {
>     if (s==123)
>     throw 1;
> }
> 
> int main() {
>     assert_sthg(0);
>     return 0;
> }
> 
> When compiling, we indeed get a warning:
> 
> test.C:4:1: warning: control reaches end of non-void function
> [-Wreturn-type]
> 
> I can well understand that the program being buggy that the optimizer is
> allowed to do anything including the observed segmentation violation.
> Yet the result is quite surprising

Undefined behavior can have any kind of surprising behavior.

> The question is, in that case, wouldn't it be better to turn the warning
> into an error at -O3 ?

No, it can't be an error by default, it is undefined behavior only at
runtime, if you never call the function or always call it with
assert_sthg(123), then the program can be valid.

Jakub

[Bug tree-optimization/104288] [11/12 Regression] EVRP null pointer check removal for strcmp (and maybe others) is not flow senative

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Keywords||needs-bisection
  Component|middle-end  |tree-optimization

--- Comment #2 from Andrew Pinski  ---
EVRP is removing the null pointer check. I suspect the ranger code is not
taking into account where we are in the IR and it thinks the arguments to
strcmp will be null pointers but before we have other function calls which
might not return.

[Bug middle-end/104288] [11/12 Regression] Null pointer check invalidly deleted

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

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

Andrew Pinski  changed:

   What|Removed |Added

   Last reconfirmed||2022-01-30
Summary|Null pointer check  |[11/12 Regression] Null
   |invalidly deleted   |pointer check invalidly
   ||deleted
   Keywords||wrong-code
   Target Milestone|--- |11.3
 Ever confirmed|0   |1
 Status|UNCONFIRMED |NEW

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

Reduced/more self-contained testcase:
void h(int result) __attribute__((noipa));
void h(int result)
{
if (result)
__builtin_exit(0);
}
void n(const char *value_1) __attribute__((noipa));
void n(const char *value_1)
{
h(value_1 == 0);

int result = !__builtin_strcmp(value_1, "value 1");
__builtin_exit (!result);
}
int main()
{
n(0);
}

Re: [EXTERNAL] [PATCH] testsuite: Fix up tree-ssa/pr103514.c testcase [PR103514]

[Navid Rahimi via Gcc-patches]

Thanks Jakob for the correction. Sadly, I didn’t have any access to any non x86 
architecture. But x86 was fully tested and there was no regression.

In my spare time I will look at implementation of this for short-circuit 
targets.

Best wishes,
Navid.

From: Jakub Jelinek 
Sent: Saturday, January 29, 2022 8:46:09 AM
To: Richard Biener ; Jeff Law 
Cc: Navid Rahimi ; gcc-patches@gcc.gnu.org 

Subject: [EXTERNAL] [PATCH] testsuite: Fix up tree-ssa/pr103514.c testcase 
[PR103514]

[You don't often get email from ja...@redhat.com. Learn why this is important 
at http://aka.ms/LearnAboutSenderIdentification.]

On Fri, Jan 28, 2022 at 03:14:16PM -0700, Jeff Law via Gcc-patches wrote:
> > This patch will add the missed pattern described in bug 103514 [1] to the 
> > match.pd. [1] includes proof of correctness for the patch too.
> >
> > PR tree-optimization/103514
> > * match.pd (a & b) ^ (a == b) -> !(a | b): New optimization.
> > * match.pd (a & b) == (a ^ b) -> !(a | b): New optimization.
> > * gcc.dg/tree-ssa/pr103514.c: Testcase for this optimization.
> >
> > 1) 
> > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fbugzilla%2Fshow_bug.cgi%3Fid%3D103514data=04%7C01%7Cnavidrahimi%40microsoft.com%7C712766ef9fc24c7ffeda08d9e346e086%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637790716153978385%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000sdata=CGslhJuy%2BTSrPpYbALD9pBh9945Hl6lINeHKmTEWqK0%3Dreserved=0
> Note the bug was filed an fixed during stage3, review just didn't happen in
> a reasonable timeframe.
>
> I'm going to ACK this for the trunk and go ahead and commit it for you.

The testcase FAILs on short-circuit targets like powerpc64le-linux.
While the first 2 functions are identical, the last two look like:
   :
  if (a_5(D) != 0)
goto ; [INV]
  else
goto ; [INV]

   :
  if (b_6(D) != 0)
goto ; [INV]
  else
goto ; [INV]

   :

   :
  # iftmp.1_4 = PHI <1(3), 0(4)>
  _1 = a_5(D) == b_6(D);
  _2 = (int) _1;
  _3 = _2 ^ iftmp.1_4;
  _9 = _2 != iftmp.1_4;
  return _9;
instead of the expected:
   :
  _3 = a_8(D) & b_9(D);
  _4 = (int) _3;
  _5 = a_8(D) == b_9(D);
  _6 = (int) _5;
  _1 = a_8(D) | b_9(D);
  _2 = ~_1;
  _7 = (int) _2;
  _10 = ~_1;
  return _10;
so no wonder it doesn't match.  E.g. x86_64-linux will also use jumps
if it isn't just a && b but a && b && c && d (will do
a & b and c & d tests and jump based on those.

As it is too late to implement this optimization even for the short
circuiting targets this late (not even sure which pass would be best),
this patch just forces non-short-circuiting for the test.

Tested on x86_64-linux -m32/-m64 and powerpc64le-linux, ok for trunk?

2022-01-29  Jakub Jelinek  

PR tree-optimization/103514
* gcc.dg/tree-ssa/pr103514.c: Add
--param logical-op-non-short-circuit=1 to dg-options.

--- gcc/testsuite/gcc.dg/tree-ssa/pr103514.c.jj 2022-01-29 11:11:39.338627697 
+0100
+++ gcc/testsuite/gcc.dg/tree-ssa/pr103514.c2022-01-29 17:37:18.255237211 
+0100
@@ -1,5 +1,5 @@
 /* { dg-do compile } */
-/* { dg-options "-O -fdump-tree-optimized" } */
+/* { dg-options "-O --param logical-op-non-short-circuit=1 
-fdump-tree-optimized" } */
 #include 

 bool
@@ -30,4 +30,4 @@ h (bool a, bool b)
 /* Make sure we have removed "==" and "^" and "&". */
 /* { dg-final { scan-tree-dump-not "&" "optimized"} } */
 /* { dg-final { scan-tree-dump-not "\\^"  "optimized"} } */
-/* { dg-final { scan-tree-dump-not "==" "optimized"} } */
\ No newline at end of file
+/* { dg-final { scan-tree-dump-not "==" "optimized"} } */


Jakub

[Bug c/104288] New: Null pointer check invalidly deleted

[nrk at disroot dot org via Gcc-bugs]

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

Bug ID: 104288
   Summary: Null pointer check invalidly deleted
   Product: gcc
   Version: 11.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: nrk at disroot dot org
  Target Milestone: ---

Hi,

In the following code, the null checks are removed when compiled with `-O2` on
gcc v11.2.1. Compiling with `-O2 -fno-delete-null-pointer-checks` produces
proper result.

#include 
#include 
#include 
#include 


#define RESULT_PASS "PASS"
#define RESULT_FAIL "FAIL"


void test_assert(bool result)
{
printf("Assert: %s\n", result ? RESULT_PASS : RESULT_FAIL);

if (!result)
exit(EXIT_FAILURE);
}


void test_strcmp(const char *value_1, const char *value_2)
{
test_assert(value_1 != NULL);
test_assert(value_2 != NULL);

bool result = !strcmp(value_1, value_2);

printf("Test equal: %s\n", result ? RESULT_PASS : RESULT_FAIL);
}


int main()
{
test_strcmp(NULL, "value 1");
}

(code snippet taken from:
https://gist.github.com/novns/c84d6e1efd6304b3076811fef34096fd )

[Bug libstdc++/92770] std::unordered_map requires both T and U to be fully declared

[fchelnokov at gmail dot com via Gcc-bugs]

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

Fedor Chelnokov  changed:

   What|Removed |Added

 CC||fchelnokov at gmail dot com

--- Comment #2 from Fedor Chelnokov  ---
I see that this issue is fixed in GCC trunk. Demo:
https://gcc.godbolt.org/z/Gz5WY495Y

Was it intentionally or by accident?

[Bug c++/58855] Attributes ignored on type alias in template

[gcc at ebasoft dot com.pl via Gcc-bugs]

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

gcc at ebasoft dot com.pl changed:

   What|Removed |Added

 CC||gcc at ebasoft dot com.pl

--- Comment #3 from gcc at ebasoft dot com.pl ---
This bug is still present in gcc version 11.2.1 20220115

namespace concepts
{
 template
 concept arithmetic = std::integral || std::floating_point;
}
template
using point_vector = T __attribute__((__vector_size__(sizeof(T)*2)));

warning: ignoring attributes applied to dependent type ‘T’ without an
associated declaration [-Wattributes]
   70 | using point_vector = T
__attribute__((__vector_size__(sizeof(T)*2)));
  |   
^

Enquiry

[Theodore Papadopoulo]

Before creating a bug report, I want to check with the GCC community 
(all the more that checking that the problem has not yet been reported 
is complicated at leat for me).


The following (admitedly buggy) program generates a segmentation 
violation on fedora 35 (this is with g++ 11.2.1 20211203 (Red Hat 
11.2.1-7) (GCC))
when compiled with -O3 (other versions replacing unisgned by std::string 
may trigger the exception instead of the segv)


bool assert_sthg(const unsigned s) {
    if (s==123)
    throw 1;
}

int main() {
    assert_sthg(0);
    return 0;
}

When compiling, we indeed get a warning:

test.C:4:1: warning: control reaches end of non-void function 
[-Wreturn-type]


I can well understand that the program being buggy that the optimizer is 
allowed to do anything including the observed segmentation violation.

Yet the result is quite surprising
The question is, in that case, wouldn't it be better to turn the warning 
into an error at -O3 ?


    Thank's for any input.

        Theo.

Re: [PATCH] libstdc++ testsuite: Increase lwg3464.cc timeout factors to 20

[Jonathan Wakely via Gcc-patches]

On Sun, 30 Jan 2022, 01:37 Hans-Peter Nilsson via Libstdc++, <
libstd...@gcc.gnu.org> wrote:

> These tests have always been failing for my cris-elf
> autotester running a simulator; they take about 20 minutes
> each, compared to the timeout of 720 seconds, doubled
> because they timed out in another simulator setup.
>
> They are the *only* libstdc++ tests that timeout for my
> setup so I thought this'd be best fixed in the testsuite
> rather than a local timeout setting (in e.g. the baseboard
> file).  And, better make it an increase that counts.  Or,
> maybe they're actually needlessly excessive?


They are testing behaviour when a counter overflows, so they have to read
that many bytes. Making them do less work would not test that condition.

But there is nothing target-specific in that code, so it should be fine to
disable them for simulators. They're already disabled for LP64 because
overflowing the 64-bit counter would take forever.

I think that would be better than letting them potentially run for 40
minutes even on real hardware.

[Bug d/104287] [12 regression] error: spurious trailing punctuation sequence ').' in format [-Werror=format-diag]

[schwab--- via Gcc-bugs]

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

Andreas Schwab  changed:

   What|Removed |Added

   Target Milestone|--- |12.0

[Bug d/104287] New: [12 regression] error: spurious trailing punctuation sequence ').' in format [-Werror=format-diag]

[schwab--- via Gcc-bugs]

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

Bug ID: 104287
   Summary: [12 regression] error: spurious trailing punctuation
sequence ').'  in format [-Werror=format-diag]
   Product: gcc
   Version: 12.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: d
  Assignee: ibuclaw at gdcproject dot org
  Reporter: sch...@linux-m68k.org
  Target Milestone: ---

../../gcc/d/decl.cc: In function 'void d_finish_decl(tree)':
../../gcc/d/decl.cc:1601:53: error: spurious trailing punctuation sequence ').'
in format [-Werror=format-diag]
 1601 |   "its initializer size (%wd).",
  | ^~