Timothy Madden | 1 Feb 01:26 2010
Picon

Support for export keyword to use with C++ templates ?

On Sat, Jan 30, 2010 at 4:23 AM, Michael Witten
[...]
> However, I have a gut feeling that at least a restricted version of
> 'export' (or a cousin of 'export') could be both useful and trivial to
> implement: [...]
>

Those were my thoughts too.

Since such a change must happen in small steps, I would be interested
to know how 'acceptable' would a limited implementation be at first ?
Like the command line options I have seen declared 'experimental' in
the gcc manual before ...

The idea of a "cousin of" or "variation of" is less important though,
as I am interested in standard conformance, even if partly
implemented.

Timothy Madden

Timothy Madden | 1 Feb 01:34 2010
Picon

Re: Support for export keyword to use with C++ templates ?

On Sat, Jan 30, 2010 at 4:05 AM, Paolo Carlini <paolo.carlini <at> oracle.com> wrote:
[...]
> Even for implementors knowing *very* well both the details of the C++
> standard and the internals of a specific front-end, implementing export
> is an *highly* non-trivial task. [...]

Yes, everyone is telling me that, but could someone please describe a
little what would be the first problems that would have to be
addressed for export with the current g++ implementation ?  Or
summarise the steps that would have to be taken for a first attempt at
export ?

Did someone here said they tried some things before ?

Thank you,
Timothy Madden

Paolo Carlini | 1 Feb 01:38 2010
Picon

Re: Support for export keyword to use with C++ templates ?

On 02/01/2010 01:26 AM, Timothy Madden wrote:
> Since such a change must happen in small steps, I would be interested
> to know how 'acceptable' would a limited implementation be at first ?
> Like the command line options I have seen declared 'experimental' in
> the gcc manual before ...
>   
As I see the issue, you should first check over the next months that the
feature is not deprecated by ISO. Then start learning about the
internals of GCC and eventually propose a detailed plan explaining how
you want to attack the problem, because before that it's extremely
unlikely that the C++ front-end maintainers could even consider
reviewing patches from a novice for such an hard to implement feature.

That said, if you *really* plan contributing to GCC, maybe outside
export first (which seems a terribly good idea to me) first and
foremost, read the relevant web page:

   http://gcc.gnu.org/contribute.html

and start immediately the paperwork for the Copyright assignment,
because it takes time.

Paolo.

Ian Lance Taylor | 1 Feb 05:56 2010
Picon

Re: Support for export keyword to use with C++ templates ?

Timothy Madden <terminatorul <at> gmail.com> writes:

> On Sat, Jan 30, 2010 at 4:05 AM, Paolo Carlini <paolo.carlini <at> oracle.com> wrote:
> [...]
>> Even for implementors knowing *very* well both the details of the C++
>> standard and the internals of a specific front-end, implementing export
>> is an *highly* non-trivial task. [...]
>
> Yes, everyone is telling me that, but could someone please describe a
> little what would be the first problems that would have to be
> addressed for export with the current g++ implementation ?  Or
> summarise the steps that would have to be taken for a first attempt at
> export ?

Aside from what Paolo said, the first requirement is clearly going to
be the ability to write out and read in the frontend IR.

Ian

fanqifei | 1 Feb 09:13 2010
Picon

Re: Help-The possible places where insn is splitted in greg pass

2010/1/27 fanqifei <fanqifei <at> gmail.com>:
> 2010/1/25 Ulrich Weigand <uweigand <at> de.ibm.com>:
>> Qifei Fan wrote:
>>
>>> > But insn#479 is not recognized by recog() in insn-recog.c and the
>>> > compilation failed. (recog only recognizes RTL defined in md, right?)
>>> > Here the backtrace is
>>> > reload--->cleanup_subreg_operands--->extract_insn_cached--->extract_insn-=
>>> -->recog_memoized--->recog.
>>> > There is no machine instruction(r3=3Dr1*4+r2) match the pattern of
>>> > insn#479. Though there is pattern r3=3Dmem(r1*4+r2).
>>> > I don=92t quite understand the generation of reload information.
>>
>> There's two issues here.  The first issue is that reload makes the
>> fundamental assumption that everything that is a valid address, can
>> be loaded into a register as well, if necessary.  On many platforms
>> this is true, either because there is some sort of "load address"
>> instruction, or because the form of valid addresses matches standard
>> arithmetic instruction patterns.  Reload will simply emit a naked
>> "set" of some register to the address -- if the back-end doesn't
>> support that, you'll get the failure you saw.
>>
>> If this doesn't work on your particular platform, you could either
>> try to set things up so that reload never thinks it needs to reload
>> an address (but this may be difficult to achieve).  The safe option
>> would be to tell reload how to achieve computing an address by
>> providing a "secondary reload" pattern.  See e.g. s390_secondary_reload
>> (in config/s390/s390.c) and the associated "reload<mode>_plus" pattern.
>>
>> The second issue is as you notice here:
(Continue reading)

Jonathan Wakely | 1 Feb 10:27 2010
Picon

