Re: For testing: full __float128 patch

[Gerald Pfeifer]

On Mon, 30 Aug 2010, Uros Bizjak wrote:
> Oh, additional patch for libgcc is also needed. Attached patch will
> enable filtering out TImode on 32bits and will also enable fallbacks
> for the two missing functions, so no need for any other changes.
> 
> Can you please regression test these two patches on freebsd (32 and 64 
> bit)?

Tests running...

Steve, I assume you run a number of bootstrap+test cycles over time? Would 
you mind submitting your results to gcc-testresults as well? So far I'm 
the only one doing that for FreeBSD it seems, and comparisons etc. would
be useful.

Gerald

built-in atomic functions

[manju k]

Hello,

Are there any new built-in implementations equivalent to atomic_read and 
atomic_write in latest releases ?
if not should I rely on trick suggested in one of the earlier discussions as 
below ?

  ">>We don't have atomic read or atomic write builtins (ok, you could

>>abuse __sync_fetch_and_add (&x, 0) for atomic read and a loop
>>with __sync_compare_and_swap_val for atomic store, but that's a horrible
>>overkill."
Also I am looking for atomic_set, I do not see any __sync* functions.
but from atomic.h, atomic_set just does a normal assignment, so doing the same 
should be safe enough?

Thanks for any help.

Thanks and Regards,
Manju



  

How is the definition of stack canary on MIPS arch?

[Adam Jiang]

Hello,

How is the definition of stack canery on MIPS arch? Where can I find a
specific on this topic?

When I read the source in Linux kerne, it was said that stack canary for
implementing stack protector is defined as an offset to %gs on x86
architecture. How about stack canary defined on MIPS?

Best regards,
/Adam

Re: GCC 4.5.1 Released

[Linju Baby John]

thanku for giving me all notifications of gcc release..

On 8/8/10, Richard Guenther  wrote:
>
> The GNU Compiler Collection version 4.5.1 has been released.
>
> GCC 4.5.1 is a bug-fix release containing fixes for regressions and
> serious bugs in GCC 4.5.0.  This release is available from the
> FTP servers listed at:
>
>   http://www.gnu.org/order/ftp.html
>
> Please do not contact me directly regarding questions or comments about
> this release.  Instead, use the resources available from
> http://gcc.gnu.org.
>
> As always, a vast number of people contributed to this GCC release -- far
> too many to thank individually!
>

Re: Add uninitialized attribute?

[Michael Matz]

Hi,

On Fri, 20 Aug 2010, H.J. Lu wrote:

> int x = 0;
> 
> to silence gcc from uninitialized warnings when I know it is
> unnecessary.  Is that a good idea to add
> 
> int x __attribute__ ((uninitialized));
> 
> to tell compiler that it is OK for "x" to be uninitialized?

int x = x;

is the way GCC offers this idiom since about forever, no need for an 
attribute.  Downthread I see that people worry about this generating an 
actual (uninitialized) access to x.  They are confused.


Ciao,
Michael.

Re: Add uninitialized attribute?

[Vincent Lefevre]

On 2010-08-30 14:46:57 +0200, Michael Matz wrote:
> int x = x;
> 
> is the way GCC offers this idiom since about forever, no need for an 
> attribute.  Downthread I see that people worry about this generating an 
> actual (uninitialized) access to x.  They are confused.

This is not a good idea as "int x = x;" may really generate an
(uninitialized) access to x with other compilers.

-- 
Vincent Lefèvre  - Web: 
100% accessible validated (X)HTML - Blog: 
Work: CR INRIA - computer arithmetic / Arénaire project (LIP, ENS-Lyon)

Re: For testing: full __float128 patch

[Gerald Pfeifer]

On Mon, 30 Aug 2010, Gerald Pfeifer wrote:
>> Can you please regression test these two patches on freebsd (32 and 64 
>> bit)?
> Tests running...

Looks like a nice improvement, actually.  On both this fixes previously
existing test failures and adds some passes (no changes on the failure
side on i386).

>From all I can tell, please go ahead, Uros. :-)  I wonder whether these
might also be suitable for GCC 4.5?



First x86_64-unknown-freebsd8.1 (cf. 
http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg02964.html without
and http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg02959.html with):

=== gcc tests ===
 
