Dear developers,
http://gcc.gnu.org/install/configure.html says
--enable-languages=lang1,lang2,...
...
Currently, you can use any of the following: all, ada, c, c++,
fortran, java, objc, obj-c++, treelang.
At least for the 3.4 train it seems that "fortran" is not supported,
one rath
On 8/27/06, Georg Schwarz <[EMAIL PROTECTED]> wrote:
Dear developers,
http://gcc.gnu.org/install/configure.html says
--enable-languages=lang1,lang2,...
...
Currently, you can use any of the following: all, ada, c, c++,
fortran, java, objc, obj-c++, treelang.
At least for the 3.4 train
Can one of you remind me who we need to lobby at
Apple to change the 'make check' on the regress testing
server to...
make -k check RUNTESTFLAGS='--target_board="unix{,-m64}"'
Since you are already building gcc with multilib support,
it makes little sense to not do so. Especially considering
On 8/26/06, Michael Veksler <[EMAIL PROTECTED]> wrote:
Jack Howarth wrote:
>Would any of the gcc developers care to drop by the python-dev
> mailing list and give the author of python an answer?
>
> http://mail.python.org/pipermail/python-dev/2006-August/068482.html
>
>
*Guido van Rossum wrot
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> I know I cannot win an argument with the GCC developers but I can't
> help wondering if they've gone bonkers. They may get Python 2.5 fixed,
> but what about 2.4? 2.3? This code has been there for a long time.
>
> It would be better if one had to e
gcc-4.1.0-0.20051206r108118 emits wrong .size directives for
statically initialized objects with a flexible array member,
e.g.:
struct {int x; int y[];} obj = {1, {2, 3}};
.globl obj
.data
.align 4
.type obj, @object
.size obj, 4
obj:
.long 1
On 27 Aug 2006 09:05:47 -0700, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
> I know I cannot win an argument with the GCC developers but I can't
> help wondering if they've gone bonkers. They may get Python 2.5 fixed,
> but what about 2.4? 2.3? This
"Guido van Rossum" <[EMAIL PROTECTED]> writes:
[...]
| > In general I think I personally am on the very conservative edge of
| > gcc developers, in that I am generally opposed to breaking existing
| > code. But this particular optimization will let us do a much better
| > job on very simple loop
"Marcin 'Qrczak' Kowalczyk" <[EMAIL PROTECTED]> writes:
> gcc-4.1.0-0.20051206r108118 emits wrong .size directives for
> statically initialized objects with a flexible array member,
> e.g.:
>
> struct {int x; int y[];} obj = {1, {2, 3}};
>
> .globl obj
> .data
> .align 4
>
Guido van Rossum wrote:
It has calmed me down. But I hope that the future quality of the
arguments defending the feature is better than Michael Veksler's
attempt. Thanks for responding in person.
Sorry, next time I'll find a better example. Gosh, who would think
that a benign example, would st
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> "Marcin 'Qrczak' Kowalczyk" <[EMAIL PROTECTED]> writes:
>
>> gcc-4.1.0-0.20051206r108118 emits wrong .size directives for
>> statically initialized objects with a flexible array member,
>> e.g.:
>>
>> struct {int x; int y[];} obj = {1, {2, 3}};
>>
>
I asked:
> Can this have serious effects (like overlapped or split objects),
> or is .size used only for e.g. debugging?
It seems that .size is used for shared libraries compiled without
-fPIC: linking the same code statically or with -fPIC fixes the wrong
behavior, and -finhibit-size-directive c
On Sun, 2006-08-27 at 22:15 +0200, Marcin 'Qrczak' Kowalczyk wrote:
> I asked:
> I found that the .size bug has been reported in January 2006:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25805
This is a different issue unrelated to .size but really to actually not
outputting all the data for fle
13 matches
Mail list logo
