This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Your changes to diagnostic machinery


"Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:

|  > From: Gabriel Dos Reis <gdr@integrable-solutions.net>
|  > 
|  > "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu> writes:
|  > 
|  > | Yes that was intentional on my part, as noted by these comments in
|  > | c-common.c:
|  > | 
|  > | 	#include "c-tree.h"
|  > | 	/* In order to ensure we use a common subset of valid specifiers
|  > | 	   (between the various C family frontends) in this file, we restrict
|  > | 	   ourselves to the generic specifier set.  */
|  > | 	#undef GCC_DIAG_STYLE
|  > | 	#include "toplev.h"
|  > 
|  > Currently, what are the C family front ends that use the machinery?  I
|  > can see C, C++ and Objective C.  All of them recognize %D and
|  > variants. 
| 
| That's not the issue.
| 
| My point is that we have to choose at compile-time on a compilation
| unit (per-file) basis which specifier set is valid for each particular
| file.

I think that approach is fundamentally broken because we're dealing
with an evolving software and we need more flexibility than the
approach you outlined.

We don't need an inflexible scheme that gets into the way each time
something sound is added.

| You can't have more than one valid set in any particular file,
| because each file is compiled exactly once.

Sure that file is compiled once, but can be run many times.  Instead
of fixing the parameters at compile-time, they should be set at
run-time. 

| Given that, which set do
| we choose for files linked into more than one language like
| c-common.c?

That is why I suggested the valid format specifiers be registred at
run-time instead of being hardwired at compile-time.

[...]

|  > Furthermore, because C++ codes can call codes in c-common.c, it is
|  > important that C++ front end specifiers be allowed to pass through.
|  > That is true for C++, but it is also true for any front-end that
|  > happens to  use c-common.c
| 
| No I strongly disagree with you here.  If you use a specifier only
| valid in the C++ frontend in c-common.c, what's to stop the C frontend
| from calling that same code and crashing because it doesn't understand
| that specifier?

You missed the point:  %D is not just a C++ format speficier.  It is
also a C and Objective C formats specifier.
Furthermore if the code is in c-common.c, certainly it is not just a
C++ code, thus the format specifier is shared by all front-ends that
use c-common.c.  

| If you find yourself needing to use a C++ frontend specifier in
| c-common.c, then I suspect that code should really live in the cp/
| directory.

No you missed the issue.  

I'm just going to remove those attributes.

| 
| 
|  > That is why I said (when you first brought the issue) that the format
|  > specifiers should be registered at start-up by front-end and not
|  > something syntactically hardwired in the code.
|  > [...]
|  > Thanks,
|  > -- Gaby
| 
| Sorry that makes no sense to me, "registered at start-up" of what
| exactly, the compiler being built?

Yes.  Just like we set other flags at start up.
The formats-specifiers chercher is part of the compiler, it needs
reference data to chech agains the supplied formt specifiers used in
diagnostic functions.  Those reference data should be supplied at
startup. They are no different from other flags.

-- Gaby


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]