[COMIITTED] Testsuite: Make dependence on -fdelete-null-pointer-checks explicit
I've checked in these tweaks for various testcases that fail on
nios2-elf without an explicit -fdelete-null-pointer-checks option. This
target is configured to build with that optimization off by default.
-Sandra
commit 04c69d0e61c0f98a010d77a79ab749d5f0aa6b67
Author: Sandra Loosemore
Date: Sat Jan 8 22:02:13 2022 -0800
Testsuite: Make dependence on -fdelete-null-pointer-checks explicit
nios2-elf target defaults to -fno-delete-null-pointer-checks, breaking
tests that implicitly depend on that optimization. Add the option
explicitly on these tests.
2022-01-08 Sandra Loosemore
gcc/testsuite/
* g++.dg/cpp0x/constexpr-compare1.C: Add explicit
-fdelete-null-pointer-checks option.
* g++.dg/cpp0x/constexpr-compare2.C: Likewise.
* g++.dg/cpp0x/constexpr-typeid2.C: Likewise.
* g++.dg/cpp1y/constexpr-94716.C: Likewise.
* g++.dg/cpp1z/constexpr-compare1.C: Likewise.
* g++.dg/cpp1z/constexpr-if36.C: Likewise.
* gcc.dg/init-compare-1.c: Likewise.
libstdc++-v3/
* testsuite/18_support/type_info/constexpr.cc: Add explicit
-fdelete-null-pointer-checks option.
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-compare1.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-compare1.C
index ad65019..603c6d5 100644
--- a/gcc/testsuite/g++.dg/cpp0x/constexpr-compare1.C
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-compare1.C
@@ -1,4 +1,5 @@
// { dg-do compile { target c++11 } }
+// { dg-additional-options "-fdelete-null-pointer-checks" }
extern int a, b;
static_assert ( == , "");
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-compare2.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-compare2.C
index b1bc472..5c08dbb 100644
--- a/gcc/testsuite/g++.dg/cpp0x/constexpr-compare2.C
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-compare2.C
@@ -1,5 +1,6 @@
// PR c++/69681
// { dg-do compile { target c++11 } }
+// { dg-additional-options "-fdelete-null-pointer-checks" }
void f();
void g();
diff --git a/gcc/testsuite/g++.dg/cpp0x/constexpr-typeid2.C b/gcc/testsuite/g++.dg/cpp0x/constexpr-typeid2.C
index 78c6b8e..8ab76f9 100644
--- a/gcc/testsuite/g++.dg/cpp0x/constexpr-typeid2.C
+++ b/gcc/testsuite/g++.dg/cpp0x/constexpr-typeid2.C
@@ -1,5 +1,6 @@
// PR c++/103600
// { dg-do compile { target c++11 } }
+// { dg-additional-options "-fdelete-null-pointer-checks" }
#include
diff --git a/gcc/testsuite/g++.dg/cpp1y/constexpr-94716.C b/gcc/testsuite/g++.dg/cpp1y/constexpr-94716.C
index 90173f3..5ac8720 100644
--- a/gcc/testsuite/g++.dg/cpp1y/constexpr-94716.C
+++ b/gcc/testsuite/g++.dg/cpp1y/constexpr-94716.C
@@ -1,5 +1,6 @@
// PR c++/94716
// { dg-do compile { target c++14 } }
+// { dg-additional-options "-fdelete-null-pointer-checks" }
template char v = 0;
static_assert (<2> == <2>, "");
diff --git a/gcc/testsuite/g++.dg/cpp1z/constexpr-compare1.C b/gcc/testsuite/g++.dg/cpp1z/constexpr-compare1.C
index a53c03c..d40d536 100644
--- a/gcc/testsuite/g++.dg/cpp1z/constexpr-compare1.C
+++ b/gcc/testsuite/g++.dg/cpp1z/constexpr-compare1.C
@@ -1,4 +1,5 @@
// { dg-do compile { target c++17 } }
+// { dg-additional-options "-fdelete-null-pointer-checks" }
inline int a = 0;
inline int b = 0;
diff --git a/gcc/testsuite/g++.dg/cpp1z/constexpr-if36.C b/gcc/testsuite/g++.dg/cpp1z/constexpr-if36.C
index 4a1b134..e425af2 100644
--- a/gcc/testsuite/g++.dg/cpp1z/constexpr-if36.C
+++ b/gcc/testsuite/g++.dg/cpp1z/constexpr-if36.C
@@ -3,6 +3,7 @@
// weakness.
// { dg-do compile { target c++17 } }
+// { dg-additional-options "-fdelete-null-pointer-checks" }
extern void weakfn1 (void);
extern void weakfn2 (void);
diff --git a/gcc/testsuite/gcc.dg/init-compare-1.c b/gcc/testsuite/gcc.dg/init-compare-1.c
index 9208b66..6737c85 100644
--- a/gcc/testsuite/gcc.dg/init-compare-1.c
+++ b/gcc/testsuite/gcc.dg/init-compare-1.c
@@ -1,4 +1,5 @@
/* { dg-do compile } */
+/* { dg-additional-options "-fdelete-null-pointer-checks" } */
extern int a, b;
int c = ==
diff --git a/libstdc++-v3/testsuite/18_support/type_info/constexpr.cc b/libstdc++-v3/testsuite/18_support/type_info/constexpr.cc
index 07f4fb6..6fb67b4 100644
--- a/libstdc++-v3/testsuite/18_support/type_info/constexpr.cc
+++ b/libstdc++-v3/testsuite/18_support/type_info/constexpr.cc
@@ -1,5 +1,6 @@
// { dg-options "-std=gnu++23 -frtti" }
// { dg-do compile { target c++23 } }
+// { dg-additional-options "-fdelete-null-pointer-checks" }
#include
[Bug target/60301] cross compiler for android: multiple definition of TARGET_POSIX_IO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60301 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #2 from Andrew Pinski --- -DTARGET_POSIX_IO never shows up in any of the gcc sources for the building so this has to be some patch from the android folks.
[Bug target/10778] Exception handling seems to fail on a powerpc using GCC 3.2.3 powerpc-eabi cross compiler
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=10778 Andrew Pinski changed: What|Removed |Added Resolution|--- |WORKSFORME Status|WAITING |RESOLVED --- Comment #11 from Andrew Pinski --- No feedback in over 5 years, I am going to assume it works now.
[Bug libstdc++/41628] _GLIBCXX_DEBUG feature: check for unstable iterators
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41628 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #5 from Andrew Pinski --- >Roland, could you please clarify the request, or I'll close this report as >WORKSFORME. No clarification in over 6 years so I am just going to close as works for me.
[Bug ada/68183] Using Serial communication stream lose packets somtimes, file OK
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68183 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #2 from Andrew Pinski --- No testcase provided in over 6 years so closing as invalid.
[Bug target/48244] iso-c-binding support missing on NetBSD (with patch)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48244 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.0 --- Comment #13 from Andrew Pinski --- One part fof the patch in comment # 3 was committed as r7-4703, the other part was committed in r7-4638. So closing as fixed in GCC 7.
[Bug fortran/59263] Fortran debug: For MODULEs, set DW_AT_accessibility with DW_ACCESS_private where appopriate
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59263 Andrew Pinski changed: What|Removed |Added Status|WAITING |NEW
[Bug fortran/56626] [DWARF/debug] Generate proper debug symbols for assumed-rank arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56626 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|2015-10-20 00:00:00 |2022-01-09 Ever confirmed|0 |1
[Bug fortran/56626] [DWARF/debug] Generate proper debug symbols for assumed-rank arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56626 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED
[Bug lto/55902] lto1 SIGSEGV
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55902 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Host|i686-w64-mingw32| Status|WAITING |RESOLVED Build|x86_64-linux-gnu| --- Comment #7 from Andrew Pinski --- The google drive link does not work any more. Plus there has been many improvements to both ld and GCC with respect to LTO even for mingw. So closing as invalid. Plus there is no way to test almost 9 year old bug.
[Bug other/47029] fixincludes: the fix for c99 inlines in the glibc header files fixes function declarations as well as function definitions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47029 Andrew Pinski changed: What|Removed |Added Ever confirmed|1 |0 Status|WAITING |UNCONFIRMED
[Bug plugins/44968] structs saved (in a vector) during PLUGIN_FINISH_TYPE are mangled by the time of PLUGIN_FINISH_UNIT
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=44968 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #6 from Andrew Pinski --- The plugin is saving around GC'able memory without having it in a GC root so it is being GC'ed away. There is nothing that GCC can do differently in this case so closing as invalid. Also there is no feedback on this for the last 10 years.
[PATCH] middle-end: move initialization of stack_limit_rtx [PR103163]
This patch fixes the ICE I reported in PR103163. We were initializing
stack_limit_rtx before the register properties it depends on were
getting set. I moved it to the same function where stack_pointer_rtx,
frame_pointer_rtx, etc are being initialized.
Besides nios2 where I observed it, this bug was also reported to affect
powerpc. Anybody want to check it there? Otherwise, OK to check in?
-Sandra
commit bd91ec874339f9fd256b2d83de7159f6c11f
Author: Sandra Loosemore
Date: Sat Jan 8 19:59:26 2022 -0800
middle-end: move initialization of stack_limit_rtx [PR103163]
stack_limit_rtx was being initialized before init_reg_modes_target (),
resulting in the REG expression being created incorrectly and an ICE
later in compilation.
2022-01-08 Sandra Loosemore
PR middle-end/103163
gcc/
* emit-rtl.c (init_emit_regs): Initialize stack_limit_rtx here...
(init_emit_once): ...not here.
diff --git a/gcc/emit-rtl.c b/gcc/emit-rtl.c
index f16..76dbe42 100644
--- a/gcc/emit-rtl.c
+++ b/gcc/emit-rtl.c
@@ -6097,6 +6097,13 @@ init_emit_regs (void)
if ((unsigned) PIC_OFFSET_TABLE_REGNUM != INVALID_REGNUM)
pic_offset_table_rtx = gen_raw_REG (Pmode, PIC_OFFSET_TABLE_REGNUM);
+ /* Process stack-limiting command-line options. */
+ if (opt_fstack_limit_symbol_arg != NULL)
+stack_limit_rtx
+ = gen_rtx_SYMBOL_REF (Pmode, ggc_strdup (opt_fstack_limit_symbol_arg));
+ if (opt_fstack_limit_register_no >= 0)
+stack_limit_rtx = gen_rtx_REG (Pmode, opt_fstack_limit_register_no);
+
for (i = 0; i < (int) MAX_MACHINE_MODE; i++)
{
mode = (machine_mode) i;
@@ -6177,13 +6184,6 @@ init_emit_once (void)
/* Create the unique rtx's for certain rtx codes and operand values. */
- /* Process stack-limiting command-line options. */
- if (opt_fstack_limit_symbol_arg != NULL)
-stack_limit_rtx
- = gen_rtx_SYMBOL_REF (Pmode, ggc_strdup (opt_fstack_limit_symbol_arg));
- if (opt_fstack_limit_register_no >= 0)
-stack_limit_rtx = gen_rtx_REG (Pmode, opt_fstack_limit_register_no);
-
/* Don't use gen_rtx_CONST_INT here since gen_rtx_CONST_INT in this case
tries to use these variables. */
for (i = - MAX_SAVED_CONST_INT; i <= MAX_SAVED_CONST_INT; i++)
[Bug middle-end/96032] RFE: add a way to use output from --fdiagnostics-format=json as input
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96032 Andrew Pinski changed: What|Removed |Added Target Milestone|9.0 |---
[Bug c/101630] [9/10/11/12 Regression] ICE with -Wall: in get_constant, at c-family/c-format.c:325
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101630 Andrew Pinski changed: What|Removed |Added Target Milestone|9.0 |9.5
[Bug testsuite/85527] [openacc] atomic_capture-1.{c,f90} undefined behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85527 Andrew Pinski changed: What|Removed |Added Target Milestone|9.0 |---
[Bug tree-optimization/69196] [5 Regression] code size regression with jump threading at -O2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69196 Andrew Pinski changed: What|Removed |Added Target Milestone|6.5 |---
[Bug tree-optimization/57503] Missing warning for signed overflow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57503 Andrew Pinski changed: What|Removed |Added Target Milestone|6.5 |---
[Bug go/66368] [5 Regression] go tool crashes on powerpc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66368 Andrew Pinski changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |WORKSFORME --- Comment #12 from Andrew Pinski --- No feedback in over 6 years so closing.
[Bug target/66195] Optimize _GLIBCXX_GUARD_TEST_AND_ACQUIRE and _GLIBCXX_GUARD_SET_AND_RELEASE for PowerPC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66195 Andrew Pinski changed: What|Removed |Added Target Milestone|6.5 |---
[Bug debug/66668] FAIL: gcc.dg/debug/dwarf2/stacked-qualified-types-3.c scan-assembler-times DIE \\([^\n]*\\) DW_TAG_(?:const|volatile|atomic|restrict)_type 8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=8 Andrew Pinski changed: What|Removed |Added Target Milestone|6.0 |--- Build|hppa64-hp-hpux11.11,| |*-*-solaris2.1[01], | |x86_64-unknown-linux-gnu| Summary|[6 regression] FAIL:|FAIL: |gcc.dg/debug/dwarf2/stacked |gcc.dg/debug/dwarf2/stacked |-qualified-types-3.c|-qualified-types-3.c |scan-assembler-times DIE|scan-assembler-times DIE |\\([^\n]*\\)|\\([^\n]*\\) |DW_TAG_(?:const|volatile|at |DW_TAG_(?:const|volatile|at |omic|restrict)_type 8 |omic|restrict)_type 8 Host|hppa64-hp-hpux11.11,| |*-*-solaris2.1[01], | |x86_64-unknown-linux-gnu|
[Bug bootstrap/67062] -no-pie check breaks cross compilation of GCC [OS X -> Windows]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67062 Andrew Pinski changed: What|Removed |Added Target Milestone|6.0 |---
[Bug target/51837] Use of result from 64*64->128 bit multiply via __uint128_t not optimized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51837 Andrew Pinski changed: What|Removed |Added Target Milestone|6.0 |---
[Bug c/49706] No warning for (!x > 1) which is always false
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49706 Andrew Pinski changed: What|Removed |Added Target Milestone|5.5 |---
[Bug target/66047] vlc compilation failure with target attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66047 Andrew Pinski changed: What|Removed |Added Target Milestone|5.5 |---
[Bug c++/57466] [DR 1584] Argument deduction fails for 'const T*' when T is function type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57466 Andrew Pinski changed: What|Removed |Added Target Milestone|5.5 |---
[Bug tree-optimization/63989] tree-ssa-strlen.c doesn't handle constant pointer plus and array refs if constant offset is smaller than known constant string length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63989 Andrew Pinski changed: What|Removed |Added Target Milestone|5.5 |--- Keywords||missed-optimization
[Bug c++/57868] misleading location for invalid variadic template
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57868 Andrew Pinski changed: What|Removed |Added Target Milestone|5.5 |---
[Bug ipa/65873] Failure to inline always_inline memcpy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65873 Andrew Pinski changed: What|Removed |Added Target Milestone|5.5 |---
[Bug target/56540] No __SIZEOF__XXX__ macro for __float128
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56540 Andrew Pinski changed: What|Removed |Added Target Milestone|5.5 |---
[Bug middle-end/44440] ira_initialization and buitins construction taking too much of startup time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=0 Andrew Pinski changed: What|Removed |Added Target Milestone|5.5 |--- Keywords||compile-time-hog
[Bug target/64331] regcprop propagates registers noted as REG_DEAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64331 Andrew Pinski changed: What|Removed |Added Target Milestone|5.5 |---
[Bug target/62631] gcc.dg/tree-ssa/ivopts-lt-2.c FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62631 Andrew Pinski changed: What|Removed |Added Target Milestone|5.5 |---
[Bug libbacktrace/89262] [libbacktrace] dwarf5 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89262 Andrew Pinski changed: What|Removed |Added Severity|enhancement |normal Resolution|--- |FIXED Target Milestone|10.2|10.0 Status|UNCONFIRMED |RESOLVED --- Comment #2 from Andrew Pinski --- r10-5447
[Bug tree-optimization/97405] ICE in get_or_alloc_expr_for in code hoisting with SVE intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97405 Andrew Pinski changed: What|Removed |Added Target Milestone|10.2|--- Last reconfirmed|2020-10-14 00:00:00 |2022-1-8 Known to fail||12.0
[Bug lto/48200] Implement function attribute for symbol versioning (.symver)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 Andrew Pinski changed: What|Removed |Added Target Milestone|10.0|---
[Bug c++/65861] libstdc++ is silently generating wrong code when its std::search is given an input iterator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65861 Andrew Pinski changed: What|Removed |Added Target Milestone|10.0|---
[Bug middle-end/87256] hppa spends huge amount of time in synth_mult()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87256 Andrew Pinski changed: What|Removed |Added Target Milestone|10.0|---
[Bug c/101478] [10/11/12 Regression] ICE on invalid code: recompute_tree_invariant_for_addr_expr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101478 Andrew Pinski changed: What|Removed |Added Target Milestone|10.0|10.4
[Bug tree-optimization/53947] [meta-bug] vectorizer missed-optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53947 Bug 53947 depends on bug 89028, which changed state. Bug 89028 Summary: 8-byte loop isn't vectorized https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89028 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug target/89028] 8-byte loop isn't vectorized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89028 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #4 from Andrew Pinski --- Fixed.
[Bug middle-end/92929] OpenACC/OpenMP 'target' 'exit data'/'update' optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92929 Andrew Pinski changed: What|Removed |Added Target Milestone|10.0|---
[Bug middle-end/95270] OpenACC 'enter data attach' looks up target memory object displaced by pointer size
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95270 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Target Milestone|10.0|10.2 Status|ASSIGNED|RESOLVED --- Comment #5 from Andrew Pinski --- Fixed.
gcc-11-20220108 is now available
Snapshot gcc-11-20220108 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20220108/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision 32d0d5fe3e522c18fc40109325f9dc055619cedc You'll find: gcc-11-20220108.tar.xz Complete GCC SHA256=a433837a85087c2357a456145ae140bd588e75d44a90031ed57c29de66e46468 SHA1=f89942362a87cb9c49f53177e7fcc57c77238197 Diffs from 11-20220101 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 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 c++/94061] defaulted member operator <=> defined as deleted if a base has protected member operator <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94061
--- Comment #3 from Frank Heckenbach ---
(In reply to Patrick Palka from comment #2)
> How do you define it? It works if we define it as
>
> auto operator <=> (const B& b) const {
> return A::operator<=>(b);
> }
>
> but not if it's defined as
>
> auto operator <=> (const B& b) const {
> return static_cast(*this) <=> static_cast(b);
> }
I'd do the former. I don't know what the standard says exactly, but intuitively
it seems to me that "protected" should suffice, also by comparison with
constructors.
Re: reordering of trapping operations and volatile
Am Samstag, den 08.01.2022, 10:35 -0800 schrieb Andrew Pinski:
> On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc wrote:
> >
> > Hi Richard,
> >
> > I have a question regarding reodering of volatile
> > accesses and trapping operations. My initial
> > assumption (and hope) was that compilers take
> > care to avoid creating traps that are incorrectly
> > ordered relative to observable behavior.
> >
> > I had trouble finding examples, and my cursory
> > glace at the code seemed to confirm that GCC
> > carefully avoids this. But then someone showed
> > me this example, where this can happen in GCC:
> >
> >
> > volatile int x;
> >
> > int foo(int a, int b, _Bool store_to_x)
> > {
> > if (!store_to_x)
> > return a / b;
> > x = b;
> > return a / b;
> > }
> >
> >
> > https://godbolt.org/z/vq3r8vjxr
>
> The question becomes what is a trapping instruction vs an undefined
> instruction?
> For floating point types, it is well defined what is a trapping
> instruction while for integer types it is not well defined.
> On some (many?) targets dividing by 0 is just undefined and does not
> trap (powerpc, aarch64, arm and many others; MIPS it depends on the
> options passed to GCC if the conditional trap should be inserted or
> not).
> The other side is if there is undefined code on the path, should
> observable results happen first (stores to volatile/atomics, etc.)?
I think for volatile stores and I/O, I think it would be
nice of we could guarantee that those happen before the UB
ruins the day. (I am not sure about atomics, those are
not directly obsevable)
For I/O this is probably already the case (?).
For volatile, it seems this would need some tweaks.
I am trying to figure out whether this is feasible.
> GCC assumes by default that divide is trappable but stores not are not
> observable. This is where -fnon-call-exceptions come into play.
Ok, thanks! I will look at this!
> In the second case, GCC assumes reducing trappable instructions are
> fine.
-fnon-call-exceptions would treat trapping instructions
as defined (and trapping) instead of UB? This is
then probably even stronger than the requirement above.
> Note I thought -fno-delete-dead-exceptions would fix the sink
> but it didn't.
Martin
[Bug c++/103769] [11/12 Regression] checking ICE in hashtab_chk_error with alias template and pack expansion after r11-7931
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103769
--- Comment #8 from Sergei Trofimovich ---
Slightly simpler executable example without recursion:
template using t = T;
template struct s {};
template s...> f() { return {};}
int main() { f(); }
[Bug fortran/83079] ICE in gfc_widechar_to_char, at fortran/scanner.c:198
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83079 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- The testcase in comment#0 is fixed by: diff --git a/gcc/fortran/target-memory.c b/gcc/fortran/target-memory.c index af1c21047f6..9b5af8d1482 100644 --- a/gcc/fortran/target-memory.c +++ b/gcc/fortran/target-memory.c @@ -485,7 +485,7 @@ gfc_interpret_character (unsigned char *buffer, size_t buffer_size, result->value.character.string[result->value.character.length] = '\0'; - return result->value.character.length; + return size_character (result->value.character.length, result->ts.kind); }
Re: [power-ieee128] OPEN CONV
On Sat, Jan 08, 2022 at 02:15:14PM -0500, David Edelsohn wrote: > On Sat, Jan 8, 2022 at 1:59 PM Michael Meissner > wrote: > > > > On Sat, Jan 08, 2022 at 03:18:07PM +0100, Jakub Jelinek wrote: > > > On Sat, Jan 08, 2022 at 03:13:10PM +0100, Thomas Koenig wrote: > > > > > > > > On 08.01.22 15:02, Jakub Jelinek via Fortran wrote: > > > > > Note, as for byteswapping, apparently it wasn't ever working right fox > > > > > the IBM extended real(kind=16) and complex(kind=16). > > > > > > > > The lack of bug reports since the conversion feature was introduced in > > > > 2006, more than 15 years ago, tells us something, I guess... > > > > > > powerpc64le was only introduced in GCC 4.8 in 2013, so slightly less > > > than that, but still. > > > Either nobody interchanges/shares fortran unformatted data between > > > powerpc big and little endian, or if they do, they don't use real(kind=16) > > > or complex(kind=16) in there... > > > > I still wish I had had the forethought when we were setting up the LE ABI to > > change the default 128-bit format to IEEE instead of IBM. But alas, I > > didn't. > > You would still need converters between the big endian IBM format and little > > endian IEEE format, but it would have avoided a lot of the problems where > > GCC > > assumes there is only one floating point format for each size. > > Mike, > > The LE ABI initial target was Power8 and IEEE128 hardware support was > added to Power9. The ABI was a conscious decision. IEEE 128 was not a > viable requirement for the LE ABI at the time of the transition. Yes I know, but my memory is we (the GCC group within IBM) at least knew that IEEE 128-bit was coming towards the end of the ABI definition period. But perhaps not. In any case, it doesn't much matter now, as it is all ancient history. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com
Re: [power-ieee128] OPEN CONV
On Sat, Jan 8, 2022 at 1:59 PM Michael Meissner wrote: > > On Sat, Jan 08, 2022 at 03:18:07PM +0100, Jakub Jelinek wrote: > > On Sat, Jan 08, 2022 at 03:13:10PM +0100, Thomas Koenig wrote: > > > > > > On 08.01.22 15:02, Jakub Jelinek via Fortran wrote: > > > > Note, as for byteswapping, apparently it wasn't ever working right fox > > > > the IBM extended real(kind=16) and complex(kind=16). > > > > > > The lack of bug reports since the conversion feature was introduced in > > > 2006, more than 15 years ago, tells us something, I guess... > > > > powerpc64le was only introduced in GCC 4.8 in 2013, so slightly less > > than that, but still. > > Either nobody interchanges/shares fortran unformatted data between > > powerpc big and little endian, or if they do, they don't use real(kind=16) > > or complex(kind=16) in there... > > I still wish I had had the forethought when we were setting up the LE ABI to > change the default 128-bit format to IEEE instead of IBM. But alas, I didn't. > You would still need converters between the big endian IBM format and little > endian IEEE format, but it would have avoided a lot of the problems where GCC > assumes there is only one floating point format for each size. Mike, The LE ABI initial target was Power8 and IEEE128 hardware support was added to Power9. The ABI was a conscious decision. IEEE 128 was not a viable requirement for the LE ABI at the time of the transition. Thanks, David
[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949 --- Comment #8 from Jörn Heusipp --- > Note in newer versions of glibc, libpthread is all intergrated into libc and > there is no issues again. > > For Mac OS X/darwin you don't need -lm -pthread because libc has it. Two examples where it works by chance is not sufficient to invalidate my point about the general case. > >gcc libstdc++ implements std::thread. So what's your point again? > > Because it implements it on top of pthreads. Yeah, so that is an implementation detail because of which I am required to pass -pthread. Why should the user of gcc even care how std::thread is implemented? It literally makes no sense. You are supporting my point. > While C threads is implemented > inside the libc. If it was implemented in libc, I would not be seeing "c11.c:(.text+0x53): undefined reference to `thrd_create'". Something is wrong with your argument. I actually do not know where it is implemented. And I should not be needing to know. Again, you are supporting my point. > If you want __STDC_NO_THREADS defined file a bug about that but gcc will need > to record which versions of glibc has C11 thread defined or not. The compiler is required to know that by the C standard. > You could use __has_include extension which will handle that mostly for you > really. That's not how the C standard specifies to do to check for thread support. > I still think this should not be done on the GCC side as it is > changing/fixing on the glibc side of things already. There are more platforms that GCC targets than just glibc. glibc alone cannot fix the general case. > In the case of mingw, the problem is how GCC was configured: Debian MinGW-w64 gcc is built in 2 flavours. One with Win32 and one with posix threading model support. The version with posix threading model support uses pthreads, and knows how to implement std::thread. Why is GCC assuming single-threaded in that context? That seems like a broken configuration to me that gcc should not allow to be buildable, which looks like a bug to me. (or I am misunderstanding what you are saying)
Re: [power-ieee128] OPEN CONV
On Sat, Jan 08, 2022 at 03:18:07PM +0100, Jakub Jelinek wrote: > On Sat, Jan 08, 2022 at 03:13:10PM +0100, Thomas Koenig wrote: > > > > On 08.01.22 15:02, Jakub Jelinek via Fortran wrote: > > > Note, as for byteswapping, apparently it wasn't ever working right fox > > > the IBM extended real(kind=16) and complex(kind=16). > > > > The lack of bug reports since the conversion feature was introduced in > > 2006, more than 15 years ago, tells us something, I guess... > > powerpc64le was only introduced in GCC 4.8 in 2013, so slightly less > than that, but still. > Either nobody interchanges/shares fortran unformatted data between > powerpc big and little endian, or if they do, they don't use real(kind=16) > or complex(kind=16) in there... I still wish I had had the forethought when we were setting up the LE ABI to change the default 128-bit format to IEEE instead of IBM. But alas, I didn't. You would still need converters between the big endian IBM format and little endian IEEE format, but it would have avoided a lot of the problems where GCC assumes there is only one floating point format for each size. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com
[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949 --- Comment #7 from Andreas Schwab --- This is only a matter of QoI and/or documentation.
[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949 --- Comment #6 from Andrew Pinski --- If you want __STDC_NO_THREADS defined file a bug about that but gcc will need to record which versions of glibc has C11 thread defined or not. You could use __has_include extension which will handle that mostly for you really.
[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949 --- Comment #5 from Andrew Pinski --- >You did not address any of the standard violating behavior concerning >advertising thread support at all. There is no standard violating behavior with respect to thread support. Again the C/C++ standard don't say how you invoke the compiler. POSIX has a section on that but as I mentioned that is a different story all together. In the case of mingw, the problem is how GCC was configured: #ifndef THREAD_MODEL_SPEC /* Targets that define THREAD_MODEL_SPEC need to define __STDCPP_THREADS__ in their config/XXX/XXX-c.c themselves. */ if (cxx_dialect >= cxx11 && strcmp (thread_model, "single") != 0) cpp_define (pfile, "__STDCPP_THREADS__=1"); #endif Which means add -mthread will not fix the issue there. You need to get a GCC which is configured correctly to not to be single threaded.
[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949 --- Comment #4 from Andrew Pinski --- Note in newer versions of glibc, libpthread is all intergrated into libc and there is no issues again. For Mac OS X/darwin you don't need -lm -pthread because libc has it. >gcc libstdc++ implements std::thread. So what's your point again? Because it implements it on top of pthreads. While C threads is implemented inside the libc. I still think this should not be done on the GCC side as it is changing/fixing on the glibc side of things already.
Re: reordering of trapping operations and volatile
On Sat, Jan 8, 2022 at 12:33 AM Martin Uecker via Gcc wrote:
>
>
> Hi Richard,
>
> I have a question regarding reodering of volatile
> accesses and trapping operations. My initial
> assumption (and hope) was that compilers take
> care to avoid creating traps that are incorrectly
> ordered relative to observable behavior.
>
> I had trouble finding examples, and my cursory
> glace at the code seemed to confirm that GCC
> carefully avoids this. But then someone showed
> me this example, where this can happen in GCC:
>
>
> volatile int x;
>
> int foo(int a, int b, _Bool store_to_x)
> {
> if (!store_to_x)
> return a / b;
> x = b;
> return a / b;
> }
>
>
> https://godbolt.org/z/vq3r8vjxr
The question becomes what is a trapping instruction vs an undefined instruction?
For floating point types, it is well defined what is a trapping
instruction while for integer types it is not well defined.
On some (many?) targets dividing by 0 is just undefined and does not
trap (powerpc, aarch64, arm and many others; MIPS it depends on the
options passed to GCC if the conditional trap should be inserted or
not).
The other side is if there is undefined code on the path, should
observable results happen first (stores to volatile/atomics, etc.)?
GCC assumes by default that divide is trappable but stores not are not
observable. This is where -fnon-call-exceptions come into play.
In the second case, GCC assumes reducing trappable instructions are
fine. Note I thought -fno-delete-dead-exceptions would fix the sink
but it didn't.
Thanks,
Andrew Pinski
>
> In this example a division is hoisted
> before the volatile store. (the division
> by zero which could trap is UB, of course).
>
> As Martin Sebor pointed out this is done
> as part of redundancy elimination
> in tree-ssa-pre.c and that this might
> simply be an oversight (and could then be
> fixed with a small change).
>
> Could you clarify whether such reordering
> is intentional and could be exploited in
> general also in other optimizations or
> confirm that this is an oversight that
> affects only this specific case?
>
> If this is intentional, are there examples
> where this is important for optimization?
>
>
> Martin
>
>
>
>
>
>
[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949 Jörn Heusipp changed: What|Removed |Added Status|RESOLVED|UNCONFIRMED Resolution|INVALID |--- --- Comment #3 from Jörn Heusipp --- > The c and c++ standard does not talks about how to invoke the compiler. POSIX > does but that is a different standard all together. I'm not asking gcc to implement whatever POSIX demands or deems reasonable from a C compiler. I am asking -std=c11, or -std=c++17, which are ISO standards, for which gcc by default only provides incomplete implementations while it would be actually easy to provide complete implementations, and that would simplify building. If the standard does not demand anything, why are you even linking libc by default then? There is no explanation or reasoning for the inconsistency between different aspects of the standard. > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358 This is exactly the same problem, and as https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81358#c2 Andreas Schwab said: "That doesn't mean that the mistake should be repeated." I very much agree. And I very much want to see the earlier mistakes repaired as well. Consider the atomics issue to be also required to fix in order to close this bug. > Also gcc implements the compiler, it is up to the other vendor to implement > the rest of the c library. Gcc does not implement printf either. gcc libstdc++ implements std::thread. So what's your point again? You did not address any of the standard violating behavior concerning advertising thread support at all. I did ask to not outright disregard this bug report. I suggest re-reading my report, and at least try to acknowledge my reasoning, and reconsider. Outright closing the bug feels just completely disrespectful. These broken and surprising defaults, and even more surprising differences between platforms that result from the broken defaults have cost the whole industry presumably multi-million-dollar figures of money over the last decade, and will continue to do so forever, if nothing gets actually fixed. And if you want to disregard that argument because I cannot prove it, fine. I myself have wasted probably days of my life with these quirks. I honestly cannot remember which platform wants -pthread, which platform needs -lpthreads, which platform needs -latomic, which platform wants -lm, which platform does not provide -lm at all. It's a complete mess, and gcc is in the position to fix it, because it *knows*. Changing back to UNCONFIRMED so that *other* people can have a look.
[Bug middle-end/103950] [9/10/11/12 Regression] printf("\xff") incorrectly optimized to putchar(-1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103950 --- Comment #4 from Andrew Pinski --- >That happens even if -funsigned-char is used. Yes because in this case, GCC is using char internally and forgetting it is signed by default when calling a function as shown by my patch.
[Bug middle-end/103950] [9/10/11/12 Regression] printf("\xff") incorrectly optimized to putchar(-1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103950
Andrew Pinski changed:
What|Removed |Added
Target Milestone|--- |9.5
Summary|printf("\xff") incorrectly |[9/10/11/12 Regression]
|optimized to putchar(-1)|printf("\xff") incorrectly
||optimized to putchar(-1)
Known to work||4.0.0
--- Comment #3 from Andrew Pinski ---
The optimization was introduced in r0-69361 and so it is a regression from GCC
4.0.0 and before.
I think the following will fix the issue:
apinski@xeond:~/src/upstream-gcc/gcc/gcc$ git diff gimple-fold.c
diff --git a/gcc/gimple-fold.c b/gcc/gimple-fold.c
index 77c551af942..6f158d301c5 100644
--- a/gcc/gimple-fold.c
+++ b/gcc/gimple-fold.c
@@ -3907,7 +3907,7 @@ gimple_fold_builtin_printf (gimple_stmt_iterator *gsi,
tree fmt,
/* Given printf("c"), (where c is any one character,)
convert "c"[0] to an int and pass that to the replacement
function. */
- newarg = build_int_cst (integer_type_node, str[0]);
+ newarg = build_int_cst (integer_type_node, (unsigned char)str[0]);
if (fn_putchar)
{
gcall *repl = gimple_build_call (fn_putchar, 1, newarg);
[Bug middle-end/103950] printf("\xff") incorrectly optimized to putchar(-1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103950
Andrew Pinski changed:
What|Removed |Added
Last reconfirmed||2022-01-08
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
Known to fail||4.1.2, 5.1.0
--- Comment #2 from Andrew Pinski ---
Confirmed.
Simplified testcase:
int main(void)
{
__builtin_printf("\xff");
}
[Bug driver/39439] The Driver hides "undefined reference" messages from shared libs (but not object files) in linker phase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=39439 --- Comment #5 from Andrew Pinski --- To clearify here, -shared and shared libraries in general accept undefined referneces while linking. You can change the behavior of that, if using GNU binutils, the option would be -Wl,--no-allow-shlib-undefined .
[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949 --- Comment #2 from Andrew Pinski --- Also gcc implements the compiler, it is up to the other vendor to implement the rest of the c library. Gcc does not implement printf either.
[Bug c/80528] reimplement gnulib's "useless-if-before-free" script as a compiler warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80528 Andrew Pinski changed: What|Removed |Added Severity|normal |enhancement
Re: reordering of trapping operations and volatile
> Most C programmers would assume that volatile accesses already > provides this guarantee, so actually doing so would be good. I'm a little skeptical of this statement: if it was true, how come the most recent version of the standard does not provide it 30 years after the language was first standardized? > Or a more practical example: While debugging some embedded > device, it would also be very annoying if the compilers reorders > some trap before some debugging output. I could easily imagine > loosing hours figuring out what happens. The thing to do to avoid losing these hours is to debug the code at -O0. -- Eric Botcazou
[Bug driver/103949] gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949 Andrew Pinski changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Andrew Pinski --- The c and c++ standard does not talks about how to invoke the compiler. POSIX does but that is a different standard all together.
[Bug c/103950] printf("\xff") incorrectly optimized to putchar(-1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103950
--- Comment #1 from Thorsten Otto ---
In gimple_fold_builtin_printf(), a call to printf() with a
single-character-string is optimized to putchar(). However that is also done
with non-ascii-characters, which in the case of printf("\ff") will call putchar
with a value of (-1) == EOF. That happens even if -funsigned-char is used.
[Bug c/103950] New: printf("\xff") incorrectly optimized to putchar(-1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103950
Bug ID: 103950
Summary: printf("\xff") incorrectly optimized to putchar(-1)
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: ad...@tho-otto.de
Target Milestone: ---
[Bug c++/103943] [11/12 Regression] ICE building qualified name inside class with variadic CTAD
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103943 Patrick Palka changed: What|Removed |Added CC||jason at gcc dot gnu.org, ||ppalka at gcc dot gnu.org Keywords|needs-bisection | --- Comment #2 from Patrick Palka --- Started with r11-2748
Re: reordering of trapping operations and volatile
Am Samstag, den 08.01.2022, 16:03 +0100 schrieb David Brown:
> On 08/01/2022 09:32, Martin Uecker via Gcc wrote:
> > Hi Richard,
> >
> > I have a question regarding reodering of volatile
> > accesses and trapping operations. My initial
> > assumption (and hope) was that compilers take
> > care to avoid creating traps that are incorrectly
> > ordered relative to observable behavior.
> >
> > I had trouble finding examples, and my cursory
> > glace at the code seemed to confirm that GCC
> > carefully avoids this. But then someone showed
> > me this example, where this can happen in GCC:
> >
> >
> > volatile int x;
> >
> > int foo(int a, int b, _Bool store_to_x)
> > {
> > if (!store_to_x)
> > return a / b;
> > x = b;
> > return a / b;
> > }
> >
> >
> > https://godbolt.org/z/vq3r8vjxr
> >
> > In this example a division is hoisted
> > before the volatile store. (the division
> > by zero which could trap is UB, of course).
> >
>
> Doesn't this depend on whether the trap is considered "observable
> behaviour", or "undefined behaviour" ?
>
> If (on the given target cpu and OS, and with any relevant compiler
> flags) dividing by zero is guaranteed to give a trap with specific known
> behaviour, then it is observable behaviour and thus should be ordered
> carefully with respect to the volatile accesses.
>
> On the other hand, if division by 0 is considered undefined behaviour
> (the C and C++ standards explicitly mark it as undefined, but a compiler
> can of course define its behaviour) then the compiler can assume it does
> not happen, or you don't care about the result of the program if it
> happens. Undefined behaviour can be freely re-ordered around volatile
> accesses, as far as I understand it - though that can come as a surprise
> to some people.
In C++ has wording that makes it clear that this reordering
is allowed. In C, some people also see it this way. In my
opinion, this is not clear and I always read the standard
in a different way (i.e. run-time UB happens at a point
in time but can not go backwards at change previous
defined behavior).
But in any case, I would find it much more useful if it is
guaranteed to not affect previous observable behavior.
This would make volatile more useful, which in my opinion
is preferable to introducing another language feature to
work around this issue.
This of course assumes that this reodering around volatile
accesses and I/O is not essential for optimization.
Martin
>
> I don't know which of these views gcc takes - I think both are valid.
> But it might be worth noting in the reference manual.
>
> David
>
>
>
> > As Martin Sebor pointed out this is done
> > as part of redundancy elimination
> > in tree-ssa-pre.c and that this might
> > simply be an oversight (and could then be
> > fixed with a small change).
> >
> > Could you clarify whether such reordering
> > is intentional and could be exploited in
> > general also in other optimizations or
> > confirm that this is an oversight that
> > affects only this specific case?
> >
> > If this is intentional, are there examples
> > where this is important for optimization?
> >
> >
> > Martin
> >
> >
> >
> >
> >
> >
> >
Re: Help with an ABI peculiarity
On 1/7/2022 2:55 PM, Paul Koning via Gcc wrote: On Jan 7, 2022, at 4:06 PM, Iain Sandoe wrote: Hi Folks, In the aarch64 Darwin ABI we have an unusual (OK, several unusual) feature of the calling convention. When an argument is passed *in a register* and it is integral and less than SI it is promoted (with appropriate signedness) to SI. This applies when the function parm is named only. When the same argument would be placed on the stack (i.e. we ran out of registers) - it occupies its natural size, and is naturally aligned (so, for instance, 3 QI values could be passed as 3 registers - promoted to SI .. or packed into three adjacent bytes on the stack).. The key is that we need to know that the argument will be placed in a register before we decide whether to promote it. (similarly, the promotion is not done in the callee for the in-register case). I am trying to figure out where to implement this. I don't remember the MIPS machinery well enough, but is that a similar case? It too has register arguments (4 or 8 of them) along with stack arguments (for the rest). Most targets these days use registers for parameter passing and obviously we can run out of registers on all of them. The key property is the size/alignment of the argument differs depending on if it's pass in a register (get promoted) or passed in memory (not promoted). I'm not immediately aware of another ABI with that feature. Though I haven't really gone looking. jeff
[Bug c++/94061] defaulted member operator <=> defined as deleted if a base has protected member operator <=>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94061
Patrick Palka changed:
What|Removed |Added
CC||ppalka at gcc dot gnu.org
--- Comment #2 from Patrick Palka ---
(In reply to Frank Heckenbach from comment #1)
> I ran into the same problem.
>
> Interestingly, clang also seems to reject it, so maybe it is wrong by the
> letter of the standard? Though it would seem strange to me -- after all,
> when manually implementing B::operator<=> a protected operator in A will do
> fine.
How do you define it? It works if we define it as
auto operator <=> (const B& b) const {
return A::operator<=>(b);
}
but not if it's defined as
auto operator <=> (const B& b) const {
return static_cast(*this) <=> static_cast(b);
}
According to [class.spaceship], IIUC the synthesized operator<=> looks more
similar to the latter invalid definition (invoking <=> recursively as an
operator expression on each pair of corresponding subobjects), so GCC/Clang
might be right to define it as deleted.
Re: [PATCH 1/1] [PATCH] Fix canadian compile for mingw-w64 copies the wrong dlls for mingw-w64 multilibs [PR100427]
On 1/8/2022 2:04 AM, NightStrike via Gcc-patches wrote: On Thu, Jan 6, 2022, 18:31 cqwrteur via Gcc-patches wrote: When building GCC hosted on windows with Canadian/native compilation (host==target), the build scripts in GCC would override DLLs with each other. For example, for MinGW-w64, 32-bit DLLs would override 64 bits because build scripts copy them both to /bin. This patch fixes the issue by avoiding copying DLLs with multilibs. However, it would still copy when we do not build multilibs, usually the native build for GCC on windows. --- gcc/configure | 26 ++ You should probably not be modifying configure directly. Umm, the patch modifies libtool.m4 (two instances) and presumably the configure changes are just rebuilds with the autotools. jeff
Re: [PATCH] gcc: pass-manager: Fix memory leak. [PR jit/63854]
On 1/6/2022 6:53 AM, David Malcolm via Gcc-patches wrote: On Sun, 2021-12-19 at 22:30 +0100, Marc Nieper-Wißkirchen wrote: This patch fixes a memory leak in the pass manager. In the existing code, the m_name_to_pass_map is allocated in pass_manager::register_pass_name, but never deallocated. This is fixed by adding a deletion in pass_manager::~pass_manager. Moreover the string keys in m_name_to_pass_map are all dynamically allocated. To free them, this patch adds a new hash trait for string hashes that are to be freed when the corresponding hash entry is removed. This fix is particularly relevant for using GCC as a library through libgccjit. The memory leak also occurs when libgccjit is instructed to use an external driver. Before the patch, compiling the hello world example of libgccjit with the external driver under Valgrind shows a loss of 12,611 (48 direct) bytes. After the patch, no memory leaks are reported anymore. (Memory leaks occurring when using the internal driver are mostly in the driver code in gcc/gcc.c and have to be fixed separately.) The patch has been tested by fully bootstrapping the compiler with the frontends C, C++, Fortran, LTO, ObjC, JIT and running the test suite under a x86_64-pc-linux-gnu host. Thanks for the patch. It looks correct to me, given that pass_manager::register_pass_name does an xstrdup and puts the result in the map. That said: - I'm not officially a reviewer for this part of gcc (though I probably touched this code last) - is it cleaner to instead change m_name_to_pass_map's key type from const char * to char *, to convey that the map "owns" the name? That way we probably wouldn't need struct typed_const_free_remove, and (I hope) works better with the type system. Dave gcc/ChangeLog: PR jit/63854 * hash-traits.h (struct typed_const_free_remove): New. (struct free_string_hash): New. * pass_manager.h: Use free_string_hash. * passes.c (pass_manager::register_pass_name): Use free_string_hash. (pass_manager::~pass_manager): Delete allocated m_name_to_pass_map. My concern (and what I hadn't had time to dig into) was we initially used nofree_string_hash -- I wanted to make sure there wasn't any path where the name came from the stack (can't be free'd), was saved elsewhere (danging pointer) and the like. ie, why were we using nofree_string_hash to begin with? I've never really mucked around with these bits, so the analysis side kept falling off the daily todo list. If/once you're comfortable with the patch David, then go ahead and apply it on Marc's behalf. jeff
Re: reordering of trapping operations and volatile
Am Samstag, den 08.01.2022, 15:41 +0100 schrieb Eric Botcazou: > > Yes, although I think potentially trapping ops > > are not moved before calls (as this would be > > incorrect). So do you think it would be feasable > > to prevent this for volatile too? > > Feasible probably, but why would this be desirable in C? It's not Java! It would allow us to still give at least some guarantees about the observable behavior of programs that later in their execution encounter UB (e.g. that an transaction with an external device is correctly completed). Considering the fact that it is virtually impossible to prove that any realistic C program is completely free of UB, this is would be very useful. As another example, there was recently the a proposal about adding a safe memory erasure function to the standard lib. It was pointed out that volatile stores would not be enough to be sure that the compiler safely erased some sensitive information, because an optimization based on later UB in the program could undo this. There is now also a proposal for C++ to introduce std::observable, which would require similar ordering constraints. But this would require the programmer to annotate the program correctly. Most C programmers would assume that volatile accesses already provides this guarantee, so actually doing so would be good. Or a more practical example: While debugging some embedded device, it would also be very annoying if the compilers reorders some trap before some debugging output. I could easily imagine loosing hours figuring out what happens. Martin
Re: reordering of trapping operations and volatile
On 08/01/2022 09:32, Martin Uecker via Gcc wrote:
>
> Hi Richard,
>
> I have a question regarding reodering of volatile
> accesses and trapping operations. My initial
> assumption (and hope) was that compilers take
> care to avoid creating traps that are incorrectly
> ordered relative to observable behavior.
>
> I had trouble finding examples, and my cursory
> glace at the code seemed to confirm that GCC
> carefully avoids this. But then someone showed
> me this example, where this can happen in GCC:
>
>
> volatile int x;
>
> int foo(int a, int b, _Bool store_to_x)
> {
> if (!store_to_x)
> return a / b;
> x = b;
> return a / b;
> }
>
>
> https://godbolt.org/z/vq3r8vjxr
>
> In this example a division is hoisted
> before the volatile store. (the division
> by zero which could trap is UB, of course).
>
Doesn't this depend on whether the trap is considered "observable
behaviour", or "undefined behaviour" ?
If (on the given target cpu and OS, and with any relevant compiler
flags) dividing by zero is guaranteed to give a trap with specific known
behaviour, then it is observable behaviour and thus should be ordered
carefully with respect to the volatile accesses.
On the other hand, if division by 0 is considered undefined behaviour
(the C and C++ standards explicitly mark it as undefined, but a compiler
can of course define its behaviour) then the compiler can assume it does
not happen, or you don't care about the result of the program if it
happens. Undefined behaviour can be freely re-ordered around volatile
accesses, as far as I understand it - though that can come as a surprise
to some people.
I don't know which of these views gcc takes - I think both are valid.
But it might be worth noting in the reference manual.
David
> As Martin Sebor pointed out this is done
> as part of redundancy elimination
> in tree-ssa-pre.c and that this might
> simply be an oversight (and could then be
> fixed with a small change).
>
> Could you clarify whether such reordering
> is intentional and could be exploited in
> general also in other optimizations or
> confirm that this is an oversight that
> affects only this specific case?
>
> If this is intentional, are there examples
> where this is important for optimization?
>
>
> Martin
>
>
>
>
>
>
>
[Bug driver/103949] New: gcc fails to provide a standard conforming C11 or C++17 environment even when specifying -std=c11 or -std=c++17
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103949
Bug ID: 103949
Summary: gcc fails to provide a standard conforming C11 or
C++17 environment even when specifying -std=c11 or
-std=c++17
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: driver
Assignee: unassigned at gcc dot gnu.org
Reporter: manx-bugzilla at problemloesungsmaschine dot de
Target Milestone: ---
Consider the following simple C11 program:
```
#include
#include
#include
#include
#include
#if !defined(__STDC_NO_THREADS)
#include
#endif
#if !defined(__STDC_NO_THREADS)
static int mythread(void * arg) {
int param = *(int*)arg;
double value = pow((double)param, (double)param);
printf("%f\n", value);
return 1;
}
bool test(int param) {
thrd_t t;
memset(, 0, sizeof(thrd_t));
if (thrd_create(, , ) != thrd_success) {
return false;
}
int result = 0;
if (thrd_join(t, ) != thrd_success) {
return false;
}
return (result != 0);
}
#else
bool test(int param) {
double value = pow((double)param, (double)param);
printf("%f\n", value);
return true;
}
#endif
int main(int argc, const char * argv []) {
(void)argv;
return test(argc) ? EXIT_SUCCESS : EXIT_FAILURE;
}
```
When I invoke `gcc -std=c11`, it fails to build the program:
```
manx@appendix:~/tmp$ gcc -std=c11 -O3 -Wall -Wextra -Wpedantic c11.c -o test
/usr/bin/ld: /tmp/ccxASC6u.o: in function `mythread':
c11.c:(.text+0x11): undefined reference to `pow'
/usr/bin/ld: /tmp/ccxASC6u.o: in function `test':
c11.c:(.text+0x53): undefined reference to `thrd_create'
/usr/bin/ld: c11.c:(.text+0x7b): undefined reference to `thrd_join'
collect2: error: ld returned 1 exit status
manx@appendix:~/tmp$
```
(gcc (Debian 11.2.0-13) 11.2.0 on a amd64 Debian Testing system, as of today).
It works when I invoke gcc as `gcc -std=c11 -pthread -lm`:
```
manx@appendix:~/tmp$ gcc -std=c11 -O3 -Wall -Wextra -Wpedantic c11.c -lm
-pthread -o test
manx@appendix:~/tmp$
```
Looking at C++, g++ is slightly better in that it does not barf for math,
however it also fails for threads:
```
manx@appendix:~/tmp$ cat cxx17.cpp
#if defined(__STDCPP_THREADS__) && (__STDCPP_THREADS__ == 1)
#include
#include
#include
static void mythread(double param) {
double value = std::pow(param, param);
std::cout << value << std::endl;
return;
}
bool test(int param) {
{
std::thread t{, static_cast(param)};
t.join();
}
return true;
}
int main(int argc, const char * argv []) {
static_cast(argv);
return test(argc) ? 0 : 1;
}
#else
#error "no threads"
#endif
manx@appendix:~/tmp$ g++ -std=c++17 -O3 -Wall -Wextra -Wpedantic cxx17.cpp -o
test
/usr/bin/ld: /tmp/cc1ItNk0.o: in function `test(int)':
cxx17.cpp:(.text+0xd7): undefined reference to `pthread_create'
collect2: error: ld returned 1 exit status
manx@appendix:~/tmp$ g++ -std=c++17 -O3 -Wall -Wextra -Wpedantic cxx17.cpp
-pthread -o test
manx@appendix:~/tmp$
```
For MinGW, it's just confused:
```
manx@appendix:~/tmp$ i686-w64-mingw32-g++-posix -std=c++17 -O3 -Wall -Wextra
-Wpedantic -mthreads cxx17.cpp -o test
cxx17.cpp:30:2: error: #error "no threads"
30 | #error "no threads"
| ^
manx@appendix:~/tmp$ i686-w64-mingw32-g++-posix -std=c++17 -O3 -Wall -Wextra
-Wpedantic -mthreads -D__STDCPP_THREADS__=1 cxx17.cpp -o test
manx@appendix:~/tmp$ i686-w64-mingw32-g++-posix --version
i686-w64-mingw32-g++-posix (GCC) 10-posix 20210110
Copyright (C) 2020 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
manx@appendix:~/tmp$
```
The C11 as well as the C++17 standards both include both, math and threads, yet
gcc fails to provide a complete implementation without adding baroque options.
Even more so, gcc *claims* to support threads, when it actually does not.
Now, I am aware of historic reasons why things came to be the way they
currently (which is ~50 years later) still are, however I completely fail to
see why it is really necessary to still complicate building standard conforming
programs for modern users. The original reasons are irrelevant to the common
case nowadays.
I am also aware of embedded situations where the fragmented behavior *could* be
desirable.
I therefore suggest:
1. Implicitly link anything mandated by the respective standard for a complete
implementation when the user requests standard-compliance via -std= switch.
2. Add compiler option -fno-math, which (optionally) cuts off linking some
standard libraries by default if possible on the respective platform.
3. Add compiler option
Re: reordering of trapping operations and volatile
> Yes, although I think potentially trapping ops > are not moved before calls (as this would be > incorrect). So do you think it would be feasable > to prevent this for volatile too? Feasible probably, but why would this be desirable in C? It's not Java! -- Eric Botcazou
Re: [power-ieee128] OPEN CONV
On Sat, Jan 08, 2022 at 03:13:10PM +0100, Thomas Koenig wrote: > > On 08.01.22 15:02, Jakub Jelinek via Fortran wrote: > > Note, as for byteswapping, apparently it wasn't ever working right fox > > the IBM extended real(kind=16) and complex(kind=16). > > The lack of bug reports since the conversion feature was introduced in > 2006, more than 15 years ago, tells us something, I guess... powerpc64le was only introduced in GCC 4.8 in 2013, so slightly less than that, but still. Either nobody interchanges/shares fortran unformatted data between powerpc big and little endian, or if they do, they don't use real(kind=16) or complex(kind=16) in there... Jakub
Re: [power-ieee128] OPEN CONV
On 08.01.22 15:02, Jakub Jelinek via Fortran wrote: Note, as for byteswapping, apparently it wasn't ever working right fox the IBM extended real(kind=16) and complex(kind=16). The lack of bug reports since the conversion feature was introduced in 2006, more than 15 years ago, tells us something, I guess...
Re: reordering of trapping operations and volatile
On Sat, 8 Jan 2022, Martin Uecker via Gcc wrote:
Am Samstag, den 08.01.2022, 13:41 +0100 schrieb Richard Biener:
On January 8, 2022 9:32:24 AM GMT+01:00, Martin Uecker
wrote:
Hi Richard,
thank you for your quick response!
I have a question regarding reodering of volatile
accesses and trapping operations. My initial
assumption (and hope) was that compilers take
care to avoid creating traps that are incorrectly
ordered relative to observable behavior.
I had trouble finding examples, and my cursory
glace at the code seemed to confirm that GCC
carefully avoids this. But then someone showed
me this example, where this can happen in GCC:
volatile int x;
int foo(int a, int b, _Bool store_to_x)
{
if (!store_to_x)
return a / b;
x = b;
return a / b;
}
https://godbolt.org/z/vq3r8vjxr
In this example a division is hoisted
before the volatile store. (the division
by zero which could trap is UB, of course).
As Martin Sebor pointed out this is done
as part of redundancy elimination
in tree-ssa-pre.c and that this might
simply be an oversight (and could then be
fixed with a small change).
Could you clarify whether such reordering
is intentional and could be exploited in
general also in other optimizations or
confirm that this is an oversight that
affects only this specific case?
If this is intentional, are there examples
where this is important for optimization?
In general there is no data flow information that
prevents traps from being reordered with respect
to volatile accesses.
Yes, although I think potentially trapping ops
are not moved before calls (as this would be
incorrect). So do you think it would be feasable
to prevent this for volatile too?
The specific case could be
easily mitigated in PRE. Another case would be
A = c / d;
X = 1;
If (use_a)
Bar (a);
Where we'd sink a across x into the guarded Bb I suspect.
Yes. Related example:
https://godbolt.org/z/5WGhadre3
volatile int x;
void bar(int a);
void foo(int c, int d)
{
int a = c / d;
x = 1;
if (d)
bar(a);
}
foo:
mov DWORD PTR x[rip], 1
testesi, esi
jne .L4
ret
.L4:
mov eax, edi
cdq
idivesi
mov edi, eax
jmp bar
It would be nice to prevent this too, although
I am less concerned about this direction, as
the UB has already happened so there is not
much we could guarantee about this anyway.
In the other case, it could affect correct
code before the trap.
-fnon-call-exceptions helps with the first testcase but not with the
second one. I don't know if that's by accident, but the flag seems
possibly relevant.
--
Marc Glisse
Re: [power-ieee128] OPEN CONV
On Sat, Jan 08, 2022 at 12:10:56PM +0100, Jakub Jelinek via Gcc-patches wrote:
> One reason for that is that neither conversion is lossless, neither format
> is a subset or superset of the other. Yes, IEEE quad has both much bigger
> exponent range (-16382..16383 vs. -1022..1023) and slightly bigger fixed
> precision (113 vs. 106 bits).
> But IBM extended has that weirdo numerically awful flexible precision where
> certain numbers can have much bigger precision than those 106 bits, up to
> 2048+52 or so. So there is rounding in both directions.
> So, after distros switch to -mabi=ieeelongdouble by default or when people
> use -mabi=ieeelongdouble on their programs, they'd better store that format
> into data files by default, without the need of some magic CONVERT= options,
> env vars or command line options. Only in the case where they need to
> interact with -mabi=ibmlongdouble environments, they need to take some
> action.
Note, as for byteswapping, apparently it wasn't ever working right fox
the IBM extended real(kind=16) and complex(kind=16).
Because unlike IEEE extended or integral types, it seems powerpc*-*-*
doesn't actually fully byteswap those between little and big endian.
Proof:
long double a =
0.L;
compiled little endian IBM long double:
.size a, 16
a:
.long 1431655765
.long 1070945621
.long 1431655766
.long 1014322517
compiled big endian IBM long double:
.size a, 16
a:
.long 1070945621
.long 1431655765
.long 1014322517
.long 1431655766
compiled little endian IEEE long double:
.size a, 16
a:
.long 1431655765
.long 1431655765
.long 1431655765
.long 1073567061
compiled big endian IEEE long double:
.size a, 16
a:
.long 1073567061
.long 1431655765
.long 1431655765
.long 1431655765
where the numbers in .long arguments are 32-bit numbers stored in the
selected endianity. Compiled with -mlong-double-64 little endian:
.size a, 8
a:
.long 1431655765
.long 1070945621
and big endian:
.size a, 8
a:
.long 1070945621
.long 1431655765
Unless I'm misreading this, for IEEE long double, or double (and I bet float
too) byteswapping the whole numbers is what is needed for interoperability
between powerpc64{,le}-linux, for IBM long double we'd actually want to
byteswap it as 2 real(kind=8) numbers and not one real(kind=16) one, i.e.
the numbers are always stored as the more significant double followed by
less significant double in memory.
Jakub
Re: reordering of trapping operations and volatile
Am Samstag, den 08.01.2022, 13:41 +0100 schrieb Richard Biener:
> On January 8, 2022 9:32:24 AM GMT+01:00, Martin Uecker
> wrote:
> > Hi Richard,
thank you for your quick response!
> > I have a question regarding reodering of volatile
> > accesses and trapping operations. My initial
> > assumption (and hope) was that compilers take
> > care to avoid creating traps that are incorrectly
> > ordered relative to observable behavior.
> >
> > I had trouble finding examples, and my cursory
> > glace at the code seemed to confirm that GCC
> > carefully avoids this. But then someone showed
> > me this example, where this can happen in GCC:
> >
> >
> > volatile int x;
> >
> > int foo(int a, int b, _Bool store_to_x)
> > {
> > if (!store_to_x)
> >return a / b;
> > x = b;
> > return a / b;
> > }
> >
> >
> > https://godbolt.org/z/vq3r8vjxr
> >
> > In this example a division is hoisted
> > before the volatile store. (the division
> > by zero which could trap is UB, of course).
> >
> > As Martin Sebor pointed out this is done
> > as part of redundancy elimination
> > in tree-ssa-pre.c and that this might
> > simply be an oversight (and could then be
> > fixed with a small change).
> >
> > Could you clarify whether such reordering
> > is intentional and could be exploited in
> > general also in other optimizations or
> > confirm that this is an oversight that
> > affects only this specific case?
> >
> > If this is intentional, are there examples
> > where this is important for optimization?
>
> In general there is no data flow information that
> prevents traps from being reordered with respect
> to volatile accesses.
Yes, although I think potentially trapping ops
are not moved before calls (as this would be
incorrect). So do you think it would be feasable
to prevent this for volatile too?
> The specific case could be
> easily mitigated in PRE. Another case would be
>
> A = c / d;
> X = 1;
> If (use_a)
> Bar (a);
>
> Where we'd sink a across x into the guarded Bb I suspect.
Yes. Related example:
https://godbolt.org/z/5WGhadre3
volatile int x;
void bar(int a);
void foo(int c, int d)
{
int a = c / d;
x = 1;
if (d)
bar(a);
}
foo:
mov DWORD PTR x[rip], 1
testesi, esi
jne .L4
ret
.L4:
mov eax, edi
cdq
idivesi
mov edi, eax
jmp bar
It would be nice to prevent this too, although
I am less concerned about this direction, as
the UB has already happened so there is not
much we could guarantee about this anyway.
In the other case, it could affect correct
code before the trap.
Martin
> (sorry for the odd formatting, writing this on a mobile device).
>
> Richard.
> > Martin
> >
> >
> >
> >
> >
> >
Re: reordering of trapping operations and volatile
On January 8, 2022 9:32:24 AM GMT+01:00, Martin Uecker
wrote:
>
>Hi Richard,
>
>I have a question regarding reodering of volatile
>accesses and trapping operations. My initial
>assumption (and hope) was that compilers take
>care to avoid creating traps that are incorrectly
>ordered relative to observable behavior.
>
>I had trouble finding examples, and my cursory
>glace at the code seemed to confirm that GCC
>carefully avoids this. But then someone showed
>me this example, where this can happen in GCC:
>
>
>volatile int x;
>
>int foo(int a, int b, _Bool store_to_x)
>{
> if (!store_to_x)
>return a / b;
> x = b;
> return a / b;
>}
>
>
>https://godbolt.org/z/vq3r8vjxr
>
>In this example a division is hoisted
>before the volatile store. (the division
>by zero which could trap is UB, of course).
>
>As Martin Sebor pointed out this is done
>as part of redundancy elimination
>in tree-ssa-pre.c and that this might
>simply be an oversight (and could then be
>fixed with a small change).
>
>Could you clarify whether such reordering
>is intentional and could be exploited in
>general also in other optimizations or
>confirm that this is an oversight that
>affects only this specific case?
>
>If this is intentional, are there examples
>where this is important for optimization?
In general there is no data flow information that prevents traps from being
reordered with respect to volatile accesses. The specific case could be easily
mitigated in PRE. Another case would be
A = c / d;
X = 1;
If (use_a)
Bar (a);
Where we'd sink a across x into the guarded Bb I suspect.
(sorry for the odd formatting, writing this on a mobile device).
Richard.
>
>Martin
>
>
>
>
>
>
[PATCH] nvptx: Improved support for HFMode including neghf2 and abshf2.
This patch adds more support for _Float16 (HFmode) to the nvptx backend.
Currently negation, absolute value and floating point comparisons are
implemented by promoting to float (SFmode). This patch adds suitable
define_insns to nvptx.md, most conditional on TARGET_SM53 (-misa=sm_53).
This patch also adds support for HFmode fused multiply-add.
One subtlety is that neghf2 and abshf2 are implemented by (HImode)
bit manipulation operations to update the sign bit. The NVidia PTX
ISA documentation for neg.f16 and abs.f16 contains the caution
"Future implementations may comply with the IEEE 754 standard by preserving
the (NaN) payload and modifying only the sign bit". Given the availability
of suitable replacements, I thought it best to provide IEEE 754 compliant
implementations. If anyone observes a performance penalty from this
choice I'm happy to provide a -ffast-math variant (or revisit this
decision).
This patch has been tested on nvptx-none hosted on x86_64-pc-linux-gnu
(including newlib) with a make and make -k check with no new failures.
Ok for mainline?
2022-01-08 Roger Sayle
gcc/ChangeLog
* config/nvptx/nvptx.md (*cmpf): New define_insn.
(cstorehf4): New define_expand.
(fmahf4): New define_insn.
(neghf2): New define_insn.
(abshf2): New define_insn.
gcc/testsuite/ChangeLog
* gcc.target/nvptx/float16-3.c: New test case for neghf2.
* gcc.target/nvptx/float16-4.c: New test case for abshf2.
* gcc.target/nvptx/float16-5.c: New test case for fmahf4.
* gcc.target/nvptx/float16-6.c: New test case.
Thanks in advance,
Roger
--
diff --git a/gcc/config/nvptx/nvptx.md b/gcc/config/nvptx/nvptx.md
index ce74672..a6046d7 100644
--- a/gcc/config/nvptx/nvptx.md
+++ b/gcc/config/nvptx/nvptx.md
@@ -779,6 +779,14 @@
""
"%.\\tsetp%c1\\t%0, %2, %3;")
+(define_insn "*cmphf"
+ [(set (match_operand:BI 0 "nvptx_register_operand" "=R")
+ (match_operator:BI 1 "nvptx_float_comparison_operator"
+ [(match_operand:HF 2 "nvptx_register_operand" "R")
+ (match_operand:HF 3 "nvptx_nonmemory_operand" "RF")]))]
+ "TARGET_SM53"
+ "%.\\tsetp%c1\\t%0, %2, %3;")
+
(define_insn "jump"
[(set (pc)
(label_ref (match_operand 0 "" "")))]
@@ -969,6 +977,21 @@
DONE;
})
+(define_expand "cstorehf4"
+ [(set (match_operand:SI 0 "nvptx_register_operand")
+ (match_operator:SI 1 "nvptx_float_comparison_operator"
+ [(match_operand:HF 2 "nvptx_register_operand")
+ (match_operand:HF 3 "nvptx_nonmemory_operand")]))]
+ "TARGET_SM53"
+{
+ rtx reg = gen_reg_rtx (BImode);
+ rtx cmp = gen_rtx_fmt_ee (GET_CODE (operands[1]), BImode,
+ operands[2], operands[3]);
+ emit_move_insn (reg, cmp);
+ emit_insn (gen_setccsi_from_bi (operands[0], reg));
+ DONE;
+})
+
;; Calls
(define_insn "call_insn_"
@@ -1156,6 +1179,26 @@
"TARGET_SM53"
"%.\\tmul.f16\\t%0, %1, %2;")
+(define_insn "fmahf4"
+ [(set (match_operand:HF 0 "nvptx_register_operand" "=R")
+ (fma:HF (match_operand:HF 1 "nvptx_register_operand" "R")
+ (match_operand:HF 2 "nvptx_nonmemory_operand" "RF")
+ (match_operand:HF 3 "nvptx_nonmemory_operand" "RF")))]
+ "TARGET_SM53"
+ "%.\\tfma%#.f16\\t%0, %1, %2, %3;")
+
+(define_insn "neghf2"
+ [(set (match_operand:HF 0 "nvptx_register_operand" "=R")
+ (neg:HF (match_operand:HF 1 "nvptx_register_operand" "R")))]
+ ""
+ "%.\\txor.b16\\t%0, %1, -32768;")
+
+(define_insn "abshf2"
+ [(set (match_operand:HF 0 "nvptx_register_operand" "=R")
+ (abs:HF (match_operand:HF 1 "nvptx_register_operand" "R")))]
+ ""
+ "%.\\tand.b16\\t%0, %1, 32767;")
+
(define_insn "exp2hf2"
[(set (match_operand:HF 0 "nvptx_register_operand" "=R")
(unspec:HF [(match_operand:HF 1 "nvptx_register_operand" "R")]
diff --git a/gcc/testsuite/gcc.target/nvptx/float16-3.c
b/gcc/testsuite/gcc.target/nvptx/float16-3.c
new file mode 100644
index 000..914282a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/nvptx/float16-3.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -misa=sm_53 -mptx=6.3" } */
+
+_Float16 var;
+
+void neg()
+{
+ var = -var;
+}
+
+/* { dg-final { scan-assembler "xor.b16" } } */
diff --git a/gcc/testsuite/gcc.target/nvptx/float16-4.c
b/gcc/testsuite/gcc.target/nvptx/float16-4.c
new file mode 100644
index 000..b11f17a
--- /dev/null
+++ b/gcc/testsuite/gcc.target/nvptx/float16-4.c
@@ -0,0 +1,11 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -misa=sm_53 -mptx=6.3 -ffast-math" } */
+
+_Float16 var;
+
+void foo()
+{
+ var = (var < (_Float16)0.0) ? -var : var;
+}
+
+/* { dg-final { scan-assembler "and.b16" } } */
diff --git a/gcc/testsuite/gcc.target/nvptx/float16-5.c
b/gcc/testsuite/gcc.target/nvptx/float16-5.c
new file mode 100644
index 000..5fe15ec
--- /dev/null
+++ b/gcc/testsuite/gcc.target/nvptx/float16-5.c
@@ -0,0 +1,14 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -misa=sm_53 -mptx=6.3
[Bug tree-optimization/103948] Vectorizer does not use vec_cmpMN without vcondMN pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103948 --- Comment #4 from Uroš Bizjak --- (In reply to Uroš Bizjak from comment #3) > diff --git a/gcc/optabs-tree.c b/gcc/optabs-tree.c > index 78e388d82f6..871366f3b7e 100644 > --- a/gcc/optabs-tree.c > +++ b/gcc/optabs-tree.c > @@ -502,6 +502,9 @@ expand_vec_cond_expr_p (tree value_type, tree > cmp_op_type, enum tree_code code) > cannot be certain whether a vector insn is available. */ > return false; > > + if (expand_vec_cmp_expr_p (value_type, cmp_op_type, code)) > +return true; > + >return vcond_icode_p (value_type, cmp_op_type, code) > || vcond_eq_icode_p (value_type, cmp_op_type, code); > } Well, this won't fly... I'll leave this to someone more knowledgeable with trees.
Re: [power-ieee128] OPEN CONV
On Sat, Jan 08, 2022 at 12:00:38PM +0100, Jakub Jelinek via Gcc-patches wrote: > And IMHO the default like for byte-swapping should be the native > format, i.e. the one the program actually used. One reason for that is that neither conversion is lossless, neither format is a subset or superset of the other. Yes, IEEE quad has both much bigger exponent range (-16382..16383 vs. -1022..1023) and slightly bigger fixed precision (113 vs. 106 bits). But IBM extended has that weirdo numerically awful flexible precision where certain numbers can have much bigger precision than those 106 bits, up to 2048+52 or so. So there is rounding in both directions. So, after distros switch to -mabi=ieeelongdouble by default or when people use -mabi=ieeelongdouble on their programs, they'd better store that format into data files by default, without the need of some magic CONVERT= options, env vars or command line options. Only in the case where they need to interact with -mabi=ibmlongdouble environments, they need to take some action. Jakub
Re: [Ada] Read directory in Ada.Directories.Start_Search rather than Get_Next_Entry
Hi Pierre-Marie, is this really a good idea? If a directory has millions of files in it (rare, but I've seen it) this may consume a lot of memory. Also, if using a slow medium like a network file system, reading the entire directory contents may take a long time. Finally, you aren't really solving the race condition, you're just making the window smaller, right? After all, if I understand right you are still using readdir, you just use it during a shorter time period. Best wishes, Duncan. On 07/01/2022 17:27, Pierre-Marie de Rodat via Gcc-patches wrote: The Ada.Directories directory search function is changed so the contents of the directory is now read in Start_Search instead of in Get_Next_Entry. Start_Search now stores the result of the directory search in the search object, with Get_Next_Entry returning results from the search object. This differs from the prior implementation where Get_Next_Entry would query the directory directly for the next item using the POSIX readdir function. The problem with building Get_Next_Entry around the readdir function is POSIX does not specify the behavior of readdir when files are added or removed from the directory being read. For example: on most systems, deleting files from the folder being read does not impact readdir. However, some systems, like RTEMS and HFS+ volumes on macOS, will return NULL instead of the next item in the directory if the current item returned by readdir is deleted. To avoid this issue, the contents of the directory is read in Start_Search and the user is given a copy of these results. Consequently, any subsequent modification to the directory does not affect the ability to iterate through the results. This approach is the same taken by the popular fts C functions. Tested on x86_64-pc-linux-gnu, committed on trunk gcc/ada/ * libgnat/a-direct.adb (Search_Data): Remove type. (Directory_Vectors): New package instantiation. (Search_State): New type. (Fetch_Next_Entry): Remove. (Close): Remove. (Finalize): Rewritten. (Full_Name): Ditto. (Get_Next_Entry): Return next entry from Search results vector rather than querying the directory directly using readdir. (Kind): Rewritten. (Modification_Time): Rewritten. (More_Entries): Use Search state cursor to determine if more entries are available for users to read. (Simple_Name): Rewritten. (Size): Rewritten. (Start_Search_Internal): Rewritten to load the contents of the directory that matches the pattern and filter into the search object. * libgnat/a-direct.ads (Search_Type): New type. (Search_Ptr): Ditto. (Directory_Entry_Type): Rewritten to support new Start_Search procedure. * libgnat/s-filatt.ads (File_Length_Attr): New function.
Re: [power-ieee128] OPEN CONV
On Sat, Jan 08, 2022 at 11:07:24AM +0100, Thomas Koenig wrote: > I have tried to unravel the different cases here, I count six > (lumping together the environment variables, the CONVERT specifier > and -fconvert, and leaving out the byte swapping) > > CompilerConvert Read action Write action > > IEEENone NoneNone > IEEEIEEE NoneNone > IEEEIBM IBM->IEEE IEEE->IBM > > IBM None NoneNone > IBM IEEE IEEE->IBM IBM->IEEE > IBM IBM NoneNone > > From this table, it is clear that the compiler has to inform > the library about the option it is using, I think it is best > encoded in the number passed to _gfortran_set_convert. Whether the compiler is using IEEE or IBM real(kind=16) or complex(kind=16) for a particular spot (which doesn't have to be the same in the whole program) is known to the library by the kind argument it provides to the I/O routines, if it is kind=16, it is IBM, if it is kind=17, it is IEEE. See the patch I've posted, which does one thing when the runtime kind (i.e. abi_kind on the compiler side) is 17 and convert says r16_ibm, and another thing when runtime kind is 16 and convert says r16_ieee. Other cases shouldn't need conversion. And IMHO the default like for byte-swapping should be the native format, i.e. the one the program actually used. The only thing that should be encoded in _gfortran_set_convert is -fconvertWHATEVER command line option IMO. Jakub
[Bug tree-optimization/103615] [9 Regression] wrong code with "-O3" or "-O1 -ftree-vectorize" on x86_64-pc-linux-gnu
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103615 Andrew Pinski changed: What|Removed |Added Target Milestone|9.4 |9.5
[Bug tree-optimization/68694] SLP loads should be permuted until supported if possible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68694 Andrew Pinski changed: What|Removed |Added Target Milestone|9.3 |--- Keywords||needs-bisection
[Bug tree-optimization/55288] Improve handling/suppression of maybe-uninitialized warnings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55288 Andrew Pinski changed: What|Removed |Added Target Milestone|4.9.0 |---
[Bug libstdc++/49745] error: ‘int truncate’ redeclared as different kind of symbol
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49745 Andrew Pinski changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED|RESOLVED --- Comment #25 from Andrew Pinski --- It was fixed in GCC 4.7.0, just the test case was failing with the newer glibc. The testcase was fixed so closing back as fixed for GCC 4.7.0.
[Bug tree-optimization/103948] Vectorizer does not use vec_cmpMN without vcondMN pattern
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103948 --- Comment #3 from Uroš Bizjak --- diff --git a/gcc/optabs-tree.c b/gcc/optabs-tree.c index 78e388d82f6..871366f3b7e 100644 --- a/gcc/optabs-tree.c +++ b/gcc/optabs-tree.c @@ -502,6 +502,9 @@ expand_vec_cond_expr_p (tree value_type, tree cmp_op_type, enum tree_code code) cannot be certain whether a vector insn is available. */ return false; + if (expand_vec_cmp_expr_p (value_type, cmp_op_type, code)) +return true; + return vcond_icode_p (value_type, cmp_op_type, code) || vcond_eq_icode_p (value_type, cmp_op_type, code); }
[Bug c++/41874] Incorrect "dereferencing type-punned pointer will break strict-aliasing rules" warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41874 Andrew Pinski changed: What|Removed |Added Target Milestone|4.5.0 |---
[Bug c++/26950] Error diagnostic not issued for unacceptable result of lookup for a name used in a nested-name-specifier
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=26950 Andrew Pinski changed: What|Removed |Added Target Milestone|4.4.0 |---
[Bug middle-end/95507] [meta-bug] bogus/missing -Wnonnull
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95507 Andrew Pinski changed: What|Removed |Added Target Milestone|3.3 |---
[Bug c++/96184] [11/12 Regression] GCC treats "use of local variable with automatic storage from containing function" differently in versions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96184 Andrew Pinski changed: What|Removed |Added Target Milestone|11.0|11.3
[Bug bootstrap/92680] PGO bootstrap is broken with --with-build-config=bootstrap-lto-lean and in-itree mpfr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92680 Andrew Pinski changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from Andrew Pinski --- Can you try again with the versions from ./contrib/download_prerequisites ?
