Re: debugging
On Tue, Mar 22, 2011 at 03:29:26PM -0700, Ian Lance Taylor wrote: Mike Stump mikest...@comcast.net writes: So, I was trying to debug some stuff with the top of the tree on a suse linux x86_64 box and got: (gdb) p mode Unhandled dwarf expression opcode 0xf3 which I don't find entertaining. I know I _could_ install a new gdb, and most likely this would fix the problem, but, I don't want to do that right now. I think gcc should avoid codes that gdb doesn't support. I rebuilt with --O0, just to try and avoid the issue, and that didn't work either. :-( At -O0 -g DW_OP_GNU_entry_value isn't emitted, you need var-tracking for it, nothing else creates it. I haven't looked, but you should be able to use, e.g., -gdwarf-2 -gstrict-dwarf. If that doesn't work then something has gone wrong. Even -gdwarf-3 -gstrict-dwarf or -gdwarf-4 -gstrict-dwarf or -fno-var-tracking-assignments will stop emitting them. Alternatively, new enough gdb will ignore them: http://sources.redhat.com/ml/gdb-cvs/2011-03/msg00268.html or alternatively http://sourceware.org/git/?p=archer.git;a=shortlog;h=refs/heads/archer-jankratochvil-entryval is the git branch with gdb support for this, though as I was told it is a GDB 7.4 material rather than 7.3 (the msg00268.html commit is hopefully GDB 7.3 material). Jakub
Re: RFC: Representing vector lane load/store operations
On Tue, Mar 22, 2011 at 8:43 PM, Richard Sandiford rdsandif...@googlemail.com wrote: Richard Guenther richard.guent...@gmail.com writes: Simple. Just make them registers anyway (I did that in the past when working on middle-end arrays). You'd set DECL_GIMPLE_REG_P on the decl. OK, thanks, I'll give that a go. TBH, I'm still hopeful we can do without it, because we do seem to cope quite well as things stand. But I suppose that might not hold true as the examples get more complicated. 4. a vector-of-vectors type Cons * I don't think we want that ;) Yeah :-) __builtin_load_lanes (REF : array N*M of X) returns array N of vector M of X maps to vldN on ARM in practice, the result would be used in assignments of the form: vectorY = ARRAY_REF result, Y __builtin_store_lanes (VECTORS : array N of vector M of X) returns array N*M of X maps to vstN on ARM in practice, the argument would be populated by assignments of the form: ARRAY_REF VECTORS, Y = vectorY __builtin_load_lane (REF : array N of X, VECTORS : array N of vector M of X, LANE : integer) returns array N of vector M of X maps to vldN_lane on ARM __builtin_store_lane (VECTORS : array N of vector M of X, LANE : integer) returns array N of X maps to vstN_lane on ARM __builtin_load_dup (REF : array N of X) returns array N of vector M of X maps to vldN_dup on ARM I've hacked up a prototype of this and it seems to produce good code. What do you think? How do you expect these to be used? That is, would you ever expect components of those large vectors/arrays be used in operations like add, or does the HW provide vector-lane variants for those as well? The individual vectors would be used for add, etc. That's what the ARRAY_REF stuff above is supposed to be getting at. So... Thus, will for (i=0; iN; ++i) X[i] = Y[i] + Z[i]; result in a single add per vector lane load or a single vector lane load for M unrolled instances of (small) vector adds? If the latter then we have to think about indexing the vector lanes as well as allowing partial stores (or have a vector-lane construct operation). Representing vector lanes as automatic memory (with array of vector type) makes things easy, but eventually not very efficient. ...Ira would know best, but I don't think it would be used for this kind of loop. It would be more something like: for (i=0; iN; ++i) X[i] = Y[i].red + Y[i].blue + Y[i].green; (not a realistic example). You'd then have: compoundY = __builtin_load_lanes (Y); red = ARRAY_REF compoundY, 0 green = ARRAY_REF compoundY, 1 blue = ARRAY_REF compoundY, 2 D1 = red + green D2 = D1 + blue MEM_REF X = D2; My understanding is that'd we never do any operations besides ARRAY_REFs on the compound value, and that the individual vectors would be treated pretty much like any other. Ok, I thought it might be used to have a larger vectorization factor for loads and stores, basically make further unrolling cheaper because you don't have to duplicate the loads and stores. I had new tree/stmt codes for array loads/stores for middle-end arrays. Eventually the vector lane support can at least walk in the same direction that middle-end arrays would ;) What's the status of the middle-end array stuff? A quick search showed up your paper, but is it still WIP, or has it already gone in? (Showing my ignorance of tree-level stuff here. :-)) It does sound like it'd be a good fit for these ops. Well, the work is basically suspended (though a lot of middle-end surgery that was required went in) - I was stuck on the necessity to have the Fortran frontend generate these expressions to have testing on real code (rather than constructing examples from my lame C frontend + builtins hack). ISTR porting the patch to tuples, the current patch seems to have two or three places that adjust the middle-end in order to allow aggregate typed SSA names. But as you have partial defs of the vector lane array the simplest approach is probably to not make them a register. Be prepared for some surprises during RTL expansion though ;) Richard. Richard
Re: Using secondary reload to reload CONST_INT?
Georg-Johann Lay a...@gjlay.de writes: 1) The internals just mention TARGET_SECONDARY_RELOAD for REG-MEM and for REG-REG moves, no word about REG-CONST moves. So is using secondary reloads for CONST_INT (or other consts) like outlined above a defined use case I can rely on? Yeah, it should be. Other targets rely on this too. E.g. MIPS allows integers to be stored in FPRs as well as GPRs, but you can't load a symbolic constant directly into an FPR; it has to go through a GPR. 2) The secondary reload hook is always called with regclass = GENERAL_REGS, even in cases where the class is known to be NO_LD_REGS like, e.g. when preparing arguments for a function call. Why this? I would expect to get the smallest available regclass. If a reg lies in LD_REGS, a secondary reload is not needed, but how can I know if class is always GENERAL_REGS? Is it ensured that secondary reload hook gets never called when a constraint alternative matches, like d,i? As far as the last bit goes: once reload has decided that it needs to reload A into B, it's uses the secondary reload hook (and only that hook) to decide whether a secondary reload is needed. The movsi constraints only matter when reloading a pre-reload movsi instruction. I think the reason you only ever see GENERAL_REGS being passed in is because (from a quick look at avr.md) very few non-move patterns use the d and l constraints. They all seem to use the r constraint. Thus reloads from those instructions will use GENERAL_REGS rather than NO_LD_REGS. If you want to make reload use NO_LD_REGS for these GENERAL_REGS reloads, at least when the reloaded value is a constant, then it might be worth defining TARGET_PREFERRED_RELOAD_CLASS. 3) What is the unit of sri-extra_cost? Compared to COST_N_INSNS? Or compared to ? constraint cost? I think it's measured in the same units as REGISTER_MOVE_COST. (2 == a simple register move). Richard
coreutils fails to compile wih GCC 4.6.0-rc2 but compile fine with
I heard you would like to release gtcc4.6.0 next week, so I quickly set up a new pass 1 from LFS. With gcc-4.6-20110205, I Manage to compile coreutils (and almost the all set of ports of NuTyX) but with this version of gcc I get stuck at coreutils in the first pass. May be it's me but I prefer to ask your opignion. Maybe have look at the logs so far: http://kiao.no-ip.info/NuTyX/logs/2011/i686/pass1/17_coreutils.log You can have the all history of what I did so far. For me its very strange, I did change much in the scripts which are doing the job: http://kiao.no-ip.info/NuTyX/git/?p=MakeNuTyX;a=summary Thierry
Re: coreutils fails to compile wih GCC 4.6.0-rc2 but compile fine with
On Wed, Mar 23, 2011 at 10:30:46AM +0100, t...@nutyx.com wrote: I heard you would like to release gtcc4.6.0 next week, so I quickly set up a new pass 1 from LFS. With gcc-4.6-20110205, I Manage to compile coreutils (and almost the all set of ports of NuTyX) but with this version of gcc I get stuck at coreutils in the first pass. May be it's me but I prefer to ask your opignion. Maybe have look at the logs so far: http://kiao.no-ip.info/NuTyX/logs/2011/i686/pass1/17_coreutils.log Tbat's almost certainly a user error. The: ./configure ... --with-gmp-include=/tmp/work/src/coreutils-8.10/gmp configure: WARNING: unrecognized options: --with-gmp-include warning might hint you at the error. If you don't have gmp.h available in standard include paths, it isn't surprising the compilation fails. Nothing to do with gcc. Jakub
Re: Fw: RFC: Representing vector lane load/store operations
...Ira would know best, but I don't think it would be used for this kind of loop. It would be more something like: for (i=0; iN; ++i) X[i] = Y[i].red + Y[i].blue + Y[i].green; (not a realistic example). You'd then have: compoundY = __builtin_load_lanes (Y); red = ARRAY_REF compoundY, 0 green = ARRAY_REF compoundY, 1 blue = ARRAY_REF compoundY, 2 D1 = red + green D2 = D1 + blue MEM_REF X = D2; My understanding is that'd we never do any operations besides ARRAY_REFs on the compound value, and that the individual vectors would be treated pretty much like any other. Ok, I thought it might be used to have a larger vectorization factor for loads and stores, basically make further unrolling cheaper because you don't have to duplicate the loads and stores. Right, we can do that using vld1/vst1 instructions (full load/store with N=1) and operate on up to 4 doubleword vectors in parallel. But at the moment we are concentrating on efficient support of strided memory accesses. Ira
Re: RFC: Representing vector lane load/store operations
Richard Guenther richard.guent...@gmail.com writes: But as you have partial defs of the vector lane array the simplest approach is probably to not make them a register. Be prepared for some surprises during RTL expansion though ;) OK. It's there I'd like to start, specifically with: These arrays of vectors would still need to have a non-BLK mode, so that they can be stored in _rtl_ registers. But we need that anyway for ARM's arm_neon.h; the code that today's GCC produces for the intrinsic functions is very poor. because I'd like to fix the bad code we generate for intrinsics. Thing is, this is going to be another case where the mode of a type depends on the current target. E.g. on ARM, we don't want to use a 24-byte mode for an array of 3 2xSI vectors unless V2SI is also available. Both the mode of the vector type and the mode of the array type will therefore depend on whether Neon is enabled. I know you don't like the way we handle TYPE_MODE for vectors: #define TYPE_MODE(NODE) \ (TREE_CODE (TYPE_CHECK (NODE)) == VECTOR_TYPE \ ? vector_type_mode (NODE) : (NODE)-type.mode) so I'm guessing you wouldn't be too happy to see ARRAY_TYPE popping up there as well. :-) What's the best way of handling this? Richard
Re: Target library disabling at toplevel
Joseph S. Myers jos...@codesourcery.com writes: (And why (CC to maintainer) do some CRIS and MMIX targets list Fortran in unsupported languages? I didn't think the Fortran libraries had any porting issues, unlike Java and Go and Ada.) For the record, builds with mipsisa64-elf fail with: libgfortran/intrinsics/time_1.h:99:1: error: static declaration of ‘localtime_r’ follows non-static declaration newlib/libc/include/time.h:61:12: note: previous declaration of ‘localtime_r’ was here This is a long-standing problem. It got stalled a while ago because of a disagreement (in my eyes anyway) about how libgloss targets should be handled. We started down the path of using -Ttarget.ld, so that they could be treated like other targets. But I preferred (and still prefer) the idea of making libgfortran handle newlib in the same way as libstdc++, or disabling libgfortran if we don't care. I think Rask Ingemann Lambertsen also had a patch that used a config.cache-style approach. Richard
Re: Target library disabling at toplevel
On Tue, Mar 22, 2011 at 6:07 PM, Ian Lance Taylor i...@google.com wrote: Joseph S. Myers jos...@codesourcery.com writes: Why do a great many targets disable libgcj by default in the toplevel configure.ac? I believe that it's just a hack: libgcj doesn't build on the target, but gcc/java does. Disabling libgcj lets the gcc configure/make complete in a natural way. unsupported_languages is a clearly superior approach, but it postdates many of the cases in which libgcj is added to noconfigdirs. In some cases, like for x86_64-w64-mingw (Win64), we can build gcj fine, and we intend to support a java compiler. However, at present, we cannot build libgcj because the boehm-gc in the tree is several years out of date. Once Hans, or someone else with enough skill, updates that, we can turn on libgcj. Until then, we'd like to make sure that building the compiler doesn't break. Given how out of date certain dependencies are for libgcj, I would not be surprised if other targets suffered the same fate.
Re: RFC: Representing vector lane load/store operations
On Wed, Mar 23, 2011 at 11:38 AM, Richard Sandiford richard.sandif...@linaro.org wrote: Richard Guenther richard.guent...@gmail.com writes: But as you have partial defs of the vector lane array the simplest approach is probably to not make them a register. Be prepared for some surprises during RTL expansion though ;) OK. It's there I'd like to start, specifically with: These arrays of vectors would still need to have a non-BLK mode, so that they can be stored in _rtl_ registers. But we need that anyway for ARM's arm_neon.h; the code that today's GCC produces for the intrinsic functions is very poor. because I'd like to fix the bad code we generate for intrinsics. Thing is, this is going to be another case where the mode of a type depends on the current target. E.g. on ARM, we don't want to use a 24-byte mode for an array of 3 2xSI vectors unless V2SI is also available. Both the mode of the vector type and the mode of the array type will therefore depend on whether Neon is enabled. I know you don't like the way we handle TYPE_MODE for vectors: #define TYPE_MODE(NODE) \ (TREE_CODE (TYPE_CHECK (NODE)) == VECTOR_TYPE \ ? vector_type_mode (NODE) : (NODE)-type.mode) so I'm guessing you wouldn't be too happy to see ARRAY_TYPE popping up there as well. :-) What's the best way of handling this? I'd say use either DECL_MODE at the point where we decide on expanding vars (setting it from a target hook), or simply ask such a hook at expansion time. That should have worked for the target atttribute stuff as well instead of dispatching in TYPE_MODE (types are global and TYPE_MODE with the target attribute depends on the context, but decls are local to the declaration context, so the mode persists and is not dependent on the attribute). Might need some surgery in places where we assume TYPE_MODE == DECL_MODE, but I suspect it's mostly around RTL expansion. Richard. Richard
Re: RFC: Representing vector lane load/store operations
Richard Guenther richard.guent...@gmail.com writes:
On Wed, Mar 23, 2011 at 11:38 AM, Richard Sandiford
richard.sandif...@linaro.org wrote:
Richard Guenther richard.guent...@gmail.com writes:
But as you have partial defs of the vector lane array the simplest
approach is probably to not make them a register. Be prepared
for some surprises during RTL expansion though ;)
OK. It's there I'd like to start, specifically with:
These arrays of vectors would still need to have a non-BLK mode,
so that they can be stored in _rtl_ registers. But we need that anyway
for ARM's arm_neon.h; the code that today's GCC produces for the intrinsic
functions is very poor.
because I'd like to fix the bad code we generate for intrinsics.
Thing is, this is going to be another case where the mode of a type
depends on the current target. E.g. on ARM, we don't want to use
a 24-byte mode for an array of 3 2xSI vectors unless V2SI is also
available. Both the mode of the vector type and the mode of the
array type will therefore depend on whether Neon is enabled.
I know you don't like the way we handle TYPE_MODE for vectors:
#define TYPE_MODE(NODE) \
(TREE_CODE (TYPE_CHECK (NODE)) == VECTOR_TYPE \
? vector_type_mode (NODE) : (NODE)-type.mode)
so I'm guessing you wouldn't be too happy to see ARRAY_TYPE popping
up there as well. :-) What's the best way of handling this?
I'd say use either DECL_MODE at the point where we decide on
expanding vars (setting it from a target hook), or simply ask such
a hook at expansion time. That should have worked for the target
atttribute stuff as well instead of dispatching in TYPE_MODE (types
are global and TYPE_MODE with the target attribute depends on
the context, but decls are local to the declaration context, so the
mode persists and is not dependent on the attribute). Might
need some surgery in places where we assume TYPE_MODE == DECL_MODE,
but I suspect it's mostly around RTL expansion.
Hmm, but if we do that, when is it correct to look at TYPE_MODE?
E.g. when expanding the new __builtin_load_lanes function described
earlier, it wouldn't be valid to base the target register's mode on
TYPE_MODE, so I suppose we'd have to call the hook instead. And if we
did revert the TYPE_MODE change for vector types, the vector optabs
would need to do the same thing. Wouldn't we just end up replacing
most/all uses of TYPE_MODE with calls to the hook? What would any
remaining uses of TYPE_MODE actually be testing?
E.g. I suppose we really ought to do the same thing for 128-bit types,
since this:
/* TODO: This isn't correct, but as logic depends at the moment on
host's instead of target's wide-integer.
If there is a target not supporting TImode, but has an 128-bit
integer-scalar register, this target check needs to be adjusted. */
if (targetm.scalar_mode_supported_p (TImode))
{
int128_integer_type_node = make_signed_type (128);
int128_unsigned_type_node = make_unsigned_type (128);
}
seems to apply one value of scalar_mode_supported_p to the whole compilation.
(TImode support seems to depend on TARGET_ZARCH for s390.)
Richard
Re: Cross compiler build instructions - PowerPC
On Wed, 23 Mar 2011, Rohit Arul Raj wrote: Hello All, I have been trying to build a cross compiler (for PowerPC) on x86_64 linux host. I followed the build procedure given in the link below: http://www.eglibc.org/archives/patches/msg00078.html You should be referring to the current checked-in version of this documentation, not a four-year-old draft. However, it doesn't appear to have relevant changes. Maxim, perhaps we should add --disable-decimal-float --disable-libffi --disable-libquadmath to the configure options for the first GCC in EGLIBC.cross-building? -- Joseph S. Myers jos...@codesourcery.com
Re: RFC: Representing vector lane load/store operations
On Wed, Mar 23, 2011 at 1:18 PM, Richard Sandiford
richard.sandif...@linaro.org wrote:
Richard Guenther richard.guent...@gmail.com writes:
On Wed, Mar 23, 2011 at 11:38 AM, Richard Sandiford
richard.sandif...@linaro.org wrote:
Richard Guenther richard.guent...@gmail.com writes:
But as you have partial defs of the vector lane array the simplest
approach is probably to not make them a register. Be prepared
for some surprises during RTL expansion though ;)
OK. It's there I'd like to start, specifically with:
These arrays of vectors would still need to have a non-BLK mode,
so that they can be stored in _rtl_ registers. But we need that anyway
for ARM's arm_neon.h; the code that today's GCC produces for the intrinsic
functions is very poor.
because I'd like to fix the bad code we generate for intrinsics.
Thing is, this is going to be another case where the mode of a type
depends on the current target. E.g. on ARM, we don't want to use
a 24-byte mode for an array of 3 2xSI vectors unless V2SI is also
available. Both the mode of the vector type and the mode of the
array type will therefore depend on whether Neon is enabled.
I know you don't like the way we handle TYPE_MODE for vectors:
#define TYPE_MODE(NODE) \
(TREE_CODE (TYPE_CHECK (NODE)) == VECTOR_TYPE \
? vector_type_mode (NODE) : (NODE)-type.mode)
so I'm guessing you wouldn't be too happy to see ARRAY_TYPE popping
up there as well. :-) What's the best way of handling this?
I'd say use either DECL_MODE at the point where we decide on
expanding vars (setting it from a target hook), or simply ask such
a hook at expansion time. That should have worked for the target
atttribute stuff as well instead of dispatching in TYPE_MODE (types
are global and TYPE_MODE with the target attribute depends on
the context, but decls are local to the declaration context, so the
mode persists and is not dependent on the attribute). Might
need some surgery in places where we assume TYPE_MODE == DECL_MODE,
but I suspect it's mostly around RTL expansion.
Hmm, but if we do that, when is it correct to look at TYPE_MODE?
Most of the tree passes shouldn't care about TYPE_MODE (nor
DECL_MODE) and on RTL we shouldn't need to care about trees.
E.g. when expanding the new __builtin_load_lanes function described
earlier, it wouldn't be valid to base the target register's mode on
TYPE_MODE, so I suppose we'd have to call the hook instead.
Well, you'd expand __builtin_load_lanes only if the mode is available, no?
So you know the mode in advance and don't need to get it from anywhere.
And if we
did revert the TYPE_MODE change for vector types, the vector optabs
would need to do the same thing. Wouldn't we just end up replacing
most/all uses of TYPE_MODE with calls to the hook? What would any
remaining uses of TYPE_MODE actually be testing?
I think a lot of TYPE_MODE users are just lazy, like the optabs should
get a mode input and not use a type - the vectorizer knows what target
support it targets for so it can supply a proper mode. Alternatively
extract the mode from the operands instead, using DECL_MODE.
That said, I think given that target support can change across functions
using something global like TYPE_MODE is fundamentally flawed
(unless you start doing ugly things like that callback in the TYPE_MODE
implementation).
E.g. I suppose we really ought to do the same thing for 128-bit types,
since this:
/* TODO: This isn't correct, but as logic depends at the moment on
host's instead of target's wide-integer.
If there is a target not supporting TImode, but has an 128-bit
integer-scalar register, this target check needs to be adjusted. */
if (targetm.scalar_mode_supported_p (TImode))
{
int128_integer_type_node = make_signed_type (128);
int128_unsigned_type_node = make_unsigned_type (128);
}
seems to apply one value of scalar_mode_supported_p to the whole compilation.
(TImode support seems to depend on TARGET_ZARCH for s390.)
Well, it depends on where int128_integer_type_node is used. I think
if the target with some settings supports TImode then we probably
want to have that type node. At the point the user declares some vars
with it you can error out dependent on local support. At expansion
time you'd need to check whether accesses in a given mode are
really possible and dispatch to BLKmode handling if they are not.
The tree level really doesn't care, and most TYPE_MODE uses there
are bogus - the valid ones want to check targetm._mode_supported_p
instead. During RTL expansion we have to deal with handling modes
we don't support (or ICE, as we do now with a lot of target attribute
uses).
For your case in question the vectorizer would create local vars with
that mode, knowing it is supported, so I don't see big problems for
that particular case.
Richard.
Re: RFC: Representing vector lane load/store operations
Richard Guenther richard.guent...@gmail.com writes:
Hmm, but if we do that, when is it correct to look at TYPE_MODE?
Most of the tree passes shouldn't care about TYPE_MODE (nor
DECL_MODE) and on RTL we shouldn't need to care about trees.
It sounds like you think it would be better to get rid of TYPE_MODE.
I can see why that's appealing, but it also sounds very ambitious :-)
As well as all the uses in the middle-end, targets have (wrongly) tended
to use type modes to define the ABI. It might be quite difficult to
untangle the whole mess now.
Of course, that's also an argument in favour of what you say about
TYPE_MODE not changing unless we can help it...
For your case in question the vectorizer would create local vars with
that mode, knowing it is supported, so I don't see big problems for
that particular case.
The problem is that I'd like to use this for intrinsics as well as for
automatic vectorisation. E.g. I'd like:
typedef struct int8x16x4_t
{
int8x16_t val[4];
} int8x16x4_t;
to have non-BLKmode as well. arm_neon.h uses this type of structure
to represent compounds vectors. But once the type is defined (with Neon
support enabled), there's nothing to stop someone using the type
(not the intrinsics) in a function that has Neon disabled. We mustn't
use the special mode in such cases, because there aren't enough GPRs to
store it. It should be treated as BLKmode instead. Which I suppose
is the same situation as...
E.g. I suppose we really ought to do the same thing for 128-bit types,
since this:
/* TODO: This isn't correct, but as logic depends at the moment on
host's instead of target's wide-integer.
If there is a target not supporting TImode, but has an 128-bit
integer-scalar register, this target check needs to be adjusted. */
if (targetm.scalar_mode_supported_p (TImode))
{
int128_integer_type_node = make_signed_type (128);
int128_unsigned_type_node = make_unsigned_type (128);
}
seems to apply one value of scalar_mode_supported_p to the whole
compilation.
(TImode support seems to depend on TARGET_ZARCH for s390.)
Well, it depends on where int128_integer_type_node is used. I think
if the target with some settings supports TImode then we probably
want to have that type node. At the point the user declares some vars
with it you can error out dependent on local support. At expansion
time you'd need to check whether accesses in a given mode are
really possible and dispatch to BLKmode handling if they are not.
...this. Do you mean that we'd error for local declarations, but fall
back to BLKmode for operations on already-defined (global) declarations?
I'm just worried that might be a bit inconsistent.
Richard
Re: RFC: Representing vector lane load/store operations
On Wed, Mar 23, 2011 at 2:01 PM, Richard Sandiford
richard.sandif...@linaro.org wrote:
Richard Guenther richard.guent...@gmail.com writes:
Hmm, but if we do that, when is it correct to look at TYPE_MODE?
Most of the tree passes shouldn't care about TYPE_MODE (nor
DECL_MODE) and on RTL we shouldn't need to care about trees.
It sounds like you think it would be better to get rid of TYPE_MODE.
I can see why that's appealing, but it also sounds very ambitious :-)
As well as all the uses in the middle-end, targets have (wrongly) tended
to use type modes to define the ABI. It might be quite difficult to
untangle the whole mess now.
Of course, that's also an argument in favour of what you say about
TYPE_MODE not changing unless we can help it...
Indeed.
For your case in question the vectorizer would create local vars with
that mode, knowing it is supported, so I don't see big problems for
that particular case.
The problem is that I'd like to use this for intrinsics as well as for
automatic vectorisation. E.g. I'd like:
typedef struct int8x16x4_t
{
int8x16_t val[4];
} int8x16x4_t;
to have non-BLKmode as well. arm_neon.h uses this type of structure
to represent compounds vectors. But once the type is defined (with Neon
support enabled), there's nothing to stop someone using the type
(not the intrinsics) in a function that has Neon disabled. We mustn't
use the special mode in such cases, because there aren't enough GPRs to
store it. It should be treated as BLKmode instead. Which I suppose
is the same situation as...
I'd use non-BLKmode for the above unconditionally.
E.g. I suppose we really ought to do the same thing for 128-bit types,
since this:
/* TODO: This isn't correct, but as logic depends at the moment on
host's instead of target's wide-integer.
If there is a target not supporting TImode, but has an 128-bit
integer-scalar register, this target check needs to be adjusted. */
if (targetm.scalar_mode_supported_p (TImode))
{
int128_integer_type_node = make_signed_type (128);
int128_unsigned_type_node = make_unsigned_type (128);
}
seems to apply one value of scalar_mode_supported_p to the whole
compilation.
(TImode support seems to depend on TARGET_ZARCH for s390.)
Well, it depends on where int128_integer_type_node is used. I think
if the target with some settings supports TImode then we probably
want to have that type node. At the point the user declares some vars
with it you can error out dependent on local support. At expansion
time you'd need to check whether accesses in a given mode are
really possible and dispatch to BLKmode handling if they are not.
...this. Do you mean that we'd error for local declarations, but fall
back to BLKmode for operations on already-defined (global) declarations?
I'm just worried that might be a bit inconsistent.
I'd say if somebody writes
v4sf float_vec;
void __attribute__((target(no-sse)))
foo (void)
{
float_vec += float_vec;
}
he deserves to get a diagnostic. Thus, even for global decls I think we
can reject such uses. Complication arises whenever we do not see
a decl, like for
void foo(v4sf *x)
{
}
which we could of course reject (at function definition time) if an
unsupported type is used in this way. But the function might
not even dereference that pointer ...
That said, I think for your case in question we should set possible
target attribute issues aside (because we have those issues already).
In that case you wouldn't need to touch TYPE_MODE at all as
it would have non-BLKmode as soon as you create a vector-lane
type or decl?
And I still think that only changing DECL_MODEs based on
target attributes and not TYPE_MODEs is appealing ;)
Richard.
Re: RFC: Representing vector lane load/store operations
Richard Guenther richard.guent...@gmail.com writes:
For your case in question the vectorizer would create local vars with
that mode, knowing it is supported, so I don't see big problems for
that particular case.
The problem is that I'd like to use this for intrinsics as well as for
automatic vectorisation. E.g. I'd like:
typedef struct int8x16x4_t
{
int8x16_t val[4];
} int8x16x4_t;
to have non-BLKmode as well. arm_neon.h uses this type of structure
to represent compounds vectors. But once the type is defined (with Neon
support enabled), there's nothing to stop someone using the type
(not the intrinsics) in a function that has Neon disabled. We mustn't
use the special mode in such cases, because there aren't enough GPRs to
store it. It should be treated as BLKmode instead. Which I suppose
is the same situation as...
I'd use non-BLKmode for the above unconditionally.
But without Neon, there aren't enough registers to store the structure.
Any use of the Neon mode would just lead to a reload failure. Even if
we think it's not sensible to use the type without Neon, we need a better
diagnostic than that.
So I think this mode has to be conditional in exactly the way that
vector modes are, or be subject to the same diagnostics that you
were suggesting for 128-bit types.
I was actually thinking along the lines of having a target hook such as:
array_mode_supported_p (tree elemtype, unsigned HOST_WIDE_INT size)
which would return true if ELEMTYPE[SIZE] should use non-BLKmode where
possible. When it returns true, we'd pass 0 rather than 1 to this
mode_for_size_tree call (from the ARRAY_TYPE case in layout_type):
/* One-element arrays get the component type's mode. */
if (simple_cst_equal (TYPE_SIZE (type),
TYPE_SIZE (TREE_TYPE (type
SET_TYPE_MODE (type, TYPE_MODE (TREE_TYPE (type)));
else
SET_TYPE_MODE (type, mode_for_size_tree (TYPE_SIZE (type),
MODE_INT, 1));
This would have the advantage (as I see it) of working with the
generic vector extensions too. E.g. if a user defines their own
3-element-array-of-vector type, they would benefit from the same
handling as the Neon-specific intrinsics and the vectoriser-generated
arrays.
We still make generic vectors available when there's no underlying
hardware support, so I'd have expected these 3-element-array-of-vector
types to be available too. That's why I prefer the idea of making the
mode conditional, as for vector types, rather than rejecting uses of
the type outright.
But from this:
I'd say if somebody writes
v4sf float_vec;
void __attribute__((target(no-sse)))
foo (void)
{
float_vec += float_vec;
}
he deserves to get a diagnostic. Thus, even for global decls I think we
can reject such uses. Complication arises whenever we do not see
a decl, like for
void foo(v4sf *x)
{
}
which we could of course reject (at function definition time) if an
unsupported type is used in this way. But the function might
not even dereference that pointer ...
it sounds like you think there's no point supporting generic vectors
when no underlying hardware support is available.
And I still think that only changing DECL_MODEs based on
target attributes and not TYPE_MODEs is appealing ;)
Understood. I just think that, if we do that, we really should
get rid of TYPE_MODE (as a global property) as well, otherwise there'd
be even more chaos than there is now. And that sounds like it could
be several months' work in itself.
Richard
Re: RFC: Representing vector lane load/store operations
On Wed, Mar 23, 2011 at 3:13 PM, Richard Sandiford
richard.sandif...@linaro.org wrote:
Richard Guenther richard.guent...@gmail.com writes:
For your case in question the vectorizer would create local vars with
that mode, knowing it is supported, so I don't see big problems for
that particular case.
The problem is that I'd like to use this for intrinsics as well as for
automatic vectorisation. E.g. I'd like:
typedef struct int8x16x4_t
{
int8x16_t val[4];
} int8x16x4_t;
to have non-BLKmode as well. arm_neon.h uses this type of structure
to represent compounds vectors. But once the type is defined (with Neon
support enabled), there's nothing to stop someone using the type
(not the intrinsics) in a function that has Neon disabled. We mustn't
use the special mode in such cases, because there aren't enough GPRs to
store it. It should be treated as BLKmode instead. Which I suppose
is the same situation as...
I'd use non-BLKmode for the above unconditionally.
But without Neon, there aren't enough registers to store the structure.
Any use of the Neon mode would just lead to a reload failure. Even if
we think it's not sensible to use the type without Neon, we need a better
diagnostic than that.
So I think this mode has to be conditional in exactly the way that
vector modes are, or be subject to the same diagnostics that you
were suggesting for 128-bit types.
I was actually thinking along the lines of having a target hook such as:
array_mode_supported_p (tree elemtype, unsigned HOST_WIDE_INT size)
which would return true if ELEMTYPE[SIZE] should use non-BLKmode where
possible. When it returns true, we'd pass 0 rather than 1 to this
mode_for_size_tree call (from the ARRAY_TYPE case in layout_type):
/* One-element arrays get the component type's mode. */
if (simple_cst_equal (TYPE_SIZE (type),
TYPE_SIZE (TREE_TYPE (type
SET_TYPE_MODE (type, TYPE_MODE (TREE_TYPE (type)));
else
SET_TYPE_MODE (type, mode_for_size_tree (TYPE_SIZE (type),
MODE_INT, 1));
This would have the advantage (as I see it) of working with the
generic vector extensions too. E.g. if a user defines their own
3-element-array-of-vector type, they would benefit from the same
handling as the Neon-specific intrinsics and the vectoriser-generated
arrays.
So the 3-element-array-of-vector type has the vector mode of a single
element? I'm confused. I also don't see how a user could want to
have a non-BLK mode on such array types (consider them being
part of a struct - how would that affect argument passing and other
ABI details?).
We still make generic vectors available when there's no underlying
hardware support, so I'd have expected these 3-element-array-of-vector
types to be available too. That's why I prefer the idea of making the
mode conditional, as for vector types, rather than rejecting uses of
the type outright.
But from this:
I'd say if somebody writes
v4sf float_vec;
void __attribute__((target(no-sse)))
foo (void)
{
float_vec += float_vec;
}
he deserves to get a diagnostic. Thus, even for global decls I think we
can reject such uses. Complication arises whenever we do not see
a decl, like for
void foo(v4sf *x)
{
}
which we could of course reject (at function definition time) if an
unsupported type is used in this way. But the function might
not even dereference that pointer ...
it sounds like you think there's no point supporting generic vectors
when no underlying hardware support is available.
Well, I meant if the user compiles with -msse, declares such a
global var (which means it gets V4SFmode and not BLKmode)
and then uses it in a function where he explicitly disables SSE
then something is wrong. If he declares a BLKmode global
then generic vector support will happily trigger and make it work.
I realize this is all a bit tricky and probably nobody properly designed
the target attribute stuff with all these details in mind. But now
we have to live with it ... :(
And I still think that only changing DECL_MODEs based on
target attributes and not TYPE_MODEs is appealing ;)
Understood. I just think that, if we do that, we really should
get rid of TYPE_MODE (as a global property) as well, otherwise there'd
be even more chaos than there is now. And that sounds like it could
be several months' work in itself.
True. But I like the idea of TYPE_MODE becoming even more dynamic
even less.
If it's just three element array-of-vector types you need why not expose
it via attribute((mode(xyz))) only? You could alias that mode to BLKmode
if neon is not enabled ...
Richard.
Re: RFC: Representing vector lane load/store operations
Richard Guenther richard.guent...@gmail.com writes:
On Wed, Mar 23, 2011 at 3:13 PM, Richard Sandiford
richard.sandif...@linaro.org wrote:
Richard Guenther richard.guent...@gmail.com writes:
For your case in question the vectorizer would create local vars with
that mode, knowing it is supported, so I don't see big problems for
that particular case.
The problem is that I'd like to use this for intrinsics as well as for
automatic vectorisation. E.g. I'd like:
typedef struct int8x16x4_t
{
int8x16_t val[4];
} int8x16x4_t;
to have non-BLKmode as well. arm_neon.h uses this type of structure
to represent compounds vectors. But once the type is defined (with Neon
support enabled), there's nothing to stop someone using the type
(not the intrinsics) in a function that has Neon disabled. We mustn't
use the special mode in such cases, because there aren't enough GPRs to
store it. It should be treated as BLKmode instead. Which I suppose
is the same situation as...
I'd use non-BLKmode for the above unconditionally.
But without Neon, there aren't enough registers to store the structure.
Any use of the Neon mode would just lead to a reload failure. Even if
we think it's not sensible to use the type without Neon, we need a better
diagnostic than that.
So I think this mode has to be conditional in exactly the way that
vector modes are, or be subject to the same diagnostics that you
were suggesting for 128-bit types.
I was actually thinking along the lines of having a target hook such as:
array_mode_supported_p (tree elemtype, unsigned HOST_WIDE_INT size)
which would return true if ELEMTYPE[SIZE] should use non-BLKmode where
possible. When it returns true, we'd pass 0 rather than 1 to this
mode_for_size_tree call (from the ARRAY_TYPE case in layout_type):
/* One-element arrays get the component type's mode. */
if (simple_cst_equal (TYPE_SIZE (type),
TYPE_SIZE (TREE_TYPE (type
SET_TYPE_MODE (type, TYPE_MODE (TREE_TYPE (type)));
else
SET_TYPE_MODE (type, mode_for_size_tree (TYPE_SIZE (type),
MODE_INT, 1));
This would have the advantage (as I see it) of working with the
generic vector extensions too. E.g. if a user defines their own
3-element-array-of-vector type, they would benefit from the same
handling as the Neon-specific intrinsics and the vectoriser-generated
arrays.
So the 3-element-array-of-vector type has the vector mode of a single
element?
No, it has a wider, non-vector mode. At the moment, ARM uses integer
modes for this, and after trying a few variations, I think that's
actually the best compromise. So the uint8x16x4_t ought to have a
64-byte integer type(!), which ARM defines as XImode:
INT_MODE (XI, 64);
I also don't see how a user could want to have a non-BLK mode on such
array types (consider them being part of a struct - how would that
affect argument passing and other ABI details?).
The point is that we shouldn't use the mode for the ABI anyway. Even the
intrinsic-defined types (like uint8x16x4_t above) should be passed in
the same way as BLKmode structures would.
I'd say if somebody writes
v4sf float_vec;
void __attribute__((target(no-sse)))
foo (void)
{
float_vec += float_vec;
}
he deserves to get a diagnostic. Thus, even for global decls I think we
can reject such uses. Complication arises whenever we do not see
a decl, like for
void foo(v4sf *x)
{
}
which we could of course reject (at function definition time) if an
unsupported type is used in this way. But the function might
not even dereference that pointer ...
it sounds like you think there's no point supporting generic vectors
when no underlying hardware support is available.
Well, I meant if the user compiles with -msse, declares such a
global var (which means it gets V4SFmode and not BLKmode)
and then uses it in a function where he explicitly disables SSE
then something is wrong. If he declares a BLKmode global
then generic vector support will happily trigger and make it work.
Ah, OK. I'm just not sure whether, to take a MIPS example,
MIPS16 functions in a -mno-mips16 compile should behave
differently from unannotated functions in a -mips16 compile.
If it's just three element array-of-vector types you need why not expose
it via attribute((mode(xyz))) only? You could alias that mode to BLKmode
if neon is not enabled ...
I don't think that really changes anything. Getting the non-BLK mode
on the array type seems like the easy part. The difficult part is
dealing with the fallout when the array is defined in a Neon context
and used in a non-Neon context.
Richard
[pph] Adapting LTO streaming for front end AST saving
Over at the PPH branch we are starting to re-use the LTO streaming routines to save front end trees. Clearly, there are things that need to be extended and/or replaced since LTO streaming assumes that we are in GIMPLE. However, there is a large intersection that I think can be commoned out. - ASTs do not need to concern themselves with language differences. They are generated and consumed by cc1plus, so saving language-dependent information is fine. - LTO streaming has several checks and assumptions that prevent non-gimple trees (e.g., DECL_SAVED_TREE must be NULL). I'm looking for opinions on what would be the best approach to factor out the common code. So far, I have created a layer of routines and data structures that the front end calls to manipulate PPH files. These are wrappers on top of LTO streaming that deal with all the sections, buffers and streams used by LTO. I was thinking of using langhooks to do things like checks (like the check for DECL_SAVED_TREE in lto_output_ts_decl_non_common_tree_pointers or the asserts in lto_get_common_nodes). I'm expecting that there will be other things, like handling more tree nodes in the tree streaming routines. But everything else seems to be already sufficiently flexible for our needs. Thoughts? Thanks. Diego.
Re: [pph] Adapting LTO streaming for front end AST saving
On Wed, 23 Mar 2011, Diego Novillo wrote: Over at the PPH branch we are starting to re-use the LTO streaming routines to save front end trees. Clearly, there are things that need to be extended and/or replaced since LTO streaming assumes that we are in GIMPLE. However, there is a large intersection that I think can be commoned out. - ASTs do not need to concern themselves with language differences. They are generated and consumed by cc1plus, so saving language-dependent information is fine. - LTO streaming has several checks and assumptions that prevent non-gimple trees (e.g., DECL_SAVED_TREE must be NULL). I'm looking for opinions on what would be the best approach to factor out the common code. So far, I have created a layer of routines and data structures that the front end calls to manipulate PPH files. These are wrappers on top of LTO streaming that deal with all the sections, buffers and streams used by LTO. I was thinking of using langhooks to do things like checks (like the check for DECL_SAVED_TREE in lto_output_ts_decl_non_common_tree_pointers or the asserts in lto_get_common_nodes). I'm expecting that there will be other things, like handling more tree nodes in the tree streaming routines. But everything else seems to be already sufficiently flexible for our needs. Thoughts? Yes, Micha has a load of patches cleaning up streaming and removing unecessary abstraction. So, why'd you need to share any of it? I think it would be much easier if you worked with a copy (ugh, streaming trees again). Richard.
Re: [pph] Adapting LTO streaming for front end AST saving
On Wed, Mar 23, 2011 at 10:53, Richard Guenther rguent...@suse.de wrote: Yes, Micha has a load of patches cleaning up streaming and removing unecessary abstraction. So, why'd you need to share any of it? Removing unnecessary abstraction is fine. But there is a bunch of code that will be common, in particular: building string index tables, symbol tables (the decl index), reading/writing hooks to use other file formats (pph are not elf files) and basic trees (particularly, decls, constants, expressions). We could add anything that is specific to the front end we can add with callbacks. But duplicating all that common code seems wasteful. Diego.
Re: [pph] Adapting LTO streaming for front end AST saving
On Wed, 23 Mar 2011, Diego Novillo wrote: Over at the PPH branch we are starting to re-use the LTO streaming routines to save front end trees. Clearly, there are things that need to be extended and/or replaced since LTO streaming assumes that we are in GIMPLE. However, there is a large intersection that I think can be commoned out. - ASTs do not need to concern themselves with language differences. They are generated and consumed by cc1plus, so saving language-dependent information is fine. - LTO streaming has several checks and assumptions that prevent non-gimple trees (e.g., DECL_SAVED_TREE must be NULL). I'm looking for opinions on what would be the best approach to factor out the common code. So far, I have created a layer of routines and data structures that the front end calls to manipulate PPH files. These are wrappers on top of LTO streaming that deal with all the sections, buffers and streams used by LTO. I was thinking of using langhooks to do things like checks (like the check for DECL_SAVED_TREE in lto_output_ts_decl_non_common_tree_pointers or the asserts in lto_get_common_nodes). I'm expecting that there will be other things, like handling more tree nodes in the tree streaming routines. But everything else seems to be already sufficiently flexible for our needs. Thoughts? Yes, Micha has a load of patches cleaning up streaming and removing unecessary abstraction. So, why'd you need to share any of it? I Cool, I also have some. think it would be much easier if you worked with a copy (ugh, streaming trees again). I also think using same machinery for FE/gimple is a mistake. Trees are making life hard since they are interface in between FE-gimplifier, part of gimple, interface for RTL expansion and way we represent debug info. Those are not neccesarily related things and tying them together makes things harder to optimize cleanup. I would rather see well define Gimple bitcode rather than designing common format to handle PCHs, LTO and external templates on the top of existing trees. Honza Richard.
Re: [pph] Adapting LTO streaming for front end AST saving
On Wed, Mar 23, 2011 at 12:38, Jan Hubicka hubi...@ucw.cz wrote: think it would be much easier if you worked with a copy (ugh, streaming trees again). I also think using same machinery for FE/gimple is a mistake. Trees are making life hard since they are interface in between FE-gimplifier, part of gimple, interface for RTL expansion and way we represent debug info. Yes, but this is only part of the common machinery. I'm actually more interested in the other functionality. Keeping string tables, symbol tables, file sections, ability to stream shared pointers by creating references, etc. As gimple gets rid of trees, we can transition that code into the front end. The common code that remains, we can add hooks so each user implements its own functionality. Those are not neccesarily related things and tying them together makes things harder to optimize cleanup. No, that's not the intent. I simply want to re-use common code. We will have streamers for debug info, and passes have their own streamers. PPH is adding another streamer in the front end. All I'm looking for is to have a set of common streaming code I can use. I would rather see well define Gimple bitcode rather than designing common format to handle PCHs, LTO and external templates on the top of existing trees. In as much as gimple is still using tree codes, those would remain in common code. As gimple gets rid of trees, we handle those in the front end. So, I don't think that will be a problem. Diego.
Re: Target library disabling at toplevel
On 03/22/2011 08:51 PM, Joseph S. Myers wrote: Why do a great many targets disable libgcj by default in the toplevel configure.ac? Because that dates to before 2004, which IIRC is when toplevel configure.ac started looking at config-lang.in files. Paolo
Re: debugging
On Wed, 23 Mar 2011 08:51:25 +0100, Jakub Jelinek wrote: http://sourceware.org/git/?p=archer.git;a=shortlog;h=refs/heads/archer-jankratochvil-entryval is the git branch with gdb support for this, though as I was told it is a GDB 7.4 material rather than 7.3 (the msg00268.html commit is hopefully GDB 7.3 material). Yes it is on HEAD, 7.3 is not yet branched, gdb-7.3 will consider 0xf3 as standard optimized out (like before the gcc patch). Discussed at: [patch] [entryval] fixup: Unhandled dwarf expression opcode 0xf3 http://sourceware.org/ml/gdb-patches/2011-03/msg00965.html GDB is now in something like stage 3 for gdb-7.3. The full support from archer-jankratochvil-entryval will go in GDB HEAD after 7.3 gets branched/released. Thanks, Jan
Re: [pph] Adapting LTO streaming for front end AST saving
This thread spilled into IRC chatter. I think we stopped talking past each other now: (2011-03-23 12:51:34) froydnj: dnovillo: gimple gets rid of trees? how does that work? (2011-03-23 12:52:29) dnovillo: froydnj: we've been talking about tuplifying more, but i don't think it makes sense past certain point (say, _CST, IDENTIFIERS, DECLs, etc) (2011-03-23 12:53:05) dnovillo: i wasn't clear in my initial message, i think that's what confused honza and richi (2011-03-23 12:58:26) honza: dnovillo: What would be really nice to have is an sane (from middle end POV) type representation. Tree types makes life quite hard, especially at WPA time. (2011-03-23 12:58:35) honza: because they tie way too many things together (2011-03-23 12:59:03) honza: but indeed gimplified/tuplified types are quite intrusive change. (2011-03-23 12:59:18) dnovillo: honza: agreed. but i want to make sure my point is clear. i want to reuse common streaming code. it's more than just pickling trees. (2011-03-23 13:00:06) dnovillo: honza: there will be things we will never change out of trees, so that will stay in common code. if/when we start getting rid of trees in gimple, it will make sense to take that code out of lto-streamer*.c and move it into tree-streamer*c or some such. (2011-03-23 13:00:30) dnovillo: does that clarify things? (2011-03-23 13:02:53) honza: dnovillo: Well, I am trying to get cleaner idea where we want to go with streaming WRT LTO and WPA in longer term. It is obvious that gread deal of ineffecitvity coes from fact that we stream blindly all the data we currently have in our tree nodes = a lot of things that is never really used in middle-end. (2011-03-23 13:03:34) honza: plus I really think we want defined bytecode in longer run and trees makes this hard too. (2011-03-23 13:03:35) matz: honza: I'm currently working quite hard to do merging while reading in the global state, and to reduce the stuff we have to put into global state. (2011-03-23 13:03:44) dnovillo: honza: sure. and we want to get rid of as much as we can there. (2011-03-23 13:04:06) matz: But now the IPA passes are quite a road-block :/ (2011-03-23 13:04:17) dnovillo: honza: but i don't want to simply toss out that pickling code. i want to move it to tree-streamer* (2011-03-23 13:04:18) honza: matz: Why? (2011-03-23 13:04:38) dnovillo: honza: so that we can use from FEs that want to pickle trees. (2011-03-23 13:04:40) matz: honza: I managed to get quite far with merging symbols before reading in the cgraph. (2011-03-23 13:04:58) honza: matz: and now you need to merge summaries, I see ;) (2011-03-23 13:05:19) matz: honza: Exactly. And the info in those summaries is currently not always self-contained. (2011-03-23 13:05:59) honza: dnovillo: hmm, I really don't know here. On one hand clearly I would like to see more separation of gimple and frontend ASTs. on the other side with current state of affairs I see that not sharing streamer code is just impractical code duplication... (2011-03-23 13:06:02) matz: honza: For instance the ipa-prop info doesn't stream out the number of params, and also depends on the callee list at stream-in to be exactly as when streaming out. (2011-03-23 13:06:24) dnovillo: honza: now you lost me. what? (2011-03-23 13:08:11) honza: dnovillo: for LTO it makes a lot sense when the way you stream function bodies is well defined VM (well, like LLVM). We can't reach this when we will just keep saving our trees without any more strict specification (2011-03-23 13:08:38) honza: for AST in FE you have different requirements, even when they happens to be represented by same tree * structure in GCC. (2011-03-23 13:08:51) dnovillo: honza: sure. i agree with that completely. (2011-03-23 13:09:18) honza: that is flawed design. So i am just concerned that merging the streamer implemetnation still goes indirection of reusing tree for both purposes. (2011-03-23 13:09:55) dnovillo: honza: i am not talking about merging anything. i don't know how to explain this. let me try again. (2011-03-23 13:10:04) dnovillo: honza: there's a bunch of streaming code that has nothing to do with pickling. (2011-03-23 13:10:05) honza: but I guess without going all the way and designing gimple way of implementing tuples/debug info etc. there is not much help. (2011-03-23 13:10:28) dnovillo: honza: that code is commonable and re-usable from various places. (2011-03-23 13:10:30) dnovillo: right? (2011-03-23 13:10:59) honza: OK. Depends on how high level of streaming logic you think of. (2011-03-23 13:11:21) dnovillo: (keeping of string tables, streams, sections, hooks to read/write, etc) (2011-03-23 13:11:35) honza: yep, that is fine for sure. (2011-03-23 13:11:39) dnovillo: honza: the *pickling* code is what you are worried about. (2011-03-23 13:11:50) honza: OK, I guess we are in sync then :0 (2011-03-23 13:12:00) honza: Yes, getting this separated and with clean API is good idea. (2011-03-23 13:12:17) matz: And even the pickling code currently can
-Wconversion is very poor
I've turned on all warnings to have clean program.
Turn on -Wconversion but it will not care about BIG trouble in C++:
conversion.
class A{
public:
A(unsigned int){}
};
class B{
public:
B(A){}
};
B b(-1); //OK without warnings
int main(void){}
-1 = A(FF..FF) = B(FF..FF)
I want to see all program like:
B b(A(-1));
Which warning I must to set?
--
View this message in context:
http://old.nabble.com/-Wconversion-is-very-poor-tp3197p3197.html
Sent from the gcc - Dev mailing list archive at Nabble.com.
Re: -Wconversion is very poor
On 23 March 2011 17:58, Lisp2D wrote:
I've turned on all warnings to have clean program.
Turn on -Wconversion but it will not care about BIG trouble in C++:
conversion.
class A{
public:
A(unsigned int){}
};
class B{
public:
B(A){}
};
B b(-1); //OK without warnings
int main(void){}
-1 = A(FF..FF) = B(FF..FF)
I want to see all program like:
B b(A(-1));
Which warning I must to set?
Your question is inappropriate for this mailing list, questions about
using or building gcc should go to gcc-h...@gcc.gnu.org
Please take any follow up question to that list, thanks.
As clearly documented in the manual, you need -Wsign-conversion in C++
http://gcc.gnu.org/onlinedocs/gcc-4.5.2/gcc/Warning-Options.html#index-Wconversion-368
Re: Pruning for torture tests?
Hi Iain, On Darwin, we have a number of gcc.c-torture fails reported for both ppc and i386 which are bogus (nothing to do with gcc - but simply warning output from a system tool). For dg-based tests these are pruned - I wonder if it would be worth adding a prune capability to the torture suites? IMO this is the wrong approach. I'd like us to move away from the non-dg testsuites if at all possible. I had a quick look and it seems doable, but a complete cleanup of the testsuites is a giant task ;-) Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Pruning for torture tests?
Hi Rainer, On 23 Mar 2011, at 18:45, Rainer Orth wrote: On Darwin, we have a number of gcc.c-torture fails reported for both ppc and i386 which are bogus (nothing to do with gcc - but simply warning output from a system tool). For dg-based tests these are pruned - I wonder if it would be worth adding a prune capability to the torture suites? IMO this is the wrong approach. I'd like us to move away from the non-dg testsuites if at all possible. I personally agree... ... but when I suggested this for the (relatively small) ObjC set of torture tests, it was not greeted enthusiastically... (the problem voiced, IIRC, is of maintaining audit history of test pass/fails) ... I'd imagine that this would be amplified 100x for the other torture suites. Iain
Re: Pruning for torture tests?
Hi Iain, IMO this is the wrong approach. I'd like us to move away from the non-dg testsuites if at all possible. I personally agree... ... but when I suggested this for the (relatively small) ObjC set of torture tests, it was not greeted enthusiastically... (the problem voiced, IIRC, is of maintaining audit history of test pass/fails) indeed, and I wouldn't certainly advocate moving the tests around, just using a different dg-based driver for the torture testsuites. ... I'd imagine that this would be amplified 100x for the other torture suites. This would clearly be unacceptable. Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Pruning for torture tests?
On Wed, 23 Mar 2011, Rainer Orth wrote: indeed, and I wouldn't certainly advocate moving the tests around, just using a different dg-based driver for the torture testsuites. gcc.c-torture/compile.exp was moved to using the dg driver a long time ago, moving the others (so that .x files are no longer needed, and so that people don't get confused and add dg- directives to individual tests that have no effect - PR 20567) certainly seems like a good idea. -- Joseph S. Myers jos...@codesourcery.com
[Bug c++/48247] New: Options -std=gnu++0x -pedantic -Werror produce [-Werror=edantic]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48247
Summary: Options -std=gnu++0x -pedantic -Werror produce
[-Werror=edantic]
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: denis.excoff...@airbus.com
I use GCC 4.6.0 RC 20110314 or 20110321.
% cat foo.cc
#include cstdio
//
int main() {
//
printf(hello world!\n);
};
% gcc -O -o foo -std=gnu++0x -pedantic -Werror foo.cc
foo.cc:7:2: error: extra ';' [-Werror=edantic]
cc1plus: all warnings being treated as errors
%
Should be [-Werror=pedantic] at least.
[Bug c++/48247] Options -std=gnu++0x -pedantic -Werror produce [-Werror=edantic]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48247 --- Comment #1 from Denis Excoffier Denis.Excoffier at airbus dot com 2011-03-23 06:57:23 UTC --- Okay, see also PR44774. Sorry for the noise.
[Bug c++/45437] Loses reference during update
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45437
Patrick Horgan phorgan1 at gmail dot com changed:
What|Removed |Added
CC||phorgan1 at gmail dot com
--- Comment #16 from Patrick Horgan phorgan1 at gmail dot com 2011-03-23
07:03:09 UTC ---
Confirming that this is still occurring in gcc (GCC) 4.6.0 20110113
(experimental) where this code:
int
main()
{
bool b1, b2, b3;
b1 = b2 = b3 = true;
b1 |= b2 |= b1 |=b3;
}
results in the error message:
testit.cpp:10:24: warning: operation on ‘b1’ may be undefined
[-Wsequence-point]
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #11 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-03-23 07:46:49 UTC --- (In reply to comment #10) IZ81343 (or one of its sister APARs) fixes the original issue. But, it leaves a new issue. The new error looks like: Perry, have you seen this on AIX 5.3 or 6.1 ?
[Bug c++/48196] [C++0x] ICE on inclusion of utility, decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48196 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-23 08:43:48 UTC --- Can you try either current mainline or 4_6-branch (would be 4.6.0), because quite a few fixes went into those and if the issue isn't a regression and affects only older branches is very unlikely to be fixed.
[Bug preprocessor/48248] New: Wrong error message location when compiling preprocessed code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48248
Summary: Wrong error message location when compiling
preprocessed code
Product: gcc
Version: 4.5.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: preprocessor
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joerg.rich...@pdv-fs.de
$ cat foobar.h EOF
enum Foo
{
BAR
};
#define BAR(x)
#define BARBAR BAR
EOF
$ cat main.cc EOF
#include foobar.h
void func()
{
(void)BARBAR;
aaa;
}
EOF
$ g++ -c main.cc
main.cc: In function 'void func()':
main.cc:8:3: error: 'aaa' was not declared in this scope
$ g++ -E main.cc main.ii
$ g++ -c main.ii
foobar.h: In function 'void func()':
foobar.h:8:3: error: 'aaa' was not declared in this scope
Please notice the wrong filename when compiling the preprocessed source.
GCC 4.4 doesn't have this problem.
[Bug c++/48247] Options -std=gnu++0x -pedantic -Werror produce [-Werror=edantic]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48247 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-23 09:04:48 UTC --- dup *** This bug has been marked as a duplicate of bug 44774 ***
[Bug c/44774] -Werror=edantic
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44774 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added CC||Denis.Excoffier at airbus ||dot com --- Comment #13 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-23 09:04:48 UTC --- *** Bug 48247 has been marked as a duplicate of this bug. ***
[Bug target/45233] FAIL: gcc.c-torture/compile/pr44707.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45233 Iain Sandoe iains at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.23 09:26:39 CC||iains at gcc dot gnu.org, ||mrs at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Iain Sandoe iains at gcc dot gnu.org 2011-03-23 09:26:39 UTC --- confirmed for O1 : Apparently, we have concluded that the indirect references are not required when there is a 0 offset for the var. When the offset is non-zero (v.b, v.c, v.d), we correctly construct the indirect ref. for O0, all the references are correctly formed (and there is a corresponding L_w$non_lazy_ptr). --- .text .align2 .globl _foo _foo: stw r31,-4(r1);, mflr r0;, bcl 20,31,L001$pb; L001$pb:; mflr r31;, mtlr r0;, addis r2,r31,ha16(_v-L001$pb);,, la r10,lo16(_v-L001$pb)(r2);,, addis r2,r31,ha16(_w-L001$pb);,, la r11,lo16(_w-L001$pb)(r2);,, addis r2,r31,ha16(L_v$non_lazy_ptr-L001$pb);,, lwz r2,lo16(L_v$non_lazy_ptr-L001$pb)(r2);,, addis r8,r31,ha16(L_v$non_lazy_ptr-L001$pb);,, lwz r8,lo16(L_v$non_lazy_ptr-L001$pb)(r8);,, addis r9,r31,ha16(L_v$non_lazy_ptr-L001$pb);,, lwz r9,lo16(L_v$non_lazy_ptr-L001$pb)(r9);,, ; 12 /Volumes/ScratchCS/gcc-live-trunk/gcc/testsuite/gcc.c-torture/compile/pr44707.c 1 /* 0(r10) 0(r11) 4(r2) 8(r8) 12(r9) */; v.a, w, v.b, v.c, v.d ; 0 2 lwz r31,-4(r1);, blr; .non_lazy_symbol_pointer L_v$non_lazy_ptr: .indirect_symbol _v .long0 .subsections_via_symbols
[Bug debug/48229] DW_TAG_type_unit has no DW_AT_producer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48229 --- Comment #1 from Dodji Seketeli dodji at gcc dot gnu.org 2011-03-23 09:31:08 UTC --- I am not sure to understand why the DW_TAG_type_unit DIE should have a DW_AT_producer attribute. From the DWARF-4 specification, I can't see DW_AT_producer listed as a possible attribute of the DW_TAG_type_unit DIE. AIUI, the DW_AT_producer attribute is meant to be hung off of DW_AT_compile_unit and DW_AT_partial_unit. I guess I am missing something ...
[Bug c++/48224] ERROR: compile in g++ version 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48224 --- Comment #7 from Evgenij evgenij.fokin at gmail dot com 2011-03-23 09:35:29 UTC --- Jonathan, I disagree with you. (In reply to comment #2) The C++ standard library says the effects are undefined if an incomplete type is used as a template argument when instantiating a template component (17.4.3.6p2) Yes, but instantiation made in cxx file where all types completed. In any case workaround have been found. Thank you, Andrew.
[Bug preprocessor/48248] [4.5/4.6/4.7 Regression] Wrong error message location when compiling preprocessed code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48248
Richard Guenther rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.03.23 09:41:27
CC||tromey at gcc dot gnu.org
Target Milestone|--- |4.5.3
Summary|Wrong error message |[4.5/4.6/4.7 Regression]
|location when compiling |Wrong error message
|preprocessed code |location when compiling
||preprocessed code
Ever Confirmed|0 |1
--- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-23
09:41:27 UTC ---
Confirmed.
g++-4.5 -S foo.c -save-temps
foobar.h: In function ‘void func()’:
foobar.h:8:3: error: ‘aaa’ was not declared in this scope
and preprocessed source looks like
# 1 foo.c
# 1 built-in
# 1 command-line
# 1 foo.c
# 1 foobar.h 1
enum Foo
{
BAR
};
# 2 foo.c 2
void func()
{
(void)
# 6 foobar.h
BAR
;
aaa;
}
we miss to switch back to foo.c. 4.4 does not switch to foobar.h at all.
[Bug target/47553] ARM neon vld1q_lane_u8 co. don't accept lanes = 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47553 --- Comment #1 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-03-23 09:57:50 UTC --- Author: rsandifo Date: Wed Mar 23 09:57:26 2011 New Revision: 171344 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171344 Log: gcc/ PR target/47553 * config/arm/predicates.md (neon_lane_number): Accept 0..15. gcc/testsuite/ PR target/47553 * gcc.target/arm/neon-vld-1.c: New test. Added: trunk/gcc/testsuite/gcc.target/arm/neon-vld-1.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/arm/predicates.md trunk/gcc/testsuite/ChangeLog
[Bug lto/48246] ICE in lto_wpa_write_files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48246 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.23 10:00:36 CC||hubicka at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-23 10:00:36 UTC --- Confirmed. An intermediate partition is completely empty (ltrans_partitions[2], after lto_balanced_map (), out of 7 partitions in total). Sorting moves that empty partition last. We do seem to allow a single empty partition (probably for an empty CU): gcc_assert (cgraph_node_set_nonempty_p (set) || varpool_node_set_nonempty_p (vset) || !i); so we could change !i for i == n_sets-1, but I suppose we could arrive with multiple empty partitions here as well. Honza, why do we even care to assert the above if we handle empty partitions just fine (in case of !i)? It looks like some partitioning sanity check to me, not something we should assert on.
[Bug regression/48249] New: gcc-4.6: __builtin___memmove_chk wrong results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48249
Summary: gcc-4.6: __builtin___memmove_chk wrong results
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: regression
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: holger.h...@sap.com
__builtin___memmove_chk produces wrong results if src and dest are
overlapping (gcc-4.6 rev. 171299 and trunk):
this is already wrong (source mm.c):
typedef long unsigned int size_t;
extern __inline __attribute__ ((__always_inline__)) __attribute__
((__artificial__)) void *
__attribute__ ((__nothrow__)) memmove (void *__restrict __dest, __const void
*__restrict __src, size_t __len)
{
return __builtin___memmove_chk (__dest, __src, __len, __builtin_object_size
(__dest, 0));
}
void memmove2 (void *dest, const void *src, size_t n)
{
memmove (dest, src, n);
}
correct test program that triggers wrong results (source m.c):
#include string.h
#include stdio.h
void memmove2 (void *dest, const void *src, size_t n);
int main()
{
char s[50];
strcpy (s, abcdefghijklmnop);
memmove2 (s+2, s, 14);
printf (%s\n, s);
return 0;
}
reproduce (linux, x86_64):
$ gcc-4.6 -O2 -c mm.c -o mm46.o
$ gcc-4.5 -O2 -c mm.c -o mm45.o
gcc-4.6 is wrong:
$ gcc-4.6 m.c mm46.o ./a.out
abababefefijklmn
gcc-4.5 produces correct result:
$ gcc-4.6 m.c mm45.o ./a.out
ababcdefghijklmn
[Bug lto/48200] linking shared library with LTO results in different exported symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Keywords||lto --- Comment #8 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-23 10:06:17 UTC --- (In reply to comment #7) Well, upping it only workarounds the problem and you loose parallelizm linking small files. I did bit of tunning on this compiling one of spec2k benchmarks (twolf?) to get smallest time with the cpus I had (4 if I remember) Well ... I suppose this also heavily depends on your I/O speed. Nevetheless the number _looks_ awfully low compared to those others.
[Bug regression/48249] gcc-4.6: __builtin___memmove_chk wrong results
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48249 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-23 10:12:27 UTC --- This is a bug in glibc that has been fixed (the restrict qualification on the wrapper is obviously wrong).
[Bug target/48239] ARM Thumb: Undefined reference to `__aeabi_lmul'
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48239 Sebastian Huber sebastian.hu...@embedded-brains.de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Sebastian Huber sebastian.hu...@embedded-brains.de 2011-03-23 10:14:01 UTC --- Sorry for the noise, I had to update the gcc/config.gcc with a new line tm_file=$tm_file ../../libgcc/config/arm/bpabi-lib.h in the RTEMS specific ARM part.
[Bug target/47553] ARM neon vld1q_lane_u8 co. don't accept lanes = 8
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47553 --- Comment #2 from rsandifo at gcc dot gnu.org rsandifo at gcc dot gnu.org 2011-03-23 10:17:13 UTC --- Fixed on trunk. Will backport to 4.6.1 and 4.5 once 4.6.0 is released.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 Dr. David Kirkby david.kirkby at onetel dot net changed: What|Removed |Added CC||david.kirkby at onetel dot ||net --- Comment #12 from Dr. David Kirkby david.kirkby at onetel dot net 2011-03-23 10:34:54 UTC --- I'm seeing this error on AIX 5.3. Two GNU projects effected by this are * GNU patch * GSL (GNU Scientific library) In the case of the former, if one configures with CFLAGS =-g0, so not to include debugging information, the problem goes away. So when one compiles GNU patch like this I see: gcc -c -DHAVE_CONFIG_H -Ded_PROGRAM=\/usr/bin/ed\ -I. -I. -g0 quotesys.c But the GSL Scientific library can't be compiled this way, as the users's -g0 gets in before the -g added by GSL, so one see something like: gcc -g0 -g foo.c which means the debugging information is still present.
[Bug c++/48224] ERROR: compile in g++ version 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48224 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-23 10:37:40 UTC --- (In reply to comment #7) Jonathan, I disagree with you. You're welcome to disagree, but you're wrong ;) In your original example the compiler tells you where the template is instantiated: compileError.hxx:11:62: instantiated from here At that point the type is incomplete. The example in comment 3 is also undefined, but compiles anyway. That doesn't make it correct. As I said, undefined means it might work, it might not, you can't rely on any specific behaviour. Compiling with -D_GLIBCXX_CONCEPT_CHECKS turns on C++03 concept checking, which tells you the problem: the concept checks fail for the code in comment 3 because the incomplete type does not meet the requirements of Assignable types (required by 23.1p3 [lib.containers.requirements] in C++03). Without concept checks it compiles OK because you don't do an assignment. In your original example you do an assignment on line 11, which is the point of instantiation that requires 'structure' to be complete.
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245 --- Comment #1 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-23 10:58:36 UTC --- Before revision 171039 the test was unsupported: UNSUPPORTED: /opt/gcc/p_work/gcc/testsuite/gcc.dg/lto/pr46940_0.c because the test for 'check_linker_plugin_available' in /opt/gcc/p_work/gcc/testsuite/lib/target-supports.exp returned gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found while following revision 171039 the same test compiles and executes without error. Which linker do you use, and what's the value of HAVE_LTO_PLUGIN in gcc/auto-host.h? Could you check the gcc/config.log snippet for the linker plugin support test. If, as I assume, you're using the Darwin linker, HAVE_LTO_PLUGIN should be 0 and you should get the following error for the linker_plugin test: gcc: error: -fuse-linker-plugin is not supported in this configuration Rainer
[Bug target/48250] New: ICE in reload_cse_simplify_operands, at postreload.c:403
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48250
Summary: ICE in reload_cse_simplify_operands, at
postreload.c:403
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: a...@gcc.gnu.org
Created attachment 23755
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23755
Reduced testcase.
Using a trunk (svn 171251) compiler, configured for ARMv7-a, I get the
following ICE:
gcc -marm -mfpu=neon -O2 -c lp723185.i
lp723185.i: In function 'foo':
lp723185.i:29:1: error: insn does not satisfy its constraints:
(insn 30 79 31 5 (set (mem/s:DI (plus:SI (reg:SI 3 r3)
(const_int -3 [0xfffd])) [4 unaligned_S_6-u64+0 S8
A64])
(reg:DI 4 r4 [146])) lp723185.i:25 626 {*arm_movdi_vfp}
(nil))
lp723185.i:29:1: internal compiler error: in reload_cse_simplify_operands, at
postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See http://gcc.gnu.org/bugs.html for instructions.
It's possible that this is the same as bug #42949, but I'm not qualified to
judge.
[Bug c++/48224] ERROR: compile in g++ version 4.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48224 --- Comment #9 from Evgenij evgenij.fokin at gmail dot com 2011-03-23 11:09:25 UTC --- (In reply to comment #8) You're welcome to disagree, but you're wrong ;) The man who never made a mistake, never made anything :) Thank you for your quick response.
[Bug debug/48229] DW_TAG_type_unit has no DW_AT_producer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48229
--- Comment #2 from Dodji Seketeli dodji at gcc dot gnu.org 2011-03-23
11:28:28 UTC ---
This is a very lightly tested patch to add the DW_AT_producer
attribute to the DW_TAG_type_unit DIE.
diff --git a/gcc/dwarf2out.c b/gcc/dwarf2out.c
index f62bb48..ff1adc3 100644
--- a/gcc/dwarf2out.c
+++ b/gcc/dwarf2out.c
@@ -6498,6 +6498,7 @@ static inline int local_scope_p (dw_die_ref);
static inline int class_scope_p (dw_die_ref);
static inline int class_or_namespace_scope_p (dw_die_ref);
static void add_type_attribute (dw_die_ref, tree, int, int, dw_die_ref);
+static void add_producer_attribute (dw_die_ref);
static void add_calling_convention_attribute (dw_die_ref, tree);
static const char *type_tag (const_tree);
static tree member_declared_type (const_tree);
@@ -10298,6 +10299,13 @@ break_out_comdat_types (dw_die_ref die)
unit = new_die (DW_TAG_type_unit, NULL, NULL);
add_AT_unsigned (unit, DW_AT_language,
get_AT_unsigned (comp_unit_die (), DW_AT_language));
+
+/* Add a DW_AT_producer attribute. This is not mandated by
+ the DWARF-4 specification. But it appears that GDB needs
+ it for cases where different DW_TAG_type_unit DIEs might
+ be emitted by different compilers. */
+add_producer_attribute (unit);
+
type_node = ggc_alloc_cleared_comdat_type_node ();
type_node-root_die = unit;
type_node-next = comdat_type_list;
@@ -18014,6 +18022,28 @@ add_type_attribute (dw_die_ref object_die, tree type,
int decl_const,
add_AT_die_ref (object_die, DW_AT_type, type_die);
}
+/* Add an DW_AT_producer attribute to a given DIE. */
+
+static void
+add_producer_attribute (dw_die_ref die)
+{
+ char producer[250];
+ const char *language_string = lang_hooks.name;
+
+ sprintf (producer, %s %s, language_string, version_string);
+#ifdef MIPS_DEBUGGING_INFO
+ /* The MIPS/SGI compilers place the 'cc' command line options in the
producer
+ string. The SGI debugger looks for -g, -g1, -g2, or -g3; if they do
+ not appear in the producer string, the debugger reaches the conclusion
+ that the object file is stripped and has no debugging information.
+ To get the MIPS/SGI debugger to believe that there is debugging
+ information in the object file, we add a -g to the producer string. */
+ if (debug_info_level DINFO_LEVEL_TERSE)
+strcat (producer, -g);
+#endif
+ add_AT_string (die, DW_AT_producer, producer);
+}
+
/* Given an object die, add the calling convention attribute for the
function call type. */
static void
@@ -20101,7 +20131,6 @@ static dw_die_ref
gen_compile_unit_die (const char *filename)
{
dw_die_ref die;
- char producer[250];
const char *language_string = lang_hooks.name;
int language;
@@ -20114,21 +20143,8 @@ gen_compile_unit_die (const char *filename)
if (!IS_ABSOLUTE_PATH (filename) filename[0] != '')
add_comp_dir_attribute (die);
}
-
- sprintf (producer, %s %s, language_string, version_string);
-
-#ifdef MIPS_DEBUGGING_INFO
- /* The MIPS/SGI compilers place the 'cc' command line options in the
producer
- string. The SGI debugger looks for -g, -g1, -g2, or -g3; if they do
- not appear in the producer string, the debugger reaches the conclusion
- that the object file is stripped and has no debugging information.
- To get the MIPS/SGI debugger to believe that there is debugging
- information in the object file, we add a -g to the producer string. */
- if (debug_info_level DINFO_LEVEL_TERSE)
-strcat (producer, -g);
-#endif
-
- add_AT_string (die, DW_AT_producer, producer);
+
+ add_producer_attribute (die);
/* If our producer is LTO try to figure out a common language to use
from the global list of translation units. */
[Bug testsuite/48251] New: guality_check hangs indefinitely on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48251 Summary: guality_check hangs indefinitely on Tru64 UNIX Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: testsuite AssignedTo: unassig...@gcc.gnu.org ReportedBy: r...@gcc.gnu.org CC: aol...@gcc.gnu.org Host: alpha-dec-osf5.1b Target: alpha-dec-osf5.1b Build: alpha-dec-osf5.1b The guality_check in g++.dg/guality/guality.exp hangs indefinitely on Tru64 UNIX V5.1B, hanging the whole testsuite run. It seems to be a gdb issue, but still occurs with CVS gdb. Here's what happens when I use a simple looping test program as target of the procedure used in guality.h: gdb -nx -nw --quiet (gdb) set height Argument required (integer to set it to.). (gdb) set height 0 (gdb) attach 216346 Attaching to process 216346 [New process 216346] Retry #1: Retry #2: Retry #3: Retry #4: 0x0001200010e0 in ?? () (gdb) set guality_attached = 1 No symbol table is loaded. Use the file command. (gdb) b 1 No symbol table is loaded. Use the file command. In g++.log, I find that the test is run with the regular timeout of 300 seconds, but this has no effect for some reason. Might be a bug in expect (5.38.2). The guality_check test in gcc.dg/guality/guality.exp isn't affected for some reason. I'll disable the test on Tru64 UNIX until this is resolved. This is somewhat related to PR testsuite/46529, but there the timeout does work.
[Bug testsuite/48251] guality_check hangs indefinitely on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48251 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2011-03-23 11:56:09 UTC --- Author: ro Date: Wed Mar 23 11:55:51 2011 New Revision: 171346 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=171346 Log: PR testsuite/48251 * g++.dg/guality/guality.exp: Disable on alpha*-dec-osf*. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/guality/guality.exp
[Bug debug/48229] DW_TAG_type_unit has no DW_AT_producer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48229 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-23 11:56:05 UTC --- I think it is a bad idea to add DW_AT_producer to .debug_type units. Making each .debug_types addition 4 bytes longer is bad for debug info size, we might have many thousands DW_TAG_type_units for each source. I think you can safely use referring DW_TAG_compile_unit's DW_AT_producer for your purposes. While it is true that .debug_types sections in the end comes from different *.o file and be produced by different compiler, it will be referenced by the current CU only if it hashes the same, thus has the same content (disregarding hash collisions, in which case you are in very bad trouble, but you are in that very bad trouble no matter whether you just want to make sure it was produced by the same or compatible producer - when hash collision happens, it might refer to completely unrelated type).
[Bug c++/48196] [C++0x] ICE on inclusion of utility, decltype
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48196 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Known to work||4.6.0, 4.7.0 Resolution||WORKSFORME --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-03-23 11:58:12 UTC --- Indeed, I just checked and both mainline and 4_6-branch are fine. If you see something different, please re-open.
[Bug testsuite/48251] guality_check hangs indefinitely on Tru64 UNIX
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48251 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.23 12:00:31 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 Known to fail||4.6.0, 4.7.0 --- Comment #2 from Rainer Orth ro at gcc dot gnu.org 2011-03-23 12:00:31 UTC --- Worked around for now.
[Bug lto/47334] g++.dg/torture/pr31863.C -O2 -flto FAILs without visibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47334 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.23 12:15:19 CC||dnovillo at google dot com, ||rguenther at suse dot de Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2011-03-23 12:15:19 UTC --- While I'm considering how to apply the prunes from lto.exp (lto_prune_warns) to tests not yet using lto.exp, I've got a more fundamental question: what's the point of trying to use visibility support on targets that don't support that and later pruning the resulting warning? It seems far more sensible to me not to try this in the first place and thus avoid the resulting mess.
[Bug lto/47334] g++.dg/torture/pr31863.C -O2 -flto FAILs without visibility
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47334 --- Comment #2 from rguenther at suse dot de rguenther at suse dot de 2011-03-23 12:20:39 UTC --- On Wed, 23 Mar 2011, ro at gcc dot gnu.org wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47334 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011.03.23 12:15:19 CC||dnovillo at google dot com, ||rguenther at suse dot de Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 --- Comment #1 from Rainer Orth ro at gcc dot gnu.org 2011-03-23 12:15:19 UTC --- While I'm considering how to apply the prunes from lto.exp (lto_prune_warns) to tests not yet using lto.exp, I've got a more fundamental question: what's the point of trying to use visibility support on targets that don't support that and later pruning the resulting warning? It seems far more sensible to me not to try this in the first place and thus avoid the resulting mess. Of course.
[Bug target/48252] New: problem with consecutive vzip, vuzp and vtrn
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48252
Summary: problem with consecutive vzip, vuzp and vtrn
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: johan.krist...@axis.com
Consecutive vzip, vuzp or vtrn intrinsic overwrite destination register.
Compiler:
gcc -v
Using built-in specs.
COLLECT_GCC=/usr/local/gcc/4.6/bin/gcc
COLLECT_LTO_WRAPPER=/usr/local/gcc/4.6/libexec/gcc/armv7l-unknown-linux-gnueabi/4.6.0/lto-wrapper
Target: armv7l-unknown-linux-gnueabi
Configured with: ../gcc-4.6/configure --prefix=/usr/local/gcc/4.6
--enable-languages=c --with-arch=armv7-a --with-float=softfp
--with-fpu=vfpv3-d16
Thread model: posix
gcc version 4.6.0 20110323 (prerelease) (GCC)
Test case:
#include arm_neon.h
#include stdio.h
int main(void)
{
uint8x8_t v1 = {1, 1, 1, 1, 1, 1, 1, 1};
uint8x8_t v2 = {2, 2, 2, 2, 2, 2, 2, 2};
uint8x8x2_t vd1, vd2;
union {uint8x8_t v; uint8_t buf[8];} d1, d2, d3, d4;
int i;
vd1 = vzip_u8(v1, vdup_n_u8(0));
vd2 = vzip_u8(v2, vdup_n_u8(0));
vst1_u8(d1.buf, vd1.val[0]);
vst1_u8(d2.buf, vd1.val[1]);
vst1_u8(d3.buf, vd2.val[0]);
vst1_u8(d4.buf, vd2.val[1]);
printf( d1 d2 d3 d4\n);
for (i = 0; i 8; i++) {
printf(%4d%4d%4d%4d\n,
d1.buf[i],
d2.buf[i],
d3.buf[i],
d4.buf[i]);
}
return 0;
}
-
Compile flags: -mfloat-abi=softfp -mfpu=neon -O2
Output:
d1 d2 d3 d4
1 1 2 1
0 0 0 0
1 1 2 1
0 0 0 0
1 1 2 1
0 0 0 0
1 1 2 1
0 0 0 0
d4 is wrong.
[Bug debug/48253] New: [4.6/4.7 Regression] Further .debug_aranges issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48253 Summary: [4.6/4.7 Regression] Further .debug_aranges issues Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: debug AssignedTo: ja...@gcc.gnu.org ReportedBy: ja...@gcc.gnu.org CC: tro...@gcc.gnu.org, jan.kratoch...@redhat.com Created attachment 23756 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23756 aranges.c As following testcases show, while PR48176 fixed some .debug_aranges related regressions, with the addition of .text.startup and .text.exit sections we still sometimes don't emit .debug_aranges covering all the code snippets for a particular CU.
[Bug debug/48253] [4.6/4.7 Regression] Further .debug_aranges issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48253 --- Comment #1 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-23 13:01:54 UTC --- Created attachment 23757 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23757 aranges2.c Another testcase, this one needs profile feedback (i.e. run compile/link first with the options and -fprofile-generate, run, compile again with -fprofile-use). On this testcase we can see other bugs, e.g. DW_AT_ranges for f1 DW_TAG_subprogram is wrong, it covers twice the same range, once perhaps with a few extra bytes of padding before it, and then not at all the cold part.
[Bug debug/48229] DW_TAG_type_unit has no DW_AT_producer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48229 --- Comment #4 from Jan Kratochvil jan.kratochvil at redhat dot com 2011-03-23 13:07:02 UTC --- (In reply to comment #3) I think it is a bad idea to add DW_AT_producer to .debug_type units. Making each .debug_types addition 4 bytes longer is bad for debug info size, we might have many thousands DW_TAG_type_units for each source. I think you can safely use referring DW_TAG_compile_unit's DW_AT_producer for your purposes. While it is true that .debug_types sections in the end comes from different *.o file and be produced by different compiler, it will be referenced by the current CU only if it hashes the same, thus has the same content (disregarding hash collisions, in which case you are in very bad trouble, but you are in that very bad trouble no matter whether you just want to make sure it was produced by the same or compatible producer - when hash collision happens, it might refer to completely unrelated type). I guess there cannot be two struct/class definitions with different fields accessibility accidentally matching each other due to ODR. Still I believe DW_TAG_type_unit should have DW_AT_producer as it is a standalone entity - but currently it is not. I guess I have to implement your described althorithm into GDB instead. Dodji, thanks and sorry for the patch.
[Bug lto/48246] ICE in lto_wpa_write_files
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48246 --- Comment #2 from Jan Hubicka hubicka at ucw dot cz 2011-03-23 13:07:58 UTC --- Honza, why do we even care to assert the above if we handle empty partitions just fine (in case of !i)? It looks like some partitioning sanity check to me, not something we should assert on. The reason was that empty partition imply overhead and there is no need for that, so I would preffer partitioning algs to never create the empty parts (there was various issues with partitioning that lead to them). But for release branch, dropping the assert is just fine. Honza
[Bug lto/45375] [meta-bug] Issues with building Mozilla with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45375 --- Comment #60 from Markus Trippelsdorf markus at trippelsdorf dot de 2011-03-23 13:10:50 UTC --- Latest mozilla-central fails here: make[5]: Entering directory `/var/tmp/mozilla-central/moz-build-dir/js/src/shell' js.cpp c++ -o js.o -c -I../../../dist/system_wrappers_js -include /var/tmp/mozilla-central/js/src/config/gcc_hidden.h -DEXPORT_JS_API -DOSTYPE=\Linux2.6\ -DOSARCH=Linux -I/var/tmp/mozilla-central/js/src -I.. -I/var/tmp/mozilla-central/js/src/shell -I. -I../../../dist/include -I../../../dist/include/ns prpub -I/usr/include/nspr-fPIC -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-vir tual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -pedantic -Wno-long-long -march=native -fpermissive -flto=4 -fu se-linker-plugin -fwhole-program -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -g -O3 -DMOZILLA_CLIENT -include ../js-confdefs.h -MD -MF .deps/js.pp /var/tmp/mozilla-central/js/src/shell/js.cpp jsworkers.cpp c++ -o jsworkers.o -c -I../../../dist/system_wrappers_js -include /var/tmp/mozilla-central/js/src/config/gcc_hidden.h -DEXPORT_JS_API -DOSTYPE=\Linux2.6\ -DOSARCH=Linux -I/var/tmp/mozilla-central/js/src -I.. -I/var/tmp/mozilla-central/js/src/shell -I. -I../../../dist/include -I../../../dist/include/nsprpub -I/usr/include/nspr-fPIC -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -pedantic -Wno-long-long -march=native -fpermissive -flto=4 -fuse-linker-plugin -fwhole-program -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -g -O3 -DMOZILLA_CLIENT -include ../js-confdefs.h -MD -MF .deps/jsworkers.pp /var/tmp/mozilla-central/js/src/shell/jsworkers.cpp In file included from /var/tmp/mozilla-central/js/src/shell/js.cpp:97:0: /var/tmp/mozilla-central/js/src/jsobjinlines.h: In member function ‘void JSObject::setArrayLength(uint32)’: /var/tmp/mozilla-central/js/src/jsobjinlines.h:316:24: warning: cast to pointer from integer of different size [-Wint-to-pointer-cast] /usr/bin/python2.7 /var/tmp/mozilla-central/js/src/config/pythonpath.py -I../config /var/tmp/mozilla-central/js/src/config/expandlibs_exec.py --uselist -- c++ -o js -fno-rtti -fno-exceptions -Wall -Wpointer-arith -Woverloaded-virtual -Wsynth -Wno-ctor-dtor-privacy -Wno-non-virtual-dtor -Wcast-align -Wno-invalid-offsetof -Wno-variadic-macros -Werror=return-type -pedantic -Wno-long-long -march=native -fpermissive -flto=4 -fuse-linker-plugin -fwhole-program -fno-strict-aliasing -pthread -pipe -DNDEBUG -DTRIMMED -g -O3 js.o jsworkers.o -lpthread -Wl,-O1,--hash-style=gnu,--as-needed,--no-keep-memory -Wl,-rpath-link,/bin -Wl,-rpath-link,/var/tmp/mozilla-central/moz-build-dir/dist/lib -L../../../dist/bin -L../../../dist/lib -Wl,-R/usr/lib64 -L/usr/lib64 -lplds4 -lplc4 -lnspr4 -lpthread -ldl ../editline/libeditline.a ../libjs_static.a -ldl lto1: internal compiler error: in output_die, at dwarf2out.c:11355 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[6]: *** [/tmp/ccC5KSYt.ltrans18.ltrans.o] Error 1 make[6]: *** Waiting for unfinished jobs lto-wrapper: make returned 2 exit status /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/../../../../x86_64-pc-linux-gnu/bin/ld: fatal error: lto-wrapper failed collect2: ld returned 1 exit status
[Bug lto/48200] linking shared library with LTO results in different exported symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48200 --- Comment #9 from Jan Hubicka hubicka at ucw dot cz 2011-03-23 13:12:37 UTC --- Well ... I suppose this also heavily depends on your I/O speed. Nevetheless the number _looks_ awfully low compared to those others. Well, totally minimizing compilation of small unit is not very worthwhile. It was from time I was trying to stress whopr to get issues like this one soon. It does not matter if we build application in 1/100th of second or 1/200th of second and too much parallelizm could slow down build of many small binaries. I guess we could shoot for resonable user response. UI guys thinks it is about 1/3rd of second, so I would not mind tuning number up until compilation on not terribly high end system approximately gets to this time. I don't think this is however terribly related to large unit sizes and inliner stuff. Honza
[Bug fortran/47571] [4.7 Regression] undefined reference to clock_gettime in Linux build of 02/01/2011
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47571 --- Comment #49 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-23 13:13:53 UTC --- Could we please avoid this mess with SUPPORTS_WEAK and GTHREAD_USE_WEAK and make configure define SUPPORTS_WEAKREF or something like this, since this is what we are actually looking for? The point was to piggyback on the existing weakref support in libgfortran rather than reinvent the wheel, but yeah, it's a bit confusing. ... especially since SUPPORTS_WEAK is unused now outside of intrinsics/system_clock.c. It seems that target backends expose macros with these same names, but they are not visible anymore when compiling libgfortran, hence the current hack trying to recreate them in libgfortran configuration. Or at least, that's the most plausible reason I came up with, I did not write that particular code nor do I claim any deep expertise in this matter. Indeed: I suppose someone saw them in gcc/gthr*.h. It seems like every user of that file needs to recreate those definitions. From what I can see, libquadmath gets this wrong, e.g.: quadmath_weak.h has #if SUPPORTS_WEAK but this isn't defined anywhere ;-( Terrible user interface, btw. If we include alpha*-dec-osf* in the list of targets that don't support weakrefs, things should start working again, but I'd prefer a patch where you can actually read *and understand* what's going on here. Would it be possible to create some test using AC_LINK_IFELSE to check whether weakrefs are supported? That way we could get rid of the ugly One should be able to use gcc/testsuite/gcc.dg/attr-weakref-1.c as basis. blacklist for defining GTHREAD_USE_WEAK. In any case, IMHO that's the topic of a separate patch. Indeed, and the only sensible (read: the autoconf way) approach if feasible. Apart from that, has anyone actually *measured* the overhead of simply linking libgfortran with librt on Linux, rather than claiming that there might be some? It the overhead were acceptable or even neglegible, we could avoid all this mess in the first place, link with -lrt if need be, and be done with it. The overhead is application dependent, and while I suspect that it's negligible for most, it's not that far fetched to imagine an application where it could make a big difference. For instance, the seed of the RANDOM_NUMBER intrinsic is protected by a weakrefed mutex; thus it's easy to imagine a program that makes lots of RANDOM_NUMBER calls becoming a lot slower if every call results in an unecessary mutex lock/unlock. Ok, though it would be useful to have some hard data on this to make an informed decision. Additionally, the usage model for the weakref seems questionable to me: while the technique is well-known and common on ELF targets to produce code that can work with or without libpthread linked into the application (which is what users will actually do!), which user is supposed to link his Fortran code with librt to get improved system clock resolution? I dare say that close to nobody will even think about this. Probably not many. OTOH there are quite many who use OpenMP, and as enabling OpenMP implicitly links in librt, they get the better clock for free. True, but those same users will be mightly confused if the clock resolution suddenly drops without OpenMP ;-( I wonder how we want to continue from here: adding alpha*-dec-osf* to the host list in libgfortran/acinclude.m4 (GTHREAD_USE_WEAK) on top of your patch allowed testing to finish successfully. Should we go this way or apply my workaround from the 4.6 branch to mainline until this is all sorted out properly? Thanks. Rainer
[Bug lto/47333] [4.6 regression] g++.dg/lto/20091219 FAILs on Solaris 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47333 Rainer Orth ro at gcc dot gnu.org changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #10 from Rainer Orth ro at gcc dot gnu.org 2011-03-23 13:23:20 UTC --- Unfortunately, while this works now with gas, it still fails with Sun as, all Solaris versions, both SPARC and x86.
[Bug debug/48253] [4.6/4.7 Regression] Further .debug_aranges issues
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48253 --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-23 13:25:04 UTC --- Created attachment 23758 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23758 gcc46-pr48253.patch Untested fix.
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #13 from Perry Smith pedzsan at gmail dot com 2011-03-23 13:26:10 UTC --- On Mar 23, 2011, at 2:47 AM, michael.haubenwallner at salomon dot at wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #11 from Michael Haubenwallner michael.haubenwallner at salomon dot at 2011-03-23 07:46:49 UTC --- (In reply to comment #10) IZ81343 (or one of its sister APARs) fixes the original issue. But, it leaves a new issue. The new error looks like: Perry, have you seen this on AIX 5.3 or 6.1 ? 5.3 -- something. I thought I put it in my update. I can check when I get to work. Seems like it was tl10 but a later SP than others reported. Does that help? Perry
[Bug other/48254] New: documentation minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48254 Summary: documentation minor Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: other AssignedTo: unassig...@gcc.gnu.org ReportedBy: denis.excoff...@airbus.com Under GCC 4.6.0 RC 20110314: Two items: - consider replacement of affective by effective; this is under the description of the option `-fipa-struct-reorg' - option `-funroll-loops' should not be described twice (pages 108 and 122, if we consider the PDF manual from http://gcc.gnu.org/onlinedocs/gcc/)
[Bug target/46934] gcc ICE: error: unrecognizable insn: in extract_insn, at recog.c:2109
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46934 --- Comment #3 from Chung-Lin Tang cltang at gcc dot gnu.org 2011-03-23 14:48:38 UTC --- Please disregard the above comments, I think this is an ARM backend problem after all.
[Bug libmudflap/12310] [tree-ssa] libmudflap fails to build on mips-sgi-IRIX6.5
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=12310 --- Comment #12 from Frank Ch. Eigler fche at redhat dot com 2011-03-23 14:52:34 UTC --- testing, please ignore
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245 --- Comment #2 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-23 14:56:37 UTC --- Which linker do you use, and what's the value of HAVE_LTO_PLUGIN in gcc/auto-host.h? Could you check the gcc/config.log snippet for the linker plugin support test. If, as I assume, you're using the Darwin linker, HAVE_LTO_PLUGIN should be 0 and you should get the following error for the linker_plugin test: gcc: error: -fuse-linker-plugin is not supported in this configuration The linker is @(#)PROGRAM:ld PROJECT:ld64-97.17 llvm version 2.9svn, from Apple Clang 1.7 (build 77) on x86_64-apple-darwin10.7.0, and @(#)PROGRAM:ld PROJECT:ld64-85.2.1 on powerpc-apple-darwin9. In gcc/auto-host.h I have ... /* Define to the level of your linker's plugin support. */ #ifndef USED_FOR_TARGET #define HAVE_LTO_PLUGIN 0 #endif ... and in gcc/config.log ... | #define LTOPLUGINSONAME liblto_plugin.so ... configure:23133: checking linker plugin support configure:23163: result: 0 ... gcc_cv_lto_plugin=0 ... enable_plugin='yes' ... pluginlibs='' ... #define LTOPLUGINSONAME liblto_plugin.so ... I have grepped the different *.log files, but I did not see any gcc: error: -fuse-linker-plugin is not supported in this configuration
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245
--- Comment #3 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot
Uni-Bielefeld.DE 2011-03-23 15:05:17 UTC ---
The linker is
@(#)PROGRAM:ld PROJECT:ld64-97.17
llvm version 2.9svn, from Apple Clang 1.7 (build 77)
on x86_64-apple-darwin10.7.0, and
@(#)PROGRAM:ld PROJECT:ld64-85.2.1
on powerpc-apple-darwin9.
So both of them non-GNU and not supporting -plugin.
In gcc/auto-host.h I have
...
/* Define to the level of your linker's plugin support. */
#ifndef USED_FOR_TARGET
#define HAVE_LTO_PLUGIN 0
#endif
...
As it should: vendor linker without plugin support.
I have grepped the different *.log files, but I did not see any
gcc: error: -fuse-linker-plugin is not supported in this configuration
This would only occur in gcc/testsuite/*/*.log, but of course with xgcc
or something as the command name.
What happens if you try to compile and link the test program from
check_linker_plugin_available with the new gcc?
$ cd gcc
$ cat lpl.c
int main() { return 0; }
$ ./xgcc -B./ -flto -fuse-linker-plugin lpl.c
Rainer
[Bug debug/48229] DW_TAG_type_unit has no DW_AT_producer
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48229 Dodji Seketeli dodji at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW AssignedTo|dodji at gcc dot gnu.org|unassigned at gcc dot ||gnu.org
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245
--- Comment #4 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-23
15:28:31 UTC ---
What happens if you try to compile and link the test program from
check_linker_plugin_available with the new gcc?
$ cd gcc
$ cat lpl.c
int main() { return 0; }
$ ./xgcc -B./ -flto -fuse-linker-plugin lpl.c
See
Before revision 171039 the test was unsupported:
...
because the test for 'check_linker_plugin_available' in
/opt/gcc/p_work/gcc/testsuite/lib/target-supports.exp returned
gcc: fatal error: -fuse-linker-plugin, but liblto_plugin.so not found
while following revision 171039 the same test compiles and executes without
error.
in comment #0.
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245 --- Comment #5 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-23 15:38:08 UTC --- I see what's going on now: Darwin (in gcc/config/darwin.h) is one of only two targets (besides i386/djgpp.h) that override LINK_COMMAND_SPEC. I think darwin.h should use/honor LINK_PLUGIN_SPEC. Can you try inserting LINK_PLUGIN_SPEC \ in LINK_COMMAND_SPEC_A just after %(linker) \ as is done in gcc.c (LINK_COMMAND_SPEC) for other targets? Thanks. Rainer
[Bug c++/48255] New: default constructor with argument INT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48255
Summary: default constructor with argument INT
Product: gcc
Version: 4.5.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: lis...@lisp2d.net
class A{
public:
};
A x; // OK
A y(1); //OK
I can't found that standard says: default constructor with argument INT.
By code protection I will write:
class A{
A(); // w/o definition
A(int); // w/o definition
public:
};
What to do?
[Bug target/48256] New: gcc4.4.5 internal compiler error: in change_address_1, at emit-rtl.c:1954
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48256 Summary: gcc4.4.5 internal compiler error: in change_address_1, at emit-rtl.c:1954 Product: gcc Version: 4.4.4 Status: UNCONFIRMED Severity: critical Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: molo...@gmail.com Created attachment 23759 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23759 FFTW generated source file which fails in compilation I get an internal compiler error when attempting to compile FFTW code for ARM NEON. Details described below. HW/SW setup --- BeagleBoard xM (native compilation using gcc under ubuntu) Ubuntu 10.10 GNU make 3.8.1 gcc (Ubuntu/Linaro 4.4.1-14ubuntu5) 4.4.5 FFTW codebase and setup --- git clone git://gitorious.org/gsoc2010-fftw-neon gsoc2010-fftw-neon cd gsoc2010-fftw-neon make clean sh bootstrap.sh CFLAGS=-O3 -pipe -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp ./configure --prefix=/usr --enable-single --enable-shared --with-pic --host=arm-none-linux-gnueabi --enable-armv7-cycle-counter --enable-neon make cd kernel cp cpy1d.c __cpy1d.c cp cpy1d-neon.c cpy1d.c cd .. make snippet from failing make (offending file attached) --- /bin/bash ../../../libtool --tag=CC --mode=compile gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../.. -I../../../kernel -I../../../dft -I../../../dft/simd -I../../../simd -mfpu=neon -O3 -pipe -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -MT n1fv_128.lo -MD -MP -MF .deps/n1fv_128.Tpo -c -o n1fv_128.lo n1fv_128.c libtool: compile: gcc -std=gnu99 -DHAVE_CONFIG_H -I. -I../../.. -I../../../kernel -I../../../dft -I../../../dft/simd -I../../../simd -mfpu=neon -O3 -pipe -mcpu=cortex-a8 -mfpu=neon -mfloat-abi=softfp -MT n1fv_128.lo -MD -MP -MF .deps/n1fv_128.Tpo -c n1fv_128.c -fPIC -DPIC -o .libs/n1fv_128.o n1fv_128.c: In function 'n1fv_128': n1fv_128.c:3513: internal compiler error: in change_address_1, at emit-rtl.c:1954 Please submit a full bug report, with preprocessed source if appropriate. See file:///usr/share/doc/gcc-4.4/README.Bugs for instructions. make[5]: *** [n1fv_128.lo] Error 1
[Bug debug/48204] [4.5/4.6/4.7 Regression] ICE: in decimal_to_decnumber, at dfp.c:115 with -fno-tree-ccp -fno-tree-dominator-opts -fno-tree-fre -g
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48204 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jakub at gcc dot gnu.org |gnu.org | --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-23 15:50:25 UTC --- Created attachment 23760 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=23760 gcc46-pr48204.patch Untested fix.
[Bug c++/48255] default constructor with argument INT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48255 Richard Guenther rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Richard Guenther rguenth at gcc dot gnu.org 2011-03-23 15:55:36 UTC --- t.C:5:6: error: no matching function for call to ‘A::A(int)’ t.C:1:8: note: candidates are: A::A() t.C:1:8: note: A::A(const A) your code example is rejected as it should.
[Bug c++/48255] default constructor with argument INT
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48255 --- Comment #2 from Lisp2D lisp2d at lisp2d dot net 2011-03-23 16:15:14 UTC --- found silent conversion class A have explicit A(std::complexlong doubleconst x);
[Bug other/48254] documentation minor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48254 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||documentation --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-23 16:19:00 UTC --- (In reply to comment #0) Under GCC 4.6.0 RC 20110314: Two items: - consider replacement of affective by effective; this is under the description of the option `-fipa-struct-reorg' Good catch, thanks - option `-funroll-loops' should not be described twice (pages 108 and 122, if we consider the PDF manual from http://gcc.gnu.org/onlinedocs/gcc/) Hmm yes, it's at http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-funroll_002dloops-811 and http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#index-funroll_002dloops-864 so are -ftracer and -funroll-all-loops ... not sure if there's a reason for that
[Bug c++/40793] Error: no matching function for call to XYZ doesn't display function-template-arguments
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40793 --- Comment #11 from Jonathan Schmidt-Dominé jonathan.sd24 at yahoo dot de 2011-03-23 16:29:31 UTC --- Couldn't this patch be accepted? It looks very nice…
[Bug libstdc++/48257] New: std::string::assign() corrupts std::string static data when called on emptyString1 using emptyString2.data()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257
Summary: std::string::assign() corrupts std::string static data
when called on emptyString1 using emptyString2.data()
Product: gcc
Version: 4.1.2
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mohsinrza...@gmail.com
The output of the following program is:
4
4
#include string
#include iostream
using namespace std;
int main()
{
try
{
string emptyStr1;
string emptyStr2;
string emptyStr3;
emptyStr3.assign(emptyStr2.data(), 4);
cout emptyStr1.size() endl;
cout emptyStr3.size() endl;
}
catch(...)
{
cout Reached here endl;
}
}
The size of emptyStr1/3 should not have been modified when emptyStr3 was
assigned the contents of emptyStr2 up to 4 bytes although all string are empty.
From what I've understood of the basic_string code, the following code flow
will result in this case:
snip
templatetypename _CharT, typename _Traits, typename _Alloc
inline basic_string_CharT, _Traits, _Alloc::
basic_string()
#ifndef _GLIBCXX_FULLY_DYNAMIC_STRING
: _M_dataplus(_S_empty_rep()._M_refdata(), _Alloc()) { }
#else
: _M_dataplus(_S_construct(size_type(), _CharT(), _Alloc()), _Alloc()) { }
#endif
/snip
First, the default constructor. Since I do not have
_GLIBCXX_FULLY_DYNAMIC_STRING defined in my implementation, _M_dataplus._M_p
will get initialized to (_S_empty_rep_storage + sizeof (_Rep)) for all three
strings.
snip
const _CharT*
data() const
{ return _M_data(); }
/snip
snip
_CharT*
_M_data() const
{ return _M_dataplus._M_p; }
/snip
snip
templatetypename _CharT, typename _Traits, typename _Alloc
basic_string_CharT, _Traits, _Alloc
basic_string_CharT, _Traits, _Alloc::
assign(const _CharT* __s, size_type __n)
{
__glibcxx_requires_string_len(__s, __n);
_M_check_length(this-size(), __n, basic_string::assign);
if (_M_disjunct(__s) || _M_rep()-_M_is_shared())
return _M_replace_safe(size_type(0), this-size(), __s, __n);
else
{
// Work in-place.
const size_type __pos = __s - _M_data();
if (__pos = __n)
_M_copy(_M_data(), __s, __n);
else if (__pos)
_M_move(_M_data(), __s, __n);
_M_rep()-_M_set_length_and_sharable(__n);
return *this;
}
}
/snip
When assign is called using emptyStr2.data(), which returns the same value as
that set above for _M_dataplus._M_p, _M_disjunct() will return 0, as will
_M_is_shared() and we end up going into the else block.
Here, since __s = _M_dataplus._M_p, which is what _M_data() returns, __pos = 0
and so the only statements we end up executing are the last two in the else
block thereby setting the length = 4 in the static storage returned by
_M_rep().
This results in the corruption of static storage used by all std::string
objects.
Does that make sense?
==
Using built-in specs.
Target: x86_64-redhat-linux
Configured with: ../configure --prefix=/usr --mandir=/usr/share/man
--infodir=/usr/share/info --enable-shared --enable-threads=posix
--enable-checking=release --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-libgcj-multifile
--enable-languages=c,c++,objc,obj-c++,java,fortran,ada --enable-java-awt=gtk
--disable-dssi --enable-plugin
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre --with-cpu=generic
--host=x86_64-redhat-linux
Thread model: posix
gcc version 4.1.2 20080704 (Red Hat 4.1.2-48)
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245
Dominique d'Humieres dominiq at lps dot ens.fr changed:
What|Removed |Added
CC||howarth at nitro dot
||med.uc.edu, iains at gcc
||dot gnu.org, mrs at gcc dot
||gnu.org
--- Comment #6 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-23
16:43:42 UTC ---
I see what's going on now: Darwin (in gcc/config/darwin.h) is one of
only two targets (besides i386/djgpp.h) that override
LINK_COMMAND_SPEC.
I think darwin.h should use/honor LINK_PLUGIN_SPEC. Can you try
inserting
LINK_PLUGIN_SPEC \
in LINK_COMMAND_SPEC_A just after
%(linker) \
as is done in gcc.c (LINK_COMMAND_SPEC) for other targets?
I'll do the check ASAP (CC Iain Sandoe, Mike Stump, and Jack Howarth).
Meanwhile the following patch skips the test:
--- /opt/gcc/_clean/gcc/testsuite/gcc.dg/lto/pr46940_0.c2010-12-16
08:01:29.0 +0100
+++ /opt/gcc/work/gcc/testsuite/gcc.dg/lto/pr46940_0.c2011-03-23
17:17:07.0 +0100
@@ -1,4 +1,5 @@
/* { dg-require-linker-plugin } */
+/* { dg-require-alias } */
/* { dg-extra-ld-options -fuse-linker-plugin } */
#include stdio.h
[Bug debug/48220] DW_OP_GNU_entry_value/DW_TAG_GNU_call_site_parameter vs. register window targets
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48220 --- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org 2011-03-23 16:45:05 UTC --- The aim of the extension is to allow correct debug info, not almost correct, so I think defining upon entering of the current subprogram as anything but before the first insn in it is wrong and would make it not possible to use DW_OP_GNU_entry_value before the point (end of prologue or what?). Consider e.g. shrink-wrapping Bernd just proposed for GCC too... So I think what we currently do on SPARC has to change. As for teaching var-tracking about save/restore on SPARC, it would be a matter of adding probably two target hooks, one that would be run e.g. at the end of adjust_insn and would be supposed to change it using validate_change (..., true); in whatever way var-tracking should understand the insn. So e.g. for save you'd add into the parallel things like: (set (reg:P 24) (reg:P 8)) (clobber (reg:P 8)) and similarly for all the other param regs. Perhaps even make it explicit what exactly is subtracted from %sp. And the second target hook would return a different rtx for DECL_INCOMING_RTL, with registers adjusted back. Because for -O0 if we don't do var-tracking we probably want DECL_INCOMING_RTL to still refer to %i0 etc., even when it is not correct before the save.
[Bug target/48258] New: Add VSX support for float/double vector reductions improve float insert/extract
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48258 Summary: Add VSX support for float/double vector reductions improve float insert/extract Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: target AssignedTo: meiss...@gcc.gnu.org ReportedBy: meiss...@gcc.gnu.org Host: powerpc64-linux Target: powerpc64-linux Build: powerpc64-linux Right now, the powerpc compiler does not do support for float and double vector reductions. For float in particular, the compiler does the code, and then stores the vector in the stack to extract the bottom element. With VSX it is possible to do vector reductions in fewer instructions and to eliminate the store.
[Bug libstdc++/48257] std::string::assign() corrupts std::string static data when called on emptyString1 using emptyString2.data()
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48257 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-03-23 16:59:31 UTC --- this is undefined behaviour, the standard requires that emptyStr2.data() points to an array of at least 4 chars
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245
Iain Sandoe iains at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.03.23 17:07:04
Ever Confirmed|0 |1
--- Comment #7 from Iain Sandoe iains at gcc dot gnu.org 2011-03-23 17:07:04
UTC ---
I'll try this on *-darwin9 and a darwin9-X-cris-elf
(I assume we need to clone all the logic to cater for cross compiler cases... )
maybe this is getting complex enough to warrant a spec of its own? (and then we
could avoid cloning it)
===
Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h(revision 171353)
+++ gcc/config/darwin.h(working copy)
@@ -174,6 +174,38 @@ extern GTY(()) int darwin_ms_struct;
#define CPP_SPEC %{static:%{!dynamic:-D__STATIC__}}%{!static:-D__DYNAMIC__}
\
%{pthread:-D_REENTRANT}
+/* Conditional to test whether the LTO plugin is used or not.
+ FIXME: For slim LTO we will need to enable plugin unconditionally. This
+ still cause problems with PLUGIN_LD != LD and when plugin is built but
+ not useable. For GCC 4.6 we don't support slim LTO and thus we can enable
+ plugin only when LTO is enabled. We still honor explicit
+ -fuse-linker-plugin if the linker used understands -plugin. */
+
+/* The linker has some plugin support. */
+#if HAVE_LTO_PLUGIN 0
+/* The linker used has full plugin support, use LTO plugin by default. */
+#if HAVE_LTO_PLUGIN == 2
+#define PLUGIN_COND !fno-use-linker-plugin:%{flto|flto=*|fuse-linker-plugin
+#define PLUGIN_COND_CLOSE }
+#else
+/* The linker used has limited plugin support, use LTO plugin with explicit
+ -fuse-linker-plugin. */
+#define PLUGIN_COND fuse-linker-plugin
+#define PLUGIN_COND_CLOSE
+#endif
+#define LINK_PLUGIN_SPEC \
+%{PLUGIN_COND: \
+-plugin %(linker_plugin_file) \
+-plugin-opt=%(lto_wrapper) \
+-plugin-opt=-fresolution=%u.res \
+%{!nostdlib:%{!nodefaultlibs:%:pass-through-libs(%(link_gcc_c_sequence))}}
\
+}PLUGIN_COND_CLOSE
+#else
+/* The linker used doesn't support -plugin, reject -fuse-linker-plugin. */
+#define LINK_PLUGIN_SPEC %{fuse-linker-plugin:\
+%e-fuse-linker-plugin is not supported in this configuration}
+#endif
+
/* This is mostly a clone of the standard LINK_COMMAND_SPEC, plus
precomp, libtool, and fat build additions.
@@ -185,6 +217,7 @@ extern GTY(()) int darwin_ms_struct;
#define LINK_COMMAND_SPEC_A \
%{!fdump=*:%{!fsyntax-only:%{!c:%{!M:%{!MM:%{!E:%{!S:\
%(linker) \
+ LINK_PLUGIN_SPEC \
%{flto*:%fcompare-debug*} \
%{flto*} \
%l %X %{s} %{t} %{Z} %{u*} \
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245 --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-23 17:08:59 UTC --- With the change in comment #5, bootstrapping fails with ld: file not found: LINK_PLUGIN_SPEC collect2: ld returned 1 exit status make[5]: *** [libgcc_s.dylib] Error 1
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245 --- Comment #9 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-23 17:10:38 UTC --- maybe this is getting complex enough to warrant a spec of its own? (and then we could avoid cloning it) Why would you want to clone that? LINK_PLUGIN_SPEC is defined in gcc.c before it is used in LINK_COMMAND_SPEC, irrespective if the latter is from gcc itself or from target headers. Just use it as is. The fact that Darwin uses a clone of LINK_COMMAND_SPEC instead of having hooks in the generic one to to its stuff is a mistake, IMO. Rainer
[Bug target/46072] AIX linker chokes on debug info for uninitialized static variables
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46072 --- Comment #14 from Dr. David Kirkby david.kirkby at onetel dot net 2011-03-23 17:11:42 UTC --- Has anyone with an AIX support contract ever raised this issue with IBM? If so, is there a publicly viewable location for this? If not, can someone do it. My own RS/6000 is an ancient thing I personally own, and so I have no support contract at all. It seems to me it could be a gcc bug or a bug in the AIX assembler or linker. It would be interesting to try to replace the systems linker and assembler with versions from unpatched 5.3 or 6.1. That might give some clues. I can see this issue raised on an IBM AIX forum http://www.ibm.com/developerworks/forums/thread.jspa?threadID=348558 but don't know if its even being considered by IBM.
[Bug testsuite/48245] FAIL: gcc.dg/lto/pr46940 c_lto_pr46940_0.o assemble on *-apple-darwin*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48245 --- Comment #10 from ro at CeBiTec dot Uni-Bielefeld.DE ro at CeBiTec dot Uni-Bielefeld.DE 2011-03-23 17:15:46 UTC --- --- Comment #8 from Dominique d'Humieres dominiq at lps dot ens.fr 2011-03-23 17:08:59 UTC --- With the change in comment #5, bootstrapping fails with ld: file not found: LINK_PLUGIN_SPEC collect2: ld returned 1 exit status make[5]: *** [libgcc_s.dylib] Error 1 Iain is right: we need to turn this into a proper spec since LINK_PLUGIN_SPEC isn't defined at the point darwin.h is included. Rainer