-FAIL: gcc.dg/torture/fp-int-convert-float128-timode.c  -O0  (test for excess 
errors)
-WARNING: gcc.dg/torture/fp-int-convert-float128-timode.c  -O0  compilation 
failed to produce executable
-FAIL: gcc.dg/torture/fp-int-convert-float128-timode.c  -O1  (test for excess 
errors)
-WARNING: gcc.dg/torture/fp-int-convert-float128-timode.c  -O1  compilation 
failed to produce executable
-FAIL: gcc.dg/torture/fp-int-convert-float128-timode.c  -O2  (test for excess 
errors)
-WARNING: gcc.dg/torture/fp-int-convert-float128-timode.c  -O2  compilation 
failed to produce executable
-FAIL: gcc.dg/torture/fp-int-convert-float128-timode.c  -O3 
-fomit-frame-pointer  (test for excess errors)
-WARNING: gcc.dg/torture/fp-int-convert-float128-timode.c  -O3 
-fomit-frame-pointer  compilation failed to produce executable
-FAIL: gcc.dg/torture/fp-int-convert-float128-timode.c  -O3 -g  (test for 
excess errors)
-WARNING: gcc.dg/torture/fp-int-convert-float128-timode.c  -O3 -g  compilation 
failed to produce executable
-FAIL: gcc.dg/torture/fp-int-convert-float128-timode.c  -Os  (test for excess 
errors)
-WARNING: gcc.dg/torture/fp-int-convert-float128-timode.c  -Os  compilation 
failed to produce executable
-FAIL: gcc.dg/torture/fp-int-convert-float128.c  -O0  (test for excess errors)
-WARNING: gcc.dg/torture/fp-int-convert-float128.c  -O0  compilation failed to 
produce executable
-FAIL: gcc.dg/torture/fp-int-convert-float128.c  -O1  (test for excess errors)
-WARNING: gcc.dg/torture/fp-int-convert-float128.c  -O1  compilation failed to 
produce executable
-FAIL: gcc.dg/torture/fp-int-convert-float128.c  -O2  (test for excess errors)
-WARNING: gcc.dg/torture/fp-int-convert-float128.c  -O2  compilation failed to 
produce executable
-FAIL: gcc.dg/torture/fp-int-convert-float128.c  -O3 -fomit-frame-pointer  
(test for excess errors)
-WARNING: gcc.dg/torture/fp-int-convert-float128.c  -O3 -fomit-frame-pointer  
compilation failed to produce executable
-FAIL: gcc.dg/torture/fp-int-convert-float128.c  -O3 -g  (test for excess 
errors)
-WARNING: gcc.dg/torture/fp-int-convert-float128.c  -O3 -g  compilation failed 
to produce executable
-FAIL: gcc.dg/torture/fp-int-convert-float128.c  -Os  (test for excess errors)
-WARNING: gcc.dg/torture/fp-int-convert-float128.c  -Os  compilation failed to 
produce executable
 
=== gcc Summary ===
 
-# of expected passes   60905
-# of unexpected failures   21
+# of expected passes   60929
+# of unexpected failures   9



Second, i386-unknown-freebsd7.1 (cf. 
http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg02948.html without, 
and http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg02975.html with):

=== gcc tests ===
 
@@ -127,30 +127,6 @@
 FAIL: gcc.dg/torture/fp-int-convert-float.c  -O3 -fomit-frame-pointer  
execution test
 FAIL: gcc.dg/torture/fp-int-convert-float.c  -O3 -g  execution test
 FAIL: gcc.dg/torture/fp-int-convert-float.c  -Os  execution test
-FAIL: gcc.dg/torture/fp-int-convert-float128-timode.c  -O0  (test for excess 
errors)
-WARNING: gcc.dg/torture/fp-int-convert-float128-timode.c  -O0  compilation 
failed to produce executable
-FAIL: gcc.dg/torture/fp-int-convert-float128-timode.c  -O1  (test for excess 
errors)
-WARNING: gcc.dg/torture/fp-int-convert-float128-timode.c  -O1  compilation 
failed to produce executable
-FAIL: gcc.dg/torture/fp-int-convert-float128-timode.c  -O2  (test for excess 
errors)
-WARNING: gcc.dg/torture/fp-int-convert-float128-timode.c  -O2  compilation 
failed to produce executable
-FAIL: gcc.dg/torture/fp-int-convert-float128-timode.c  -O3 
-fomit-frame-pointer  (test for excess errors)
-WARNING: gcc.dg/torture/fp-int-convert-float128-timode.c  -O3 
-fomit-frame-pointer  compilation failed to produce executable
-FAIL: gcc.dg/torture/fp-int-convert-float128-timode.c  -O3 -g  (test for 
excess errors)
-WARNING: gcc.dg/torture/fp-int-convert-float128-timode.c  -O3 -g  compilation 
failed to produce executable
-FAIL: gcc.dg/torture/fp-int-convert-float128-timode.c  -Os  (test for excess 
errors)
-WARNING: gcc.dg/torture/fp-int-convert-float128-timode.c  -Os  compilation 
failed to produce executable
-FAIL: gcc.dg/torture/fp-int-convert-float128.c  -O0  (test for excess errors)
-WARNING: gcc.dg/torture/fp-int-convert-float128.c  -O0  compilation failed to 
produce executable
-FAIL: gcc.

