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:
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 t
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 t
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
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 +
> 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
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.
ch
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;
>/
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 Li
> 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 ti
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 h
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 som
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 mak
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;
>//
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. Howeve
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.
>
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
> m
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 s
"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
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 compi
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 compi
> 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
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 defi
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 siz
"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 the
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 o
"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 DEFAUL
"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
> 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 con
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
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 o
"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 precedi
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
> -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
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 p
> 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 eventu
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
'*',
> 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
>> 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 funct
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
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_
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 relea
"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
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-ve
"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
> 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 en
46 matches
Mail list logo
