This is a Cygwin failure yeah?
Got to building the latest stuff on Cygwin - I modiifed the autoconfig script to get around some issues relating to 'ln -s' - and I then started the build. Got some errors, one I think is a Cygwin issue (but wanting that final 1% assurance) other I am pretty sure is a build/setup issue: source: latest as of yesterday morning 10:00 GMT config command: $ ../gcc/configure --enable-languages=c,c++ --enable-nls --enable-threads=posix build command: $ make >&../build_log.txt Errors: Cygwin one: When it gets to stage 3 (after many hours) I get the following printed out to the console (not redirected) - 217 [unknown (0x1B0)] conftest 3408 _cygtls::handle_exceptions: Error while dumping state (probably corrupted stack) By the looks of this I wold say that some part of the Cygwin runtime has failed. I've not seen this one in Cygwin at any other time than building GCC which leads me to assume (which is dangerous I realise) that there is an issue with my version and how GCC builds. Placing the "blame" on the Cygwin runtime. Is this a correct assumption can anyone tell me? [obviously if it is a Cygwin issue then I'll track it down a bit more before posting on their forums] GCC Build One: Again stage3 part of build, and this is what actually stops the build the above issue doesn't seem to (I think it happens in stage 2), I get the following: /home/andy/live-gcc/my_gcc/./gcc/xgcc -B/home/andy/live-gcc/my_gcc/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2-I. -I../../../gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic ../../../gcc/libiberty/strsignal.c -o pic/strsignal.o; \ else true; fi /home/andy/live-gcc/my_gcc/./gcc/xgcc -B/home/andy/live-gcc/my_gcc/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem /usr/local/i686-pc-cygwin/include -isystem /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2-I. -I../../../gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic ../../../gcc/libiberty/strsignal.c -o strsignal.o ../../../gcc/libiberty/strsignal.c:408: error: conflicting types for 'strsignal' /usr/include/string.h:78: note: previous declaration of 'strsignal' was here make[2]: *** [strsignal.o] Error 1 make[2]: Leaving directory `/home/andy/live-gcc/my_gcc/i686-pc-cygwin/libiberty' make[1]: *** [all-target-libiberty] Error 2 make[1]: Leaving directory `/home/andy/live-gcc/my_gcc' make: *** [all] Error 2 Which seems like a possible setup/build issue. If this is so anyone seen it before and any helpful hints on how to get rid of it? Thanks. Andy -- Brain upgrade required: a working hypothalamus
Re: This is a Cygwin failure yeah?
Hello Andy On 07.01.09, you wrote: > Cygwin one: > > When it gets to stage 3 (after many hours) I get the following printed > out to the console (not redirected) - > > 217 [unknown (0x1B0)] conftest 3408 _cygtls::handle_exceptions: Error > while dumping state (probably corrupted stack) > I think its a problem that cygwin cant use more stack.and in some case there get a stack overflow.but it seem not possible to increase the stack for the cygwin bash(i read many about that in inet but no solution see).only solution seem to build the build gcc with the stack option that the fvork for start cc1 use more stack than the bash process. maybe on GGC code can add that it use always 2 MB stack cygwin bash only have 400 kb of stack.Unix commad for stack increase(forget the name) dont work the exception handler of cygwin seem too broken, because a abort give always this message and no abort text. I btw get such crashes from binutil 2.14 assembler and can reproduce them when i forget on writing asm inline code a \n\ at end. normaly the assembler give error messages, but i guess due too much stack of assembler error writing, gcc crash because of too few stack. strange, compiler 2.95 and older binutil work without \n\ at end > By the looks of this I wold say that some part of the Cygwin runtime > has failed. I've not seen this one in Cygwin at any other time than > building GCC which leads me to assume (which is dangerous I realise) > that there is an issue with my version and how GCC builds. Placing the > "blame" on the Cygwin runtime. > > Is this a correct assumption can anyone tell me? [obviously if it is a > Cygwin issue then I'll track it down a bit more before posting on > their forums] > > GCC Build One: > > Again stage3 part of build, and this is what actually stops the build > the above issue doesn't seem to (I think it happens in stage 2), I get > the following: > > > > /home/andy/live-gcc/my_gcc/./gcc/xgcc > -B/home/andy/live-gcc/my_gcc/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ > -B/usr/local/i686-pc-cygwin/lib/ -isystem > /usr/local/i686-pc-cygwin/include -isystem > /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2-I. > -I../../../gcc/libiberty/../include -W -Wall -Wwrite-strings > -Wc++-compat -Wstrict-prototypes -pedantic > ../../../gcc/libiberty/strsignal.c -o pic/strsignal.o; \ > else true; fi > /home/andy/live-gcc/my_gcc/./gcc/xgcc -B/home/andy/live-gcc/my_gcc/./gcc/ > -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem > /usr/local/i686-pc-cygwin/include -isystem > /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2 -I. > -I../../../gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat > -Wstrict-prototypes -pedantic ../../../gcc/libiberty/strsignal.c -o > strsignal.o ../../../gcc/libiberty/strsignal.c:408: error: conflicting > types for 'strsignal' /usr/include/string.h:78: note: previous declaration > of 'strsignal' was here make[2]: *** [strsignal.o] Error 1 make[2]: > Leaving directory `/home/andy/live-gcc/my_gcc/i686-pc-cygwin/libiberty' > make[1]: *** [all-target-libiberty] Error 2 make[1]: Leaving directory > `/home/andy/live-gcc/my_gcc' make: *** [all] Error 2 > > Which seems like a possible setup/build issue. If this is so anyone > seen it before and any helpful hints on how to get rid of it? > > Thanks. > > Andy Regards
Re: This is a Cygwin failure yeah?
Hello Andy On 07.01.09, you wrote: > Cygwin one: > > When it gets to stage 3 (after many hours) I get the following printed > out to the console (not redirected) - > > 217 [unknown (0x1B0)] conftest 3408 _cygtls::handle_exceptions: Error > while dumping state (probably corrupted stack) > I think its a problem that cygwin cant use more stack.and in some case there get a stack overflow.but it seem not possible to increase the stack for the cygwin bash(i read many about that in inet but no solution see).only solution seem to build the build gcc with the stack option that the fvork for start cc1 use more stack than the bash process. maybe on GGC code can add that it use always 2 MB stack cygwin bash only have 400 kb of stack.Unix commad for stack increase(forget the name) dont work the exception handler of cygwin seem too broken, because a abort give always this message and no abort text. I btw get such crashes from binutil 2.14 assembler and can reproduce them when i forget on writing asm inline code a \n\ at end. normaly the assembler give error messages, but i guess due too much stack of assembler error writing, gcc crash because of too few stack. strange, compiler 2.95 and older binutil work without \n\ at end > By the looks of this I wold say that some part of the Cygwin runtime > has failed. I've not seen this one in Cygwin at any other time than > building GCC which leads me to assume (which is dangerous I realise) > that there is an issue with my version and how GCC builds. Placing the > "blame" on the Cygwin runtime. > > Is this a correct assumption can anyone tell me? [obviously if it is a > Cygwin issue then I'll track it down a bit more before posting on > their forums] > > GCC Build One: > > Again stage3 part of build, and this is what actually stops the build > the above issue doesn't seem to (I think it happens in stage 2), I get > the following: > > > > /home/andy/live-gcc/my_gcc/./gcc/xgcc > -B/home/andy/live-gcc/my_gcc/./gcc/ -B/usr/local/i686-pc-cygwin/bin/ > -B/usr/local/i686-pc-cygwin/lib/ -isystem > /usr/local/i686-pc-cygwin/include -isystem > /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2-I. > -I../../../gcc/libiberty/../include -W -Wall -Wwrite-strings > -Wc++-compat -Wstrict-prototypes -pedantic > ../../../gcc/libiberty/strsignal.c -o pic/strsignal.o; \ > else true; fi > /home/andy/live-gcc/my_gcc/./gcc/xgcc -B/home/andy/live-gcc/my_gcc/./gcc/ > -B/usr/local/i686-pc-cygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem > /usr/local/i686-pc-cygwin/include -isystem > /usr/local/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2 -I. > -I../../../gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat > -Wstrict-prototypes -pedantic ../../../gcc/libiberty/strsignal.c -o > strsignal.o ../../../gcc/libiberty/strsignal.c:408: error: conflicting > types for 'strsignal' /usr/include/string.h:78: note: previous declaration > of 'strsignal' was here make[2]: *** [strsignal.o] Error 1 make[2]: > Leaving directory `/home/andy/live-gcc/my_gcc/i686-pc-cygwin/libiberty' > make[1]: *** [all-target-libiberty] Error 2 make[1]: Leaving directory > `/home/andy/live-gcc/my_gcc' make: *** [all] Error 2 > > Which seems like a possible setup/build issue. If this is so anyone > seen it before and any helpful hints on how to get rid of it? > > Thanks. > > Andy Regards
Re: libmudflap and emutls question
Hi Paolo,
Thanks for your review!
Paolo Bonzini wrote:
+AC_COMPILE_IFELSE([__thread int a; int b; int main() { return a = b; }],
+ [if grep __emutls_get_address conftest.$ac_objext
>/dev/null ; then
grepping in a binary file is not portable. If this works it would be
better:
AC_COMPILE_IFELSE([[__thread int a; int b;
extern void __emutls_get_address();
int main() {
__emutls_get_address();
return a = b;
}]],
[gcc_cv_use_emutls=yes],
[gcc_cv_use_emutls=no])
This does not work. For x86_64 native gcc, the compiler output is
$ gcc -c test.c
test.c:2: warning: conflicting types for built-in function
‘__emutls_get_address’
For Blackfin gcc, the compiler output is
$ bfin-uclinux-gcc -c test.c
test.c:2: warning: conflicting types for built-in function
‘__emutls_get_address’
Both are same.
I thought about using "int __emutls_v.a;" to trigger duplicate
definitions, but C don't allow dot in symbol name. If there is something
like AC_COMPILE_IFELSE but output assembly file instead of object file,
it will be the best choice. But I don't know if it exists. There is an
existing practice in autoconf (c.m4), which greps object file to find
out endianness. So I think grep object file might be acceptable.
Otherwise, the configury parts look fine to me.
Regards,
Jie
Re: m32c, ivopts, 20000412-6.c
On Wed, Jan 7, 2009 at 1:46 AM, DJ Delorie wrote: > > I'm looking a failure for m32c-elf (-mcpu=m32c) in > gcc.c-torture/execute/2412-6.c. > > I've narrowed it down to a transformation done in 107t.ivopts. > > In 104t.cunroll: (tmp_9 and tmp_16 are 24-bit pointer values): > > tmp_9 = tmp_16 + 2; > if (bufend_6(D) > tmp_9) > > but in 107t.ivopts: > > tmp_9 = tmp_16 + 2; > D.1229_1 = (unsigned int) tmp_9; > tmp_13 = (short unsigned int *) D.1229_1; > if (bufend_6(D) > tmp_13) > > The problem is that tmp_9 is a 24-bit value, and casting it to > unsigned int (16 bits) truncates off eight of the bits. Why are we > casting pointers to integer values at all? Is there any way to stop > ivopts from performing this truncation? As I repeatedly said having sizetype of a different precision than pointer types will cause all sorts of problems ;) The middle-end generally assumes it can cast between sizetype and pointers arbitrarily. In the above case, what type is tmp_9, what type is tmp_16? Richard.
Re: libmudflap and emutls question
> Both are same.
Ah, I see, the call is optimized out because __emutls_get_address is
const. You can try
__thread int a;
int main () {
return *(int *)__emutls_get_address ((void *)0) == a;
}
I don't have an emutls target at hand, but it does fail on Linux.
Paolo
Options of fixing biggest alignment in PR target/38736
This is about http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38736 and I'd rather
discuss it in gcc mail list. Basicly the problem is shown as following example:
Case 1 (on x86 or x86_64):
$ cat i.h
struct s
{
char dummy0;
// align at maxmiun aligned boundary supported by this target.
char dummy __attribute__((aligned));
int data;
};
extern void foo(struct s*);
$ cat foo.c
#include "i.h"
void foo(struct s* input)
{ input->data = 1; }
$ cat main.c
#include "i.h"
extern void abort(void);
struct s g_s;
int main()
{
foo(&g_s);
if (g_s.data != 1) abort();
}
$ gcc -S foo.c
$ gcc -S main.c -mavx
$ gcc -o foo.exe foo.s main.s
$ ./foo.exe
Aborted
The reason is that AVX target defines BIGGEST_ALIGNMENT to 32 bytes and non-AVX
x86 target does as 16 bytes. Since __attribute__((aligned)) aligns struct
memory according to BIGGEST_ALIGNMENT, objects built by avx/non-avx GCC will
result in different struct layout.
There are options to solve this problem so far I can think of:
Option 1: Leave BIGGEST_ALIGNMENT as it is nowaday and modify all libraries and
header files using __attribute__((aligned)) similar to i.h
Option 2: Define BIGGEST_ALIGNMENT as a fixed value 16 bytes, for all x86
target.
Option 3: Define BIGGEST_ALIGNMENT as a fixed value 32 bytes, for all x86
target, and extend to 64 or more bytes in future.
Option 1 follows the definition of __attribute__((aligned)) in GCC manual, and
it works as expected to provide a way to align at maxium target alignment.
However, fixing all libraries will be tidious and easy to miss. Also
documentation should mention the potiential issue using this feature.
Option 2 and option 3 seems to be a quick solution, but their draw back is
obvious. Firstly it doesn't follow the definition of __attribute__((aligned))
and can leave confusion to users. Secondly it eliminates a convenient way for
user utilize the maxium alignment supported in x86 family. Also very
importantly they won't solve all problem, for example if i.h is like this:
Case 2:
$ cat i2.h
#ifdef __AVX__
#define aligned __aligned__(32)
#else
#define aligned __aligned__(16)
#endif
struct s
{
char dummy0;
char dummy __attribute__((aligned));
int data;
};
extern void foo(struct s*);
Furthermore option 3 will result different behavior for GCC 4.3- and GCC 4.4+,
case 1 will still fail if foo.c is built by GCC 4.3- and main.c by 4.4+.
In summary, I don't see an obvious best way to solve in PR38736. But IMHO
option 1 is more reasonable.
Thanks - Joey
Re: Options of fixing biggest alignment in PR target/38736
On Wed, Jan 7, 2009 at 10:22 AM, Ye, Joey wrote:
> This is about http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38736 and I'd
> rather discuss it in gcc mail list. Basicly the problem is shown as following
> example:
>
> Case 1 (on x86 or x86_64):
> $ cat i.h
> struct s
> {
>char dummy0;
>// align at maxmiun aligned boundary supported by this target.
>char dummy __attribute__((aligned));
>int data;
> };
> extern void foo(struct s*);
> $ cat foo.c
> #include "i.h"
> void foo(struct s* input)
> { input->data = 1; }
> $ cat main.c
> #include "i.h"
> extern void abort(void);
> struct s g_s;
> int main()
> {
>foo(&g_s);
>if (g_s.data != 1) abort();
> }
>
> $ gcc -S foo.c
> $ gcc -S main.c -mavx
> $ gcc -o foo.exe foo.s main.s
> $ ./foo.exe
> Aborted
>
> The reason is that AVX target defines BIGGEST_ALIGNMENT to 32 bytes and
> non-AVX x86 target does as 16 bytes. Since __attribute__((aligned)) aligns
> struct memory according to BIGGEST_ALIGNMENT, objects built by avx/non-avx
> GCC will result in different struct layout.
>
> There are options to solve this problem so far I can think of:
> Option 1: Leave BIGGEST_ALIGNMENT as it is nowaday and modify all libraries
> and header files using __attribute__((aligned)) similar to i.h
> Option 2: Define BIGGEST_ALIGNMENT as a fixed value 16 bytes, for all x86
> target.
> Option 3: Define BIGGEST_ALIGNMENT as a fixed value 32 bytes, for all x86
> target, and extend to 64 or more bytes in future.
>
> Option 1 follows the definition of __attribute__((aligned)) in GCC manual,
> and it works as expected to provide a way to align at maxium target
> alignment. However, fixing all libraries will be tidious and easy to miss.
> Also documentation should mention the potiential issue using this feature.
>
> Option 2 and option 3 seems to be a quick solution, but their draw back is
> obvious. Firstly it doesn't follow the definition of __attribute__((aligned))
> and can leave confusion to users. Secondly it eliminates a convenient way for
> user utilize the maxium alignment supported in x86 family. Also very
> importantly they won't solve all problem, for example if i.h is like this:
> Case 2:
> $ cat i2.h
> #ifdef __AVX__
> #define aligned __aligned__(32)
> #else
> #define aligned __aligned__(16)
> #endif
> struct s
> {
>char dummy0;
>char dummy __attribute__((aligned));
>int data;
> };
> extern void foo(struct s*);
>
> Furthermore option 3 will result different behavior for GCC 4.3- and GCC
> 4.4+, case 1 will still fail if foo.c is built by GCC 4.3- and main.c by 4.4+.
>
> In summary, I don't see an obvious best way to solve in PR38736. But IMHO
> option 1 is more reasonable.
IMHO Option 2 is the most reasonable thing for GCC 4.4.
Richard.
> Thanks - Joey
>
Re: libmudflap and emutls question
Hi Paolo,
Paolo Bonzini wrote:
Both are same.
Ah, I see, the call is optimized out because __emutls_get_address is
const. You can try
__thread int a;
int main () {
return *(int *)__emutls_get_address ((void *)0) == a;
}
I don't have an emutls target at hand, but it does fail on Linux.
Which version of gcc did you use? gcc 4.1 (maybe and 4.2) will report
error. But gcc 4.3 compiles OK. I tested using x86_64 native gcc from
Debian unstable. __emutls_get_address is defined in libgcc even the
target has real TLS.
/usr/lib/gcc/x86_64-linux-gnu$ readelf -a ./4.3/libgcc_s.so | grep emutls
28: 00013a80 390 FUNCGLOBAL DEFAULT 12
__emutls_get_address@@GCC_4.3.0
136: 0001397057 FUNCGLOBAL DEFAULT 12
__emutls_register_common@@GCC_4.3.0
Regards,
Jie
Re: libmudflap and emutls question
> Which version of gcc did you use? gcc 4.1 (maybe and 4.2) will report > error. But gcc 4.3 compiles OK. I tested using x86_64 native gcc from > Debian unstable. __emutls_get_address is defined in libgcc even the > target has real TLS. Uff... not my day. I used 4.2 (emutls was posted in 4.2 time but committed in 4.3 only). But I didn't think of the simplest solution: use greps together with strings(1): "strings ./conftest | grep __emutls_get_address". Paolo
Re: libmudflap and emutls question
On Wed, Jan 07, 2009 at 11:38:55AM +0100, Paolo Bonzini wrote: > > > Which version of gcc did you use? gcc 4.1 (maybe and 4.2) will report > > error. But gcc 4.3 compiles OK. I tested using x86_64 native gcc from > > Debian unstable. __emutls_get_address is defined in libgcc even the > > target has real TLS. > > Uff... not my day. I used 4.2 (emutls was posted in 4.2 time but > committed in 4.3 only). But I didn't think of the simplest solution: > use greps together with strings(1): "strings ./conftest | grep > __emutls_get_address". I'd say much better would be just to grep assembly. See e.g. libffi/configure.ac's libffi_cv_hidden_visibility_attribute test. Jakub
Re: This is a Cygwin failure yeah?
Andy Scott wrote: > When it gets to stage 3 (after many hours) I get the following printed > out to the console (not redirected) - > > 217 [unknown (0x1B0)] conftest 3408 _cygtls::handle_exceptions: Error > while dumping state (probably corrupted stack) > > By the looks of this I wold say that some part of the Cygwin runtime > has failed. To be precise: what this means is that firstly a user application has failed with a segfault or some similar error that would normally produce a .stackdump file (Cygwin's equivalent of dumping core when an application fails), but that there has been an exception in the code that tries to unwind the stack and generate the dumpfile. So it could be a Cygwin runtime failure, or it could just be a particularly bad crash in whatever application was running at the time. > I've not seen this one in Cygwin at any other time than > building GCC which leads me to assume (which is dangerous I realise) > that there is an issue with my version and how GCC builds. Placing the > "blame" on the Cygwin runtime. > > Is this a correct assumption can anyone tell me? It could be, but it could also be a bad codegen bug in the new compiler you're building. You haven't given enough context to tell exactly where it's happening, but since we're in stage 3 and the executable is called 'conftest', it could be one of the configure test programs built with the new compiler when configuring to build the target libraries. Another possibility is that it's not even actually a problem at all. It may well be that this is a configure test for some feature that isn't implemented or doesn't work on Cygwin and configure is correctly deducing that attempts to use it will fail. > GCC Build One: > > Again stage3 part of build, and this is what actually stops the build > the above issue doesn't seem to (I think it happens in stage 2), That sentence contradicts itself and what you said earlier, doesn't it? > ../../../gcc/libiberty/strsignal.c -o strsignal.o > ../../../gcc/libiberty/strsignal.c:408: error: conflicting types for > 'strsignal' > /usr/include/string.h:78: note: previous declaration of 'strsignal' was here > make[2]: *** [strsignal.o] Error 1 > make[2]: Leaving directory > `/home/andy/live-gcc/my_gcc/i686-pc-cygwin/libiberty' > make[1]: *** [all-target-libiberty] Error 2 > make[1]: Leaving directory `/home/andy/live-gcc/my_gcc' > make: *** [all] Error 2 > > Which seems like a possible setup/build issue. If this is so anyone > seen it before and any helpful hints on how to get rid of it? Looks like newlib has a non-posix-compliant definition of strsignal. If you take a look at the header file, it seems GDB has a problem with it too: /tmp/binutils/binutils-2.19/ld $ cat -n /usr/include/string.h | grep -C4 78 74 char*_EXFUN(strlwr,(char *)); 75 char*_EXFUN(strupr,(char *)); 76 #ifdef __CYGWIN__ 77 #ifndef DEFS_H /* Kludge to work around problem compiling in gdb */ 78 const char *_EXFUN(strsignal, (int __signo)); 79 #endif 80 int _EXFUN(strtosigno, (const char *__name)); 81 #endif 82 /tmp/binutils/binutils-2.19/ld $ ... maybe just adding -DDEFS_H to your CFLAGS would be a work-around. Hmm, given that Cygwin supports strsignal, this bit of libiberty shouldn't be being compiled, because configure should have defined HAVE_STRSIGNAL. On my local build of 4.3.2, this works correctly: "nm libiberty/strsignal.o" shows the function isn't defined, and HAVE_STRSIGNAL is defined in config.h. Have a look through libiberty/config.log and see if you can figure out why it isn't defined; maybe it's even something to do with the earlier crash? cheers, DaveK
Re: Use longlong.h?
This started as a query on the newlib mailing list, but this now touched a question which is important to a large number of other gcc users and developers, which is why I am cross-posting this to the gcc mailing list. Quoting Jeff Johnston : Joern Rennecke wrote: I've noticed that we could make the code that uses Storeinc / Pack_32 (dtoa.c and mprec.c in libc/stdlib) a lot more efficient if we used the operations defined in longlong.h . Would it be OK to use longlong.h in newlib? If you are referring to the longlong.h found in gcc's source tree, no, it is GPL. Yes, that is the longlong.h I was referring to. I thought that it had the gcc library exception, so that we could simply autoconf its use in newlib. However, looking at the file, I see that you are correct, it is GPL without a library exception. This is not only a problem with the use in newlib I was thinking of, but also with its usage in gcc by libgcc, because it means that programs linked with libgcc have to be GPL licensed when distributed unless the user has a separate license from the included code from the author which allows distribution other licenses. If not, what longlong.h are you referring to and is it guaranteed to exist for all platforms? If the copyright notice of gcc's longlong.h is not fixed, longlong.h will have to be forked (where the Copyright assigner whishes the general usability of longlong.h, dual licensing of the contributed code is possible) / recoded by the poeople who want to provide GNU based toolchains which can be used to compile not only GPL software, but software with different licenses too. Which, I believe, is a large part of the gcc contributors.
Re: Options of fixing biggest alignment in PR target/38736
On Wed, Jan 7, 2009 at 1:22 AM, Ye, Joey wrote:
> This is about http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38736 and I'd
> rather discuss it in gcc mail list. Basicly the problem is shown as following
> example:
>
> Case 1 (on x86 or x86_64):
> $ cat i.h
> struct s
> {
>char dummy0;
>// align at maxmiun aligned boundary supported by this target.
>char dummy __attribute__((aligned));
>int data;
> };
> extern void foo(struct s*);
> $ cat foo.c
> #include "i.h"
> void foo(struct s* input)
> { input->data = 1; }
> $ cat main.c
> #include "i.h"
> extern void abort(void);
> struct s g_s;
> int main()
> {
>foo(&g_s);
>if (g_s.data != 1) abort();
> }
>
> $ gcc -S foo.c
> $ gcc -S main.c -mavx
> $ gcc -o foo.exe foo.s main.s
> $ ./foo.exe
> Aborted
>
> The reason is that AVX target defines BIGGEST_ALIGNMENT to 32 bytes and
> non-AVX x86 target does as 16 bytes. Since __attribute__((aligned)) aligns
> struct memory according to BIGGEST_ALIGNMENT, objects built by avx/non-avx
> GCC will result in different struct layout.
>
> There are options to solve this problem so far I can think of:
> Option 1: Leave BIGGEST_ALIGNMENT as it is nowaday and modify all libraries
> and header files using __attribute__((aligned)) similar to i.h
> Option 2: Define BIGGEST_ALIGNMENT as a fixed value 16 bytes, for all x86
> target.
> Option 3: Define BIGGEST_ALIGNMENT as a fixed value 32 bytes, for all x86
> target, and extend to 64 or more bytes in future.
>
> Option 1 follows the definition of __attribute__((aligned)) in GCC manual,
> and it works as expected to provide a way to align at maxium target
> alignment. However, fixing all libraries will be tidious and easy to miss.
> Also documentation should mention the potiential issue using this feature.
>
> Option 2 and option 3 seems to be a quick solution, but their draw back is
> obvious. Firstly it doesn't follow the definition of __attribute__((aligned))
> and can leave confusion to users. Secondly it eliminates a convenient way for
> user utilize the maxium alignment supported in x86 family. Also very
> importantly they won't solve all problem, for example if i.h is like this:
> Case 2:
> $ cat i2.h
> #ifdef __AVX__
> #define aligned __aligned__(32)
> #else
> #define aligned __aligned__(16)
> #endif
> struct s
> {
>char dummy0;
>char dummy __attribute__((aligned));
>int data;
> };
> extern void foo(struct s*);
>
> Furthermore option 3 will result different behavior for GCC 4.3- and GCC
> 4.4+, case 1 will still fail if foo.c is built by GCC 4.3- and main.c by 4.4+.
>
> In summary, I don't see an obvious best way to solve in PR38736. But IMHO
> option 1 is more reasonable.
>
__attribute__((aligned)) is a problem only when
1. It is used in a public interface. And
2. It is used as field in a struct.
I checked the gcc source. I think struct _Unwind_Exception is the only one.
We can change it to __attribute__((aligned(16))) for x86. As for other usages
outside of gcc, we can issue a warning/error when it happens?
If we want to take option 2, we should update gcc document.
--
H.J.
Mixing languages in the same TU and dwarf2out_frame_finish
In the LTO branch, we changed the use of eh_personality_libfunc because when merging files from different front ends, we will have functions that require different EH personalities. So, every function_decl now has a pointer to its personality function accessed via get_personality_function. However, this doesn't work properly when we are in global contexts. For this, we have eh_personality_decl which each front end initializes in a similar manner as eh_personality_func. But instead of creating the RTL for the libfunc, only its DECL is created (http://gcc.gnu.org/ml/gcc-patches/2008-12/msg00913.html). The problem we are having now is that in compile_file, we call dwarf2out_frame_finish() which in turn calls output_call_frame_info. On mainline, output_call_frame_info references eh_personality_libfunc, which is created for the particular FE that is active. However, on LTO, we may have several personality functions in the same object file. So, it's not clear what should we do here. Should we call dwarf2out_frame_finish() for each of the personalities that we saw in that file? Related to this is the problem that eh_personality_decl is not created in lto1, simply because it's not a real front end, it relies on each front end putting the appropriate personality on each function in the TU. But I'm not sure what should be done when we are emitting information like call frames at the global scope. Thanks. Diego.
Re: Use longlong.h?
On Wed, 7 Jan 2009, Joern Rennecke wrote: > Yes, that is the longlong.h I was referring to. I thought that it had the > gcc library exception, so that we could simply autoconf its use in newlib. > However, looking at the file, I see that you are correct, it is GPL without > a library exception. > This is not only a problem with the use in newlib I was thinking of, but > also with its usage in gcc by libgcc, because it means that programs linked > with libgcc have to be GPL licensed when distributed unless the user has a > separate license from the included code from the author which allows > distribution other licenses. As code shared by GCC and glibc I would suggest the same license notice as soft-fp (LGPL >= 2.1 + exception) to allow an identical file to be shared. (Indeed, soft-fp uses this header.) The version in GMP diverged long ago so sharing the file with that may not be feasible. -- Joseph S. Myers jos...@codesourcery.com
Re: Question about UNSPEC rtx and a new instruction
JCX writes: > Hello, I am working on a gcc porting for a new instruction. This > instruction needs to move data from memory to two registers. So I use > the SET rtx, and the dest of SET is an UNSPEC rtx with two registers. > By using such a rtl pattern, gcc performs very differently. It makes > mistakes for register replacement and instruction reordering. > For example, when gcc optimizes in pass_cse, it performs register > substitution of registers in UNSPEC rtx without checking the validity > of the resulting insn. > So I wonder about the UNSPEC rtx. > > What's the usage of UNSPEC rtx? UNSPEC is used for values which can not be easily specified in RTL. There are many existing examples. I'm surprised that using it as the destination of a set works at all. > And do you have a better rtl pattern for this new instruction? Use a PARALLEL with two SETs. (define_insn "" [(set () ()) (set () ())] ...) This is a common RTL pattern on machines with a condition code register, such as the x86. Ian
Re: About Hazard Recognizer:DFA
daniel tian wrote: Hi Dr. Uday Khedker: Happy New Year! I met hazard problem. And I have debuged this error for a few days. I wrote DFA to avoid load hazard, but still it exists. I wonder whether in default the command './cc1 hazard.c' doesn't compile the file with DFA. By default the scheduler is enabled starting at -O2, so this should at least be './cc1 -O2 hazard.c'. Of cause, you should also add generation of nops, as Vladimir said, either in machine dependent reorg or in assembler. Also, scheduler dumps may be helpful for you; they can be enabled via -fsched-verbose=N switch. -- Maxim
Re: Options of fixing biggest alignment in PR target/38736
"Ye, Joey" writes: > Option 3: Define BIGGEST_ALIGNMENT as a fixed value 32 bytes, for > all x86 target, and extend to 64 or more bytes in future. Assuming that code compiled with -mavx is intended to interoperate with code compiled without -mavx, I believe that this is the only viable long-term option. Unfortunately that would be a change in the ABI for any code which exposes a struct with an attribute((aligned)) field. BIGGEST_ALIGNMENT should always be a constant for code which can interoperate. I doubt that many ABIs expose a struct with a field with attribute((aligned)), but as far as I can see we are going to have to break those ABIs eventually. The question now is whether we should break them for 4.4, for 4.5, or for some later version. That said, I should also note that the glibc solution has been to fix the maximum alignment at 8, in that that is the alignment which malloc returns on the x86. I don't think that is a wise choice, but it is a choice that we could also make: we could simply fix the x86 BIGGEST_ALIGNMENT at 16 and never change it in the future. Ian
Re: Options of fixing biggest alignment in PR target/38736
On Wed, Jan 7, 2009 at 7:55 AM, Ian Lance Taylor wrote: > "Ye, Joey" writes: > >> Option 3: Define BIGGEST_ALIGNMENT as a fixed value 32 bytes, for >> all x86 target, and extend to 64 or more bytes in future. > > Assuming that code compiled with -mavx is intended to interoperate > with code compiled without -mavx, I believe that this is the only > viable long-term option. Unfortunately that would be a change in the > ABI for any code which exposes a struct with an attribute((aligned)) > field. > BIGGEST_ALIGNMENT should always be a constant for code which can > interoperate. > > I doubt that many ABIs expose a struct with a field with > attribute((aligned)), but as far as I can see we are going to have to > break those ABIs eventually. The question now is whether we should > break them for 4.4, for 4.5, or for some later version. > > That said, I should also note that the glibc solution has been to fix > the maximum alignment at 8, in that that is the alignment which malloc > returns on the x86. I don't think that is a wise choice, but it is a > choice that we could also make: we could simply fix the x86 > BIGGEST_ALIGNMENT at 16 and never change it in the future. > Fixing BIGGEST_ALIGNMENT to 16 may require extensive changes. I am thinking to add DEFAULT_ALIGNMENT with #ifndef DEFAULT_ALIGNMENT #define DEFAULT_ALIGNMENT BIGGEST_ALIGNMENT #endif and use it only for attribute((aligned)). x86 will define DEFAULT_ALIGNMENT as 16. Of course, we need to update document for attribute((aligned)). -- H.J.
Re: Options of fixing biggest alignment in PR target/38736
On Wed, Jan 7, 2009 at 4:55 PM, Ian Lance Taylor wrote: > "Ye, Joey" writes: > >> Option 3: Define BIGGEST_ALIGNMENT as a fixed value 32 bytes, for >> all x86 target, and extend to 64 or more bytes in future. > > Assuming that code compiled with -mavx is intended to interoperate > with code compiled without -mavx, I believe that this is the only > viable long-term option. Unfortunately that would be a change in the > ABI for any code which exposes a struct with an attribute((aligned)) > field. > > BIGGEST_ALIGNMENT should always be a constant for code which can > interoperate. > > I doubt that many ABIs expose a struct with a field with > attribute((aligned)), but as far as I can see we are going to have to > break those ABIs eventually. The question now is whether we should > break them for 4.4, for 4.5, or for some later version. > > That said, I should also note that the glibc solution has been to fix > the maximum alignment at 8, in that that is the alignment which malloc > returns on the x86. I don't think that is a wise choice, but it is a > choice that we could also make: we could simply fix the x86 > BIGGEST_ALIGNMENT at 16 and never change it in the future. As there is no hardware implementation of AVX available I think we definitely should stay with 16 for 4.4. And IMNSHO also for all future - __attribute__((aligned)) is part of the ABI, and if it is not the only user of BIGGEST_ALIGNMENT then BIGGEST_ALIGNMENT should be properly split between an ABI part and an optimization related part. Richard. > Ian >
Re: m32c, ivopts, 20000412-6.c
> As I repeatedly said having sizetype of a different precision than > pointer types will cause all sorts of problems ;) And as I've rebutted repeatedly, I can't change the chip. > The middle-end generally assumes it can cast between sizetype and > pointers arbitrarily. Bad assumption. It will get worse with the upcoming named address branch work. > In the above case, what type is tmp_9, what type is tmp_16? The 107t dump file doesn't say, but the .128r.expand file looks like this: ;; D.1229 = (unsigned int) tmp; (insn 36 35 37 2412-6.c:14 (set (reg:SI 53) (sign_extend:SI (reg/v/f:PSI 48 [ tmp ]))) -1 (nil)) (insn 37 36 0 2412-6.c:14 (set (reg:HI 47 [ D.1229 ]) (subreg:HI (reg:SI 53) 0)) -1 (nil)) ;; if (bufend > (short unsigned int *) D.1229) (insn 39 37 40 2412-6.c:18 (set (reg:SI 55) (zero_extend:SI (reg:HI 47 [ D.1229 ]))) -1 (nil)) (insn 40 39 41 2412-6.c:18 (set (reg:PSI 54) (truncate:PSI (reg:SI 55))) -1 (nil)) So it goes PSI -> SI -> HI -> SI -> PSI
Re: How to define 2 bypasses for a single pair of insn_reservation
Ye, Joey wrote: Vladimir Makarov [mailto:vmaka...@redhat.com] wrote: It was supposed to have two latency definitions at most (one in define_insn_reservation and another one in define_bypass). That time it seemed enough for all processors supported by GCC. It also simplified semantics definition when two bypass conditions returns true for the same insn pair. If you really need more one bypass for insn pair, I could implement this. Please, let me know. In this case semantics of choosing latency time could be o time in first bypass occurred in pipeline description whose condition returns true o time given in define_insn_reservation Maxim and I encountered the same problem, and I believe we won't be the last two unlucky guys. Can you please implement the extended semantics, which looks good to me? Ok. I think that patch will be ready tomorrow or day after tomorrow.
Re: m32c, ivopts, 20000412-6.c
On Wed, Jan 7, 2009 at 5:09 PM, DJ Delorie wrote: > >> As I repeatedly said having sizetype of a different precision than >> pointer types will cause all sorts of problems ;) > > And as I've rebutted repeatedly, I can't change the chip. > >> The middle-end generally assumes it can cast between sizetype and >> pointers arbitrarily. > > Bad assumption. It will get worse with the upcoming named address > branch work. Yeah well. It can only get fixed if we get rid of the restriction of using sizetype for POINTER_PLUS_EXPR. Which is some work. >> In the above case, what type is tmp_9, what type is tmp_16? > > The 107t dump file doesn't say, but the .128r.expand file looks like this: It should. Actually they should be the same type (the variable name is tmp). So, tmp_9 = tmp_16 + 2; D.1229_1 = (unsigned int) tmp_9; tmp_13 = (short unsigned int *) D.1229_1; if (bufend_6(D) > tmp_13) there is probably some place that inserts a useless conversion sequence (well, not useless in your case ;)) from tmp to unsigned int to short unsigned int *. I guess tmp is not short unsigned int * but some other pointer type, right? But bufend is short unsigned int *? Can you open a bugzilla for this? It should be not too difficult to track down the piece of IVOPTs that creates that conversion sequence ... Richard.
Re: Options of fixing biggest alignment in PR target/38736
"Richard Guenther" writes: > As there is no hardware implementation of AVX available I think > we definitely should stay with 16 for 4.4. That makes sense. > And IMNSHO also for > all future - __attribute__((aligned)) is part of the ABI, and if it is > not the only user of BIGGEST_ALIGNMENT then BIGGEST_ALIGNMENT > should be properly split between an ABI part and an optimization > related part. I certainly agree that they should be split. However, I don't agree that the value should be fixed for the future, if that is indeed what you are saying. __attribute__ ((aligned)) is very useful for use with portable code. It should correctly reflect the requirements of the processor. That is, there are two conflicting requirements: maintaining a stable ABI on a single platform, and supporting a cross-platform API. I would argue that code which runs on a single platform and needs a stable ABI should avoid __attribute__ ((aligned)). That leaves us with the case of a cross-platform API which wants to present a stable ABI on each platform. (gcc's unwind code could fall into this category, although it's not clear to me that the alignment is actually exposed in a way that it matters.) Is there a way that we can handle that case that is better than simply documenting changes? Ian
Re: Options of fixing biggest alignment in PR target/38736
On Wed, Jan 7, 2009 at 5:27 PM, Ian Lance Taylor wrote: > "Richard Guenther" writes: > >> As there is no hardware implementation of AVX available I think >> we definitely should stay with 16 for 4.4. > > That makes sense. > >> And IMNSHO also for >> all future - __attribute__((aligned)) is part of the ABI, and if it is >> not the only user of BIGGEST_ALIGNMENT then BIGGEST_ALIGNMENT >> should be properly split between an ABI part and an optimization >> related part. > > I certainly agree that they should be split. However, I don't agree > that the value should be fixed for the future, if that is indeed what > you are saying. __attribute__ ((aligned)) is very useful for use with > portable code. It should correctly reflect the requirements of the > processor. > > That is, there are two conflicting requirements: maintaining a stable > ABI on a single platform, and supporting a cross-platform API. I > would argue that code which runs on a single platform and needs a > stable ABI should avoid __attribute__ ((aligned)). That leaves us > with the case of a cross-platform API which wants to present a stable > ABI on each platform. (gcc's unwind code could fall into this > category, although it's not clear to me that the alignment is actually > exposed in a way that it matters.) Is there a way that we can handle > that case that is better than simply documenting changes? I agree with you if I interpret "cross-platform" as for example ppc vs. x86. But certainly not if it is x86_64 vs. x86_64 -mavx. Richard.
Re: Options of fixing biggest alignment in PR target/38736
"H.J. Lu" writes: > Fixing BIGGEST_ALIGNMENT to 16 may require extensive changes. > I am thinking to add DEFAULT_ALIGNMENT with > > #ifndef DEFAULT_ALIGNMENT > #define DEFAULT_ALIGNMENT BIGGEST_ALIGNMENT > #endif > > and use it only for attribute((aligned)). This does need to be done, but DEFAULT_ALIGNMENT is a poorly chosen name. It should be something more like ATTRIBUTE_ALIGNED_VALUE. Ian
Re: Options of fixing biggest alignment in PR target/38736
"Richard Guenther" writes: >> That is, there are two conflicting requirements: maintaining a stable >> ABI on a single platform, and supporting a cross-platform API. I >> would argue that code which runs on a single platform and needs a >> stable ABI should avoid __attribute__ ((aligned)). That leaves us >> with the case of a cross-platform API which wants to present a stable >> ABI on each platform. (gcc's unwind code could fall into this >> category, although it's not clear to me that the alignment is actually >> exposed in a way that it matters.) Is there a way that we can handle >> that case that is better than simply documenting changes? > > I agree with you if I interpret "cross-platform" as for example > ppc vs. x86. But certainly not if it is x86_64 vs. x86_64 -mavx. Yes, I mean x86_64 as a single platform, with or without -mavx. By cross-platform I mean code which is not interoperable. Ian
Re: m32c, ivopts, 20000412-6.c
> I guess tmp is not short unsigned int * but some other pointer type, > right? But bufend is short unsigned int *? Both are "short unsigned int *" - pointers to shorts. > Can you open a bugzilla for this? It should be not too difficult to track > down the piece of IVOPTs that creates that conversion sequence ... Will do.
Feature request concerning opcodes in the function prolog
Hello, I am working on the Wine project(www.winehq.org), which (obviously) uses gcc to compile its own code. There are some Windows applications like Steam(www.steampowered.com) and others which try to hook Win32 API functions by patching the first 5 bytes of the Windows API functions exported by our DLLs with a jump. Unfortunately these applications are rather picky regarding the instructions they expect in the prolog. I'm trying to add some function attributes to give Wine more control over that, but I am afraid that I need some help. This is what the average Win32 API prolog looks like: : 8b ff mov%edi,%edi : 55 push %ebp : 8b ec mov%esp,%ebp There are two differences to the code gcc generates that hurt us: 8b ff mov%edi,%edi This instruction was added by Microsoft in XP Service Pack 2 to make hooking the Win32 API functions easier. Microsoft uses it themselves for a feature they call "hotpatching", to avoid reboots after updates. Consequently many other applications try to use it. I think Microsoft generates it using the __naked__ function attribute by writing the function prolog and epilog by hand, but I saw some mails on this list which make it pretty clear that this will never ever be supported in gcc, and we don't like it ourselves and would prefer some other solution. The attached file gcc.diff contains a kinda helpless attempt to generate this instruction. My first problem is that any optimization optimizes it away because it is a NOP. Is there any way to prevent the optimizer from removing it? The second problem is that I haven't found yet how to read my attribute "ms_hook" in that code. The different trees still confuse me. Finally, is there a nicer way to specify the %edi register? Hardcoding the value 5 doesn't look pretty. 8b ec mov%esp,%ebp The problem here is the "8b ec". Binutils generates "89 e5". Its the same instruction, but the Microsoft version has the direction inversion flag set. Unfortunately the Windows apps only know the 8b ec version because that is all they find on Windows. (This flag is also set on the mov %edi, %edi above - gcc currently generates 89 ff) I talked to the binutils maintainers and they helped me by adding a new instruction suffix .s: movl%esp, %ebp => 89 e5 movl.s %esp, %ebp => eb ec Now I need gcc to set this suffix, but here I am pretty lost. I haven't found out yet how to add this to the gcc code. The other issue is compatibility with old binutils versions, since so far this feature is in svn only and no release has it. Does gcc attempt to detect binutils features, or does it just assume that everything it needs is there? Thanks for your help, Stefan Dösinger gcc.diff Description: Binary data
Re: Options of fixing biggest alignment in PR target/38736
On Wed, Jan 7, 2009 at 8:30 AM, Ian Lance Taylor wrote:
> "H.J. Lu" writes:
>
>> Fixing BIGGEST_ALIGNMENT to 16 may require extensive changes.
>> I am thinking to add DEFAULT_ALIGNMENT with
>>
>> #ifndef DEFAULT_ALIGNMENT
>> #define DEFAULT_ALIGNMENT BIGGEST_ALIGNMENT
>> #endif
>>
>> and use it only for attribute((aligned)).
>
> This does need to be done, but DEFAULT_ALIGNMENT is a poorly chosen
> name. It should be something more like ATTRIBUTE_ALIGNED_VALUE.
>
> Ian
>
Here is a patch to implement ATTRIBUTE_ALIGNED_VALUE. OK for trunk?
Thanks.
--
H.J.
---
gcc/
2009-01-07 H.J. Lu
PR target/38736
* c-common.c (handle_aligned_attribute): Use
ATTRIBUTE_ALIGNED_VALUE instead of ATTRIBUTE_ALIGNED_VALUE for
default alignment value.
* defaults.h (ATTRIBUTE_ALIGNED_VALUE): New.
* config/i386/i386.h (ATTRIBUTE_ALIGNED_VALUE): Likewise.
* doc/extend.texi: Update __attribute__ ((aligned)) with
ATTRIBUTE_ALIGNED_VALUE.
* doc/tm.texi: Document ATTRIBUTE_ALIGNED_VALUE.
gcc/testsuite/
2009-01-07 H.J. Lu
PR target/38736
* g++.dg/other/pr38736-1.C: New.
* g++.dg/other/pr38736-2.C: Likewise.
* gcc.target/i386/pr38736-1.c: Likewise.
* gcc.target/i386/pr38736-2.c: Likewise.
gcc/
2009-01-07 H.J. Lu
PR target/38736
* c-common.c (handle_aligned_attribute): Use
ATTRIBUTE_ALIGNED_VALUE instead of ATTRIBUTE_ALIGNED_VALUE for
default alignment value.
* defaults.h (ATTRIBUTE_ALIGNED_VALUE): New.
* config/i386/i386.h (ATTRIBUTE_ALIGNED_VALUE): Likewise.
* doc/extend.texi: Update __attribute__ ((aligned)) with
ATTRIBUTE_ALIGNED_VALUE.
* doc/tm.texi: Document ATTRIBUTE_ALIGNED_VALUE.
gcc/testsuite/
2009-01-07 H.J. Lu
PR target/38736
* g++.dg/other/pr38736-1.C: New.
* g++.dg/other/pr38736-2.C: Likewise.
* gcc.target/i386/pr38736-1.c: Likewise.
* gcc.target/i386/pr38736-2.c: Likewise.
Index: gcc/doc/extend.texi
===
--- gcc/doc/extend.texi (revision 4884)
+++ gcc/doc/extend.texi (working copy)
@@ -3697,9 +3697,8 @@ that forces the union to be double-word
As in the preceding examples, you can explicitly specify the alignment
(in bytes) that you wish the compiler to use for a given variable or
structure field. Alternatively, you can leave out the alignment factor
-and just ask the compiler to align a variable or field to the maximum
-useful alignment for the target machine you are compiling for. For
-example, you could write:
+and use @code{ATTRIBUTE_ALIGNED_VALUE} for the target machine you are
+compiling for. For example, you could write:
@smallexample
short array[3] __attribute__ ((aligned));
@@ -3707,11 +3706,11 @@ short array[3] __attribute__ ((aligned))
Whenever you leave out the alignment factor in an @code{aligned} attribute
specification, the compiler automatically sets the alignment for the declared
-variable or field to the largest alignment which is ever used for any data
-type on the target machine you are compiling for. Doing this can often make
-copy operations more efficient, because the compiler can use whatever
-instructions copy the biggest chunks of memory when performing copies to
-or from the variables or fields that you have aligned this way.
+variable or field to @code{ATTRIBUTE_ALIGNED_VALUE}. Doing this can
+often make copy operations more efficient, because the compiler can use
+whatever instructions copy the biggest chunks of memory aligned at
+...@code{attribute_aligned_value} when performing copies to or from the
+variables or fields that you have aligned this way.
When used on a struct, or struct member, the @code{aligned} attribute can
only increase the alignment; in order to decrease it, the @code{packed}
Index: gcc/doc/tm.texi
===
--- gcc/doc/tm.texi (revision 4884)
+++ gcc/doc/tm.texi (working copy)
@@ -1105,6 +1105,11 @@ Alignment, in bits, a C conformant mallo
provide. If not defined, the default value is @code{BITS_PER_WORD}.
@end defmac
+...@defmac ATTRIBUTE_ALIGNED_VALUE
+Alignment used by the @code{__attribute__ ((aligned))} construct. If
+not defined, the default value is @code{BIGGEST_ALIGNMENT}.
+...@end defmac
+
@defmac MINIMUM_ATOMIC_ALIGNMENT
If defined, the smallest alignment, in bits, that can be given to an
object that can be referenced in one operation, without disturbing any
Index: gcc/defaults.h
===
--- gcc/defaults.h (revision 4884)
+++ gcc/defaults.h (working copy)
@@ -944,4 +944,9 @@ along with GCC; see the file COPYING3.
((TYPE) ? LOCAL_ALIGNMENT ((TYPE), (ALIGN)) : (ALIGN))
#endif
+/* Alignment value for attribute ((aligned)). */
+#ifndef ATTRIBUTE_ALIGNED_VALUE
+#define ATTRIBUTE_ALI
Re: Options of fixing biggest alignment in PR target/38736
"H.J. Lu" writes:
> Index: gcc/doc/extend.texi
> ===
> --- gcc/doc/extend.texi (revision 4884)
> +++ gcc/doc/extend.texi (working copy)
> @@ -3697,9 +3697,8 @@ that forces the union to be double-word
> As in the preceding examples, you can explicitly specify the alignment
> (in bytes) that you wish the compiler to use for a given variable or
> structure field. Alternatively, you can leave out the alignment factor
> -and just ask the compiler to align a variable or field to the maximum
> -useful alignment for the target machine you are compiling for. For
> -example, you could write:
> +and use @code{ATTRIBUTE_ALIGNED_VALUE} for the target machine you are
> +compiling for. For example, you could write:
>
> @smallexample
> short array[3] __attribute__ ((aligned));
> @@ -3707,11 +3706,11 @@ short array[3] __attribute__ ((aligned))
>
> Whenever you leave out the alignment factor in an @code{aligned} attribute
> specification, the compiler automatically sets the alignment for the declared
> -variable or field to the largest alignment which is ever used for any data
> -type on the target machine you are compiling for. Doing this can often make
> -copy operations more efficient, because the compiler can use whatever
> -instructions copy the biggest chunks of memory when performing copies to
> -or from the variables or fields that you have aligned this way.
> +variable or field to @code{ATTRIBUTE_ALIGNED_VALUE}. Doing this can
> +often make copy operations more efficient, because the compiler can use
> +whatever instructions copy the biggest chunks of memory aligned at
> +...@code{attribute_aligned_value} when performing copies to or from the
> +variables or fields that you have aligned this way.
ATTRIBUTE_ALIGNED_VALUE is an internal compiler macro. extend.texi is
external user documentation. extend.texi should not documented the
attribute in terms of ATTRIBUTE_ALIGNED_VALUE.
> Index: gcc/testsuite/gcc.target/i386/pr38736-2.c
> ===
> --- gcc/testsuite/gcc.target/i386/pr38736-2.c (revision 0)
> +++ gcc/testsuite/gcc.target/i386/pr38736-2.c (revision 0)
> @@ -0,0 +1,19 @@
> +/* PR target/38736 */
> +/* { dg-do run } */
> +/* { dg-require-effective-target avx } */
> +/* { dg-options "-O2 -mavx" } */
> +
> +extern void abort (void);
> +
> +struct alignment_test_struct
> +{
> + char space[4] __attribute__((__aligned__));
> +};
> +
> +int
> +main ()
> +{
> + if (__alignof__(struct alignment_test_struct) != 16)
> +abort ();
> + return 0;
> +}
This test case seems to be asserting that attribute ((aligned)) should
always align to a 16-byte boundary on x86. It is not clear to me that
that should be the case. In fact, I tend to think that it should not
be the case.
It would be better to (somehow) have a multi-file test which checked
that attributed ((aligned)) has the same value with and without -mavx.
> +/* Alignment value for attribute ((aligned)). It is a constant
> + since it is the part of the ABI. */
> +#define ATTRIBUTE_ALIGNED_VALUE 128
Please add some comment here about the AVX issue.
Ian
Re: Feature request concerning opcodes in the function prolog
On Wed, Jan 7, 2009 at 10:05 AM, Stefan Dösinger wrote: > > I talked to the binutils maintainers and they helped me by adding a new > instruction suffix .s: > movl%esp, %ebp => 89 e5 > movl.s %esp, %ebp => eb ec > > Now I need gcc to set this suffix, but here I am pretty lost. I haven't > found out yet how to add this to the gcc code. The other issue is > compatibility with old binutils versions, since so far this feature is in > svn only and no release has it. Does gcc attempt to detect binutils > features, or does it just assume that everything it needs is there? > You need to check assembler feature with autconf before using them. See HAVE_AS_IX86_SAHF as example. FWIW, Linux binutils 2.19.51.0.1 supports .s suffix. -- H.J.
RE: Feature request concerning opcodes in the function prolog
> -Original Message- > From: H.J. Lu [mailto:hjl.to...@gmail.com] Nice to see a familiar face, or better, mail address :-) > You need to check assembler feature with autconf before using them. > See HAVE_AS_IX86_SAHF as example. Thanks! Does that look ok? It seems to detect the support correctly for me: gcc_GAS_CHECK_FEATURE([swap suffix], gcc_cv_as_ix86_swap,,, [movl.s %esp, %ebp],, [AC_DEFINE(HAVE_AS_IX86_SWAP, 1, [Define if your assembler supports the swap suffix.])])
Re: Feature request concerning opcodes in the function prolog
The attached file gcc.diff contains a kinda helpless attempt to generate this instruction. My first problem is that any optimization optimizes it away because it is a NOP. Is there any way to prevent the optimizer from removing it? You can make a new instruction pattern with an UNSPEC_VOLATILE pattern. For a quick prototype you could also use an assembler prologue, although if you need not experiment with different insn sequences, this will likely be more work in the long run if/when assembler prologues are eventually discontinued. Finally, is there a nicer way to specify the %edi register? Hardcoding the value 5 doesn't look pretty. You can use a define_constants definition in the .md file to give a symbolic name to such constants. i386.md already has DI_REG . Now I need gcc to set this suffix, but here I am pretty lost. I haven't found out yet how to add this to the gcc code. This becomes a non-issue when you define your own UNSPEC_VOLATILE pattern or assembler prologue. The other issue is compatibility with old binutils versions, since so far this feature is in svn only and no release has it. You could fall back to .byte / .short directives to emit specific opcodes.
RE: Feature request concerning opcodes in the function prolog
> You can make a new instruction pattern with an UNSPEC_VOLATILE pattern. > For a quick prototype you could also use an assembler prologue, > although > if you need not experiment with different insn sequences, this will > likely > be more work in the long run if/when assembler prologues are eventually > discontinued. Thanks for the hint - I'll see what I can find. Do you have any hints for good examples in the existing code? > > Now I need gcc to set this suffix, but here I am pretty lost. I > haven't > > found out yet how to add this to the gcc code. > > This becomes a non-issue when you define your own UNSPEC_VOLATILE > pattern > or assembler prologue. Ideally I'd like to set this suffix on all instructions in a function(gas ignores the suffix on instrs that don't support it). I'll probably survive if this is just set on the mov %edi, %edi and mov %esp, %ebp. But unfortunately not all functions apps try to hook have the mov %edi, %edi, but apps still try to hook them. This means that 2 bytes remain problematic, and on those there's often a xor %eax, %eax (which is either 31 c0 or 33 c0) or a sub modifying the stack pointer. So the problem potentially goes beyond the prologue.
RE: Feature request concerning opcodes in the function prolog
Quoting Stefan Dösinger : Thanks for the hint - I'll see what I can find. Do you have any hints for good examples in the existing code? An example of an unspec_volatile instruction pattern in config/i386/i386.md is "cld". Note that by giving the pattern a name which is not prefixed with '*', a generator function will be emitted when you build gcc (gen_cld for the cld example; it is used in i386.md). For examples of assembler prologues, grep config/*/*.c for TARGET_ASM_FUNCTION_PROLOGUE . Note that you can have both an asm prologue and an rtl prologue, which is ugly, but flexible ;-) Ideally I'd like to set this suffix on all instructions in a function(gas ignores the suffix on instrs that don't support it). I'll probably survive if this is just set on the mov %edi, %edi and mov %esp, %ebp. But unfortunately not all functions apps try to hook have the mov %edi, %edi, but apps still try to hook them. This means that 2 bytes remain problematic, and on those there's often a xor %eax, %eax (which is either 31 c0 or 33 c0) or a sub modifying the stack pointer. So the problem potentially goes beyond the prologue. gcc has the concept of assembler dialects, where you can have different syntax depending on an invocation option; or you could use some % directive in the assembler template to emit - or not emit - a suffix. But since you have to have a new gas anyway, wouldn't it be simpler to have a new option for gas to instruct it to choose the opcodes that are expected by the win32 applications? Or do they require different opcodes for the same instruction in different places, e.g an 8bec movl esp,ebp in the prologue and a 89e5 movl esp,ebp for address arithmetic in an -fomit-frame-pointer (or the moral equivalent) compiled function?
RE: Feature request concerning opcodes in the function prolog
> An example of an unspec_volatile instruction pattern in > config/i386/i386.md > is "cld". I ran across that, your hints should give me some information to chew on for the next hours. Currently I am compiling with this code to see what happens: (define_insn "movnop" [(unspec_volatile [(const_int 0)] UNSPECV_MOVNOP)] "" "movl.r\t%edi,%edi" [(set_attr "length" "2") (set_attr "length_immediate" "0") (set_attr "modrm" "0")]) and then a gen_movnop(/* better name anyone? */) to use it. Lets see what happens > But since you have to have a new gas anyway, wouldn't it be simpler to > have > a new option for gas to instruct it to choose the opcodes that are > expected > by the win32 applications? This was my first idea, but Alexandre Julliard(the Wine maintainer) disliked it and prefered a function attribute to turn it on per-function. However, from looking at the gcc code it seems that this is the best option to generate Win32-friendly code everywhere. I'll look at your other suggestions and talk to Alexandre again.
Re: Feature request concerning opcodes in the function prolog
>> But since you have to have a new gas anyway, wouldn't it be simpler to >> have >> a new option for gas to instruct it to choose the opcodes that are >> expected >> by the win32 applications? > This was my first idea, but Alexandre Julliard(the Wine maintainer) disliked > it and prefered a function attribute to turn it on per-function. However, > from looking at the gcc code it seems that this is the best option to > generate Win32-friendly code everywhere. I'll look at your other suggestions > and talk to Alexandre again. Indeed the option would just have to flip the movl/movl.s default... Paolo
gcc-4.2-20090107 is now available
Snapshot gcc-4.2-20090107 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20090107/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 4.2 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-4_2-branch revision 143167 You'll find: gcc-4.2-20090107.tar.bz2 Complete GCC (includes all of below) gcc-core-4.2-20090107.tar.bz2 C front end and core compiler gcc-ada-4.2-20090107.tar.bz2 Ada front end and runtime gcc-fortran-4.2-20090107.tar.bz2 Fortran front end and runtime gcc-g++-4.2-20090107.tar.bz2 C++ front end and runtime gcc-java-4.2-20090107.tar.bz2 Java front end and runtime gcc-objc-4.2-20090107.tar.bz2 Objective-C front end and runtime gcc-testsuite-4.2-20090107.tar.bz2The GCC testsuite Diffs from 4.2-20081231 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-4.2 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.
Re: Options of fixing biggest alignment in PR target/38736
Jakub pointed out on gcc-patches that changing the value of __attribute__ ((aligned)) has difficulties. Historically this value was never intended to be fixed for all time. For example, for the i386, it was last changed here: Tue Jan 18 16:19:55 MET 2000 Jan Hubicka * i386.h (BIGGEST_ALIGNMENT): Set to 128. However, people have erroneously assumed that the value is fixed, and they have hardcoded the value into ABIs. We even did that ourselves for struct _Unwind_Exception in gcc/unwind-generic.h. The C++ ABI says the structure needs to be double-word aligned, but our code says this: /* @@@ The IA-64 ABI says that this structure must be double-word aligned. Taking that literally does not make much sense generically. Instead we provide the maximum alignment required by any type for the machine. */ } __attribute__((__aligned__)); This has been the case since the structure was added in 2001. There is a clear use for __attribute__ ((aligned)) returning the maximal required alignment. Something like that is required for writing a generic memory allocation routine, one which does the right thing for arrays in the presence of auto-vectorization optimizations. Unfortunately we have now worked ourselves into a corner where changing __attribute__ ((aligned)) changes the ABI. Therefore, I propose that we do the following: 1) Introduce __attribute__ ((aligned (scalar))). This will be documented as having a fixed value for each ABI. The value will be guaranteed to be sufficient to hold any ordinary non-vector type. The default will be BIGGEST_ALIGNMENT. The value for the x86/x86_64 will be 128. 2) Introduce __attribute__ ((aligned (max))). This will be documented as having the largest value available for any version of the architecture, and thus in particular it may change if new versions of the architecture are released. The value will not change based on command line options which do not change the ABI; that is, if it is possible to link together two files compiled with different set of command line options and expect the result to work, then those command line options must not change the value of this attribute. The value will be guaranteed to be sufficient to hold any type, including any vector type. The default will be BIGGEST_ALIGNMENT. The value for the x86/x86_64 will (presumably) be 256. 3) Deprecate __attribute__ ((aligned)). While it remains, it will have the value of __attribute__ ((aligned (scalar))). For 4.4 it will remain unchanged. For 4.5 we will warn about under control of -Wno-deprecated. In 4.8 or 5.0, whichever comes first, we will remove it. Ian
Re: Options of fixing biggest alignment in PR target/38736
On Wed, Jan 7, 2009 at 2:47 PM, Ian Lance Taylor wrote: > 2) Introduce __attribute__ ((aligned (max))). This will be documented > as having the largest value available for any version of the > architecture, and thus in particular it may change if new versions > of the architecture are released. The value will not change based > on command line options which do not change the ABI; that is, if it > is possible to link together two files compiled with different set > of command line options and expect the result to work, then those > command line options must not change the value of this attribute. > The value will be guaranteed to be sufficient to hold any type, > including any vector type. The default will be BIGGEST_ALIGNMENT. > The value for the x86/x86_64 will (presumably) be 256. > 256 isn't big enough. There are 512bit vectors in the future: http://en.wikipedia.org/wiki/Larrabee_(GPU) 1024bit vector isn't impossible either. -- H.J.
Re: Options of fixing biggest alignment in PR target/38736
"H.J. Lu" writes: > On Wed, Jan 7, 2009 at 2:47 PM, Ian Lance Taylor wrote: >> 2) Introduce __attribute__ ((aligned (max))). This will be documented >> as having the largest value available for any version of the >> architecture, and thus in particular it may change if new versions >> of the architecture are released. The value will not change based >> on command line options which do not change the ABI; that is, if it >> is possible to link together two files compiled with different set >> of command line options and expect the result to work, then those >> command line options must not change the value of this attribute. >> The value will be guaranteed to be sufficient to hold any type, >> including any vector type. The default will be BIGGEST_ALIGNMENT. >> The value for the x86/x86_64 will (presumably) be 256. >> > > 256 isn't big enough. There are 512bit vectors in the future: > > http://en.wikipedia.org/wiki/Larrabee_(GPU) > > 1024bit vector isn't impossible either. Of course a 1024 bit vector need not require 1024 bit alignment. In any case, we can set it higher now if we want, or we can wait until we support those processors. Ian
RE: Options of fixing biggest alignment in PR target/38736
From: Ian Lance Taylor [mailto:i...@google.com]: > Therefore, I propose that we do the following: > > 1) Introduce __attribute__ ((aligned (scalar))). This will be >documented as having a fixed value for each ABI. The value will be >guaranteed to be sufficient to hold any ordinary non-vector type. >The default will be BIGGEST_ALIGNMENT. The value for the >x86/x86_64 will be 128. > > 2) Introduce __attribute__ ((aligned (max))). This will be documented >as having the largest value available for any version of the >architecture, and thus in particular it may change if new versions >of the architecture are released. The value will not change based >on command line options which do not change the ABI; that is, if it >is possible to link together two files compiled with different set >of command line options and expect the result to work, then those >command line options must not change the value of this attribute. >The value will be guaranteed to be sufficient to hold any type, >including any vector type. The default will be BIGGEST_ALIGNMENT. >The value for the x86/x86_64 will (presumably) be 256. To me "new version of x86 architecture are released" usually means "change based on command line option". How about the default value grow to 512 or even higher in future? Thanks - Joey
Re: Options of fixing biggest alignment in PR target/38736
"Ye, Joey" writes: > From: Ian Lance Taylor [mailto:i...@google.com]: >> Therefore, I propose that we do the following: >> >> 1) Introduce __attribute__ ((aligned (scalar))). This will be >>documented as having a fixed value for each ABI. The value will be >>guaranteed to be sufficient to hold any ordinary non-vector type. >>The default will be BIGGEST_ALIGNMENT. The value for the >>x86/x86_64 will be 128. >> >> 2) Introduce __attribute__ ((aligned (max))). This will be documented >>as having the largest value available for any version of the >>architecture, and thus in particular it may change if new versions >>of the architecture are released. The value will not change based >>on command line options which do not change the ABI; that is, if it >>is possible to link together two files compiled with different set >>of command line options and expect the result to work, then those >>command line options must not change the value of this attribute. >>The value will be guaranteed to be sufficient to hold any type, >>including any vector type. The default will be BIGGEST_ALIGNMENT. >>The value for the x86/x86_64 will (presumably) be 256. > To me "new version of x86 architecture are released" usually means > "change based on command line option". How about the default value > grow to 512 or even higher in future? There is a command line option change, sure, but in general, as far as I know, files compiled with -march=NEW can be linked with files compiled with -march=OLD, and the result is expected to work. If that is not the case--if files compiled with -march=avx and -march=i386 (or -march=nocona) can not be linked together and work--then there is no problem here. Ian
Re: Mixing languages in the same TU and dwarf2out_frame_finish
> However, on LTO, we may have several personality functions in the same > object file. So, it's not clear what should we do here. Should we > call dwarf2out_frame_finish() for each of the personalities that we > saw in that file? I don't think so. We're calling dwarf2out_frame_finish() at the end of the TU, not at the end of each function, and it generates the CFI information for all functions in the TU at once. I think you're going to need to do the following: - In dwarf2out_begin_prologue, store the value of get_personality_function (current_function_decl) in the fde_table entry for the current function. - In output_call_frame_info, scan the fde_table, and generate a separate CIE record for each unique personality function -- this is where the pointer to the personality routine is recorded. Then when generating the FDE records, set the CIE_pointer field to point to the appropriate CIE record. Currently, all FDE records share a single CIE record. On the other hand, if you can arrange for dwarf2out_do_cfi_asm() to return true, the assembler should take care of it already. -cary
