[Bug c/57750] New: Internal compiler error when initializing struct member with array
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57750
Bug ID: 57750
Summary: Internal compiler error when initializing struct
member with array
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dabler at gmail dot com
A code that causes the problem:
void main(){ struct a { int *b; } a = { (int*){1} }; }
Command line:
gcc bug.c
The compiler output:
bug.c: In function 'main':
bug.c:1:21: warning: initialization makes pointer from integer without a cast
[enabled by default]
bug.c:1:21: warning: (near initialization for '(anonymous)') [enabled by
default]
bug.c:1:35: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugs.gentoo.org/> for instructions.
Output of gcc -v:
gcc (Gentoo 4.6.3 p1.7, pie-0.5.2) 4.6.3
Copyright (C) 2011 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.
Output of gcc bug.c -save-temps; cat bug.i:
# 1 "bug.c"
# 1 ""
# 1 ""
# 1 "bug.c"
void main(){ struct a { int *b; } a = { (int*){1} }; }
[Bug middle-end/55185] Error generated on extern inline function which isn't called
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55185
--- Comment #1 from DaBler 2012-12-04 20:55:17 UTC ---
I have same problem here:
$ gcc -O3 -mno-sse -xc - < #include
> int main(){return 0;}
> END
In file included from :1:0:
/usr/include/stdlib.h: In function ‘atof’:
/usr/include/stdlib.h:280:1: error: SSE register return with SSE disabled
[Bug tree-optimization/78742] New: internal compiler error: in int_cst_value, at tree.c:10782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78742
Bug ID: 78742
Summary: internal compiler error: in int_cst_value, at
tree.c:10782
Product: gcc
Version: 5.4.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
Assignee: unassigned at gcc dot gnu.org
Reporter: dabler at gmail dot com
Target Milestone: ---
Created attachment 40283
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40283&action=edit
testcase
On x86_64 Linux:
$ gcc -v -save-temps -O3 -o libmp-test.o libmp.c -c
Using built-in specs.
COLLECT_GCC=gcc
Target: x86_64-linux
Configured with: ../configure --build=x86_64-linux --with-arch=core2
--with-tune=westmere --with-thread=posix --with-as=/usr/bin/as
--with-ld=/usr/bin/ld --with-system-zlib --program-suffix=-5.4
Thread model: posix
gcc version 5.4.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-o' 'libmp-test.o' '-c'
'-mtune=westmere' '-march=core2'
/usr/local/libexec/gcc/x86_64-linux/5.4.0/cc1 -E -quiet -v libmp.c
-mtune=westmere -march=core2 -O3 -fpch-preprocess -o libmp.i
ignoring duplicate directory
"/usr/local/lib/gcc/x86_64-linux/5.4.0/../../../../x86_64-linux/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/lib/gcc/x86_64-linux/5.4.0/include
/usr/local/include
/usr/local/lib/gcc/x86_64-linux/5.4.0/include-fixed
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O3' '-o' 'libmp-test.o' '-c'
'-mtune=westmere' '-march=core2'
/usr/local/libexec/gcc/x86_64-linux/5.4.0/cc1 -fpreprocessed libmp.i -quiet
-dumpbase libmp.c -mtune=westmere -march=core2 -auxbase-strip libmp-test.o -O3
-version -o libmp.s
GNU C11 (GCC) version 5.4.0 (x86_64-linux)
compiled by GNU C version 5.4.0, GMP version 4.3.1, MPFR version 2.4.1,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C11 (GCC) version 5.4.0 (x86_64-linux)
compiled by GNU C version 5.4.0, GMP version 4.3.1, MPFR version 2.4.1,
MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 6af85bd5d50765bfdcb33ae94df5c82d
libmp.c: In function ‘func’:
libmp.c:3:6: internal compiler error: in int_cst_value, at tree.c:10782
void func()
^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
$ cat libmp.c
void foo();
void func()
{
int m;
int tab[m];
__int128 j;
for(; j; j++)
{
tab[j] = 0;
tab[j+1] = 0;
}
foo();
}
Affected gcc versions I have found: 5.x.x, 6.x.x
[Bug c/60360] New: __attribute((aligned(...))) changes sizeof(...) of struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60360
Bug ID: 60360
Summary: __attribute((aligned(...))) changes sizeof(...) of
struct
Product: gcc
Version: 4.8.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dabler at gmail dot com
If the __attribute((aligned(...))) is used on structure, a size reported by
sizeof(...) operator is affected. Example:
struct strtype {
int i;
} __attribute((aligned(64))) s;
printf("%zu\n", sizeof(s));
This is in contrast with the behavior on other types, e.g. int type.
int i __attribute((aligned(64)));
printf("%zu\n", sizeof(i));
I believe that there is no reason to change sizeof(...) of the given struct
because an alignment can be determined by __alignof(...) operator.
[Bug c/60360] __attribute((aligned(...))) changes sizeof(...) of struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60360 --- Comment #1 from DaBler --- Created attachment 32227 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32227&action=edit he preprocessed file that triggers the bug Output: 64 64 64 64 4 64 4 64 4 64 Expected output: 4 64 4 64 4 64 4 64 4 64
[Bug c/60360] __attribute((aligned(...))) changes sizeof(...) of struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60360 --- Comment #2 from DaBler --- The output of gcc -v: Using built-in specs. COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3/gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.3/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: /var/tmp/portage/sys-devel/gcc-4.6.3/work/gcc-4.6.3/configure --prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.3 --includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include --datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3 --mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/man --infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/info --with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/include/g++-v4 --host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec --disable-fixed-point --with-cloog --with-ppl --with-cloog-include=/usr/include/cloog-ppl --disable-ppl-version-check --enable-lto --enable-nls --without-included-gettext --with-system-zlib --enable-obsolete --disable-werror --enable-secureplt --enable-multilib --enable-libmudflap --disable-libssp --enable-libgomp --with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.3/python --enable-checking=release --disable-libgcj --enable-libstdcxx-time --enable-languages=c,c++,fortran --enable-shared --enable-threads=posix --enable-__cxa_atexit --enable-clocale=gnu --enable-targets=all --with-bugurl=http://bugs.gentoo.org/ --with-pkgversion='Gentoo 4.6.3 p1.13, pie-0.5.2' Thread model: posix gcc version 4.6.3 (Gentoo 4.6.3 p1.13, pie-0.5.2)
[Bug c/60360] __attribute((aligned(...))) changes sizeof(...) of struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60360 --- Comment #4 from DaBler --- I see no reason why should not another variable be padded after struct as well.
[Bug c/60360] __attribute((aligned(...))) changes sizeof(...) of struct
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60360
--- Comment #6 from DaBler ---
When I call sizeof(...) on the int type (instead of a variable), it is the
same:
typedef int TypeInt __attribute((aligned(64)));
printf("%zu %zu\n", sizeof(TypeInt), alignof(TypeInt)); // Output: 4 64
Moreover, It is not possible to use this type for a construction of arrays. In
contrast, When I call sizeof(...) on the struct type:
typedef struct {
int i;
} __attribute((aligned(64))) TypeStruct;
printf("%zu %zu\n", sizeof(TypeStruct), alignof(TypeStruct)); // Output: 64 64
Thus, I still see an inconsistency.
[Bug c/98479] New: Missed optimization opportunity for unsigned __int128 modulo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98479
Bug ID: 98479
Summary: Missed optimization opportunity for unsigned __int128
modulo
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: dabler at gmail dot com
Target Milestone: ---
I have found that manually calculating the % operator on __int128 is
significantly faster than the built-in compiler operator. I will show you how
to calculate modulo 9, but the method can be used to calculate modulo any other
number.
First, consider the built-in compiler operator:
uint64_t mod9_v1(unsigned __int128 n)
{
return n % 9;
}
Now consider my manual implementation:
uint64_t mod9_v2(unsigned __int128 n)
{
uint64_t r = 0;
r += (uint32_t)(n);
r += (uint32_t)(n >> 32) * (uint64_t)4;
r += (uint32_t)(n >> 64) * (uint64_t)7;
r += (uint32_t)(n >> 96);
return r % 9;
}
Measuring over 100,000,000 random numbers gives the following results:
mod9_v1 | 3.986052 secs
mod9_v2 | 1.814339 secs
GCC 9.3.0 with -march=native -O3 was used on AMD Ryzen Threadripper 2990WX.
Note that 2^32 == 4 (mod 9), 2^64 == 7 (mod 9), etc.
