> I am interesting in it. How about the current status, is it ongoing
> developing? Is it included in GCC official release?
Unfortunately our group is not actively working on that right now.
Because of some reasons
( mainly the paucity of time) we couldnt release it to the GCC
community then ( ab
> The file.c.176r.greg for insn 309 says
>
> "Spilling for insn 309.
> Using reg 6 for reload 0"
>
> and indeed rld[0].regno is 6 and rld[0].in is
>
> (plus:SI (reg/f:SI 29 $sp)
> (const_int 176 [0xb0]))
>
> However the function choose_reload_regs chooses $c1 for this reload
> and sets rld[0].r
Hi,
Is there any progress in the gcc-plugin project ?
How far is the code and what about its integration in a future release ?
I still think this is a great idea and I'm quite impatient to try it out
(I'll have some time in January).
Regards
--
Emmanuel Fleury
Out the 10Base-T, through the ro
On Nov 5, 2007, "Steven Bosscher" <[EMAIL PROTECTED]> wrote:
> I am worried about some of the things going on in the
> var-tracking-assignments branch. The thing that worries me most, is
> the introduction of an insn that is not an instruction:
> /* An annotation for variable assignment trackin
Hi Eric,
Thanks for the response
> Of course, it goes to great length to do so but there can be bugs. You didn't
> specify which version of the compiler you're using though; they may have been
> already fixed on the mainline.
Oh, I am using quite a new version of the compiler - rev 129547,
DATES
> Oh, I am using quite a new version of the compiler - rev 129547,
> DATESTAMP 20071022.
OK. AFAICS there is nothing glaring in the RTL you posted so you'll have to
put a watchpoint and find out who has set reg_rtx for this particular reload.
--
Eric Botcazou
> Even though the other 2 addressing modes are implemented, the
> attributes could not be checked in the other 2 modes. These 2 modes
> are "disp with register" and "register indirect" addressing modes. The
> tree structure in these addressing modes could not be checked for
> attributes using the R
> Did you test for large programs? Such as applications from SPEC 2006? or
> the equal size of programs. Thanks.
Oh no, we didnt. We stopped when we achieved fair stability purely on
the basis of
the number of testsuite failures ( less than 100).
cheers!
Pranav
> OK. AFAICS there is nothing glaring in the RTL you posted so you'll have to
> put a watchpoint and find out who has set reg_rtx for this particular reload.
reg_rtx gets set due to a call to choose_reload_regs which in turn
calls allocate_reload_reg to set reg_rtx.
Also, just to confirm if I am
David Edelsohn wrote:
Dave Korn writes:
Dave> I don't understand: why wouldn't designing it so that they have to be
Dave> implemented as DSOs and hence are covered by the
Dave> anything-directly-linked-in-is-GPL'd clause do the job? Or is the concern
Dave> that people will write trivial marsha
On 07 November 2007 16:41, Joe Buck wrote:
> On Wed, Nov 07, 2007 at 09:20:21AM +0100, Emmanuel Fleury wrote:
>> Is there any progress in the gcc-plugin project ?
>
> Non-technical holdups. RMS is worried that this will make it too easy
> to integrate proprietary code directly with GCC.
>
> If
Mark Mitchell <[EMAIL PROTECTED]> wrote on 05/11/2007 01:51:33:
> Gerald Pfeifer wrote:
> > On Thu, 1 Nov 2007, Janis Johnson wrote:
> >> -fipa-cp steven
> >> -fipa-matrix-reorg razya
> >> -fipa-pure-const zadeck (enabled with -O)
> >> -fipa-referencezadeck
Hello All:
This is a message already sent to the mspgcc-users mailing list, which
deals with msp430 port of the gnu toolchain for this 8bit microcontrollers
[1]. I now post it here because someone advised me that this was also a
good place to ask for this information.
I'm concerned about th
Hi,
On Wed, 7 Nov 2007, Alexandre Oliva wrote:
> > With the different approach I and Matz started (and to which we didn't
> > yet spend enough time to get debug information actually output - but I
> > hope we'll get there soon), on the tree level the extra information is
> > stored in a bitmap
Joe Buck <[EMAIL PROTECTED]> writes:
> On Wed, Nov 07, 2007 at 07:48:53AM -0800, Ian Lance Taylor wrote:
> > "Debarshi Sanyal" <[EMAIL PROTECTED]> writes:
> >
> > >Is there any way to turn off "named return value optimization"
> > > (NRVO) while compiling a C++ program with g++?
> >
> > This
On Nov 7, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
> Alexandre Oliva <[EMAIL PROTECTED]> writes:
>> I've pondered both alternatives, and decided that the latter was the
>> only testable path. If we had a reliable debug information tester, we
>> could proceed incrementally with the first
Hi,
Is there any way to turn off "named return value optimization"
(NRVO) while compiling a C++ program with g++?
Please reply. This is very urgent.
Regards,
Debarshi
Hello,
I am wondering whether there is a simple function/interface in GCC to
check whether one instruction is dependent on the other (direct and
indirect). It would be very useful for my target-specific optimizing
passes, and I could not find in the GCC internal manual and GCC source
code. Thanks
Razya Ladelsky wrote:
> Mark Mitchell <[EMAIL PROTECTED]> wrote on 05/11/2007 01:51:33:
>
>
>> Gerald Pfeifer wrote:
>>
>>> On Thu, 1 Nov 2007, Janis Johnson wrote:
>>>
-fipa-cp steven
-fipa-matrix-reorg razya
-fipa-pure-const zadeck (ena
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> I've pondered both alternatives, and decided that the latter was the
> only testable path. If we had a reliable debug information tester, we
> could proceed incrementally with the first alternative; it might be
> viable, but I don't really see that it
Bingfeng Mei wrote:
Hello,
I am wondering whether there is a simple function/interface in GCC to
check whether one instruction is dependent on the other (direct and
indirect). It would be very useful for my target-specific optimizing
passes, and I could not find in the GCC internal manual and GC
> Dave Korn writes:
Dave> I don't understand: why wouldn't designing it so that they have to be
Dave> implemented as DSOs and hence are covered by the
Dave> anything-directly-linked-in-is-GPL'd clause do the job? Or is the concern
Dave> that people will write trivial marshalling plugins and s
On Nov 7, 2007, at 9:28 AM, Robert Dewar wrote:
Tom Tromey wrote:
First, aren't we already in this situation? There are at least 2
compilers out there that re-use parts of GCC by serializing trees and
then reading them into a different back end.
It's not obvious to me that this is consistent
Tom Tromey wrote:
First, aren't we already in this situation? There are at least 2
compilers out there that re-use parts of GCC by serializing trees and
then reading them into a different back end.
It's not obvious to me that this is consistent with the GPL ..
interesting issue ...
Second,
Joe Buck wrote:
On Wed, Nov 07, 2007 at 09:20:21AM +0100, Emmanuel Fleury wrote:
Is there any progress in the gcc-plugin project ?
Non-technical holdups. RMS is worried that this will make it too easy
to integrate proprietary code directly with GCC.
If proponents can come up with good argume
On Wed, Nov 07, 2007 at 09:20:21AM +0100, Emmanuel Fleury wrote:
> Is there any progress in the gcc-plugin project ?
Non-technical holdups. RMS is worried that this will make it too easy
to integrate proprietary code directly with GCC.
If proponents can come up with good arguments about how the
"Debarshi Sanyal" <[EMAIL PROTECTED]> writes:
>Is there any way to turn off "named return value optimization"
> (NRVO) while compiling a C++ program with g++?
This question is not appropriate for gcc@gcc.gnu.org, which is for
developers of gcc. It is appropriate for [EMAIL PROTECTED]
Please
On Wed, Nov 07, 2007 at 07:48:53AM -0800, Ian Lance Taylor wrote:
> "Debarshi Sanyal" <[EMAIL PROTECTED]> writes:
>
> >Is there any way to turn off "named return value optimization"
> > (NRVO) while compiling a C++ program with g++?
>
> This question is not appropriate for gcc@gcc.gnu.org, wh
> "Joe" == Joe Buck <[EMAIL PROTECTED]> writes:
Joe> On Wed, Nov 07, 2007 at 09:20:21AM +0100, Emmanuel Fleury wrote:
>> Is there any progress in the gcc-plugin project ?
Joe> Non-technical holdups. RMS is worried that this will make it too easy
Joe> to integrate proprietary code directly wi
On Nov 7, 2007, Michael Matz <[EMAIL PROTECTED]> wrote:
> On Wed, 7 Nov 2007, Alexandre Oliva wrote:
>> This will fail on a very fundamental level. Consider code such as:
>>
>> f(int x, int y) { int c; /* other vars */
>> c = x; do_something_with(c, ...); // doesn't touch x or y
>> c = y; do
>> The concern is the many forms of shim layers that possibly could
>> be written more easily with a plug-in framework.
>
> there is also a difference in these two scenarios:
>
> 1. a) Company X writes a modification to GCC to generate special
> intermediate stuff with format Y.
>
> b) Com
On 07/11/2007, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
>
> This is a part of the code :
> --
> extern struct dummy temp[];
> error: array type has incomplete element type
> -
Brendon Costa wrote:
The concern is the many forms of shim layers that possibly could
be written more easily with a plug-in framework.
there is also a difference in these two scenarios:
1. a) Company X writes a modification to GCC to generate special
intermediate stuff with format Y.
b)
> Also, just to confirm if I am on the right track, shouldnt the bit for
> reg #1 (i.e $c1) be set in live_throughout in the insn chain for
> insn #91 ( reproduced below for convenience ) ?
>
> (call_insn:HI 91 270 92 5 cor_h.c:129 (parallel [
>(set (reg:SI 1 $c1)
>(c
Robert Dewar wrote:
> Brendon Costa wrote:
The concern is the many forms of shim layers that possibly could
be written more easily with a plug-in framework.
>>> there is also a difference in these two scenarios:
>>>
>>> 1. a) Company X writes a modification to GCC to generate special
On Wed, Nov 07, 2007 at 02:56:24PM -0800, Ian Lance Taylor wrote:
> At one time, gcc actually provided better debugging of optimized code
> than any other compiler, though I don't know if that is still true.
> Optimized gcc code is still debuggable today. I do it all the time.
> (For me poor suppo
Alexandre Oliva <[EMAIL PROTECTED]> writes:
> > Your approach gives you a point solution--did anything change
> > today--but it doesn't give us a maintenance solution--did anything
> > change over time?
>
> Actually, no, your assessment is incorrect.
Ah, you're right. I was wrong.
> > While I
Brendon Costa wrote:
The patch against GCC is GPL, the main library that is capable of
manipulating the data exported by the patched GCC is LGPL and could
theoretically be under any license.
Whose theory? You don't know that!
What i was trying to point out is that proprietary projects can
al
Snapshot gcc-4.2-20071107 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20071107/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.2 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
There are several outstanding bugs (29436, 28560, 28834, possibly
others) having to do with applying attributes to uses of structs in
typedefs or other places other than the point of definition. The
problem with doing this is that the attribute code makes a new
TYPE_MAIN_VARIANT, so we basical
If you want to have a legal discussion, please take this
conversation somewhere else.
Thanks, David
Robert Dewar wrote:
> Brendon Costa wrote:
>
>> The patch against GCC is GPL, the main library that is capable of
>> manipulating the data exported by the patched GCC is LGPL and could
>> theoretically be under any license.
>
> Whose theory? You don't know that!
I thought it was obvious :-) My T
David Edelsohn wrote:
> If you want to have a legal discussion, please take this
> conversation somewhere else.
>
> Thanks, David
>
Sorry. I just posted another email before i got this. Is there a
suitable place to move this discussion besides private emails?
Thanks,
Brendon.
On Wed, 7 Nov 2007, Mark Mitchell wrote:
> Jason Merrill wrote:
>
> > One solution to this issue would be to simply disallow attributes on
> > structs after the definition. Failing that, we need to define how they
> > interact with the type system. Opinions?
>
> We had a discussion about this
David Edelsohn wrote:
>> Mark Mitchell writes:
>
> Mark> I think we all agree that providing better debugging of optimized code
> Mark> is a priori a good thing. So, as I see it, this thread is focused on
> Mark> what internal representation we might use for that.
>
> Yes, it is a good
Joe Buck wrote:
> On Wed, Nov 07, 2007 at 09:20:21AM +0100, Emmanuel Fleury wrote:
>> Is there any progress in the gcc-plugin project ?
>
> Non-technical holdups. RMS is worried that this will make it too easy
> to integrate proprietary code directly with GCC.
>
> If proponents can come up with
Ian Lance Taylor wrote:
> At one time, gcc actually provided better debugging of optimized code
> than any other compiler, though I don't know if that is still true.
> Optimized gcc code is still debuggable today. I do it all the time.
> (For me poor support for debugging C++ is a much bigger iss
On Nov 7, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> First and foremost, I want to know what, concretely, Alexandre is
> trying to achieve, beyond "better debugging info for optimized
> code".
I'm not really going for "better". I'm going for "correct" first,
while making room for "better"
On Nov 7, 2007, Ian Lance Taylor <[EMAIL PROTECTED]> wrote:
>> Does it really matter? Do we compromise standards compliance (and so
>> violently, while at that) in any aspect of the compiler?
> What standards are you talking about?
Debug information standards such as DWARF-3.
> I'm not aware
Tomer Benyamini wrote:
Hi,
I was wondering if it is possible to create a dependency between 2 insns
through a specific scheduler hook (maybe through
TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK) even though the insns are not
really dependent (not really read-after-write etc.). If it is possible,
wh
Hi,
I was wondering if it is possible to create a dependency between 2 insns
through a specific scheduler hook (maybe through
TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK) even though the insns are not
really dependent (not really read-after-write etc.). If it is possible,
what is the best way to do
Hi Maxim,
Thanks for the prompt response! I'm using gcc 4.2.0, and couldn't locate
sd_add_dep in sched-deps.c. Is add_dependence () an appropriate
equivalent?
Thanks,
Tomer
-Original Message-
From: Maxim Kuvyrkov [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 08, 2007 09:30
To: Tome
Tomer Benyamini wrote:
Hi Maxim,
Thanks for the prompt response! I'm using gcc 4.2.0, and couldn't locate
sd_add_dep in sched-deps.c. Is add_dependence () an appropriate
equivalent?
Now quite.
Try
add_back_dep ();
add_forw_dep ();
--
Maxim
Joe Buck <[EMAIL PROTECTED]> writes:
> On Wed, Nov 07, 2007 at 09:20:21AM +0100, Emmanuel Fleury wrote:
> > Is there any progress in the gcc-plugin project ?
>
> Non-technical holdups. RMS is worried that this will make it too easy
> to integrate proprietary code directly with GCC.
>
> If propo
Jason Merrill wrote:
> One solution to this issue would be to simply disallow attributes on
> structs after the definition. Failing that, we need to define how they
> interact with the type system. Opinions?
We had a discussion about this a while back:
http://gcc.gnu.org/ml/gcc/2006-10/msg0031
> Mark Mitchell writes:
Mark> I think we all agree that providing better debugging of optimized code
Mark> is a priori a good thing. So, as I see it, this thread is focused on
Mark> what internal representation we might use for that.
Yes, it is a good thing, but not at any price. Re
On Nov 7, 2007, Mark Mitchell <[EMAIL PROTECTED]> wrote:
> Until we all know what we're trying to do
Here's what I am trying to do:
1. Ensure that, for every user variable for which we emit debug
information, the information is correct, i.e., if it says the value of
a variable at a certain inst
On Nov 7, 2007, David Edelsohn <[EMAIL PROTECTED]> wrote:
> Who is "we"? What better debugging are GCC users demanding? What
> debugging difficulties are they experiencing?
I, for one, miss the arguments of inlined functions, a lot.
The reason for that is that arguments are currently op
58 matches
Mail list logo
