On Thursday 25 August 2005 07:12, Christoph Hellwig wrote:
> > On systems with small command-line buffers, this is a must-have
> > feature.
>
> Do you really want every application to work around a broken propritary
> system?
GCC supports many proprietary systems and non-GNU systems, even
though t
Hi,
We're supposed to be getting closer to a 4.1 release branch, but just
like in the past so-many releases we have succeeded again in slowing
down GCC, and we've slowed it down a _lot_ compared even to GCC 4.0.
Taking SPECint and CSiBE as examples:
http://www.suse.de/~aj/SPEC/amd64/CINT/sandbox-
On Tuesday 30 August 2005 01:26, Joe Buck wrote:
> On Tue, Aug 30, 2005 at 12:20:11AM +0200, Steven Bosscher wrote:
> > We're supposed to be getting closer to a 4.1 release branch, but just
> > like in the past so-many releases we have succeeded again in slowing
> > dow
On Tuesday 30 August 2005 01:56, Joe Buck wrote:
> OK. Do we have any consistent measurements for SPEC2000 on amd64
> for 4.0.x vs mainline?
Some incomplete data is in
http://people.redhat.com/dnovillo/spec2000.em64t/gcc/individual-build-secs_elapsed.html
Gr.
Steven
On Tuesday 30 August 2005 17:53, Peter Steinmetz wrote:
> While this doesn't explain all of the degradations discussed (some were
> showing up on older versions of the compiler), it may explain some.
There is a lot of empirical evidence that the loop optimizer already
doesn't do many useful things
On Thursday 01 September 2005 23:19, girish vaitheeswaran wrote:
> Sorry I still did not follow. This is what I
> understood. During Feedback optimization apart from
> the -fprofile-generate, one needs to turn on
> -fmove-loop-invariants.
You don't "need to". It just might help iff you are using
On Friday 02 September 2005 00:53, Janis Johnson wrote:
> Girish started this thread about problems he is seeing with GCC 3.4.3
> (see http://gcc.gnu.org/ml/gcc/2005-07/msg00866.html). Others of us
> chimed in about similar issues with later versions. Suggestions for
> avoiding the problems have
On Monday 05 September 2005 17:35, Peter S. Mazinger wrote:
> Hello!
>
> libssp subdir is present in cvs (checked on savannah) but cvs -q upd does
> not get it. Is it a cvs-server failure or something on my side?
cvs upd -d -P ?
Or better yet: contrib/gcc_update
Gr.
Steven
On Monday 05 September 2005 23:26, Richard Kenner wrote:
> I'm watching it deal with
>
> # small_1 = PHI <32(0), 1(1)>
>
> vrp_meet is called with [32, 32] and [1,1].
>
> It determines that the ranges don't intersect and then comes up with
> result?
I would hope VR_VARYING...?
Gr.
Steven
On Tuesday 06 September 2005 14:04, Richard Kenner wrote:
> On the
> other hand, we define "valid GENERIC" to be those trees that were generated
> by the compiler immediately before the tree-ssa conversion and trees of the
> above form were generated then. So they are valid GENERIC and ought to be
Hi,
Consider this little snippet:
int x;
int
foo (int a)
{
x = a;
return x + 3;
}
With -fno-tree-dominator-opts, we do not optimize away the load
from x in "x + 3". I would have expected store-copyprop to do
this, but
On Tuesday 06 September 2005 15:05, Gabriel Dos Reis wrote:
> Richard Guenther <[EMAIL PROTECTED]> writes:
> | On 9/6/05, Richard Kenner <[EMAIL PROTECTED]> wrote:
> | > I don't think we ever defined "valid GENERIC" that way.
> | >
> | > About a year ago, when we tried to define it, that's what
On Tuesday 06 September 2005 15:37, Richard Kenner wrote:
> What would be your proposal as to which nodes it's valid to have as
> operands of an ADDR_EXPR? We certainly never even thought of such a rule
> before.
Hmm, odd that such a rule wouldn't exist. To me it seems an ADDR_EXPR
only makes se
On Saturday 10 September 2005 13:48, Gunther Piez wrote:
> Why?
>
> I just switched my project to gcc-4.0.1 and now i get tons of warnings :-(
> I always found the min/max operators extremly useful, especially der
> assignment variations ?= . There isn't even an replacemant for
> them I am aware of
On Monday 12 September 2005 18:55, Giovanni Bajo wrote:
> Daniel Towner <[EMAIL PROTECTED]> wrote:
> > The linker and assembler used by the port are proprietary, and can't
> > be made publicly available at this point. The port will have to be
> > assembler output only.
>
> I suppose this means that
On Wednesday 14 September 2005 10:53, Robert Dewar wrote:
> Gerald Pfeifer wrote:
> > (If so, I'm wondering what it's going to buy the interested parties,
> > because I have a hard time seeing one of the large GNU/Linux distributors
> > switching to a compiler different from FSF GCC for Itanium.)
>
On Friday 16 September 2005 07:47, Christian Joensson wrote:
> .. just a quickie here... I just noticed that I don't see the fortran
> test results on cvs trunk anymore... I suppose this might be related
> to the change of name from f95/gfortran to fortran...
Unlikely. --enable-languages=f95 stil
On Sep 22, 2005 11:25 AM, Zdenek Dvorak <[EMAIL PROTECTED]> wrote:
> > 4. Other ideas?
>
> Preserving the information about loops throughout the optimizations, and
> just keeping this information attached at the loop description would by
> far be the cleanest approach -- admitedly also the one tha
On Friday 30 September 2005 21:36, Asher Langton wrote:
> On Thu, 29 Sep 2005, Jack Howarth wrote:
> > Asher,
> >Any progress on the paperwork?
>
> None. I haven't received anything from the FSF. I just pinged them
> again. The FSF does have a disclaimer from LLNL, which seems like it
> shou
On Saturday 01 October 2005 01:02, George White wrote:
> Frankly, I don't care what standards say is no longer acceptable
> syntax.
I think this is a nice summary of your mail.
Fortunately, most of our users do care about this.
Gr.
Steven
On Monday 26 September 2005 10:38, Paolo Bonzini wrote:
> Right now, I am thinking more
> about shuffling the pass order. One possibility that comes to mind is
> GCSE+fwprop+CSE, where GCSE could work out the common code for loading
> the address, and fwprop/CSE could do the addressing mode select
On Thursday 29 September 2005 17:29, Segher Boessenkool wrote:
> >int f(int *);
> >int verbosity;
> >int *arr;
> >int last;
> >
> >void g ()
> >{
> > int i;
> > if (last < 4000) {
> > if (verbosity >= 4) f(&verbosity);
> > for (i = 0; i <= last;
On Saturday 08 October 2005 01:23, Steve Ellcey wrote:
> I would like to start by getting any input and advice the members of the
> GCC community might have for me.
This may be a totally stupid idea, but perhaps you can start with
writing a new PCH format that is not just a memory dump but a real
On Thursday 06 October 2005 16:17, Daniel Berlin wrote:
> This branch contains the work Ken Zadeck and I have been doing
> replacing the backend dataflow (such as live register analysis) with
> df.c based dataflow.
Very cool! :-)
Gr.
Steven
On Monday 10 October 2005 19:35, Mark Mitchell wrote:
> As previously announced, here:
>
> http://gcc.gnu.org/ml/gcc/2005-10/msg00093.html
>
> the mainline is now subject to the usual release-branch rules: only
> fixes for regressions.
How does this affect gfortran, and what about already posted
b
On Friday 14 October 2005 01:41, Evan Cheng wrote:
#(insn:TI 126 125 40 (parallel [
#(set (reg:SI 0 ax [71])
#(minus:SI (reg:SI 0 ax [71])
#(reg:SI 5 di)))
#(clobber (reg:CC 17 flags))
#]) 242 {*subsi_1} (insn_list:REG_DEP_TRUE 12
[Sorry, pressed the wrong key combination again for the other mail... ]
On Friday 14 October 2005 01:41, Evan Cheng wrote:
> gcc produces the following code:
You're not giving enough information for me to reproduce it. I used
"-O2 -march=i686 -dAP" for the follow annotated assembler output:
#(in
Hi,
Since October 13, SPEC's swim, applu, and sixtrack fail to build and
fma3d has a
serious performance degradation. See the results from Diego's SPEC
tester:
http://people.redhat.com/dnovillo/spec2000.i686/gcc/individual-run-ratio.html
Gr.
Steven
On Wednesday 19 October 2005 17:06, Paolo Carlini wrote:
> Daniel Berlin wrote:
> >5. Lastly, just to be clear, if you guys don't think the benefits
> >outweigh the costs, we don't have to move.
> >So far, the amount of dissent i've heard is pretty small, but please, if
> >you don't want to move (o
On Oct 20, 2005 10:45 AM, Uros Bizjak <[EMAIL PROTECTED]> wrote:
> I got following times:
>
> 1m37.986
> 1m37.139
> 1m38.410
>
> And _with_ patch:
>
> 1m37.264
> 1m37.352
> 1m37.383
>
> I would say that the difference is burried in noise.
It is still an extra pass over all instructions in the func
On Oct 20, 2005 11:01 AM, Eric Botcazou <[EMAIL PROTECTED]>
wrote:
> - portability of svn to non-Linux systems
http://subversion.tigris.org/faq.html#portability
Gr.
Steven
On Oct 20, 2005 12:11 PM, Arnaud Charlet <[EMAIL PROTECTED]> wrote:
> And maybe if svn 1.4 will improve such important improvements, it
> would
> be a good idea to wait till svn 1.4 is outt so that people do not have
> to
> upgrade multiple times to get "the expected" behavior.
By then, I'm sure,
On Thursday 20 October 2005 15:33, Daniel Jacobowitz wrote:
> I eagerly look forward to svn.
Yay. Agreed.
Gr.
Steven
On Thursday 20 October 2005 16:57, Richard Kenner wrote:
> Sorry about that, but let's not remember of the other dozens which
> works on branches and can do a merge in seconds instead of literally
> *hours*, and so on.
>
> Yes, but how often do even those who work on branches a lot do m
On Oct 21, 2005 02:55 PM, shreyas krishnan <[EMAIL PROTECTED]> wrote:
> Hi,
> I want to demarcate conditional statments similar to how NOTE's
> are use to make loop starts and ends.
The fact that we use NOTEs for loops is considered a mis-feature. May I
suggest you browse gcc-patches archives f
On Oct 21, 2005 03:12 PM, Toon Moene <[EMAIL PROTECTED]> wrote:
> L.S.,
Toon S., welcome back :-)
May I suggest you try the autovect-branch too, a lot of vectorizer
enhancements are still pending there...
Gr.
Steven
Kind regards,
>
> --
> Toon Moene - e-mail: [EMAIL PROTECTED] - phone: +31 346 214290
> Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
> A maintainer of GNU Fortran 95: http://gcc.gnu.org/fortran/
>
Steven Bosscher
SUSE Labs
On Oct 22, 2005 09:34 PM, Steven Bosscher <[EMAIL PROTECTED]> wrote:
>
Some stuff that, needless to say, was in Dutch and intended for Toon
only.
Sorry,
Gr.
Steven
On Tuesday 25 October 2005 22:19, [EMAIL PROTECTED] wrote:
> Hello,
>
> We just bought a HP Integrity Itanium server and are running VMS 8.2.
> Does a Gnu C-compiler exist ?
So, you're saying you can find this mailing list, but not the compiler
that is being discussed here?
Gr.
Steven
On Oct 26, 2005 02:30 AM, Joe Buck <[EMAIL PROTECTED]> wrote:
> I'm still waiting for an explanation as to why this is an important
> issue, other than that someone has a customer who says that it is.
> Why is it important to the customer? Why wouldn't a one-line sed
> script that eliminates the is
On Wednesday 26 October 2005 18:28, Joe Buck wrote:
> That's what we have standards for: so that compilers work the same way
> for standard-conformant code.
And we have de facto standards that you just want to ignore.
Gr.
Steven
On Wednesday 26 October 2005 18:58, Robert Dewar wrote:
> Steven Bosscher wrote:
> > On Wednesday 26 October 2005 18:28, Joe Buck wrote:
> >>That's what we have standards for: so that compilers work the same way
> >>for standard-conformant code.
> >
> >
On Nov 01, 2005 01:07 PM, Anthony Shipman <[EMAIL PROTECTED]> wrote:
> But then if I compile with -O the constructor will be inlined. The
> generated
> machine code contains a loop which does nothing 100 times:
> movl $100, %eax
> L11:
> decl %eax
> jne .L11
>
> I think that the optimiser should ge
On Nov 01, 2005 02:07 PM, Florian Weimer <[EMAIL PROTECTED]> wrote:
> * Steven Bosscher:
>
> >> I think that the optimiser should get rid of the loop once it has
> >> got
> >> rid of
> >> the body!
>
> > I don't think so. This kind of
On Tuesday 01 November 2005 19:59, Jim Wilson wrote:
> Rainer Emrich wrote:
> > rm -f /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/; \
> > ln /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/gfortran
> > /appl/shared/gcc/Linux/i686-pc-linux-gnu/gcc-4.0.2/bin/; \
>
> Looking
On Saturday 05 November 2005 18:54, Giovanni Bajo wrote:
> Hello,
>
> any specific reason why we still don't unroll loops by default at -O3? It
> looks like it gives better results on most benchmark, and many people use
> it always together with -O3 to say "really optimize, I mean it".
One reason
On Saturday 05 November 2005 19:11, Robert Dewar wrote:
> I guess the issue is what does "huge" mean, it is hard to discuss based
> on loaded adjectives taking the place of data :-)
Huge here means 15-20% on x86* hosts.
Gr.
Steven
On Saturday 05 November 2005 19:49, Giovanni Bajo wrote:
> My feeling is that -funroll-loops is almost always an improvement. It might
> be false sometimes, but this can be said of many optimization passes.
You can't enable an option based on a feeling ;-)
Gr.
Steven
On Sunday 06 November 2005 01:12, Robert Dewar wrote:
> Giovanni Bajo wrote:
> > Steven Bosscher <[EMAIL PROTECTED]> wrote:
> >>>I guess the issue is what does "huge" mean, it is hard to discuss based
> >>>on loaded adjectives taking the place o
Hi,
We have this interesting ABI change between GCC 3.3 and GCC 3.4, which
we are tracking in PR22275. A test case for the problem is this:
typedef unsigned long size_t;
#ifndef offsetof
#define offsetof(TYPE, MEMBER) ((size_t) &((TYPE *)0)->MEMBER)
Hi,
Something fixed something:
http://www.inf.u-szeged.hu/csibe/draw-diag.php?draw=sum-ot&basephp=s-i686-linux
Obviously there's no reason to complain. But does anyone know where
this came from?
Gr.
Steven
Hi,
This is a bit of a silly question, maybe, and I feel kinda stupid that
I have to ask, but grep doesn't help and looking through ChangeLogs is
not getting me any further either.
So...
Where does the MIPS backend define TARGET_EXPLICIT_RELOCS? It is used
in a lot of places in this backend, bu
Hi,
I'm trying to figure out how much effort it would take to make
dbr_schedule CFG aware. One of the issues I'm running into is
that the RTL CFG stuff doesn't support SEQUENCEs at all. So if
I have a delay slot filled, e.g.,
(sequence [
(jump_insn (...)) ;; The branch with delay slots
On Sunday 13 November 2005 22:02, Jeffrey A Law wrote:
> No great insights on how to make dbr_schedule CFG aware -- just
> remember that a filled delay slot can represent 3 different cases:
>
> 1. An extension of the block containing the sequence.
>
> 2. An extension of the block at the target
On Nov 14, 2005 10:31 AM, Florian Weimer <[EMAIL PROTECTED]> wrote:
>
> What do you think?
I thought labels can't appear in an asm statement...?
Gr.
Steven
On Nov 14, 2005 12:52 PM, Martin Reinecke <[EMAIL PROTECTED]>
wrote:
> Hi,
>
> current mainline boostrap breaks (at least for me) on
> i686-pc-linux-gnu.
Known problem, someone checked in a bad patch.
See http://gcc.gnu.org/ml/gcc-patches/2005-11/msg00946.html
Gr.
Steven
On Tuesday 15 November 2005 19:59, Mark K. Smith wrote:
> RTL is too complicated. On Andrew Macleod and my etsimation only
> writing a new good register allocator is at least 2 years project.
> Significtant simplifying rtl or usage another IR is even more
> complicated task than introducing Tree-SS
On Nov 16, 2005 02:35 PM, Osku Salerma <[EMAIL PROTECTED]> wrote:
> Not sure what you mean by "have the branches locally" (SVK?), but a
> plain rename of a branch doesn't force new check-outs, people can use
> svn switch to point their working copies at the new branch name.
But some people have th
On Wednesday 16 November 2005 15:35, Dorit Naishlos wrote:
> We'd like to suggest a few new tree-codes/optabs in order to express the
> extraction and merging of elements from/to vectors.
Watch out for tree code starvation:
$ ~/devel/gomp-branch/gcc> grep ^DEFTREECODE *.def | wc
181 908
On Nov 17, 2005 01:11 PM, "Unruh, Erwin"
<[EMAIL PROTECTED]> wrote:
> is there some
> equivalent.
No, there isn't. You are not being very specific about the problem you
are trying to solve. You'll have to tell more before anyone can give
you a more helpful answer.
Gr.
Steven
On Thursday 17 November 2005 16:51, Dorit Naishlos wrote:
> only thing I can suggest in the context of the vectorizer is to use an
> extra argument to save a few tree-codes:
I don't think that this is a good idea. If we are going to need
more tree codes, we're just going to have to figure out a w
On Thursday 17 November 2005 16:55, Steven Bosscher wrote:
> On Thursday 17 November 2005 16:51, Dorit Naishlos wrote:
> > only thing I can suggest in the context of the vectorizer is to use an
> > extra argument to save a few tree-codes:
>
> I don't think that this
On Friday 18 November 2005 17:31, Michael Matz wrote:
> Perhaps even a merger of both
> approaches is sensible, three address form for most simple gimple
> statements with falling back to stack encoding for deeply nested operands.
That would be a bad violation of the KISS principle.
Gr.
Steven
On Thursday 17 November 2005 17:53, Andrew MacLeod wrote:
> http://people.redhat.com/dnovillo/rable.pdf
How are the insn annotations and caches you propose different from
what df.c already does?
Gr.
Steven
On Saturday 19 November 2005 18:56, Chris Lattner wrote:
> > Only the Ada frontend seems to be in a state to maybe support direct
> > frontend IR to LLVM translation.
>
> Sure, also maybe Fortran?
I wouldn't count on it...
Gr.
Steven
On Sunday 20 November 2005 01:49, Chris Lattner wrote:
> On Sun, 20 Nov 2005, Steven Bosscher wrote:
> > On Saturday 19 November 2005 18:56, Chris Lattner wrote:
> >>> Only the Ada frontend seems to be in a state to maybe support direct
> >>> frontend IR to LLVM
On Tuesday 22 November 2005 17:20, Diego Novillo wrote:
> The initial impression I get is that LLVM involves starting from scratch.
I thought it would basically "only" replace the GIMPLE parts of the
compiler. That is,
FE --> GENERIC --> LLVM--> RTL --> asm
(trees)
On Tuesday 22 November 2005 20:26, Peter Bergner wrote:
> Insn Annotations [page(s) 17-18]:
> * I like the idea of easy access to the register usage info
> provided by the insn annotations. RTL isn't really setup
> for making that easy.
But it is if you use df.c. Really, it is.
On Tuesday 22 November 2005 21:18, Scott Robert Ladd wrote:
> Jan Hubicka wrote:
> > I should note that comparison to ICC is not quite fair since it lacks
> > Opteron tunning...
>
> I think you may be comparing oranges to tangerines -- not as bad as
> apples and oranges, but still potentially an in
On Tuesday 22 November 2005 19:17, Benjamin Kosnik wrote:
> What about compile-time performance?
>
> I'd actually like to make this a requirement, regardless of the option
> chosen.
Amen.
Maybe we should pick a baseline compiler, and require that all
compile time comparisons are made wrt. that ba
On Tuesday 22 November 2005 20:21, Benjamin Kosnik wrote:
> Tree-SSA managed to add new technology to the compiler without major
> slowdowns.
You must be looking at different timings than I do.
GCC 4.1 is on average almost 40% slower than GCC 3.3.
Gr.
Steven
On Tuesday 22 November 2005 20:06, Richard Henderson wrote:
> > The GVM plan could take years to get to that point...
>
> Could, but probably won't. I'd have actually guessed they could
> have something functional, if not 100% robust, in 6 months given
> 2 or 3 people on the project.
Yes. But wo
On Tuesday 22 November 2005 23:32, Eric Botcazou wrote:
> > > Tree-SSA managed to add new technology to the compiler without major
> > > slowdowns.
> >
> > You must be looking at different timings than I do.
> >
> > GCC 4.1 is on average almost 40% slower than GCC 3.3.
>
> That's not true for GCC 4
Hi Aldy,
The MS1 backend is not listed in http://gcc.gnu.org/backends.html.
Could you please add it?
Gr.
Steve
On Sunday 04 December 2005 17:48, H. J. Lu wrote:
> SPEC CPU 2K FP compiled with gcc 4.2 failed to run with libgfortran
> from gcc 4.1. Is this expected?
Yes.
On Saturday 03 December 2005 20:43, Mark Mitchell wrote:
> There is one advantage I see in the LTO design over LLVM's design. In
> particular, the LTO proposal envisions a file format that is roughly at
> the level of GIMPLE. Such a file format could easily be extended to be
> at the source-level
On Tuesday 06 December 2005 00:23, Jim Blandy wrote:
> Debug information describes two things: (...snip...)
> Keeping the two representations separate (which I could easily
> see being beneficial for optimization) shifts that burden onto some
> new party which isn't being discussed, and which will
On Thursday 08 December 2005 13:11, Richard Guenther wrote:
> look at those CSE numbers!
Why do they surprise you?
> The profile generating numbers suggest we're either doing something
> stupid, or that we want some heuristics applied to not instrument
> every edge, but only interesting ones.
We
Hi,
Someone caused a >10% compile time regression yesterday for CSiBE, see
http://www.csibe.org/draw-diag.php?branchid=mainline&flags=-Os&rel_flag=--none--&dataview=Timeline&finish_button=Finish&draw=sbs&view=1&basephp=l-sbs
Gr.
Steven
Hi people,
Consider the following C++ program, which is my test case for PR25130,
a wrong-code issue seen on x86 and powerpc (with a different test case)
but it can probably be triggered anywhere under the right, well wrong,
circumstances if I understand the bug properly (and that's a Big If).
//
On Dec 20, 2005 08:17 AM, Eric Fisher <[EMAIL PROTECTED]> wrote:
> >Yes for zero'd initialized variables, GCC puts them into BSS to say
> >space in the executable.
>
> Thanks. But, you say 'to say space in the executable'. I'm not clear
> what does it mean.
"save space".
Gr.
Steven
On Dec 20, 2005 10:50 AM, Hans-Peter Nilsson
<[EMAIL PROTECTED]> wrote:
> The actual code should be simple; I just want to check that
> there's consensus on the actual change before doing it.
>
> Thoughts?
You really have to wonder if cleaning up this jump is a job combine
should be doing. I woul
On Tuesday 20 December 2005 21:04, Grigory Zagorodnev wrote:
> GCC 4.1 is getting ICE in ' refers_to_regno_for_reload_p' while
> compiling CPU2000/177.mesa on ia32 Linux.
>
> Is that a known issue?
You could have asked bugzilla before asking here ;-)
Gr.
Steven
On Dec 22, 2005 02:28 PM, Piotr Wyderski <[EMAIL PROTECTED]> wrote:
> HOST: AIX, 8 * IBM POWER2 CPU
> COMPILER: GCC 4.0.1, GCC 3.4.4
>
> I am trying to compile my low-level library, which contains
> several inline assembly functions. It doesn't work, because
> the compiler (4.0.1) does not replace
Hi rth,
The stack space sharing you added to cfgexpand.c breaks RTL alias
analysis.
For example, the attached test case breaks for pentiumpro at -O2.
The problem apparently is that the second store to c is moved up
before before the load.
This looks like a serious problem to me...
Many thanks t
On Tuesday 03 January 2006 17:27, Richard Henderson wrote:
> I'll have to give this some thought.
Heh, like many before you... Hope you can come up with an answer.
This is now bug 25654 in Bugzilla.
Gr.
Steven
On Wednesday 11 January 2006 21:44, Steven Bosscher wrote:
> Hi,
>
> I can't build the trunk today:
>
> gcc -c -O0 -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
> -Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
> -Wold-style-definition
Hi,
I can't build the trunk today:
gcc -c -O0 -g -DIN_GCC -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -pedantic -Wno-long-long -Wno-variadic-macros
-Wold-style-definition -Wmissing-format-attribute-DHAVE_CONFIG_H -I. -I.
-I../../trunk/gcc -I../../trunk/gcc/. -I../
On Saturday 14 January 2006 01:42, Alfred M. Szmidt wrote:
> Could someone check the bugs that depend on #21824? They have been
> pending for several months now with no activity, and it is kinda bad
> karma not having GCC working on the GNU system.
The usual process is that you post them to the g
On Saturday 14 January 2006 02:18, Alfred M. Szmidt wrote:
> But this seems very awkward for people who only send a patch ones in a
> blue moon;
Why? There are lots of people who only send a few patches per year
and they all know how to contribute them.
> and not much good info on that either, t
On Sunday 15 January 2006 10:35, Robert Dewar wrote:
> >- I believe that it is a grave mistake to conclude that a well defined
> > semantic operation on an indeterminate value, has undefined semantics.
>
> Well the standards committee made the grave mistake if it is one, so if
> you want to challe
On Sunday 15 January 2006 22:13, John David Anglin wrote:
> #include
> unsigned char
> T (unsigned char x)
> {
> static int first = 1;
> static unsigned char firstx;
>
> if (first)
> {
> first = 0;
> firstx = x;
> return ~x;
> }
>
> if (x == firstx)
> printf (
> >For what it's worth, it annoys me to no end that you have managed to
> >turn more than a day of hard work to understand and fix PR24626 into
> >a discussion about defining undefined behavior. I don't think I'll
> >ever look at HPPA bugs anymore if they don't affect me.
>
> Well we have to under
On Tuesday 03 January 2006 17:27, Richard Henderson wrote:
> On Mon, Jan 02, 2006 at 12:45:49AM -0500, Daniel Berlin wrote:
> > ... the real
> > solution is to transfer the information that the stack space sharing
> > knows into some simple set form, and use *that directly* in alias.c, and
> > chec
On Sat, Jul 4, 2015 at 3:45 PM, Ajit Kumar Agarwal wrote:
> I am not sure why the above optimization is not implemented in GCC.
-fsplit-ivs-in-unroller
Ciao!
Steven
On Fri, Apr 29, 2016 at 12:52 PM, Kyrill Tkachov wrote:
> I'm looking at an issue in RTL ifcvt and I'm trying to understand the way
> edges between
> basic blocks are treated and in particular what is the canonical use of
> EDGE_FALLTHRU.
> Is it governed by the conditional jump condition?
>
> In f
(NONJUMP_INSN_P (insn)
> && (! reload_completed
> || (GET_CODE (PATTERN (insn)) != USE
> && GET_CODE (PATTERN (insn)) != CLOBBER))));
> }
>
> It is clear that someone [Steven Bosscher] thought it needs fixing but what's
> the prob
On Sat, Jul 26, 2014 at 7:57 PM, Andreas Schwab wrote:
> NightStrike writes:
>
>> On Jul 26, 2014 9:26 AM, "Andreas Schwab" wrote:
>>>
>>> pinskia writes:
>>>
>>> >> On Jul 23, 2014, at 9:51 AM, Andreas Schwab wrote:
>>> >>
>>> >> Ian Lance Taylor writes:
>>> >>
>>> >>> At the same time, we face th
On Fri, Aug 15, 2014 at 9:59 PM, Aldy Hernandez wrote:
> So... I've been getting my feet wet with LTO and debugging and I noticed a
> seemingly unrelated yet annoying problem. On x86-64,
> gcc.dg/guality/pr48437.c fails when run in LTO mode.
Eh, sorry I can't actually answer your question but, e
On Sat, Aug 30, 2014 at 12:23 AM, Trevor Saunders wrote:
>> Of course we should make things more explicit here and move all data
>> structures out of GC that are explicitly freed. Work in that direction is
>> welcome. The CFG is in GC memory because it indirectly refers to trees (the
>> sing
301 - 400 of 961 matches
Mail list logo