Re: Bugzilla and setting priorities

On 29 January 2010 11:09, Piotr Wyderski wrote:
> Paolo Carlini wrote:
>
>> Thus, what's the point of submitter fiddling with those Bugzilla
>> fields? Putting some sort of psychological pressure on people actually
>> working on fixing the bugs?
>
> Well, that's true when it comes to high priorities, but the
> submitter should have the opportunity to specify lower
> priorities. For instance a typo is a bug which should be
> fixed, but certainly it isn't a showstopper, so it doesn't
> deserve to be classified as a normal priority report.

Sorry for the late reply, but isn't that what the Severity field is for?
The submitter can say what the impact of the bug is, but they should
not dictate the order in which a bug should be fixed.
The Severity field is available on the Enter Bug form, and its meaning
is explained if you click on the field name (although I note that the
link is broken, it should be
http://gcc.gnu.org/bugs/management.html#severity not
http://gcc.gnu.org/bugs/management.html#bug_severity)

That explanation is repeated at
http://gcc.gnu.org/bugzilla/page.cgi?id=fields.html#bug_severity which
is what you get if you click on the field name once the bug has been
created.

Rainer Orth | 1 Feb 14:57 2010
Picon
Picon

Re: Obsoleting IRIX < 6.5, Solaris 7, and Tru64 UNIX < V5.1

Richard Sandiford <rdsandiford <at> googlemail.com> writes:

>> ** I also consider obsoleting support for the O32 ABI: the SGI linker used
>>    is different from the N32/N64 ld, and has repeatedly caused problems
>>    which couldn't be resolved even when SGI still had full IRIX
>>    support.  Also, the ISO C99 support in libc is only available for the
>>    N32 and N64 ABIs.
>
> Yeah, that's a difficult one.  On the one hand, I can see that it
> doesn't make sense to support an ABI that was there for compatibility
> with IRIX 5 and earlier (which we're declaring obselete).  On the other,
> I think o32 worked better with the GNU linker than it did with the
> SGI linker.  E.g. I remember hitting GOT overflow problems with the
> SGI o32 linker (which didn't support multiple GOTs) that were solved
> by using the GNU linker.

Indeed: although I was in direct contact with SGI's Dave Anderson about
this issue, we couldn't find a resolution back then, and the linker guys
were too busy to investigate themselves.  I haven't tried GNU ld on IRIX
in quite some time, though, but am often wary to use in rather than the
vendor ld since sometimes one loses features not supported by GNU ld, or
GNU ld produces binaries the vendor rld/ld.so cannot handle.

> But that was a long time ago (binutils 2.15?) and I don't know how
> well it works now.  And I still can't see any reason why IRIX 6.5
> users would prefer o32 over n32.  I certainly don't object to
> removing o32 support from the IRIX port.

I had this problem with binutils 2.17 and linking the o32
libgfortran.so, but they vanished with binutils 2.20.  Given the
(Continue reading)

Frank Ch. Eigler | 1 Feb 16:22 2010
Picon

Re: Git mirror needs a run of "git gc"

Florian Weimer <fw <at> deneb.enyo.de> writes:

> Right now, each fresh clone needs to create a compressed pack, which
> takes quite a while.

I ran "git repack -a -d", HTH.

- FChE

Ugo Mezzogori | 1 Feb 18:22 2010
Picon

An information about GIMPLE

My name is Ugo Mezzogori and i am doing my graduation thesis about GCC
architecture.
Can i ask you a few questions?
I know that you rewrote the language Gimple in Tuples instead of trees.
Why did you translare GIMPLE into tuple? which are benefits?
Which is the mechanism?
How do you pass from AST to GENERIC? and GENERIC to GIMPLE?
and GIMPLE to RTL? ecc...
Because, i understood what you did it, but i can not understand to
pass into other language, for example from tree to tuple. Which is the
mechanism?

Thank you very much for your attention.
I'll be looking forward to your answer.

Best regards, Ugo Mezzogori
Undergraduate Computer Science, Univeristy of Bologna.

.um

Ian Lance Taylor | 1 Feb 18:47 2010
Picon

Re: An information about GIMPLE

Ugo Mezzogori <ugo.mezzogori <at> gmail.com> writes:

> I know that you rewrote the language Gimple in Tuples instead of trees.
> Why did you translare GIMPLE into tuple? which are benefits?

GIMPLE uses less memory in the compiler.

> Which is the mechanism?
> How do you pass from AST to GENERIC? and GENERIC to GIMPLE?
> and GIMPLE to RTL? ecc...
> Because, i understood what you did it, but i can not understand to
> pass into other language, for example from tree to tuple. Which is the
> mechanism?

I'm sorry I don't understand the question.  Converting from IR to
another is more or less straightforward.

The C frontend starts with a C frontend specific representation that
is really just GENERIC plus some language-specific tree codes.  The
C++ frontend is similar.  That representation is translated into
GENERIC, then into GIMPLE, then back into GENERIC (don't ask), then
into RTL, and finally the compiler generates assembler.

Ian


Gmane