Re: The Linux binutils 2.18.50.0.9 is released
Hi, H.J. Lu wrote: This is the beta release of binutils 2.18.50.0.9 for Linux, which is based on binutils 2008 0822 in CVS on sourceware.org plus various changes. It is purely for Linux. ... 1. binutils-2.18.50.0.9.tar.bz2. Source code. 2. binutils-2.18.50.0.8-2.18.50.0.9.diff.bz2. Patch against the previous beta source code. 3. binutils-2.18.50.0.9.i686.tar.bz2. IA-32 binary tar ball for RedHat EL 4. 4. binutils-2.18.50.0.9.ia64.tar.bz2. IA-64 binary tar ball for RedHat EL 4. 5. binutils-2.18.50.0.9.x86_64.tar.bz2. X64_64 binary tar ball for RedHat EL 4. The primary sites for the beta Linux binutils are: 1. http://www.kernel.org/pub/linux/devel/binutils/ Looks to me as if the tarball is missing the .tar extension. Greetings, -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name
Arquivo - REDE INDUSTRIAL MUNDIAL
Amigos, Como é do conhecimento de todos , este fórum tem a presença de diversos amigos , profissionais de outros países. Temos aqui conosco argentinos, Bolivianos, Cubanos, Paraguaios, uruguaios, chilenos, portugueses, Espanhois, cubanos, angolanos, americanos, etc. Quero , então lembrar a você que , neste fórum você pode trocar experiências com pessoas do Brasil e de outras nações, pois vocÊ passa a fazer parte desta grande família do mundo globalizado (somos milhares). É importante que todos nós saibamos da existência destes profissionais em nossa rede , para que possamos trocar informações sobre os mais diversos temas industriais (manutenção, produção, qualidade, segurança, administração, etc) a fim de que todos nós , neste mundo globalizado, possamos crescer ainda mais, com a troca de informações. Esta Rede NÃO TEM FRONTEIRA, POIS É UMA REDE MUNDIAL. p.s. - Para quem está chegando agora, e deseja ter conhecimento dos assuntos já discutidos no fórum, acesse http://br.groups.yahoo.com/group/redeindustrial e faça buscas em MENSAGENS. Grande abraço a todos. Abrahão Lima Coordenador Rede Industrial
Arquivo - REDE INDUSTRIAL MUNDIAL
Amigos, Como é do conhecimento de todos , este fórum tem a presença de diversos amigos , profissionais de outros países. Temos aqui conosco argentinos, Bolivianos, Cubanos, Paraguaios, uruguaios, chilenos, portugueses, Espanhois, cubanos, angolanos, americanos, etc. Quero , então lembrar a você que , neste fórum você pode trocar experiências com pessoas do Brasil e de outras nações, pois vocÊ passa a fazer parte desta grande família do mundo globalizado (somos milhares). É importante que todos nós saibamos da existência destes profissionais em nossa rede , para que possamos trocar informações sobre os mais diversos temas industriais (manutenção, produção, qualidade, segurança, administração, etc) a fim de que todos nós , neste mundo globalizado, possamos crescer ainda mais, com a troca de informações. Esta Rede NÃO TEM FRONTEIRA, POIS É UMA REDE MUNDIAL. p.s. - Para quem está chegando agora, e deseja ter conhecimento dos assuntos já discutidos no fórum, acesse http://br.groups.yahoo.com/group/redeindustrial e faça buscas em MENSAGENS. Grande abraço a todos. Abrahão Lima Coordenador Rede Industrial
Re: The Linux binutils 2.18.50.0.9 is released
On Mon, Aug 25, 2008 at 3:28 AM, René Rebe <[EMAIL PROTECTED]> wrote: > Hi, > > H.J. Lu wrote: >> >> This is the beta release of binutils 2.18.50.0.9 for Linux, which is >> based on binutils 2008 0822 in CVS on sourceware.org plus various >> changes. It is purely for Linux. >> > > ... >> >> 1. binutils-2.18.50.0.9.tar.bz2. Source code. > Looks to me as if the tarball is missing the .tar extension. > It should be fixed now. Thanks. -- H.J.
Re: Better GCC diagnostics
> > Well, clearly, the preprocessor and handling of #include is very > > C/C++ specific, and not used by Ada or Fortran. > > Both Ada and Fortran are linked with libcpp.a. Sure, because as we've said, libcpp is not modular enough. Clearly Ada does not need to link with A C preprocessor at all. > Even if you do not use line-map.o, the middle-end does, so you still > have the duplication. Right, this is the only part that is indeed shared and for which Ada requires libcpp. > > It has also handled column info from day one (and we would not want any > > of the e.g. -fshow-column stuff: why would you *not* want to display > > column information ? :-) > > Yes, why? So, I assume there are plans to get rid of -fshow-column switch (and make it the only default). > The point is that other front-ends would be able to use it. And > non-Ada developers would be able to fix it and extend it. Moreover, I certainly have no problem giving access to other front-ends to GNAT's capability here, as long as everyone is cool with using Ada in other front-ends, I'm certainly all for it. > even if GNAT won't use it, moving all this out of libcpp and making it > modular would allow to link only to the things that you really need. Definitely. > Finally, the middle-end is using it anyway, so gnat is using it. Sure. Using line-map is one thing, using a C preprocessor is another. Arno
Re: Better GCC diagnostics
>> Even if you do not use line-map.o, the middle-end does, so you still >> have the duplication. > > Right, this is the only part that is indeed shared and for which Ada requires > libcpp. There are exactly 6 uses of linemap functions in libcpp. They could be replaced with a handful of function pointers, moving line-map.c to gcc. There are 2 more uses in makedepend.c, which could define its own dummy functions because it does not care about locations at all. Paolo
Re: Better GCC diagnostics
2008/8/25 Arnaud Charlet <[EMAIL PROTECTED]>: >> Even if you do not use line-map.o, the middle-end does, so you still >> have the duplication. > > Right, this is the only part that is indeed shared and for which Ada requires > libcpp. My point is that if the rest of the compiler extends diagnostics.c to handle caret and ranges and all other features, Ada would need carry all that around even if gnat has its own diagnostics machinery. But perhaps that is OK. I am not trying to force anything just make you aware of the situation. >> > It has also handled column info from day one (and we would not want any >> > of the e.g. -fshow-column stuff: why would you *not* want to display >> > column information ? :-) >> >> Yes, why? > > So, I assume there are plans to get rid of -fshow-column switch (and make it > the > only default). No, I cannot decide such thing. I would be happy to write such patch, though. >> The point is that other front-ends would be able to use it. And >> non-Ada developers would be able to fix it and extend it. Moreover, > > I certainly have no problem giving access to other front-ends to GNAT's > capability here, as long as everyone is cool with using Ada in other > front-ends, > I'm certainly all for it. I see that as very unrealistic, GCC development is already complex enough, so we will have to live with the duplication. I just wanted to make you notice that even if location_t is moved out of libcpp, GNAT will still link with diagnostic.c and whatever other diagnostics features that will be implemented. The burden of the duplication would be on GNAT executable, the other front-ends do not carry GNAT's code. Probably the effect of it is negligible, anyway. >> Finally, the middle-end is using it anyway, so gnat is using it. > > Sure. Using line-map is one thing, using a C preprocessor is another. Again, my point is that even if GNAT has all these features already, GNAT should be interested in this since it means moving stuff out of libcpp which will allow to break that dependency. C/C++ could very well implement caret diagnostics and everything else within libcpp, so the dependency of GNAT with libcpp would be actually harder to break. My fear is that if the other FEs do not care about this issue "because we have it already", then this is exactly what will happen. Cheers, Manuel.
Re: Better GCC diagnostics
2008/8/25 Paolo Bonzini <[EMAIL PROTECTED]>: > >>> Even if you do not use line-map.o, the middle-end does, so you still >>> have the duplication. >> >> Right, this is the only part that is indeed shared and for which Ada requires >> libcpp. > > There are exactly 6 uses of linemap functions in libcpp. They could be > replaced with a handful of function pointers, moving line-map.c to gcc. You have to count all uses of: SOURCE_LINE, SOURCE_COLUMN, MAIN_FILE_P, LAST_SOURCE_LINE, LAST_SOURCE_LINE_LOCATION, and LINEMAP_POSITION_FOR_COLUMN which are all macros. Also, line-map functions seem to be in the critical path, so the extra dereferencing may be noticeable. > There are 2 more uses in makedepend.c, which could define its own dummy > functions because it does not care about locations at all. Sure about that? line-map.h seems pretty important to handle the include stack. Cheers, Manuel.
Re: Better GCC diagnostics
Manuel López-Ibáñez wrote: > 2008/8/25 Paolo Bonzini <[EMAIL PROTECTED]>: Even if you do not use line-map.o, the middle-end does, so you still have the duplication. >>> Right, this is the only part that is indeed shared and for which Ada >>> requires >>> libcpp. >> There are exactly 6 uses of linemap functions in libcpp. They could be >> replaced with a handful of function pointers, moving line-map.c to gcc. > > You have to count all uses of: > > SOURCE_LINE, SOURCE_COLUMN, MAIN_FILE_P, LAST_SOURCE_LINE, > LAST_SOURCE_LINE_LOCATION, and LINEMAP_POSITION_FOR_COLUMN > > which are all macros. Yes, but libcpp could still provide the *interface* of line-map.h (the macros), and leave the actual implementation of the data structure to the client. > Also, line-map functions seem to be in the > critical path, so the extra dereferencing may be noticeable. That's true. Unless we lexed everything up front, in which case one could hope that the indirect branches would be predicted well. In fact, I'm curious about how good/bad the branch predictor works for GCC. My wild guess: awfully. > Sure about that? line-map.h seems pretty important to handle the include > stack. As far as I could see, all the dependency stuff is in mkdeps.c; maybe it could use the line-map infrastructure more. Of course, in that case moving line-map.c out of libcpp would mean moving mkdeps.c too -- and not in gcc/, but rather in its own library so that makedepend can use it... at which point you wonder if it was really a good idea... Paolo
Re: Better GCC diagnostics
2008/8/25 Paolo Bonzini <[EMAIL PROTECTED]>: > > As far as I could see, all the dependency stuff is in mkdeps.c; maybe it > could use the line-map infrastructure more. Of course, in that case > moving line-map.c out of libcpp would mean moving mkdeps.c too -- and > not in gcc/, but rather in its own library so that makedepend can use > it... at which point you wonder if it was really a good idea... Well, my opinion is that line-map.c should be in its own library/object file independent of libcpp but libcpp (and makedepend and cc1 and gnat) should still be able to use it, preferably directly and not through pointers. Not sure how to do this but I think it is what we do with libiberty, don't we? Perhaps there is an even easier way. The same should happen with diagnostic.[ch]. Cheers, Manuel.
Re: Better GCC diagnostics
Manuel López-Ibáñez wrote: Again, my point is that even if GNAT has all these features already, GNAT should be interested in this since it means moving stuff out of libcpp which will allow to break that dependency. C/C++ could very well implement caret diagnostics and everything else within libcpp, so the dependency of GNAT with libcpp would be actually harder to break. My fear is that if the other FEs do not care about this issue "because we have it already", then this is exactly what will happen. Fortran is probably an example of don't care: Fortran already uses caret diagnostics, but it depends also on libcpp as several Fortran programs require CPP preprocessing. Tobias
Re: REAL(16) ...on x86/x86-64
Steve Kargl wrote: On Mon, Aug 25, 2008 at 03:15:42PM -0700, Steve Kargl wrote: On Mon, Aug 25, 2008 at 11:50:16PM +0200, Dominique Dhumieres wrote: REAL(16) needs to be done in software -- on x86, x86-64 -- as it is not supported in hardware; if you want to use more than REAL(8) on x86, x86-64 you can use REAL(10). Or you use a system such as PowerPC which supports REAL(16) in silicon. As far as I can tell, the ifc implementation is a "real" one where the full 128 bits are used to code the real number. So far i did not have the time to play with it. Now concerning gfortran and since gcc requires gmp and mpfr, how difficult (efficient) would it be to use these libraries to implement REAL(xxx)? Getting +, -, *, and / working is almost trivial. The hard part is getting REAL(16) working in all the fun corners of the standard as well as getting IO working. Here's a start where one may need to distinguish between hardware FP and software emulation. With the patch I sent earlier with an off-by-1 fix in exponents, I get Kind: 4 8 10 16 Precision: 6 15 18 33 Digits: 24 53 64 113 Radix: 2 2 2 2 Min. exp.: -125 -1021 -16381 -16381 Max. exp.: 128 1024 16384 16384 on x86_64-*-freebsd. program probe real(4) a real(8) b real(10) c real(16) d print '(A,4(I0,x))', ' Kind: ', kind(a), kind(b), kind(c), kind(d) print '(A,4(I0,x))', 'Precision: ', precision(a), precision(b), & & precision(c), precision(d) print '(A,4(I0,x))', ' Digits: ', digits(a), digits(b), digits(c), & & digits(d) print '(A,4(I0,x))', 'Radix: ', radix(a), radix(b), radix(c), radix(d) print '(A,4(I0,x))', 'Min. exp.: ', minexponent(a), minexponent(b), & & minexponent(c), minexponent(d) print '(A,4(I0,x))', 'Max. exp.: ', maxexponent(a), maxexponent(b), & & maxexponent(c), maxexponent(d) end program probe This looks like a nice start. We already have support for real(16) I/O working so that will be a minor piece. There exists float-128 routines within the gcc libraries now. We need to figure out how to adapt/configure and use these. Steve, will you carry this patch forward to get +,-,*, and / working? In the meantime, is there someone knowledgeable of the flt-128 library that can guide us in this area. Maybe between Steve and I we can get it working with some mentoring on the configuration stuff. (target gcc 4.5) Jerry
Re: REAL(16) ...on x86/x86-64
On Mon, Aug 25, 2008 at 07:09:12PM -0700, Jerry DeLisle wrote:
> Steve Kargl wrote:
> >On Mon, Aug 25, 2008 at 03:15:42PM -0700, Steve Kargl wrote:
> >>On Mon, Aug 25, 2008 at 11:50:16PM +0200, Dominique Dhumieres wrote:
> REAL(16) needs to be done in software -- on x86, x86-64 -- as it is not
> supported in hardware; if you want to use more than REAL(8) on x86,
> x86-64 you can use REAL(10). Or you use a system such as PowerPC which
> supports REAL(16) in silicon.
> >>>As far as I can tell, the ifc implementation is a "real" one where the
> >>>full 128 bits are used to code the real number. So far i did not have
> >>>the time to play with it.
> >>>
> >>>Now concerning gfortran and since gcc requires gmp and mpfr, how
> >>>difficult (efficient) would it be to use these libraries to implement
> >>>REAL(xxx)?
> >>>
> >>Getting +, -, *, and / working is almost trivial. The hard part is
> >>getting REAL(16) working in all the fun corners of the standard
> >>as well as getting IO working. Here's a start where one may need
> >>to distinguish between hardware FP and software emulation.
> >>
> >>
> >
> >With the patch I sent earlier with an off-by-1 fix in exponents, I get
> >
> > Kind: 4 8 10 16
> >Precision: 6 15 18 33
> > Digits: 24 53 64 113
> >Radix: 2 2 2 2
> >Min. exp.: -125 -1021 -16381 -16381
> >Max. exp.: 128 1024 16384 16384
> >
> >on x86_64-*-freebsd.
> >
> This looks like a nice start. We already have support for real(16) I/O
> working so that will be a minor piece.
I think you'ld need to adapt the IO for software emulated FP.
Everything would remain an mpfr_t type, so you (this is a
generic you) need to transfer mpfr_t during IO.
> There exists float-128 routines within the gcc libraries now. We need to
> figure out how to adapt/configure and use these.
I had the impression some would like to see real.c die.
> Steve, will you carry this patch forward to get +,-,*, and / working?
I don't have any plans to carry this any further. It was just a pointer
to others where to start. I'll note that if the REAL(16) stuff is
completely implemented within framework of mpfr, then one can implement
-freal-bits=255,15. This then can be used to define a real type
with 255 bits of precision and an exponent range of 2**15-3:2**15-1.
In trans-type, one does
if (option.real_bits) then
else
what I already posted.
end if
> In the meantime, is there someone knowledgeable of the flt-128 library that
> can guide us in this area. Maybe between Steve and I we can get it working
> with some mentoring on the configuration stuff. (target gcc 4.5)
Well, my idea (based on Dominique's comment) is to keep everything
in a mpfr_t type. For example, in the following code,
real(16) x, y
x = 1._16
y = 2._16
x = x + y
end
The binary operator + ultimately gets translated to
mpfr_t tmp;
mpfr_init(tmp, 113);
mpfr_add(tmp, x, y, RND);
mpfr_set(x, tmp, RND);
mpfr_clear(tmp)
BTW, constant folding already works.
program probe
real(16) d, e
d = 1.e0_16 + 3.14e1_16
e = 2. / 3._16
d = 4._16 * 3.3_16
e = 42. - 8.4_16
d = - 3._16
d = sin(1.2345_16)
a = sin(1.2345)
end program probe
troutmask:sgk[204] gfc4x -o z -fdump-tree-original a.f90
troutmask:sgk[205] tail a.f90.003t.original
d = 3.2399987674048355921690540442e+1;
e = 6.6345678342602127357824e-1;
d = 1.313837024177960845270221e+1;
e = 3.3600012325951644078309459558e+1;
d = -3.0e+0;
d = 9.43983323944511166155703552452566891228124607439110465785e-1;
a = 9.439833164215087890625e-1;
Now, for something like a very basic binary operator, one needs
to convert a = b + c into similar mpfr code. This can be done in
trans-expr.c(gfc_conv_expr_op) by short circuiting the logic.
if (expr->value.op.op1->ts.kind == 16 || expr->value.op.op2->ts.kind == 16)
{
gfc_error_now ("Tsk! Tsk! Need to convert op into mpfr call");
}
--
Steve
Re: c++0x {g++}4.4, =default definition outside template class fails{ to link}.
Sorry Paolo, that definitely should have been.
=== THIS CODE FAILS TO LINK ===
template
class foo {
public:
foo() =default; // <<--- this works fine.
~foo();
};
template
foo::~foo() =default; <<--- ERROR: This doesn't get built by the compiler.
// foo::~foo() {}; <<-- replacing with this line fixes the error.
int main() {
foo fi;
return 0;
}
===
Not
=== THIS CODE FAILS TO COMPILE ===
...
Still, shouldn't the version of
"foo::~foo() =default;"
be built by the compiler since it's called by main().
Is this a bug? Should I update my gcc and go retest?
Does it fail to link for you? (or anyone else)?
Also, yes I am using a snapshot, I couldn't figure out how to get the
mainline (trunk?) 4.4 version, all I got was 4.3 using svn. Then again
I'm new to svn and building gcc.
