On Thu, Mar 10, 2005 at 01:10:49PM -0800, James E Wilson wrote:
> Steve Kargl wrote:
> >I'm looking to the broken behavior of gfortran with its
> >-r8, -i8, and -d8 options. gfortran/lang.opt contains
>
> You can't choose any name for front-end options. There are complicated
> rules for determi
On Thu, 2005-03-10 at 20:14, Hans-Peter Nilsson wrote:
> That question isn't applicable or maybe I should say "by
> identity mapping". To wit, SYMNAME refers to whatever has
> "static" in front of it *in the source code*, but for which you
> want it removed, i.e. globalized (speaking in C terms).
> From: James E Wilson <[EMAIL PROTECTED]>
> Date: Thu, 10 Mar 2005 19:34:01 -0800
> On Thu, 2005-03-10 at 17:48, Hans-Peter Nilsson wrote:
> > Of course! The simple (and best) way out is to define what
> > happens in all those situations as the equivalent of removing
> > "static" for such an ide
On Thu, 2005-03-10 at 17:48, Hans-Peter Nilsson wrote:
> This isn't a source-level modification, by definition.
And I could argue that my suggestion isn't a source-level modification
either, or I could argue that your suggestion really is a source-level
modification, but it seems pointless to argu
Greg Schafer wrote:
This is rather critical, yet a bugmaster saw fit to remove the 4.0.0 target
milestone on this bug:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20166
Any chance of making this one a high priority?
I've restored the target milestone, but I've marked this as low
priority. It wo
Daniel Berlin wrote:
As for why the new name doesn't work, it's not clear from the above.
I'd need to see the assembly and the error.
:)
Likewise. I assume these functions have only internal linkage? Or that
the original function is still provided with external linkage? (I'm
just checking that
> Date: Thu, 10 Mar 2005 17:36:37 -0800
> On Thu, 2005-03-10 at 16:55, Hans-Peter Nilsson wrote:
> > But that requires source-level instrumentation.
>
> Isn't a compiler option -fglobalize-symbol also a form of source-level
> instrumentation? Either way, you need the source, and you get differen
Ranjit Mathew wrote:
IMHO "gnattools" should be added to "ADA_DIRS" in "gcc_release"
to generate snapshots properly. Otherwise, people who do not
download and install "gcc-ada" tarballs will get a bootstrap
error.
I verified that if I download the gcc-core snapshot and try a bootstrap,
I get a f
On Thu, 2005-03-10 at 16:55, Hans-Peter Nilsson wrote:
> But that requires source-level instrumentation.
Isn't a compiler option -fglobalize-symbol also a form of source-level
instrumentation? Either way, you need the source, and you get different
code emitted.
If you are interested in implement
Well as we speak - im on the verge of grabbing gcc-cvs - the only thing
that worries me is that right after i build gcc and start building the
system some major bug or regression in 4.0 will be fixed and illl have
to basicly start over (its a p2 so its slow)
im going to try and compile with
-ma
> Date: Thu, 10 Mar 2005 14:41:23 -0800
> From: James E Wilson <[EMAIL PROTECTED]>
> Fredrik Hugosson wrote:
> > My proposal is the following new options:
> > -fglobalize-symbol=SYMBOLNAME
> > -fglobalize-symbols=FILENAME
> > -fglobalize-all-symbols
>
> It is unlikely someone will volunteer to im
On Thu, 2005-03-10 at 15:27, Joe Buck wrote:
> On Thu, Mar 10, 2005 at 12:39:28PM -0800, James E Wilson wrote:
> > Also, it is probably a little early to worry about this, as the gcc-4
> > release is probably still 2 months away.
> While I usually hesitate to disagree with Jim, I will in this case
On Thu, Mar 10, 2005 at 12:39:28PM -0800, James E Wilson wrote:
> Andrew Muraco wrote:
> >After the compiler is installed im going to recompile glibc using gcc
> >4.0 and recompile other major parts of the system
>
> This is probably more trouble than it is worth. gcc-4 won't be fully
> ABI comp
Fredrik Hugosson wrote:
My proposal is the following new options:
-fglobalize-symbol=SYMBOLNAME
-fglobalize-symbols=FILENAME
-fglobalize-all-symbols
It is unlikely someone will volunteer to implement a feature that only
you need.
Globalizing a symbol in a shared library is potentially unsafe, and
my platform is x86
the distribution i use is Gentoo - so im familiar with compiling a whole
distro.
and i am aware of the 2 months until the release - but i have been
considering using my spare computer to test out gcc-4.0 (maybe i might
even try gcc-4.1 if i get daring - and compile the system
Shaun Jackman wrote:
Is it possible by hacking the specs file to change the target for
arm-elf-gcc from -marm to -mthumb? I tried a few obvious things like
changing marm in *multilib_defaults to mthumb, but this did not have
the desired effect.
You have to do more than that. multilib_defaults only
Shaun Jackman wrote:
Why does the above specs snippet cause gcc to forget it's linking
against thumb libraries?
The -mthumb support works by passing extra -L options to the linker.
Try using -v and looking at the linker options.
You didn't include your linker script, but a possibility here is tha
Paul Schlie wrote:
- might forcing sjlj exceptions help? With what consequences?
Perhaps, try it and see. Less efficient C++ EH support. We also have C
extensions for EH support, but they are not widely used.
- or might it be best for me to attempt to refine the baseline exception
data struct
Sachin Sonawane wrote:
But I want to see the Assembly code with no-ops. How do I go for it?
Which construct in .md file or any other file do I need to set for it?
We have no support for emitting padding nops. You would have to modify
the x86 backend to emit them, and this would be a non-trivial
Denis Zaitsev wrote:
a) Formally, the code is correct. As p->what can never be < 0
according to its type.
I am assuming this is C code. C and C++ have different rules for enums.
This isn't strictly true. The C standard does not say that enums are
unsigned. It only says that they are equivalent
Rajkishore Barik wrote:
Does anyone know how to obtain the overall spill cost for the old reg
alloc of GCC (global.c)?
We don't have existing hooks for this, but it shouldn't be hard for you
to add them yourself. Try looking at the code, see in particular
dump_global_regs in global.c and the u
Hello,
> >I think I will try the later fix today (mostly because I no longer
> >remember what exactly were the problems that lead me to introducing
> >the TREE_OVERFLOW check to is_gimple_min_invariant).
>
> http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00786.html
> And yes the testcase still fail
Paul Schlie wrote:
Does anyone have any further insight with respect to this potential problem?
I don't believe there is any problem here if attributes are used
correctly. If you need attributes to work differently than they already
do, then you will have to extend gcc yourself.
I also think th
Tom Tromey <[EMAIL PROTECTED]> writes:
> > "Zack" == Zack Weinberg <[EMAIL PROTECTED]> writes:
>
> >> Computed headers are dealt with somewhat clumsily in automake. As a
> >> user you specify "BUILT_SOURCES", and then these are built by 'all'
> >> before anything else is done.
>
> Zack> Thi
Balaji S wrote:
But, i'm not able to access target specific attribute from second level
of indirection onwards.
For example,
int **gpi ;
Note that in this case finding the target means indirecting through a
memory address, and hence we would have to track the attributes of all
memory locations w
Steve Kargl wrote:
I'm looking to the broken behavior of gfortran with its
-r8, -i8, and -d8 options. gfortran/lang.opt contains
You can't choose any name for front-end options. There are complicated
rules for determining whether an option is for the gcc driver or
preprocessor or front-end or b
Mark Mitchell dixit:
>4.1 Status
>==
>
>The 4.1 projects Wiki page shows that four projects have been checked
>in:
Hello etoh-san, do you have a statement about ProPolice for gcc 4?
Are you working on it, or even bringing it into mainline (maybe even
disabled by default, doesn't matter as
On Thu, 2005-03-10 at 18:02 +, Nathan Sidwell wrote:
> Razya Ladelsky wrote:
> > Hi,
> >
> > My case is this:
> > I version the operator<< function and name it operator<<.number (creating
> > an identifier which is not valid in the source code).
> > The assembly name created for the versioned
Someone pointed out lack of documentation for the e500 cpu. Committing
to mainline, 4.0, 3.4, and 3.4-e500-branch.
Phew.
Aldy
* doc/invoke.texi: Add 8540 to list of cpus in rs6000 cpu section.
Index: doc/invoke.texi
===
RCS
Andrew Muraco wrote:
After the compiler is installed im going to recompile glibc using gcc
4.0 and recompile other major parts of the system
This is probably more trouble than it is worth. gcc-4 won't be fully
ABI compatible with gcc-3.4, and you are likely to find bugs in gcc and
various other
feng qiu wrote:
> When I compile with "gcc" ,the output is 6.But the output is 5 when
> using "-fpack-struct" to build,and the "#pragma pack(2)" seems to be
> invalid.What is the reason?
-fpack-struct and #pragma pack(2) are contraditctory instructions, and
-fpack-struct wins. It was never the
Giovanni Bajo wrote:
I would like to still get hold of the information that used to be present at
that page because they were in fact very useful.
This is what web search engines are for. Going to yahoo, typing gcc
visibility, and then clicking on the "cached" link for the first search
result, I
Razya Ladelsky wrote:
Hi,
My case is this:
I version the operator<< function and name it operator<<.number (creating
an identifier which is not valid in the source code).
The assembly name created for the versioned function is the same as the
tree identifier, which is not valid for the assembler.
On Thu, 10 Mar 2005 15:54:03 +0100, Gabriel Dos Reis <[EMAIL PROTECTED]> said:
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
> | On 2005-03-10 01:01:18 +0100, Gabriel Dos Reis wrote:
> | > The asseryion that 0^0 is mathematically undefined is not a bogus
> | > reason. It is a fact.
> |
> | I disa
Marcus <[EMAIL PROTECTED]> wrote:
> > On the page, http://gcc.gnu.org/gcc-4.0/changes.html, the link
> > http://www.nedprod.com/programs/gccvisibility.html (near the end of the
> > document) contains
> >
> > ``DOMAIN HOLDING PAGE
> > ...
On Thu, Mar 10, 2005 at 09:43:42AM +0100, Giovanni Bajo wro
Vincent Lefevre wrote:
BTW, couldn't it be used when compiling C programs too?
Is there anything planned?
Can be used as any other __builtin_*: just call it ;)
By the way, it's also in 4.0, not only mainline.
Paolo.
On 2005-03-10 15:29:49 +0100, Paolo Carlini wrote:
> Vincent Lefevre wrote:
> >What is powi()? I couldn't find it in the C standard. It isn't
> >in the Linux man pages either.
> >
> ;) It's just a new builtin that we have in mainline, very useful for
> implementing the integer power overloads manda
On 2005-03-10 15:54:03 +0100, Gabriel Dos Reis wrote:
> The C standard is not the holy bible and certainly does not define
> everything. We're talking about compiler construction, here.
This isn't just compiler construction. __builtin_cpow is equivalent
to the C99 cpow (as said in gcc/doc/extend.
Vincent Lefevre <[EMAIL PROTECTED]> writes:
| On 2005-03-10 01:01:18 +0100, Gabriel Dos Reis wrote:
| > No. I mean when I call powi() either through built-ins or appropriate
| > overload (several programming languages do so), I expect sane semantics.
|
| What is powi()? I couldn't find it in the
Vincent Lefevre wrote:
On 2005-03-10 01:01:18 +0100, Gabriel Dos Reis wrote:
No. I mean when I call powi() either through built-ins or appropriate
overload (several programming languages do so), I expect sane semantics.
What is powi()? I couldn't find it in the C standard. It isn't
in the
On 2005-03-10 01:01:18 +0100, Gabriel Dos Reis wrote:
> No. I mean when I call powi() either through built-ins or appropriate
> overload (several programming languages do so), I expect sane semantics.
What is powi()? I couldn't find it in the C standard. It isn't
in the Linux man pages either.
>
On Mar 10, 2005, at 6:23 AM, Zdenek Dvorak wrote:
I think I will try the later fix today (mostly because I no longer
remember what exactly were the problems that lead me to introducing
the TREE_OVERFLOW check to is_gimple_min_invariant).
http://gcc.gnu.org/ml/gcc-patches/2003-12/msg00786.html
And y
On Mar 9, 2005, at 03:18, Duncan Sands wrote:
if the Ada front-end has an efficient, accurate implementation
of x^y, wouldn't it make sense to move it to the back-end
(__builtin_pow) so everyone can benefit?
Does not have it yet. Current implementation is reasonably accurate,
but not very fast. How
Hi,
My case is this:
I version the operator<< function and name it operator<<.number (creating
an identifier which is not valid in the source code).
The assembly name created for the versioned function is the same as the
tree identifier, which is not valid for the assembler.
I tried creating an
Hello,
> Why is D.1476 not being propagated? IVOPTS introduces it,
> but I don't see any reason why...
>
> Also, why all the leading zeros? Is there something special
> about that constant? The initial RTL gcc produces for the
> assignment to D.1476 is also suboptimal:
>
> ;; D.1476 = -00
Hi,
Consider this embarassingly trivial function:
void
foo (int a)
{
while (a--) ;
}
Here is the .optimized tree dump that we produce for this test:
;; Function foo (foo)
Analyzing Edge Insertions.
foo (a)
{
int D.1476;
:;
:;
a = a - 1;
D.1476 = -1;
if (a != D.1476) goto ;
Marcus <[EMAIL PROTECTED]> wrote:
> On the page, http://gcc.gnu.org/gcc-4.0/changes.html, the link
> http://www.nedprod.com/programs/gccvisibility.html (near the end of the
> document) contains
>
> ``DOMAIN HOLDING PAGE
>
> This is a holding page for a domain registered by Total Registrations on
47 matches
Mail list logo
