ns?
Branches are for major work and a new pass is not that major.
Gr.
Steven
is uninitialized for
the "return" statement or not?
Gr.
Steven
is apparently necessary for good Windows support, and something
that other compilers there support, so why not have it in GCC?
> Looks like gcc is really heading down the wrong way..
So which way would you suggest it should go?
Gr.
Steven
4.1 right now is a small compile time disaster. Are there any
ideas for what can be done about it before releasing it?
Gr.
Steven
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
t do many useful things anymore, so this "some" is likely a
negligible some.
A more likely source of performance degradation is that loop unrolling
is enabled when profiling, and loop unrolling is almost always a bad
pessimization on 32 bits x86 targets.
Gr.
Steven
ight help iff you are using a gcc 4.1
based compiler.
> However this option is not
> recognized by the gcc 3.4.4 or 3.4.3 compilers. What
> am I missing?
You are missing that
1) this whole thread does not concern gcc 3.4.x; and
2) the option -fmove-loop-invariants does not exist in 3.4.x.
Gr.
Steven
roblems have been about those later versions, not the
> version he is using.
Ah. Sorry then. My bad.
Gr.
Steven
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
d GENERIC and ought to be
> handled by the gimplifier.
I don't think we ever defined "valid GENERIC" that way. If we had done
that, the C and C++ front ends wouldn't have had to be converted to make
them produce valid GENERIC.
So IMHO your code should just be Ada specific.
Gr.
Steven
to do
this, but apparently it doesn't. So, Diego, is this a real bug
in store-copyprop or am I expecting too much of your pass here?
Gr.
Steven
le? As Kenner puts it himself:
"This turned out to be the "well known" problem that the Ada
front end is making an ADDR_EXPR of odd things, in this case
a COMPOUND_EXPR."
So there you have it: a well known problem in the Ada front end, not
a bug in the gimplifier.
Gr.
Steven
DDR_EXPR
only makes sense on something that is addressable, and a COMPOUND_EXPR
is not addressable, even if, as in your example, the language semantics
explain how the & is to be interpreted. IMHO for GENERIC we should
only allow ADDR_EXPRs to appear on addressable things (i.e. addressable
symbols).
Gr.
Steven
compound
forms (`?=') have been deprecated and will be removed in a future
version. Code using these operators should be modified to use std::min and
std::max instead."
Gr.
Steven
free toolchain;
or gcc developers not being able to test changes when some patch
needs changes in every port.
Gr.
Steven
two entirely different backends. Would it even want to
hire new engineers or let its existing work-force learn compiler
internals of another compiler to support just one target? I don't
think so.
Gr.
Steven
-languages=f95 still works.
Gr.
Steven
- admitedly also the one that requires the
> greatest amount of work.
Shouldn't the regions patch allow us to preserve loops quite easily?
Gr.
Steven
utor here that it's taking such
a long time :-(
Gr.
Steven
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
ressing mode selection
> properly.
If fwprop runs before GCSE, you can remove gcse.c's local_cprop. I've
tested it and there is nothing useful left to do for local_cprop after
running fwprop.
That saves another whole pass over the function, plus it makes one more
cselib client disappear :-)
Gr.
Steven
rbosity >= 4) f(&verbosity);
> > for (i = 0; i <= last; i++) arr[i] = i;
> > }
> >}
>
> If last != 0, arr+i cannot point to last for any i,
> as last is not part of an array with two or more
> elements. Does GCC perform loop versioning for
> cases like this?
No.
Gr.
Steven
a real
dump of the IL, and work from there. At least that way you have
something you can test your IL reader/writer with right now, and
it buys other folks some time to address some more fundamental
problems blocking real IPA at the moment.
Gr.
Steven
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
out already posted
but still unreviewed patches?
Gr.
Steven
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
ly model that in this case.
> My question is: where and how would you suggest we do this
> optimization.
combine.
> With peephole2?
You'd get an explosion of peephole patterns.
Gr.
Steven
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
he job better.
It's also not a particularly great idea to duplicate a lot of code (like
you did, from the CC-cse pass), and I thought machine-specific
optimization passes are a no-no unless there really, _really_ is no way
to do the optimization elsewhere in the shared code.
Gr.
Steven
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
switch will occur in a week" was relatively effective at that ;-)
> - getting as much improvements in svn 1.4 as possible
> - switch when 1.4.x is out and considered stable enough so that people
> can use it heavily
This smells like the "committee approach" ;-)
Gr.
Steven
On Thursday 20 October 2005 15:33, Daniel Jacobowitz wrote:
> I eagerly look forward to svn.
Yay. Agreed.
Gr.
Steven
me of the benefits for the most common operations like diffing, updating,
and regression hunting.
Gr.
Steven
gcc-patches archives for the structure analysis /
region formation patches of which previews were posted recently?
Gr.
Steven
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
Als je wil, kan ik wel een handje helpen door e.e.a. te analyzeren
voordat je de problemen voorlegt aan de mailing-list.
Erg interessant, als dit werkt. Gaat het KNMI ook daadwerkelijk
gfortran gebruiken of zijn we nog lang niet ver genoeg daarvoor?
Gr.
Steven
On Oct 21, 2005 09:49 PM, Toon
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
nical superior
thing to do, it may not be the right thing to do. People actually use
this compiler, and if GCC does things differently from most others
compiler, it makes GCC a headache instead of a tool if those folks want
to switch compilers.
Gr.
Steven
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.
> >
> >
o-server.de/gcc-m16c/20050419.html', it said, GCC
M16C project is totally bugy.
so, what's the fact and what's your suggestion? (BTW: i need compile C++ not C
only)
thanks!
--
steven woody (id: narke)
fact i can not,
i know nothing about compiler writing :(
so, i am thinking another question. if i can write the code which can pass both
the current (3.4) g++ compiler and the IAR M16C C++ compiler, so my problem
will resolved. but is it possible of the idea? i think i can use some #ifdef
sta
te that
okay, it's a good news.
> g++'s C++ is much more strict and current than most other C++
> compilers; it's likely you'll have to fix your code to get it to work,
> but this would be due to code bugs and not g++ bugs if so.
i plan to write in g++ from scratch. so its strictness is a good news and it
will make life easy when i later compile on IAR's compiler, do i rightly
understand?
--
steven woody (id: narke)
How Far You Fall Doesn't Matter, It's How You Land
- Haine, La (1995)
after it were done, i will get capabilities of compile/linker from c++ source
to M16C executable on my Linux host computer and the special capabilities come
from giving extra options to gcc/ld/as command and these commands will keep no
change when i use them normally and produce native code, righ
I think that the optimiser should get rid of the loop once it has got
> rid of
> the body!
>
> Should I submit this as a bug?
I don't think so. This kind of thing is optimized away by gcc 4.1
already.
Gr.
Steven
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
riately.
>
> I think we need a PR here to keep track of this.
>
> The install rule starts with a "-", so it shouldn't have caused the
> install to fail, even though it is wrong. I haven't seen install
> failures because of this problem.
Wasn't this whole issue fixed by this patch:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg01785.html
Gr.
Steven
, I mean it".
One reason why it's not enabled is because it causes a huge compile time
regression.
Gr.
Steven
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
h seems to be the
behavior of GCC pre-3.4.
Jason suggested that it looks like they want it to mean "align the
next field despite pragma pack". So that is option (2),
Is this acceptable to everyone here?
Gr.
Steven
P.S. Just as an interesting observation: Intel ICC 8.0 follows the GCC
3.3 behavior, but ICC 9.0 breaks in the same way that GCC 3.4 and
later do :-)
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
i want to check in my C++ program, what variable is allocated in where. is
there such a tool?
another relative question is, where the 'new' operator get memory from? the
global heap? does it same with what 'malloc' get from?
thanks.
--
steven woody (id: narke)
Ce
how can i get see the runtime memory useage graph for my c++ program? this will
include stack memory and dynamic memory (heap). thanks.
-
narke
i want to check in my C++ program, what variable is allocated in where. is
there such a tool?
another relative question is, where the 'new' operator get memory from? the
global heap? does it same with what 'malloc' get from?
thanks.
--
steven woody (id: narke)
Ce
ckend, but I can't find where it's defined.
Help? :-)
Gr.
Steven
quot; and go hack
all the RTL cfg routines to support SEQUENCEs. But I'd rather
not do that unless I'm really sure nobody thinks that is a Very
Bad Idea. ;-)
Thoughts?
Gr.
Steven
lock at the target of a branch.
>
> 3. An extension of the fall-thru block.
>
> 4. An entirely new basic block on its own.
When can option 4 happen??
Gr.
Steven
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
e-reload pass. Which was ugly, but as a proof-of-concept I
think it was quite successful.
Gr.
Steven
ch name.
But some people have those branches checked out on autotester boxes, or
they have the branch names hard-coded into scripts and so on.
Renaming existing branches is IMHO a bad idea.
Gr.
Steven
code only
can hold that many...
Gr.
Steven
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
to figure out a way to
make it possible to have more tree codes, e.g. by cleaning up 8
of the 24 bits reserved for various flags, and make the field for
the tree code 16 bits.
Gr.
Steven
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
start (like tree-SSA did when LLVM was introduced to
the GCC community, ironically? ;-) so maybe Chris can have a working
prototype implementation within, what, months? The GVM plan could
take years to get to that point...
So my dummy prediction would be that the LLVM path would result in a
reasonable product more quickly than the GVM plan -- iff RTL stays.
Gr.
Steven
should be coming from the cfg which comes from profile data or
> from a good static profile.
The profile information or branch predictions are available in the
CFG. In fact, even the current Chow-like allocator uses it. See
allocno_compare in global.c.
Gr.
Steven
ter file, too,
for x86-64.
AMD's Opteron (AMD64) and Intel's Nocona (EM64T-cheap-ass-AMD64-clone)
are both just implementations of the x86-64 architecture. And ICC is
tuned for EM64T, I would guess. GCC is tuned for AMD64.
But both compilers compile for x86-64, so both compilers use the larger
register file.
Gr.
Steven
re made wrt. that baseline instead of
wrt. the head of the trunk, to avoid the gradual 0.05%-per-patch
slowdowns that keep accumulating...
Gr.
Steven
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
rts
at least as much as just moving to some entirely different IL for the
optimizers.
Without less heavy data structures, we're going to have such a huge
memory footprint that IPA would be practically impossible for serious
applications.
Gr.
Steven
than GCC 3.3.
>
> That's not true for GCC 4.0.
True, but GCC 4.0 produces code that is hardly better than what
GCC 3.3 makes of it, and 4.0 is still significantly slower. Just
not as much as GCC 4.1 (something like 15%-20% wrt. GCC 3.3, iirc).
Gr.
Steven
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.
IMPLE only, not the full front end
and middle-end tree representation.
Sharing a tree dumper between the front ends and the middle-end would
only make it more difficult again to move to sane data structures for
the middle end and to cleaner data structures for the front ends.
Gr.
Steven
nstead of "everything-is-a-tree".
If that means writing two intermediate representation dumpers, tough.
It would be worth it.
Gr.
Steven
ing edges :-P
Gr.
Steven
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
hat I'll
never learn enough RTL to be sure about anything.
2) Iff I am right at least, then I still wouldn't know how to make
GCSE handle these two MEMs differently.
So in short, I could use some help here, please :-)
Gr.
Steven
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
ine
should be doing. I would have thought we'd clean this up _before_
combine (and no, I don't mean the tree optimizers, but e.g. CSE, or jump
bypassing (even though the latter doesn't work for critical edges)). Are
there other cases, you think, where we fail to combine 2 insns into 2
cheaper ones??
Gr.
Steven
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
the compiler (4.0.1) does not replace local labels from the
> assembly code (i.e. "0:", "1:", etc.) with their machine-specific
> replacements ("LCFI..4:" and so on).
The manual says: "This assumes your assembler supports local labels, as
the GNU assembler and most Unix assemblers do." Does your assembler
support this?
Gr.
Steven
to Honza for crafting this test case.
Gr.
Steven
extern void abort (void) __attribute__((noreturn));
union setconflict
{
short a[20];
int b[10];
};
int
main ()
{
int sum = 0;
{
union setconflict a;
short *c;
c = a.a;
asm ("": "=r" (c):"0&q
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
igure --enable-languages=c
--disable-{libmudflap,nls,libssp,checking} --disable-bootstrap
make -j 2 CFLAGS="-O0 -g"
My host compiler is "gcc (GCC) 4.0.2 20050901".
Gr.
Steven
em to the gcc-patches mailing
list for review. And if they are approved, you can commit then or
you can ask someone to commit them for you. As far as I can tell,
you have never posted the patches. At least, there is no sign of
that in the PR audit trails.
Gr.
Steven
ose few users who want to help developing gcc can find links to that
documentation in the chapter "Contributing to GCC development" in the
users manual. It seems you overlooked that chapter.
Gr.
Steven
atic storage duration is used
while it is indeterminate (6.2.4, 6.7.8, 6.8)."
I have added Joseph to the CC:, maybe he can clarify things for us...
Gr.
Steven
301 - 400 of 1056 matches
Mail list logo
