Hi,
On Thu, 10 Nov 2011, Steve Ellcey wrote:
> This patch (r181172) has broken my bootstrap of IA64 Linux and I am
> trying to figure out what to do about it.
>
> The failure happens while building libunwind (I did not configure with
> --with-system-libunwind):
>
> /ctires/gcc/nightly/build-ia6
Michael,
This patch (r181172) has broken my bootstrap of IA64 Linux and I am
trying to figure out what to do about it.
The failure happens while building libunwind (I did not configure with
--with-system-libunwind):
/ctires/gcc/nightly/build-ia64-redhat-linux-gnu-trunk/obj_gcc/./gcc/xgcc
-B/cti
On Mon, Nov 7, 2011 at 4:57 PM, Michael Matz wrote:
> Hi,
>
> On Thu, 3 Nov 2011, Richard Guenther wrote:
>
>> Otherwise the patch looks ok, but given the Ada issue let's wait until
>> that is sorted out in some way. That also gives others the chance to
>> comment on the patch.
>
> So, this is wh
Hi,
On Thu, 3 Nov 2011, Richard Guenther wrote:
> Otherwise the patch looks ok, but given the Ada issue let's wait until
> that is sorted out in some way. That also gives others the chance to
> comment on the patch.
So, this is what I came up with. As discussed I didn't do the uintptr_t
cas
On Fri, Nov 04, 2011 at 12:39:47PM +0100, Jakub Jelinek wrote:
> Well, for just the clobber stmts followed by resx that isn't caught in the
> function at least we definitely shouldn't catch it, do nothing and rethrow.
Forgot to mention, I'm not opposing the inclusion of your patch at this
point un
On Thu, Nov 03, 2011 at 02:07:31PM +0100, Michael Matz wrote:
> In this specific case we could notice that resx1 actually is the outermost
> resume, hence only will leave the function and therefore the clobber is
> useless (as in, moving them down actually removes them from the function
> body).
> Note, though, that eventually you'll probably have to link with g++ for
> real anyway, as soon as somebody starts using c++ features in those files.
Given the current pace, probably at the end of the decade, yes. :-)
> Meanwhile I've put the -fno-exceptions flag to real testing, will commit
> i
Hi,
On Thu, 3 Nov 2011, Eric Botcazou wrote:
> > libcpp and libcommon and libcommon-target, the latter are:
> >
> > diagnostic.o pretty-print.o intl.o input.o version.o
> > prefix.o params.o opts.o opts-common.o options.o vec.o hooks.o
> > common/common-targhooks.o
> > -common.o
> >
> > Doesn't r
> libcpp and libcommon and libcommon-target, the latter are:
>
> diagnostic.o pretty-print.o intl.o input.o version.o
> prefix.o params.o opts.o opts-common.o options.o vec.o hooks.o
> common/common-targhooks.o
> -common.o
>
> Doesn't read as if these were good candidates to compile with C only whe
Hi,
On Thu, 3 Nov 2011, Richard Guenther wrote:
> >> If gnattools are built with the C++ compiler they should also link
> >> with the G++ driver, so that's worth fixing anyway I think.
> >
> > gnattools is built with the C compiler, but it reuses a couple of
> > object files of libbackend.a th
Hi,
On Thu, 3 Nov 2011, Jakub Jelinek wrote:
> > It's possible. At expansion time the clobbers expand to nothing, so
> > those regions theoretically are mergeable with outer regions, but we
> > don't have EH cleanups on RTL anymore.
>
> That is unfortunate. Can't EH cleanups be taught about
On Thu, Nov 3, 2011 at 10:23 AM, Eric Botcazou wrote:
>> There is a bug about not using -fexceptions (50857).
>
> Then let's fix it, as you said there "We fail to pass -fno-exceptions
> -fno-rtti
> to g++ for stage2 and stage3 building the host binaries. That leads to
> increased compile-time an
On Thu, Nov 03, 2011 at 12:01:05PM +0100, Michael Matz wrote:
> > Do your artificial EH regions survive into .gcc_except_table,
>
> It's possible. At expansion time the clobbers expand to nothing, so those
> regions theoretically are mergeable with outer regions, but we don't have
> EH cleanups
Hi,
On Thu, 3 Nov 2011, Jakub Jelinek wrote:
> > personality. I'm not sure what the best fix here is. The rest of the
> > compiler uses COMPILER and LINKER make variables that are set
> > correctly depending on bootstrap configuration. But the gnattools
> > Makefile.in doesn't know about th
Hi,
On Thu, 3 Nov 2011, Richard Guenther wrote:
> > + /* Add clobbers for all variables that go out of scope. */
> > + for (t = BIND_EXPR_VARS (bind_expr); t ; t = DECL_CHAIN (t))
> > + {
> > + if (TREE_CODE (t) == VAR_DECL
> > + && !is_global_var (t)
>
> I think you want to u
On Thu, Nov 03, 2011 at 12:15:49AM +0100, Michael Matz wrote:
> And there's also one issue with Ada that I need help with: it doesn't
> build anymore. ;-) Well, the tools don't link when C++ bootstrap is
> active. This is because our whole libbackend is compiled with g++, and
> hence uses the
> There is a bug about not using -fexceptions (50857).
Then let's fix it, as you said there "We fail to pass -fno-exceptions -fno-rtti
to g++ for stage2 and stage3 building the host binaries. That leads to
increased compile-time and possibly runtime." And now that will be worse.
> If gnattool
On Thu, Nov 3, 2011 at 12:15 AM, Michael Matz wrote:
> Hi,
>
> [Eric, see below for an Ada issue]
>
> so, this is a more complete resubmission of an old patch, trying to get it
> into 4.7. In order not to have to rely on TREE_BLOCK of variables to
> determine valid sharing (which never really wor
On Thu, Nov 3, 2011 at 2:10 AM, Eric Botcazou wrote:
>> And there's also one issue with Ada that I need help with: it doesn't
>> build anymore. ;-) Well, the tools don't link when C++ bootstrap is
>> active. This is because our whole libbackend is compiled with g++, and
>> hence uses the gxx_per
> And there's also one issue with Ada that I need help with: it doesn't
> build anymore. ;-) Well, the tools don't link when C++ bootstrap is
> active. This is because our whole libbackend is compiled with g++, and
> hence uses the gxx_personality_v0 routines. But the gnattools are linked
> with
Hi,
[Eric, see below for an Ada issue]
so, this is a more complete resubmission of an old patch, trying to get it
into 4.7. In order not to have to rely on TREE_BLOCK of variables to
determine valid sharing (which never really worked that well when all the
intermediate code movements that cou
21 matches
Mail list logo
