Daniel Berlin wrote on 04/14/07 22:59:
> If there was stmt->aux we'd put it there instead (note that the
> current way wastes memory, since we really only care about UID's for
> statements that generate vdefs/vuses)
That's the thing. There currently is *no* "aux" field to do this. We
may be for
Andrea Callia D'Iddio wrote on 04/17/07 08:30:
> I know that if expression 'e' is a variable or an array element, then
> TREE_CODE(e)==VAR_DECL. But how can I know if 'e' is a variable, or an
> array element? and, if it's an array element, how can I know which is
> the index value? can I have othe
J.C. Pizarro wrote on 04/17/07 21:48:
> The visual representation in HTML is more effective for humans than
> in text.
No. Heck, no.
H. J. Lu wrote on 04/20/07 21:30:
> -fprefetch-loop-arrays shouldn't be on by default since HW prefetch
> usually will have negative performance impact on Intel.
We are talking about one specific architecture where it usually helps: ia64.
Robert Dewar wrote on 04/20/07 21:42:
> One possibility would be to have a -Om switch (or whatever) that
> says "do all optimizations for this machine that help".
I think this is a good compromise. I personally don't think we should
limit ourselves to doing the exact same optimizations across al
Mark Mitchell wrote on 04/23/07 13:56:
> So, I think there's a middle ground between "exactly the same passes on
> all targets" and "use Acovea for every CPU to pick what -O2 means".
> Using Acovea to reveal some of the suprising, but beneficial results,
> seems like a fine idea, though.
I'm hopi
Dave Korn wrote on 04/23/07 14:26:
> Has any of the Acovea research demonstrated whether there actually is any
> such thing as a "good default set of flags in all cases"? If the results
Not Acovea itself. The research I'm talking about involves a compiler
whose pipeline can be modified and re
[EMAIL PROTECTED] wrote on 04/23/07 14:37:
> Currently, the -On flags set/unset 60 flags, which yields 2^60 conbinations.
> If you also kind the passes not controlled by a flag, but decided upon
> depending on the optimization level, that adds another, virtual flag
> (i.e. using -O1, -O2, -O3
[EMAIL PROTECTED] wrote on 04/23/07 14:40:
> Any references?
Yes, at the last HiPEAC conference Grigori Fursin presented their
interactive compilation interface, which could be used for this.
http://gcc-ici.sourceforge.net/
Ben Elliston had also experimented with a framework to allow GCC to
chan
Richard Guenther wrote on 04/25/07 03:54:
> I guess I can only produce a workaround, as I'm not too deeply into
> the aliasing stuff. So I'd prefer if Danny or Diego could have a look
> (Danny apperantly doesn't have time to do so, my bets for Diego are
> similar), but I'll give the workaround I
Geert Bosch wrote on 04/25/07 11:49:
> I'd assume 100% contain 0 or more register operands.
> Did you mean 43% contain 1 or more?
Well, no. I meant 0 or more, but it's badly worded. It means that 43%
of the statements either have no operands or they contain only register
operands. I'll rephras
Daniel Berlin wrote on 04/25/07 14:40:
> It still has the addresses_taken bitmap, remove it :)
Oh, right. Is it gone already?
> Also, I assume for a call with no return, it will be a GS_CALL with lhs ==
> NULL?
Yes. I clarified it. Thanks.
Sjodin, Jan wrote on 05/01/07 13:54:
> Does LTO have any hard dependencies on the gimple-tuples? I imagine the
> on-disk representation could be separate from any internal
> representation. I am curious if the two efforts can be worked on in
> parallel and how well they can be separated, since the
On 5/1/07, Sjodin, Jan <[EMAIL PROTECTED]> wrote:
Does anyone know how many people that are currently working on the
tuple representation and can perhaps guess how many months it would take to
get into mainline?
Aldy is working full time on it, atm. Richard, Andrew and I may start
working on
Nathanael Nerode wrote:
"Although maintaining a development branch, including merging new changes from
the mainline, is somewhat burdensome, the absolute worst case is that such a
branch will have to be maintained for four months."
This is wrong. There is no limit on how long a development branch
Andrew Pinski wrote:
But it is documented on our own web site:
http://gcc.gnu.org/develop.html
Yes, I know. I still disagree with it. But don't care enough to keep
arguing about it.
Diego.
Steven Bosscher wrote:
It's not about how long the branch may live, but the most time it
may have to be maintained before being merged.
We're splitting semantic hairs now, but you need to maintain the branch
during its lifetime, not just the 4 months prior to its merge. Anyway,
this is about all
Janis Johnson wrote:
I also find it annoying that the dump files aren't cleaned up. Should
the dump files for failing tests be left, or would it be OK to remove
all of them?
Much as I don't use the failing executables left behind by the
testsuite, I wouldn't use the dump files. They can be easil
Zack Weinberg wrote:
(a) the numbers reported by the "time" command,
real0m10.129s
user0m4.387s
sys 0m0.726s
(b) what sort of machine this is and how old, and
i686-pc-linux-gnu, P4 3GHz (about a year old).
(c) whether or not you would be willing to trade that much additional
delay in an
Mark Mitchell wrote:
* Structure Aliasing Part I
Submitted today. I've started reading it over.
Diego.
On 03/12/05 08:14, Rajesh Babu wrote:
I want the root node of the AST built by gcc, so that I can do the
manipulations I want to do on the intermediate nodes of AST. Can
someone tell me where I can find the root node of AST and the place
where the construction of AST finishes in GCC source.
To represent call-clobbering effects we currently collect all the
call-clobbered symbols and make every call a definition site for each of
them. For instance, given 3 global variables X, Y and Z:
foo()
{
X = 3
Y = 1
Z = X + 1
bar ()
Y = X + 2
return Y + Z
}
we put the three symbols in
On Mon, Mar 14, 2005 at 11:42:18AM +0900, J. Hart wrote:
> Are there currently any other facilities in gcc for this kind of support
> for memory checkers ?
>
You may want to try -fmudflap in current 4.0 snapshots.
Diego.
Starting around 2005-03-17, I haven't been able to compile
several SPEC tests with mainline. Has there been any change in
the pre-processor that might explain these errors?
I'm pretty sure my installation is correct because this worked
until 2005-03-15, the system header files are all there and I
On Sat, Mar 26, 2005 at 12:00:43PM -0500, Kazu Hirata wrote:
> Have you considered merging CCP and VRP (as suggested by Kenny last
> year at the summit)?
>
By merging, do you mean *replacing* CCP with VRP? Yes, it's
doable. No, it's not a good idea.
Because of its lattice evaluation, VRP is ab
On Sun, Mar 27, 2005 at 08:08:43PM -0500, Kazu Hirata wrote:
> Also, if we are inserting ASSERT_EXPRs, it seems to be a good idea to
> run copy-prop before VRP. Otherwise, we would end up with lots of
>
There is a copy-propagation pass before VRP. Or do you mean
right before? Sure, the orderin
On Wed, Mar 23, 2005 at 05:35:42PM +0100, Biagio Lucini wrote:
> The gomp branch fails to bootstrap for libtool problems in libgomp.
> Verified on x86_64-unknown-linux-gnu and on i686-unknown-linux-gnu.
>
> It appears that the fix is pretty easy: libgomp/configure (and related files)
> need to b
On Mon, Mar 28, 2005 at 04:08:49PM +0200, Steven Bosscher wrote:
> On Mar 28, 2005 03:08 AM, Kazu Hirata <[EMAIL PROTECTED]> wrote:
> > Huh, whey I talked to them on IRC they didn't seem to have implemented
> > this. I'll try to get this issue one of these days.
>
> Ehm. I did in fact implement
On Wed, Mar 30, 2005 at 10:58:39AM -0700, Jeffrey A Law wrote:
> Whatever scheme we use to explicitly expose context sensitive
> equivalences in the IL needs to be a pure expression.
>
Well, that's the fundamental mechanism behind ASSERT_EXPRs and
VRP. Remember more details about the problem?
On Thu, Mar 31, 2005 at 05:46:40PM -0500, Kaveh R. Ghazi wrote:
> And what is the place of fold_builtin_1() given we have
> ccp_fold_builtin() ?
>
> Would someone please enlighten me?
>
ccp_fold_builtin was mostly an attempt to enhance CCP so that we
could propagate constant string attributes fr
On Fri, Apr 01, 2005 at 11:24:06AM -0800, Mark Mitchell wrote:
> Dale Johannesen wrote:
>
> >So I guess question 1 is, Mark, do you feel negatively enough about this
> >feature to block its acceptance in mainline?
>
> I'm not sure that I *could* block it, but, no, I don't feel that negatively.
>
On Mon, Apr 04, 2005 at 07:21:43PM -0300, Alexandre Oliva wrote:
> Perhaps. But the fundamental problem is that we shouldn't be hashing
> on pointers, and tree-eh.c does just that for finally_tree and
> throw_stmt_table.
>
I've heard both versions: that hashing on pointers is no big
deal, and th
On Wed, Apr 06, 2005 at 01:56:48PM +0100, Andrew Haley wrote:
> Has anyone else seen this?
>
Yes. At first I thought it was my patch, but it only happens on
i686 and libjava was working fine the day before.
Diego.
On Thu, Apr 07, 2005 at 03:08:50PM -0700, James E Wilson wrote:
> Is it possible that something changed on Diego's machine? Such as a new
> binutils, or a new kernel, etc?
>
Yes. I rebooted the machine into a new kernel on 2005-03-31
(2.6.10-1.770_FC3). The slowdown coincided with the box bei
On Thu, Apr 07, 2005 at 05:57:06PM -0700, James E Wilson wrote:
> So I think this is a possibility only if the Ada library got suddenly
> bigger and slower to compile, and if you are including Ada in your
> builds.
>
No Ada. I only build default languages. Oh, well, we'll see
what the timings lo
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
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, 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
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 prob
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 Sat, Apr 09, 2005 at 04:27:52PM +0200, Christian Parpart wrote:
> I've reported a bug on gcc-help list, but nooone seem to be interested in.
>
Bugs ought to be reported at http://gcc.gnu.org/bugzilla.
Diego.
On Fri, Apr 08, 2005 at 10:52:02AM -0600, Jeffrey A Law wrote:
> When we vectorize the store we copy the virtual operands from the
> original statement to the new vectorized statement via this code:
>
> /* Copy the V_MAY_DEFS representing the aliasing of the original array
> element's defi
#x27;s your top-of-ChangeLog? Works for me up to
2005-04-11 Diego Novillo <[EMAIL PROTECTED]>
PR tree-optimization/20933
* tree-ssa-alias.c (compute_flow_insensitive_aliasing): Move
[ ... ]
Diego.
On Tue, Apr 12, 2005 at 07:30:56AM +0200, Gabriel Dos Reis wrote:
> This might be due to the bootstrapping compiler -- I was using a
> compiler built from yesterday tree to bootstrap
>
Oh, PR 20933. Yes, the fix you see there should allow you to use
4.1 as a stage0 compiler again. We were misco
I have been using this crutch for the last couple of days to be
able to get mainline to bootstrap with java enabled.
Index: varasm.c
===
RCS file: /cvs/gcc/gcc/gcc/varasm.c,v
retrieving revision 1.495
diff -u -3 -p -r1.495 varasm.c
--
My ppc64 tester started failing last night while trying to create
libstdc++ libraries with:
-
/home/cygnus/dnovillo/perf/sbox/gcc/local.ppc64/bld.torreja/./gcc/xgcc -shared-l
ibgcc -B/home/cygnus/dnovillo/perf/sbox/gcc/loc
Is anybody seeing this failure on ia64? ld segfaults trying to
create libgcj.so in mainline. This was working as of 2005-04-13:
-
/home/cygnus/dnovillo/perf/sbox/gcc/local.ia64/bld.tonic/./gcc/xgcc -shared-libg
cc -B/hom
On Thu, Apr 14, 2005 at 09:33:52AM -0400, Diego Novillo wrote:
> My ppc64 tester started failing last night while trying to create
> libstdc++ libraries with:
>
I forgot to mention. This is on mainline.
Diego.
On Thu, Apr 14, 2005 at 11:26:33AM -0500, Jon Grimm wrote:
> Diego Novillo wrote:
>
>
> >
> >I see no changes in libstdc++ since the previous run and nothing
> >in the C++ FE, so I'm not sure whether it may be something broken
> >in my box.
> >
>
On Thu, Apr 14, 2005 at 10:24:32AM -0700, Richard Henderson wrote:
> On Thu, Apr 14, 2005 at 09:39:37AM -0400, Diego Novillo wrote:
> > GNU ld version 2.14.90.0.4 20030523
>
> Worked for me with 2.15.94.
>
OK. Thanks.
Diego.
On Thu, Apr 14, 2005 at 12:20:05PM -0700, Mark Mitchell wrote:
> Would you report your as + ld version numbers? Again, I'm guessing that
> you have an assembler with COMDAT and a linker without, or a broken
> assembler.
>
binutils-2.15.92.0.2-5
$ ld --version
GNU ld version 2.15.92.0.2 200409
On Thu, Apr 14, 2005 at 05:40:04PM +0200, Jason Merrill wrote:
> But the memory model for the language must provide semantics that make it
> possible for threaded programs to be written. Currently, if you want to
> write a portable pthreads program you need to use a mutex around all uses
> of sha
On Thu, Apr 14, 2005 at 11:19:19PM +0200, Gabriel Dos Reis wrote:
> Diego Novillo <[EMAIL PROTECTED]> writes:
>
> [...]
>
> | Seems to me that if C++ is all of the sudden interested in
> | dictating memory semantics for threaded programs, it should also
> | provid
On Thu, Apr 14, 2005 at 01:29:53PM -0700, H. J. Lu wrote:
> You need at least
>
> http://sourceware.org/ml/binutils/2004-12/msg7.html
>
> for COMDAT. Otherwise, you will get what you saw and
>
> http://gcc.gnu.org/ml/gcc-patches/2005-04/msg01606.html
>
OK, thanks.
Diego.
On Thu, Apr 14, 2005 at 11:30:20PM +0200, Jason Merrill wrote:
> I shouldn't have used the term "sequential memory ordering." Nobody is
> suggesting that C++ should enforce sequential consistency between threads.
> But even in the weakest memory models...*especially* in the weakest memory
> model
On Fri, Apr 15, 2005 at 10:18:35AM -0600, Jeffrey A Law wrote:
> I went ahead and ran this through the usual bootstrap and regression
> test. Installed this morning...
>
Excellent. Thanks.
Diego.
On Sat, Apr 23, 2005 at 09:07:23AM +0200, Andreas Jaeger wrote:
> Current GCC CVS Mainline fails to bootstrap for me:
>
Odd, my x86_64 works just fine. Send me a .i file?
Thanks. Diego.
On Sun, Apr 24, 2005 at 05:58:36PM +0200, Andreas Jaeger wrote:
> I can still reproduce the problem and played around a bit. If I
> disable checking completely, I can bootstrap. So, perhaps I have one
> more checking option enabled than you have?
>
Perhaps, but the ICE is in the generic verify_
On Sun, Apr 24, 2005 at 07:35:43PM +0200, Andreas Jaeger wrote:
> I configure with:
>
> /cvs/gcc/configure --prefix=/opt/gcc/4.1-devel
> --enable-checking=misc,tree,gc,rtl,rtlflag,assert --enable-threads=posix
> --enable-clocale=gnu --enable-__cxa_atexit --enable-shared
> --enable-languages=c,
ncing
- of the passes. The branch is maintained by Diego Novillo.
- Patches and discussion related to the branch should be marked
- with the tag [tcb] in the subject line. The usual
- contribution and testing rules apply. Patches should be CC'd
- to Diego Novillo for final approval.
On Wed, Apr 27, 2005 at 10:36:08PM +0200, Steven Bosscher wrote:
> [*] Does anyone have an idea of how large GCC really is?
>
~1.8 MLOC.
Courtesy of David Wheeler's SLOCCount (testsuites excluded):
SLOCDirectory SLOC-by-Language (Sorted)
1179994 gcc ansic=745370,ada=395409,
On Fri, Apr 29, 2005 at 12:05:03PM -0400, Ian Lance Taylor wrote:
> The way to help this process along is to report bugs at
> http://gcc.gnu.org/bugzilla.
>
> In particular, if you provide a set of preprocessed .i files,
> from, say, sys, libc, or libcrypto, whichever seems worst, and
> open a gc
On Sun, Apr 24, 2005 at 07:35:43PM +0200, Andreas Jaeger wrote:
> I configure with:
>
> /cvs/gcc/configure --prefix=/opt/gcc/4.1-devel
> --enable-checking=misc,tree,gc,rtl,rtlflag,assert --enable-threads=posix
> --enable-clocale=gnu --enable-__cxa_atexit --enable-shared
> --enable-languages=c,
On Sun, May 01, 2005 at 02:16:27PM -0400, Friends wrote:
> Only when I compile with an optimization level of "O2" or "O3" does the
> program exit with a memory access error.
>
It may be a bug in GCC and it may also be a bug in your program
(some problems like aliasing bugs only are exposed at hi
On Sun, May 01, 2005 at 10:45:15PM +0530, Virender Kashyap wrote:
> Also what exactly happens in a = b + c (b,c local) ?
>
That statement is already in GIMPLE form, so it's not changed.
What you describe is how the conversion into gimple occurs, have
you found a problem with it? I'm not sure whe
I am tracking an ICE in VRP that triggers only in Ada. Given
this:
1 D.1480_32 = nam_30 - 30361;
2 if (D.1480_32 <= 1) goto ; else goto ;
3 :;
4 D.1480_94 = ASSERT_EXPR ;
5 goto ();
When visiting statemen #4, VRP tries to create the range [-INF, 1]
for name D
On Mon, May 02, 2005 at 09:46:59PM -0400, Richard Kenner wrote:
> You're not showing where this comes from, so it's hard to say. However
> D.1480 is created by the gimplifier, not the Ada front end. There could
> easily be a typing problem in the tree there (e.g., that of the subtraction),
> but
On Tue, May 03, 2005 at 05:57:12PM +0200, Nico Moser wrote:
> Where is the bla.c.t**.optimized file?
>
You didn't use -O. None of the optimizers run without it.
> What is the bla.c.t03.generic file? The same as the
>
That's the IL that all FEs generate while parsing. In some cases
.original a
I have started working on connecting Dmitry's OpenMP parser to
the middle-end so that we can start generating the basic runtime
calls, which Richard should be posting soon. With any luck, we
should have some basic functionality in a few weeks.
Initially, we will be outlining parallel sections int
On Tue, May 03, 2005 at 04:45:55PM -0400, Scott Robert Ladd wrote:
> If you have a suggestion for better benchmarks, I'm listening. Is your
> ray tracer available?
>
I recently heard of Openbench, a project to create an open
version of the SPEC benchmarks http://www.exactcode.de/oss/openbench/
ISTR a link from GCC's home page into http://gcc.gnu.org/benchmarks/
but it doesn't seem to be there anymore. Shouldn't it be on the
index on the left at least?
Thanks. Diego.
On Tue, May 03, 2005 at 11:05:05PM +0200, Lars Segerlund wrote:
> I will try to look it over, right now I am very busy, and I
> don't know when I can get back. I have to remarks so far, the
> first is that we have to extend the gfortran internal
> representation also, and the second is tha
On Tue, May 03, 2005 at 02:16:35PM -0700, Richard Henderson wrote:
> On Tue, May 03, 2005 at 04:42:47PM -0400, Diego Novillo wrote:
> > GENERIC
> > GIMPLE
> > GOMP_ATOMIC
>
> Do we gain anything over expanding this to the approprate __sync_foo
> builtin
On Tue, May 03, 2005 at 08:23:59PM -0400, Ian Lance Taylor wrote:
> Diego Novillo <[EMAIL PROTECTED]> writes:
>
> > GENERIC
> > GOMP_PARALLEL
> >
> > GIMPLE
> > GOMP_PARALLEL
> > L1:
> > g_body
> > L2:
>
On Tue, May 03, 2005 at 03:59:24PM -0700, Richard Henderson wrote:
> Sure, in the same way we know what "strlen" is.
>
Excellent. I'll get rid of them then.
> > That's what I thought at first, but the standard threw me into a
> > loop when it mentioned "id-expression" instead of just
> > "ident
On Wed, May 04, 2005 at 12:48:27AM +0200, Gerald Pfeifer wrote:
> You mean, like the following? Good idea.
>
> Installed.
>
Cool. Thanks.
Diego.
On Tue, May 03, 2005 at 06:21:11PM -0400, Richard Kenner wrote:
> As of right now, I don't think this is a VRP problem, but something wrong
> with the tree Ada produces.
>
That'd be good. If that's the case, we can make VRP assert that
the range derived from such types agrees with the type's ran
On Tue, May 03, 2005 at 08:48:20PM -0400, Ian Lance Taylor wrote:
> If I understand what you are saying, I am complaining about the
> specific cases where the difference is in the syntax.
>
Drat, trapped in my own web of logic and definitions ;) Yes,
that's exactly what I was saying and now I see
On Wed, May 04, 2005 at 12:15:18PM +, Biagio Lucini wrote:
> Also, talking about IR, since OpenMP is mostly unique, probably
> we just need to link the gfortran parser to the work in the
> middle-end that is currently being done, with perhaps a few
> (hopefully no) exception.
>
Yes, the FEs e
On Wed, May 04, 2005 at 11:59:49AM -0600, Chris Friesen wrote:
> Without the locks, the compiler is free to only load *b once (and in
> fact gcc does so). Is the addition of the locks sufficient to force *b
> to be re-read each time, or do I need to declare it as
>
As long as you keep 'b' poin
On Wed, May 04, 2005 at 01:47:20PM -0600, Chris Friesen wrote:
> Also, what about threads and pthread locking? Do I need to use volatile
> there? If not, then what about using pthread locking between processes?
>
Same reply I gave you before. As long as the address of your
shared memory is ou
On Wed, May 04, 2005 at 04:15:41PM -0400, Diego Novillo wrote:
> Same reply I gave you before. As long as the address of your
> shared memory is outside of the function and the pointer is
> itself a global variable or gets its value from the heap, then
> calls to functions that canno
On Wed, May 04, 2005 at 02:47:14PM -0600, Chris Friesen wrote:
> In multiple messages to comp.programming.threads he has stated that
> volatile is not necessary between threads if you use the posix locking
> functions, and in fact that one of the main purposes of the posix locks
> is to ensure
On Wed, May 04, 2005 at 05:08:23PM -0700, James E Wilson wrote:
> We can perhaps handle this well in the tree-aliasing code (if
> it handled restrict at all), but it would be difficult to
> handle this well in the RTL aliasing code.
>
It doesn't. Mostly for similar reasons.
Perhaps we could be m
On Thu, May 05, 2005 at 12:19:07PM -0400, Daniel Berlin wrote:
> On Wed, 2005-05-04 at 22:40 -0700, Mark Mitchell wrote:
> > GCC 4.1 is going rather well thus far.
> >
> > Technically, Stage 1 ended on April 25th, though I failed to announce
> > that. There are a few stage 1 tasks that have not
On Fri, Apr 22, 2005 at 02:56:30PM -0700, Steve Kargl wrote:
> Appears that any nested loops are doomed with -O2 with gfortran.
> This is a critical important problem, because almost every
> Fortran program that I know contains nested loops.
>
Is this fixed now? This works for me.
Diego.
Wouldn't it make sense for operand_equal_p to start with:
int
operand_equal_p (tree arg0, tree arg1, unsigned int flags)
{
if (arg0 == arg1 && !TREE_SIDE_EFFECTS (arg0))
return 1;
...
}
Am I missing something here?
Thanks. Diego.
On Thu, May 12, 2005 at 05:33:05PM -0700, H. J. Lu wrote:
> I got the same comparsion failure.
>
Have you tried with Zdenek's patch to LSM that I approved earlier today?
http://gcc.gnu.org/ml/gcc-patches/2005-05/msg01150.html
Diego.
On Wed, May 18, 2005 at 05:31:29PM -0700, Richard Henderson wrote:
> After three days of sequential bootstrap breakage, I'd like to propose
> that mainline go into slush, wherein all these bootstrap problems, and
> all the new testsuites failures get fixed. No other patches would be
> allowed at
On Thu, May 19, 2005 at 04:42:29PM +0200, Davide Pozza wrote:
> Calling the get_def_operand for this statement with index 0, the
> function has to return the tree corresponding to buf_13.
>
If the argument you are looking for is not call-clobbered (not in
the call_clobbered_vars set) you can retu
I updated my local tree today and now every time I 'make
restage1', fixincludes are run again. Is this a bug, or do we
need to run fixincludes all the time?
To reproduce:
$ configure && make restage1
$
$ make restage1
Diego.
On Mon, May 23, 2005 at 01:15:17AM -0500, Gabriel Dos Reis wrote:
> So, if various components maintainers (e.g. C and C++, middle-end,
> ports, etc.) are willing to help quickly reviewing patches we can
> have this done for this week (assuming mainline is unslushed soon).
> And, of course, everyb
from a
> few weeks ago since I claimed that it was an Ada front-end bug and not
> a VRP bug. Unfortunately, I got distracted and then was away. I will make
> a real attempt to look at it in the next few days.
>
The VRP bug you remember is already worked around by
2005-05-02
On Wed, May 25, 2005 at 03:37:29PM -0600, Jeffrey A Law wrote:
> So, if I wanted to be able to bootstrap Ada, what I do I need
> to do? Disable VRP?
>
Applying the patches in the PRs I mentioned. If that doesn't
work, try with VRP disabled.
Diego.
This is happening in gcc.dg/tree-ssa/20040121-1.c. The test
specifically tests that (p!=0) + (q!=0) should be computed as
int:
char *foo(char *p, char *q) {
int x = (p !=0) + (q != 0);
...
}
During VRP, we get this IL
D.1294_10 = first_8 != 0B;
D.1295_11 = last_9 != 0B;
x_12 = D.1
On Fri, May 27, 2005 at 02:23:02PM -0400, Ian Lance Taylor wrote:
> The program is legal C. The _Bool values should be promoted to int
> before doing the addition.
>
OK, thanks.
> I guess that type cast is being lost somewhere.
>
It doesn't seem to be ever emitted. There are no casts in
.origi
On Fri, May 27, 2005 at 02:32:46PM -0400, Andrew Pinski wrote:
> >
> > This is happening in gcc.dg/tree-ssa/20040121-1.c. The test
> > specifically tests that (p!=0) + (q!=0) should be computed as
> > int:
> >
> > char *foo(char *p, char *q) {
> > int x = (p !=0) + (q != 0);
> > ...
> >
On Fri, May 27, 2005 at 02:45:14PM -0400, Andrew Pinski wrote:
> Are you sure, the NE_EXPR does not have a type of INTEGER_TYPE?
> This sounds like a missing fold_convert somewhere.
>
Ah, yes. I see what you mean now. The comparison was of type
int but the evaluation was generating a _Bool valu
On Sat, May 28, 2005 at 01:02:49AM -0400, Paul Schlie wrote:
> Especially for the purpose of VRP, why wouldn't it be most ideally
> appropriate to define the result of a comparison to be a _Bool, as it's
>
Read my original message. (_Bool)1 + (_Bool)1 is folded to 0. I
needed it to be folded to
101 - 200 of 1389 matches
Mail list logo