Re: How is the definition of stack canary on MIPS arch?

[Richard Henderson]

On 08/30/2010 03:45 AM, Adam Jiang wrote:
> When I read the source in Linux kerne, it was said that stack canary for
> implementing stack protector is defined as an offset to %gs on x86
> architecture. How about stack canary defined on MIPS?

It's not implemented for MIPS.


r~

Re: For testing: full __float128 patch

[Joseph S. Myers]

On Mon, 30 Aug 2010, Gerald Pfeifer wrote:

> On Mon, 30 Aug 2010, Gerald Pfeifer wrote:
> >> Can you please regression test these two patches on freebsd (32 and 64 
> >> bit)?
> > Tests running...
> 
> Looks like a nice improvement, actually.  On both this fixes previously
> existing test failures and adds some passes (no changes on the failure
> side on i386).
> 
> From all I can tell, please go ahead, Uros. :-)  I wonder whether these
> might also be suitable for GCC 4.5?

Assuming that symbol versioning is enabled on FreeBSD, you need to set 
appropriate versions for all the new symbols in libgcc_s - which would be 
GCC_4.6.0 for something going on trunk only but GCC_4.5.2 for something 
going on 4.5 as well (and with the right %inherit settings in any case).

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: For testing: full __float128 patch

[Steve Kargl]

On Mon, Aug 30, 2010 at 08:28:58AM +0200, Uros Bizjak wrote:
> 
> Oh, additional patch for libgcc is also needed. Attached patch will
> enable filtering out TImode on 32bits and will also enable fallbacks
> for the two missing functions, so no need for any other changes.
> 
> Can you please regression test these two patches on freebsd (32 and 64 bit)?
> 
> Uros.

I won't be able to test the new patch until
later tonight (about 10 hours from now 10:30 am PST).
Gerald's testing appears to show good results.

-- 
Steve

Re: 2010 GCC and GNU Toolchain Developers' Summit

[Toon Moene]

NightStrike wrote:


On Thu, Aug 12, 2010 at 4:22 PM, I  wrote:



Perhaps some from the gfortran effort would like to give a talk.  As far  as
I can see I can support one person financially (trip from Europe to Ottawa
vice versa and stay in "Les Suites").


Only a gfortran person?  Because I'd like to nominate Kai Tietz for
that, if he's willing to accept.


Well, obviously, I mostly interested in the progress of the Mother Of 
All Programming Languages, but I might be persuaded to fund a lesser cause.


[ Add :-)'s to taste ]

--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG  Maartensdijk, The Netherlands
At home: http://moene.org/~toon/; weather: http://moene.org/~hirlam/
Progress of GNU Fortran: http://gcc.gnu.org/gcc-4.5/changes.html#Fortran

Re: For testing: full __float128 patch

[Uros Bizjak]

On Mon, Aug 30, 2010 at 6:48 PM, Joseph S. Myers
 wrote:

>> >> Can you please regression test these two patches on freebsd (32 and 64
>> >> bit)?
>> > Tests running...
>>
>> Looks like a nice improvement, actually.  On both this fixes previously
>> existing test failures and adds some passes (no changes on the failure
>> side on i386).
>>
>> From all I can tell, please go ahead, Uros. :-)  I wonder whether these
>> might also be suitable for GCC 4.5?
>
> Assuming that symbol versioning is enabled on FreeBSD, you need to set
> appropriate versions for all the new symbols in libgcc_s - which would be
> GCC_4.6.0 for something going on trunk only but GCC_4.5.2 for something
> going on 4.5 as well (and with the right %inherit settings in any case).

I'm not familiar in versioning stuff, but since soft-fp symbols are
part of generic libgcc-std.ver for a long time (before 4.5.0), I
believe, it is enough to patch only configure files (see i.e. commits
that enabled soft-fp on mingw/cygwin/-gnu*).

gcc/ChangeLog:

2010-08-30  Uros Bizjak  

* config.gcc: Add i386/t-fprules-softfp and soft-fp/t-softfp
to tmake_file for i[34567]86-*-freebsd* and x86_64-*-freebsd*.

libgcc/ChangeLog:

