[Bug web/95165] New: Since 9.1 we do have ISO_Fortran_binding.h
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95165 Bug ID: 95165 Summary: Since 9.1 we do have ISO_Fortran_binding.h Product: gcc Version: 9.1.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: web Assignee: unassigned at gcc dot gnu.org Reporter: mcccs at gmx dot com Target Milestone: --- At https://gcc.gnu.org/onlinedocs/gfortran/Further-Interoperability-of-Fortran-with-C.html#Further-Interoperability-of-Fortran-with-C outdated statement: > GNU Fortran always uses an array descriptor, which does not match the one of > the Technical Specification. The ISO_Fortran_binding.h header file and the C > functions it specifies are not available. But in https://gcc.gnu.org/gcc-9/changes.html > C descriptors and the ISO_Fortran_binding.h source file have been > implemented.
[Bug target/93082] New: macOS Authorization.h needs fixinclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082
Bug ID: 93082
Summary: macOS Authorization.h needs fixinclude
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mcccs at gmx dot com
Target Milestone: ---
This bug has existed for at least two years.
In Authorization.h:
```
static const size_t kAuthorizationExternalFormLength = 32;
typedef struct {
char bytes[kAuthorizationExternalFormLength];
} AuthorizationExternalForm;
```
GCC prints this error:
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Security.framework/Headers/Authorization.h:193:7:
error: variably modified 'bytes' at file scope
(from gcc/c/c-decl.c Line 5792)
Clang (-Wall -Wextra): *Compiles without warning*
Clang (-Wall -Wextra -pedantic): warning: variable length array folded to
constant array as an extension [-Wgnu-folding-constant]
Impact: Golang's official compiler allows linking between C and Go. When I try
to build a Go package that imports "crypto/x509" (usually indirectly), part of
Go standard library on macOS, and `export CC=gcc-9` is set, Go returns the
following error:
# crypto/x509
In file included from
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Security.framework/Headers/AuthSession.h:32,
from
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Security.framework/Headers/Security.h:42,
from
/usr/local/Cellar/go/1.13.5/libexec/src/crypto/x509/root_cgo_darwin.go:17:
/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/System/Library/Frameworks/Security.framework/Headers/Authorization.h:193:7:
error: variably modified 'bytes' at file scope
193 | char bytes[kAuthorizationExternalFormLength];
| ^
Other than a fixinclude, there are other ways:
- Every time after an upgrade, open Authorization.h with sudo vim and replace
kAuthorizationExternalFormLength with 32
- Remove `export CC=gcc-9`
- Disable C-Go interlink (on by default)
A fixincludes entry would be quite clean:
fix = {
hackname = darwin_authorization;
mach = "*-*-darwin*";
files = Frameworks/Security.framework/Headers/Authorization.h;
select=
"char bytes[kAuthorizationExternalFormLength];\n";
c_fix = format;
c_fix_arg =
"char bytes[32];\n";
test_text =
"char bytes[kAuthorizationExternalFormLength];\n";
};
However, I can't test it due to PR90835.
[Bug target/93082] macOS Authorization.h needs fixinclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082
--- Comment #2 from mcccs at gmx dot com ---
Reported on the "other side" https://bugs.llvm.org/show_bug.cgi?id=44406
Changing it to enum works too, my only doubt is that it has a different width
and sign (but better than not compiling)
Updated patch, thank you Andrew:
fix = {
hackname = darwin_authorization;
mach = "*-*-darwin*";
files = Frameworks/Security.framework/Headers/Authorization.h;
select=
"static const size_t kAuthorizationExternalFormLength = 32;\n";
c_fix = format;
c_fix_arg =
"enum { kAuthorizationExternalFormLength = 32 };\n";
test_text =
"static const size_t kAuthorizationExternalFormLength = 32;\n";
};
[Bug target/88035] missing _mm512_reduce_round_pd() et al
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88035 MCCCS changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #1 from MCCCS --- Only the `_mm_` reduce-intrinsics don't exist. You can still call them from GCC by 1) Opening the table https://github.com/llvm-mirror/clang/blob/master/lib/Headers/avx512dqintrin.h 2) Ctrl + F for the function (e.g. _mm512_reduce_round_pd) 3) Call the function in the definition (e.g. __builtin_ia32_reducepd512_mask) But this is only a workaround, those `_mm_` functions/macros should be added, I agree.
[Bug c/88645] New: Don't assume functions are always nonnull if there's __attribute__((weak_import)), similar to __attribute__((weak))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88645
Bug ID: 88645
Summary: Don't assume functions are always nonnull if there's
__attribute__((weak_import)), similar to
__attribute__((weak))
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mcccs at gmx dot com
Target Milestone: ---
OS: Darwin/macOS
Test vector:
extern void a (void) __attribute__((weak_import));
int main(void) {
return !!a;
}
It shouldn't print a warning **iff** on macOS.
This warning:
warning: the address of 'void a()' will never be NULL [-Waddress]
The test would pass if it was __attribute__((weak)) instead of
__attribute__((weak_import))
The fix can be added to the `warn_for_null_address` function in gcc/cp/typeck.c
Aside from the warning, the assembly generation behavior is correct.
[Bug c/88645] Don't assume functions are always nonnull if there's __attribute__((weak_import)), similar to __attribute__((weak))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88645 --- Comment #1 from MCCCS --- Typo: fix can be added to "decl_with_nonnull_addr_p" of "/c-family/c-common.c" if anyone is interested.
[Bug c/88645] Don't assume functions are always nonnull if there's __attribute__((weak_import)), similar to __attribute__((weak))
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88645 MCCCS changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |INVALID --- Comment #2 from MCCCS --- *it works. This bug seemed to exit because of a missing weak_import in Apple's headers.
[Bug target/83531] Build broken on macOS 10.13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83531 MCCCS changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #2 from MCCCS --- The issue is caused by `os/availability.h` or `AvailabilityInternal.h`. Instead of `API_AVAILABLE`, only `__API_AVAILABLE` is defined (Clang defines both) This is also the cause of a few failing tests (g++.dg/other/darwin-cfstring1.C for example)
[Bug target/83531] Build broken on macOS 10.13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83531
--- Comment #4 from MCCCS ---
Iain could you please test if this patch works for you
too? If so, I'll send it as a patch tomorrow
(For me, it even fixes g++.dg/other/darwin-cfstring1.C):
Index: fixincludes/fixincl.x
===
--- fixincludes/fixincl.x (revision 267969)
+++ fixincludes/fixincl.x (working copy)
@@ -2,11 +2,11 @@
*
* DO NOT EDIT THIS FILE (fixincl.x)
*
- * It has been AutoGen-ed October 16, 2018 at 11:38:39 AM by AutoGen 5.18.7
+ * It has been AutoGen-ed January 16, 2019 at 07:37:22 PM by AutoGen 5.18.12
* From the definitionsinclhack.def
* and the template file fixincl
*/
-/* DO NOT SVN-MERGE THIS FILE, EITHER Tue Oct 16 11:38:39 CEST 2018
+/* DO NOT SVN-MERGE THIS FILE, EITHER Wed Jan 16 19:37:22 CEST 2019
*
* You must regenerate it. Use the ./genfixes script.
*
@@ -15,7 +15,7 @@
* certain ANSI-incompatible system header files which are fixed to work
* correctly with ANSI C and placed in a directory that GNU C will search.
*
- * This file contains 251 fixup descriptions.
+ * This file contains 252 fixup descriptions.
*
* See README for more information.
*
@@ -2636,6 +2636,56 @@ static const char* apzDarwin_AvailabilityinternalP
/* * * * * * * * * * * * * * * * * * * * * * * * * *
*
+ * Description of Darwin_Api_Availability fix
+ */
+tSCC zDarwin_Api_AvailabilityName[] =
+ "darwin_api_availability";
+
+/*
+ * File name selection pattern
+ */
+tSCC zDarwin_Api_AvailabilityList[] =
+ "os/availability.h\0";
+/*
+ * Machine/OS name selection pattern
+ */
+tSCC* apzDarwin_Api_AvailabilityMachs[] = {
+"*-*-darwin*",
+(const char*)NULL };
+
+/*
+ * content selection pattern - do fix if pattern found
+ */
+tSCC zDarwin_Api_AvailabilitySelect0[] =
+ " *#define __API_AVAILABLE.*\n\
+ *#define __API_DEPRECATED.*\n\
+ *#define __API_DEPRECATED_WITH_REPLACEMENT.*\n\
+ *#define __API_UNAVAILABLE.*\n";
+
+/*
+ * content bypass pattern - skip fix if pattern found
+ */
+tSCC zDarwin_Api_AvailabilityBypass0[] =
+ "__IPHONE_OS_VERSION_MIN_REQUIRED";
+
+#defineDARWIN_API_AVAILABILITY_TEST_CT 2
+static tTestDesc aDarwin_Api_AvailabilityTests[] = {
+ { TT_NEGREP, zDarwin_Api_AvailabilityBypass0, (regex_t*)NULL },
+ { TT_EGREP,zDarwin_Api_AvailabilitySelect0, (regex_t*)NULL }, };
+
+/*
+ * Fix Command Arguments for Darwin_Api_Availability
+ */
+static const char* apzDarwin_Api_AvailabilityPatch[] = {
+"format",
+"#define API_AVAILABLE(...)\n\
+#define API_DEPRECATED(...)\n\
+#define API_DEPRECATED_WITH_REPLACEMENT(...)\n\
+#define API_UNAVAILABLE(...)\n",
+(char*)NULL };
+
+/* * * * * * * * * * * * * * * * * * * * * * * * * *
+ *
* Description of Darwin_9_Long_Double_Funcs_2 fix
*/
tSCC zDarwin_9_Long_Double_Funcs_2Name[] =
@@ -10188,9 +10238,9 @@ static const char* apzX11_SprintfPatch[] = {
*
* List of all fixes
*/
-#define REGEX_COUNT 289
+#define REGEX_COUNT 291
#define MACH_LIST_SIZE_LIMIT 187
-#define FIX_COUNT251
+#define FIX_COUNT252
/*
* Enumerate the fixes
@@ -10258,6 +10308,7 @@ typedef enum {
CTRL_QUOTES_USE_FIXIDX,
CXX_UNREADY_FIXIDX,
DARWIN_AVAILABILITYINTERNAL_FIXIDX,
+DARWIN_API_AVAILABILITY_FIXIDX,
DARWIN_9_LONG_DOUBLE_FUNCS_2_FIXIDX,
DARWIN_EXTERNC_FIXIDX,
DARWIN_GCC4_BREAKAGE_FIXIDX,
@@ -10760,6 +10811,11 @@ tFixDesc fixDescList[ FIX_COUNT ] = {
DARWIN_AVAILABILITYINTERNAL_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE,
aDarwin_AvailabilityinternalTests, apzDarwin_AvailabilityinternalPatch,
0 },
+ { zDarwin_Api_AvailabilityName,zDarwin_Api_AvailabilityList,
+ apzDarwin_Api_AvailabilityMachs,
+ DARWIN_API_AVAILABILITY_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE,
+ aDarwin_Api_AvailabilityTests, apzDarwin_Api_AvailabilityPatch, 0 },
+
{ zDarwin_9_Long_Double_Funcs_2Name,zDarwin_9_Long_Double_Funcs_2List,
apzDarwin_9_Long_Double_Funcs_2Machs,
DARWIN_9_LONG_DOUBLE_FUNCS_2_TEST_CT, FD_MACH_ONLY | FD_SUBROUTINE,
Index: fixincludes/inclhack.def
===
--- fixincludes/inclhack.def(revision 267969)
+++ fixincludes/inclhack.def(working copy)
@@ -1298,6 +1298,33 @@ fix = {
};
/*
+ * macOS 10.13 and 10.14 forget to define API_AVAILABLE if
+ * __attribute__((availability)) is not supported.
+ */
+fix = {
+hackname = darwin_api_availability;
+mach = "*-*-darwin*";
+files = os/availability.h;
+bypass= "__IPHONE_OS_VERSION_MIN_REQUIRED";
+select=
+" *#define __API_AVAILABLE.*\n"
+" *#define __API_DEPRECATED.*\n"
+" *#define __API_DEPRECATED_WITH_REPLACEMENT.*\n"
+" *#define __API_UNAVAILABLE.*\n";
+c_fix = format;
+c_fix_arg =
+"#define API_AVAILABLE(...)\n"
+"#define API_DEPRECATE
[Bug target/83531] Build broken on macOS 10.13.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83531 --- Comment #6 from MCCCS --- After reading your comment, I noticed that there were two things I forgot to mention: 1 - availability.h is the file where "API_AVAILABLE" is defined for Clang. 2 - the part of the file the patch changes is 1:1 copied from AvailabilityInternal.h, so someone must've forgotten to replace after pasting. But yes, there's no need to hurry to fix it. It's existed since October 2017; no one has noticed.
[Bug tree-optimization/85971] New: Really Simple "If" with one function call inside is not optimized efficiently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85971
Bug ID: 85971
Summary: Really Simple "If" with one function call inside is
not optimized efficiently
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mcccs at gmx dot com
Target Milestone: ---
GCC: 8 or 9/trunk
Optimization: O3 or Ofast
Code:
```
int PolyMod(int s);
void CreateChecksum(int isTestNet, int *mod) {
if (isTestNet == 0) {
*mod = PolyMod(5);
} else {
*mod = PolyMod(9);
}
}
```
It is optimized very inefficiently. The
assembly has one branch.
However, if the compiler was as smart as the
people who develop it, he'd transform the code into
this:
```
int PolyMod(int s);
void CreateChecksum(int isTestNet, int *mod) {
int a;
if (isTestNet == 0) {
a = 5;
} else {
a = 9;
}
*mod = PolyMod(a);
}
```
which compiles to assembly with zero branches.
Another way to reach the same efficient assembly would be
```
int PolyMod(int s);
void CreateChecksum(int isTestNet, int *mod) {
*mod = PolyMod(isTestNet == 0 ? 5 : 9);
}
```
So, the compiler has problems seeing little powerful
argument optimizations.
[Bug tree-optimization/86136] New: Modular multiplication optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86136
Bug ID: 86136
Summary: Modular multiplication optimization
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mcccs at gmx dot com
Target Milestone: ---
Optimization: Ofast
GCC can't see that
(a * n) % k = (a * (n % k)) % k
(even) when n is known at compile time.
As a result,
int k (int a) {
return (a * t) % 5;
}
always gives a different assembly for t = 1, 2, ...
you can also replace 5 with any number
Play with it here: https://godbolt.org/g/HkyHqg
Clang has this bug too.
[Bug tree-optimization/86136] Modular multiplication optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86136 --- Comment #1 from MCCCS --- Note: It can notice (a * n) % k = 0 if n is a multiple of k. The bug happens only if n % k != 0.
[Bug c/86150] New: Trunk Segmentation Fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86150 Bug ID: 86150 Summary: Trunk Segmentation Fault Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c Assignee: unassigned at gcc dot gnu.org Reporter: mcccs at gmx dot com Target Milestone: --- This has been happening since ~5 days ago. -v output: Using built-in specs. COLLECT_GCC=/opt/compiler-explorer/gcc-snapshot/bin/g++ COLLECT_LTO_WRAPPER=/opt/compiler-explorer/gcc-trunk-20180611/bin/../libexec/gcc/x86_64-linux-gnu/9.0.0/lto-wrapper Target: x86_64-linux-gnu Configured with: ../gcc-trunk-20180611/configure --prefix=/opt/compiler-explorer/gcc-build/staging --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu --disable-bootstrap --enable-multiarch --with-abi=m64 --with-multilib-list=m32,m64,mx32 --enable-multilib --enable-clocale=gnu --enable-languages=c,c++,fortran --enable-ld=yes --enable-gold=yes --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id --enable-lto --enable-plugins --enable-threads=posix --with-pkgversion=GCC-Explorer-Build Thread model: posix gcc version 9.0.0 20180610 (experimental) (GCC-Explorer-Build) COLLECT_GCC_OPTIONS='-g' '-o' '/tmp/compiler-explorer-compiler118514-54-ka0j7a.n4wma/output.s' '-Wall' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /opt/compiler-explorer/gcc-trunk-20180611/bin/../libexec/gcc/x86_64-linux-gnu/9.0.0/cc1plus -quiet -v -imultiarch x86_64-linux-gnu -iprefix /opt/compiler-explorer/gcc-trunk-20180611/bin/../lib/gcc/x86_64-linux-gnu/9.0.0/ -D_GNU_SOURCE -quiet -dumpbase example.cpp -mtune=generic -march=x86-64 -auxbase example -g -Wall -version -o /tmp/cclN2skN.s GNU C++14 (GCC-Explorer-Build) version 9.0.0 20180610 (experimental) (x86_64-linux-gnu) compiled by GNU C version 7.3.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 ignoring nonexistent directory "/opt/compiler-explorer/gcc-trunk-20180611/bin/../lib/gcc/x86_64-linux-gnu/9.0.0/../../../../x86_64-linux-gnu/include" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20180611/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.0.0/../../../../include/c++/9.0.0" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20180611/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.0.0/../../../../include/c++/9.0.0/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20180611/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.0.0/../../../../include/c++/9.0.0/backward" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20180611/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.0.0/include" ignoring nonexistent directory "/usr/local/include/x86_64-linux-gnu" ignoring duplicate directory "/opt/compiler-explorer/gcc-trunk-20180611/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.0.0/include-fixed" ignoring nonexistent directory "/opt/compiler-explorer/gcc-trunk-20180611/bin/../lib/gcc/../../lib/gcc/x86_64-linux-gnu/9.0.0/../../../../x86_64-linux-gnu/include" ignoring duplicate directory "/usr/include/x86_64-linux-gnu" #include "..." search starts here: #include <...> search starts here: /usr/include/x86_64-linux-gnu /opt/compiler-explorer/gcc-trunk-20180611/bin/../lib/gcc/x86_64-linux-gnu/9.0.0/../../../../include/c++/9.0.0 /opt/compiler-explorer/gcc-trunk-20180611/bin/../lib/gcc/x86_64-linux-gnu/9.0.0/../../../../include/c++/9.0.0/x86_64-linux-gnu /opt/compiler-explorer/gcc-trunk-20180611/bin/../lib/gcc/x86_64-linux-gnu/9.0.0/../../../../include/c++/9.0.0/backward /opt/compiler-explorer/gcc-trunk-20180611/bin/../lib/gcc/x86_64-linux-gnu/9.0.0/include /opt/compiler-explorer/gcc-trunk-20180611/bin/../lib/gcc/x86_64-linux-gnu/9.0.0/include-fixed /usr/local/include /opt/compiler-explorer/gcc-trunk-20180611/bin/../lib/gcc/../../include /usr/include End of search list. GNU C++14 (GCC-Explorer-Build) version 9.0.0 20180610 (experimental) (x86_64-linux-gnu) compiled by GNU C version 7.3.0, GMP version 6.1.0, MPFR version 3.1.4, MPC version 1.0.3, isl version isl-0.18-GMP GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096 Compiler executable checksum: ee1f9e5f6ad5942fe2c52b4ffb2106ba COLLECT_GCC_OPTIONS='-g' '-o' '/tmp/compiler-explorer-compiler118514-54-ka0j7a.n4wma/output.s' '-Wall' '-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64' /opt/compiler-explorer/gcc-trunk-20180611/bin/../lib/gcc/x86_64-linux-gnu/9.0.0/../../../../x86_64-linux-gnu/bin/as -v --64 -o /tmp/ccQCpaIE.o /tmp/cclN2skN.s g++: in
[Bug tree-optimization/86136] Modular multiplication optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86136
--- Comment #3 from MCCCS ---
What about
unsigned int k (unsigned int a) {
if (a > 5) {
__builtin_unreachable();
}
return (a * 83) % 5;
}
[Bug middle-end/90348] Small inlined function has local variables in invalid stack location
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
MCCCS changed:
What|Removed |Added
CC||mcccs at gmx dot com
--- Comment #2 from MCCCS ---
/*Below's the compiler testsuite code with no headers.
Here's the assembly difference (because the difference is very small. The one
on the left works (-O1 only) while the one on the right has `-O1
-finline-small-functions`): https://www.diffchecker.com/hAYLeoPV
I've also tested it on macOS 10.14 with GCC 8, it failed too.
In addition, on Aarch64 - Raspberry/Raspbian using GCC 6 and GCC 9: GCC 9 also
failed on ARM, but GCC 6 didn't cause assertion fail, thus it's clearly a
7/8/9/10 regression.*/
/* { dg-do run } */
/* { dg-options "-O2" } */
void __attribute__ ((noinline)) set_one (unsigned char* ptr)
{
*ptr = 1;
}
int __attribute__ ((noinline)) check_nonzero (unsigned char const* in, unsigned
int len)
{
for (unsigned int i = 0; i < len; ++i) {
if (in[i] != 0) return 1;
}
return 0;
}
void set_one_on_stack () {
unsigned char buf[1];
set_one (buf);
}
int main () {
for (int i = 0; i < 5; ++i) {
unsigned char in[4];
for (int j = 0; j < i; ++j) {
in[j] = 0;
set_one_on_stack ();
}
if (check_nonzero (in, i)) {
__builtin_abort ();
}
}
}
//~ MCCCS (DesWurstes)
[Bug tree-optimization/86604] New: Compiler can't think of smaller variable ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86604
Bug ID: 86604
Summary: Compiler can't think of smaller variable ranges
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mcccs at gmx dot com
Target Milestone: ---
Summary: The compiler thinks variables as of the widest domain.
(32 bits for int, 64 bits for int64_t) It's possible to optimize
further by giving the compiler a hint about the domain. It can
be used to eliminate most of the branches.
For clarity, I'm going to define __builtin_guarantee first.
#define __builtin_guarantee(a) \
if (!(a)) {\
__builtin_unreachable(); \
}
The optimization: We can tell the compiler about the range
of a parameter, and it'll be able to use this knowledge
to eliminate most of the branches.
void CreateChecksum(int isTestNet, int *t) {
if (isTestNet == 0)
*t += 1;
}
Output with `-Ofast -march=native`:
CreateChecksum:
test edi, edi
jne .L3
inc DWORD PTR [rsi]
.L3:
ret
But if we could do that:
void CreateChecksum(int isTestNet, int *t) {
__builtin_guarantee(isTestNet == 0 || isTestNet == 1);
if (isTestNet == 0)
*t += 1;
}
It'd see that
*t += isTestNet ^ 1
But for some reason, Compiler doesn't limit the number of
possibilities of variables according to builtin unreachable.
[Bug tree-optimization/86710] New: 3 missing logarithm optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86710 Bug ID: 86710 Summary: 3 missing logarithm optimizations Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: mcccs at gmx dot com Target Milestone: --- I've looked at match.pd, and spotted missing properties of logarithm. I could poorly write the code for two, still needs to check that the log base is the same: (for logs (LOG LOG2 LOG10) /* logN(a) + logN(b) -> logN(a * b). */ (simplify (plus (logs (@0)) (logs (@1))) (logs (mult:c (@0) (@1 (for logs (LOG LOG2 LOG10) /* logN(a) - logN(b) -> logN(a / b). */ (simplify (sub (logs (@0)) (logs (@1))) (logs (rdiv (@0) (@1 I couldn't code the last one /* logN(b)/logN(a) * logN(c)/logN(b) -> logN(c)/logN(a). */ Here are the test cases: 1: https://godbolt.org/g/boqxQb 2: https://godbolt.org/g/m7zHxK 3: https://godbolt.org/g/KXrbV4
[Bug tree-optimization/87009] New: Can't find XOR pattern applying De Morgan sequentially
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87009
Bug ID: 87009
Summary: Can't find XOR pattern applying De Morgan sequentially
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mcccs at gmx dot com
Target Milestone: ---
Optimization: -Ofast
Suggested debugging layout: https://godbolt.org/g/ERWctt
int xor_int(int a, int b) {
...
}
Don't work:
int x = ~(a|b);
return ~(x|a)|~(x|b);
return ~(~(a|b)|a)|~(~(a|b)|b);
int x = ~a&~b;
return ~((x|a)&(x|b));
return ~(((~a&~b)|a)&((~a&~b)|b));
int x = ~a&~b;
return ~(x|a)|~(x|b);
return ~((~a&~b)|a)|~((~a&~b)|b);
int x = ~a&~b;
return (~x&~a)|(~x&~b);
int x = ~a&~b;
return ~x&(~a|~b);
Those two work:
return (~(~a&~b)&~a)|(~(~a&~b)&~b);
return ~(~a&~b)&(~a|~b);
A different calculation:
Don't work:
return ~(~(~a&b)&~(a&~b));
return ~(~(~a|~b)|~(a|b));
return ~((a&b)|~(a|b));
This works:
return ~(a&b)&(a|b);
Different calculation:
return ~((a|~b)&(~a|b));
return ~(a|~b)|~(~a|b);
return (~a&b)|~(~a|b);
This works:
return (~a&b)|(a&~b);
SUGGESTED SOLUTTION
At match.pd:774 There's the De Morgan law
for bitwise AND but there isn't one for OR.
https://github.com/gcc-mirror/gcc/blob/fe4311f/gcc/match.pd#L774
No one noticed this, because it can (somehow) transform ~(~a|b) to a&~b
sometimes, (for example, if BMI instructions is enabled, it can use the 'andn'
instruction which calculates a&~b) If I understand it correctly, it only works
if it's not simplified a different way until RTL optimization comes.
/* ~(~a | b) --> a & ~b */
(simplify
(bit_not (bit_ior:cs (bit_not @0) @1))
(bit_and @0 (bit_not @1)))
[Bug tree-optimization/87009] Can't find XOR pattern applying De Morgan sequentially
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87009
--- Comment #1 from MCCCS ---
Proposed patch:
Index: gcc/match.pd
===
--- gcc/match.pd(revision 263646)
+++ gcc/match.pd(working copy)
@@ -776,6 +776,11 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(bit_not (bit_and:cs (bit_not @0) @1))
(bit_ior @0 (bit_not @1)))
+/* ~(~a | b) --> a & ~b */
+(simplify
+ (bit_not (bit_ior:cs (bit_not @0) @1))
+ (bit_and @0 (bit_not @1)))
+
/* Simplify (~X & Y) to X ^ Y if we know that (X & ~Y) is 0. */
#if GIMPLE
(simplify
Index: gcc/testsuite/g++.dg/pr87009.C
===
--- gcc/testsuite/g++.dg/pr87009.C (nonexistent)
+++ gcc/testsuite/g++.dg/pr87009.C (working copy)
@@ -0,0 +1,18 @@
+/* { dg-do compile } */
+/* { dg-options "-O2 -fdump-tree-original" } */
+/* { dg-final { scan-tree-dump-times " ^ " 3 "original" } */
+
+int f1 (int x, int s)
+{
+ return ~(~(x|s)|x)|~(~(x|s)|s);
+}
+
+int f2 (int x, int s)
+{
+ return ~(~(~x&s)&~(x&~s));
+}
+
+int f3 (int x, int s)
+{
+ return ~((x|~s)&(~x|s));
+}
[Bug tree-optimization/87186] New: Does not inline constant to sim
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87186 Bug ID: 87186 Summary: Does not inline constant to sim Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: mcccs at gmx dot com Target Milestone: ---
[Bug tree-optimization/87186] Does not inline constant to simplify bitwise expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87186 --- Comment #1 from MCCCS --- It can simplify ~(~(x|s)|x)|~(~(x|s)|s) to s^x but it can't simplify const int t = x|s; ~(~t|x)|~(~t|s) or const int t = ~(x|s); ~(t|x)|~(t|s) or const int t = ~x&~s; ~(t|x)|~(t|s)
[Bug tree-optimization/87186] Does not inline constant to simplify bitwise expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87186
--- Comment #4 from MCCCS ---
Flags: -O2 -fdump-tree-original
Code:
int f1 (int x, int s) {
return ~(~(x|s)|x)|~(~(x|s)|s);
}
int f2 (int x, int s) {
const int t = x|s;
return ~(~t|x)|~(~t|s);
}
int f3 (int x, int s) {
const int t = ~(x|s);
return ~(t|x)|~(t|s);
}
int f4 (int x, int s) {
const int t = ~x&~s;
return ~(t|x)|~(t|s);
}
Tree output (f1 has the expected output, others
should have had the same output):
;; Function f1 (null)
;; enabled by -tree-original
{
return s ^ x;
}
;; Function f2 (null)
;; enabled by -tree-original
{
const int t = x | s;
const int t = x | s;
return ~((int) ~t | x & s);
}
;; Function f3 (null)
;; enabled by -tree-original
{
const int t = ~(x | s);
const int t = ~(x | s);
return ~(x & s | (int) t);
}
;; Function f4 (null)
;; enabled by -tree-original
{
const int t = ~(x | s);
const int t = ~(x | s);
return ~(x & s | (int) t);
}
[Bug tree-optimization/87261] New: Optimize bool expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87261 Bug ID: 87261 Summary: Optimize bool expressions Product: gcc Version: 9.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: tree-optimization Assignee: unassigned at gcc dot gnu.org Reporter: mcccs at gmx dot com Target Milestone: --- (~x & y) | ~(x | y) (x | y) ^ (x | ~y) (x & y) | ~(x | y) (~x | y) ^ (x ^ y) (x ^ y) | ~(x | y) Patch ready, will send it soon. Submitted here to reserve a `prABCDE.c` file in gcc.dg.
[Bug rtl-optimization/85283] New: Generates 20 lines of assembly while only one assembly instruction is enough.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85283
Bug ID: 85283
Summary: Generates 20 lines of assembly while only one assembly
instruction is enough.
Product: gcc
Version: 8.0.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mcccs at gmx dot com
Target Milestone: ---
GCC version: trunk/20180407 (also older versions)
Target: x86_64-linux-gnu
Compile options: -Ofast -mavx2 -mfma -Wall -Wextra -Wpedantic
Build options: --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu --disable-bootstrap --enable-multiarch --with-abi=m64
--with-multilib-list=m32,m64,mx32 --enable-multilib --enable-clocale=gnu
--enable-languages=c,c++,fortran --enable-ld=yes --enable-gold=yes
--enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-linker-build-id
--enable-lto --enable-plugins --enable-threads=posix
--with-pkgversion=GCC-Explorer-Build
The exact code (no #include s):
typedef struct {
float x, y;
} Vec2;
Vec2 vec2_add(Vec2 a, Vec2 b) {
Vec2 out = {a.x + b.x,
a.y + b.y};
return out;
}
Produced assembly with line numbers:
1 vec2_add:
2 vmovq rcx, xmm0
3 vmovq rsi, xmm1
...
21 vmovq xmm0, QWORD PTR [rsp-24]
22 ret
Expected assembly (as compiled by Clang 6.0 with -Ofast -mavx2 -mfma):
1 vec2_add: # @vec2_add
2 vaddps xmm0, xmm1, xmm0
3 ret
(Yes, only three lines)
^^
(These can be experimented here: https://godbolt.org/g/tTwusV)
See also (for other inefficiencies): https://godbolt.org/g/AtWNgf
[Bug web/87829] New: Contradiction about -fReorder-Blocks
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87829
Bug ID: 87829
Summary: Contradiction about -fReorder-Blocks
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: web
Assignee: unassigned at gcc dot gnu.org
Reporter: mcccs at gmx dot com
Target Milestone: ---
On this page: https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
(invoke.texi)
It says:
@option{-Os} disables the following optimization flags:
@gccoptlist{-falign-functions -falign-jumps -falign-loops @gol
-falign-labels -freorder-blocks -freorder-blocks-algorithm=stc @gol
-freorder-blocks-and-partition -fprefetch-loop-arrays}
If you scroll down, it says:
@item -freorder-blocks
@opindex freorder-blocks
Reorder basic blocks in the compiled function in order to reduce number of
taken branches and improve code locality.
Enabled at levels @option{-O}, @option{-O2}, @option{-O3}, @option{-Os}.
Is it enabled in -Os or not? They contradict.
Also for -freorder-blocks-algorithm and -freorder-blocks-and-partition
[Bug d/87876] New: Mac failing: conversion from longdouble to long int is ambiguous
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87876
Bug ID: 87876
Summary: Mac failing: conversion from longdouble to long int is
ambiguous
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: d
Assignee: ibuclaw at gdcproject dot org
Reporter: mcccs at gmx dot com
Target Milestone: ---
macOS 10.14.1
compiled with GCC 8.2
/Users/username/Downloads/gcc-trunk/gcc/d/dmd/constfold.c:1162:50: error:
conversion from 'real_t' {aka 'longdouble'} to 'sinteger_t' {aka 'long int'} is
ambiguous
result = (d_int8)(sinteger_t)r;
^
In file included from
/Users/username/Downloads/gcc-trunk/gcc/d/dmd/root/ctfloat.h:11,
from
/Users/username/Downloads/gcc-trunk/gcc/d/dmd/globals.h:14,
from
/Users/username/Downloads/gcc-trunk/gcc/d/dmd/errors.h:13,
from
/Users/username/Downloads/gcc-trunk/gcc/d/dmd/constfold.c:22:
/Users/username/Downloads/gcc-trunk/gcc/d/longdouble.h:54:3: note: candidate:
'longdouble::operator int32_t()'
operator int32_t (void)
^~~~
/Users/username/Downloads/gcc-trunk/gcc/d/longdouble.h:57:3: note: candidate:
'longdouble::operator int64_t()'
operator int64_t (void)
^~~~
/Users/username/Downloads/gcc-trunk/gcc/d/longdouble.h:60:3: note: candidate:
'longdouble::operator uint32_t()'
operator uint32_t (void)
^~~~
/Users/username/Downloads/gcc-trunk/gcc/d/longdouble.h:63:3: note: candidate:
'longdouble::operator uint64_t()'
operator uint64_t (void)
^~~~
/Users/username/Downloads/gcc-trunk/gcc/d/longdouble.h:66:3: note: candidate:
'longdouble::operator bool()'
operator bool (void)
^~~~
/Users/username/Downloads/gcc-trunk/gcc/d/dmd/constfold.c:1166:50: error:
conversion from 'real_t' {aka 'longdouble'} to 'dinteger_t' {aka 'long unsigned
int'} is ambiguous
result = (d_uns8)(dinteger_t)r;
^
In file included from
/Users/username/Downloads/gcc-trunk/gcc/d/dmd/root/ctfloat.h:11,
from
/Users/username/Downloads/gcc-trunk/gcc/d/dmd/globals.h:14,
from
/Users/username/Downloads/gcc-trunk/gcc/d/dmd/errors.h:13,
from
/Users/username/Downloads/gcc-trunk/gcc/d/dmd/constfold.c:22:
/Users/username/Downloads/gcc-trunk/gcc/d/longdouble.h:54:3: note: candidate:
'longdouble::operator int32_t()'
operator int32_t (void)
^~~~
/Users/username/Downloads/gcc-trunk/gcc/d/longdouble.h:57:3: note: candidate:
'longdouble::operator int64_t()'
operator int64_t (void)
^~~~
/Users/username/Downloads/gcc-trunk/gcc/d/longdouble.h:60:3: note: candidate:
'longdouble::operator uint32_t()'
operator uint32_t (void)
^~~~
/Users/username/Downloads/gcc-trunk/gcc/d/longdouble.h:63:3: note: candidate:
'longdouble::operator uint64_t()'
operator uint64_t (void)
^~~~
/Users/username/Downloads/gcc-trunk/gcc/d/longdouble.h:66:3: note: candidate:
'longdouble::operator bool()'
operator bool (void)
^~~~
/Users/username/Downloads/gcc-trunk/gcc/d/dmd/constfold.c:1169:51: error:
conversion from 'real_t' {aka 'longdouble'} to 'sinteger_t' {aka 'long int'} is
ambiguous
result = (d_int16)(sinteger_t)r;
^
In file included from
/Users/username/Downloads/gcc-trunk/gcc/d/dmd/root/ctfloat.h:11,
from
/Users/username/Downloads/gcc-trunk/gcc/d/dmd/globals.h:14,
from
/Users/username/Downloads/gcc-trunk/gcc/d/dmd/errors.h:13,
from
/Users/username/Downloads/gcc-trunk/gcc/d/dmd/constfold.c:22:
/Users/username/Downloads/gcc-trunk/gcc/d/longdouble.h:54:3: note: candidate:
'longdouble::operator int32_t()'
operator int32_t (void)
^~~~
/Users/username/Downloads/gcc-trunk/gcc/d/longdouble.h:57:3: note: candidate:
'longdouble::operator int64_t()'
operator int64_t (void)
^~~~
/Users/username/Downloads/gcc-trunk/gcc/d/longdouble.h:60:3: note: candidate:
'longdouble::operator uint32_t()'
operator uint32_t (void)
^~~~
/Users/username/Downloads/gcc-trunk/gcc/d/longdouble.h:63:3: note: candidate:
'longdouble::operator uint64_t()'
operator uint64_t (void)
^~~~
/Users/username/Downloads/gcc-trunk/gcc/d/longdouble.h:66:3: note: candidate:
'longdouble::operator bool()'
operator bool (void)
^~~~
/Users/username/Downloads/gcc-trunk/gcc/d/dmd/constfold.c:1173:51: error:
conversion from 'real_t' {aka 'longdouble'} to 'dinteger_t' {aka '
[Bug bootstrap/87788] [9 Regression] Bootstrap fails for x86_64-apple-darwin* with default languages selection after D addition.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87788 --- Comment #16 from MCCCS --- Hi, could you please change the component from "bootstrap" to "d" ? The same error occurs during non-bootstrap compiling too. Otherwise this is in the wrong category, people might not see this and send duplicates.
[Bug tree-optimization/88014] New: Restrict/C2X/N2260 Restricted function argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88014
Bug ID: 88014
Summary: Restrict/C2X/N2260 Restricted function argument
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mcccs at gmx dot com
Target Milestone: ---
N2260 ( http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2260.pdf )
has been integrated to C2X, according to
https://gustedt.wordpress.com/2018/11/12/c2x/ .
Code taken from the paper above:
#include
void g(int **a, int *b)
{
*a = b;
}
int foo(int * restrict p, int *q)
{
g(&q, p); // effectively q = p
*p = 1;
*q = 2;
return *p + *q;
}
int main()
{
int x, y;
printf("%d", foo(&x, &y));
return 0;
}
Args: -O0
Result: 4 (correct)
Args: -fno-inline -O3
Result: 3 (incorrect)
[Bug target/88353] New: AVX512 instructions on macOS using Xcode Clang's assembler needs extra flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88353
Bug ID: 88353
Summary: AVX512 instructions on macOS using Xcode Clang's
assembler needs extra flags
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mcccs at gmx dot com
Target Milestone: ---
Note: You can skip to the tldr.
#include
int main(void) {
__m512i a;
a = _mm512_conflict_epi32(a);
return (int)a[1];
}
$ gcc-8 -mavx512cd /Users/usr/Downloads/k.c -v
Last login: Tue Dec 4 17:14:01 on ttys000
usr:~ usr$ cd /Users/usr/Downloads
usr:Downloads usr$ gcc-8 -mavx512cd /Users/usr/Downloads/k.c -v
Using built-in specs.
COLLECT_GCC=gcc-8
COLLECT_LTO_WRAPPER=/usr/local/Cellar/gcc/8.2.0/libexec/gcc/x86_64-apple-darwin18.0.0/8.2.0/lto-wrapper
Target: x86_64-apple-darwin18.0.0
Configured with: ../configure --build=x86_64-apple-darwin18.0.0
--prefix=/usr/local/Cellar/gcc/8.2.0
--libdir=/usr/local/Cellar/gcc/8.2.0/lib/gcc/8
--enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-8
--with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr
--with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl
--with-system-zlib --enable-checking=release --with-pkgversion='Homebrew GCC
8.2.0' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues
--disable-nls --disable-multilib --with-native-system-header-dir=/usr/include
--with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
Thread model: posix
gcc version 8.2.0 (Homebrew GCC 8.2.0)
COLLECT_GCC_OPTIONS='-mavx512cd' '-v' '-mmacosx-version-min=10.14.0'
'-asm_macosx_version_min=10.14' '-mtune=core2'
/usr/local/Cellar/gcc/8.2.0/libexec/gcc/x86_64-apple-darwin18.0.0/8.2.0/cc1
-quiet -v -D__DYNAMIC__ /Users/usr/Downloads/k.c -fPIC -quiet -dumpbase k.c
-mavx512cd -mmacosx-version-min=10.14.0 -mtune=core2 -auxbase k -version -o
/var/folders/rj/2dy816nd25b86ywkrrgv2ms4gn/T//ccP9tvXX.s
GNU C17 (Homebrew GCC 8.2.0) version 8.2.0 (x86_64-apple-darwin18.0.0)
compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.20-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/local/include"
ignoring nonexistent directory
"/usr/local/Cellar/gcc/8.2.0/lib/gcc/8/gcc/x86_64-apple-darwin18.0.0/8.2.0/../../../../../../x86_64-apple-darwin18.0.0/include"
ignoring nonexistent directory
"/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/Library/Frameworks"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/Cellar/gcc/8.2.0/lib/gcc/8/gcc/x86_64-apple-darwin18.0.0/8.2.0/include
/usr/local/Cellar/gcc/8.2.0/lib/gcc/8/gcc/x86_64-apple-darwin18.0.0/8.2.0/include-fixed
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/usr/include
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk/System/Library/Frameworks
End of search list.
GNU C17 (Homebrew GCC 8.2.0) version 8.2.0 (x86_64-apple-darwin18.0.0)
compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version 4.0.1,
MPC version 1.1.0, isl version isl-0.20-GMP
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 66326856387bebccbffed284b95b1664
COLLECT_GCC_OPTIONS='-mavx512cd' '-v' '-mmacosx-version-min=10.14.0'
'-mtune=core2'
as -arch x86_64 -v -force_cpusubtype_ALL -mmacosx-version-min=10.14 -o
/var/folders/rj/2dy816nd25b86ywkrrgv2ms4gn/T//ccZala60.o
/var/folders/rj/2dy816nd25b86ywkrrgv2ms4gn/T//ccP9tvXX.s
Apple LLVM version 10.0.0 (clang-1000.11.45.5)
Target: x86_64-apple-darwin18.2.0
Thread model: posix
InstalledDir:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
"/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/clang"
-cc1as -triple x86_64-apple-macosx10.14.0 -filetype obj -main-file-name
ccP9tvXX.s -target-cpu penryn -fdebug-compilation-dir /Users/usr/Downloads
-dwarf-debug-producer Apple LLVM version 10.0.0 (clang-1000.11.45.5)
-dwarf-version=4 -mrelocation-model pic -o
/var/folders/rj/2dy816nd25b86ywkrrgv2ms4gn/T//ccZala60.o
/var/folders/rj/2dy816nd25b86ywkrrgv2ms4gn/T//ccP9tvXX.s
/var/folders/rj/2dy816nd25b86ywkrrgv2ms4gn/T//ccP9tvXX.s:11:2: error:
instruction requires: AVX-512 ISA
vmovdqa64 -120(%rsp), %zmm0
^
/var/folders/rj/2dy816nd25b86ywkrrgv2ms4gn
[Bug target/86393] GCC-8 appears to not detect AVX512 on iMac Pro 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86393 MCCCS changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #5 from MCCCS --- *** Bug 88353 has been marked as a duplicate of this bug. ***
[Bug target/88353] AVX512 instructions on macOS using Xcode Clang's assembler needs extra flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88353 MCCCS changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #2 from MCCCS --- Duplicate of 86393 *** This bug has been marked as a duplicate of bug 86393 ***
[Bug target/86393] GCC-8 appears to not detect AVX512 on iMac Pro 2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86393 --- Comment #7 from MCCCS --- The problem was that the LLVM assembler required -mavx512f. I've researched it and found that this LLVM bug was fixed months and shipped with LLVM 7. Apple updates Xcode's LLVM with one year delay, and it should be fixed the next year with 10.15. To sum up: this is llvm 6 bug https://bugs.llvm.org/show_bug.cgi?id=36202 https://llvm.org/viewvc/llvm-project?view=revision&revision=324106
[Bug target/93082] macOS Authorization.h needs fixinclude
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93082 --- Comment #4 from mcccs at gmx dot com --- (In reply to Fabian Groffen from comment #3) > The problem with this snippet is that it doesn't work on Frameworks, does > it? At least for me, it seems it searches from usr/include only? I'm not sure but it sounds likely. Isn't usr/include the higher-priority #include <...> search directory?
[Bug tree-optimization/86604] phiopt missed optimization of conditional add
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86604 mcccs at gmx dot com changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from mcccs at gmx dot com --- Sure, let's not dereference pointers. *** This bug has been marked as a duplicate of bug 103216 ***
[Bug tree-optimization/103216] missed optimization, phiopt/vrp?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103216 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #8 from mcccs at gmx dot com --- *** Bug 86604 has been marked as a duplicate of this bug. ***
[Bug target/119626] On aarch64, use the bfcvt instruction to cast to __bf16 when target supports it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119626
--- Comment #6 from mcccs at gmx dot com ---
Lastly I would like to mention why this is such an important issue in the use
__bf16 and why __bf16 is otherwise very inefficient: bfcvt is not only used for
casts. Consider the following code:
__bf16 a[4];
void multiply() {
for (int i = 0; i < 4; i++)
a[i] *= 16;
}
It does involve the bfcvt instruction.
The function compiles to:
Clang O3 -bf16: 13 instructions
Clang O3 +bf16: 8 instructions
GCC O3 +bf16: 43 instructions
It seems there are two parts to solving the problem. By comparing with Clang,
first is to ensure
__bf16 convert(float x) {
return (__bf16) x;
}
uses bfcvt
the second is to ensure
void convert2(float * __restrict a, __bf16 * __restrict x) {
for (int i = 0; i < 4; i++)
x[i] = (__bf16)a[i];
}
can be vectorized even with march=...-bf16
[Bug target/119626] On aarch64, use the bfcvt instruction to cast to __bf16 when target supports it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119626
--- Comment #5 from mcccs at gmx dot com ---
Sorry for another ping. I did some more research and to make it easier for you
to confirm this issue, we can confirm the expected behavior with clang:
Clang behavior -march=armv9-a+bf16 -O3:
void convert1(int * __restrict a, __bf16 * __restrict x) {
for (int i = 0; i < 4; i++)
x[i] = (__bf16)a[i];
}
void convert2(float * __restrict a, __bf16 * __restrict x) {
for (int i = 0; i < 4; i++)
x[i] = (__bf16)a[i];
}
produces:
convert1(int*, __bf16*):
ldr q0, [x0]
scvtf v0.4s, v0.4s
bfcvtn v0.4h, v0.4s
str d0, [x1]
ret
convert2(float*, __bf16*):
ldr q0, [x0]
bfcvtn v0.4h, v0.4s
str d0, [x1]
ret
whereas with GCC the produced assembly is not only not using bfcvt, it is also
unvectorized. So Clang without `+bf16` can vectorize it but GCC can't. Maybe
this should be split into two separate bugs (one for vectorizing it with
`-bf16` and one for using the bfcvt instruction if `+bf16`).
[Bug target/119626] On aarch64, use the bfcvt instruction to cast to __bf16 when target supports it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119626 --- Comment #7 from mcccs at gmx dot com --- Today Microsoft Copilot wrongly quoted what I earlier said (bots are reading these threads), so I need to fix my mistake for anyone reading this thread: If you want to allow the compiler to use the bfcvt instruction on Arm, use the argument -march=armv9.1-a or -march=armv8.6-a or -march=armv[any version]+bf16 not +fp16! FP16 is not BF16
[Bug target/119678] New: FreeBSD RISC-V broken due to single-char typo in macro FBSD_LINK_PG_NOTES
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119678 Bug ID: 119678 Summary: FreeBSD RISC-V broken due to single-char typo in macro FBSD_LINK_PG_NOTES Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: mcccs at gmx dot com Target Milestone: --- https://github.com/gcc-mirror/gcc/pull/108 has found out that the commit https://github.com/gcc-mirror/gcc/commit/48abb540701447b0cd9df7542720ab65a34fc1b1 has a typo that gcc/config/riscv/freebsd.h refers to FBSD_LINK_PG_NOTES, which is undefined instead of FBSD_LINK_PG_NOTE
[Bug tree-optimization/119706] [15 regression] ICE in gimple pass 'dom' for -O3 -mcpu=grace --param=aarch64-autovec-preference=sve-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119706 --- Comment #4 from mcccs at gmx dot com --- Created attachment 61059 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61059&action=edit This is a reduced testcase, but modified in a way that it gives an error in VRP stage instead of DOM While minimizing the testcase, this source code fails in the VRP stage instead of DOM, which might make it a good testcase. To make it fail again in the DOM stage, add "noexcept" back to "cr cb()"
[Bug tree-optimization/119706] [15 regression] ICE in gimple pass 'dom' for -O3 -mcpu=grace --param=aarch64-autovec-preference=sve-only
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119706 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #2 from mcccs at gmx dot com --- O2 doesn't cause ICE but O3 does because of -fvect-cost-model=dynamic
[Bug tree-optimization/86136] Modular multiplication optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86136 mcccs at gmx dot com changed: What|Removed |Added Resolution|--- |WONTFIX Status|NEW |RESOLVED --- Comment #5 from mcccs at gmx dot com --- I think this can be closed. most cases would be unable to apply this due to overflow; even in the case of no overflow, it won't result in much speedup.
[Bug bootstrap/119663] Can't build GCC on aarch64-apple-darwin24.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119663 --- Comment #1 from mcccs at gmx dot com --- version: trunk
[Bug target/119663] Can't build GCC on aarch64-apple-darwin24.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119663 --- Comment #2 from mcccs at gmx dot com --- Right, latest macOS 15.4 which is darwin24.4.0 neither works
[Bug bootstrap/119663] New: Can't build GCC on aarch64-apple-darwin24.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119663 Bug ID: 119663 Summary: Can't build GCC on aarch64-apple-darwin24.3.0 Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: bootstrap Assignee: unassigned at gcc dot gnu.org Reporter: mcccs at gmx dot com Target Milestone: --- On macos 15.3.1 (I'll make another comment down if 15.4 is no different), where uname -r says 24.3.0 configure says: *** Configuration aarch64-apple-darwin24.3.0 not supported configuring with ./configure --with-gmp=/opt/homebrew/Cellar/gmp/6.3.0 --with-mpfr=/opt/homebrew/Cellar/mpfr/4.2.2 --with-mpc=/opt/homebrew/Cellar/libmpc/1.3.1
[Bug target/119663] Can't build GCC on aarch64-apple-darwin24.3.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119663 --- Comment #3 from mcccs at gmx dot com --- *typo: configure does succeed, it is from `make` that: *** Configuration aarch64-apple-darwin24.4.0 not supported
[Bug other/119729] New: GCC does not issue a warning for in-tree building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119729 Bug ID: 119729 Summary: GCC does not issue a warning for in-tree building Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other Assignee: unassigned at gcc dot gnu.org Reporter: mcccs at gmx dot com Target Milestone: --- it would save time for contributors if GCC could detect that you're building inside the directory and ask you to cd to a different directory and build there and refer to documentation for details
[Bug bootstrap/119729] configure should issue a warning about building in the src tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119729 --- Comment #3 from mcccs at gmx dot com --- > If it is refusing ./configure, why not. When doing ./configure a very ugly bug today in `configure` didn't allow me to compile, we can just forbid this. So if you agree I'll edit the title from "warn" to "error on", please revert if you disagree
[Bug tree-optimization/119552] New: Deduplicate __divmodbitint4 calls for quotient and remainder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119552
Bug ID: 119552
Summary: Deduplicate __divmodbitint4 calls for quotient and
remainder
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: mcccs at gmx dot com
Target Milestone: ---
_BitInt(1280) a, b, c, d;
void divide() {
c = a/b;
d = a%b;
}
calls __divmodbitint4 twice
Relevant bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=43721
[Bug tree-optimization/119552] Deduplicate __divmodbitint4 calls for quotient and remainder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119552 mcccs at gmx dot com changed: What|Removed |Added Keywords||missed-optimization --- Comment #1 from mcccs at gmx dot com --- on both x86 and arm64
[Bug target/119626] New: Use bfcvt arm instruction to cast to __bf16 when ARM target supports it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119626
Bug ID: 119626
Summary: Use bfcvt arm instruction to cast to __bf16 when ARM
target supports it
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: mcccs at gmx dot com
Target Milestone: ---
__bf16 convert1(int a) {
return (__bf16) a;
}
__bf16 convert2(float a) {
return (__bf16) a;
}
compiled with -march=armv9-a+fp16 -Ofast
should make use of bfcvt instruction when available, it's slower otherwise
[Bug target/119626] On ARM, use the bfcvt instruction to cast to __bf16 when target supports it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119626
mcccs at gmx dot com changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED|UNCONFIRMED
--- Comment #2 from mcccs at gmx dot com ---
Nor does the following use bfcvt:
void convert1(int a, int b, int c, int d, __bf16 *x) {
x[0] = (__bf16)a;
x[1] = (__bf16)b;
x[2] = (__bf16)c;
x[3] = (__bf16)d;
}
void convert1(float a, float b, float c, float d, __bf16 *x) {
x[0] = (__bf16)a;
x[1] = (__bf16)b;
x[2] = (__bf16)c;
x[3] = (__bf16)d;
}
This seems to be a bug?
[Bug target/119626] On ARM, use the bfcvt instruction to cast to __bf16 when target supports it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119626 mcccs at gmx dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution|--- |FIXED --- Comment #1 from mcccs at gmx dot com --- Sorry it's not a vector so GCC is doing the right thing
[Bug target/119626] On ARM, use the bfcvt instruction to cast to __bf16 when target supports it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119626 mcccs at gmx dot com changed: What|Removed |Added Resolution|FIXED |INVALID
[Bug target/119626] On ARM, use the bfcvt instruction to cast to __bf16 when target supports it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119626
--- Comment #3 from mcccs at gmx dot com ---
Sorry for so many pings, the final code is:
void convert1(int * __restrict a, __bf16 * __restrict x) {
x[0] = (__bf16)a[0];
x[1] = (__bf16)a[1];
x[2] = (__bf16)a[2];
x[3] = (__bf16)a[3];
}
void convert2(float * __restrict a, __bf16 * __restrict x) {
x[0] = (__bf16)a[0];
x[1] = (__bf16)a[1];
x[2] = (__bf16)a[2];
x[3] = (__bf16)a[3];
}
[Bug tree-optimization/119778] [13/14/15 regression] -Wuninitialized crashed with longjmp/setjmp
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119778 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #6 from mcccs at gmx dot com --- Bisecting on GCC 13 branch (13.2-13.3) points at https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5ee6e01fba873580f0ee6c88a3f733e79af2e8a3 Can 13.1 (and 13.2) be moved to "known to work" please? This can be verified on Compiler Explorer (I bisected with the original attachment, by the time I started apinski didn't have uploaded the reductions)
[Bug other/105404] Update in-tree copy of zlib to zlib-1.3.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105404 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #13 from mcccs at gmx dot com --- It would be great to upgrade to zlib 1.3.1 for Mac users as well. I failed to build from Iain's branch with both Apple and LLVM clang (latest CLT, macOS 15.4) because zlib earlier than 1.3.1 can't be built on this configuration with these compilers (see https://github.com/ahrm/sioyek/issues/1361) (Surprisingly Iain failed to reproduce this on his system x86). This can be patched separately (https://github.com/iains/gcc-14-branch/pull/22/files) but a direct upgrade to v1.3.1 or later would be simpler.
[Bug ipa/115767] [12/13/14/15 regression] GCC loses track of value on aarch64 with -O2 since r11-3308-gd119f34c952f87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115767 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #25 from mcccs at gmx dot com --- I used creduce and some de-namespacing and brought it to about 60k lines, I hope to post the checkpoint soon
[Bug ipa/115767] [12/13/14/15 regression] GCC loses track of value on aarch64 with -O2 since r11-3308-gd119f34c952f87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115767 --- Comment #27 from mcccs at gmx dot com --- *sorry I meant 60k bytes not lines
[Bug bootstrap/119729] configure should issue a warning about building in the src tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119729 --- Comment #4 from mcccs at gmx dot com --- Suggested patch: +if test $srcdir = . ; then + AC_MSG_ERROR([building in the top level project directory is not supported. Please change the current directory to a new directory (can be a new subdirectory of the project root)]) +fi just above "# Find the build and target subdir names." in top-level configure.ac
[Bug middle-end/110282] Segmentation fault with specific optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110282
--- Comment #10 from mcccs at gmx dot com ---
Bad commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ff6686d2e5f797d6c6a36ad14a7084bc1dc350e4
Minimal testcase:
int a[];
short b, c;
long d;
__attribute__((noipa)) long(e)() {}
static int f(int *g) { char h = b < *g | c <= e(d); }
int main() { f(a); }
-O3 -fno-dce -fno-ipa-cp -fno-tree-dce -fno-tree-sink
Reproducible on arm as well - different "optimized" pass output
Known to work 9.5.0 as well
[Bug middle-end/110282] Segmentation fault with specific optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110282 --- Comment #12 from mcccs at gmx dot com --- Thanks Sam, I'm restarting reduction this time checking if it compiles with trunk GCC as well
[Bug middle-end/110282] Segmentation fault with specific optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110282
--- Comment #14 from mcccs at gmx dot com ---
Minimized testcase:
int a[], d[];
long b, c, e, g;
int f, h, i;
short j, k, l;
int *m = a;
static int *n(int *o) {
int p = l == *o | k <= j;
p = *d;
h = c;
g = 0 == e;
f = *m;
b = 0;
return &i;
}
int main() { n(a); }
-O3 -fno-dce -fno-ipa-cp -fno-tree-dce
works on 9.5.0
I bisected it before I reduced it the previous time so as I said it's
introduced by:
Bad commit:
https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=ff6686d2e5f797d6c6a36ad14a7084bc1dc350e4
[Bug ipa/115767] [12/13/14/15 regression] GCC loses track of value on aarch64 with -O2 since r11-3308-gd119f34c952f87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115767 --- Comment #28 from mcccs at gmx dot com --- Created attachment 61145 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61145&action=edit 27k bytes reduced testcase further reduced with c-reduce. verified with various LLVM fsanitize's
[Bug ipa/115767] [12/13/14/15 regression] GCC loses track of value on aarch64 with -O2 since r11-3308-gd119f34c952f87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115767 --- Comment #29 from mcccs at gmx dot com --- fails with even -O1 -fstrict-aliasing -fcode-hoisting
[Bug bootstrap/119729] configure should issue a warning about building in the src tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119729 --- Comment #6 from mcccs at gmx dot com --- I haven't been given a sourceware account, I can't file a bug on sourceware. Maybe we can do it for GCC only and if they agree with it in the future they can change it: Updated patch: +if test $srcdir = . && test -d $srcdir/gcc ; then + AC_MSG_ERROR([building GCC with the top level project directory as the working directory is not supported. Please change the current directory to a different directory (can be a new subdirectory of the project root)]) +fi just above "# Find the build and target subdir names." in top-level configure.ac
[Bug middle-end/110282] Segmentation fault with specific optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110282 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #8 from mcccs at gmx dot com --- GCC 11 branch was closed so this can be closed?
[Bug middle-end/110282] Segmentation fault with specific optimizations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110282 --- Comment #9 from mcccs at gmx dot com --- Sorry never mind I understand, it should still be bisected and reduced so that any hidden bugs would be uncovered. I'll bisect it
[Bug tree-optimization/119683] [13/14/15 Regression] recalculating the return value which was already in the register right before function return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119683 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #2 from mcccs at gmx dot com --- Bisect points at https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=e7310e24b1c0ca67b1bb507c1330b2bf39e59e32
[Bug c/119877] New: [12/13/14/15/16 Regression] Honor __attribute__((unused)) and don't issue a warning -Wunused-function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119877
Bug ID: 119877
Summary: [12/13/14/15/16 Regression] Honor
__attribute__((unused)) and don't issue a warning
-Wunused-function
Product: gcc
Version: 15.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mcccs at gmx dot com
Target Milestone: ---
When compiling:
static __attribute__((unused)) int a();
int main() {}
GCC 12+ fail to compile with -Werror=unused-function
[Bug tree-optimization/119872] [15/16 regression] wrong code at -O{1,2,s}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119872 mcccs at gmx dot com changed: What|Removed |Added Attachment #61163|0 |1 is obsolete|| --- Comment #4 from mcccs at gmx dot com --- Created attachment 61164 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61164&action=edit cleanup2 a little more cleanup. fails with any optimization level except Og at trunk
[Bug tree-optimization/119872] [15/16 regression] wrong code at -O{1,2,s}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119872 --- Comment #3 from mcccs at gmx dot com --- Created attachment 61163 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61163&action=edit cleaned up I cleaned up the testcase, without changing the arithmetic, so it passes with 14.2 -O3 and trunk -O0, while failing with trunk -Os. It turns out my cleanup revealed another latent bug - it now aborts with trunk -O3 as well
[Bug rtl-optimization/116479] [15/16 Regression] wrong code with -O -funroll-loops -finline-stringops -fmodulo-sched --param=max-iterations-computation-cost=637924876 on aarch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=116479 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #2 from mcccs at gmx dot com --- bisection bad commit: 5d0c1b4e0d33c2d1077264636d0a65ce206d0d96
[Bug ipa/115767] [12/13/14/15/16 regression] GCC loses track of value on aarch64 with -O2 since r11-3308-gd119f34c952f87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115767 --- Comment #34 from mcccs at gmx dot com --- Thanks Andrew for the reply. In that case, the issue is probably invalid because checkpoint4.cpp also has several reinterpret_casts casting to things involving templates. Too bad, LLVM's -fsanitize=undefined and -fsanitize=type don't print any errors for this
[Bug tree-optimization/119592] [12/13/14/15/16 Regression] false positive array bounds warning with set>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119592 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #4 from mcccs at gmx dot com --- Bisect points at https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=6feb628a706e86eb3f303aff388c74bdb29e7381
[Bug ipa/115767] [12/13/14/15/16 regression] GCC loses track of value on aarch64 with -O2 since r11-3308-gd119f34c952f87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115767
mcccs at gmx dot com changed:
What|Removed |Added
Attachment #61145|0 |1
is obsolete||
--- Comment #30 from mcccs at gmx dot com ---
Comment on attachment 61145
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61145
27k bytes reduced testcase
>template struct b {
> static const int c = a;
>};
>struct e {};
>template struct aa;
>template struct ab;
>template <> struct aa<1> {
> template struct ac {
>typedef h d;
> };
>};
>template <> struct aa<2> {
> template struct ac {
>typedef ad d;
> };
>};
>template struct ae {};
>template struct as;
>template struct ae> {
> typedef g d;
>};
>template struct i {
> static const int c = af;
>};
>template struct j : i {};
>template struct j : i {};
>template
>struct ah : ae::template ac {};
>template <> struct ah<> {
> template struct ac : ah {};
>};
>template struct al {
> typedef aj d;
>};
>template struct al<0, aj, ak> {
> typedef ak d;
>};
>template struct an {
> typedef typename al::d d;
>};
>template struct ao {
> static const int c = at;
> typedef ao ar;
>};
>template struct au {
> typedef __typeof__(aw::av(ao())) d;
>};
>template struct bb : ae::d> {};
>template <> struct as {
> template struct ac : bb {};
>};
>template struct ar {
> typedef typename g::ar d;
>};
>template struct ay : bc {
> typedef typename bc::az ba;
> typedef typename ba::ar az;
> typedef typename ar::d bg;
> static ae av(ba);
> using bc::av;
>};
>template <> struct ae {
> template struct ac {
>typedef ay d;
> };
>};
>template
>struct be : bd::template ac {};
>template
>struct bf : bd::template ac {};
>template
>struct bl : bd::template ac {};
>template struct bj {
> typedef typename an::d ::d d;
>};
>template struct bk {
> typedef typename al::d ::d d;
>};
>template struct bp {
> typedef typename bb::d d;
>};
>template struct ar> {
> typedef bp d;
>};
>struct bm {
> typedef int ai;
> typedef ao<0> az;
> typedef ao<0> bg;
> void av();
>};
>template struct ac : aw::bg {};
>struct bn {
> template struct ac {
>typedef bp d;
> };
>};
>template struct bv : ay {};
>template struct bq : ay> {};
>template
>struct br : ay> {};
>template
>struct bs : ay> {};
>template
>struct bt;
>template <> struct bt<> : bm {};
>template struct bt : bv {};
>template
>struct bt : bs {};
>template struct allocator {
> template allocator(bu) {}
>};
>template struct cf;
>template struct cf> {
> using bx = bw *;
> template using bz = allocator;
> static bx allocate() { return (bx)__builtin_calloc(1, sizeof(bw)); }
>};
>template struct ca {
> typedef g &d;
>};
>template struct begin {
> typedef typename bn::ac::d d;
>};
>template
>struct cb : as::template ac> {};
>template struct cd : g {};
>template struct ce;
>template
>struct ce, h, ad, cp> {
> typedef typename bl, h, ad>::d d;
>};
>struct l;
>template struct cg {
> template struct ac {
>typedef typename be, int, ad, int>::d,
>typename ce, int, ad, int>::d>::d d;
> };
>};
>template class> struct ch;
>struct m;
>template struct ci {
> template struct ac {
>typedef typename bf, m, typename ce::d>::d d;
> };
>};
>template
>struct cj {
> template struct ac {
>typedef typename bl::d,
>typename ce::d>::d d;
> };
>};
>template typename aq, typename h, typename ad, typename cp>
>struct ce, h, ad, cp> {
> typedef typename bl, h, ad>::d d;
>};
>template struct ck {
> typedef typename g::d d;
>};
>template class bd> struct ch {
> template
> struct ac : ck> {};
>};
>template class bd>
>struct cw {
> template
> struct ac : ck> {};
>};
>template struct ab {
> typedef g cm;
> typedef g d;
>};
>template
>struct ab, cn> {
> typedef cg d;
>};
>template struct da {
> typedef cd> d;
>};
>template class bd, typename aj,
> typename ak, typename am, typename cn>
>struct ab, cn> {
> typedef typename da>::d d;
>};
>template template class,
> typename, typename, typename, typename, typename>
>struct cq;
>templ
[Bug ipa/115767] [12/13/14/15/16 regression] GCC loses track of value on aarch64 with -O2 since r11-3308-gd119f34c952f87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115767 --- Comment #31 from mcccs at gmx dot com --- Created attachment 61160 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61160&action=edit minimized.cpp GCC -O1 -fstrict-aliasing or -O2 or -O3: aborts I've attached the minimized human-readable reduced file. I do think it demonstrates GCC's fault in the original file, because if you: change reinterpret_cast *> near the end of the file to reinterpret_cast *>, which has the exact same memory layout (the template parameter is a dummy parameter), the produced assembly changes and execution does not abort. Comparing the "optimized" pass output with and without this mutation, it's seen that MEM[(struct templated_long_s *)_9].right = 42; only exists in the correct version. Therefore the testcase has the line reinterpreted->right = 42; completely dropped due to optimization. To experiment with the testcase, you may replace all 4 occurences of "long long" with "long" or "int".
[Bug ipa/115767] [12/13/14/15/16 regression] GCC loses track of value on aarch64 with -O2 since r11-3308-gd119f34c952f87
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115767 --- Comment #32 from mcccs at gmx dot com --- Oh no I'm so sorry all! I tried to set the previous attachment obsolete unfortunately it quoted all of it and posted here! Sorry for the tall thread
[Bug tree-optimization/119872] [15/16 regression] wrong code at -O{1,2,s}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119872 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #2 from mcccs at gmx dot com --- Bisect points at https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=735edbf1e2479fa2323a2b4a9714fae1a0925f74
[Bug tree-optimization/119592] [12/13/14/15/16 Regression] false positive array bounds warning with set> since r12-1992-g6feb628a706e86
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119592 --- Comment #6 from mcccs at gmx dot com --- Created attachment 61165 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61165&action=edit reduced.cpp Thanks for the pointer Sam, here's the C-vise reduction.
[Bug target/118008] [14/15/16 regression] ICE when bootstrapping with Go on arm (gen_movdi, at config/arm/arm.md:6296)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118008 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #14 from mcccs at gmx dot com --- I just bootstrapped on aarch64 with --with-arch=armv8-a+fp --with-float-abi=hard without any errors
[Bug tree-optimization/112307] Segmentation fault with -O1 -fcode-hoisting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #11 from mcccs at gmx dot com --- I'd like to try to reduce it but when I do g++ -E -std=c++23 x.cpp > y.cpp and g++ -fpreprocessed -std=c++23 y.cpp with latest trunk or 14.2 GCC I get lots of errors in the second command on both mac and linux
[Bug tree-optimization/112307] Segmentation fault with -O1 -fcode-hoisting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307 --- Comment #14 from mcccs at gmx dot com --- Created attachment 61179 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61179&action=edit reduced.cpp I think this reduction is valid. Fails with -O1 -fcode-hoisting, doesn't fail with -O0 or -O3 or with LLVM's various sanitizers
[Bug tree-optimization/112307] Segmentation fault with -O1 -fcode-hoisting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307 --- Comment #15 from mcccs at gmx dot com --- Thanks Jonathan for -x c++, it was just what GCC on my system needed
[Bug tree-optimization/119959] [15/16 regression] simple loop miscompiled into an endless loop since r15-580-gf3e5f4c58591f5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119959 --- Comment #9 from mcccs at gmx dot com --- Also to make sure my bisections are correct, after running the script automatically, I manually checkout to the bad commit and its parent and compare them. My previously pasted commit was my previous bisection which I discarded because the bisect script lacked "exit 125" (signifying that the commit is untestable) so GCC failing to build on my system counted wrongly influenced the bisection
[Bug tree-optimization/119959] [15/16 regression] simple loop miscompiled into an endless loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119959 --- Comment #5 from mcccs at gmx dot com --- Bisection points at r15-988-g5316c35b13cf53 also target aarch64 as well .L8: add x19, x19, 8 cmp x20, x19 beq .L16 versus .L7: add x19, x19, 8
[Bug tree-optimization/119959] [15/16 regression] simple loop miscompiled into an endless loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119959 --- Comment #7 from mcccs at gmx dot com --- Sorry right that's the parent commit! I pasted the wrong hash. Bisection says r15-580-gf3e5f4c58591f5
[Bug c++/119916] [15/16 Regression] folly (2025.04.14.00 and earlier): coroutine tests fail with GCC 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119916 mcccs at gmx dot com changed: What|Removed |Added Attachment #61203|0 |1 is obsolete|| --- Comment #7 from mcccs at gmx dot com --- Created attachment 61204 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61204&action=edit preprocessed.cpp.xz raw preprocessed file zipped again. replaced __float128 with _Float128, replaced mac-only assert failure function with __builtin_abort() so it works on my linux as well
[Bug tree-optimization/112307] Segmentation fault with -O1 -fcode-hoisting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307 --- Comment #21 from mcccs at gmx dot com --- Sorry again, there's a function of int type that didn't return anything but the compiler didn't catch it so the reduction script allowed it. My last reduction is also invalid.
[Bug tree-optimization/112307] Segmentation fault with -O1 -fcode-hoisting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307 --- Comment #23 from mcccs at gmx dot com --- Yes that's what I think! Thanks
[Bug c++/119916] [15/16 Regression] folly (2025.04.14.00 and earlier): coroutine tests fail with GCC 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119916 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #5 from mcccs at gmx dot com --- I have the source failing with latest GCC and succeeding with GCC 14. I'll try to reduce it
[Bug tree-optimization/112307] Segmentation fault with -O1 -fcode-hoisting
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112307 mcccs at gmx dot com changed: What|Removed |Added Attachment #61179|0 |1 is obsolete|| --- Comment #20 from mcccs at gmx dot com --- Created attachment 61199 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61199&action=edit reduced.cpp Thank you Andrew for pointing out the flaw - this time I verified there's nothing suspicious with -Wall
[Bug middle-end/119954] New: "a < b < c < d < ..." taking long time to process to generate error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119954
Bug ID: 119954
Summary: "a < b < c < d < ..." taking long time to process to
generate error message
Product: gcc
Version: 16.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
Assignee: unassigned at gcc dot gnu.org
Reporter: mcccs at gmx dot com
Target Milestone: ---
While trying to reduce pr118526, I found that source code of just
"a < b < c < d < ..."
compiled with std=c++20 is taking long times. an extra "< next_letter" added
takes 15 times more time I guess
[Bug c++/119916] [15/16 Regression] folly (2025.04.14.00 and earlier): coroutine tests fail with GCC 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119916 --- Comment #6 from mcccs at gmx dot com --- Created attachment 61203 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61203&action=edit preprocessed.cpp.xz The preprocessed source
[Bug tree-optimization/119959] [15/16 regression] simple loop miscompiled into an endless loop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119959 mcccs at gmx dot com changed: What|Removed |Added CC||mcccs at gmx dot com --- Comment #4 from mcccs at gmx dot com --- > -fno-ivopts looks to fix it ... Then is it a duplicate of pr119872 ?
[Bug c++/119916] [15/16 Regression] folly (2025.04.14.00 and earlier): coroutine tests fail with GCC 15
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119916 --- Comment #8 from mcccs at gmx dot com --- bisect bad commit: r15-3153-g68ee624bc52ba1 reduce is running, we can't know if the fault is in a commit or in the source for now
[Bug c++/119954] "a < b < c < d < ..." taking long time to process to generate error message
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119954 --- Comment #2 from mcccs at gmx dot com --- Created attachment 61219 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61219&action=edit testcase that should be run with -std=c++20 or above.cpp Uploaded testcase
[Bug c++/119916] [15/16 Regression] folly (2025.04.14.00 and earlier): coroutine tests fail with GCC 15 since r15-3153-g68ee624bc52ba1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119916 --- Comment #11 from mcccs at gmx dot com --- Created attachment 61216 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61216&action=edit reduction.cpp Probably correct reduction
