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
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.
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.
Warn
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-m
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
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)
>
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
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 l
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.
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 sho
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, an
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.
>
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 n
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
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-o
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)
{
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
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 d
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
>
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
> typ
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 incomplet
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 t
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 a
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
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.
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 ra
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
27 matches
Mail list logo