2010-08-30  Uros Bizjak  

* config.host: Add i386/${host_address}/t-fprules-softfp and
t-softfp to tmake_file for i[34567]86-*-freebsd* and x86_64-*-freebsd*.

Tested by Gerald. OK for 4.5.2 and mainline?

Uros.
Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 163647)
+++ gcc/config.gcc  (working copy)
@@ -3485,6 +3485,9 @@
i[34567]86-*-cygwin* | i[34567]86-*-mingw* | x86_64-*-mingw*)
tmake_file="${tmake_file} i386/t-fprules-softfp 
soft-fp/t-softfp"
;;
+   i[34567]86-*-freebsd* | x86_64-*-freebsd*)
+   tmake_file="${tmake_file} i386/t-fprules-softfp 
soft-fp/t-softfp"
+   ;;
ia64*-*-linux*)
tmake_file="${tmake_file} ia64/t-fprules-softfp 
soft-fp/t-softfp"
;;
Index: libgcc/config.host
===
--- libgcc/config.host  (revision 163647)
+++ libgcc/config.host  (working copy)
@@ -608,7 +608,8 @@
   i[34567]86-*-linux* | x86_64-*-linux* | \
   i[34567]86-*-gnu* | \
   i[34567]86-*-solaris2* | \
-  i[34567]86-*-cygwin* | i[34567]86-*-mingw* | x86_64-*-mingw*)
+  i[34567]86-*-cygwin* | i[34567]86-*-mingw* | x86_64-*-mingw* | \
+  i[34567]86-*-freebsd* | x86_64-*-freebsd*)
if test "${host_address}" = 32; then
tmake_file="${tmake_file} t-softfp 
i386/${host_address}/t-fprules-softfp"
fi

Re: 2010 GCC and GNU Toolchain Developers' Summit

[NightStrike]

On Mon, Aug 30, 2010 at 1:33 PM, Toon Moene  wrote:
> NightStrike wrote:
>
>> On Thu, Aug 12, 2010 at 4:22 PM, I  wrote:
>
>>> Perhaps some from the gfortran effort would like to give a talk.  As far
>>>  as
>>> I can see I can support one person financially (trip from Europe to
>>> Ottawa
>>> vice versa and stay in "Les Suites").
>>
>> Only a gfortran person?  Because I'd like to nominate Kai Tietz for
>> that, if he's willing to accept.
>
> Well, obviously, I mostly interested in the progress of the Mother Of All
> Programming Languages, but I might be persuaded to fund a lesser cause.
>
> [ Add :-)'s to taste ]

Well, you might be interested to know that we've been working hard to
get the *best language in the world* to work on our target platform,
Win64.  In fact, the last testsuite I ran has it down to just 2 or
three distinct errors, depending on how you count.  A year or two ago,
we couldn't even run the front end without it segfaulting.  This makes
GCC a big competitor to Absoft for targetting 64-bit windows, and Kai
is the prime mover on that front.

Re: How is the definition of stack canary on MIPS arch?

[David Daney]

On 08/30/2010 09:46 AM, Richard Henderson wrote:

On 08/30/2010 03:45 AM, Adam Jiang wrote:

When I read the source in Linux kerne, it was said that stack canary for
implementing stack protector is defined as an offset to %gs on x86
architecture. How about stack canary defined on MIPS?


It's not implemented for MIPS.




For the Linux kernel, the MIPS stack canary would be a constant offset 
(that depends on PAGE_SIZE) from register $28.


David Daney

Re: For testing: full __float128 patch

[Richard Henderson]

On 08/30/2010 10:37 AM, Uros Bizjak wrote:
> I'm not familiar in versioning stuff, but since soft-fp symbols are
> part of generic libgcc-std.ver for a long time (before 4.5.0), I
> believe, it is enough to patch only configure files (see i.e. commits
> that enabled soft-fp on mingw/cygwin/-gnu*).

It will "work", but not properly.  One should never have symbols
magically appear in old versions.  If you add the symbols to the
proper current version number in a config/gcc/i386/libgcc-bsd.ver,
they'll appear at the right place.


r~

Re: For testing: full __float128 patch

[Uros Bizjak]

On Mon, Aug 30, 2010 at 7:48 PM, Richard Henderson  wrote:
> On 08/30/2010 10:37 AM, Uros Bizjak wrote:
>> I'm not familiar in versioning stuff, but since soft-fp symbols are
>> part of generic libgcc-std.ver for a long time (before 4.5.0), I
>> believe, it is enough to patch only configure files (see i.e. commits
>> that enabled soft-fp on mingw/cygwin/-gnu*).
>
> It will "work", but not properly.  One should never have symbols
> magically appear in old versions.  If you add the symbols to the
> proper current version number in a config/gcc/i386/libgcc-bsd.ver,
> they'll appear at the right place.

