Tom Quarendon wrote:
> If I do this I get std::terminate called from __cxa_throw. Researching
> this it seems that I somehow need to register some exception handling
> tables to correspond to the "magic" function to enable the exception
> handler to allow the exception to propagate through.
Right
Hi,
I have a problem using external variables in the constructor code of my
shared library. The constructor code is an init() function labeled by gcc
__attribute__((constructor)). In that function I make a reference to an
extern variable X provided by the driving app. The problem is that X is not
Hi,
Checkin r139050 broke the build. In the file gcc/toplev.h, the new
declaration pedwarn_at is incomplete, leading to syntax errors.
Sebastian
Index: gcc/toplev.h
===
--- gcc/toplev.h(revision 139053)
+++ gcc/toplev.h
2008/8/13 Sebastian Redl <[EMAIL PROTECTED]>:
> Hi,
>
> Checkin r139050 broke the build. In the file gcc/toplev.h, the new
> declaration pedwarn_at is incomplete, leading to syntax errors.
>
> Sebastian
Apologies, my fault. I messed up a conflict resolution.
Committed as obvious as revision 13905
Can anyone explain the relationship between the current vectorization
optimizations in the gcc trunk compiler and the new -floop-strip-mine,
-floop-interchange and -floop-block loop optimizations? Which takes
precedence and does one set block the other in any way? I would hope
that the new loop
>Can anyone explain the relationship between the current vectorization
> optimizations in the gcc trunk compiler and the new -floop-strip-mine,
> -floop-interchange and -floop-block loop optimizations? Which takes
> precedence and does one set block the other in any way? I would hope
> that the
Dorit,
So it is correct to say that any loop that is vectorized is
removed from consideration for these other loop optimizations?
I ask because I am wondering if I should be testing these new
loop optimizations at -O2 in order to see their full effect
(without vectorization inhibiting their use)
hi,
they should work completely independently from vectorization. It does not
matter if vectorizaton is already run or not, they will apply
if You enable them by flags.
konrad
Hi,
sorry for my top-posting in last e-mail.
> hi,
>
> they should work completely independently from vectorization. It does not
> matter if vectorizaton is already run or not, they will apply
> if You enable them by flags.
>
> konrad
>
>
> Dorit,
> So it is correct to say that any loop that
On Wed, Aug 13, 2008 at 05:33:39PM +0300, Konrad Trifunovic wrote:
> hi,
>
> they should work completely independently from vectorization. It does not
> matter if vectorizaton is already run or not, they will apply
> if You enable them by flags.
>
> konrad
>
Konrad,
So gcc will always perfo
Hi folks.
I'm looking at 3544[123] and 35742, which are all related to
pp_c_expression not handling complex expressions, so we can't display
correct error messages for statement expressions, etc:
({break;})()
The error here is currently:
#'goto_expr' not supported by pp_c_expression#'
On Wed, 13 Aug 2008, Aldy Hernandez wrote:
> It seems to me that the only approach here would be to provide caret
> diagnostics, because reconstructing the original sources from GENERIC
> seems like a loosing proposition.
In some cases the only useful place to find the expression is in the
pre
> "Aldy" == Aldy Hernandez <[EMAIL PROTECTED]> writes:
Aldy> The error here is currently:
Aldy> #'goto_expr' not supported by pp_c_expression#'bug.c: In function 'foo':
Aldy> bug.c:4: error: called object is not a function
Aldy> But, is this slew of work even worth it? I for one think t
> "Tom" == Tom Tromey <[EMAIL PROTECTED]> writes:
Tom> As far as I know nobody is actively working on any of this, though
Tom> Mañuel and I talk about it sporadically.
Crap, I misspelled his name while trying extra to get it right.
Sorry about that.
Tom
Tom Tromey wrote:
Aldy> Are there any thoughts on this (the PRs, the caret diagnostics, plan of
Aldy> attack, etc?).
Caret diagnostics do seem like the way to go.
Yes, I've advocated that for years. People consistently tell me that
EDG's diagnostics are superior to GCC, in part because of E
Per the request in doc/install.texi, I'm reporting a successful build
of gcc 3.4.6. I have not run the tests; I have none of the test
infrastructure tools (dejagnu, tcl, expect) installed, and (unless it
proves to be broken when I try to use it, and maybe not even then) the
tests are nowhere near
> If you're interested in working on this, I think one way to do it
> would be to start with a parser and make sure it always picks the
> proper token from which to extract a location. This is a reasonable
> amount of work, and unfortunately much of it would have to be complete
> before we could e
Snapshot gcc-4.2-20080813 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.2-20080813/
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
Tom> I suspect that there's some work fixing optimization passes. I have
Tom> not looked but I would not be surprised if some of them pick locations
Tom> poorly when rearranging things.
Aldy> But this has nothing to do with error messages. I mean, not initially.
Yeah, it is somewhat indirect.
On Aug 13, 2008, at 12:16 PM, Joseph S. Myers wrote:
On Wed, 13 Aug 2008, Aldy Hernandez wrote:
It seems to me that the only approach here would be to provide caret
diagnostics, because reconstructing the original sources from GENERIC
seems like a loosing proposition.
In some cases the only
20 matches
Mail list logo
