On Friday 08 April 2005 00:12, James E Wilson wrote:
> On Thu, 2005-04-07 at 04:35, Bernd Schmidt wrote:
> > Try the patch below - does it fix the problem?
>
> OK, I will try it. This may take about 2 days. My lone IA-64 machine
> is busy doing other stuff at the moment.
With this patch, I can b
Hello everybody,
I need benchmark programs for my project.
Does anybody have or know the links to C benchmarks
that can be compiled using gcc?
Thanking you,
Vivek
__
Yahoo! Messenger
Show us what our next emoticon should look like. Join the fun.
Steven Bosscher wrote:
On Friday 08 April 2005 00:12, James E Wilson wrote:
On Thu, 2005-04-07 at 04:35, Bernd Schmidt wrote:
Try the patch below - does it fix the problem?
OK, I will try it. This may take about 2 days. My lone IA-64 machine
is busy doing other stuff at the moment.
With this pat
> I see that's not the problem. AFAICT from the code that deals with
> builtin_apply and builtin_return it looks like untyped_call and
> untyped_return should be doing what you expect for the code to save the
> values (a quick glance at sparc.md didn't show any problems, but...). Or
> is something
Geert Bosch <[EMAIL PROTECTED]>:
> As far as I can seem from this patch, it rounds
incorrectly.
> This is a problem with the library version as well,
I believe.
>
> The issue is that one cannot round a positive float
to int
> by adding 0.5 and truncating. (Same issues with
negative values
> an
Folks,
I am looking for information on the different sections that are generated
by the GNU compiler when compiling C code for an embedded PowerPC,
specifically an MPC860.
I need to understand the GOT, GOT2 and FIXUP sections in order to
modify the boot loader for my embedded board.
I should fir
Many thanks to all for the lessons on how NOT to make things you don't
want.
After 56 hours teh full make bootstrap finished - make install failed
miserable as
install.sh was not where it belonged - so I copied the SRCDIR install.sh
in and that made the top level installs work, but the sub-sub dir
On Fri, Apr 08, 2005 at 09:05:17AM -0400, Ray Holme wrote:
> Many thanks to all for the lessons on how NOT to make things you don't
> want.
>
> After 56 hours teh full make bootstrap finished - make install failed
> miserable as
> install.sh was not where it belonged - so I copied the SRCDIR insta
Andrew Pinski writes:
>
> On Apr 7, 2005, at 1:59 PM, Andrew Haley wrote:
>
> > So maybe it is a front end bug. I'm working on it now.
>
> Note I really doubt this is a front-end bug as exception handling
> is lowered on the tree and then expanded from the tree tables to
> the rtl table
On Thu, 2005-04-07 at 19:45, Eric Christopher wrote:
> On Thu, 2005-04-07 at 16:48 +0200, Eric Botcazou wrote:
> > > That was my thoughts too. You could take a look at how I fixed it on
> > > ARM.
> >
> > Thanks. So basically you bypass the apply_result_mode array entirely,
> > which
> > is st
One of the micro-optimizations I am about to merge from TCB
involves disregarding V_MAY_DEF/V_MUST_DEF operands for read-only
globals.
So, if a symbol is marked read-only and the operand scanner
requests a V_MAY_DEF or V_MUST_DEF operand for it, we replace it
with a VUSE.
This works fine, except
There's a rather annoying bug in the vectorizer which can cause us to
have SSA_NAMEs which are used, but never defined.
Consider this testcase compiled with -msse2 -ftree-vectorize:
typedef char achar __attribute__ ((__aligned__(16)));
int main1 ()
{
struct {
achar *p;
achar *q;
} s;
On Apr 8, 2005, at 1:35 AM, vivek sukumaran wrote:
Hello everybody,
I need benchmark programs for my project.
Does anybody have or know the links to C benchmarks
that can be compiled using gcc?
Thanking you,
You question is not clear and this is probably
wrong list for whatever you are looking for.
On Thu, Apr 07, 2005 at 03:36:18PM -0700, James E Wilson wrote:
> H. J. Lu wrote:
> >Gcc 4,0 generates
> >.section .gnu.linkonce.t._ZN3FooC1Ev,"axG",@progbits,_ZN3FooC1Ev,comdat
> >for comdat group. Can gcc use
> >.section .text._ZN3FooC1Ev,"axG",@progbits,_ZN3FooC1Ev,comdat
> >instead? At least, t
On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
> There's a rather annoying bug in the vectorizer which can cause us to
> have SSA_NAMEs which are used, but never defined.
>
> Consider this testcase compiled with -msse2 -ftree-vectorize:
>
> typedef char achar __attribute__ ((__ali
On Fri, 2005-04-08 at 12:45 -0400, Diego Novillo wrote:
> One of the micro-optimizations I am about to merge from TCB
> involves disregarding V_MAY_DEF/V_MUST_DEF operands for read-only
> globals.
>
> So, if a symbol is marked read-only and the operand scanner
> requests a V_MAY_DEF or V_MUST_DEF
> When we rescan the operands, we get a different set of V_MAY_DEFS,
> specifically we lose the V_MAY_DEF for SFT.3_20.
Why?
It should be copying subvars to the new vectorizer variable too.
At least, i believe i added that.
On Fri, 2005-04-08 at 13:04 -0400, Daniel Berlin wrote:
> > When we rescan the operands, we get a different set of V_MAY_DEFS,
> > specifically we lose the V_MAY_DEF for SFT.3_20.
>
> Why?
>
> It should be copying subvars to the new vectorizer variable too.
> At least, i believe i added that.
Whe
On Fri, 2005-04-08 at 18:58 +0200, Jakub Jelinek wrote:
> On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
> > There's a rather annoying bug in the vectorizer which can cause us to
> > have SSA_NAMEs which are used, but never defined.
> >
> > Consider this testcase compiled with -mss
On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
> > There's a rather annoying bug in the vectorizer which can cause us to
> > have SSA_NAMEs which are used, but never defined.
> >
> > Consider this testcase compiled with -msse2 -ftree-vectorize:
> >
> > typedef char achar __attrib
On Fri, Apr 08, 2005 at 09:20:47AM -0400, Daniel Jacobowitz wrote:
> On Fri, Apr 08, 2005 at 09:05:17AM -0400, Ray Holme wrote:
> > Many thanks to all for the lessons on how NOT to make things you don't
> > want.
> >
> > After 56 hours teh full make bootstrap finished - make install failed
> > mis
On Fri, Apr 08, 2005 at 10:11:33AM -0700, Joe Buck wrote:
> On Fri, Apr 08, 2005 at 06:58:54PM +0200, Jakub Jelinek wrote:
> > See middle-end/20794, there is discussion about declaring this
> > invalid. When a type with size that is not an integral multiple
> > of alignment (e.g. smaller size than
On Apr 8, 2005, at 10:08 AM, Jeffrey A Law wrote:
On Fri, 2005-04-08 at 13:04 -0400, Daniel Berlin wrote:
When we rescan the operands, we get a different set of V_MAY_DEFS,
specifically we lose the V_MAY_DEF for SFT.3_20.
Why?
It should be copying subvars to the new vectorizer variable too.
At leas
On Fri, 2005-04-08 at 12:52, Jeffrey A Law wrote:
> In the interest of brevity, I'm just going to point out the
> problematical store from the .ifcvt dump:
>
>
> # x_16 = V_MAY_DEF ;
> # SFT.3_20 = V_MAY_DEF ;
> *D.1470_8 = D.1472_11;
>
> Which gets vectorized and appears like this in
On Apr 8, 2005, at 1:26 PM, Devang Patel wrote:
On Apr 8, 2005, at 10:08 AM, Jeffrey A Law wrote:
On Fri, 2005-04-08 at 13:04 -0400, Daniel Berlin wrote:
When we rescan the operands, we get a different set of V_MAY_DEFS,
specifically we lose the V_MAY_DEF for SFT.3_20.
Why?
It should be copying sub
On Fri, 2005-04-08 at 13:26, Devang Patel wrote:
> On Apr 8, 2005, at 10:08 AM, Jeffrey A Law wrote:
>
> > On Fri, 2005-04-08 at 13:04 -0400, Daniel Berlin wrote:
> >>> When we rescan the operands, we get a different set of V_MAY_DEFS,
> >>> specifically we lose the V_MAY_DEF for SFT.3_20.
> >>
>
dnovillo wrote:
> [...]
> I rebooted the machine into a new kernel on 2005-03-31
> (2.6.10-1.770_FC3). The slowdown coincided with the box being
> rebooted into the new kernel:
> [...]
> 2005-03-305,704 <-- 2.6.10-1.760_FC3
> 2005-03-317,026 <-- 2.6.10-1.770_FC3
> [..
On Fri, Apr 08, 2005 at 07:25:37PM +0200, Jakub Jelinek wrote:
> On Fri, Apr 08, 2005 at 10:11:33AM -0700, Joe Buck wrote:
> > The problem, then, is that there's no way for the user to specify
> > that we have an array whose beginning has, say, 16-byte alignment,
> > but that after that, the elemen
On Fri, 2005-04-08 at 13:27, Andrew MacLeod wrote:
> On Fri, 2005-04-08 at 12:52, Jeffrey A Law wrote:
> > When we rescan the operands, we get a different set of V_MAY_DEFS,
> > specifically we lose the V_MAY_DEF for SFT.3_20. Which results in
> > uses of SFT.3_20 later, but SFT.3_20 is never def
On Fri, 2005-04-08 at 11:08 -0600, Jeffrey A Law wrote:
> On Fri, 2005-04-08 at 13:04 -0400, Daniel Berlin wrote:
> > > When we rescan the operands, we get a different set of V_MAY_DEFS,
> > > specifically we lose the V_MAY_DEF for SFT.3_20.
> >
> > Why?
> >
> > It should be copying subvars to th
On Fri, Apr 08, 2005 at 10:13:38AM -0700, Joe Buck wrote:
> On Fri, Apr 08, 2005 at 09:20:47AM -0400, Daniel Jacobowitz wrote:
> > On Fri, Apr 08, 2005 at 09:05:17AM -0400, Ray Holme wrote:
> > > Many thanks to all for the lessons on how NOT to make things you don't
> > > want.
> > >
> > > After 5
On Fri, 2005-04-08 at 13:27, Andrew MacLeod wrote:
> On Fri, 2005-04-08 at 12:52, Jeffrey A Law wrote:
>
actually, I'll jsut keep talking to myself here :-)
> > In the interest of brevity, I'm just going to point out the
> > problematical store from the .ifcvt dump:
> >
> >
> > # x_16 = V_
On Fri, 2005-04-08 at 13:27 -0400, Andrew MacLeod wrote:
>
>
> What are these uses?
The later uses are scalar reads from the same memory location.
> If they are references to things that aliased
> *D.1470_8, we should eliminate the VUSE/MAYDEF, shouldnt we? I presume
> they arent relevant any
On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
> It would probably be wise to audit the other uses of
> copy_virtual_operands. We might also consider forcing statement
> rescans as part of our IL checking code to avoid these kinds of
> problems in the future.
>
Yes, I've run int
On Fri, Apr 08, 2005 at 11:44:34AM -0600, Jeffrey A Law wrote:
> For the alias not to be relevant would indicate that vectorization
> actually improved alias analysis.
>
Right. Both ivopts and vectorization have that effect, and
that's why the IL needs to be rescanned.
Diego.
On Fri, 2005-04-08 at 13:55 -0400, Diego Novillo wrote:
> On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
>
> > It would probably be wise to audit the other uses of
> > copy_virtual_operands. We might also consider forcing statement
> > rescans as part of our IL checking code to a
On Fri, 2005-04-08 at 13:41 -0400, Andrew MacLeod wrote:
> On Fri, 2005-04-08 at 13:27, Andrew MacLeod wrote:
> > On Fri, 2005-04-08 at 12:52, Jeffrey A Law wrote:
> >
>
> actually, I'll jsut keep talking to myself here :-)
>
> > > In the interest of brevity, I'm just going to point out the
> >
On 2005-04-05, at 16:12, Nix wrote:
I could turn the question back: What's so hard about grepping the
source?
Because one does not expect to find compilation flags embedded in the
source?
One does - if not grown up in the limited gcc "community". All the high
scale
compilers out there DO IT.
B
On Fri, 2005-04-08 at 13:58 -0400, Diego Novillo wrote:
> On Fri, Apr 08, 2005 at 11:44:34AM -0600, Jeffrey A Law wrote:
>
> > For the alias not to be relevant would indicate that vectorization
> > actually improved alias analysis.
> >
> Right. Both ivopts and vectorization have that effect, an
On Fri, Apr 08, 2005 at 12:04:02PM -0600, Jeffrey A Law wrote:
> On Fri, 2005-04-08 at 13:55 -0400, Diego Novillo wrote:
> > On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
> >
> > > It would probably be wise to audit the other uses of
> > > copy_virtual_operands. We might also co
> > Also, after ivopts, the whole CFG needs to be
> > re-scanned because the new alias relations it creates affect
> > statements that have not even been modified by the process.
> Wow. Egad.
>
Yes, this would be very ungood if it is the case.
If it is really changing the *semantics* of the pr
On Thu, Apr 07, 2005 at 07:14:05PM +0100, Paul Brook wrote:
> On Thursday 07 April 2005 18:54, Steve Kargl wrote:
> > On Thu, Apr 07, 2005 at 01:41:21PM -0400, Geert Bosch wrote:
> > > On Apr 7, 2005, at 13:27, Steve Kargl wrote:
> > > >Try -fdump-parse-tree. You've given more digits in y than
> >
On Fri, 2005-04-08 at 13:39 -0400, Daniel Berlin wrote:
> On Fri, 2005-04-08 at 11:08 -0600, Jeffrey A Law wrote:
> > On Fri, 2005-04-08 at 13:04 -0400, Daniel Berlin wrote:
> > > > When we rescan the operands, we get a different set of V_MAY_DEFS,
> > > > specifically we lose the V_MAY_DEF for SFT
Danny Smith wrote:
Danny, according to that bug report in SF, you said that you're not
submitting that bug to GCC because you couldn't test it on Win 2K and
XP. Now it's been tested on both platforms, are you willing to submit
that patch to GCC?
No, I have an alternative patch that also
On Fri, Apr 08, 2005 at 09:57:35AM -0700, H. J. Lu wrote:
> On Thu, Apr 07, 2005 at 03:36:18PM -0700, James E Wilson wrote:
> > H. J. Lu wrote:
> > >Gcc 4,0 generates
> > >.section .gnu.linkonce.t._ZN3FooC1Ev,"axG",@progbits,_ZN3FooC1Ev,comdat
> > >for comdat group. Can gcc use
> > >.section .text.
On Thu, Apr 07, 2005 at 08:34:01PM -0400, Diego Novillo wrote:
> I'm rebooting the machine into the previous kernel right now to
> see if it changes things. Tomorrow's run will use kernel
> 2.6.10-1.760_FC3.
>
Well, it seem that the kernel had nothing to do with the problem.
Today's bootstrap ti
On Saturday 09 April 2005 00:32, Diego Novillo wrote:
> On Thu, Apr 07, 2005 at 08:34:01PM -0400, Diego Novillo wrote:
> > I'm rebooting the machine into the previous kernel right now to
> > see if it changes things. Tomorrow's run will use kernel
> > 2.6.10-1.760_FC3.
>
> Well, it seem that the k
On Sat, Apr 09, 2005 at 12:35:47AM +0200, Steven Bosscher wrote:
> On Saturday 09 April 2005 00:32, Diego Novillo wrote:
> > On Thu, Apr 07, 2005 at 08:34:01PM -0400, Diego Novillo wrote:
> > > I'm rebooting the machine into the previous kernel right now to
> > > see if it changes things. Tomorrow
On Fri, 2005-04-08 at 18:48 -0400, Daniel Jacobowitz wrote:
> On Sat, Apr 09, 2005 at 12:35:47AM +0200, Steven Bosscher wrote:
> > On Saturday 09 April 2005 00:32, Diego Novillo wrote:
> > > On Thu, Apr 07, 2005 at 08:34:01PM -0400, Diego Novillo wrote:
> > > > I'm rebooting the machine into the pr
Daniel Berlin wrote:
Your transform is correct.
The FE is not. The variable is not read only.
It is write once, then read-only.
Diego, your analysis is exactly correct about what is happenning.
I agree, in principle. The C++ FE should not set TREE_READONLY on
variables that require dynanmic initi
On Apr 8, 2005, at 4:40 PM, Mark Mitchell wrote:
Daniel Berlin wrote:
Your transform is correct.
The FE is not. The variable is not read only.
It is write once, then read-only.
Diego, your analysis is exactly correct about what is happenning.
I agree, in principle. The C++ FE should not set TREE_R
On Fri, 2005-04-08 at 16:51 -0700, Dale Johannesen wrote:
> On Apr 8, 2005, at 4:40 PM, Mark Mitchell wrote:
>
> > Daniel Berlin wrote:
> >
> >> Your transform is correct.
> >> The FE is not. The variable is not read only.
> >> It is write once, then read-only.
> >
> > Diego, your analysis is exac
On Fri, Apr 08, 2005 at 07:36:17PM -0400, Daniel Berlin wrote:
> [ tracking down sudden increase in bootstrap time ]
> So just so we are clear on the state:
>
> Jim works on a machine:
>
> Sees no difference in compile times from 03-29 -> 04-01
>
> Diego works on a machine
>
> Sees 50% differ
Snapshot gcc-3.4-20050408 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/3.4-20050408/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 3.4 CVS branch
with the following options: -rgcc-ss-3_4-20050408
You'll
Dale Johannesen <[EMAIL PROTECTED]> wrote:
>> I do think the C++ FE needs fixing before Diego's change gets merged,
>> though. I can make the change, but not instantly. If someone files
>> a PR, and assigns to me, I'll get to it at some not-too-distant
>> point.
>
> It would be good to have a wa
On Fri, Apr 08, 2005 at 04:40:01PM -0700, Mark Mitchell wrote:
> I do think the C++ FE needs fixing before Diego's change gets merged,
> though. I can make the change, but not instantly. If someone files a
> PR, and assigns to me, I'll get to it at some not-too-distant point.
>
PR c++/20912.
>> On Fri, 2005-04-08 at 16:51 -0700, Dale Johannesen wrote:
>>> On Apr 8, 2005, at 4:40 PM, Mark Mitchell wrote:
Daniel Berlin wrote:
Your transform is correct.
The FE is not. The variable is not read only.
It is write once, then read-only.
>>>
>>> Diego, your analysis is exact
On Fri, Apr 08, 2005 at 07:57:31PM -0400, Daniel Berlin wrote:
> Some of these global properties probably belong in cgraph_var node's
> instead of shoving them into the tree structure.
I tend to agree. This would allow us to do things like find out
that the variable is read-write while compiling
58 matches
Mail list logo