Can someone please help here?

Thanks,
Uros.

Re: 2010 GCC and GNU Toolchain Developers' Summit

[Kai Tietz]

2010/8/30 NightStrike :
> On Mon, Aug 30, 2010 at 1:33 PM, Toon Moene  wrote:
>> NightStrike wrote:
>>
>>> On Thu, Aug 12, 2010 at 4:22 PM, I  wrote:
>>
 Perhaps some from the gfortran effort would like to give a talk.  As far
  as
 I can see I can support one person financially (trip from Europe to
 Ottawa
 vice versa and stay in "Les Suites").
>>>
>>> Only a gfortran person?  Because I'd like to nominate Kai Tietz for
>>> that, if he's willing to accept.
>>
>> Well, obviously, I mostly interested in the progress of the Mother Of All
>> Programming Languages, but I might be persuaded to fund a lesser cause.
>>
>> [ Add :-)'s to taste ]
>
> Well, you might be interested to know that we've been working hard to
> get the *best language in the world* to work on our target platform,
> Win64.  In fact, the last testsuite I ran has it down to just 2 or
> three distinct errors, depending on how you count.  A year or two ago,
> we couldn't even run the front end without it segfaulting.  This makes
> GCC a big competitor to Absoft for targetting 64-bit windows, and Kai
> is the prime mover on that front.
>

Hello Toon,

I am grateful for this opportunity.  I am just a bit curious to get
it. Indeed it would be great. Indeed we spend the last years much
effort to support "The mother of all languages" for windows and
especially for x64. There are still some minor nits open, but they are
already addressed and get hopefully fixed in 4.6.

So if you serious, thank you very much.
Kai


