RE: Missing web link
On 19 October 2006 15:36, Bruce Korb wrote: > I was going to re-subscribe my dropped subscription to gcc-patches, > but the only links (that I can find) on gcc.gnu.org lead to the archives, > not to the subscription page. Thanks - Bruce http://gcc.gnu.org/lists.html Search for "Subscribing/unsubscribing". cheers, DaveK -- Can't think of a witty .sigline today
RE: Abt gcses-1.c testcase
On 30 October 2006 13:36, Mohamed Shafi wrote: > Hello all, > > Can anybody tell me the purpose of the testcase > testsuite\gcc.dg\special\gcsec-1.c in the gcc testsuite ? > Is it something related with garbage clooection? Yes, but not the gcc garbage collector but the linker's section-based gc. > What exactly doec this testcase test ? It appears to be testing that the linker supports the --gc-sections option, and that the compiler generates the right output for it when compiling with -ffunction-sections -fdata-sections. cheers, DaveK -- Can't think of a witty .sigline today
RE: How to deliver my source code???
On 30 October 2006 18:01, Marcelo Marchi wrote: > Hi all, > > I need some help from gcc gurus regarding delivering source code > I have a application that needs to be delivered to be compiled on my > customer side, BUT it cannot make changes or have any understanding > about code. > This deliver is strong necessary by many reasons, particularly by > changes that will be made in any cases with a tool. Then I need to > know if has some ANSI C compiler that compiles crypto C source files, > or any other solution about this. What you ask is a) off-topic and b) logically impossible. Sorry. If you want to discuss source-code obfuscation techniques, please try the gcc-help list or other generic programming list/group: this group is about working on the internals of the compiler itself. However, you will get much the same advice there: it is impossible. You can make source code hard to read and unclear, but that's the most that you can do. If the crypto-sources-compiler could decode it enough to compile it, so could anyone else. [ Plus, of all the places to ask, a mailing list of an organisation dedicated to the promotion of open source and free software is not very likely to be the best place to seek advice on how to hide your code and keep it secret! ] cheers, DaveK -- Can't think of a witty .sigline today
GCSE again: bypass_conditional_jumps -vs- commit_edge_insertions - problem with ccsetters?
Hello gcc-hackers,
Tracking down a gcse bug while unrolling a loop where the count is known to
be one, I've narrowed the problem down to the actions of
commit_edge_insertions and bypass_conditional_jumps, and I could use a little
help in appreciating the reasoning behind what they're /trying/ to do.
The bug is similar or perhaps related to PR/9974, see
http://gcc.gnu.org/ml/gcc-patches/2003-03/msg02162.html for the explanation of
that one; I also have a non-cc0 target, and a SET immediately prior to a
conditional jump is being assumed to be a CC-setter. But the
reg_killed_on_edge patch that solved that one isn't helping me in this case.
Here's the testcase:
struct Peripheral {
int index;
};
struct PeripheralManager {
struct Peripheral *activePeripherals[1];
};
struct PeripheralManager *manager;
int RegisterPeripheral (struct Peripheral *periph);
int RegisterPeripheral (struct Peripheral *periph)
{
int rc = 0;
if ((0 != periph) && (-1 == periph->index))
{
unsignedi = 0;
while ((i < 1)
&& (0 != manager->activePeripherals [i]))
{
i++;
}
if (i < 1)
{
manager->activePeripherals [i] = periph;
periph->index = (int) i;
rc = 1;
}
}
return rc;
}
When compiled at O2, gcc optimises away the entire body of the function and
just returns zero. This happens during the first gcse pass, and it appears to
be because of bad code movement on an edge during cjump bypassing. What
happens is that the "i++" from the loop body is always executed, because it
gets hoisted up past the "0 != manager->activePeripherals [i]" test at the
loop top; later, gcc realises that since i is always at least 1, the "if (i <
NUM_ARRAY_ELEMENTS (manager->activePeripherals))" clause can never happen and
discards it; as a result it decides i is unused and discards the entire loop
body as well.
In the code below[*], BB#2 initialises the loop counter (r74) to zero, loads
the variable 'manager' into r85 and r75, then loads up r89 from (mem r85) to
get the first entry of the activePeripherals[] array for testing at the top of
the loop in the entry condition. If r89 fails the non-zero test in the jump
insn 100, it exits immediately to BB#6, which performs the 'if' test after the
loop. Otherwise it falls through to BB#4.
BB#4 is the loop body. It increments the loop counter r74 and tests if the
result is non-zero, which is equivalent to saying '< 1' with unsigned, where
'1' is the loop count; if so, it exits the loop to BB#6. Otherwise, it falls
into BB#5, which tests the second part of the loop condition, the
activePeripherals[] array entry, falling out to BB#6 if it fails, or
returning to BB#4 if not. (Oddly enough it hasn't advanced r75, the pointer
to the array, even though it has advanced the index number r74; then again, it
does know the size of the array is 1 and the loop will not iterate).
Anyway this looks reasonable enough until gcse comes along. Near the end of
gcse_main, one_cprop_pass is called one final time, but for the first time
with the flag set that permits it to modify jumps. This causes one_cprop_pass
to call bypass_conditional_jumps, and that's how we get into trouble.
Initially, we've got a flow graph that looks something like this:
|=|
|BB#2 |
| i = 0 |
| |
|if arr[i]==0:+--+
|=| |
| |
| |
V |
+->|=| |
| |BB#4 | |
| | i++| |
| | if i!=0:+--+
| | | |
| |=| |
| | |
| | |
| V |
| |=| |
| |BB#5 | |
| | | |
+--+:if arr[i]!=0| |
| | |
|=| |
| |
| |
V |
|=|<-+
|BB#6 |
| |
| if i!=0:+--+
| | |
|=| |
| |
| |
V |
|=| |
|BB#7 | |
| | |
|arr[i]=periph| |
| | |
|=| |
| |
| |
V |
|=|<-+
|BB#8 |
| |
| |
| |
|=|
where 'arr' stands for 'manager->activePeripherals'. The first thing that
happens in bypass_conditional_jumps is that it decides that BB#4 can be
bypassed when coming from BB#2...
Replacing insn 100 by jump 115
JUMP-BYPASS: P
RE: return void from void function is allowed.
On 31 October 2006 20:21, Igor Bukanov wrote:
> GCC 4.1.2 and 4.0.3 incorrectly accepts the following program:
>
> void f();
>
> void g()
> {
> return f();
> }
>
> No warning are issued on my Ubuntu Pentium-M box. Is it a known bug?
>
> Regards, Igor
Yep. PR 5678. This patch worked for me: apologies in advance for
line-wrapping it.
===
RCS file: /sources/repository/external_source/gnu/gcc-3.3.3/gcc/c-typeck.c,v
retrieving revision 1.1
retrieving revision 1.2
diff -u -r1.1 -r1.2
--- external_source/gnu/gcc-3.3.3/gcc/c-typeck.c2004/03/26 13:22:21
1.1
+++ external_source/gnu/gcc-3.3.3/gcc/c-typeck.c2006/04/23 15:25:06
1.2
@@ -7068,8 +7068,12 @@
else if (valtype == 0 || TREE_CODE (valtype) == VOID_TYPE)
{
current_function_returns_null = 1;
+ /* [ARTIMI_LOCAL] Fix PR40 (gcc PR5678) by warning without -pedantic,
+ even if attempting to 'return a void'. */
if (pedantic || TREE_CODE (TREE_TYPE (retval)) != VOID_TYPE)
pedwarn ("`return' with a value, in function returning void");
+ else if (warn_return_type)
+ warning ("`return' with a value, in function returning void");
}
else
{
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: GCSE again: bypass_conditional_jumps -vs- commit_edge_insertions - problem with ccsetters?
On 02 November 2006 01:38, Roger Sayle wrote:
> On Tue, 31 Oct 2006, Dave Korn wrote:
>> Tracking down a gcse bug while unrolling a loop where the count is
>> known to be one, I've narrowed the problem down to the actions of
>> commit_edge_insertions and bypass_conditional_jumps, and I could use
>> a little help in appreciating the reasoning behind what they're /trying/
>> to do.
>
> Sorry for the delay, but I only read the "gcc" list infrequently and
> have only just seen your question.
No apologies needed, I very much appreciate your input.
>> Is the bug perhaps because the bypass code notes that there are two code
>> paths from BB#2 to BB#7, notices that the indirect one depends on a
>> condition that it knows is true, but doesn't realise that that doesn't
>> mean they are equivalent to each other?
>
> Aftre reading through your analysis I suspect this is precisely the
> problem. The jump bypassing code is making the assumption that there
> can temporarily be two (or more) edges between the same pair of basic
> blocks. The distinction being that one edge has an instructin inserted
> on it, and the other one doesn't.
Right. For the moment, I've just done this:
@@ -4816,19 +4921,34 @@ bypass_conditional_jumps ()
}
else if (GET_CODE (insn) == JUMP_INSN)
{
- if (any_condjump_p (insn) && onlyjump_p (insn))
+ if (any_condjump_p (insn) && onlyjump_p (insn)
+#ifndef HAVE_cc0
+&& !setcc
+#endif
+)
changed |= bypass_block (bb, setcc, insn);
break;
}
else if (INSN_P (insn))
break;
to completely disable the bypassing when any instruction would need to be
inserted on the edge. I think that's suboptimal, it should be ok if there are
no *other* edges between the same two blocks but I don't know how to test that
yet.
> I suspect that somewhere this is falling foul of some other CFG related
> optimization that says if both branches of a conditional jump go the same
> label, then the conditional jump is redundant and can be replaced by an
> unconditional jump. One the CFG believes that BB#2 has only one sucessor,
> then commit_edge_insertions is free to place things there.
>
> Your investigation and understanding is flawless so far. We now need
> to figure out how these edges are getting merged. If this is a
> side-effect of recent CFG/RTL related changes jump bypassing might
> need to be restructured/rewritten to avoid using the insn on edge
> functionality.
So far I haven't been able to reproduce this on 4.x; I've only seen it on
3.3.3 with a (custom) non-cc0 backend and I only have an x86 build of trunk.
I've had a thorough browse through bugzilla and haven't found any similar bug
or related fix, so it may well be one of those things that is still there but
doesn't trip any more because of tree-ssa doing so much work before the rtl
optimisers get called. I'll see if I can reproduce it on a cross ppc build of
trunk.
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: GCSE again: bypass_conditional_jumps -vs- commit_edge_insertions - problem with ccsetters?
On 02 November 2006 06:10, Steven Bosscher wrote: > On 11/2/06, Roger Sayle <[EMAIL PROTECTED]> wrote: >> Steven Bosscher might even have plans for reorganizing jump bypassing >> already as part of his CSE/GCSE overhaul? > > Yes, and one part of that plan is to pre-split all critical edges so > that you never have to insert on edges. That would make your problem > go away, iiuc. Yes, I'm sure it would, and as I mentioned in my reply to Roger, it's possible that it might be completely hidden by the effects of tree-ssa in practice on mainline, but the code in that area hasn't been changed so it could still be latent. cheers, DaveK -- Can't think of a witty .sigline today
RE: gcc trunk
On 02 November 2006 13:12, Gerald Pfeifer wrote: > On Thu, 26 Oct 2006, Brooks Moses wrote: >> I would say, on looking at it, that the order of items under "Status" is >> slightly confusing; it seems to me that "Active Development" ought go >> next to "Next Release Series". > > That's a good point. > > From a user perspective, how about > > Current (4.1) > Previous (4.0) > Next (4.2) > Active development (4.3) > I think that's the nicer way to do it. > Thoughts? Let's be user-centric. Us developers can be expected to cope. cheers, DaveK -- Can't think of a witty .sigline today
RE: Volatile operations and PRE
On 07 November 2006 16:33, Andrew Haley wrote:
> Ricardo FERNANDEZ PASCUAL writes:
> > I have done some experiments to try to understand what is happening, and
> > I am a bit confused by the bahavior of GCC. Consider the following C
> > function:
> >
> > static struct { int w; } s;
> >
> > void wait (void) {
> > int t;
> > loop:
> > t = *((volatile int *) &s.w);
> > if (t > 0) goto loop;
> > }
> >
> >
> > The code generated by "cc1 -O3" on x86 is:
> >
> > wait:
> > movls, %eax
> > pushl %ebp
> > movl%esp, %ebp
> > testl %eax, %eax
> > jg .L6
> > popl%ebp
> > ret
> > .L3:
> > .L6:
> > jmp .L6
> >
> >
> > Which does not seem to respect the semantics of volatile. Is this the
> > expected behavior or is this a bug?
>
> I think it's a bug.
> > FWIW, the folowing function:
> which looks right. A temporary shouldn't make any difference here.
Can I just remind everyone we had a huge long thread with this discussion
last year and it might be worth reviewing. Look for the thread titled
"volatile semantics" running from Tue 03/05/2005 09:42 to Tue 26/07/2005
00:09. (We should try not to repeat too much of a three-month long debate!)
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: wiki topics wish (configuration related)
On 08 November 2006 12:25, Ralf Wildenhues wrote: > Hello Basile, > > * Basile STARYNKEVITCH wrote on Tue, Nov 07, 2006 at 11:19:16PM CET: >> >> http://gcc.gnu.org/wiki/AboutGCCConfiguration > If you need a [ ... ] > The first chapter of the Automake 1.10 manual [ ... ] > The Autobook and the tutorial page [ ... ] > Hope that helps. You don't really "get" wiki, do you? ;-) cheers, DaveK -- Can't think of a witty .sigline today
RE: wiki topics wish (configuration related)
On 08 November 2006 16:19, 'Ralf Wildenhues' wrote: > * Dave Korn wrote on Wed, Nov 08, 2006 at 04:59:34PM CET: >>>> http://gcc.gnu.org/wiki/AboutGCCConfiguration > [...] >> You don't really "get" wiki, do you? ;-) > > Oh, I didn't know this wiki was editable by anybody. > I mistakenly inferred from notices on other wiki pages > that there are restrictions and rules. > > Cheers, > Ralf You need to get an account and sign in, but yes, this is an open-source and collaborative wiki, everyone is encouraged to contribute! :) Basile even said "Comments and improvements are welcome", I took the word improvements as meaning that no offense would be caused if someone was to build on and extend what's there. So I think there's no reason you shouldn't add some links to it yourself. cheers, DaveK -- Can't think of a witty .sigline today
RE: How to grow the Fortran I/O parameter struct and keep ABI compatibility
On 08 November 2006 08:13, FX Coudert wrote: >> Suggestion: We should make sure we can accommodate F2003 with >> 4.2 and 4.3 by increasing the possible number of flags as needed. > > I'm in favour of that, and I already started writing the necessary > patch. But it looks like we'll have to bump the so number a last > time, for 4.3, and then make the private part of the structure wider, > to accomodate any new flags (for things like extension, or the way > we'll really handle asynchronous I/O). > > FX What's the problem with just adding a new 'extended private stuff' field to the very end of the struct and allocating one of the remaining flag bits to say if it's present or not? cheers, DaveK -- Can't think of a witty .sigline today
RE: [m32c-elf] losing track of register lifetime in combine?
On 10 November 2006 07:13, Ian Lance Taylor wrote:
> DJ Delorie <[EMAIL PROTECTED]> writes:
>
>> I compared the generated code with an equivalent explicit test,
>> and discovered that gcc uses a separate rtx for the intermediate:
>>
>> i = 0xf;
>> if (j >= 16)
>> {
>> int i2;
>> i2 = i >> 8;
>> i = i2 >> 8;
>> j -= 16;
>> }
>>
>> This seems to avoid the combiner problem, becuase you don't have the
>> same register being set and being used in one insn. Does this explain
>> why combine was having a problem, or was this a legitimate thing to do
>> and the combiner is still wrong? Using a temp in the expander works
>> around the problem.
>
> Interesting. Using a temporary is the natural way to implement this
> code. But not using a temporary should be valid. So I think there is
> a bug in combine.
Doesn't this just suggest that there's a '+' constraint modifier missing
from an operand in a pattern in the md file somewhere, such as the one that
expands the conditional in the first place?
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: How to create both -option-name-* and -option-name=* options?
On 10 November 2006 07:34, Brooks Moses wrote: > The Fortran front end currently has a lang.opt entry of the following form: > >ffixed-line-length- >Fortran RejectNegative Joined UInteger > > I would like to add to this the following option which differs in the > last character, but should be treated identically: > >ffixed-line-length= >Fortran RejectNegative Joined UInteger >In file included from tm.h:7, > from ../../svn-source/gcc/genconstants.c:32: >options.h:659: error: redefinition of `OPT_ffixed_line_length_' >options.h:657: error: `OPT_ffixed_line_length_' previously defined > here > > This is because both the '=' and the '-' in the option name reduce to a > '_' in the enumeration name, which of course causes the enumerator to > get defined twice -- and that's a problem, even though I'm quite happy > for the options to both be treated identically. > > There's not really any good way around this problem, is there? It may seem a bit radical, but is there any reason not to modify the option-parsing machinery so that either '-' or '=' are treated interchangeably for /all/ options with joined arguments? That is, whichever is specified in the .opt file, the parser accepts either? cheers, DaveK -- Can't think of a witty .sigline today
RE: [m32c-elf] losing track of register lifetime in combine?
On 10 November 2006 15:01, Ian Lance Taylor wrote: > In any case a '+' constraint doesn't make any difference this early in > the RTL passes. combine doesn't look at constraints. bah, of course! Ignore me, I'll just go sit in the dunce's corner for a while :) cheers, DaveK -- Can't think of a witty .sigline today
RE: Abt long long support
On 10 November 2006 17:55, Rask Ingemann Lambertsen wrote: > On Fri, Nov 10, 2006 at 07:17:29AM -0800, Ian Lance Taylor wrote: >> "Mohamed Shafi" <[EMAIL PROTECTED]> writes: >> >>> 1. What could be the reason for this behavior? >> >> I'm really shooting in the dark here, but my guess is that you have a >> define_expand for movdi that is not reload safe. > >And in case the target doesn't have registers capable of holding DImode > values, consider deleting the movdi pattern. No, surely you don't want to do that! You really need a movdi pattern - even more so if there are no natural DImode-sized registers, as gcse can get terribly confused by bad reg_equal notes if you don't. See e.g.: http://gcc.gnu.org/ml/gcc/2003-04/msg01397.html http://gcc.gnu.org/ml/gcc/2004-06/msg00993.html cheers, DaveK -- Can't think of a witty .sigline today
RE: How to create both -option-name-* and -option-name=* options?
On 10 November 2006 20:06, Mark Mitchell wrote: > Dave Korn wrote: > >> It may seem a bit radical, but is there any reason not to modify the >> option-parsing machinery so that either '-' or '=' are treated >> interchangeably for /all/ options with joined arguments? That is, >> whichever is specified in the .opt file, the parser accepts either? > > I like that idea. Would it be a suitable solution to just provide a specialised wrapper around the two strncmp invocations in find_opt? It seems ok to me; we only want this change to affect comparisons, we call whichever form is listed in the .opts file the canonical form and just don't worry if the (canonical) way a flag is reported in an error message doesn't quite match when the non-canonical form was used on the command line? (I'm not even going to mention the 'limitation' that we are now no longer free to create -fFLAG=VALUE and -fFLAG-VALUE options with different meanings!) cheers, DaveK -- Can't think of a witty .sigline today
RE: How to create both -option-name-* and -option-name=* options?
On 10 November 2006 21:18, Brooks Moses wrote: > Dave Korn wrote: > But that's already not possible -- that's essentially how I got into > this problem in the first place. If one tries to define both of those, > the declaration of the enumeration-type holding the option flags breaks, > so you can't do that. That aside, it would have been possible before, and the mangling could easily have been fixed to support it had we wanted to. > (Well, you could hack that to make it work; define -fFLAG as the option > name, so that the '-' or '=' is the first character of the argument. > That will still work, but it's a pain if VALUE is otherwise a UInteger.) Yeh, but it's also the right thing to do with the machinery as it stands. > This does raise a point about how the options are compared, though -- to > be useful, this needs to also handle cases where a Joined option is > emulated by a "normal" option. For instance, Fortran's lang.opt > contains something like: > >-ffixed-line-length-none >Fortran > >-ffixed-line-length- >Fortran Joined > > We would also want "-ffixed-line-length=none" to be handled > appropriately, which makes this a bit trickier than just handling the > last character of Joined options. > > Are there any meaningful downsides to just having the option-matcher > treat all '-' and '=' values in the option name as equivalent? It would > mean that we'd also match "-ffixed=line=length-none", for instance, but > I don't think that causes any real harm. I think it's horribly ugly! (Yes, this would not be a show-stopper in practice; I have a more serious reason to object, read on...) > An alternative would be to specify that an '=' in the name in the .opt > file will match either '=' or '-' on the command line. This does > require that the canonical form be the one with '=' in it, and means > that things with '-' in them need to be changed in the .opt file to > accept both, but the benefit is that it can accept pseudo-Joined options > in either form without accepting all sorts of wierd things with random > '='s in them. I think that for this one case we should just say that you have to supply both forms -ffixed-line-length-none and -ffixed-line-length=none. What you have here is really a joined option that has an argument that can be either a text field or an integer, and to save the trouble of parsing the field properly you're playing a trick on the options parser by specifying something that looks to the options machinery like a longer option with a common prefix, but looks to the human viewer like the same option with a text rather than integer parameter joined. Treating a trailing '-' as also matching a '=' (and vice-versa) doesn't blur the boundary between what are separate concepts in the option parsing machinery. I think if you really want these pseudo-joined fields, add support to the machinery to understand that the joined field can be either a string or a numeric. The change I'm proposing is kind of orthogonal to that. It solves your problem with the enum; there becomes only one enum to represent both forms and both forms are accepted and parse to that same enumerated value. It does not solve nor attempt to address your other problem, with the limitations on parsing joined fields, and I don't think we should try and bend it into shape to do this second job as well. If you address the parsing limitation on joined fields, the flexibility that my suggestion offers /will/ automatically be available to your usage. cheers, DaveK -- Can't think of a witty .sigline today
RE: strict aliasing question
On 12 November 2006 03:35, Howard Chu wrote:
> Here's a different example, which produces the weaker warning
> warning: type-punning to incomplete type might break strict-aliasing rules
>
> struct foo;
>
> int blah(int fd) {
> int buf[BIG_ENOUGH];
> void *v = buf;
> struct foo *f;
>
> f = v;
> f = (struct foo *)buf;
>
> init(f, fd);
> munge(f);
> flush(f);
> }
>
> "foo" is an opaque structure. We have no idea what's inside, we just
> know that it's relatively small. There are allocators available that
> will malloc them for us, but we don't want to use malloc here because
> it's too slow, so we want to reserve space for it on the stack, do a few
> things with it, then forget it.
>
> If we go through the temporary variable v, there's no warning. If we
> don't use the temporary variable, we get the "might break" message.
Try
> f = (struct foo *)(void *)buf;
Or even better...
struct foo;
int blah(int fd) {
struct foo *f;
f = alloca (BIG_ENOUGH);
init(f, fd);
munge(f);
flush(f);
}
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: strict aliasing question
On 12 November 2006 04:16, Howard Chu wrote: > Dave Korn wrote: >> On 12 November 2006 03:35, Howard Chu wrote: >> >> >>> If we go through the temporary variable v, there's no warning. If we >>> don't use the temporary variable, we get the "might break" message. >>> >> >> Try >> >> >>> f = (struct foo *)(void *)buf; >>> >> >> > That's good, but why is it safe? Passing through void* means gcc has to assume it could alias anything, IIUIC, as a result of the standard allowing implicit void*<=>T* conversions. cheers, DaveK -- Can't think of a witty .sigline today
bootstrap failure on HEAD
I see this on linux but not on cygwin: make[3]: Leaving directory `/home/dk/gnu/obj' Comparing stages 2 and 3 warning: ./cc1-checksum.o differs warning: ./cc1plus-checksum.o differs warning: ./cc1obj-checksum.o differs Bootstrap comparison failure! ./cfg.o differs ./cfgloopanal.o differs ./loop-iv.o differs ./predict.o differs ./profile.o differs ./value-prof.o differs ./ipa-inline.o differs make[2]: *** [compare] Error 1 make[2]: Leaving directory `/home/dk/gnu/obj' make[1]: *** [stage3-bubble] Error 2 make[1]: Leaving directory `/home/dk/gnu/obj' make: *** [all] Error 2 [EMAIL PROTECTED] obj]$ ../gcc/config.guess i686-pc-linux-gnu [EMAIL PROTECTED] obj]$ uname -a Linux pepper.cam.artimi.com 2.4.18-14 #1 Wed Sep 4 13:35:50 EDT 2002 i686 i686 i386 GNU/Linux [EMAIL PROTECTED] obj]$ Is it just me, or does anyone else get this? I objdump'd and diff'd the stage2 and stage3 versions of cfg.o and it seems to have developed a habit of inserting 'shrd'/'shld' opcodes: @@ -8895,8 +8896,10 @@ : : 11 4c 24 34 %ecx,0x34(%esp,1) : 8b 5c 24 34 mov0x34(%esp,1),%ebx : 8b 4c 24 30 mov0x30(%esp,1),%ecx -: c1 e0 10shl$0x10,%eax : 8b 54 24 44 mov0x44(%esp,1),%edx +: 0f ac d9 01 shrd $0x1,%ebx,%ecx +: 0f a4 c2 10 shld $0x10,%eax,%edx +: c1 e0 10shl$0x10,%eax : d1 fb sar%ebx : 01 c8 %ecx,%eax : 11 da %ebx,%edx although disturbingly enough there's a missing 'lea' too: @@ -8968,29 +8971,29 @@ : : 31 d2 xor%edx,%edx : 01 c8 %ecx,%eax : 11 da %ebx,%edx +: 0f ac d0 10 shrd $0x10,%edx,%eax : c1 fa 10sar$0x10,%edx : 83 fe f8cmp$0xfff8,%esi : 89 46 30mov%eax,0x30(%esi) : 89 56 34mov%edx,0x34(%esi) -: 0f 84 62 03 00 00 je +: 0f 84 66 03 00 00 je : 8b 76 08mov0x8(%esi),%esi : 85 f6 test %esi,%esi : 89 74 24 60 mov%esi,0x60(%esp,1) -: 0f 85 ce 03 00 00 jne +: 0f 85 d2 03 00 00 jne : 31 c9 xor%ecx,%ecx : 31 ed xor%ebp,%ebp : 31 d2 xor%edx,%edx : 31 c0 xor%eax,%eax -: 8d b4 26 00 00 00 00lea0x0(%esi,1),%esi : 39 c1 cmp%eax,%ecx -: 0f 84 76 03 00 00 je +: 0f 84 81 03 00 00 je cheers, DaveK -- Can't think of a witty .sigline today
RE: bootstrap failure on HEAD
On 12 November 2006 16:50, H. J. Lu wrote: > On Sun, Nov 12, 2006 at 02:44:36PM -0000, Dave Korn wrote: >> Comparing stages 2 and 3 >> warning: ./cc1-checksum.o differs >> warning: ./cc1plus-checksum.o differs >> warning: ./cc1obj-checksum.o differs >> Bootstrap comparison failure! >> ./cfg.o differs >> ./cfgloopanal.o differs >> ./loop-iv.o differs >> ./predict.o differs >> ./profile.o differs >> ./value-prof.o differs >> ./ipa-inline.o differs >> make[2]: *** [compare] Error 1 > Gcc mainline may miscompile gcc when -O2 is used. See > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680 > > I have no problems on x86, x86-64 and ia64 with revision 118723 today > after reverting revision 117986. Can you try > > http://gcc.gnu.org/bugzilla/attachment.cgi?id=12574 Hi H.J., I updated to the revision you said, tried a clean bootstrap and verified the bug was still present, then applied your patch, and continued the bootstrap. I still get the same problem, so I have to conclude that Dorit is most likely correct to suggest the host compiler is at fault: I have been using 3.2 Reading specs from /usr/lib/gcc-lib/i386-redhat-linux/3.2/specs Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --enable-shared --enable-threads=posix --disable-checking --host=i386-redhat-linux --with-system-zlib --enable-__cxa_atexit Thread model: posix gcc version 3.2 20020903 (Red Hat Linux 8.0 3.2-7) Since 3.x is dead, I'm not going to investigate, I'll just try using an intermediate 4.1 to get going. Thanks for the suggestion. cheers, DaveK -- Can't think of a witty .sigline today
RE: Abt long long support
On 10 November 2006 22:31, 'Rask Ingemann Lambertsen' wrote: > On Fri, Nov 10, 2006 at 07:11:34PM -0000, Dave Korn wrote: > >> No, surely you don't want to do that! You really need a movdi pattern - >> even more so if there are no natural DImode-sized registers, as gcse can >> get terribly confused by bad reg_equal notes if you don't. See e.g.: >> >> http://gcc.gnu.org/ml/gcc/2003-04/msg01397.html >> http://gcc.gnu.org/ml/gcc/2004-06/msg00993.html > >PR number? None that I could find. Most of the backends in mainline already have movdi patterns, this is the sort of problem you only run into when you're developing a custom backend. The only backends that don't define movdi (or indeed any DImode instructions) are avr c4x dsp16xx h8300 mn10200 stormy16 I don't know if it might be possible to demonstrate the problem on one of those platforms, I haven't tried. cheers, DaveK -- Can't think of a witty .sigline today
RE: How to create both -option-name-* and -option-name=* options?
On 11 November 2006 00:14, Brooks Moses wrote: > Dave Korn wrote: >> On 10 November 2006 21:18, Brooks Moses wrote: >> I think that for this one case we should just say that you have to supply >> both forms -ffixed-line-length-none and -ffixed-line-length=none. > > Which I would be glad to do, except that as far as I can tell, it's not > possible to actually do that. The same problem arises there as arises > when it doesn't have "none" on the end and "Joined" in the specification. Oh of couse. Hey, isn't this where I came in? >> What you have here is really a joined option that has an argument that >> can be either a text field or an integer, and to save the trouble of >> parsing the field properly you're playing a trick on the options parser by >> specifying something that looks to the options machinery like a longer >> option with a common prefix, but looks to the human viewer like the same >> option with a text rather than integer parameter joined. > > Right, agreed. Though it's not so much "to save the trouble" as "to be > able to leverage all the useful things the option parser does to verify > numeric fields". All the more reason to give the option parser even more useful things that it does that can be leveraged. > And, given that adding support for both string and numeric values looks > fairly easy (much more so than I would have guessed), that's probably > the better way to go. A UIntegerOrString property would be incompatible > with the Var property, since it would need two variables for storing the > result, but I think this is not a notable loss since the combination of > Var and UInteger is already rare -- the only flag that uses them both is > -fabi-version. > > Or, given that the only thing that appears to use this at the moment is > this old g77-style fixed-line-length Fortran option that we're only > supporting for legacy purposes, I suppose we could just go for the > cop-out of supporting the "-none" version and not the "=none" version, > and only document it as accepting "=0". Your choice; there's only a limited need to support ancient compile flags. Actually, perhaps you should fix this simply, by using a specs to rewrite the =none version into the -none version. Is there not a Fortran equivalent of CC1_SPEC/CC1PLUS_SPEC/... ? cheers, DaveK -- Can't think of a witty .sigline today
RE: Abt long long support
On 13 November 2006 12:27, Mohamed Shafi wrote:
> (insn 94 91 95 6 (set (reg:SI 12 a4)
> (mem/c:SI (reg:SI 12 a4) [0 D.1863+0 S4 A32])) 15 {movsi_load} (nil)
> (nil))
>
> (insn 95 94 31 6 (set (reg:SI 13 a5 [orig:12+4 ] [12])
> (mem/c:SI (plus:SI (reg:SI 12 a4)
> (const_int 4 [0x4])) [0 D.1863+4 S4 A32])) 15 {movsi_load}
> (nil) (nil))
> As you can see insns 90,91,94 and 95 are inserted in this pass, and
> the code goes wrong in insns 95/94
>
> Why are these insns inserted in between ?
It is a bug. Reload is not too clever when it comes to synthesizing DI
sized instructions from SI sized insns. Here, it is trying to reload a DI
sized variable into registers from a stack slot (I'm guessing r14 is your SP,
yes?). It is trying to implement (set (reg:DI 12) (mem:DI (reg:SI 12))).
This would be fine if reload understood that in DImode, r12 includes r13, or
if it thought that the input operand had to be an earlyclobber, in which case
it could not allocate an overlapping range or it could re-order the loads.
But it doesn't, and it gets it wrong.
> With only subdi3 and adddi3 pattern available in the md file, and no
> other define_split or define_insns or define_expand for DI mode, how
> can i control the instructions generated due to reload?
You *must* implement a movdi expander, and it has to be clever enough to
notice when one of the output registers is going to clobber one of the input
operands and emit the two SImode halves of the move in the opposite order.
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: Abt long long support
On 13 November 2006 12:37, Dave Korn wrote: > You *must* implement a movdi expander, and it has to be clever enough to > notice when one of the output registers is going to clobber one of the input > operands and emit the two SImode halves of the move in the opposite order. Take a look at, e.g., rs6000.md, the way that movdi is an expander that calls rs6000_emit_move to emit a (set (xxx:DI ) (xxx:DI)) which is then recognized by *movdi_internal32 which takes care to emit two SI-sized move opcodes in the right order. Doing this also avoids a bug in the interpretation of REG_EQUAL notes when applied to SI mode SUBREGs of DI mode REGs during cse, at least in 3.3.3 it does. cheers, DaveK -- Can't think of a witty .sigline today
RE: GCSE again: bypass_conditional_jumps -vs- commit_edge_insertions - problem with ccsetters?
On 02 November 2006 01:38, Roger Sayle wrote: > On Tue, 31 Oct 2006, Dave Korn wrote: >> Tracking down a gcse bug while unrolling a loop where the count is >> known to be one, I've narrowed the problem down to the actions of >> commit_edge_insertions and bypass_conditional_jumps, and I could use >> a little help in appreciating the reasoning behind what they're /trying/ >> to do. > > Sorry for the delay, but I only read the "gcc" list infrequently and > have only just seen your question. Sorry for the delay, but it's taken me a little time to dig further into this :) > I suspect that somewhere this is falling foul of some other CFG related > optimization that says if both branches of a conditional jump go the same > label, then the conditional jump is redundant and can be replaced by an > unconditional jump. One the CFG believes that BB#2 has only one sucessor, > then commit_edge_insertions is free to place things there. I think you're right, and I think I've tracked it down. I think it is another manifestation of PR13859, which is fixed on mainline since 2004-01-28; to quote the comment from the patch, + /* Avoid unification of the edge with other edges from original +branch. We would end up emitting the instruction on "both" +edges. */ I was slightly misled for a while by the debug output that says: Replacing insn 100 by jump 115 JUMP-BYPASS: Proved reg 74 in jump_insn 22 equals constant (const_int 0 [0x0]) Bypass edge from 2->4 to 6 because reg 74 in jump_insn 22 actually is (const_int 1), having just been incremented; but in fact, it is only the debug output that is incorrect, as it does not allow for the possibility of the (not) cc-setting insn affecting the value of the register. This possibility /is/ correctly allowed for in calculating which way the branch will go, it's just that the original value of the set found at the end of the predecessor block is what gets dumped out. The fix for 13859 solves my bug, although at the cost of leaving the actual loop structure present in the final output, which isn't perfect, because the compiler should be able to know that the loop is only going to run once, but it is at least correct. cheers, DaveK -- Can't think of a witty .sigline today
RE: Threading the compiler
On 14 November 2006 01:51, Geert Bosch wrote: > On Nov 11, 2006, at 03:21, Mike Stump wrote: >> The cost of my assembler is around 1.0% (ppc) to 1.4% (x86) >> overhead as measured with -pipe -O2 on expr.c,. If it was >> converted, what type of speedup would you expect? > > Given that CPU usage is at 100% now for most jobs, such as > bootstrapping GCC, there is not much room for any improvement > through threading. To be fair, Mike was talking about multi-core SMP, not threading on a single cpu, so given that CPU usage is at 100% now for most jobs, there is an Nx100% speedup to gain from using 1 thread on each of N cores. > The main place where threading may make sense, especially > with LTO, is the linker. This is a longer lived task, and > is the last step of compilation, where no other parellel > processes are active. Moreover, linking tends to be I/O > intensive, so a number of threads will likely be blocked > for I/O. I'm not really sure how this would play with SMP (as opposed to threading). I don't see why you think threading could be particularly useful in the linker? It's the pipeline of compiler optimisation passes that looks like an obvious candidate for threading to me. cheers, DaveK -- Can't think of a witty .sigline today
RE: GCC Garbage Collection
On 14 November 2006 03:30, Mike Stump wrote: > On Nov 13, 2006, at 5:23 PM, Brendon Costa wrote: >> At most there is about 40 lines of code in each of them. > > PCH is when you have 500,000 lines of C++ code in the main .h file, > and 20 lines in the .C file. :-) Nonono, PCH is when you have 6 lines in the .C file, *one* line in the main.h file, and 500,000 lines in the seventeen nested recursive levels of standard headers that are pulled in by that single "#include " in the main .h file! Or IOW, it's *ideally* suited for compiling hello.C! cheers, DaveK -- Can't think of a witty .sigline today
RE: Threading the compiler
On 14 November 2006 18:30, Ian Lance Taylor wrote: > "Dave Korn" <[EMAIL PROTECTED]> writes: > >>> The main place where threading may make sense, especially >>> with LTO, is the linker. This is a longer lived task, and >>> is the last step of compilation, where no other parellel >>> processes are active. Moreover, linking tends to be I/O >>> intensive, so a number of threads will likely be blocked >>> for I/O. >> >> I'm not really sure how this would play with SMP (as opposed to >> threading). I don't see why you think threading could be particularly >> useful in the linker? It's the pipeline of compiler optimisation passes >> that looks like an obvious candidate for threading to me. > > It's irrelevant to the main discussion here, but in fact there is a > fair amount of possible threading in the linker proper, quite apart > from LTO. The linker spends a lot of time reading large files, and > the I/O wait can be parallelized. That's not even thread-worthy, that just required bog-standard AIO techniques. Um, /are/ there suitably portable AIO techniques? I guess the answer is going to be "Yeah, spawn a posix thread and make an ordinary synchronous f* io call in there"! Heh. > And the linker spends a reasonable > amount of time computing relocations, which can be parallelized such > that the relocations for each input file are computed independently. Ooh yes, big win to be had there. cheers, DaveK -- Can't think of a witty .sigline today
RE: Threading the compiler
On 14 November 2006 15:38, Robert Dewar wrote: > Geert Bosch wrote: > >> Given that CPU usage is at 100% now for most jobs, such as >> bootstrapping GCC, there is not much room for any improvement >> through threading. > > Geert, I find this a bit incomprehensible, the whole point > of threading is to increase CPU availability by using > multiple cores. Geert's followup explained this seeming anomaly: he means that the crude high-level granularity of "make -j" is enough to keep all cpus busy at 100%, and I'm fairly persuaded by the arguments that, at the moment, that's sufficient in most circumstances to get 99% of the benefit there to be had. I suspect that the balance will tip when the number of cores starts to get huge, and that at some time in the future we would benefit of the extra parallelizability we could get from reducing the effective scheduling granularity by threading the compiler. cheers, DaveK -- Can't think of a witty .sigline today
RE: Threading the compiler
On 14 November 2006 19:40, Joe Buck wrote: > On Tue, Nov 14, 2006 at 07:15:19PM -0000, Dave Korn wrote: >> Geert's followup explained this seeming anomaly: he means that the crude >> high-level granularity of "make -j" is enough to keep all cpus busy at >> 100%, and I'm fairly persuaded by the arguments that, at the moment, that's >> sufficient in most circumstances to get 99% of the benefit there to be had. > > Currently the serial step is linking, and for the typical builds I do it > is the bottleneck as the c/c++ -> o step is highly parallelizable. Figure > out how to make the linker parallel, and then we can talk. I was only talking in terms of the benefit to be had vs. threading the linker! cheers, DaveK -- Can't think of a witty .sigline today
RE: 4.1.1 spec files missing, FAQ misinformation
On 19 November 2006 16:07, Gerald Pfeifer wrote: > On Wed, 4 Oct 2006, Daniel Jacobowitz wrote: "This file can be found in the same directory that contains cc1 (run gcc -print-prog-name=cc1 to find it)." >>> I think that indicates someone trying to be overly clever when they >>> configured your gcc package. Normally libdir and libexecdir point to the >>> same dir. What output do you see from "gcc -v"? >> Not any more. The default changed some time ago. Some distributors >> configure them to the same location. >> >> Jeff, for background, up until a few releases ago cc1 and specs would >> always be in the same directory. > > Daniel, Dave, if one of you could have a look at > http://gcc.gnu.org/faq.html#rpath > and update that, that would be great! If you prefer, just provide any > edits/changes to me, and I'll take care of updating that web page, markup > and committing. > > Thanks, > > Gerald I'm not quite sure how we tell people where to find the right default directory for it anymore. Did libgcc move to libdir from libexecdir as well? Otherwise I can't think of any file that's guaranteed to be there to look for with -print-file-name. Modulo that minor difficulty, here's a proposed re-wording: However, if you feel you really need such an option to be passed automatically to the linker, you can create a GCC specs file and add it there. The http://gcc.gnu.org/onlinedocs/gcc/Spec-Files.html#Spec-Files"specs file is the mechanism used by gcc to control which options are passed to which of the sub-stages of compiling, assembling and linking; GCC normally operates according to a built-in set of specs, but these defaults can be overridden by providing an external specs file. This file can either be passed to the compiler by supplying the --specs= option, or can be placed in the same directory that contains (run gcc -print-file-name=??? to find it), where gcc will locate and use it automatically every time it runs. You can then add linker flags such as -R or -rpath, depending on platform and linker, to the *link or *lib specs. cheers, DaveK -- Can't think of a witty .sigline today
RE: Invoking static library automatically
On 01 December 2006 08:13, Eric Botcazou wrote: >> I have built a static runtime library and i want the linker to access >> it automatically without having to pass it explicitly. > > Wrong list, this one is for GCC development, not development with GCC. So, the answer from this list is "add it to LINK_SPEC, then rebuild the compiler" :) cheers, DaveK -- Can't think of a witty .sigline today
RE: Char shifts promoted to int. Why?
On 18 December 2006 19:31, Robert Dewar wrote: > Chris Lattner wrote: > >> Thus, the transformation is safe in this specific case on i386. >> However, shifting a 32-bit value left by 33 bits would not be safe. > > That's the case where the transformation IS safe, since shifting a > 32-bit value left by 33 bits gives an undefined result as I understand > things. Only a compiler developer could say "It's safe because it's undefined so it doesn't matter what it does"! :) I'm fairly sure most /users/ would call undefined behaviour dangerous... cheers, DaveK -- Can't think of a witty .sigline today
RE: [RFC] ordered comparison of pointer with integer zero warning in Wextra
On 17 December 2006 12:56, Manuel López-Ibáñez wrote:
> Currently Wextra warns about a pointer compared against integer zero
> with <, <=, >, or >=. This warning is not available in C++ (the
> documentation does not say this) and it is implemented in
> gcc/c-typeck.c (build_binary_op) in this manner:
>
> else if (code0 == POINTER_TYPE && null_pointer_constant_p (orig_op1))
> {
> result_type = type0;
> if (pedantic || extra_warnings)
> pedwarn ("ordered comparison of pointer with integer zero");
> }
> else if (code1 == POINTER_TYPE && null_pointer_constant_p (orig_op0))
> {
> result_type = type1;
> if (pedantic)
> pedwarn ("ordered comparison of pointer with integer zero");
> }
>
> That is, given int *p and -Wextra, the above code warns for p < 0 but
> not for 0 > p. Given -pedantic, we warn for both situations. This is
> also the only warning activated by both pedantic and -Wextra.
>
> Taking into account the above, is there a reason for this?
Looks like an oversight, the changelog doesn't suggest it would be intended
to work that way:
http://gcc.gnu.org/viewcvs?view=rev&revision=9580
(build_binary_op): Also warn about ordered comparison of pointer with
zero if -Wall.
Nothing to suggest the asymmetry was intentional, but of course it could have
been.
> For me, the
> best would be to NOT enable the warning for Wextra, so I don't need to
> come up with a name for this warning flag. Otherwise, we would have to
> document that the warning is enabled by both pedantic and Wextra, so a
> user won't be surprised when the warning does not go away by using the
> Wno-* form just because pedantic is enabled.
Well, the intent was clearly to enable the warning for Wall (later Wextra) in
addition to pedantic, so I would suggest that in the absence of a positive
reason to revert it, you should extend the second clause to cover Wextra as
well.
Heh. Or you could always make it a divide-by-zero error instead :)
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: [RFC] ordered comparison of pointer with integer zero warning in Wextra
On 20 December 2006 00:39, Manuel López-Ibáñez wrote: > On 20/12/06, Dave Korn <[EMAIL PROTECTED]> wrote: >> Heh. Or you could always make it a divide-by-zero error instead :) > > Oh, sorry. I didn't get this. If you would be so kind to elaborate... Possibly the world's only attempt ever at C pointer-arithmetic humour, and now we know why. Ordered comparison of pointers amounts to pointer subtraction which is done in units of the size of the pointed-to type and the sizeof void is zero[*]. cheers, DaveK [*] - Or conceivably NaN. -- Can't think of a witty .sigline today
RE: GCC optimizes integer overflow: bug or feature?
On 20 December 2006 02:28, Andrew Pinski wrote: >> Paul Brook wrote: Compiler can optimize it any way it wants, as long as result is the same as unoptimized one. >>> >>> We have an option for that. It's called -O0. >>> >>> Pretty much all optimization will change the behavior of your program. >> >> Now that's a bit TOO strong a statement, critical optimizations like >> register allocation and instruction scheduling will generally not change >> the behavior of the program (though the basic decision to put something >> in a register will, and *surely* no one suggests avoiding this critical >> optimization). > > Actually they will with multi threaded program, since you can have a case > where it works and now it is broken because one thread has speed up so much > it writes to a variable which had a copy on another thread's stack. Why isn't that just a buggy program with wilful disregard for the use of correct synchronisation techniques? cheers, DaveK -- Can't think of a witty .sigline today
RE: GCC optimizes integer overflow: bug or feature?
On 20 December 2006 02:40, Mike Stump wrote: > On Dec 19, 2006, at 6:33 PM, Dave Korn wrote: >> On 20 December 2006 02:28, Andrew Pinski wrote: >> >>>> Paul Brook wrote: >>>>>> Compiler can optimize it any way it wants, >>>>>> as long as result is the same as unoptimized one. >>>>> >>>>> We have an option for that. It's called -O0. >>>>> >>>>> Pretty much all optimization will change the behavior of your >>>>> program. >>>> >>>> Now that's a bit TOO strong a statement, critical optimizations like >>>> register allocation and instruction scheduling will generally not change >>>> the behavior of the program (though the basic decision to put something >>>> in a register will, and *surely* no one suggests avoiding this critical >>>> optimization). >>> >>> Actually they will with multi threaded program, since you can have a case >>> where it works and now it is broken because one thread has speed up so >>> much it writes to a variable which had a copy on another thread's stack. >> >> Why isn't that just a buggy program with wilful disregard for the use of >> correct synchronisation techniques? > > It is that, as well as a program that features a result that is > different from unoptimized code. Well, I for one wish to complain. All the empty for loops that I use for precision timing have been getting faster and faster over the past few years. It used to take several minutes for i to count from one to a hundred million. Now it seems to take no time at all! cheers, DaveK -- Can't think of a witty .sigline today
RE: GCC optimizes integer overflow: bug or feature?
On 20 December 2006 16:25, Matthew Woehlke wrote:
> Dave Korn wrote:
>> On 20 December 2006 02:28, Andrew Pinski wrote:
>>>> Paul Brook wrote:
>>>>> Pretty much all optimization will change the behavior of your program.
>>>>
>>>> Now that's a bit TOO strong a statement, critical optimizations like
>>>> register allocation and instruction scheduling will generally not change
>>>> the behavior of the program (though the basic decision to put something
>>>> in a register will, and *surely* no one suggests avoiding this critical
>>>> optimization).
>>>
>>> Actually they will with multi threaded program, since you can have a case
>>> where it works and now it is broken because one thread has speed up so
>>> much it writes to a variable which had a copy on another thread's stack.
>>> So the argument about it being too strong is wrong because timing matters
>>> now a days. Instruction scheduling can cause the same issue as it forces
>>> a write too early for another thread to act on.
>>
>> Why isn't that just a buggy program with wilful disregard for the use of
>> correct synchronisation techniques?
>
> Excuse me while I beat you on the head with a number of real-life
> examples of *lock-free* algorithms. :-)
Thanks, I've heard of them, in fact I've implemented many, debugged many,
and currently work with several every single day of the week.
> Particularly lock-free queues
> (google should help you find one that applies here), whose correct
> operation is critically dependent on the order in which the loads and
> stores are performed.
No, absolutely not. Lock-free queues work by (for example) having a single
producer and a single consumer, storing the queue in a circular buffer, and
assigning ownership of the queue's head pointer to the producer and the
(chasing) tail pointer to the consumer. The whole point about lock-free
algorithms is that they are guaranteed to work *regardless* of the order of
operations between the two asynchronous processes that interact with the
queue, given only the ability to perform an atomic read or write. The
ordering is critical within a single thread of execution; e.g. you must fill
in all the details of the new entry you are adding to the queue /before/ you
increment the head pointer, whereas in a locking algorithm it wouldn't matter
if you incremented the head pointer first, then filled in the blank entry you
had just moved it past, because you'd do both within the lock.
If you design a lock-free algorithm that relies on two threads being
precisely synchronised, it's not really lock-free, it just has 'implicit'
locking; and if your precise synchronisation depends on the precise
cycle-timing of low-level instruction sequences, you have made a very very
fragile design that works, if it does, by good fortune.
> This is a very real, entirely legitimate example
> where the compiler thinking it knows how to do my job better than I do
> is wrong.
Nope, this is a very real example of a bug in your algorithmic design, or of
you misleading the compiler, or relying on undefined or implementation-defined
behaviour.
> We (in a major, commercial application) ran into exactly this issue.
> 'asm volatile("lock orl $0,(%%esp)"::)' is your friend when this happens
> (it is a barrier across which neither the compiler nor CPU will reorder
> things). Failing that, no-op cross-library calls (that can't be inlined)
> seem to do the trick.
This simply means you have failed to correctly declare a variable volatile
that in fact /is/ likely to be spontaneously changed by a separate thread of
execution.
And relying on a library call to act as a memory barrier is risky. The only
way in which it works is because it takes long enough that there's enough time
for the CPU's load-store unit to have completed any posted writes, but if (for
a contrived example) you're using a cut-down embedded library and the
particular routine that you call happens to be a stub and just returns
immmediately, you've got a two-instruction call-return sequence that very
seriously is not a guarantee of externally-visible memory access ordering.
Now, the compiler *does* know not to optimise moves across library calls, but
you're investing too much trust in them if you think the CPU's internal units
know or care whether you're in a libcall or your mainline code.
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: GCC optimizes integer overflow: bug or feature?
On 20 December 2006 20:16, Seongbae Park wrote:
> On 12/20/06, Dave Korn <[EMAIL PROTECTED]> wrote:
> ...
>>> We (in a major, commercial application) ran into exactly this issue.
>>> 'asm volatile("lock orl $0,(%%esp)"::)' is your friend when this happens
>>> (it is a barrier across which neither the compiler nor CPU will reorder
>>> things). Failing that, no-op cross-library calls (that can't be inlined)
>>> seem to do the trick.
>>
>> This simply means you have failed to correctly declare a variable
>> volatile that in fact /is/ likely to be spontaneously changed by a
>> separate thread of execution.
>
> The C or C++ standard doesn't define ANYTHING related to threads,
> and thus anything related to threads is beyond the standard.
> If you think volatile means something in an MT environment,
> think again.
No no, I fully appreciate that; what volatile means is simply that the
object may change outside the control or knowledge of the compiler, the
particular mechanism does not matter at all, and that is all that is relevant
for the purpose of my argument.
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: GCC optimizes integer overflow: bug or feature?
On 20 December 2006 21:42, Matthew Woehlke wrote: > Dave Korn wrote: >>> Particularly lock-free queues whose correct >>> operation is critically dependent on the order in which the loads and >>> stores are performed. >> >> No, absolutely not. Lock-free queues work by (for example) having a >> single producer and a single consumer, storing the queue in a circular >> buffer, and assigning ownership of the queue's head pointer to the >> producer and the (chasing) tail pointer to the consumer. >> [snip] >> The ordering is critical within a single thread of execution; e.g. you must >> fill in all the details of the new entry you are adding to the queue >> /before/ you increment the head pointer, > > Exactly. Guess what the compiler did to us? :-) "Oh, no, I'm /sure/ it's > OK if I re-order your code so that those assignments happen /after/ I > handle this dinky little increment for you." Now our code may have been > wrong in this instance Exactly and unquestionably so. You wrote wrong code, it worked not how you expected it, but the compiler *did* do exactly as you told it to and there's an end of it. You left out 'volatile', you completely lied to and misled the compiler! > Let's be clear. Order matters. /You/ said so yourself. :-) And even if > the programmer correctly tells the compiler what to do, what (unless the > compiler inserts memory barriers) keeps the CPU from circumventing both? You wrote wrong code, it worked not how you expected it, but the compiler *did* do exactly as you told it to and there's an end of it. You left out 'volatile', you completely lied to and misled the compiler about what /it/ could assume about the behaviour of entities in the compiled universe. > That said, I've seen even stranger things, too. For example: > > foo->bar = make_a_bar(); > foo->bar->none = value; > > being rendered as: > > call make_a_bar > foo->bar->none = value > foo->bar = > > So what was wrong with my C code in that instance? :-) You'd have to show me the actual real code before I could tell you whether there was a bug in your code or you hit a real bug in the compiler. Either is possible; the virtual machine definition in the standard AKA the 'as-if' rule is what decides which is correct and which is wrong. C is no longer a glorified shorthand for assembly code. It did /used to be/, but every development since K'n'R days has taken it further from that. At -O0, it still /almost/ is a glorified assembler. >>> This is a very real, entirely legitimate example >>> where the compiler thinking it knows how to do my job better than I do >>> is wrong. >> >> Nope, this is a very real example of a bug in your algorithmic design, >> or of you misleading the compiler, or relying on undefined or >> implementation-defined behaviour. [snip] >> This simply means you have failed to correctly declare a variable >> volatile that in fact /is/ likely to be spontaneously changed by a >> separate thread of execution. > > /That/ is very possible. I'm talking about /OLD/ code here, i.e. code > that was written back in K&R days, back before there /was/ a volatile > keyword. (Although I had understood that 'volatile' was a no-op in most > modern compilers? Does it have the semantics that loads/stores of > volatile variables are not re-ordered with respect to each other?) Exactly so, that's why 'volatile' was chosen as the keyword to extend 'asm' in order to mean "don't reorder past here because it's unpredictable". As I said, C is no longer a glorified assembler language, and one of the main motivations behind that progression is the non-portability of code such as you describe above, the fact that making assumptions about the precise details behind a compiled version of any particular code sequence is a mistake because they'll only turn out to be right on some platforms and with some compiler versions and not with others. The compiler is *not* a glorified assembler; if you really want guarantees about what codegen you get, use a .S file and write assembler. Or use a 20-year-old version of the compiler if what you *really* want is the exact codegen it used to do 20 years ago. It's open source, it's free, you can get it and use it and keep on using it for ever and it will *always* produce exactly what you expect by the way of codegen. These days, however, you have to accept that your code is not valid; that it contains implicit assumptions that were only ever going to be true for the particular compiler version and on the particular platform where it was first writt
RE: GCC optimizes integer overflow: bug or feature?
On 21 December 2006 02:50, Gabriel Dos Reis wrote: > Andrew Haley <[EMAIL PROTECTED]> writes: > > [...] > >> C is no longer a kind of high-level assembly laguage: >> it's defined by a standard, in terms of an abstract machine, and some >> operations are not well-defined. > > that does not mean C is not a kind of high-level assembly language. > :-/ > > -- Gaby I swear, I wrote my previous two mails before I read this exchange! cheers, DaveK -- Can't think of a witty .sigline today
[GCCWIKI] password reset borken?
Afternoon all,
I was trying to recover my password for the gcc wiki, and it doesn't work:
when I enter my email and click the button, I see an error message at the top
of the page saying:
{u'[EMAIL PROTECTED]': (550, 'relaying denied')}
I believe this is reporting an error at the sourceware/gcc machine because I
have no problem receiving any other mail from external sources, so I don't
think it's our server generating the error. Is whoever administers the wiki
around? Could you take a quick look at it for me? TIA!
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: Char shifts promoted to int. Why?
On 21 December 2006 21:54, Ayal Zaks wrote: >> Something along these lines may be useful to do in the vectorizer when we >> get code like this: > ((char)x) = ((char)( ((int)((char)x)) << >> ((int)c) ) ) >> and don't feel like doing all the unpacking of chars to ints and then >> packing the ints to chars after the shift. An alternative could be to >> transform the above pattern to: >> char_x1 = 0 >> char_x2 = char_x << c >> char_x = ((int)c < size_of_char) ? char_x2 : char_x1 >> and vectorize that (since we already know how to vectorize selects). > > Alternatively, do > char_c2 = (c < size_of_char ? c : 0) > char_x2 = char_x << char_c2 > which is like saturating the shift amount. You don't really mean zero as the third operand of that ternary operator, you want size_of_char. cheers, DaveK -- Can't think of a witty .sigline today
RE: GCC optimizes integer overflow: bug or feature?
On 22 December 2006 00:59, Denis Vlasenko wrote: > Or this, absolutely typical C code. i386 arch can compare > 16 bits at a time here (luckily, no alighment worries on this arch): Whaddaya mean, no alignment worries? Misaligned accesses *kill* your performance! I know this doesn't affect correctness, but the coder might well have known that the pointer is unaligned and written two separate byte-sized accesses on purpose; volatile isn't the answer because it's too extreme, there's nothing wrong with caching these values in registers and they don't spontaneously change on us. cheers, DaveK -- Can't think of a witty .sigline today
RE: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
On 30 December 2006 11:49, Robert Dewar wrote: > Paul Eggert wrote: Nor would I relish the prospect of keeping wrapv assumptions out of GCC as other developers make further contributions, as the wrapv assumption is so natural and pervasive. >>> It's neither natural not pervasive to me! I would never write code >>> that way >> >> That's great, but GCC has had many other hands stirring the pot. >> I daresay a careful scan would come up with many other examples of >> undefined behavior due to signed integer overflow. (No doubt >> you'll be appalled by them as well, but there they are.) > > Not so appalling really, given that relying on wrapping is as > has been pointed out in this thread, the most natural and > convenient way of testing for overflow. It is really *quite* > difficult to test for overflow while avoiding overflow, and > this is something that is probably not in the lexicon of > many C programmers. Maybe the answer (as far as autoconf goes) is that autoconf tests should be compiled at -O0. They are trying to determine the underlying machine behaviour; -O0 makes gcc more like the glorified-assembler model of a compiler. Which is probably what we want; the code to actually execute on the target, not for the compiler to deduce what it would do if it did run and maybe get it wrong. (Maybe they could be compiled at -O0 *and* at -O2, and the results compared, to infer overflow behaviour and decide whether to add -fwrapv to the generated CFLAGS?) cheers, DaveK -- Can't think of a witty .sigline today
RE: changing "configure" to default to "gcc -g -O2 -fwrapv ..."
On 31 December 2006 18:47, Paul Eggert wrote: > "Daniel Berlin" <[EMAIL PROTECTED]> writes: > The question is not whether GCC should support wrapv > semantics; it already does, if you specify -fwrapv. > The question is merely whether wrapv should be the default > with optimization levels -O0 through -O2. Maybe we need to make it a trinary, like -Wstrict-aliasing. Then we would turn on -fwrapv=1 at -O2, and we would only need to argue about which wrap-assuming optimisations were suitable for level 1 and which weren't. cheers, DaveK -- Can't think of a witty .sigline today
RE: gcc, mplayer and profile (mcount)
On 03 January 2007 19:08, Adam Sulmicki wrote: > On Wed, 3 Jan 2007, Ian Lance Taylor wrote: > >> I told you was to use the gcc-help mailing list, which was correct. > >> So this seems to be a bug in gcc: it should be calling _mcount. > > It just that it is my impression that gcc list is more > appropriate for gcc bugs than gcc-help. Is that your idea of an apology? Regardless of topicality there's no reasonable reading of Ian's words as a flame, they were entirely polite and well-measured, and you should withdraw your baseless accusation and say sorry rather than trying to rationalise it. cheers, DaveK -- Can't think of a witty .sigline today
RE: RFC: Walways-true considered harmful
On 13 January 2007 12:55, Rask Ingemann Lambertsen wrote:
> On Sat, Jan 13, 2007 at 04:08:18AM +, Manuel López-Ibáñez wrote:
>
>> Much later, the warning was given a name, Walways-true [3], since the
>> warning message said explicitly that something will always be true.
>> However, Andrew Morton didn't want to get a warning just because the
>> expression was always true. He wanted to be warned of using the
>> address of a function where it makes more sense to call the function.
>
>Also, while it will be good to warn about
>
> if (func)
> {
> ...
> }
>
> it'll be bad to warn about
>
> if (timerstruct->callbackfunc)
> {
> ...
> timerstruct->callbackfunc (...);
> ...
> }
>
And equally bad to warn about
> if (func)
> {
> ...
func (...);
> ...
> }
Did you mean to limit it specifically to struct members?
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: RFC: Walways-true considered harmful
On 13 January 2007 14:00, Dave Korn wrote:
> On 13 January 2007 12:55, Rask Ingemann Lambertsen wrote:
>
>>
>> if (func)
>> {
>> ...
>> }
>>
>> it'll be bad to warn about
>>
>> if (timerstruct->callbackfunc)
>> {
>> ...
>> timerstruct->callbackfunc (...);
>> ...
>> }
>>
>
> And equally bad to warn about
>
>> if (func)
>> {
>> ...
> func (...);
>> ...
>> }
Nope, hang on.. that first 'func' is an explicit function name, the second
two cases are meant to be variables... I don't see why it should be any
problem to only warn for explicit function names.
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: Performance of gcc 4.1 vs gcc 3.4
On 15 January 2007 15:02, ying lcs wrote: > Hi, > > Can you please tell me if there is any performance gain in the output > program if i switch from gcc 3.4 to gcc 4.1 on Red hat Enterprise > linux 4? > > Thank you. Yes, you can expect at least a 20dB gain in SNR, a 12% increase in miles per gallon, a 147% increase in thermal output per btu, a 99.12% decrease in the permittivity of free-space, *and* it goes up to 11. :) cheers, DaveK -- Can't think of a witty .sigline today
RE: Miscompilation of remainder expressions
On 16 January 2007 18:23, Robert Dewar wrote: > Gabriel Paubert wrote: > \ >> No, because the instruction has actually two result values: >> >> - the remainder, which you could safely set to zero (not 1!) >> >> - the quotient, which is affected by the overflow and there may be >> compiler and languages that rely on the exception being generated. > > But the division is undefined, programs have no right to > rely on an exception being generated. It really depends whether you think of the % operator as being an atomic mathematical operation, or a compound function involving real division and multiplication and subtraction. I think the wording of the standard says only that the inequality "(a/b)*b + a%b == a" does not hold when (a/b) cannot be represented, but does not deny the modulo operator the option of just returning the correct result, which is representable. cheers, DaveK -- Can't think of a witty .sigline today
RE: Miscompilation of remainder expressions
On 16 January 2007 18:42, Robert Dewar wrote: > Dave Korn wrote: >> On 16 January 2007 18:23, Robert Dewar wrote: >> >>> Gabriel Paubert wrote: >>> \ >>>> No, because the instruction has actually two result values: >>>> >>>> - the remainder, which you could safely set to zero (not 1!) >>>> >>>> - the quotient, which is affected by the overflow and there may be >>>> compiler and languages that rely on the exception being generated. >>> But the division is undefined, programs have no right to >>> rely on an exception being generated. >> >> It really depends whether you think of the % operator as being an atomic >> mathematical operation, or a compound function involving real division and >> multiplication and subtraction. I think the wording of the standard says >> only that the inequality "(a/b)*b + a%b == a" does not hold when (a/b) >> cannot be represented, but does not deny the modulo operator the option of >> just returning the correct result, which is representable. > > I think you missed my point Oops, yeh. I was thinking of Andrew Haley's question about the wording of the language in the standard. cheers, DaveK -- Can't think of a witty .sigline today
RE: Miscompilation of remainder expressions
On 17 January 2007 19:09, Joe Buck wrote: > On Wed, Jan 17, 2007 at 05:48:34PM +, Andrew Haley wrote: >> From a performance/convenience angle, the best place to handle this is >> either libc or the kernel. Either of these can quite easily fix up >> the operands when a trap happens, with zero performance degradation of >> existing code. I don't think there's any need for gcc to be altered >> to handle this. > > How will the kernel know whether the overflow in the divide instruction > is because the user's source code has a '%' and not a '/'? We generate > the exact same instruction for i / minus_one(), after all, and in that > case the trap really should be there. > > I suppose that the trap handler could try to analyze the code following > the divide instruction; if the quotient result is never used and the > divisor is -1, it could replace the remainder result with zero and return. > But that would be rather hairy, if it is even feasible. Alternatively, > the divide instruction could be marked somehow, but I have no idea how. Didn't someone suggest a no-op prefix somewhere back up-thread? cheers, DaveK -- Can't think of a witty .sigline today
RE: Signed int overflow behaviour in the security context
On 24 January 2007 12:51, Richard Kenner wrote: >> Your conclusion may well be correct. The question for this group is: >> what's the best that GCC can do to serve the community/society? > > Do all it can to discourage people from writing safety- or > security-critical code in a language they don't understand? ;-) You mean we should invoke the as-if rule in conjunction with the nasal demons tradition and /actually/ erase the user's hard-drive at compile time if they write a signed overflow? ;) cheers, DaveK -- Can't think of a witty .sigline today
RE: Hi all, just an onfo about huw to use gcc tree
On 03 March 2007 20:15, Fabio Giovagnini wrote: > Hi all, > I'd like to develop a tool able to do the following things: > 1) to load all the .h and .c/.cpp files; > 2) to analyze allo the data struct / unions and classes; > 3) to give me for each data member of a struct or union and for each data > member of a class, the offset in bytes related to the base addess of a > generic istance of the struct/union and class. > > In this way I could easily calculate the real address of each data member of > each global declared struct / union and classes, and I clould easily read > usign a simple communication protocol the content of a memory location of an > embedded system only knowing the map file and the offset of each member of > each global variable. Sounds like what you really want is a debugger... GDB does things like that. The information you want is all emitted by the compiler as debug info in your object files when you use the -g flag. You haven't given details about the task you're trying to achieve but scripting gdb is probably going to be the way to go. cheers, DaveK -- Can't think of a witty .sigline today
RE: Adding a new gcc dir
On 06 March 2007 16:07, Paulo J. Matos wrote: > Well, added a couple of lines to gcc/Makefile.in referring to files in > myproj. Still, although it is partly working one thing is annoying me. > It's using these flags by default: > -W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes > -pedantic -Wno-long-long -Wno-variadic-macros -Wold-style-definition > -Wmissing-format-attribute > > Which means using C90, which means no mixed declarations and code, no > C++ comments, etc. Is there any way to compile at least, my files with > c99 constructs? Take a look at the section of gcc/Makefile.in beginning "# Various ways of specifying flags for compilations:" and go from there. > Or all gcc code should be built like this?? Well, for your own personal purposes, you can do whatever you like, but it is part of the coding standard that all gcc code should be bog-standard C90, so that it is possible for end-users to build gcc on any machine, even a very old one with a very old compiler. cheers, DaveK -- Can't think of a witty .sigline today
RE: Adding a new gcc dir
On 06 March 2007 18:22, Paulo J. Matos wrote: > i686-pc-linux-gnu-ar: symbol-tables.o: No such file or directory > > And in fact there is no symbol-tables.o but I saw it being compiled so > I wonder where it has gone to. > > > Any suggestions ?? 1. Always pipe the build output to a file so you can review it after the build and see what went wrong. 2. Learn about the unix 'find' command. 3. Don't use a subdirectory, none of the other passes do that, subdirectories are for separate languages. Think of it like this: a compile taking place in a subdirectory of the gcc build dir can reference the core gcc .o files built in the parent dir, but the core gcc build in the parent dir can't reference files in a sub-dir. (This isn't strictly true, I'm sure there's a way to make it work, but all the existing build machinery works this way round and it's probably easiest to keep to the same scheme). cheers, DaveK -- Can't think of a witty .sigline today
RE: Adding a new gcc dir
On 06 March 2007 20:12, Paulo J. Matos wrote: > On 3/6/07, Dave Korn <[EMAIL PROTECTED]> wrote: >> On 06 March 2007 18:22, Paulo J. Matos wrote: >> >> >>> i686-pc-linux-gnu-ar: symbol-tables.o: No such file or directory >>> >>> And in fact there is no symbol-tables.o but I saw it being compiled so >>> I wonder where it has gone to. >>> >>> >>> Any suggestions ?? >> >> 1. Always pipe the build output to a file so you can review it after the >> build and see what went wrong. >> > > Yes, so? What help would that be right now? You would be able to look again at the command-line that was invoked when you "saw it being compiled" and see what the -o option said. You could also see if there were any errors when it was compiled. >> 2. Learn about the unix 'find' command. >> > > I know about the find command! Why should I need it here? To do "find > . -name symbol-tables.o" ? I told you, there's no such file. You also told me you "saw it being compiled", from which I inferred that it /was/ compiled, from which I inferred that there had to be an output file somewhere. The only way I could reconcile those two seemingly-contradictory statements was to assume that you must not have looked for it in the place where it actually ended up. Of course, it's possible that it was compiled one minute and automagically deleted the next. If you had had that log file, you'd be able to see *that* too. >> 3. Don't use a subdirectory, none of the other passes do that, >> subdirectories are for separate languages. Think of it like this: a >> compile taking place in a subdirectory of the gcc build dir can reference >> the core gcc .o files built in the parent dir, but the core gcc build in >> the parent dir can't reference files in a sub-dir. (This isn't strictly >> true, I'm sure there's a way to make it work, but all the existing build >> machinery works this way round and it's probably easiest to keep to the >> same scheme). >> > > So, any auxiliar files to the pass should be in the same directory as > the pass itself. Well, that is how every other pass has been implemented. > Or do you advise me to have _all_ the code in the > pass file? No, I advise that when adding a pass, regardless of whether the code can fit in a single file or is large enough to need to use several separate files, it's consistent to put all the files that implement the pass in the main 'gcc' source directory. cheers, DaveK -- Can't think of a witty .sigline today
RE: Adding a new gcc dir
On 07 March 2007 14:30, [EMAIL PROTECTED] wrote: > Is it time to offer "second-strap" level of compilation? Ie allow C99 to > bootstrap the creation of a basic GCC compiler, then allow a second compile > using the basic GCC compiler to get the full compiler. > > Nick Effectively that's what bootstrapping already does, so IIUIC, as long as no C99 creeps into the core C language compiler, it /should/ work to use C99 (and indeed GCC language extensions, attributes etc. etc.) in e.g. the cp/ subdirectory or other places where the files only relate to other languages. cheers, DaveK -- Can't think of a witty .sigline today
RE: Adding a new gcc dir
On 07 March 2007 15:05, Paulo J. Matos wrote: > On 3/7/07, Dave Korn <[EMAIL PROTECTED]> wrote: >> On 07 March 2007 14:30, [EMAIL PROTECTED] wrote: >> >>> Is it time to offer "second-strap" level of compilation? Ie allow C99 to >>> bootstrap the creation of a basic GCC compiler, then allow a second >>> compile using the basic GCC compiler to get the full compiler. >>> >>> Nick >> >> Effectively that's what bootstrapping already does, so IIUIC, as long as >> no C99 creeps into the core C language compiler, it /should/ work to use >> C99 (and indeed GCC language extensions, attributes etc. etc.) in e.g. the >> cp/ subdirectory or other places where the files only relate to other >> languages. >> > > But if I add in my pass // args, or mixed code and variable > declarations for example, I get warnings, so it is not that clean. > Maybe only by removing pedantic, are you able to do that. > > Right? Yeah, absolutely. Although it does /work/ to use these features, I think we don't yet want to use any of them in the official sources, so the flags set in the gcc makefile are chosen in order to draw attention to any such features that anyone might accidentally use without realising. cheers, DaveK -- Can't think of a witty .sigline today
RE: Adding a new gcc dir
On 07 March 2007 15:07, Paulo J. Matos wrote: > Moreover, for some reason when using malloc, a lot of poisonous malloc > warning come up which are solved by using xmalloc instead, which is > another thing I cannot figure out. What is better in xmalloc than > malloc? Take a look, the source for it is in libiberty. I think the only substantial difference is that if it runs out of memory it exits instead of returning a NULL pointer, meaning the rest of the code doesn't have to remember to check every single malloc return. cheers, DaveK -- Can't think of a witty .sigline today
RE: Adding a new gcc dir
On 07 March 2007 16:16, Paulo J. Matos wrote:
> On 3/7/07, Paul Brook <[EMAIL PROTECTED]> wrote:
>> On Wednesday 07 March 2007 14:30, [EMAIL PROTECTED] wrote:
>>> Is it time to offer "second-strap" level of compilation? Ie allow C99 to
>>> bootstrap the creation of a basic GCC compiler, then allow a second
>>> compile using the basic GCC compiler to get the full compiler.
>>
>> Maybe, but I consider rejecting mixed code/declarations to be a feature :-)
>
> Well, I'm curious to hear more about that... Why do you think that...
> int i;
> ...
> ...
> for(i = 0; i < n; i++) ..
>
> is better than
> for(int i = 0; i < ..) ... ???
As explained: because it makes it impossible for users running old systems
with pre-C99 compilers to build gcc and thereby excludes them from the world
of free software, which is the opposite of what we're trying to achieve.
> Their value lies (at least for me) in things line
> if (foo) // now I'll do...
> {
>
> }
>
> and for example
> struct foo {
> int myint ; // this int is ...
> double mydouble ; // this double is...
> };
The benefit of saving three keypresses is outweighed (for the FSF's goals)
by the disadvantage of excluding a whole category of potential
users/contributors.
> in a one line comments, using /* */ is just horrid! :)
That's a purely religious opinion!
You might find it interesting to browse the gnu coding standards
(http://www.gnu.org/prep/standards/) and the additional standards specific to
gcc (http://gcc.gnu.org/codingconventions.html), since much of what we have
discussed is explained there along with the rationale that justifies the
decisions.
Things won't stay like this forever, and at some point we'll undoubtedly
decide that it's no longer necessary to stay backwardly compatible all that
far back, and start using C99 features (and beyond that, we may at sometime
start using C++ in the compiler core). It's a purely practical matter of
ensuring gcc is accessible to the greatest possible number of people.
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: Adding a new gcc dir
On 07 March 2007 17:44, Paulo J. Matos wrote: > Well, I surely understand that and I find it nice. Still, I was > questioning Paul why he said: "I consider rejecting mixed > code/declarations to be a feature" > I surely don't know FSF's goals but again I understand gcc code not > containing //, but my question was more directed to Paul view. :) Ah, well I'd best let him speak for himself! cheers, DaveK -- Can't think of a witty .sigline today
RE: Libiberty functions
On 08 March 2007 11:46, Paulo J. Matos wrote: > Hello all, > > when using functions from libiberty, I'm for example using xstrdup and > xmalloc but free is not defined as free or xfree afail nor strlen so > how should I include things? Before system.h and then standard libs or > the other way around? > > I am almost sure it should be the other way around but I would like > confirmation on this. Huh? I don't quite get you here. For example, xmalloc is a wrapper around the system malloc; all it does is calls malloc and checks the result isn't NULL. So you don't need any xfree; just call the ordinary system free. Same goes for xstrdup; it's just a wrapper around the standard strdup implementation that guarantees it won't fail; since strlen doesn't allocate any memory and can't fail, there's no need for a xstrlen function. In any case, it's not a matter of include file ordering; you should have no need to do anything other than just stick to the usual ordering, which is standard library files first, application files last. There's libiberty documentation available online at DJ's homepage: http://www.delorie.com/gnu/docs/gcc/libiberty.html (Also, bear in mind that if you want your new pass to work correctly with pre-compiled headers, you really ought to be using Gcc's garbage-collected memory management facilities. See http://gcc.gnu.org/onlinedocs/gccint/Type-Information.html#Type-Information for the full gory details) cheers, DaveK -- Can't think of a witty .sigline today
RE: Looking for specific pages from Muchnick's book
On 08 March 2007 12:59, Steven Bosscher wrote: > On 3/8/07, Steven Bosscher <[EMAIL PROTECTED]> wrote: >> Could someone scan those pages and send them to me, please? > > I received some private mails from people that are concerned about > copyright issues and all that. A few pages for personal study? That's fair use by any meaningful definition, no matter how much the RIAA/MPAA/similar-copyright-nazis would like to redefine the meanings of perfectly clear words and phrases in the english language. cheers, DaveK -- Can't think of a witty .sigline today
Quick FUNCTION_MODE doco query
--
http://gcc.gnu.org/onlinedocs/gccint/Misc.html#Misc
- Macro: FUNCTION_MODE
An alias for the machine mode used for memory references to functions
being called, in call RTL expressions. On most machines this should be QImode.
--
Was this description perhaps written in pre-RISC days? Is it not correct to
use SImode on a RISC machine where all instructions are always 4-aligned? (A
quick grep suggests that of current backends, 7 use Pmode, 3 HImode, 17 QImode
and 8 SImode). It looks to me like it should be a mode that has the same
alignment as the smallest addressable instruction, no? Would the below be a
more accurate description?
@defmac FUNCTION_MODE
An alias for the machine mode used for memory references to functions
being called, in @code{call} RTL expressions. On most CISC machines,
where an instruction can begin at any byte address, this should be
@code{QImode}; on RISC machines, where all instructions are word-sized
and aligned, this should be a mode with the same size and alignment as
the machine instruction words - @code{SImode} for 32-bit processors, or
perhaps @code{HImode} for such machines as the ARM cpu in Thumb mode,
which uses 16-bit instructions.
@end defmac
If so I'll send a patch+changelog to the patches list.
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: On NULL and 0
On 13 March 2007 13:52, Paulo J. Matos wrote: > Hello, > > When programming, due to my journeys through C++ recently, I've been > using 0 instead of NULL. Strangely gcc compilation doesn't warn me > about it. Is it ok to do this? (So far, I had no problems). Is there > anything I should be aware when using 0 instead of NULL in gcc code? Nope. (This is really a gcc-help@ question, but anyway) Zero is completely acceptable for a null pointer constant in all circumstances *except* when passing to a varargs function, which can go badly wrong on platforms where the sizeof a pointer is larger than the sizeof an int. See the gnu coding standards, which mentions this. cheers, DaveK -- Can't think of a witty .sigline today
RE: Question for removing trailing whitespaces (not vertical tab) from source
On 13 March 2007 14:02, Andrew Haley wrote: > Kai Tietz writes: > > > I want to remove some trailing whitespaces from gcc source as coding > style > demands. Also I wrote, while doing a small tool for that, a > feature to > replace horiz. tabs by spaces. But the question is by which > width should > be used ? > > 8. > > Andrew. Can you explain that value? It's just that 1) I see vast acres and acres of code where the tabstop size is two spaces 2) the coding standard doesn't seem to /demand/ a specific tab size and 3) if we use 8-space TABs with the kind of depths of nesting the gcc code often contains we're going to exceed the 80-column line length limit just on the leading indentation alone pretty often cheers, DaveK -- Can't think of a witty .sigline today
RE: Question for removing trailing whitespaces (not vertical tab) from source
On 13 March 2007 15:06, Andrew Haley wrote: > Dave Korn writes: > > On 13 March 2007 14:02, Andrew Haley wrote: > > > > > Kai Tietz writes: > > > > > > > I want to remove some trailing whitespaces from gcc source as coding > > > style > demands. Also I wrote, while doing a small tool for that, a > > > feature to > replace horiz. tabs by spaces. But the question is by > which > > width should > be used ? > > > > > > 8. > > > > > > Can you explain that value? It's just that 1) I see vast acres and > acres of > code where the tabstop size is two spaces 2) the coding > standard doesn't seem > to /demand/ a specific tab size and 3) if we use > 8-space TABs with the kind of > depths of nesting the gcc code often > contains we're going to exceed the > 80-column line length limit just on > the leading indentation alone pretty > often > > That's not the question I answered, which was "when I come across a > leading tab character in GNU souce code, how many spaces does that tab > represent?" It says nothing about correct GNU indentation, which is > two spaces. Thanks for clarification, the false inference I was making was that a TAB was (or could be) equivalent to an indent level. (Sometimes it is, of course - I guess a lot of the mixed-formatting problems probably arise where a chunk of code that used to be at one indent level that happened to be a multiple of 4 and hence could be aligned using TABs gets moved to a different context where they would need to be converted to spaces and adjusted...) cheers, DaveK -- Can't think of a witty .sigline today
RE: Question for removing trailing whitespaces (not vertical tab) from source
On 13 March 2007 15:12, Daniel Jacobowitz wrote: > On Tue, Mar 13, 2007 at 03:02:44PM -0000, Dave Korn wrote: >> Can you explain that value? It's just that 1) I see vast acres and >> acres of code where the tabstop size is two spaces 2) the coding standard >> doesn't seem to /demand/ a specific tab size and 3) if we use 8-space TABs >> with the kind of depths of nesting the gcc code often contains we're going >> to exceed the 80-column line length limit just on the leading indentation >> alone pretty often > > GCC indents with tabs replacing eight leading spaces but an indentation > depth of two spaces. I don't know where your acres and acres are, > but they aren't in most GNU software. Yeh, as explained, I was conflating tabstops with indents, sorry. > Personally I think that regardless of your indentation preferences, > using anything besides eight column tab stops for \t is silly; that's > what "cat" is going to use. Well, I always *used* to think of a tab stop as being unequivocally and universally equal to 8 columns too, but that was a long time ago and since then bitmapped displays and WYSIWYG editors have come into being ... Anyway. The presence of the word "preferences" indicates to me that this thread is liable to decay into an OT bikeshed debate if we keep it up, so I'm dropping it now! :-) cheers, DaveK -- Can't think of a witty .sigline today
How to hide registers from local RA but not reload?
Hello Gcc hackers, I don't even know if what I'm doing is supposed to be possible, but I'm trying it anyway! To oversimplify the situation, I've got an external memory-mapped peripheral that does multiply operations. It's got three SImode registers; you write a word each to the multiplier and multiplicand, and a few cycles later you read back the result from the result register. So my first idea to make this work is to treat each of the peripheral's memory locations as if they were actually hard regs. My strategy is - allocate hard reg numbers to each of these registers - define a reg class for each of these registers, with a single member in each, corresponding to the given (fake) hard register. - define md constraint letters for each of these classes. - implement the mulsi3 pattern, accepting only register operands and using the constraint letter on each operand that corresponds to the relevant hard(ware) register. - implement movsi3 alternatives to move between a general register and each of the single-member reg classes (these are actually memory load/stores in disguise as reg-reg moves). - allow reload to take care of moving the operands for mulsi3 insns into the relevant pseudo-hardregs by using the movsi3 patterns. However, the last thing I want is for the register allocater to decide it's a good idea to ever allocate one of these registers for general usage, because they're really memory locations; using one to store a pseudo would be basically the same as spilling it to the stack. Trying to mark them as FIXED_REGs didn't work, as it meant reload didn't even think it could use them, so I settled for leaving them unFIXED, but not mentioning them in the REG_ALLOC_ORDER. This initially appeared to have the desired effect; at any rate, it generated correct assembly code for mulsi3 operations. But it has had some undesirable knock-on effects; it perturbs the lreg pass in a bad way. The intermediate cause is that lreg considers all the special-purpose reg classes when allocating, and for some reason decides that several of the special-purpose classes have equal cost (zero) to GENERAL_REGS. The bit I find strange about this is that it then decides to take the highest-numbered class as the preferred register class, despite the fact that it has a lot less members in it than GENERAL_REGS. (There is no overlap between the classes, so I haven't put them in the "wrong order", as one is not a subset of the other). Anyway, somehow this preference throws things off, and it *looks* like it ends up assuming it needs yet another register to reload into the specialised class reg, and then it eliminates the original register and the overall effect is that instead of allocating a consecutive bunch of hard regs starting with my volatile arg-passing regs, it leaves gaps in the range and allocates further registers beyond the end of it, so a routine that previously got allocated r1 to r6 (r1-r4 are function arg-passing regs in this setup) might end up using r1 to r5 and r7. Which leads to one or two questions: Q. Is it possible to do what I really want: to make the compiler aware of some registers, but limit their usage to a single insn; to allow reload to use these registers when directed to by a constraint letter, but for the rest of the compiler to basically pretend they don't even exist. Q. Would it perhaps work better if I didn't rely on reload to move args into the specialised registers, but used an expander or splitter to generate the sequence of store operand 1 to multiplier register, store operand 2 to multiplicand register, load operand zero from result register? I wouldn't need to mess around with register classes at all, but I might have problems controlling the scheduling and sequencing of the operations - you have to load the two input registers in the correct order, since loading the second one triggers the operation. Q. Or should I just adjust the costs of these registers to something ludicrous, so that they would never ever seem to be preferable to any other register nor even a memory spill, and not worry about whether it thinks they are allocatable or not? cheers, DaveK -- Can't think of a witty .sigline today
RE: How to hide registers from local RA but not reload?
On 13 March 2007 19:56, Ian Lance Taylor wrote: > "Dave Korn" <[EMAIL PROTECTED]> writes: > >> The intermediate cause is that lreg considers all the special-purpose reg >> classes when allocating, and for some reason decides that several of the >> special-purpose classes have equal cost (zero) to GENERAL_REGS. The bit I >> find strange about this is that it then decides to take the >> highest-numbered class as the preferred register class, despite the fact >> that it has a lot less members in it than GENERAL_REGS. (There is no >> overlap between the classes, so I haven't put them in the "wrong order", >> as one is not a subset of the other). > > Did you set REGISTER_MOVE_COST for your new registers? Ah, no I didn't. Having said that, do I really want to? At the moment I have no definition of it at all, so everything has the default cost 2. Isn't this right? I want to use reloads to get the input operands from gprs into the memory-mapped registers, and I have defined movsi3 patterns to exchange between any of the specialised registers and the gprs, and I'm not sure in what way you're suggesting I should uuse REGISTER_MOVE_COST. >> Q. Is it possible to do what I really want: to make the compiler aware of >> some registers, but limit their usage to a single insn; to allow reload to >> use these registers when directed to by a constraint letter, but for the >> rest of the compiler to basically pretend they don't even exist. > > This is more or less what the MIPS backend does with the HI and LO > registers. You might want to look at that. Thanks Ian, that sounds very much like what I'm looking for, I'll take a dig through it. cheers, DaveK -- Can't think of a witty .sigline today
[SOLVED] RE: How to hide registers from local RA but not reload?
On 13 March 2007 19:56, Ian Lance Taylor wrote: > "Dave Korn" <[EMAIL PROTECTED]> writes: > >> The intermediate cause is that lreg considers all the special-purpose reg >> classes when allocating, and for some reason decides that several of the >> special-purpose classes have equal cost (zero) to GENERAL_REGS. The bit I >> find strange about this is that it then decides to take the >> highest-numbered class as the preferred register class, despite the fact >> that it has a lot less members in it than GENERAL_REGS. (There is no >> overlap between the classes, so I haven't put them in the "wrong order", >> as one is not a subset of the other). > > Did you set REGISTER_MOVE_COST for your new registers? > > >> Q. Is it possible to do what I really want: to make the compiler aware of >> some registers, but limit their usage to a single insn; to allow reload to >> use these registers when directed to by a constraint letter, but for the >> rest of the compiler to basically pretend they don't even exist. > > This is more or less what the MIPS backend does with the HI and LO > registers. You might want to look at that. Thanks Ian, that was just the ticket. The solution was indeed to define REGISTER_MOVE_COST to a high value for moves between general regs and the special purpose regs; that prevents RA from considering them to be preferred classes for operands that aren't constrained to occupy a SPR. Adding secondary reloads via gprs when reloading from/to memory wrapped it up nicely. cheers, DaveK -- Can't think of a witty .sigline today
RE: What to do when constraint doesn't match
On 15 March 2007 05:00, Mohamed Shafi wrote: > I have a define_expand with the pattern name mov and a > define_insn mov_store > The predicate in define_expand is general_operand, so that all > operands are matched. > While in define_insn i have a predicate which allows only two class of > registers say 'a' and 'b'. But the constraint for define_insn only > allows registers of class 'b'. > > I also have a pattern for register move from 'a' to 'b', call it > mova2b. So if for mov_store define_insn constraint > doesn't satisfy why is that the compiler is not trying to match the > constraint by generating a mova2b pattern? Is there something > that i am missing here? Secondary reloads. IIUIC (I'm up to my neck in this area of the compiler myself ATM!) you use them to tell the compiler it needs to use a temporary register of class 'a' to move any value (that isn't a REG or SUBREG already in class 'b') into a reg of class 'b'. Look at `SECONDARY_RELOAD_CLASS', and `reload_inM' and `reload_outM' in the internals docs. cheers, DaveK -- Can't think of a witty .sigline today
RE: Constrain not satisfied - floating point insns.
On 14 March 2007 21:21, Jim Wilson wrote: > Rohit Arul Raj wrote: >> (define_insn "movsf_store" >> [(set (match_operand:SF 0 "memory_operand" "=m") >> (match_operand:SF 1 "float_reg""f"))] > > You must have a single movsf define_insn that accepts all alternatives > so that reload will work. You can't have separate define_insns for > movsf and movsf_store. But it is ok to use a define_expand (that accepts all alternatives) for movsf and use that to generate one of several movsf_ insns, isn't it? cheers, DaveK -- Can't think of a witty .sigline today
regclass oddity?
Hi all,
When regclass determines that placing an operand into either one of several
register classes would have the same cost, it picks the numerically highest
one in enum reg_class ordering.
In my particular circumstances this is not good, because a lot of the
high-numbered reg classes (which correspond to special-purpose registers) only
have one member in them. I am aware of the ordering rule that says that class
x must be numerically lower than class y if y is a superset of x, but in this
case the classes are entirely disjoint.
What makes it even worse is that regclass insists on picking these classes,
despite the fact that a) there is no way to load a memory operand into one, it
has to go via a secondary reload into a GPR, and b) there is no way to load an
immediate constant into one either. The only way to access these registers is
via a gpr.
So, is there actually anything inconsistent or incorrect about setting up my
reg classes in this fashion?
#define REG_CLASS_CONTENTS { \
{ 0x, 0x, 0x }, /* NO_REGS */ \
{ 0x, 0x, 0x }, /* GENERAL_REGS */ \
{ 0x, 0x, 0x0001 }, /* MPD_REG 64 */ \
{ 0x, 0x, 0x0002 }, /* MPR_REG 65 */ \
{ 0x, 0x, 0x0004 }, /* MPRA_REG 66 */ \
{ 0x, 0x, 0x0008 }, /* MPRL_REG 67 */ \
{ 0x, 0x, 0x0010 }, /* MPRH_REG 68 */ \
{ 0x, 0x, 0x0020 }, /* MPC_REG 69 */ \
{ 0x, 0x, 0x0040 }, /* MPV_REG 70 */ \
{ 0x, 0x, 0x0080 }, /* MPRLS_REG 71 */ \
{ 0x, 0x, 0x0100 }, /* MPAR_REG 72 */ \
{ 0x, 0x, 0x }, /* SPECIAL_REGS */ \
{ 0x, 0x, 0x } /* ALL_REGS */ \
}
I might be able to 'disguise' the problem by moving GENERAL_REGS after
SPECIAL_REGS, so that it would be picked if it was as favourable as any other,
but I'm curious: should regalloc really not care about the size of classes?
ISTM that given an equal cost for putting some operand into a class with 1
member and a class with 32 members, it would be highly preferable to choose
the bigger class to try and avoid register pressure. The nearest I can see to
any such logic in regclass would be the part of record_reg_classes that says
/* If this insn is a single set copying operand 1 to operand 0
and one operand is a pseudo with the other a hard reg or a pseudo
that prefers a register that is in its own register class then
we may want to adjust the cost of that register class to -1.
but that isn't coming into play in this case because it only cares about
reg->reg moves and I'm having trouble with a mem->reg move.
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: regclass oddity?
On 15 March 2007 15:53, Dave Korn wrote:
> Hi all,
>
> When regclass determines that [ ... ]
> So, is there actually anything inconsistent or incorrect about setting up
> my reg classes in this fashion?
>
> #define REG_CLASS_CONTENTS { \
> { 0x, 0x, 0x }, /* NO_REGS */ \
> { 0x, 0x, 0x }, /* GENERAL_REGS */ \
> { 0x, 0x, 0x0001 }, /* MPD_REG 64 */ \
> { 0x, 0x, 0x0002 }, /* MPR_REG 65 */ \
> { 0x, 0x, 0x0004 }, /* MPRA_REG 66 */ \
> { 0x, 0x, 0x0008 }, /* MPRL_REG 67 */ \
> { 0x, 0x, 0x0010 }, /* MPRH_REG 68 */ \
> { 0x, 0x, 0x0020 }, /* MPC_REG 69 */ \
> { 0x, 0x, 0x0040 }, /* MPV_REG 70 */ \
> { 0x, 0x, 0x0080 }, /* MPRLS_REG 71 */ \
> { 0x, 0x, 0x0100 }, /* MPAR_REG 72 */ \
> { 0x, 0x, 0x }, /* SPECIAL_REGS */ \
> { 0x, 0x, 0x } /* ALL_REGS */ \
> }
Hmm, further reading in the manual suggests another question I should be
asking about now:
Because my movsi3 pattern that allows both GENERAL_REGS through an 'r'
constraint, and MPD_REG and MPRL_REG through custom constraint letters ('a'
and 'd'), does that mean I need to define a union class or I'm actually doing
something wrong?
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: regclass oddity?
On 15 March 2007 16:12, Dave Korn wrote:
>> So, is there actually anything inconsistent or incorrect about setting up
>> my reg classes in this fashion?
>>
>> #define REG_CLASS_CONTENTS { \
>> { 0x, 0x, 0x }, /* NO_REGS */ \
>> { 0x, 0x, 0x }, /* GENERAL_REGS */ \
>> { 0x, 0x, 0x0001 }, /* MPD_REG 64 */ \
>> { 0x, 0x, 0x0002 }, /* MPR_REG 65 */ \
>> { 0x, 0x, 0x0004 }, /* MPRA_REG 66 */ \
>> { 0x, 0x, 0x0008 }, /* MPRL_REG 67 */ \
>> { 0x, 0x, 0x0010 }, /* MPRH_REG 68 */ \
>> { 0x, 0x, 0x0020 }, /* MPC_REG 69 */ \
>> { 0x, 0x, 0x0040 }, /* MPV_REG 70 */ \
>> { 0x, 0x, 0x0080 }, /* MPRLS_REG 71 */ \
>> { 0x, 0x, 0x0100 }, /* MPAR_REG 72 */ \
>> { 0x, 0x, 0x }, /* SPECIAL_REGS */ \
>> { 0x, 0x, 0x } /* ALL_REGS */ \
>> }
>
> Hmm, further reading in the manual suggests another question I should be
> asking about now:
>
> Because my movsi3 pattern that allows both GENERAL_REGS through an 'r'
> constraint, and MPD_REG and MPRL_REG through custom constraint letters ('a'
> and 'd'), does that mean I need to define a union class or I'm actually
> doing something wrong?
Well, it certainly /appears/ to have helped. I also moved GENERAL_REGS to
last entry before ALL_REGS just to make it preferred over the smaller classes.
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: Constrain not satisfied - floating point insns.
On 16 March 2007 15:30, Richard Sandiford wrote: > Jim Wilson <[EMAIL PROTECTED]> writes: >> Dave Korn wrote: >>> But it is ok to use a define_expand (that accepts all alternatives) for >>> movsf and use that to generate one of several movsf_ insns, isn't it? >> >> Reload doesn't use the move define_expands. It can't. A define_expand >> is allowed to do stuff like generate new RTL that would completely mess >> up what reload is trying to do. > > That isn't unconditionally true, is it? reload1.c:gen_reload > uses gen_move_insn, which is just a start_sequence/end_sequence > wrapper for emit_move_insn_1, which in turn calls the move expanders. Yes, in fact isn't this the reason why you have to take great care in movMM expanders to check for no_new_pseudos? It may or may not be technically correct, but it's certainly the standard practice for movDI - almost every backend uses an expander instead of an insn. cheers, DaveK -- Can't think of a witty .sigline today
Trouble understanding reload dump file format..
Morning all,
I'm not entirely familiar with the format and meaning of all the terms used
in the reload pass dump files, I was wondering if someone could comment on
whether this seems sane or not:
mul.c: In function `try_mulsi3':
mul.c:5: error: unable to find a register to spill in class `MPD_REG'
Reload 0: reload_in (SI) = (reg/v:SI 3 r3 [102])
MPD_REG, RELOAD_FOR_INPUT (opnum = 1)
reload_in_reg: (reg/v:SI 3 r3 [102])
Reload 1: GENERAL_REGS, RELOAD_FOR_INPUT_ADDRESS (opnum = 3), can't combine,
secondary_reload_p
Reload 2: MPD_REG, RELOAD_FOR_INPUT_ADDRESS (opnum = 3), can't combine,
secondary_reload_p
secondary_in_reload = 1
secondary_in_icode = reload_insi
Reload 3: reload_in (SI) = (scratch:SI)
MPR_REG, RELOAD_FOR_INPUT (opnum = 3)
reload_in_reg: (scratch:SI)
secondary_in_reload = 2
mul.c:5: error: this is the insn:
(insn 12 4 19 0 0x0 (parallel [
(set (reg:SI 67 s3_MPRL(r0) [104])
(mult:SI (reg/v:SI 2 r2 [103])
(reg/v:SI 3 r3 [102])))
(clobber (scratch:SI))
]) 51 {mulsi3} (insn_list 4 (insn_list 3 (nil)))
(expr_list:REG_DEAD (reg/v:SI 2 r2 [103])
(expr_list:REG_DEAD (reg/v:SI 3 r3 [102])
(expr_list:REG_UNUSED (scratch:SI)
(nil)
mul.c:5: confused by earlier errors, bailing out
In particular, I really don't understand what a RELOAD_FOR_INPUT_ADDRESS
means when all the operands are regs, or why there should be three reloads for
the same operand when it's just a clobber scratch. Is there something special
about how reload handles clobber and match_scratch?
The insn pattern looks like:
(define_insn "mulsi3"
[(set (match_operand:SI 0 "register_operand" "=d")
(mult:SI (match_operand:SI 2 "register_operand" "r")
(match_operand:SI 1 "register_operand" "a")))
(clobber (match_scratch:SI 3 "b"))]
"TARGET_MUL_BLOCK"
"sw \\t%3,%2; CAUSE MULTIPLY"
[(set_attr "type" "mul")
(set_attr "length" "4")]
)
where the constraint letters 'a', 'b' and 'd' mean MPD_REG, MPR_REG and
MPRL_REG respectively, classes that contain just a single special purpose hard
reg each.
If I replace the match_scratch with an explicit (reg:SI) using the hard reg
num of the MPR_REG, instead of trying to regclass preference gcc into picking
it as the scratch register, all those reloads disappear.
I currently use secondary reloads to specify that a GENERAL_REG is required
to reload the specialised regs from memory. I tried making the secondary
reload class functions return NO_REGS for a (scratch:MM) pattern, but that got
me a different kind of error:
mul.c: In function `try_mulsi3':
mul.c:5: error: unrecognizable insn:
(insn 28 4 12 0 0x0 (set (reg:SI 65 s1_MPR(r0))
(scratch:SI)) -1 (nil)
(nil))
mul.c:5: internal compiler error: in extract_insn, at recog.c:2175
...which is even more confusing.
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: Trouble understanding reload dump file format..
On 19 March 2007 17:03, Ulrich Weigand wrote: > Dave Korn wrote: > >> (define_insn "mulsi3" >> [(set (match_operand:SI 0 "register_operand" "=d") >> (mult:SI (match_operand:SI 2 "register_operand" "r") >> (match_operand:SI 1 "register_operand" "a"))) >>(clobber (match_scratch:SI 3 "b"))] > > You should be using "=b" to designate the operand as *output* only. > > Otherwise, reload will attempt (unsuccessfully) to load up "scratch:SI" > as input value ... :) Thanks! I guess that even makes a reasonable amount of sense, all things considered![*] > B.t.w. if the register class denoted by "b" has just a single > element, you might just as well use the hard reg directly in > the insn pattern here. Hmm, well I modelled my approach on the way e.g. MIPS port uses a class-per-register, and that seems to work ok. Also, it's not actually a hard reg, it's in fact a memory-mapped peripheral. This means that I need to specify secondary reloads (can't be loaded directly from memory as I have no mem->mem move insn, needs to go via a gpr) and that implies that the register has to exist as a class because you can only specify secondary reloads on a per-reg-class basis. cheers, DaveK [*] - #1 in an occasional series of "Things you don't hear people say about reload /every/ day of the week." :-) -- Can't think of a witty .sigline today
RE: error: unable to find a register to spill in class 'FP_REGS'
Except when travelling backwards in time and replying to a post that hasn't been written yet! cheers, DaveK -- Can't think of a witty .sigline today On 19 March 2007 20:21, Mike Stump wrote: > Never top post. > > On Mar 19, 2007, at 3:13 AM, Markus Franke wrote: > >> Just another issue. Everything is working fine if using "-O1", "- O2" or >> "-O3". >> Maybe this helps. >> >> Regards, >> Markus >> >> Markus Franke wrote:
RE: We're out of tree codes; now what?
On 19 March 2007 22:41, Gabriel Dos Reis wrote: > > yeah, the trouble is that we don't seem to agree on what is good for > long-term, or if and when we agree whether we would find and allocate > resources to implement the solution. So, we end up accumulating > small% regressions over small% regressions. Then we get busy with > short-term fixes, because that is what gets the releases out the door. > Until the next trouble. > > -- Gaby As concise a summary of the report of the 1968 Nato conference on the crisis in software engineering as ever I've read! cheers, DaveK -- Can't think of a witty .sigline today
RE: Listing file-scope variables inside a pass
On 19 March 2007 22:16, Karthikeyan M wrote: > What should I do if I want a list of all file-scope variables inside > my own pass ? > > The file_scope variable is local to c-decl.c . Is there a reason why > the scope holding variables are local to c-decl.c ? Because we want to keep front-, mid- and back- ends of the compiler as modular and non-interdependent as possible, perhaps? If you need a routine to dump that data, why not write it in c-decl.c and just expose the prototype in a suitable header file (c-tree.h)? cheers, DaveK -- Can't think of a witty .sigline today
ROFL
/external_source/gnu/gcc-3.3.3/gcc/testsuite/gcc.c-torture/unsorted/udivmod4.c : In function `main': /external_source/gnu/gcc-3.3.3/gcc/testsuite/gcc.c-torture/unsorted/udivmod4.c :56: error: unrecognizable insn: (insn 208 207 209 5 0x0 (set (reg:SI 3 r3) (const_string "")) -1 (nil) (nil)) /external_source/gnu/gcc-3.3.3/gcc/testsuite/gcc.c-torture/unsorted/udivmod4.c :56: internal compiler error: in extract_insn, at recog.c:2175 :) That's gotta be one of the most bizarre insns I've ever seen. Gotta love that reload pass when it gets creative! cheers, DaveK -- Can't think of a witty .sigline today
RE: i386: Problems with references to import symbols.
On 21 March 2007 16:09, Richard Henderson wrote: > On Wed, Mar 21, 2007 at 01:11:36PM +0100, Kai Tietz wrote: >> #include >> void *(my_malloc_hook)(size_t) = malloc; >> >> GCC tells me, that malloc isn't a constant symbol. Clear malloc is defined >> by using the attribute dllimport, because it comes out of the MSVCRT and >> has the name "__imp__malloc". But the import library has also the not >> decored name stub function "_malloc". Did I something wrong or is there >> something broken ? > > In i386_pe_mark_dllimport, we turn "malloc" into "*__imp_malloc", > and the later is not constant. I expect we'd have to expand this > differently if you wanted to make use of import library stubs. Presumably there would be no problem in just waiting until runtime to initialise the my_malloc_hook variable dynamically instead of trying to statically initialise it? cheers, DaveK -- Can't think of a witty .sigline today
RE: Can't bootstrap gcc (revision 123155) trunk on cygwin: configure: error: C compiler cannot create executables [configure-stage2-intl] Error 77
On 23 March 2007 12:00, Christian Joensson wrote: > For some reason, yet unknow to me, I don't seem to be able to > bootstrap gcc trunk on cygwin due to some issue with configuring in > intl: It's generic. > checking for C compiler default output file name... configure: error: > C compiler cannot create executables > See `config.log' for more details. > make[2]: *** [configure-stage2-intl] Error 77 > make[2]: Leaving directory `/usr/local/src/trunk/objdir' > make[1]: *** [stage2-bubble] Error 2 > make[1]: Leaving directory `/usr/local/src/trunk/objdir' > make: *** [all] Error 2 > > the configure in intl works for stage1 (and stage0 so to speak), > attached is the intl/config.log See http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31039 also http://cygwin.com/ml/cygwin/2007-03/msg00674.html http://cygwin.com/ml/cygwin/2007-03/msg00676.html http://cygwin.com/ml/cygwin/2007-03/msg00705.html (Running a build in the background myself to see if I can see what's going on.) cheers, DaveK -- Can't think of a witty .sigline today
RE: We're out of tree codes; now what?
On 23 March 2007 17:01, Marc Espie wrote: > In article <[EMAIL PROTECTED]> you write: >> On Mar 20, 2007, at 11:23 PM, Alexandre Oliva wrote: >>> As for configure scripts... autoconf -j is long overdue ;-) > >> Is that the option to compile autoconf stuff into fast running >> efficient code? :-) Nah, it's the parallel autoconf flag >> But seriously, I think we need to press autoconf into generating 100x >> faster code 90% of the time. Maybe prebundling answers for the >> common targets... > > Doesn't win all that much. Here's a thought, off the top of my head and not deeply considered because it's friday afternoon... The main overhead in autoconf is all the forking and spawning and doing lots and lots of operations which all involve large numbers of small files each processed one at a time with one or more of a number of tools. It would be kinda neat if instead of repeating this endless cycle of cat'ing here-docs into files, compiling those files and executing or grepping the results it could cat the whole lot into one big file, compile it once, then parse the error messages to spot the non-compiling (AC_COMPILE in particular) tests, then re-cat the surviving tests (well, just the execute tests) into another file, synthesize a main() that invokes them one after another, and parses the output from the whole lot in one go. I can see it being tricky to shoehorn execution tests all into the same executable, but I do think it should be pretty likely that it would be possible to teach it to do all the compile tests in a single compilation, shouldn't it? cheers, DaveK -- Can't think of a witty .sigline today
RE: A question on ACX_BUGURL
On 23 March 2007 18:11, H. J. Lu wrote:
> On Fri, Mar 23, 2007 at 06:55:38PM +0100, Andreas Schwab wrote:
>> "H. J. Lu" <[EMAIL PROTECTED]> writes:
>>
>>> REPORT_BUGS_TO="<$1>"
>>> - REPORT_BUGS_TEXI="@uref{$1}"
>>> + REPORT_BUGS_TEXI="@uref{`echo $1 | sed 's/@/@@/g'`}"
>>
>> You need to quote $1.
>
> I treated it the same as
>
> REPORT_BUGS_TEXI="@uref{`echo $withval | sed 's/@/@@/g'`}".
>
> It works for me.
It's a url, right? It could have colons and forward slashes, but I don't
think most of the remaining metacharacters would be valid in a URL, would
they?
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: Building GCC 4.3.0 on Cygwin...
On 22 March 2007 22:08, Brian Dessent wrote:
> The real problem seems to be that the libgcc is broken:
>
> configure:2121: /home/User/cvsroot/gcc-obj/./prev-gcc/xgcc
> -B/home/User/cvsroot/gcc-obj/./prev-gcc/
> -B/usr/local/i686-pc-cygwin/bin/
> conftest.c >&5
> /home/User/cvsroot/gcc-obj/./prev-gcc/libgcc.a(_ctors.o): In function
> `__sgetc_r':
> /usr/include/stdio.h:414: undefined reference to `_ungetc'
> /usr/include/stdio.h:410: undefined reference to `___srget_r'
> /usr/include/stdio.h:407: undefined reference to `___srget_r'
> collect2: ld returned 1 exit status
>
> It looks like a problem with some function being defined as a macro when
> it shouldn't, or vice versa. You'll need to look into how _ctors.o is
> built to see exactly, since I can't find any reference to _sgetc_r or
> ungetc in any of the libgcc2.{c,h} files. You can try the trick of
> going into the libgcc build directory (you may have to "make restage1"
> to back up one stage), "rm _ctors.o" and then "make CFLAGS="-g -O2
> -save-temps"" (or some variant) and then look at the preprocessed source
> to see what's happening.
This is what's happening:
configure, make all (fails), make stage1-bubble, cd i686-pc-cygwin/libgcc,
rm _ctors.o, make _ctors.o (optional), cd ../.., make all (succeeds).
This is how _ctors.o looks the first time:-
/gnu/gcc/obj2/i686-pc-cygwin/libgcc $ nm bad-one/_ctors.o
b .bss
d .data
N .stab
N .stabstr
t .text
0010 C ___CTOR_LIST__
0010 C ___DTOR_LIST__
t ___sgetc_r
U ___srget_r
U _ungetc
This is how it looks the second time:-
/gnu/gcc/obj2/i686-pc-cygwin/libgcc $ nm good-one/_ctors.o
b .bss
d .data
N .stab
N .stabstr
t .text
0010 C ___CTOR_LIST__
0010 C ___DTOR_LIST__
The source of the problem? From libgcc2.i after rebuilding _ctors.o:
# 1 "/gnu/gcc/gcc/libgcc/../gcc/libgcc2.c"
# 1 "/gnu/gcc/obj/i686-pc-cygwin/libgcc//"
# 1 ""
# 1 ""
# 1 "/gnu/gcc/gcc/libgcc/../gcc/libgcc2.c"
# 32 "/gnu/gcc/gcc/libgcc/../gcc/libgcc2.c"
# 1 "../.././gcc/tconfig.h" 1
[ ... snip ... ]
# 405 "/usr/include/stdio.h" 3 4
static __inline__ int __sgetc_r(struct _reent *__ptr, FILE *__p)
{
int __c = (--(__p)->_r < 0 ? __srget_r(__ptr, __p) : (int)(*(__p)->_p++));
if ((__p->_flags & 0x4000) && (__c == '\r'))
{
int __c2 = (--(__p)->_r < 0 ? __srget_r(__ptr, __p) :
(int)(*(__p)->_p++));
if (__c2 == '\n')
__c = __c2;
else
ungetc(__c2, __p);
}
return __c;
}
# 487 "/usr/include/stdio.h" 3 4
# 91 "/gnu/gcc/gcc/libgcc/../gcc/tsystem.h" 2
Here's the bad build command diffed against the good build command:
--- a0 2007-03-25 00:27:08.556375000 +
+++ a1 2007-03-25 00:27:21.85325 +
@@ -1,5 +1,5 @@
-#bad
+#good
/gnu/gcc/obj2/./gcc/xgcc -B/gnu/gcc/obj2/./gcc/
-B/gnu/install/i686-pc-cygwin/bin/ -B/gnu/install/i686-pc-cygwin/lib/ -isystem
/gnu/install/i686-pc-cygwin/include -isystem
/gnu/install/i686-pc-cygwin/sys-include
--g -fkeep-inline-functions -O2 -I/gnu/gcc/gcc/gcc/../winsup/w32api/include
-O2 -g -O2 -DIN_GCC
+-O2 -g -O2 -O2 -I/gnu/gcc/gcc/gcc/../winsup/w32api/include -O2 -g -O2
-DIN_GCC
-W -Wall -Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -isystem ./include -g -DIN_LIBGCC2
-D__GCC_FLOAT_NOT_NEEDED
--I. -I. -I../.././gcc -I/gnu/gcc/gcc/libgcc -I/gnu/gcc/gcc/libgcc/.
-I/gnu/gcc/gcc/libgcc/../gcc -I/gnu/gcc/gcc/libgcc/../include
-I/gnu/gcc/gcc/libgcc/../libdecnumber -I../../libdecnumber -o _ctors.o -MT
_ctors.o -MD -MP -MF _ctors.dep -DL_ctors -c
/gnu/gcc/gcc/libgcc/../gcc/libgcc2.c
+-I. -I. -I../.././gcc -I/gnu/gcc/gcc/libgcc -I/gnu/gcc/gcc/libgcc/.
-I/gnu/gcc/gcc/libgcc/../gcc -I/gnu/gcc/gcc/libgcc/../include
-I/gnu/gcc/gcc/libgcc/../libdecnumber -I../../libdecnumber -o _ctors.o -MT
_ctors.o -MD -MP -MF _ctors.dep -DL_ctors -c
/gnu/gcc/gcc/libgcc/../gcc/libgcc2.c
The critical difference is the presence or absence of
-fkeep-inline-functions. I think I remember there being some change between
gcc-3.x and gcc-4.x in inline handling and I think that's what's biting us
now; I think this may only arise in stage1 where we're trying to use 3.x to
compile 4.x.
What I dunno yet is why it doesn't just link against -lcygwin and pick up
the definitions of _ungetc and ___srget_r from there...
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: -fkeep-inline-functions and broken Cygwin bootstrap (was: Building GCC 4.3.0 on Cygwin...)
On 25 March 2007 07:37, Andrew Pinski wrote:
> On 3/24/07, Brian Dessent <[EMAIL PROTECTED]> wrote:
>> Dave Korn wrote:
>>
>>> # 405 "/usr/include/stdio.h" 3 4
>>
>> [ Which is from newlib (libc/include/stdio.h) if anyone reading this
>> doesn't have a Cygwin system handy. ]
>>
>>> static __inline__ int __sgetc_r(struct _reent *__ptr, FILE *__p) {
>>> [...]
>>>
>>> The critical difference is the presence or absence of
>>> -fkeep-inline-functions. I think I remember there being some change
>>> between gcc-3.x and gcc-4.x in inline handling and I think that's what's
>>> biting us now; I think this may only arise in stage1 where we're trying
>>> to use 3.x to compile 4.x.
>>
>> I too thought that this was related to the c99 inline changes, but I
>> think those only apply to "extern inline" which is not the case here.
>>
>> The real cause seems to be that -fkeep-inline-functions was a no-op up
>> until: <http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01396.html>, which
>> seems to roughly correspond to when bootstrap stopped working on Cygwin.
>>
>
> Actually it was not a no-op in 3.4, just 4.2 (or was it also broken in
> 4.1) broke -fkeep-inline-functions and nobody noticed until later.
> Cygwin's headers are broken with respect of -fkeep-inline-functions
> and need to be fixed.
This is the conclusion I came to. We certainly don't want to emit those
functions in libgcc's _ctors.o.
Eric Bocatzou added -fkeep-inline-functions while fixing PR18058
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18058) for I assume was the
specific purpose of making these kinds of problems show up sooner rather than
later.
On 25 March 2007 07:33, Brian Dessent wrote:
> So it looks like we need to either stop using -fkeep-inline-functions
> for this file, change the definition to extern inline (or extern inline
> plus __attribute__((gnu_inline))? I'm still a little confused there),
> or link against -lcygwin. I kind of think the latter sounds wrong,
> since there really is no reason that these unused function bodies should
> end up in the .o file simply because it happens to have #include
> at the top.
Yeh, I'm a little confused too... or do we have to define a macro that gets
set to "static inline" or "extern inline" according to GNUC_xxx version tests?
cheers,
DaveK
--
Can't think of a witty .sigline today
RE: error: "no newline at end of file"
On 27 March 2007 11:26, Martin Michlmayr wrote: > Between 4.3.0 20070303 and 4.3.0 20070326 the "no newline at end of > file" warning changed to an error. Interestingly enough, I cannot see > any obvious change to libcpp/lex.c or the ChangeLog. > > Does anyone else see this and know whether this was intentional? I > think this change is a bad idea since it doesn't gain us anything. Had this in my local version (3.3 series) for some time. If there's interest I could always up-port it for mainline. cheers, DaveK -- Can't think of a witty .sigline today Wno-eof-newline.diff Description: Binary data
RE: error: "no newline at end of file"
On 27 March 2007 16:07, Ian Lance Taylor wrote: > Gabriel Dos Reis <[EMAIL PROTECTED]> writes: > >> Martin Michlmayr <[EMAIL PROTECTED]> writes: >> >>> * Manuel López-Ibáñez <[EMAIL PROTECTED]> [2007-03-27 13:13]: So if you are seeing this in C++, the change was intentional because PR24924 was fixed. If you are seeing it in C and you are not using pedantic-errors, then it is probably a bug. >>> >>> Thanks for the explanation - this explains what I'm seeing. Is there >>> a good reason against changing this particular warning from >>> CPP_DL_PEDWARN to CPP_DL_WARNING? Quite a few packages in Debian fail >>> to build because of this and it seems overly strict to me. However, if >>> it'll remain an error with C++ code, I'll start filing bugs on these >>> packages. >> >> -pedantic asks for strict checking of rules. User should accept >> correcting their codes (or used codes) with they ask for strict checking. > > I agree, but what is happening now is that "no newline at end of file" > is an error even when -pedantic is not specified. I don't think that > is acceptable. > > Ian I just stumbled across enhancement request PR14331, which is for this same feature. I think I should update my old patch and submit it. I could use a little advice about the best way to add a new preprocessor option flag setting; my original patch crudely adds a new global warning flag and then copies it into a member in the cpp options struct during c_common_post_options, which I think is probably not "The Right Thing To Do"(TM), and I haven't even studied the 4.x options-handling mechanisms yet, but what Manuel wrote in that PR implies that they have changed a bit since 3.3. cheers, DaveK -- Can't think of a witty .sigline today
RE: nested backticks in Makefile
On 27 March 2007 17:55, DJ Delorie wrote: > When cross compiling with a sysroot, you sometimes end up with nested > backticks. > > The case we're seeing it with is m32r-elf, where gcc_tooldir is defined > thusly: > > gcc_tooldir = $(libsubdir)/$(unlibsubdir)/`echo $(exec_prefix) | sed -e > 's|^$(prefix)||' -e 's|/$(dollar)||' -e 's|^[^/]|/|' -e > 's|/[^/]*|../|g'`$(target_noncanonical) > > and SYSTEM_HEADER_DIR is thusly: > > CROSS_SYSTEM_HEADER_DIR = $(gcc_tooldir)/sys-include > SYSTEM_HEADER_DIR = `echo $(CROSS_SYSTEM_HEADER_DIR) | sed -e :a -e > 's,[^/]*/\.\.\/,,' -e ta` > > Note that we have gcc_tooldir inside backticks, resulting in > `...`...`...`, which bash obviously is going to misinterpret. > > Given that we require GNU make, is the right solution to use $(shell > echo ...) for one of those to disambiguate it? Or how about using ':=' to force immediate evaluation? Does $gcc_tooldir change during the course of a build? If not, it seems pointlessly wasteful to repeatedly invoke shell/echo/sed every single time it's referred to... cheers, DaveK -- Can't think of a witty .sigline today
RE: nested backticks in Makefile
On 27 March 2007 18:25, Andreas Schwab wrote: > "Dave Korn" <[EMAIL PROTECTED]> writes: > >> Or how about using ':=' to force immediate evaluation? > > That won't help, since backquotes are only expanded by the shell, not by > make. Doh. Yes, we'd need immediate evaluation *and* $(shell ...). cheers, DaveK -- Can't think of a witty .sigline today
RE: Broken bootstrap of gcc on cygwin in gengtype
On 28 March 2007 11:57, Kai Tietz wrote: > Hello, > > I noticed a seg-fault in gengtype on cygwin bootstap. Guilty seem to be, > that in method "oprintf" the standard c-library call "vsnprintf" is used, > which is on MSVCRT broken. By a patching it to use vasnprintf it seems to > work. Did somebody noticed this problem too ? Yes, see the thread "Re: fyi: gengtype patches checked in" on the gcc-patches list. No immediate solution yet... cheers, DaveK -- Can't think of a witty .sigline today
How to handle c99 inline changes? [was RE: -fkeep-inline-functions and broken Cygwin bootstrap (was: Building GCC 4.3.0 on Cygwin...)]
On 25 March 2007 07:37, Andrew Pinski wrote:
> On 3/24/07, Brian Dessent wrote:
>> Dave Korn wrote:
>>
>>> # 405 "/usr/include/stdio.h" 3 4
>>
>> [ Which is from newlib (libc/include/stdio.h) if anyone reading this
>> doesn't have a Cygwin system handy. ]
>>
>>> static __inline__ int __sgetc_r(struct _reent *__ptr, FILE *__p) {
>>> [...]
>>>
>>> The critical difference is the presence or absence of
>>> -fkeep-inline-functions. I think I remember there being some change
>>> between gcc-3.x and gcc-4.x in inline handling and I think that's what's
>>> biting us now; I think this may only arise in stage1 where we're trying
>>> to use 3.x to compile 4.x.
>>
>> I too thought that this was related to the c99 inline changes, but I
>> think those only apply to "extern inline" which is not the case here.
>>
>> The real cause seems to be that -fkeep-inline-functions was a no-op up
>> until: <http://gcc.gnu.org/ml/gcc-patches/2007-02/msg01396.html>, which
>> seems to roughly correspond to when bootstrap stopped working on Cygwin.
>>
>
> Actually it was not a no-op in 3.4, just 4.2 (or was it also broken in
> 4.1) broke -fkeep-inline-functions and nobody noticed until later.
> Cygwin's headers are broken with respect of -fkeep-inline-functions
> and need to be fixed.
Ok, I can understand this; we compile with -fkeep-inline-functions in order
to behave the same as other compilers, so that we spot when bootstrapping with
a non-gcc compiler might be broken.[*] That's because non-gcc compilers can't
be relied on to eliminate static inline functions the way gcc does. So far so
good.
The problem is what to replace the function with. Converting it to 'extern
inline' solves the bootstrap problem vs. -fkeep-inline-functions, because the
statically-linked function body is never omitted.
Unfortunately, 'extern inline' is changing behaviour[**] and is about to
start meaning the exact opposite. Once this happens, cygwin bootstrap will
break again.
So, am I correct to believe that we need to use plain 'inline' for c99 after
gcc 4.4, and 'extern inline' before that? That is, I think I need to write a
test that looks like...
#if ((__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 4))) \
&& defined (__STRICT_ANSI__) && (__STRICT_ANSI__ != 0) \
&& defined (__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L)
#define ELIDABLE_INLINE inline
#else
#define ELIDABLE_INLINE extern inline
#endif
I'm not quite sure if I've got that right, though. I don't know if I need to
test __STRICT_ANSI__ or not. I'm not sure if I should be testing for gnu99
mode as well as std99 or not. I want to match the exact conditions that are
going to be tested to invoke the new standard behaviour; is this going to do it?
cheers,
DaveK
[*] - http://gcc.gnu.org/ml/gcc/2006-03/msg00015.html
[**] - http://gcc.gnu.org/ml/gcc/2006-11/msg6.html
--
Can't think of a witty .sigline today
RE: How to handle c99 inline changes? [was RE: -fkeep-inline-functions and broken Cygwin bootstrap (was: Building GCC 4.3.0 on Cygwin...)]
On 28 March 2007 15:14, Ian Lance Taylor wrote: > "Dave Korn" <[EMAIL PROTECTED]> writes: > >> So, am I correct to believe that we need to use plain 'inline' for c99 >> after gcc 4.4, and 'extern inline' before that? That is, I think I need >> to write a test that looks like... >> >> >> #if ((__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ >= 4))) \ >> && defined (__STRICT_ANSI__) && (__STRICT_ANSI__ != 0) \ >> && defined (__STDC_VERSION__) && (__STDC_VERSION__ >= 199901L) >> #define ELIDABLE_INLINE inline >> #else >> #define ELIDABLE_INLINE extern inline >> #endif > > It's simpler than that. I defined new preprocessor macros > specifically to avoid this complexity. Here is one approach that > should work; > > #ifdef __GNUC_STDC_INLINE__ > #define ELIDABLE_INLINE inline > #else > #define ELIDABLE_INLINE extern inline > #endif Fantastic! That's of course far better than trying to duplicate the logic in two places and get it right. Thanks a bunch! cheers, DaveK -- Can't think of a witty .sigline today
