erflow has been undefined since
before the C standard was finialized and in fact there is a nice
paper/book called "C Traps and Pitfalls[2]" which mentions all of this
back in 1988.
Thanks,
Andrew Pinski
[1] http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1021.pdf
[2] http://www.literat
is why I am agrueing against even changing VRP, as it
punishes people who don't depend on overflow being wrapping. Ian's
change in fact punishes people's code who does not depend on that
as it is causes compile time slow down (and an increase of memory usage
inside GCC itself) which people will complain about.
Thanks,
Andrew Pinski
commending
-fwrapv for those people who depend on signed overflow is wrong.
Thanks,
Andrew Pinski
ng Committee.
Can you wait 24 hours after all of the inliner fixes which honza are going
to commit have been committed?
This is so we don't get failures on top of other failures.
Thanks,
Andrew Pinski
>
> > We should also be very careful not to introduce differences between
> > native and cross compilers. So, we should have no run-time tests, no
> > tests that look at /proc, headers in /usr/include, etc.
>
> Right--I was really only suggesting tests that can be done at
> compile-time. Perhap
>
>
> Hello All,
>
> I cannot figure out how to have a vector of strings in a GTY-ed file
>
> As a simple example, if I add (inside trunk rev.101317) at the end of
> gcc/stringpool.c just before the last #include "gt-stringpool.h"
>
> typedef char* basilestring_t;
> DEF_VEC_P (basilestrin
First sorry about the first email.
> As a simple example, if I add (inside trunk rev.101317) at the end of
> gcc/stringpool.c just before the last #include "gt-stringpool.h"
>
> typedef char* basilestring_t;
> DEF_VEC_P (basilestring_t);
> DEF_VEC_ALLOC_P (basilestring_t,heap);
> static VE
e appropriate for gcc-help@ rather than [EMAIL PROTECTED]
Thanks,
Andrew Pinski
do is when a problem was fixed in 4.1.2 and
4.0.4 I try to keep the "know to work/fail" fields correctly so that we
know that it was fixed in 4.1.2 but failed in 4.1.1. This also allows
us and others to keep track of what was fixed when.
Thanks,
Andrew Pinski
nyways but division is the one that is
different between flag_complex_method==0 and flag_complex_method==1.
Thanks,
Andrew Pinski
>
>
>
> Yes I see now... a quite complicated way to express the choice logic:
>
> 1. if -fcx-limited-range is set go straight for the quick overflowing
> version.
> 2. be strict in case of ISO C99.
> 3. handle floaing poing divisions more precisely then multiplications
> else.
if you look
How about waiting ten days, say, see whether anyone has substantial
> objections, and proceed as noted above? (We are usually operating
> on Internet time, but giving people more than a week is fair, I think.)
I am willing to be the release manager for 4.0.4 if nobody else
steps up to the base for this.
Thanks,
Andrew Pinski
>
> Joe Buck <[EMAIL PROTECTED]> writes:
>
> | On Fri, Jan 05, 2007 at 07:26:27AM -0800, Ian Lance Taylor wrote:
> | > David Edelsohn <[EMAIL PROTECTED]> writes:
> | >
> | > > Are 4.0 snapshots still necessary? I suspect they should be
> | > > discontinued.
> | >
> | > 4.0 still seems
I wonder why the
> bootstrap doesn't fail on all targets?
This only fixes on of the problems, the other one is
function_and_variable_visibility needs to return unsigned int and 0.
This fixes an ICE building libgcc for spu-elf on powerpc-linux-gnu.
Thanks,
Andrew Pinski
with operator new?
In that if I a C++ developer provides a seperate operator new (and
delete), does libstdc++ use that one as required by the C++ standard?
Thanks,
Andrew Pinski
>
> Sergei Organov wrote:
> > Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> >
> >> Sergei Organov <[EMAIL PROTECTED]> writes:
> >>
> >>
> >>> Below are two example functions foo() and boo(), that I think both are
> >>> valid from the POV of strict aliasing rules. GCC 4.2 either warns abou
>
> Hi,
>
> Will g++ ever add a compile time enforcement of the exception
> specification like the Java compiler does?
>
> I find the exception specification almost useless with out this
> functionality.
The C++ standard ( 15.4/10) is very specific that the implemantion should not
reject code
>
> Vincent Lefevre <[EMAIL PROTECTED]> writes:
>
> | On 2007-01-16 13:41:16 -0800, Ian Lance Taylor wrote:
> | > To be clear, in my opinion, this should always be selected by an
> | > option, it should never be default behaviour for any target.
> |
> | I disagree. One should get correct results
ent
boundary (the page boundary) and that would then call the unaligned
exception handler and that is rarer).
Who really need to start getting the PS3 game OS to do an unaligned
exception handler that works instead of hanging.
Thanks,
Andrew Pinski
>
> Andrew Pinski wrote:
> I have no idea how your reply is related to my question about the
> change in alignment of char arrays between gcc-3.4 and gcc-4.1.
It was not really a rely to that part of the question but rather the
assertion in general that unaligned access was slower
>
> One use of -Wconversion is to draw attention to
>
>int x = 2.3; // warning: be careful, is this what you want?
> // this is a potential bug as it is value altering.
>
> and in an upcoming revision to C++, it is very likely that implicit
> conversion that may lose info
>
> Mike Stump <[EMAIL PROTECTED]> writes:
>
> > Here is an innovative new build failure, as seen on i686-apple-darwin9:
> >
> > ../../gcc/gcc/expmed.c:4179: warning: signed and unsigned type in
> > conditional expression
> > make[3]: *** [expmed.o] Error 1
> > make[2]: *** [all-stage2-gcc] Erro
On Sun, 2007-01-21 at 01:49 -0500, Richard Stallman wrote:
> It would be nice to have such a construct in GNU C, something that
> could be used in a macro expansion, and would turn off _all_ warnings
> for the code within the construct.
http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html
Bu
>
>
> Wiadomo¶æ napisana w dniu 2007-01-24, o godz02:30, przez David Carlton:
>
> > For 4, you should probably spend some time figuring out why bugs are
> > being introduced into the code in the first place. Is test coverage
> > not good enough?
The test coverage is not good for C++ while it i
tage1 and then again at the end of stage2.
This will get the time down for reporting of major bugs. We will still end
up with the problem that all code is ran through so we get bug reports after
the .1 release that now block the next .0 release from happening.
Sorry about the length of this email.
Thanks,
Andrew Pinski
On Tue, 2007-01-23 at 23:19 -0600, [EMAIL PROTECTED] wrote:
> GCC should treat plain char in the same fashion on all types of machines
> (by default).
No, no, no. It is up to the ABI what char is.
> The ISO C standard leaves it up to the implementation whether a char
> declared plain char is sig
>
> On Wed, 24 Jan 2007 03:02:19 +0100, Marcin Dalecki <[EMAIL PROTECTED]> said:
>
> That's largely because individual tests in the test suite are too
> long, which in turn is because the tests are testing code at a
> per-binary granularity: you have to run all of gcc, or all of one
> of the prog
>
> On FC6 x86_64-pc-linux-gnu with the svn trunk r121257 configured like this:
>
> ../trunk/configure --with-gmp=/usr/local --with-mpfr=/usr/local
> --disable-multilib --enable-languages=c,c++,java
>
> I am seeing this failure when bootstrapping. It worked for me last week:
>
> /home/daney
On Sun, 2007-01-28 at 15:41 -0800, Ray Hurst wrote:
> Shouldn't the compiler error out here.
> The statement: p = "" should have been p = '\0';
> Or does the compiler treat them as equivalent.
>
> It seems that only characters should be assigned to char's and strings
> are illegal
Read about the
>
> This is a multi-part message in MIME format.
> --050002020005030600040801
> Content-Type: text/plain; charset=ISO-8859-1; format=flowed
> Content-Transfer-Encoding: 7bit
>
>
> >> You know (or so I assume) this was a very Very VERY BAD thing to do
> >
> > are not helpful. Of cou
>
> On Wed, 31 Jan 2007, Andrew Haley wrote:
> > Can you tell us a bit more about the config? It really shouldn't be
> > failing to compile this program.
>
> The tester where this problem first surfaced as a 32-bit Athlon machine,
> with 512MB main memory and 1GB swap. The machine runs FreeBSD
>
> Hi Rask,
>
> Basically the CPU has the 'SCALE_28_4' instruction which does the following:
> output = (operand1 >> 28) | (operand2 << 4)
Isn't that a rotate? if so you can use either rotate or rotatert instead.
Thanks,
Andrew Pinski
>
> In http://gcc.gnu.org/gcc-4.3/changes.html appears
>
> "Support for SSSE3 built-in functions and code generation are available
> via |-mssse3|."
>
> Is it SSE3 (i686 SIMD) or SSSE3 (strange, unknown)?
> Is it -mssse3 or -msse3?
-mssse3 is S-SSE3 which was added for code dual 2.
Yes the opt
>
> Andrew Pinski wrote:
> >> In http://gcc.gnu.org/gcc-4.3/changes.html appears
> >>
> >> "Support for SSSE3 built-in functions and code generation are available
> >> via |-mssse3|."
> >>
> >> Is it SSE3 (i686 SIMD) or SSSE3
>
>
> Hello,
>
> We saw that the reassociation pass does not operate on built-in functions,
> for example:
>
> vp3 = vec_madd (vp1, vp2, vp3);
One thing which could be done is expand the builtins into tree code
instead of keeping around a builtin function.
This might also help other cases too
>
>
> > > That said, I think it would not be bad to put 4.3 in stage3 mode until
> > > dataflow branch is ready and, at that point, rebranch 4.2 and soon
> > > after that merge dataflow branch.
>
> FWIW I agree with Vlad and Paolo Bonzini.
>
> It seems as if 4.2 was branched with critical flaws
nciple?
I think this is a great extension as someone was requesting the same thing
here too.
Thanks,
Andrew Pinski
<http://gcc.gnu.org/ml/gcc/2001-01/msg01775.html and
http://gcc.gnu.org/ml/gcc/2001-01/msg01777.html>
And I thought this was really part of our coding style too but I
cannot find it on http://gcc.gnu.org/codingconventions.html .
Thanks,
Andrew Pinski
header with WIFEXITED, WEXITSTATUS, etc.
See http://sourceware.org/bugzilla/show_bug.cgi?id=1392 .
Thanks,
Andrew Pinski
On 2/28/07, Mohamed Shafi <[EMAIL PROTECTED]> wrote:
Is there anyway to do this?
Yes look at config/rs6000/rs6000.h and ASM_CPU_SPEC and EXTRA_SPECS
and ASM_SPEC.
Thanks,
Andrew Pinski
we were not as good but now we
have corrected those mistakes.
Thanks,
Andrew Pinski
On 3/1/07, Mike Stump <[EMAIL PROTECTED]> wrote:
On Mar 1, 2007, at 3:28 PM, Andrew Pinski wrote:
> Also I think GCC is doing the correct thing right now with respect of
> approving patches. Yes in the past we were not as good but now we
> have corrected those mistakes.
So, are
On 3/1/07, Mike Stump <[EMAIL PROTECTED]> wrote:
I don't see why:
http://gcc.gnu.org/ml/gcc-patches/2006-02/msg02031.html
was a bad thing. i think gcc would have been better if it had just
been committed.
(or the target removed)
It is not, just nobody cares about that target any more, we hav
" by "div" and validation will succeed.
As far as I can tell this is correct in the cvs holding the html.
Plus http://gcc.gnu.org/ valids as valid XHTML 1.0 Transitional. So
something in the conversion method that www.gnu.org does to the web
pages break the validation.
Thanks,
Andrew Pinski
t) or can it be a complex expression?
Thanks,
Andrew Pinski
t so
that failing is known. You might want to try adding
-fno-strict-aliasing.
I have been asking someone who has the power to submit an alt to SPEC
for that failure for 3 years now and now it is too late really.
Thanks,
Andrew Pinski
has an issue too but IV-OPTs dump gives:
D.1604_5 = MEM[base: (double *) &a, index: ivtmp.34_12];
MEM[base: (double *) &c, index: ivtmp.34_12] = D.1604_5;
the expression matching in final_cleanup was just a symptom of the issue.
Thanks,
Andrew Pinski
o be edges, you would have something like 100 basic
blocks for a simple function which is too excusive.
Thanks,
Andrew Pinski
On 3/4/07, Vladimir N. Makarov <[EMAIL PROTECTED]> wrote:
Another important thing to do is to make the 1st scheduler register
pressure sensitive.
I don't know how many times this has to be said, no this is not the
correct approach to fix that issue. The correct fix is able for the
register all
still with this change?
<http://gcc.gnu.org/ml/gcc/2007-03/msg00120.html> for the reference of
the regressions.
Thanks,
Andrew Pinski
On 05 Mar 2007 12:24:18 -0800, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
"Andrew Pinski" <[EMAIL PROTECTED]> writes:
If Mark agrees with you, then I'm unfortunately going to have to lobby
to disable VRP by default in 4.2.
Then it should also be disabled by defau
On 3/8/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Another convenient way of allocating a pool of memory is to use obstacks
(See libiberty/obstack.c).
Though alloc-pool might be a better idea than obstack, see
alloc-pool.[ch]. As alloc-pool contains checking code while obstack
does not.
-- P
limit.
This is recorded as PR 31134.
Thanks,
Andrew Pinski
On 3/11/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
Unfortunately, my ISP has apparently picked today to make DNS not
work. So, I'm having a hard time getting around the internet.
Sounds like the DST bug :).
-- Pinski
ources for this patch is
on a computer at home which does not have internet access right now.
IIRC I ran into another bug while fixing this one.
Also this is not a aliasing crash.
Thanks,
Andrew Pinski
On 3/12/07, Paolo Carlini <[EMAIL PROTECTED]> wrote:
Hi,
just wanted to say explicitely that I'm supporting completely Doug'
efforts at fixing this issue. Well, I'm a little biased, because I'm
working on C++/26099 and I will need at least one new tree code, but
that's not the point, the point i
On 3/12/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
On 3/12/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
> Can I recommend something just crazy, rewrite the C and C++ front-ends
> so they don't use the tree structure at all except when lowering until
> gimple like
On 3/13/07, Andrew Walrond <[EMAIL PROTECTED]> wrote:
Doesn't seem to work on xemacs :(
xemacs != emacs
Anyways I was going to say:
Don't
But now we are getting into emacs vs vi vs xemacs which is getting offtopic.
-- Pinski
On 3/13/07, Paulo J. Matos <[EMAIL PROTECTED]> wrote:
Which C type is HOST_WIDE_INT?
It can either be long, or long long depending on if the target needs
it to be 64bits and what size of long on the host.
Isn't the type of the constant always integer_type?
No, it can be POINTER_TYPE, ENUME
On 3/13/07, Mark Mitchell <[EMAIL PROTECTED]> wrote:
My attempt to build GCC 4.2.0 RC1 failed with:
cp doc/gcc.1 doc/g++.1
cp: cannot stat `doc/gcc.1': No such file or directory
This is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30899 yes, yes I
have bugzilla memorized.
-- Pinski
On 3/13/07, Kazu Hirata <[EMAIL PROTECTED]> wrote:
Hi Janis,
While PR 28834 stays open, I'm thinking about XFAILing
gcc.c-torture/execute/mayalias-2.c when it is run with -O3 -g.
However, I am not having any luck with writing mayalias-2.x. I am
wondering if you could help me with XFAIL.
There
On 3/13/07, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
On Tue, 13 Mar 2007, Andrew Pinski wrote:
It's true that in development we may not want to XFAIL them - but it's
also true that this FAIL is on 4.2 branch and 4.2.0 is likely to be
released with it. And users installi
On 3/14/07, Tristan Gingold <[EMAIL PROTECTED]> wrote:
Hi,
in some cases, a breakpoint can't be set on a continue or break
statement. Here is a simple example:
I think this is also related to
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29609
Yes, yes I have the whole bugzilla memorized. :)
we do for the Cell also, we expect people to compile
using two different compilers right now, but we are actually looking
into doing an "one source" based compiling where some functions or
loops are pushed off to the SPUs via annotations like the OpenMP ones.
Thanks,
Andrew Pinski
l, this is already filed as PR 22076 and others.
There was a patch posted as an RFC to fix this but it caused
regression on x86_64 and the person who submitted has not updated it
yet for the mainline.
Thanks,
Andrew Pinski
On 3/16/07, Steve Ellcey <[EMAIL PROTECTED]> wrote:
My thinking is that if libobjc was changed then we could put in a
depreciated message on these builtins for 4.3 and maybe remove them for
4.4.
libobjc has not changed yet. There was a patch a while back to change
libobjc to use libffi but I n
On 3/16/07, Steven Bosscher <[EMAIL PROTECTED]> wrote:
Do you mean this patch:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00841.html
Yes, thanks for finding the patch.
I will look over it this weekend and apply it if it is good.
-- Pinski
On 3/17/07, Andrew Haley <[EMAIL PROTECTED]> wrote:
Are there any performance issues to consider? Is using libffi
slower/faster than the builtins?
It is most likely slower but these APIs in libobjc are not used as
much as the other ones, plus GNUStep already uses libffi as the
forwarding mech
: ld terminated with signal 11 [Segmentation fault]
> make[8]: *** [libstdc++.la] Error 1
Usually that means there is a bug in binutil's ld. It might be better
to use a real FSF stable release of binutils instead of what the
vendor (distro) provides you with.
Thanks,
Andrew Pinski
On 3/18/07, Florian Weimer <[EMAIL PROTECTED]> wrote:
I'll try, but I doubt it. According to the installation
documentation, amd64 is not a multilib target.
HUH??? Which documentation? x86_64 for GCC is a multilib target and
has been since day 1 IIRC.
-- Pinski
the actual pointer and which is the integer that has been
added to it.
Is there another way to find out which is which?
Not right now, I have been working on a new representation of pointer
arithmetic for the tree level. The basic implementation is already
done, see the pointer_plus branch.
Tha
y kind of heuristic tuning is needed.
Thanks,
Andrew Pinski
On 3/19/07, Joe Buck <[EMAIL PROTECTED]> wrote:
This brings up a point: the build procedure doesn't work by default on
Debian-like amd64 distros, because they lack 32-bit support (which is
present on Red Hat/Fedora/SuSE/etc distros). Ideally this would be
detected when configuring.
Actually it
On 3/19/07, Doug Gregor <[EMAIL PROTECTED]> wrote:
On 19 Mar 2007 19:12:35 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
> similar justifications for yet another small% of slowdown have been
> given routinely for over 5 years now. small% build up; and when they
> build up, they don't not to
used by my patch to
make constant vector constructors invariant.
Thanks,
Andrew Pinski
On 3/24/07, Brian Dessent <[EMAIL PROTECTED]> wrote:
Dave Korn wrote:
> # 405 "/usr/include/stdio.h" 3 4
[ Which is from newlib (libc/include/stdio.h) if anyone reading this
doesn't have a Cygwin system handy. ]
> static __inline__ int __sgetc_r(struct _reent *__ptr, FILE *__p)
> {
> [...]
>
On 3/25/07, Ryan Hill <[EMAIL PROTECTED]> wrote:
I couldn't find one so I've filed PR #31359. Apologies if it's a duplicate.
I will again say, "undocumented extensions" don't exist (except for
the case where the documentation is in the source and this was not one
of those cases). This was jus
od idea. RTL
is not going away, and in fact GCC's model having two IR is not unique
to GCC, XLC uses that model also.
Thanks,
Andrew Pinski
On 3/26/07, Mayank Kumar <[EMAIL PROTECTED]> wrote:
In gcc packages, I could not find ld.so and libdl.so
Binutils only contains ld.
Where can I find the gnu source code for libdl.so and ld.so
They come from glibc which I doubt MS uses as they have their own
shared library (dll) loader and libc
On 27 Mar 2007 21:11:56 -0500, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote:
| In C, a pedwarn is a warning by default, an error with -pedantic-errors.
|
| In C++, a pedwarn is an error by default, a warning with -fpermissive.
You're describing a defect, not the intended semantics.
In C, a pedwar
ons
without locations but that is a bug (I cannot find the PR right now
but Daniel J. filed it).
Thanks,
Andrew Pinski
ion by zero and the
hardware does not trap either.
Thanks,
Andrew Pinski
On 4/1/07, David Daney <[EMAIL PROTECTED]> wrote:
The issue is that for some things (the java front-end) we need the
trapping behavior. I just want to optimize it if the divisor is known
to be non-zero. VRP knows, but by the time we generate the code it
seems that we have forgotten.
The java
On 4/2/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
Many x86 SSE source codes use __declspec. I'd like to make
__declspec available for Linux/x86. We can do one of the
following:
Do the following in the sources:
#ifndef __WIN32__
#define __declspec(x)
#endif
or in the makefiles:
Add "-D__declspec(x
On 4/2/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
It won't work with
__declspec(align(16)) double x [4];
And the code should be converted over to use GCC style attributes.
So really the code should be something like:
#ifndef __WIN32__
#define __align16 __attribute__((align(16) ))
#else
#define
On 4/2/07, Mike Stump <[EMAIL PROTECTED]> wrote:
I suspect I'd want this for x86 darwin as well.
Why emulate Windows compilers on non windows machine? That is wrong.
GCC for Linux/Darwin/any other OS besides Windows is not a Windows
compiler and should not act like one. If people want to por
On 4/2/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
Why emulate Windows compilers on non windows machine? That is wrong.
GCC for Linux/Darwin/any other OS besides Windows is not a Windows
compiler and should not act like one. If people want to port their
code, they should write their c
On 4/2/07, Toon Moene <[EMAIL PROTECTED]> wrote:
Ah ! A clear case of "all the world's a RISC" syndrome.
Actually I think it is a case of CSE/frowprop not doing the correct
thing for the addressing modes. So it might be the real problem is
the back-end's addressing mode cost are incorrect or
On 4/2/07, Joe Buck <[EMAIL PROTECTED]> wrote:
If the Windows version of GCC has to recognize __declspec to function
as a hosted compiler on Windows, then the work already needs to be done
to implement it. So what's the harm in allowing it on other platforms?
If it makes it easier for Windows pr
On 4/2/07, H. J. Lu <[EMAIL PROTECTED]> wrote:
I believe __declspec in Intel C++ compiler comes from:
http://msdn2.microsoft.com/en-us/library/dabb5z75.aspx
How is Microsoft documentation, the real documentation for Intel C++
compiler? Have you seen the Cell language extension document [1]?
you. Maybe
I don't see the benifit in always changing our IR without really
thinking about the problem and seeing if there are already tools
(functions) which do the same thing in a common place.
Thanks,
Andrew Pinski
On 4/6/07, Karl Chen <[EMAIL PROTECTED]> wrote:
Regarding negatives, I believe 'operator new' takes a size_t,
which is unsigned, but if it were signed it, the multiplication
would indeed be in danger of creating a negative.
Actually if it was signed, the whole result would be undefined if
there
On 4/7/07, Dave Korn <[EMAIL PROTECTED]> wrote:
No, looks like an oversight; there are no permission bits listed on my user
prefs. I logged out and logged back in to get a fresh cookie, still no
difference.
Including your @gcc.gnu.org account?
-- Pinski
On 4/8/07, Bradley Lucier <[EMAIL PROTECTED]> wrote:
Is this just a rumor, or are there data that backs this up. (That -
fwrapv doesn't work, not that Dewar was always told that it doesn't
work.)
If you look into the bugzilla, you will see now two bugs filed against
-ftrapv. One because the r
On 4/9/07, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
#include
void *__allocate_array_OptionA(size_t num, size_t size) { // 1st best
unsigned long long tmp = (unsigned long long)size * num;
if (tmp >= 0x8000ULL) tmp=~size_t(0);
return operator new[](tmp);
}
First this just h
On 4/9/07, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
3. To modify the C-preprocessor and/or C/C++ compiler for:
#if argument X is a constant then
use this code specific of constant X
#else if argument Y is not a constant then
use this code specific of non-c
On 4/9/07, J.C. Pizarro <[EMAIL PROTECTED]> wrote:
Of course, i'm a novice because i like and i don't like the
GCC development's model.
Of course the user manual explains all what I have mentioned in my
previous email so it sounds like you like 95% of the other people who
don't read the manual
On 4/9/07, Diego Novillo <[EMAIL PROTECTED]> wrote:
Following up on the recent discussion about GIMPLE tuples
(http://gcc.gnu.org/ml/gcc/2007-03/msg01126.html), we have summarized
our main ideas and implementation proposal in the attached document.
This should be enough to get the implementatio
On 4/9/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
Also I noticed in your pdf, you have "PHI NODE" as 12%, we can improve
the memory usage for this statement by removing the usage of
TREE_CHAIN/TREE_TYPE, so we can save 4/8 bytes for those 12% without
doing much work. I can sen
On 4/10/07, Andrew Pinski <[EMAIL PROTECTED]> wrote:
Here is the quick patch (thanks to the work done for gimple tuple)
which does this, removes the unneeded type from phi nodes. I have not
tested it except for a quick test on some small testcases so there
might be more places whi
101 - 200 of 1802 matches
Mail list logo