-- 
|  (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination

Re: For testing: full __float128 patch

[Uros Bizjak]

On Mon, Aug 30, 2010 at 7:53 PM, Uros Bizjak  wrote:

>>> I'm not familiar in versioning stuff, but since soft-fp symbols are
>>> part of generic libgcc-std.ver for a long time (before 4.5.0), I
>>> believe, it is enough to patch only configure files (see i.e. commits
>>> that enabled soft-fp on mingw/cygwin/-gnu*).
>>
>> It will "work", but not properly.  One should never have symbols
>> magically appear in old versions.  If you add the symbols to the
>> proper current version number in a config/gcc/i386/libgcc-bsd.ver,
>> they'll appear at the right place.
>
> Can someone please help here?

Attached is my best (untested) shot at libgcc-bsd.ver. Someone has to
write i386/t-freebsd (similar to i386/t-linux) and connect it to the
build system. The versioning assumes that this will be committed to
4.5.x first.

Uros.


libgcc-bsd.ver
Description: Binary data

Re: For testing: full __float128 patch

[Richard Henderson]

On 08/30/2010 12:25 PM, Uros Bizjak wrote:
> Attached is my best (untested) shot at libgcc-bsd.ver. Someone has
> to write i386/t-freebsd (similar to i386/t-linux) and connect it to
> the build system. The versioning assumes that this will be committed
> to 4.5.x first.

That file looks plausible, though of course the actual
version will be 4.5.2.


r~

Re: For testing: full __float128 patch

[Jakub Jelinek]

On Mon, Aug 30, 2010 at 09:25:42PM +0200, Uros Bizjak wrote:
> On Mon, Aug 30, 2010 at 7:53 PM, Uros Bizjak  wrote:
> 
> >>> I'm not familiar in versioning stuff, but since soft-fp symbols are
> >>> part of generic libgcc-std.ver for a long time (before 4.5.0), I
> >>> believe, it is enough to patch only configure files (see i.e. commits
> >>> that enabled soft-fp on mingw/cygwin/-gnu*).
> >>
> >> It will "work", but not properly.  One should never have symbols
> >> magically appear in old versions.  If you add the symbols to the
> >> proper current version number in a config/gcc/i386/libgcc-bsd.ver,
> >> they'll appear at the right place.
> >
> > Can someone please help here?
> 
> Attached is my best (untested) shot at libgcc-bsd.ver. Someone has to
> write i386/t-freebsd (similar to i386/t-linux) and connect it to the
> build system. The versioning assumes that this will be committed to
> 4.5.x first.

It is wrong, GCC 4.5.0 has been released already, so no new symbols should
be added to GCC_4.5.0 symver.
IMNSHO this isn't a regression fix, so you should just apply it to the
trunk, and introduce them as GCC_4.6.0 version.  Also, there is no need
to have two chunks for the same symver in the *.ver file, just put the
3 resp. 2 symbols before the preceeding closing brace, together with the
%ifdef/%else/%endif.

Jakub

Re: For testing: full __float128 patch

[Uros Bizjak]

On Mon, Aug 30, 2010 at 9:38 PM, Jakub Jelinek  wrote:

>> >>> I'm not familiar in versioning stuff, but since soft-fp symbols are
>> >>> part of generic libgcc-std.ver for a long time (before 4.5.0), I
>> >>> believe, it is enough to patch only configure files (see i.e. commits
>> >>> that enabled soft-fp on mingw/cygwin/-gnu*).
>> >>
>> >> It will "work", but not properly.  One should never have symbols
>> >> magically appear in old versions.  If you add the symbols to the
>> >> proper current version number in a config/gcc/i386/libgcc-bsd.ver,
>> >> they'll appear at the right place.
>> >
>> > Can someone please help here?
>>
>> Attached is my best (untested) shot at libgcc-bsd.ver. Someone has to
>> write i386/t-freebsd (similar to i386/t-linux) and connect it to the
>> build system. The versioning assumes that this will be committed to
>> 4.5.x first.
>
> It is wrong, GCC 4.5.0 has been released already, so no new symbols should
> be added to GCC_4.5.0 symver.
> IMNSHO this isn't a regression fix, so you should just apply it to the
> trunk, and introduce them as GCC_4.6.0 version.  Also, there is no need
> to have two chunks for the same symver in the *.ver file, just put the
> 3 resp. 2 symbols before the preceeding closing brace, together with the
> %ifdef/%else/%endif.

So, attached and untested.

Uros.
Index: libgcc/config.host
===
--- libgcc/config.host  (revision 163647)
+++ libgcc/config.host  (working copy)
@@ -608,7 +608,8 @@
   i[34567]86-*-linux* | x86_64-*-linux* | \
   i[34567]86-*-gnu* | \
   i[34567]86-*-solaris2* | \
-  i[34567]86-*-cygwin* | i[34567]86-*-mingw* | x86_64-*-mingw*)
+  i[34567]86-*-cygwin* | i[34567]86-*-mingw* | x86_64-*-mingw* | \
+  i[34567]86-*-freebsd* | x86_64-*-freebsd*)
if test "${host_address}" = 32; then
tmake_file="${tmake_file} t-softfp 
i386/${host_address}/t-fprules-softfp"
fi
Index: gcc/config.gcc
===
--- gcc/config.gcc  (revision 163647)
+++ gcc/config.gcc  (working copy)
@@ -1153,10 +1153,11 @@
;;
 i[34567]86-*-freebsd*)
tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h 
${fbsd_tm_file} i386/freebsd.h"
+   tmake_file="${tmake_file} i386/t-freebsd"
;;
 x86_64-*-freebsd*)
tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h 
${fbsd_tm_file} i386/x86-64.h i386/freebsd.h i386/freebsd64.h"
-   tmake_file="${tmake_file} i386/t-crtstuff"
+   tmake_file="${tmake_file} i386/t-crtstuff i386/t-freebsd"
;;
 i[34567]86-*-netbsdelf*)
