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 # format. That's what I was set to use from the beginning. It's unfortunate that it has faced so much resistance :-( > This is more critical than you may know. I knew it :-) Gratuitous extensions are evil :-) > In my version, I use #pragma gcc_debug_pwd "/sdf/sdf", and that's > turned out to be not as good as I had thought it would be. Yay. > The next problem, before you relicate more work, will be to make > distcc work well in the presence of pch. This doesn't really make sense to me. I mean... pch? We're not doing integrated preprocessing, how does pch come into play? What I'd really like is a patch that fixes the problem I refer to below, after posting my first patch for `# 1 "<directory>/path/name"': 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 FOO((x, y, > z, w)) bar; > int baz; > If we preprocess this code and compile it separately (e.g., > -save-temps), the result is: > # 2 "<filename>" > int bar; > int baz; > i.e., the declaration of bar is moved from line 3 to line 2. However, > with integrated preprocessing, the declaration of bar is correctly > flagged as in line 3 in debugging information. This difference is > enough for the bootstrap compare to fail, since at least varray.h > contains a number of union member declarations like above, with > multi-line GTY() macro invocations between the types and the > declarators. Oh, well... > This should probably be fixed. I don't think it's good that compiling > with or without -save-temps can result in different assembly output. > Neil, Zack, any comments? I've written patches that fixed this problem, but they were rejected or ignored. There's not even agreement that this is a legitimate bug :-( The way I'm thinking of fixing it is to try to figure out when we finish expanding the outermost macro, and at that point emit an explicit line&column adjust to get back in sync with what the integrated preprocessor would use. Unfortunately, the patch I had that would make sure the integrated and separate preprocessors agreed on the location of every token was conceptually rejected, and I never posted it to the list (IIRC) because it actually exposed problems in the integrated preprocessor's tracking of line&column that I could never track down. It wasn't worth pursuing, since both Neil and Zack considered it a bad idea to add enough information to the preprocessed file such that we'd be able to tell exactly where each token came from, at the expense of making it bigger. -- Alexandre Oliva Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/ Red Hat GCC Developer [EMAIL PROTECTED], gcc.gnu.org} CS PhD student at IC-Unicamp [EMAIL PROTECTED], gnu.org} Free Software Evangelist Professional serial bug killer __ distcc mailing list http://distcc.samba.org/ To unsubscribe or change options: http://lists.samba.org/cgi-bin/mailman/listinfo/distcc
