Re: -Wparentheses lumps too much together
Ian Lance Taylor <[EMAIL PROTECTED]> writes: | "Doug Gregor" <[EMAIL PROTECTED]> writes: | | > To make this discussion a bit more concrete, the attached patch | > removes this particular warning from -Wparentheses and puts it into a | > new warning, -Wprecedence, that is not enabled by -Wall. This is | > slightly more fine-grained than what -Wparentheses does now. Opinions? | | Personally, I think it should stay in -Wall. But I'm willing to hear | other opinions. I agree that the warning should stay in -Wall. However, we may consider giving that group a more suggestive name, such as -Wprecedence/-Wno-precedence (enabled by default). -- Gaby
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
Sunday 13 January 2008 17:41:03 tarihinde Gabriel Dos Reis şunları yazmıştı: > Ismail Dönmez <[EMAIL PROTECTED]> writes: > | Hi again, > | > | Wednesday 09 January 2008 00:28:54 tarihinde Manuel López-Ibáñez şunları > | > | yazmıştı: > | > For your particular example, you could open a regression bug against > | > 4.3 that says: > | > * '"foo' redefined" is not mandated by the standard or it is not > | > serious enough, so it should not be a pedwarn just a normal warning; > | > or > | > | Looks like this is actually mandated by standard :-( , thats what I am > | told on #gcc anyway :) > > #define foo bar > #define foo baz > > is asking for trouble -- one should look for fixing the source of that > inconsistency. That was just an example, real life testcase shows that problem stems from autoconf and its config.h. Projects end up defining things like HAVE_STDLIB_H twice which is not harmful at all but now causes an error if g++ is used. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
Ismail Dönmez <[EMAIL PROTECTED]> writes: | Hi again, | | Wednesday 09 January 2008 00:28:54 tarihinde Manuel López-Ibáñez şunları | yazmıştı: | > For your particular example, you could open a regression bug against | > 4.3 that says: | > * '"foo' redefined" is not mandated by the standard or it is not | > serious enough, so it should not be a pedwarn just a normal warning; | > or | | Looks like this is actually mandated by standard :-( , thats what I am told on | #gcc anyway :) #define foo bar #define foo baz is asking for trouble -- one should look for fixing the source of that inconsistency. -- Gaby
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
Ismail Dönmez <[EMAIL PROTECTED]> writes: > That was just an example, real life testcase shows that problem stems from > autoconf and its config.h. Projects end up defining things like HAVE_STDLIB_H > twice which is not harmful at all but now causes an error if g++ is used. Redefinitions with the same replacement list are not an error. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
Sunday 13 January 2008 18:03:20 tarihinde Andreas Schwab şunları yazmıştı: > Ismail Dönmez <[EMAIL PROTECTED]> writes: > > That was just an example, real life testcase shows that problem stems > > from autoconf and its config.h. Projects end up defining things like > > HAVE_STDLIB_H twice which is not harmful at all but now causes an error > > if g++ is used. > > Redefinitions with the same replacement list are not an error. Ok but that still doesn't cover the general use of #define PACKAGE_NAME foobar etc. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
On Jan 13, 2008 5:10 PM, Ismail Dönmez <[EMAIL PROTECTED]> wrote: > Sunday 13 January 2008 18:03:20 tarihinde Andreas Schwab şunları yazmıştı: > > Ismail Dönmez <[EMAIL PROTECTED]> writes: > > > That was just an example, real life testcase shows that problem stems > > > from autoconf and its config.h. Projects end up defining things like > > > HAVE_STDLIB_H twice which is not harmful at all but now causes an error > > > if g++ is used. > > > > Redefinitions with the same replacement list are not an error. > > Ok but that still doesn't cover the general use of > > #define PACKAGE_NAME foobar > > etc. But that's just bugs that need to be fixed. Richard.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
Sunday 13 January 2008 18:10:00 tarihinde Richard Guenther şunları yazmıştı: > On Jan 13, 2008 5:10 PM, Ismail Dönmez <[EMAIL PROTECTED]> wrote: > > Sunday 13 January 2008 18:03:20 tarihinde Andreas Schwab şunları yazmıştı: > > > Ismail Dönmez <[EMAIL PROTECTED]> writes: > > > > That was just an example, real life testcase shows that problem stems > > > > from autoconf and its config.h. Projects end up defining things like > > > > HAVE_STDLIB_H twice which is not harmful at all but now causes an > > > > error if g++ is used. > > > > > > Redefinitions with the same replacement list are not an error. > > > > Ok but that still doesn't cover the general use of > > > > #define PACKAGE_NAME foobar > > > > etc. > > But that's just bugs that need to be fixed. I think we already agreed that this is just too many packages to fix and that this warning should only be an error with -pedantic. People already started adding #undef hacks to workaround this, others are building with -fpermissive. So we should should just let Manu finish up his patch and get a review as C++ FE maintainers agreed as well. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
On Sun, 13 Jan 2008, Ismail Dönmez wrote: | Sunday 13 January 2008 17:41:03 tarihinde Gabriel Dos Reis sunlar? yazm?st?: | > Ismail Dönmez <[EMAIL PROTECTED]> writes: | > | Hi again, | > | | > | Wednesday 09 January 2008 00:28:54 tarihinde Manuel López-Ibáñez sunlar? | > | | > | yazm?st?: | > | > For your particular example, you could open a regression bug against | > | > 4.3 that says: | > | > * '"foo' redefined" is not mandated by the standard or it is not | > | > serious enough, so it should not be a pedwarn just a normal warning; | > | > or | > | | > | Looks like this is actually mandated by standard :-( , thats what I am | > | told on #gcc anyway :) | > | > #define foo bar | > #define foo baz | > | > is asking for trouble -- one should look for fixing the source of that | > inconsistency. | | That was just an example, I understood that. | real life testcase shows that problem stems from | autoconf and its config.h. Projects end up defining things like HAVE_STDLIB_H | twice which is not harmful at all but now causes an error if g++ is used. The problem is that any semantics of the above -- that is not an error or silent ignorance -- is order-dependent, which is worse to debug. -- Gaby
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
Sunday 13 January 2008 18:40:25 tarihinde Gabriel Dos Reis şunları yazmıştı: > | real life testcase shows that problem stems from > | autoconf and its config.h. Projects end up defining things like > | HAVE_STDLIB_H twice which is not harmful at all but now causes an error > | if g++ is used. > > The problem is that any semantics of the above -- that is not an error > or silent ignorance -- is order-dependent, which is worse to debug. True but lots of real world applications are falling apart, is it worth to break them all anyway? Also with -pedantic you will still get an error. I think its a good compromise. Regards, ismail -- Never learn by your mistakes, if you do you may never dare to try again.
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
On Sun, 13 Jan 2008, Ismail Dönmez wrote: | Sunday 13 January 2008 18:40:25 tarihinde Gabriel Dos Reis sunlar? yazm?st?: | > | real life testcase shows that problem stems from | > | autoconf and its config.h. Projects end up defining things like | > | HAVE_STDLIB_H twice which is not harmful at all but now causes an error | > | if g++ is used. | > | > The problem is that any semantics of the above -- that is not an error | > or silent ignorance -- is order-dependent, which is worse to debug. | | True but lots of real world applications are falling apart, I believe it has been reported the numbre of those (reported in an earlier message) is an overstatement. -- Gaby
jc1 out of memory error gcc 4.2.2 Linux 64-bit OS
Hello all, I downloaded and built gcc 4.2.2 on my linux box. I have also used the sources to build a cross compiler using Ranjit's Matthews guide. The build went just fine. I tried to compile my java application and got the following error: c1: out of memory allocating 4064 bytes after a total of 3909824512 bytes The specs on my laptop are as follows: Intel Core 2 Duo Suse 10.2 64-bit Linux 2.6.18.2-34-default #1 SMP Mon Nov 27 11:46:27 UTC 2006 x86_64 x86_64 x86_64 GNU/Linux 4 GB Ram jc1 spiked from 1 gig of memory to close to 4gb, eats up the swap and then finally crashes. Is there any additional information you guys would like me to provide? If so please feel free to let me know and I gladly will. Thanks in advance! -- Harpal Grover President Harpal Grover Consulting Inc
Re: Is it possible to import a gimple file into gcc so to generate the target code?
> Suppose we dump the GIMPLE tree into a file by using gcc option. Is it > possible to import the GIMPLE file into the gcc and generate the target > code? No, but you might want to take a look at the plugin project: http://gcc.gnu.org/wiki/GCC_Plugins Ben
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
On 13/01/2008, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> On 12/01/2008, Jonathan Wakely <[EMAIL PROTECTED]> wrote:
> > On 12/01/2008, Manuel López-Ibáñez <[EMAIL PROTECTED]> wrote:
> > >
> > > Here is an initial patch implementing some of your proposals. I used
> > > pederror as the name of the function. That is, it is an error unless
> > > fpermissive is given.
> >
> > These errors should be independent of -pedantic* unless the if
> > (pedantic) check is also present in the code, but that's a special
> > case. Have I understood the intention correctly?
>
> Actually, I didn't understand that we wanted to separate fpermissive
> and pedantic-errors completely. (Notice that the internal
> declaration/definition of fpermissive actually mentions pedantic.) But
> I agree with you: they should be unrelated.
I hadn't noticed that in the flag_permissive declaration, thanks for
pointing it out. I think that comment should be changed to refer to
permerrors instead. (I'm not sure about the bit about being ignored
if -pedantic is given ... is that true today?
To summarise, the proposal is
Introduce a new class of diagnostic, permerror, which is an error by
default, but -fpermissive makes it a warning.
Change most C++ FE pedwarns to permerrors
Stop using pedantic-errors by default for the C++ FE and CPP
Since most pedwarns are now permerrors, we still get errors by
default, or warnings with -fpermissive. However, now CPP doesn't have
to use pedantic-errors to align with the C++ FE, so the class of CPP
diagnostics that are causing problems will remain as warnings, as per
GCC 4.2
If you want errors from the preprocessor you can use
-fpedantic-errors, consistent with C.
I think this results in consistent behaviour for the front-end and
preprocessor for both C and C++ (which is the behaviour documented in
the manual.) Most diagnostics will behave equivalently but there are
a few special cases where the C pedwarn semantics are preferable, so
shouldn't be switched to permerrors (most of these cases are only
enabled by -pedantic and give no diagnostic without)
> Your information above was very helpful. But I am still not sure about
> the rest of pedwarns.
for decl.c I'm not so sure which category some of them should be in.
I'll list the ones I think should stay as pedwarns, everything else
should be a permerror (IMHO)
line 3811 check_tag_decl
if (TREE_CODE (declared_type) != UNION_TYPE && pedantic
&& !in_system_header)
pedwarn ("ISO C++ prohibits anonymous structs");
guarded by pedantic, looks like it's allowed as an extension, so leave
as a pedwarn.
This won't change the default behaviour but now when -pedantic is
given this will only be a warning
line 6922 check_static_variable_definition
else if (pedantic && !INTEGRAL_TYPE_P (type))
pedwarn ("ISO C++ forbids initialization of member constant "
"%qD of non-integral type %qT", decl, type);
Extension, guarded by pedantic, leave it as pedwarn
line 7007 compute_array_index_type
/* As an extension we allow zero-sized arrays. We always allow
them in system headers because glibc uses them. */
else if (integer_zerop (size) && pedantic && !in_system_header)
{
if (name)
pedwarn ("ISO C++ forbids zero-size array %qD", name);
else
pedwarn ("ISO C++ forbids zero-size array");
guarded by pedantic, leave as pedwarn
line 7025 compute_array_index_type
else if (pedantic && warn_vla != 0)
{
if (name)
pedwarn ("ISO C++ forbids variable length array %qD", name);
else
pedwarn ("ISO C++ forbids variable length array");
}
GNU extension, guarded by pedantic, leave as pedwarn
7655 grokdeclarator
else if (pedantic || ! is_main)
pedwarn ("ISO C++ forbids declaration of %qs with no type", name);
else
warning (OPT_Wreturn_type,
"ISO C++ forbids declaration of %qs with no type", name);
interesting one, the comment above says:
/* We handle `main' specially here, because 'main () { }' is so
common. With no options, it is allowed. With -Wreturn-type,
it is a warning. It is only an error with -pedantic-errors. */
That's true, but currently pedantic-errors is on by default.
I think this should become:
else if (! is_main)
permerror ("ISO C++ forbids declaration of %qs with no type", name);
else if (pedantic)
pedwarn ("ISO C++ forbids declaration of %qs with no type", name);
else
warning (OPT_Wreturn_type,
"ISO C++ forbids declaration of %qs with no type", name);
That would make it an error anywhere except main, but in main it's a
warning with -pedantic or -Wreturn-type. -pedantic-errors or -Werror
make it an error on main too.
7703 grokdeclarator
pedwarn ("long, short, signed or unsigned used invalidly for %qs",
name);
guarded by pedantic, leave as pedwarn
7808 grokdeclarator
/* This was an error in C++98 (cv-qualifiers cannot be add
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
On 13/01/2008, Ismail Dönmez <[EMAIL PROTECTED]> wrote: > > So we should should just let Manu finish up his patch and get a review as C++ > FE maintainers agreed as well. > Patch sent for approval: http://gcc.gnu.org/ml/gcc-patches/2008-01/msg00583.html Extra testing is welcome in case I missed something. In particular, any reference to flag_pedantic_errors after a permerror is a potential bug. Also, suggestions of pedwarns that should actually be permerrors would be helpful. Cheers, Manuel.
dynamic attribute
Hello I want a new attribute in my port. This has to be dynamic like the aligned attribute. So I registered a new handler in the attribute table and was able to get the value inside the handler. But how can I use this value in prologue or epilogue. All tries to append this value to the function declaration failed. Is there a better example than the aligned attribute which can show me a solution? I want to give the opportunity to overwrite the automatic register save and restore mechanism during entry and exit. So I have to read a mask out of the code, Thanks Michael Fogel
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
On 13/01/2008, Jonathan Wakely wrote:
>
> I think all others should change to permerrors.
I only meant all others in cp/decl.c of course - here are the remaining files.
Again I've only listed the ones that should remain as pedwarns and
other special cases - most change to permerrors.
In cp/error.c we have
/* Warn about the use of variadic templates when appropriate. */
void
maybe_warn_variadic_templates (void)
{
if ((cxx_dialect == cxx98) && !in_system_header)
/* We really want to suppress this warning in system headers,
because libstdc++ uses variadic templates even when we aren't
in C++0x mode. */
pedwarn ("ISO C++ does not include variadic templates");
}
Another interesting one. Variadic templates work in C++98 mode and
are used internally, but currently you have to say -fpermissive to use
them in user code. That flag is *usually* needed for
backward-compatibility, not enabling *future* extensions.
If this becomes a permerror that behaviour will be preserved, if it
stays as a pedwarn then users will only get a warning for
variadic-templates in C++98.
So is support for variadic templates in -std=gnu98 mode an official
extension, or a detail not-for-public-consumption?
the pedwarns in except.c, friend.c and init.c should be permerrors
at name-lookup.c:728 we have:
if (pedantic && ! DECL_IN_SYSTEM_HEADER (x))
pedwarn ("redeclaration of % as %qT",
TREE_TYPE (x));
guarded by pedantic, so leave as pedwarn
and later at line 1177
pedwarn ("name lookup of %qD changed for new ISO % scoping",
DECL_NAME (decl));
pedwarn (" using obsolete binding at %q+D", decl);
This is currently inaccurate, it says "using obsolete binding" but
because pedantic-errors is on it doesn't use it - you get a fatal
error.
Leaving this as a pedwarn would make the diagnostic accurate, but
personally I think it's right that this is a fatal error, so it should
change to permerror and the second line should be changed to
"(if you use -fpermissive G++ will accept your code)"
as used in lex.c and parser.c
The others in cp/name-lookup.c should be pedwarns.
In cp/parser.c your patch already changes one pedwarn. I think all
others should change unless guarded by if (pedantic), as this allow
GNU extensions like long long.
There are a couple of exceptions...
There's this oddity on line 13685
if (!parser->default_arg_ok_p)
{
if (!flag_pedantic_errors)
warning (0, "deprecated use of default argument for parameter of
non-function");
else
{
error ("default arguments are only permitted for function
parameters");
default_argument = NULL_TREE;
}
}
I think for consistency with the new proposed behaviour it should
check flag_permissive, instead of !flag_pedantic_errors, do you agree?
on line 14511:
if (scope == nested_name_specifier)
{
pedwarn ("extra qualification ignored");
nested_name_specifier = NULL_TREE;
num_templates = 0;
}
how confusing - a fatal error that says the problem was ignored :-)
I think this should be a permerror, but maybe the text should say
"extra qualification not allowed"
The other pedwarns in cp/parser.c that are not guarded by pedantic
should be permerrors.
In cp/pt.c all pedwarns except these should be permerrors:
line 14284
if (pedantic && !in_system_header)
pedwarn ("ISO C++ forbids the use of % on explicit "
"instantiations");
This is a GNU extension, leave as pedwarn
line 14370
if (pedantic && !in_system_header)
pedwarn("ISO C++ forbids the use of %qE on explicit instantiations",
storage);
GNU extension, leave as pedwarn
The others in cp/pt.c should be permerrors.
The pedwarn in cp/semantics.c should be a permerror
In cp/typeck2.c I think cxx_incomplete_type_diagnostic should continue
to use pedwarn on line 347, but line 697 should be a permerror.
In cp/typeck.c the pedwarns guarded by pedantic should stay as pedwarns.
on line 5356 there is:
if (pedantic)
/* Only issue a warning, as we have always supported this
where possible, and it is necessary in some cases. DR 195
addresses this issue, but as of 2004/10/26 is still in
drafting. */
warning (0, "ISO C++ forbids casting between pointer-to-function and
pointer-to-object");
This could switch to a pedwarn, since that will still be a warning
under the permerror proposal. That would mean it can be turned into a
fatal error with -pedantic-errors instead of -Werror, which would be
consistent with other warnings that are only enabled by -pedantic.
I'm not sure how "conditionally-supported behaviour" should interact
with -pedantic-errors so let's leave as a warning for now.
The others (including the one in build_x_compound_expr_from_list)
should change to permerrors
Is that all
Re: Changes in C++ FE regarding pedwarns to be errors are harmful
On 14/01/2008, Jonathan Wakely <[EMAIL PROTECTED]> wrote: > On 13/01/2008, Jonathan Wakely wrote: > > > > I think all others should change to permerrors. > > I only meant all others in cp/decl.c of course - here are the remaining files. > Again I've only listed the ones that should remain as pedwarns and > other special cases - most change to permerrors. > Thanks for doing this! > Another interesting one. Variadic templates work in C++98 mode and > are used internally, but currently you have to say -fpermissive to use > them in user code. That flag is *usually* needed for > backward-compatibility, not enabling *future* extensions. That is because we didn't have permerror and the semantics of fpermissive were not clear. Now it is evident that this should be a pedwarn. Wow, you found probably the best example of why the current C++ FE behaviour is confusing. > So is support for variadic templates in -std=gnu98 mode an official > extension, or a detail not-for-public-consumption? Well, right now you can use it if you use fpermissive, so if it wasn't for public-consumption, using pedwarn instead of error was not the right thing in the first place. So pedwarn. > I think for consistency with the new proposed behaviour it should > check flag_permissive, instead of !flag_pedantic_errors, do you agree? > Yes, this is the type of thing I am looking when reviewing your suggestions, since they are a potential source of bugs. In my patch I changed a few. > In cp/typeck.c the pedwarns guarded by pedantic should stay as pedwarns. > on line 5356 there is: > if (pedantic) > /* Only issue a warning, as we have always supported this >where possible, and it is necessary in some cases. DR 195 >addresses this issue, but as of 2004/10/26 is still in >drafting. */ > warning (0, "ISO C++ forbids casting between pointer-to-function and > pointer-to-object"); > > This could switch to a pedwarn, since that will still be a warning > under the permerror proposal. That would mean it can be turned into a > fatal error with -pedantic-errors instead of -Werror, which would be > consistent with other warnings that are only enabled by -pedantic. > I'm not sure how "conditionally-supported behaviour" should interact > with -pedantic-errors so let's leave as a warning for now. This is another example of trying to workaround the wrong default of pedwarns. This should be a pedwarn. The reason why is a warning is that pedantic-errors was active by default and that didn't make sense. We are changing this, so we don't need this hack anymore. > Is that all of them? Would you prefer a patch to make the changes or > are you going to go through them yourself anyway? I agree with all your other suggestions. I will try to go through them in the following days and submit a follow-up patch to the ones already submitted. Many thanks! That was impressive. Manuel.
Listing of radiologists and 34 more specialties
Current Physicians in the United States
788,263 in total <> 17,446 emails
34 primary and secondary specialties
Sort by over a dozen different fields
Dramatic cost reduction: $390
~ Get These Fr EE with every order this week ~
American Pharmaceutical Company Database
47,000 personal emails and names of decision makers
Directory of US Hospitals
23,000 Admins in more than 7,000 hospitals {a $399 value]
Database of American Dentists
A complete Directory or dentists and related services (valued at $399)
Directory of US Chiropractors
100,000 Chiropractors in the USA (worth $250 alone)
send us an email: [EMAIL PROTECTED]
good until Jan 18
By sending an email with 048 in the subject you will have your email revoked
Re: Idea to refine -Wtype-limits
On 26/11/2007, Gabriel Dos Reis <[EMAIL PROTECTED]> wrote: > > Template are tricky. During phase one, we usually do as much of > semantics analysis as we can, e.g. non dependent things get checked. > In phase two, we check only things that were dependent. So, if the > enclosing function is generated from a template (and there is a way to > know that), then we are checking something that was dependent in the > first place. > Oh Gabriel, I missed this mail completely. Do you know what is the way to check that? Cheers, Manuel.