tm_file="${tm_file} i386/unix.h i386/att.h dbxelf.h elfos.h netbsd.h 
netbsd-elf.h i386/netbsd-elf.h"
@@ -3485,6 +3486,9 @@
i[34567]86-*-cygwin* | i[34567]86-*-mingw* | x86_64-*-mingw*)
tmake_file="${tmake_file} i386/t-fprules-softfp 
soft-fp/t-softfp"
;;
+   i[34567]86-*-freebsd* | x86_64-*-freebsd*)
+   tmake_file="${tmake_file} i386/t-fprules-softfp 
soft-fp/t-softfp"
+   ;;
ia64*-*-linux*)
tmake_file="${tmake_file} ia64/t-fprules-softfp 
soft-fp/t-softfp"
;;
Index: gcc/config/i386/t-freebsd
===
--- gcc/config/i386/t-freebsd   (revision 0)
+++ gcc/config/i386/t-freebsd   (revision 0)
@@ -0,0 +1 @@
+SHLIB_MAPFILES = $(srcdir)/config/i386/libgcc-bsd.ver
Index: gcc/config/i386/libgcc-bsd.ver
===
--- gcc/config/i386/libgcc-bsd.ver  (revision 0)
+++ gcc/config/i386/libgcc-bsd.ver  (revision 0)
@@ -0,0 +1,98 @@
+# Copyright (C) 2010 Free Software Foundation, Inc.
+#
+# This file is part of GCC.
+#
+# GCC is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3, or (at your option)
+# any later version.
+#
+# GCC is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with GCC; see the file COPYING3.  If not see
+# .
+
+# 128 bit long double support was introduced with GCC 4.6.0.
+# These lines make the symbols to get a @@GCC_4.6.0 attached.
+
+%exclude {
+  __addtf3
+  __divtc3
+  __divtf3
+  __eqtf2
+  __extenddftf2
+  __extendsftf2
+  __extendxftf2
+  __fixtfdi
+  __fixtfsi
+  __fixtfti
+  __fixunstfdi
+  __fixunstfsi
+  __fixunstfti
+  __floatditf
+  __floatsitf
+  __floattitf
+  __floatunditf
+  __floatunsitf
+  __floatuntitf
+  __getf2
+  __gttf2
+  __letf2
+  __lttf2
+  __multc3
+  __multf3
+  __negtf2
+  __netf2
+  __powitf2
+  __subtf3
+  __trunctfdf2
+  _

Re: For testing: full __float128 patch

[Joseph S. Myers]

On Mon, 30 Aug 2010, Uros Bizjak wrote:

> On Mon, Aug 30, 2010 at 7:53 PM, Uros Bizjak  wrote:
> 
> >>> I'm not familiar in versioning stuff, but since soft-fp symbols are
> >>> part of generic libgcc-std.ver for a long time (before 4.5.0), I
> >>> believe, it is enough to patch only configure files (see i.e. commits
> >>> that enabled soft-fp on mingw/cygwin/-gnu*).
> >>
> >> It will "work", but not properly. ?One should never have symbols
> >> magically appear in old versions. ?If you add the symbols to the
> >> proper current version number in a config/gcc/i386/libgcc-bsd.ver,
> >> they'll appear at the right place.
> >
> > Can someone please help here?
> 
> Attached is my best (untested) shot at libgcc-bsd.ver. Someone has to
> write i386/t-freebsd (similar to i386/t-linux) and connect it to the
> build system. The versioning assumes that this will be committed to
> 4.5.x first.

I advise copying libgcc-sol2.ver, with GCC_4.5.0 changed to GCC_4.6.0, 
unless you have some reason for actually needing different sets of 
symbols, since the Solaris version has already been reviewed as including 
all relevant symbols.  (Plus, as previously discussed, the appropriate 
%inherit and empty GCC_4.6.0 version in libgcc-std.ver - like those for 
GCC_4.1.0 which also only has symbols for some targets, for example.)

The Windows versions didn't need to allow for symbol versioning since that 
target doesn't support it.  The GNU/Linux versions got some symbol 
versions wrong initially so are not a good example to work from for other 
OSes.  Thus I recommend the Solaris version as an example from after the 
bugs in this area had been worked out.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: For testing: full __float128 patch

[Steve Kargl]

On Mon, Aug 30, 2010 at 09:51:09PM +0200, Uros Bizjak wrote:
> 
> So, attached and untested.
> 
> Uros.

I tested your patch on x86_64-*-freebsd.  My ppl and cloog
libraries were built with FreeBSD's system gcc (4.2.1).  All
tests failed due to missing symbols that are marked GCC_3.0.

> Index: gcc/config/i386/t-freebsd
> ===
> --- gcc/config/i386/t-freebsd (revision 0)
> +++ gcc/config/i386/t-freebsd (revision 0)
> @@ -0,0 +1 @@
> +SHLIB_MAPFILES = $(srcdir)/config/i386/libgcc-bsd.ver

Changing the = to += seems to fix the problem.  My
regression testing is still running, so I can't 
report stats.

-- 
Steve

Re: How is the definition of stack canary on MIPS arch?

[Adam Jiang]

On Mon, Aug 30, 2010 at 10:43:44AM -0700, David Daney wrote:
> On 08/30/2010 09:46 AM, Richard Henderson wrote:
> >On 08/30/2010 03:45 AM, Adam Jiang wrote:
> >>When I read the source in Linux kerne, it was said that stack canary for
> >>implementing stack protector is defined as an offset to %gs on x86
> >>architecture. How about stack canary defined on MIPS?
> >
> >It's not implemented for MIPS.
> >
> >
> 
> For the Linux kernel, the MIPS stack canary would be a constant
> offset (that depends on PAGE_SIZE) from register $28.
> 
> David Daney

Thanks, David and Richard.

Is there code, doc or anything on this topic I can refer to? Is it
defined in gcc internally or in kernel source itself? Would you please
redirect me to the right place?

I have done some research by googling. Here are what I've gotten.

http://www.trl.ibm.com/projects/security/ssp/main.html
http://www.trl.ibm.com/projects/security/ssp/
http://lxr.linux.no/linux+v2.6.35/arch/x86/include/asm/stackprotector.h

However, it seems there is no documents about how this is done on MIPS.
Do I miss something?

/Adam

Re: For testing: full __float128 patch

[Steve Kargl]

On Mon, Aug 30, 2010 at 03:29:20PM -0700, Steve Kargl wrote:
> On Mon, Aug 30, 2010 at 09:51:09PM +0200, Uros Bizjak wrote:
> > 
> > So, attached and untested.
> > 
> > Uros.
> 
> I tested your patch on x86_64-*-freebsd.  My ppl and cloog
> libraries were built with FreeBSD's system gcc (4.2.1).  All
> tests failed due to missing symbols that are marked GCC_3.0.
> 
> > Index: gcc/config/i386/t-freebsd
> > ===
> > --- gcc/config/i386/t-freebsd   (revision 0)
> > +++ gcc/config/i386/t-freebsd   (revision 0)
> > @@ -0,0 +1 @@
> > +SHLIB_MAPFILES = $(srcdir)/config/i386/libgcc-bsd.ver
> 
> Changing the = to += seems to fix the problem.  My
> regression testing is still running, so I can't 
> report stats.
> 

With my change to +=, on x86_64-*-freebsd I get

=== gcc Summary ===

# of expected passes72950
# of unexpected failures74
# of unexpected successes   3
# of expected failures  215
# of unresolved testcases   3
# of unsupported tests  1081
/usr/home/sgk/gcc/obj4x/gcc/xgcc  version 4.6.0 20100830 (experimental) (GCC) 


=== gfortran Summary ===

# of expected passes36155
# of unexpected failures4
# of unexpected successes   7
# of expected failures  59
# of unsupported tests  53
/usr/home/sgk/gcc/obj4x/gcc/testsuite/gfortran/../../gfortran  version 4.6.0 
20100830 (experimental) (GCC) 


I quickly looked through the gcc.log file and noticed
a couple of ICE's but I believe those are unrelated to
the TFmode patch.

Note, I believe that I do not have the authority to
approve this patch.
-- 
Steve

GCC summit tutorial proposal: Easily coding a GCC extension with MELT

[Basile Starynkevitch]

Hello 

I just proposed a tutorial session to GCC Summit 2010:

Easily coding a GCC extension with MELT
===
MELT is a powerful lispy domain specific language for coding GCC
extensions, particularily in the middle-end. It is available as a GCC
plugin and as an experimental GCC branch. MELT offers several high level
features and is translated to C code, hooked to GCC thru the plugins
hooks. Notable features of MELT include: interface to most GCC internal
types( like Gimple, Tree, Loop-s, etc.), a copying garbage collector, a
single-inheritance, reflexive, object system, first-class functional
values and anonymous functions, powerful and flexible pattern matching,
easy integration of C code chunks. The tutorial is targeted for the GCC
summit audience: people somehow familiar with the GCC internals (e.g.
knowledgeable of the Gimple & Tree representations, and of the passes
organization). It does not presuppose familiarity with Lisp. It will
show how the main feature of the MELT domain specific language, how to
code simple and more complex passes using MELT, how can passes share
data, how to extend MELT itself, how to interface additional GCC
internals to MELT, etc.

This GCC summit MELT tutorial requires some basic knowledge about GCC
internals (so could follow the "essential abstractions of GCC" tutorial
proposed by Uday Khedker).

The first part of this tutorial will illustrate basic use of MELT and
introduce the MELT lispy domain specific language and the separation of
MELT values from other stuff. It does not presuppose any familiarity
with any Lisp variant. 

The second part of the tutorial will focus on MELT pattern matching
facilities and show how to use them to concisely explore particular GCC
internal representations (notably Gimple and Tree).

The third part of the tutorial will detail how to code real GCC passes
in MELT and suggest possible MELT extensions for several specific
domains. It will give some insight on the internals of MELT.

===
Regards.

-- 
Basile STARYNKEVITCH http://starynkevitch.net/Basile/
email: basilestarynkevitchnet mobile: +33 6 8501 2359
8, rue de la Faiencerie, 92340 Bourg La Reine, France
*** opinions {are only mine, sont seulement les miennes} ***