On Mon, 2009-03-09 at 21:25 -0700, Ian Lance Taylor wrote:
> > Also, is there any significant difference in bootstrap times?
>
> I haven't actually measured, but subjectively bootstrap does seem to
> take longer.
A subjective assessment was all I was interested in.
Thanks,
Ben
One of our customers has a chip with memory-mapped peripheral
registers that need to be accessed in a specific mode. The registers
represent bitfields within the hardware, so a volatile struct is an
obvious choice to represent them in C.
However, gcc has a very simplistic heuristic for deciding
On Mon, 9 Mar 2009, Sylvain Pion wrote:
> Later, 1) started to be taken care of, and it was unfortunately
> added under the control of the same -frounding-math option.
> Which now, makes it harder to come back, since we want different
> defaults for these two aspects.
>
> I have already mentioned
On Mon, 9 Mar 2009, Sylvain Pion wrote:
> - C++ does not have it, so what's the plan for C++ ?
That's for C++ maintainers, possibly guided by anything that goes in the
C++ standard.
The pragma syntax is a fairly small part of the work, as would be control
of the options at a per-function level
Ben Elliston writes:
>> I'm curious whether there are any detectable differences in the resulting
>> compiler when built with g++ rather than gcc. E.g. testsuite regressions,
>> changes in the speed or size of cc1, etc. Also, is cc1 linked with
>> libstdc++.so ? Stuff like that.
>
> Also, is t
> I'm curious whether there are any detectable differences in the resulting
> compiler when built with g++ rather than gcc. E.g. testsuite regressions,
> changes in the speed or size of cc1, etc. Also, is cc1 linked with
> libstdc++.so ? Stuff like that.
Also, is there any significant differenc
On Mon, Mar 9, 2009 at 2:21 PM, Martin Jambor wrote:
> Hi,
>
> The description of TREE_ADDRESSABLE macro in tree.h says:
>
> "In ..._TYPE nodes, it means that objects of this type must
> be fully addressable. This means that pieces of this
> object cannot go into register parameters, for exa
Hi,
The description of TREE_ADDRESSABLE macro in tree.h says:
"In ..._TYPE nodes, it means that objects of this type must
be fully addressable. This means that pieces of this
object cannot go into register parameters, for example."
Yet the current tree-sra does not check this fla
>> I think 2) is taken care of by -fassociative-math, or it should at least.
>
> I don't think it is (I haven't checked), and I don't see why it should.
> This transformation has nothing to do with associativity : unless I'm
> mistaken, it is always valid when rounding is to the nearest or towards
Dear all,
I am currently working on defining the cost of an address calculation
and I have an issue when the function is inlined. It seems that when
the address cost is taken into account only sometimes.
Here is the test code that I am testing this on:
long tab[2];
void foo(long x) {
long i;
Paolo Bonzini wrote:
Sylvain Pion wrote:
Andrew Thomas Pinski wrote:
The fact is that Roger's patch introduced a regression (this word
should be clear enough here), in that some users now have their old
code broken, and they are forced to add the -frounding-math option
(after having lost some t
Joseph S. Myers wrote:
On Sun, 8 Mar 2009, Sylvain Pion wrote:
this pragma. I nevertheless try to find grants for funding
people to implement some related things in GCC. And I also
contribute time to help in the guidance of GCC with my
expertise in this particular area, even if it requires a
Sylvain Pion wrote:
> Andrew Thomas Pinski wrote:
>>> The fact is that Roger's patch introduced a regression (this word
>>> should be clear enough here), in that some users now have their old
>>> code broken, and they are forced to add the -frounding-math option
>>> (after having lost some time fin
Andrew Thomas Pinski wrote:
The fact is that Roger's patch introduced a regression (this word
should be clear enough here), in that some users now have their old
code broken, and they are forced to add the -frounding-math option
(after having lost some time finding about this non trivial issue).
On Mon, Mar 9, 2009 at 9:03 AM, Richard Guenther
wrote:
>> I believe one should convince the middle end to emit libcall
>> for __builtin_xxx when the target has no builtint support.
>
> It of course does.
Then, Bernd's report appears to be a mystery.
-- Gaby
Hi,
I am experiencing a problem with retrieving coverage data from some
instrumented fortran code. The error I receive is: "stamp mismatch with
graph file".
Browsing Google I can find virtually no clues what might be wrong. Is
there a clear scenario that triggers this? What info do I need to
prov
On Mon, Mar 9, 2009 at 3:43 AM, Piotr Wyderski wrote:
> Could you please point me
> the "under the hood" features you think may be interesting for
> me? I mean (presumming that there are) the extended type info,
> class layout description (e.g. in order to implement reflections
> and GC), the __cx
On Mon, Mar 9, 2009 at 3:59 PM, Gabriel Dos Reis wrote:
> On Mon, Mar 9, 2009 at 7:11 AM, Bernd Roesch wrote:
>> Hello Gabriel
> [...]
>>
>> You see there is the _ not in.normaly funcs that not find have a _ before
>>
>> To get all work, it seem i need add the same function add in math.h and in
>
On Mon, Mar 9, 2009 at 7:11 AM, Bernd Roesch wrote:
> Hello Gabriel
[...]
>
> You see there is the _ not in.normaly funcs that not find have a _ before
>
> To get all work, it seem i need add the same function add in math.h and in
> the linker
> lib or change cmath file and remove all __builtin_ c
Hello Gabriel
On 09.03.09, you wrote:
> The above sqrt() function is distinct from the C version, because
> it has a C++ linkage. Consequently, I would expect that if
> __builtin_sqrtf() is not available, the compiler would emit a
> library call to the out-of-line C version.
But it dont work.
> Well, the problem is that I don't know where to find the "unofficial"
> documentation, so it is hard to figure out the questions to be asked.
Well, the unofficial documentation is the source code. :->
Paolo
Manuel López-Ibáñez wrote:
> Anyway, the documentation is there http://gcc.gnu.org/onlinedocs/
Yes, this is the official documentation I read frequently.
> Anything not documented there is likely to change or be removed
> in the future, so you should not rely on it.
I can afford the process of
2009/3/9 Piotr Wyderski :
>
> Having said that, I wonder what else can I win by sticking to
> the GNU compiler as closely as possible. There is a lot of
> officially documented extensions (computed gotos, attributes,
> PMF conversions etc.) I am aware of (and I continuously monitor
> the list), but
Hi,
Quite a long time ago I have decided to use GCC as the only compiler
for my C++* applications (mostly heavy-duty high volume data stream
processing). There are many reasons, but the most important are
listed below:
1. A GCC port is available for every platform I am interested in;
2. It is im
On Mon, Mar 9, 2009 at 2:42 AM, Bernd Roesch wrote:
> Hello Richard
>
> On 06.03.09, you wrote:
>
> ah thanks for info, i understand now too wy sqrtf, fmod (work in C programs)
> get linker error on C++ programs but sqrt and some other work on platform
> 68k.
> in c++/4.3.2/cmath include
>
> is th
On Mon, Mar 9, 2009 at 11:13 AM, Paolo Bonzini wrote:
> Timothy Madden wrote:
>> Hello
>>
>> Is -mfpmath=both for i386 and x86-64 still experimental in gcc 4.3, as
>> the in the online manual page ?
>
> Yes. It might (*might*) be better in GCC 4.4 thanks to the new register
> allocator, but it's
Dave Korn wrote:
> Gah, yes of course, you showed the config in your first post. Well, that's
> the problem.
Confirmed, with --enable-threads=posix the compiler builds correctly.
Best regards, Piotr
On Mon, Mar 9, 2009 at 12:35 AM, Joseph S. Myers
wrote:
> - Show quoted text -
> On Mon, 9 Mar 2009, Steven Bosscher wrote:
>
>> On Mon, Mar 9, 2009 at 12:24 AM, Joseph S. Myers
>> wrote:
>> > The defaults are deliberate decisions
>> > (and as such the adoption of those decisions cannot meaningf
Hello Richard
On 06.03.09, you wrote:
ah thanks for info, i understand now too wy sqrtf, fmod (work in C programs)
get linker error on C++ programs but sqrt and some other work on platform
68k.
in c++/4.3.2/cmath include
is this code.
using ::sqrt;
inline float
sqrt(float __x)
{ return
Timothy Madden wrote:
> Hello
>
> Is -mfpmath=both for i386 and x86-64 still experimental in gcc 4.3, as
> the in the online manual page ?
Yes. It might (*might*) be better in GCC 4.4 thanks to the new register
allocator, but it's unlikely that the manual page will be changed before
the release.
> gcc -S tmp.S for some reason prints to stdout, so gcc -S tmp.S > tmp.s
> is what you need
Thank you very much, I'll take a look.
Regards,
Phil
--
Versioning your /etc, /home or even your whole installation?
Try fsvs (fsvs.tigris.org)!
31 matches
Mail list logo
