"Terry Guo" writes:
> make[1]: *** [check-recursive] Error 1
> make[1]: Target `check' not remade because of errors.
> make[1]: Leaving directory
> `/home/build/gcc-4-7-daily-test/build-linux/gcc-final/arm-none-eabi/libstdc+
> +-v3'
> make: *** [check-target-libstdc++-v3] Error 2
> make: Target `
>
> "Terry Guo" writes:
>
> > make[1]: *** [check-recursive] Error 1
> > make[1]: Target `check' not remade because of errors.
> > make[1]: Leaving directory
> > `/home/build/gcc-4-7-daily-test/build-linux/gcc-final/arm-none-
> eabi/libstdc+
> > +-v3'
> > make: *** [check-target-libstdc++-v3] E
Richard Sandiford writes:
>> In fact, the only examples of a pseudo-pseudo copy that won't be
>> eliminated by fwprop et al would be to do with loops and conditionals,
>> and I don't understand why they should be special.
>
> Not just those, because loads, stores, calls, volatiles, etc.,
> can't
"Terry Guo" writes:
> Ah, you are right. I just thought the "make -k" should keep going
It does.
> and omit all the errors.
It reports _all_ (independent) errors, not just the first one.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 4
On Wed, Apr 18, 2012 at 09:36:57AM +0200, Jakub Jelinek wrote:
> I'd like to announce dwz-0.1, a DWARF compression tool I've spent this
> April hacking on. It is currently (see below) written as standalone tool,
> with minimal dependencies (though time hasn't been spent on portability
> yet, so as
We have decided to terminate the thread safety annotation project in
GCC.
The current implementation is in the branch google/main for those
interested in using it. We will not be pursuing a merge into trunk.
Instead, we have started implementing the same functionality in Clang.
I've updated th
On Thu, Apr 19, 2012 at 7:15 AM, Diego Novillo wrote:
>
> We have decided to terminate the thread safety annotation project in
> GCC.
>
> The current implementation is in the branch google/main for those
> interested in using it. We will not be pursuing a merge into trunk.
> Instead, we have star
Following the success of the 2011 meeting, we plan to hold another joint
Mpfr/Mpc developer meeting. Mpfr and Mpc are libraries for real and complex
floating point arithmetic at arbitrary precision with correct rounding of
the result. They are prerequisites for building gcc.
Date
25 June 2012, 14:
The gcc version has been difficult to support and maintain, due mainly
to the fact that the GIMPLE intermediate language was never designed
for static analysis. The abstract syntax tree provided by Clang is an
easier data structure to work with for front-end analyses of this
kind. Moreover, the g
On Thu, Apr 19, 2012 at 8:44 AM, Delesley Hutchins wrote:
> The gcc version has been difficult to support and maintain, due mainly
> to the fact that the GIMPLE intermediate language was never designed
> for static analysis. The abstract syntax tree provided by Clang is an
> easier data structure
On 18/04/12 21:47, Richard Sandiford wrote:
I don't think the idea is that these cases are special in themselves.
What we're looking for are pseudos that _may_ be decomposed into
separate registers. If one of the pseudos in the move is only used in
decomposable contexts (including nonvolatile lo
I can give you detailed technical reasons why GIMPLE was not working
for us if you like, but I'm not sure it would be all that
constructive. We have already made the decision to switch to clang
for annotalysis users within google, for reasons that are only partly
technical. The only reason to sup
On Thu, Apr 19, 2012 at 10:30 AM, Delesley Hutchins wrote:
> I can give you detailed technical reasons why GIMPLE was not working
> for us if you like, but I'm not sure it would be all that
> constructive. We have already made the decision to switch to clang
> for annotalysis users within google,
On 4/19/12 4:14 PM, Andrew Pinski wrote:
How do you know it is a major effort? Has any issues related to
changing Tuple/front-ends AST been raised to the mailing list and
asked for help on how to implement these changes?
The kind of analysis that Annotalysis needs cannot be catered by GIMPLE,
> How do you know it is a major effort?
Changing the intermediate language is *always* a major effort,
especially in a large, complex, and mature compiler. Moreover, it's
not necessarily Gimple itself, it's the way the front-end lowers code
from C++ to Gimple, it's the way in which optimizations a
Diego is right. Clang maintains an accurate C++ AST, and then layers
additional data structures, like the control flow graph, on top of
that, so you don't get the same kind of lowering artifacts that have
plagued the gcc implementation of annotalysis. That architecture
makes Clang a much better p
Snapshot gcc-4.5-20120419 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20120419/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hi,
Under what circumstances does gcc emit a base address selection entry
for a dwarf location list?
I've looked at the code, and think the answer is "never", but perhaps
I'm missing something, and I want to be sure.
Thanks,
Sterling
Delesley Hutchins writes:
> I can give you detailed technical reasons why GIMPLE was not working
> for us if you like, but I'm not sure it would be all that
> constructive.
Why wouldn't it be constructive?
Even if it's impractical for gcc to change to the degree needed to fit
your particular pro
On Thu, Apr 19, 2012 at 04:37:22PM -0700, Sterling Augustine wrote:
> Hi,
>
> Under what circumstances does gcc emit a base address selection entry
> for a dwarf location list?
>
> I've looked at the code, and think the answer is "never", but perhaps
> I'm missing something, and I want to be sure
20 matches
Mail list logo
