On 17/04/2006, at 9:55 PM, Ben Elliston wrote:
Hi Geoff
I'm seeing a bootstrap failure on x86 Linux that looks to be due to
your change (noted below):
/home/bje/build/gcc-clean/./gcc/xgcc -B/home/bje/build/gcc-clean/./
gcc/ -B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-
gnu
[apologies that this will come out threaded slightly wrong, none of my
handy mail clients feel like letting edit the references and in-reply-to
header, apparently it's not cool anymore]
> Dale Johannesen wrote:
>
> > I wasn't aware that it was supposed to be experimental either, and it
> > wasn't
This has been very enlightening information.
Is it documented anywhere which gcc features should not be trusted or
are known to have faults?
Regards,
Ivan
Richard Guenther wrote:
On 4/18/06, Ivan Novick <[EMAIL PROTECTED]> wrote:
I am a gcc user at a fininancial institution and IMHO it wou
Daniel Jacobowitz wrote:
No, this patch is not correct. Take a wander through set_std_prefix
and the call to update_path in add_prefix.
Expected as much :)
You might want to play around with relocation on a non-MinGW-hosted
system, for comparison. Does that work better? If so, it's likely
Hi Geoff
I'm seeing a bootstrap failure on x86 Linux that looks to be due to
your change (noted below):
/home/bje/build/gcc-clean/./gcc/xgcc -B/home/bje/build/gcc-clean/./gcc/
-B/usr/local/i686-pc-linux-gnu/bin/ -B/usr/local/i686-pc-linux-gnu/lib/
-isystem /usr/local/i686-pc-linux-gnu/include -
Dave Murphy wrote:
Ross Ridge wrote:
Dave Murphy wrote:
install: e:/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/
Don't use a --prefix with a drive letter. Just use --prefix=/devkitARM,
and then use "make install DESTDIR=e:/devkitPro" to install it where
you actually want it.
Doesn't
Ross Ridge wrote:
Dave Murphy wrote:
install: e:/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/
Don't use a --prefix with a drive letter. Just use --prefix=/devkitARM,
and then use "make install DESTDIR=e:/devkitPro" to install it where
you actually want it.
Doesn't help, it's still ch
> losing a slight missed optimization on the tree level.
Yay, exactly what I'm trying to fix. Glad you agree.
Aldy
>
> > Well, it's written to only in this testcase. Can you post a more complete
> > one?
>
> Here's the complete testcase.
>
> int g(_Complex int*);
> int f(void)
> {
> _Complex int t = 0;
> __real__ t = 2;
> __imag__ t = 2;
> return g(&t);
> }
Yes but that should not matter always as th
> Well, it's written to only in this testcase. Can you post a more complete
> one?
Here's the complete testcase.
int g(_Complex int*);
int f(void)
{
_Complex int t = 0;
__real__ t = 2;
__imag__ t = 2;
return g(&t);
}
> I should also mention on the mainline, we get the decomposing for the
> orginal testcase which means this is a bug only on the MEM-SSA branch.
No we don't. Look at the actual testcase I posted. This is a bug on
mainline.
> "Mark" == Mark Mitchell <[EMAIL PROTECTED]> writes:
Mark> In any case, the broader question is: to what extent should we have
Mark> experimental options in releases, and how should we warn users of their
Mark> experimental nature?
Why not put this into the option name? Something like '-Xop
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
David Nicol wrote:
> Thank you. Nobody is aware of such a problem.
>
What problem? You have provided no evidence that there indeed is a
problem here. Again, please visit our bug submission page at gcc.gnu.org.
-BEGIN PGP SIGNATURE-
Version:
On Mon, Apr 17, 2006 at 02:53:37PM -0700, Dale Johannesen wrote:
> >So from my point of view, the situation with -ftree-loop-linear is
> >fine - it's ICEing after all, not producing silently wrong-code. For
> >experimental options (where
> >I would include all options not enabled by -O[123s]) know
On Apr 17, 2006, at 2:53 PM, Dale Johannesen wrote:
I'd go further: you should not be trusting a compiler (gcc or any
other) to be correct in "mission critical" situations.
Or, to use the option that spits out the proof that the
transformation of the code that the compiler did was indeed va
Thank you. Nobody is aware of such a problem.
On Apr 17, 2006, at 2:31 PM, Richard Guenther wrote:
On 4/18/06, Ivan Novick <[EMAIL PROTECTED]> wrote:
I am a gcc user at a fininancial institution and IMHO it would not
be a
good idea to have non-production ready functionality in gcc. We are
trying to use gcc for mission critical function
On Mon, Apr 17, 2006 at 04:42:18PM -0500, David Nicol wrote:
> I am using
> gcc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)
>
> under the Inline::C perl module
>
> and having a very weird situation.
You vaguely describe your problem, speculate on its cause, and don't
include a complete testcase. Not
On Mon, Apr 17, 2006 at 04:42:18PM -0500, David Nicol wrote:
> GCC appears to be treating my long macro as some kind of block
> and throwing out variables that are not used within it instead of simply
> pasting the code in at the macro invocation point.
>
> Is this a known problem with 4.0.2? Is
I am using
gcc (GCC) 4.0.2 20051125 (Red Hat 4.0.2-8)
under the Inline::C perl module
and having a very weird situation.
I have a multi-line macro that declares several variables and then does some
work with them, for use in several functions that have similar invocations,
interfacing to an exte
On 4/18/06, Ivan Novick <[EMAIL PROTECTED]> wrote:
> I am a gcc user at a fininancial institution and IMHO it would not be a
> good idea to have non-production ready functionality in gcc. We are
> trying to use gcc for mission critical functionality.
It has been always the case that additional op
I am a gcc user at a fininancial institution and IMHO it would not be a
good idea to have non-production ready functionality in gcc. We are
trying to use gcc for mission critical functionality.
Hope this helps,
Ivan
Mark Mitchell wrote:
Dan Berlin and I exchanged some email about PR 26435, w
On Mon, Apr 17, 2006 at 11:52:26AM -0700, Mark Mitchell wrote:
> My suggestion is that features that are clearly experimental (like this
> one) should be (a) documented as such, and (b) should generate a
> warning, like:
>
> warning: -ftree-loop-linear is an experimental feature and is not
> rec
>
> >
> > Hi folks.
> >
> > While investigating a regression from the V_MUST_DEF removal on mem-ssa,
> > I've noticed that we were missing out on optimization of certain
> > stores to complex types (on mainline).
> >
> > For example, here:
> >
> > _Complex int t = 0;
> > __real__ t = 2;
> >
>
> Hi folks.
>
> While investigating a regression from the V_MUST_DEF removal on mem-ssa,
> I've noticed that we were missing out on optimization of certain
> stores to complex types (on mainline).
>
> For example, here:
>
> _Complex int t = 0;
> __real__ t = 2;
> __imag__ t = 2;
>
> we e
> Mark Mitchell writes:
Mark> My understanding is we might be able to remove just the
Mark> problematic part (or segregate that into a separate option) -- but that
Mark> problematic part is the 177.swim bit, so that's an issue.
Well, yes and no. The 177.swim bit is loop interchange a
Hello,
> What I am trying to do is something like counting the times of a particular
> function call, i.e., whenever there is a CALL_EXPR in the tree, I want to
> look at the id to see if that is the function I want to count during
> runtime. If the id is the function name I want to count, I
On 4/17/06, Aldy Hernandez <[EMAIL PROTECTED]> wrote:
> Hi folks.
>
> While investigating a regression from the V_MUST_DEF removal on mem-ssa,
> I've noticed that we were missing out on optimization of certain
> stores to complex types (on mainline).
>
> For example, here:
>
> _Complex int t = 0;
> I see the original rationale for inhibiting creation of subvariables
> on aggregates here:
>
> http://gcc.gnu.org/ml/fortran/2006-01/msg00195.html
>
> But I don't think, memory wise, it should apply to complex types.
> This patch will cause the clearring of "t" to be redundant on mainline.
> On
Thanks for reply.
What I am trying to do is something like counting the times of a particular
function call, i.e., whenever there is a CALL_EXPR in the tree, I want to
look at the id to see if that is the function I want to count during
runtime. If the id is the function name I want to count,
Dale Johannesen wrote:
> I wasn't aware that it was supposed to be experimental either, and it
> wasn't explained that way when it went in (Sep 2004). (Incomplete or
> buggy would not be surprising, but it sounds now like we're talking
> about fatally flawed design, which is different.)
My under
Hi folks.
While investigating a regression from the V_MUST_DEF removal on mem-ssa,
I've noticed that we were missing out on optimization of certain
stores to complex types (on mainline).
For example, here:
_Complex int t = 0;
__real__ t = 2;
__imag__ t = 2;
we end up with:
# t_2 = V_MU
On Apr 17, 2006, at 11:52 AM, Mark Mitchell wrote:
Dan Berlin and I exchanged some email about PR 26435, which concerns a
bug in -ftree-loop-linear, and we now think it would make sense to
have
a broader discussion.
The PR in question is about an ice-on-valid regression in 4.1, when
using -O1
David Edelsohn wrote:
> -ftree-loop-linear enables a number of features and
> transformations. Which part, exactly, is experimental? You are quoting
> from the documentation for the option, but Dan may be referring to a
> particular transformation. I thought the failure and algorithm
> cor
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark Mitchell wrote:
> Thoughts?
>
I don't know which of the loop linear transformations you folks were
debating (the loop linear stuff defines a family of transformations),
but I vote for having no experimental features in releases.
If a feature is
-ftree-loop-linear enables a number of features and
transformations. Which part, exactly, is experimental? You are quoting
from the documentation for the option, but Dan may be referring to a
particular transformation. I thought the failure and algorithm
correctness was related to creati
Dan Berlin and I exchanged some email about PR 26435, which concerns a
bug in -ftree-loop-linear, and we now think it would make sense to have
a broader discussion.
The PR in question is about an ice-on-valid regression in 4.1, when
using -O1 -ftree-loop-linear. Dan notes that this optimization o
Dave Murphy wrote:
> install: e:/devkitPro/devkitARM/lib/gcc/arm-elf/4.1.0/
Don't use a --prefix with a drive letter. Just use --prefix=/devkitARM,
and then use "make install DESTDIR=e:/devkitPro" to install it where
you actually want it.
Ross Ridge
On Mon, 2006-04-17 at 14:48 +0200, Marcin 'Qrczak' Kowalczyk wrote:
> There is a missing opportunity for optimization.
>
> int f(void);
> void test(int x) {
>if (x & 1 ? x == 0 : x > 0) f();
> }
>
> This is gcc-4.1.0-0.20051206 with some patches by PLD Linux
> Distribution. gcc -S -O2 -fomit-
[EMAIL PROTECTED] wrote:
I decided to look into the Yara branch to see if it could even be
bootstrap on PPC (with Yara turned on by default).
Thanks, for the information. It is even a surprise for me that some
tests work correctly for ppc. Last time when I had time and checked ppc
stat
I decided to look into the Yara branch to see if it could even be
bootstrap on PPC (with Yara turned on by default).
I ran into an ICE while compiling libgcc2.c for __muldi3.
The ICE was in emit_secondary_memory_move.
The preprocessed source is:
typedef int SItype __attribute__ ((mode (SI)));
ty
How about a pull-together of all the existing docs on how to create a new
front-end / back-end.. stuff like whats in the gcc internals doc, and
Stallman's "Using and porting gcc".. maybe update it all in a single place
for ver 4.x, and update for the undocumented / obsolete macros? It's not
st
There is a missing opportunity for optimization.
int f(void);
void test(int x) {
if (x & 1 ? x == 0 : x > 0) f();
}
This is gcc-4.1.0-0.20051206 with some patches by PLD Linux
Distribution. gcc -S -O2 -fomit-frame-pointer generates the
following code:
test:
movl4(%esp), %eax
VASTU BULLETIN VOLUME-29 [APR JUNE 2006]
Environment & Landscaping according to vastu
In this issue, we will be focusing on understanding environmental
influences of location. The location must have good energy. Living in a
beautiful environment is much more supportive than living in an
en
On Sun, 2006-04-16 21:30:08 -0700, Ian Lance Taylor wrote:
> http://gcc.gnu.org/projects/
> If anybody wants to pull together a single URL of projects suitable
> for students, probably on the Wiki page, that would be helpful. Or I
> might try to tackle that in the next few days myself.
Maybe
45 matches
Mail list logo
