Re: How is lang.opt processed?
Toon Moene wrote:- > >Thanks for the detailed explanation of how > >GCC options work. I'm currently thinking > >of proposing a RFC with recommendations on > >how to address this problem with gfortran. > > Ditto. Jim, are you reading from some documentation about this option > processing that I couldn't find ? I've spend hours and hours to try to > deduce the option processing rules from debugging various parts of the > gcc driver, with no success. gcc -v is worth using just to see what it's passing to the underlying programs. This would have immediately revealed that -i8 and -r8 are being lost in the driver. Neil.
Re: How is lang.opt processed?
Steve Kargl wrote:- > Yeah, tell us something we did not know! The problem, until > Jim explained option handling, is *why* these were not passed > to gfortran. Finding the info is/was non-obvious. What is > even more appalling is that there is no way to inhibit the > swallowing of the options. Ah, OK. I assumed that since you referred to lang.opt (the title of this whole thread) you were looking in the front ends. The driver and lang.opt are completely separate; the driver runs in the fabulous world of specs, which as you've noticed suck. They're reasonably well documented in gcc.c though. Changing how they work will give you more than a headache. Neil.
Re: New gcc 4.0.0 warnings seem spurious
Vincent Lefevre wrote:- > > Before the conversion, the value is representable in the type of > the expression, and after the conversion (which is well-defined), > it is still representable in the (new) type of the expression. > 6.7.8#11 mentions the possible conversion. So, I disagree here. Warnings aren't only intended for undefined things; they're supposed to point out suspect constructs. If my compiler didn't warn about assigning a 32-bit quantity to an 8-bit one I'd think it a poor implementation. Even better, you can turn of the warning with a cast, making your intent explicit to the compiler, so there's every reason to have it on by default. Neil.
Re: preprocessor/21250 and address of
Per Bothner wrote:- > Opinions on how to handle this bug? > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21250 > > This came up because we give declarations > line 0, but used line 1 in a different date structure. > I fixed the code to consistently use line 0, which is > needed for the --enable-mapped-location unification. > > However, we end up with preprocessor output like this: > > # 1 "any-file" > # 0 "" > # 1 "" > # 1 "any-file" > > Some assemblers complain about line number 0. This is especially > an issue for people who use cpp to preprocessor assembler, which > of course we don't really support. > > My suggested solution: suppress the output of , so > we get: > # 1 "any-file" > # 1 "" > # 1 "any-file" > > There should never be anything following , so it's useless Well, there is with -d output dumping. > as well as confusing. Also, if we compile multiple files at once (or > use a compile server), then logically the declaration > *precede* all the actual code, which suggests that if is > output it should be the *first* line. I wanted it to be the first line, but like you say it breaks too much including GCC's own -fpreprocessed. > But that would break too much > code. Simplest and cleanest solution: Just get rid of the > line in pre-processor output. This might break some tools that look > at cpp output, but it seems unlikely. Agreed - we never guarantee the form of -E anyway. Neil.
Re: Why the V4QImode vector operations are expanded into many SImode at "oplower" pass?
Ling-hua Tseng wrote:- > struct gcc_target targetm = TARGET_INITIALIZER; > ... > #undef TARGET_VECTOR_MODE_SUPPORTED_P > #define TARGET_VECTOR_MODE_SUPPORTED_P unicore_vector_mode_supported_p TARGET_INITIALIZER has already been expanded above, so it's not seen your macro definition below. Neil.
Re: proposed Opengroup action for c99 command (XCU ERN 76)
Paul Eggert wrote:- > Here's the problem. Currently, POSIX places almost no requirements on > how c99 transforms the physical source file into C source-language > characters. For example, c99 is free to treat CR as LF, ignore > trailing white space, convert tabs to spaces, or even (perversely) > require that input files all start with line numbers that are > otherwise ignored. This lack of specification was not intended, and > I'm trying to help nail down the intent of what c99 is allowed to do. I suggest we simply remove the GCC extension. I never liked it, it's awkward to code, and it slows down CPP a bit. Neil.
Re: No effect of -fshort-enums..is it a bug
Gaurav Gautam, Noida wrote:-
> #include
> int main()
> {
>enum aa {
>a = 0, b =127 , c
>};
> printf("size = %d %d %d\n", sizeof(enum aa),sizeof(b),sizeof(c));
> printf("value= %d %d %d\n", a,b,c);
> return 0;
> )
>
> The output is
> size = 1 1 1
> value= 0 127 128
> when gcc (GCC) 3.3.1 (SuSE Linux) is used with -fshort-enums.
>
> And
>
> size = 1 4 4
> value= 0 127 128
> when (GCC) 4.1.0 20050915 (experimental) is used with -fshort-enums.
>
> Please confirm which of the two outputs is correct and why is there a
> difference in the output of two versions of compiler?
4.1.0 is correct, therefore 3.3.1 was buggy.
Neil.
Re: gcc -I- feature
nmake Technical Support wrote:- > This is to request reinstatement of the -I- command line directory > search option. Sorry for the late request, we only recently became > aware that -I- is deprecated in gcc 4.0. I agree this should not be removed (have been removed?). It is now provided by a large number of compilers and people have found good uses for it. I am not sure why it was slated for removal. Neil.
Re: backslash whitespace newline
Howard Hinnant wrote:- > I've been reviewing the age-old issue of interpreting > * as the end-of-line indicator as is the current > practice with gcc. FWIW I support abandoning this behaviour too. Neil.
Re: backslash whitespace newline
Dave Korn wrote:- > > I would like it to be retained in at least one case: CRLF line endings > should still work, specifically backslash-CR-LF should be usable to indicate > a continued line. So how about having gcc accept > > ? > > instead? This is entirely orthogonal; the two issues should not be confused. Neil.
Re: semantics of null lang_hooks.callgraph.expand_function?
Jim Wilson wrote:- > Gary Funck wrote: > >While working with GCC's language hooks, we found that > >certain places in GCC test for a null value of > >lang_hooks.callgraph.expand_function, but > >cgraph_expand_function() calls the hook directly: > > When cgraph was first added, it was optional, and could be disabled if > -fno-unit-at-a-time was used, or if the language front-end did not > support cgraph. > > For a while, our intentions have been to make this mandatory, and > eliminate the -fno-unit-at-a-time option. It appears that we have > already reached the point where front end support for cgraph is > mandatory, as the code no longer works when callgraph.expand_function is > NULL. This means all of the checks for NULL are now obsolete and can be > removed. The -fno-unit-at-a-time options still exists meanwhile, but > will eventually be dropped. > > It looks like gcc-3.4 supports a NULL callgraph.expand_function hook, > and gcc-4.0 and later do not, so I'd guess this transition happened when > tree-ssa got merged in. Or maybe it was enabled by the tree-ssa work. In general I think the idea with hooks, whether language or target, was that they were all non-NULL and so we avoided this issue and scattering conditionals everywhere. If you wanted to do nothing you used an empty hook, which was usually the default. Neil.
Re: -Wuninitialized issues
Jeffrey A Law wrote:- > After pondering this some more I almost wonder if what we need is a > separate warning for variables which were potentially uninitialized > but which optimization passes somehow proved were unused or the paths > in which the variable was uninitialized were unexecutable. > > So the early pass would catch unconditionally uninitialized variables; > it would also record (but not warn for) maybe uninitialized variables > (by detecting default definitions appearing in PHI nodes). > > The late pass would then issue a may-be-uninitialized warning for > any variables which still had a default definition appearing in a > PHI node. I think this is a better approach than the current one, and that if we go down this patch then we should grasp the opportunity to do it right - the early pass should be in the front end. Let the optimizers do the fancy cases. 90% of cases that catch bugs can be handled in the front end I expect, with a very simple algorithm. Neil.
Re: -Wuninitialized issues
Chris Lattner wrote:- > >I think it's worth noting that we build the SSA form even when we're > >not optimizing. Which in turn with running the maybe-uninitialized > >warning code early would give you the warnings you expect without > >needing to run the optimizers. That's why I don't think we need to push > >these warnings into the front-ends. > > Sure, running it as the first stage of the optimizers has the effect of > making it have the properties I desire, without requiring the front-ends > to duplicate the code. Such a feature would be great to have! I agree if it's run with -fsyntax-only; IMO this flag should pick up the obvious cases. Neil.
Re: [RFC] PR/24900: computed but not used cast values
Richard Henderson wrote:- > On Thu, Nov 17, 2005 at 03:18:00PM -0800, Ian Lance Taylor wrote: > > I don't think you should get a warning for not using the return value of a > > function, at least not under -Wunused. > > For this, I agree. Except that we're not talking about the > return value of the function directly, we're talking about > the return value of a cast. > > Given that one can always cast any value to void to suppress > this warning, I'm unconcerned about getting every single edge > case "correct". Especially for edge cases for which one can > reasonably disagree as to what is correct. My 2 cents: a) the warning should stay, but the wording should be about a pointless (or unused) cast instead b) the kernel folks should have 2 macros, with and without the cast, and use whichever is appropriate. Assuming the cast is useful somewhere, of course. Neil.
Re: MISRA C support for GCC?
Fredrik Hederstierna wrote:- > Hi > > Do anyone know if there exist any project to get GCC support checking of > MISRA C rules? Otherwise, do anyone think this is a good idea? Derek Jones analyses them here http://www.knosof.co.uk/misracom.html and they don't come off looking well thought-out. I realize they have since been updated. This is the first request I have seen for it in GCC FWIW. Neil.
Re: 20040309-1.c vs overflow being undefined
Andreas Schwab wrote:-
> Andrew Pinski <[EMAIL PROTECTED]> writes:
>
> > sorry wrong number, I had meant 32769.
> > if (foo (32769) != 1)
> > abort ();
>
> I think with 16 bit ints you should get 0 here, since (int)32769 ==
> -32767, which is less than 32767.
int foo(unsigned short x)
{
unsigned short y;
y = x > 32767 ? x - 32768 : 0;
return y;
}
With 16-bit ints unsigned short promotes to unsigned int, since int
does not hold all the values. Similarly 32768 has type unsigned int
and not int from inception. So everything is unsigned and it should be:
y = 32769U > 32767U ? 32769U - 32768U: 0;
which is 1 to my understanding.
Neil.
Re: undefined declaration in pre-processed generated C file
GALLEGGIANTI Bruno wrote:- > typedef __builtin_va_list __gnu_va_list; > > My problem is that __builtin_va_list is never declared/defined in the > pre-processed file. I've no warning about that (-Wall option) > > Following this behaviour, I have 3 questions: > > 1) How does gcc compiler resolve this typedef (before link stage) ? __builtin_va_list is, as described, built-in to the compiler. It is not defined anywhere; it's built-in definition may well be target- specific. You will always have this problem operating on preprocessed source. Other compilers have similar built-in definitions, such as __NAN__. Preprocessed source is compiler-specific. Neil.
Re: "Experimental" features in releases
Kai Henningsen wrote:- > [EMAIL PROTECTED] (Daniel Berlin) wrote on 18.04.06 in <[EMAIL PROTECTED]>: > > > This is in fact, not terribly surprising, since the algorithm used was the > > result of Sebastian and I sitting at my whiteboard for 30 minutes trying to > > figure out what we'd need to do to make swim happy :). > > > This would leave -ftree-loop-linear in 4.2, but make it not useful for > > increasing SPEC scores. > > So is this an object lesson for why optimizing for benchmarks is a bad > idea? It certainly seems that way to me. Neil.
Re: VLA/VM [*] bug fixes for C
Joseph S. Myers wrote:-
> for that case. To quote my message:
>
> Consider the code
>
> int a, b, c, d, e, f;
> void *p1(void), *p2(void), *p3(void);
> int c1(void), c2(void);
> int d1(void), d2(void), d3(void);
> int z1(void), z2(void), z3(void);
>
> int
> h(void)
> {
> int r = (c1()
> ? (z1(), (int (*(*(*)[d1()])[])[])p1())
> : (c2()
> ? (z2(), (int (*(*(*)[])[d2()])[])p2())
> : (z3(), (int (*(*(*)[])[])[d3()])p3())
>)
> )[a][b][c][d][e][f];
> return r;
> }
>
> The outer conditional expression has a type which may informally be
> described as "pointer to arrays [d1()] of pointers to arrays [d2()] of
> pointers to arrays [d3()] of ints", by the composite type rules applied
> to
> conditional expressions. But when the expression is executed, all
> three
> dimensions are needed to evaluate the [a][b][c][d][e][f] array
> reference,
> but only one of the dimensions appears in an expression which should be
> evaluated according to the rules for evaluation of conditional
> expressions. Furthermore, the return value of d2() may depend on the
> prior calls to c2() and z2() in that part of the conditional
> expression,
> so if c1() returns nonzero it might not suffice simply to evaluate d2()
> and d3() as well as d1(); c2(), z2() and z3() would also need to be
> evaluated.
My front end, and Comeau's oneline compiler, both give a similar
message:
"/tmp/foo.c", line 10: error: expression must point to a complete type
int r = (c1()
^
which seems reasonable based on my understanding of composite types
of VLA types: that either satisfies the requirements of, and therefore
can be taken to be, the composite type.
Neil.
Re: VLA/VM [*] bug fixes for C
Joseph S. Myers wrote:-
> > which seems reasonable based on my understanding of composite types
> > of VLA types: that either satisfies the requirements of, and therefore
> > can be taken to be, the composite type.
>
> I think the type's complete: the recursive application of the composite
> type rules means that the composite of each [] and [VLA] pair is the
> [VLA], yielding a composite type int (*(*(*)[d1()])[d2()])[d3()]; the
> trouble being that d1(), d2() and d3() won't all have been evaluated when
> the composite type is required.
Unfortunately the expression is a big mess. I hope you'll permit me
to examine the slightly simpler
int
h(void)
{
int r = (0 ? (int (*(*)[d1()])[]) p1(): (int (*(*)[])[d2()]) p2()
)[a][b][c][d];
return r;
}
which I believe is analogous and my front end similarly rejects.
The logic goes like so:
We are parsing a conditional expression. We have the true and false
branches. The branches have types
int (*(*)[d1()])[]
int (*(*)[])[d2()]
namely "pointer to incomplete array of ..." and "pointer to VLA of ...".
The unqualified forms of the pointed-to types are compatible.
The conditional expression therefore has type "pointer to appropriately
qualified form of the composite type" by 6.5.15p6.
For the composite type, 6.2.7p3 dash 1 applies, and the composite is
the VLA type. That VLA type is derived indirectly from an incomplete
type, and hence subscripting that incomplete type falls foul of the
contraint on the subscript operator.
I believe your example is the same, just with an extra level of nesting
from the nested conditional expression.
If you disagree could you point out the error in my reasoning?
Neil.
Re: VLA/VM [*] bug fixes for C
Joseph S. Myers wrote:- > On Sun, 7 May 2006, Neil Booth wrote: > > > For the composite type, 6.2.7p3 dash 1 applies, and the composite is > > the VLA type. That VLA type is derived indirectly from an incomplete > > type, and hence subscripting that incomplete type falls foul of the > > contraint on the subscript operator. > > > > I believe your example is the same, just with an extra level of nesting > > from the nested conditional expression. > > > > If you disagree could you point out the error in my reasoning? > > I believe that "These rules apply recursively to the types from which the > two types are derived." means that the composite of T1[variable] and T2[] > is not T1[variable] but (composite(T1,T2))[variable]. I do not think > interpreting "is that type" to override the recursivity makes sense, > because it would yield self-contradictory results for the composite type > of two VLA types which are compatible but not the same. Well, the language is clearly different. For the known constant size case it doesn't say "that type" it says "array of that size". Had your reading been intending it could just as well say "array of that size" for a VLA case, and even collapse the wording. It doesn't, however, it explicitly separates them and says "that type". This may just be poor wording, but games with precise reading are used to justify treating "void" differently from "qualified void" so I'm generally inclined to take the standard's wording literally. It appears EDG independently read it that way too. Neil.
Re: preprocessing question
Jan Beulich wrote:-
> Can anyone set me strait on why, in the following code fragment
>
> int x(unsigned);
>
> struct alt_x {
> unsigned val;
> };
>
> #define xalt_x
> #define alt_x(p) x(p+1)
>
> int test(struct x *p) {
> return x(p->val);
> }
>
> the function invoked in test() is alt_x (rather than x)? I would have
> expected that the preprocessor
> - finds that x is an object like macro, and replaces it with alt_x
> - finds that alt_x is a function-like macro and replaces it with x(...)
> - finds that again x is an object like macro, but recognizes that it
> already participated in expansion, so doesn't replace x by alt_x a
> second time.
>
> Our compiler team also considers this misbehavior, but since I
> tested three other compilers, and they all behave the same, I
> continue to wonder if I'm mis-reading something in the standard.
The way GCC works is, once you've had to suck in the '(' for the
expansion of alt_x, you've left x, and further replacements are not
considered nested within x.
This is the behaviour of Dave Prosser's algorithm that the C90
committee agreed on, and then converted to (ambiguous) words.
Their general approach was to expand as much as possible when you
could be sure of not recursing. Since the '(' leaves the original
expansion to suck in more tokens this is the case.
You will find GCC behaves the same even if just the ')' leaves the
original x.
This tends also to be the most useful behaviour when writing macros,
and *is* relied upon by a lot of software. Changing the expansion
rules will break a lot of GCC's testcases, which I intentionally
wrote to cover its algorithm pretty well, so it couldn't be accidentally
broken in future.
Neil.
Re: [RFC] fold Reorganization Plan
Mark Mitchell wrote:- > However, while that may be necessary for Java, it's not necessary for > C++. In C++, fold should only be called for "integral constant > expressions", which, by definition, are made up of simple operations on > integers. (It's a little more complicated than that, but all the > operands collapse to integers immediately.) So, all we really need for > C++ is the ability to convert floating-point constants to integer > constants, and the ability to do basic arithmetic on integer constants. I think it's desirable for front-ends to be able to fold floating point constant expressions too, no? It can be handy for diagnostics such as detecting overflow or unreachable code based on conditionals whose expression is a floating one, albeit constant. Neil.
Re: [RFC] fold Reorganization Plan
Joe Buck wrote:- > > I think it's desirable for front-ends to be able to fold floating > > point constant expressions too, no? It can be handy for diagnostics > > such as detecting overflow or unreachable code based on conditionals > > whose expression is a floating one, albeit constant. > > The problem is that the user can independently set the IEEE rounding mode. > This means that you can only fold floating point constants in cases where > the generated result is exact; you cannot fold 1./3. for example. As Joseph pointed out, that's what the C99 pragma is for. For C90 it is probably best to not fold unless exact or it is necessary. > Also, you should not assume that the user wants the kinds of diagnostics > you describe; they might *want* the Infinity or NaN they generated. You seem to have missed my point. Nowhere did I say such a thing be thrown away. I was talking about diagnostics. Joseph pointed out the compiler needs to be able to fold for some initializers anyway. Whether you can perform the analysis, and how the user can control the results of that analysis - what you seem to be referring to - are of course entirely orthogonal. Neil.
Re: C++ PATCH:
Gabriel Dos Reis wrote:- > That statement is factually false as can be verified with EDG-3.5: Oh come on Gaby, that's not printing an expression, it prints the raw source line, comments and trigraphs included. Are you proposing your pretty printer do that too? Neil.
Re: C++ PATCH:
Gabriel Dos Reis wrote:- > Please, the statement was that EDG does not print expression outside > declarations. But the fact is it does not just print declarations. It > prints also statements and expressions part of those statements. And the fact is it Mark is right - it doesn't. It prints raw source lines. I think you owe Mark an apology. Your message was downright rude and inappropriate for a public forum. I also suggest you stop viewing everything as a personal attack. Neil.
Re: US-CERT Vulnerability Note VU#162289
David Miller wrote:- > From: Joe Buck <[EMAIL PROTECTED]> > Date: Wed, 23 Apr 2008 08:24:44 -0700 > > > If CERT is to maintain its reputation, it needs to do better. The warning > > is misdirected in any case; given the very large number of compilers that > > these coding practices cause trouble for, you need to focus on the bad > > coding practices, not on unfair demonization of new GCC releases. > > In my opinion CERT's advisory has been nothing but an unfair FUD > campaign on compilers, and GCC specifically, and has seriously > devalued CERT's advisories, in general, which were already of low > value to begin with. > > It looks similar to a news article run by a newspaper that is losing > money and has no real news to write about, but yet they have to write > about something. > > The worst part of this fiasco is that GCCs reputation has been > unfairly harmed in one way or another, and there is nothing CERT can > do to rectify the damage they've caused. I'm appalled that the original desciption hasn't been corrected. The text reads: Some C compilers optimize away pointer arithmetic overflow tests that depend on undefined behavior without providing a diagnostic (a warning). Applications containing these tests may be vulnerable to buffer overflows if compiled with these compilers. I. Description In the C language, given the types: char *buf; int len; some C compilers will assume that buf+len >= buf. which is an entirely bogus description of the problem. That this incorrect description of the state of affairs has been left to stand only shows that CERT, and those responsible for this advisory, have completely failed to understand what the real issue is here. Further, the fact that the "advisory" stands in this erroneous form, despite it having been pointed out to them many times over the past weeks on this form at least, seriously undermines their credibility in the eyes of any informed observer. At a minimum the wording should be something more like: In the C language, given an object OBJ and a pointer BUF into OBJ, char *buf; int len; the C standard requires that the result of buf + len must point within, or one byte beyond, the object BUF. A program that does not satisfy this constraint is erroneous, and many compilers take advantage of this constraint to optimize code more effectively. Unforunately much existing code is not well written and sometimes erroneous in this regard, and hence may not behave as originally intended when compiled with optimizations enabled. Neil.
