On Sep 13, 2003, Jakub Jelinek [EMAIL PROTECTED] wrote:
On Sat, Aug 23, 2003 at 05:39:51PM -0300, Alexandre Oliva wrote:
* c-ppoutput.c (cb_line_change): Don't skip line changing while
parsing macro arguments in the top-level context.
This patch seems like regression to me:
Yup, just
On Sat, Aug 23, 2003 at 05:39:51PM -0300, Alexandre Oliva wrote:
* c-ppoutput.c (cb_line_change): Don't skip line changing while
parsing macro arguments in the top-level context.
This patch seems like regression to me:
cat foo.S EOF
#define b(x) #x
a b
c
EOF
gcc -E foo.S now outputs:
# 1
[EMAIL PROTECTED];
[EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED];
Mike Stump [EMAIL PROTECTED]
Sent: Monday, August 04, 2003 9:54 AM
Subject: Re: [distcc] gcc bootstraps with distcc
Mark, any chance of having this in the 3.3 branch as well, after 3.3.1
is released? (Assuming it's now too
Alexandre Oliva wrote:-
[snip]
So it seems that it moves the expansion of a macro down to its last
line. Is that the effect? Why is this
|| (parsing_args pfile-context pfile-context-prev))
necessary?
Does this break people preprocessing Fortran?
I've no idea. How do I tell?
On Aug 4, 2003, Neil Booth [EMAIL PROTECTED] wrote:
So it seems that it moves the expansion of a macro down to its last
line. Is that the effect?
Yup. Just the same effect that we get with the integrated
preprocessor.
Why is this
|| (parsing_args pfile-context
Alexandre Oliva wrote:-
Yup. Just the same effect that we get with the integrated
preprocessor.
Why is this
|| (parsing_args pfile-context pfile-context-prev))
necessary?
I wasn't sure it was necessary. I only tried to limit the effects of
my change. I don't see how
On Aug 4, 2003, Neil Booth [EMAIL PROTECTED] wrote:
Alexandre Oliva wrote:-
I don't see how it would be possible for us to take a line
change while processing a macro.
I don't understand your last sentence.
Since macros are always defined in a single logical line, I don't see
how we could
On Aug 3, 2003, Neil Booth [EMAIL PROTECTED] wrote:
it would need to be -fpwd.
Can you please explain to me why you think it makes more sense for the
flag to be -fpwd than -Pwd?
--
Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer
Mark, any chance of having this in the 3.3 branch as well, after 3.3.1
is released? (Assuming it's now too late for 3.3.1; if it's
not... :-)
On Aug 4, 2003, Alexandre Oliva [EMAIL PROTECTED] wrote:
Index: gcc/ChangeLog
from Alexandre Oliva [EMAIL PROTECTED]
* c-ppoutput.c
On Aug 4, 2003, Neil Booth [EMAIL PROTECTED] wrote:
Alexandre Oliva wrote:-
Ok, bootstrapped on i686-pc-linux-gnu, regression tested, no
regressions. I'm checking this patch in. It includes a testcase that
will let us know in case we unintentionally change behavior.
I think with this
On Monday, August 4, 2003, at 09:54 AM, Alexandre Oliva wrote:
Mark, any chance of having this in the 3.3 branch as well, after 3.3.1
is released? (Assuming it's now too late for 3.3.1; if it's
not... :-)
I'd like this (Apple would like this) for 3.3.x release branch. We
don't care which
Alexandre Oliva [EMAIL PROTECTED] writes:
| Agreed. Still, I think -Pwd fits in better.
IMHO -Pwd is quite irregular. GCC has a good tradition of descriptive
names of switches, all starting with -f or --.
Andreas.
--
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux AG,
On Jul 16, 2003, Alexandre Oliva [EMAIL PROTECTED] wrote:
On Jul 14, 2003, Alexandre Oliva [EMAIL PROTECTED] wrote:
I don't see anything clear about it. -f to me is an option to the
compiler. This one isn't. It's an option to the preprocessor. I'm
currently thinking -Pwd would be the best
On Jul 11, 2003, Alexandre Oliva [EMAIL PROTECTED] wrote:
On Aug 23, 2002, Alexandre Oliva [EMAIL PROTECTED] wrote:
Unfortunately, the bootstrap compare test still failed :-(
The reason is that gcc generates different debugging information for a
source file such as:
#define FOO(X)
int
Alexandre Oliva wrote:-
It was actually simpler and sufficient to simply let line-breaks
through while parsing functional-macro arguments. Column numbers go
out of sync, but Neil doesn't care, so...
With this patch and the one I posted about 1 hour ago, a bootstrap of
GCC with distcc
On Aug 3, 2003, Neil Booth [EMAIL PROTECTED] wrote:
I don't agree this patch is correct.
Then we'll have to fix the integrated preprocessor to do whatever you
consider to be correct. This patch only arranges for the separate
preprocessor to match what the integrated one does as far as the
On Aug 3, 2003, Neil Booth [EMAIL PROTECTED] wrote:
No response, so I assume -Pwd is a reasonable option. Here's a
patch, bootstrapped on i686-pc-linux-gnu. Ok to install?
There has been no agreement on this patch.
Which is why I have only posted it, instead of just checking it in.
If
Alexandre Oliva wrote:-
Then we'll have to fix the integrated preprocessor to do whatever you
consider to be correct. This patch only arranges for the separate
preprocessor to match what the integrated one does as far as the
compiler computes the line of a declaration.
Please post an
On Jul 11, 2003, Neil Booth [EMAIL PROTECTED] wrote:
Alexandre Oliva wrote:-
+ _cpp_do_file_change (pfile, LC_RENAME, dir_with_slashes, 1, 0);
+ _cpp_do_file_change (pfile, LC_RENAME, name, 1, 0);
+}
Is the second rename necessary? I don't see why it should be;
if not
On 10 Jul 2003, Zack Weinberg [EMAIL PROTECTED] wrote:
Alexandre Oliva [EMAIL PROTECTED] writes:
On Jul 10, 2003, Zack Weinberg [EMAIL PROTECTED] wrote:
Yeah. I vote always do it, too.
Fine, I'll do that. As long as there's a way to disable it, I'm fine
with it. I dislike that it
Martin Pool [EMAIL PROTECTED] writes:
I don't understand. On by default makes sense precisely because
there's no bad side effect to this feature. If there *is* a bad
side effect which I'm not aware of, then my opinion may be different,
but I don't see how having this information in the .i
On 10 Jul 2003, Zack Weinberg [EMAIL PROTECTED] wrote:
Thank you for the clear explanation. The conclusion I draw from it is
that we should turn this mode on when and only when it affects the
output of the compiler. Would you, Martin, be willing to do some
research and figure out under
On Jul 11, 2003, Zack Weinberg [EMAIL PROTECTED] wrote:
Thank you for the clear explanation. The conclusion I draw from it is
that we should turn this mode on when and only when it affects the
output of the compiler.
I.e., whenever debugging is enabled. This will still defeat ccache,
since
On Thursday, July 10, 2003, at 11:48 PM, Zack Weinberg wrote:
Thank you for the clear explanation. The conclusion I draw from it is
that we should turn this mode on when and only when it affects the
output of the compiler.
Yes. This is a fine optimization. I'd prefer not to block the current
On 11 Jul 2003, Alexandre Oliva [EMAIL PROTECTED] wrote:
On Jul 11, 2003, Zack Weinberg [EMAIL PROTECTED] wrote:
Thank you for the clear explanation. The conclusion I draw from it is
that we should turn this mode on when and only when it affects the
output of the compiler.
I.e.,
Mike Stump [EMAIL PROTECTED] writes:
On Sunday, July 6, 2003, at 03:26 PM, Alexandre Oliva wrote:
On Jul 6, 2003, Alexandre Oliva [EMAIL PROTECTED] wrote:
BTW, I may have found out why the differences in macro line numbers
were gone: distcc assumes -Mpwd requires local execution, so it
On Jul 10, 2003, Mike Stump [EMAIL PROTECTED] wrote:
They bear a strong resemblance to my own patches that I developed
and delivered in our product for distcc. :-)
Did you base yours in the patch I posted 11 months ago? :-)
Your version has one advantage over mine,
they reuse of the #
On Jul 10, 2003, Zack Weinberg [EMAIL PROTECTED] wrote:
Yeah. I vote always do it, too.
Fine, I'll do that. As long as there's a way to disable it, I'm fine
with it. I dislike that it will prevent legitimate uses of ccache and
make gcc different from all other compilers in this regard, but,
Alexandre Oliva wrote:-
After some further discussion on IRC, I ended up having to go with a
different format to implement the directory line markers. Here's the
implementation. Ok to install?
It's worth noting that there was never a consensus on what to do.
I dislike this approach as 1)
On Jul 2, 2003, Neil Booth [EMAIL PROTECTED] wrote:
The LC_ are for a clear purpose: they indicate change of file name;
Well, surely a file name is not something that has a meaning by
itself. Unless it's a full pathname, it only has a complete meaning
when given a working directory. So, in a
On Jul 2, 2003, Martin Pool [EMAIL PROTECTED] wrote:
In general I would like to favour correctness over performance.
I agree, but since this is an issue that ccache should attempt to
address without cooperation from the compiler, since most (all?)
compilers will behave just like GCC without
Alexandre Oliva wrote:-
Nope. I didn't before my patch, because it duplicated built-in and
command line entries, and it doesn't after my patch, with the
difference that it introduces a duplicate directory directive too.
I *think* this was not the case when I originally wrote this patch; it
On Jul 6, 2003, Alexandre Oliva [EMAIL PROTECTED] wrote:
However, preprocessing a .i file should continue to output its
input. Does it?
Nope. I didn't before my patch, because it duplicated built-in and
command line entries
Err... Unless -fpreprocessed was given in the command line.
On Jul 6, 2003, Neil Booth [EMAIL PROTECTED] wrote:
It shouldn't duplicate them - it didn't when I last worked on this
stuff. Are you sure you passed -fpreprocessed?
I certainly didn't *blush* :-)
Hmmm. I just tested it and it works OK.
Same here. I've already fixed the bug that caused
Alexandre Oliva wrote:-
Same here. I've already fixed the bug that caused the duplication of
directory entries, but I'll refrain from posting a revised patch for
now, since we're still discussing other issues.
I'm thinking one way to handle it more efficiently would be to turn it
into a
On Jul 6, 2003, Neil Booth [EMAIL PROTECTED] wrote:
Alexandre Oliva wrote:-
#pragma GCC debugdir /path/name
This looks good at first glance. I image we'd only accept it if
-fpreprocessed?
Cool, here's the patch I came up with. I'm still bootstrapping it.
Ok if it passes?
BTW, I may
On Jul 6, 2003, Alexandre Oliva [EMAIL PROTECTED] wrote:
On Jul 6, 2003, Neil Booth [EMAIL PROTECTED] wrote:
Alexandre Oliva wrote:-
#pragma GCC debugdir /path/name
This looks good at first glance. I image we'd only accept it if
-fpreprocessed?
Cool, here's the patch I came up with.
On Jul 6, 2003, Alexandre Oliva [EMAIL PROTECTED] wrote:
BTW, I may have found out why the differences in macro line numbers
were gone: distcc assumes -Mpwd requires local execution, so it never
ran separate preprocessing and remote compilation. Oops.
Confirmed, the problem is still there.
Alexandre Oliva [EMAIL PROTECTED] writes:
The patch introduces -Mpwd, that causes GCC to output the
preprocessing directory in the preprocessed output. This means you
have to add -Mpwd to BOOT_CFLAGS to get a successful bootstrap, as
well as to get gdb to find source files in their original
On 2 Jul 2003, Alexandre Oliva [EMAIL PROTECTED] wrote:
I'm undecided. People like to be able to share ccaches, despite the
fact that, if they do, they'll end up visiting a different, shared
source code base (which is generally fine, since, if there was a cache
hit, the code is identical
On Jul 2, 2003, Neil Booth [EMAIL PROTECTED] wrote:
source and build trees. The reasons -Mpwd is not enabled by default
are backward compatibility (the directory directive might be
unexpected, even though it's in a format that is entirely
backward-compatible), efficiency and to enable
On Jun 19, 2003, [EMAIL PROTECTED] wrote:
On 18 Jun 2003, Dara Hazeghi [EMAIL PROTECTED] wrote:
it's good to see that distcc just keeps improving! I
had one question. In the known problems list, it is
mentioned (or rather implied) that distcc can't be
used for gcc bootstraps. Is this still
--- [EMAIL PROTECTED] wrote:
I haven't tried it. My impression was that you
could make it work by
excluding localhost from the list, though you might
also need to put
the build directory on a shared filesystem so that
the later compilers
can be found. I think Alexandre might know.
On 18 Jun 2003, Dara Hazeghi [EMAIL PROTECTED] wrote:
Hello,
it's good to see that distcc just keeps improving! I
had one question. In the known problems list, it is
mentioned (or rather implied) that distcc can't be
used for gcc bootstraps. Is this still the case? If
so, perhaps a bug can
Hello,
it's good to see that distcc just keeps improving! I
had one question. In the known problems list, it is
mentioned (or rather implied) that distcc can't be
used for gcc bootstraps. Is this still the case? If
so, perhaps a bug can be opened against gcc?
Dara
P.S. One other little thing: I
45 matches
Mail list logo
