Hi
I am currently looking at interix gcc and found that -fPIC generated binaries
crash although not all binaries crash. This has been known for quite some time
since I found a lot of posts about it. I want to know if this issue has already
been fixed and a patch submitted or this issues is stil
> The tree_opt_pass for my pass has PROP_ssa set in the properties_required
> field. Is this all I need to do?
You need to put your pass after pass_build_ssa. Setting PROP_ssa does
not build SSA itself, but it will cause an assertion failure if the
pass is run while SSA is (not yet) available.
> > The tree_opt_pass for my pass has PROP_ssa set in the
> properties_required
> > field. Is this all I need to do?
>
> You need to put your pass after pass_build_ssa. Setting PROP_ssa does
> not build SSA itself, but it will cause an assertion failure if the
> pass is run while SSA is (not yet
> I think (if I'm correctly interpreting the list in passes.c) it is. It's
> right after pass_warn_function_noreturn, just before pass_mudflap_2. Is
> this right? I don't get any assertion about SSA not being available.
In this case, it is also after pass_del_ssa, which means SSA has already
be
> > I think (if I'm correctly interpreting the list in passes.c) it is.
> It's
> > right after pass_warn_function_noreturn, just before pass_mudflap_2.
> Is
> > this right? I don't get any assertion about SSA not being available.
>
> In this case, it is also after pass_del_ssa, which means SSA ha
On 3/21/07, Nicholas Nethercote <[EMAIL PROTECTED]> wrote:
On Wed, 21 Mar 2007, Paul Brook wrote:
> The problem is that I don't think writing a detailed "mission statement" is
> actually going to help anything. It's either going to be gcc contributors
> writing down what they're doing anyway, or
On 3/22/07, Alexander Lamaison <[EMAIL PROTECTED]> wrote:
> > The tree_opt_pass for my pass has PROP_ssa set in the
> properties_required
> > field. Is this all I need to do?
>
> You need to put your pass after pass_build_ssa. Setting PROP_ssa does
> not build SSA itself, but it will cause an a
On Thu, 2007-03-22 at 08:17 +1100, Nicholas Nethercote wrote:
> On Wed, 21 Mar 2007, Paul Brook wrote:
>
> > The problem is that I don't think writing a detailed "mission statement" is
> > actually going to help anything. It's either going to be gcc contributors
> > writing down what they're doing
On Thu, Mar 22, 2007 at 04:22:37PM +0800, Mayank Kumar wrote:
> I am currently looking at interix gcc and found that -fPIC generated
> binaries crash although not all binaries crash. This has been known for
> quite some time since I found a lot of posts about it. I want to know if
> this issue has
Is this an appropriate SoC project?
Gcc can optionally be configured with --enable-mapped-locations.
This sets a conditional USE_MAPPED_LOCATION which changes how
line and column numbers are represented in the various data
structures. We'd like to switch gcc to use this representation,
for vario
"Doug Gregor" <[EMAIL PROTECTED]> writes:
> +#undef TREE_CODE
> +/* We redefine TREE_CODE here to omit the explicit case to "enum
> + tree_code", which has the side-effect of silencing the "case value
> + NNN not in enumerated type" warnings. */
> +#define TREE_CODE(NODE) ((NODE)->base.code)
Per Bothner <[EMAIL PROTECTED]> writes:
> Is this an appropriate SoC project?
Yes, certainly. I added a link to gcc's SoC project page
(http://gcc.gnu.org/wiki/SummerOfCode).
Ian
Am 21.03.2007, 23:38 Uhr, schrieb Ian Lance Taylor <[EMAIL PROTECTED]>:
"H. J. Lu" <[EMAIL PROTECTED]> writes:
On Wed, Mar 21, 2007 at 09:19:44PM +0100, fafa wrote:
> Hi all,
>
> I noticed that G++ 4.1.2 (on a Pentium 4) generates different
instructions
> for
> lea0x0(%esi),%esi
> or
On Mar 22, 2007, at 12:03 PM, fafa wrote:
I see. But why not simple "nop" instructions ?
They are the wrong size or too slow. Anyway, this is the wrong list
for such questions generally. This list is for developers of gcc.
fafa <[EMAIL PROTECTED]> writes:
> >> > I noticed that G++ 4.1.2 (on a Pentium 4) generates different
> >> instructions
> >> > for
> >> > lea0x0(%esi),%esi
> >> > or
> >> > lea0x0(%edi),%edi
> >> > with the same meaning but different encoding depending on the switch
> >> > "-momit-leaf
On Mar 22, 2007, at 9:13 AM, Doug Gregor wrote:
8-bit tree code (baseline):
real0m51.987s
user0m41.283s
sys 0m0.420s
subcodes (this patch):
real0m53.168s
user0m41.297s
sys 0m0.432s
9-bit tree code (alternative):
real0m56.409s
user0m43.942s
sys 0m0.429s
I
On Thu, Mar 22, 2007 at 12:28:15PM -0700, Mike Stump wrote:
> On Mar 22, 2007, at 9:13 AM, Doug Gregor wrote:
> >8-bit tree code (baseline):
> >
> >real0m51.987s
> >user0m41.283s
> >sys 0m0.420s
> >
> >subcodes (this patch):
> >
> >real0m53.168s
> >user0m41.297s
> >sys 0m0.4
On 3/22/07, Joe Buck <[EMAIL PROTECTED]> wrote:
But these numbers show that subcodes don't cost *ANY* time, or the
cost is in the noise, unless enable-checking is on. The difference
in real-time seems to be an artifact, since the user and sys times
are basically the same.
The subcodes cost com
On 3/22/07, Doug Gregor <[EMAIL PROTECTED]> wrote:
The results, compile time:
For what test case?
For a bootstrapped, --disable-checking compiler:
8-bit tree code (baseline):
real0m51.987s
user0m41.283s
sys 0m0.420s
subcodes (this patch):
real0m53.168s
user0m41.297s
sy
I work for Microsoft SFU(services for unix) group and I am currently
investigating this fPIC issue for gcc 3.3 which is available with sfu 3.5. I
have currently no intention of supporting the latest gcc for interix but I am
more interested in fixing this fPIC issue for Interix as well as contrib
On Thursday 22 March 2007 20:20, Mayank Kumar wrote:
> I work for Microsoft SFU(services for unix) group and I am currently
> investigating this fPIC issue for gcc 3.3 which is available with sfu 3.5.
gcc3.3 is really quite old, and hasn't been maintained for quite some time.
You're unlikely to ge
> As for what is best to do, I don't know. But I do know that complexity is
> bad, and that GCC is very complex. You are absolutely right about there
> being hard limits. There are trade-offs required. Whether the current and
> ongoing trade-offs are the right ones is an open question.
I'm comp
Tarmo Pikaro wrote:
If you consider different languages - c, c++, java - they are not much different
- syntax somehow vary, but you can basically create the same application using
different languages. "Generic" tries to generalize structures available in all
languages
into common form. I think c
On Mar 22, 2007, at 12:28 PM, Mike Stump wrote:
for a -g 16-bit code compile:
real0m2.629s0.15% slower
user0m2.504s
sys 0m0.121s
for a -g -O2 16-bit code compile:
real0m12.958s 0.023% slower
user0m1
On 3/22/07, Mike Stump <[EMAIL PROTECTED]> wrote:
is more obvious than the correctness of the subcoding. Thoughts?
I fully agree.
Gr.
Steven
Steven Bosscher wrote:
> On 3/22/07, Joe Buck <[EMAIL PROTECTED]> wrote:
>> But these numbers show that subcodes don't cost *ANY* time, or the
>> cost is in the noise, unless enable-checking is on. The difference
>> in real-time seems to be an artifact, since the user and sys times
>> are basicall
On 3/22/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 3/22/07, Doug Gregor <[EMAIL PROTECTED]> wrote:
> The results, compile time:
For what test case?
All the numbers I've reported are for tramp3d, compiled with -O2
-funroll-loops -ffast-math on i686-pc-linux-gnu.
Did the 9-bit tree code
On 3/22/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Doug, thanks for doing all the experiments!
OK, we've got to pick our poison.
1. We can go to 9-bit codes. They're slower, independent of checking.
Maybe we can make bitfields go faster, and get some of that back. Of
course, if we can make
> 1. We can go to 9-bit codes. They're slower, independent of checking.
> Maybe we can make bitfields go faster, and get some of that back.
I think it worth understanding why this is. One or even two instructions
should be lost in the noise on a modern machine when they are always
accompanied
On Thu, Mar 22, 2007 at 03:58:43PM -0700, Mike Stump wrote:
> Also, the correctness of: ...
> is more obvious than the correctness of the subcoding. Thoughts?
Totally agreed.
r~
On Thursday 22 March 2007 23:24, Richard Kenner wrote:
> > 1. We can go to 9-bit codes. They're slower, independent of checking.
> > Maybe we can make bitfields go faster, and get some of that back.
>
> I think it worth understanding why this is. One or even two instructions
> should be lost in t
Basile STARYNKEVITCH wrote:
It is quite standard since a long time, and I don't understand why it should
be avoided (as some old Changelog suggest).
Which old ChangeLog? What exactly does it say? We can't help you if we
don't know what you are talking about.
There used to be setjmp calls i
Rohit Arul Raj wrote:
1. The function mcount: While building with native gcc, the mcount
function is defined in glibc. Is the same mcount function available in
newlib? or is it that we have to define it in our back-end as SPARC
does (gmon-sol2.c).
Did you try looking at newlib? Try something l
> If nothing else you've got bigger code (increased icache pressure).
Yeah, but a 3% peformance hit due to that? It's hard to argue with
measurements, but something sounds fishy to me ..
There are still a number of GCC 4.2.0 P1s, including the following which
are new in GCC 4.2.0 (i.e., did not occur in GCC 4.1.x), together with
-- as near as I can tell, based on Bugzilla -- the responsibility parties.
PR 29585 (Novillo): ICE-on-valid
PR 30700 (Sayle): Incorrect constant generatio
Mark Mitchell wrote:
> There are still a number of GCC 4.2.0 P1s, including the following which
> are new in GCC 4.2.0 (i.e., did not occur in GCC 4.1.x), together with
> -- as near as I can tell, based on Bugzilla -- the responsibility parties.
>
> PR 29585 (Novillo): ICE-on-valid
> PR 30700 (Say
On Thu, 22 Mar 2007, Mark Mitchell wrote:
> Joseph, would you please take a look at PR 31136? Andrew believes this
> to be a front-end bug.
I don't think this is a front-end bug.
I applied the patch below to make the dumps give more meaningful
information than . The format of output is the sa
Hi,
am trying to istall the GCJ 4.1.2 version on my SUNOs.
steps i followed:
1. downloaded GCJ4.1.2 core and java tar from GNU site. and extracted it
to GCC4.1
after extracting folder GCC-4.1.2 is created(automatically while
extracting).
the frontend part (java tar) was extraced to /gcc-4
Annapoorna R wrote:
steps i followed:
1. downloaded GCJ4.1.2 core and java tar from GNU site. and extracted it
to GCC4.1
after extracting folder GCC-4.1.2 is created(automatically while
extracting).
the frontend part (java tar) was extraced to /gcc-4.1.2/libjava.
Did ./configure from libj
39 matches
Mail list logo
