Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

[Joseph Myers]

On Mon, 28 Mar 2016, Martin Sebor wrote:

> The general rule of thumb documented in the manual is that more
> specific options take precedence over more general ones, regardless
> of where they appear on the command line:
> 
>   The combined effect of positive and negative forms [of warning
>   options] is that more specific options have priority over less
>   specific ones, independently of their position in the command-
>   line.

As a matter of compatibility, I think it's best to keep existing semantics 
for -w, and document them more precisely, rather than change -w to act 
like a less-specific option "for each warning, disable that warning's 
option implicitly".

Note that there is another ambiguity in the general rule about more 
specific options overriding less specific options when it relates to 
-Werror= / -Wno-error= options.  An idealized form of that rule (not 
actually implemented) is described in appendix 1 in 
.  Now consider 
-Wgeneral implying -Wspecific, and look at the interaction between 
-Wno-general and -Werror=specific.

If we consider that -Wno-general implies -Wno-specific and 
-Werror=specific implies -Wspecific, at equal levels of indirection, then 
the order of the options on the command line is what determines whether 
-Wspecific is enabled (as an error).  If however we consider -Wspecific to 
be a tristate (disabled, warning, error), then -Werror=specific is a 
direct setting of the tristate while -Wno-general is only indirect, so 
-Werror=specific takes precedence whatever the command-line order.

I make no assertion here regarding what the semantics are currently (not 
necessarily consistent), or should ideally be, for this case.

-- 
Joseph S. Myers
jos...@codesourcery.com

gcc-5-20160329 is now available

[gccadmin]

Snapshot gcc-5-20160329 is now available on
  ftp://gcc.gnu.org/pub/gcc/snapshots/5-20160329/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.

This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5-branch 
revision 234538

You'll find:

 gcc-5-20160329.tar.bz2   Complete GCC

  MD5=ab62024dc5cf4e7abd217af075944586
  SHA1=703625c11434b937e687376e6743b782dff9d7b4

Diffs from 5-20160322 are available in the diffs/ subdirectory.

When a particular snapshot is ready for public consumption the LATEST-5
link is updated and a message is sent to the gcc list.  Please do not use
a snapshot before it has been announced that way.

Re: Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

[kevin-tucker]

I apologize for stating that you had reported the issue.  I copy/pasted from 
your comment rather than the original report.
The issue was reported by Teodor Petrov 

Kevin

 "Manuel López-Ibáñez"  wrote: 
> > On 03/28/2016 01:56 PM, Florian Weimer wrote:
> >>> In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though
> >>> he provides the "-Werror=return-type" option, the compiler doesn't
> >>> flag the warning/error about a control reaching the end of a non-void
> >>> function, due to the presence of the "-w" option.  He points out that
> >>> clang++ wtill flags the promoted warning even though warnings are
> >>> inhibited.
> 
> I did not report the bug and did not mention anything of the above. I only 
> commented on why GCC works like it works and how one can change the behaviour 
> if so desired. I don't care one way or the other and I can see benefits for 
> either behaviour.
> 
> >> I think -w is ordered with respect to the other warning obtions, and
> >> -w inhibits previously requested warnings, and future -W flags may
> >> enable other warnings.  With this in mind, I agree that the current
> >> GCC behavior is consistent and probably not a bug.
> 
> The command-line order does not affect '-w' and there is no way to undo '-w'. 
> It is a global boolean switch independent of anything else (including 
> pragmas) 
> that disables warnings just before they are re-classified (by pragmas or 
> -Werror=) into something else. This means that if -Wfoobar is given in the 
> command-line (or enabled by a pragma) and it requires an expensive analysis, 
> this analysis is done even in the presence of -w, only the warning message is 
> not emitted.
> 
> One question to answer if the behaviour does change is what would be the 
> effect 
> of using '-w' on warning options enabled by #pragmas. Some people may still 
> want a switch that simply disables all warnings no matter how they are 
> enabled.
> 
> Cheers,
> 
>   Manuel.

Re: Re: Should a disabled warning be allowed to be promoted to an error(Bugzilla PR 70275)?

[Manuel López-Ibáñez]

On 03/28/2016 01:56 PM, Florian Weimer wrote:

In Bugzilla PR # 70275, Manuel López-Ibáñez reports that even though
he provides the "-Werror=return-type" option, the compiler doesn't
flag the warning/error about a control reaching the end of a non-void
function, due to the presence of the "-w" option.  He points out that
clang++ wtill flags the promoted warning even though warnings are
inhibited.


I did not report the bug and did not mention anything of the above. I only 
commented on why GCC works like it works and how one can change the behaviour 
if so desired. I don't care one way or the other and I can see benefits for 
either behaviour.



I think -w is ordered with respect to the other warning obtions, and
-w inhibits previously requested warnings, and future -W flags may
enable other warnings.  With this in mind, I agree that the current
GCC behavior is consistent and probably not a bug.


The command-line order does not affect '-w' and there is no way to undo '-w'. 
It is a global boolean switch independent of anything else (including pragmas) 
that disables warnings just before they are re-classified (by pragmas or 
-Werror=) into something else. This means that if -Wfoobar is given in the 
command-line (or enabled by a pragma) and it requires an expensive analysis, 
this analysis is done even in the presence of -w, only the warning message is 
not emitted.


One question to answer if the behaviour does change is what would be the effect 
of using '-w' on warning options enabled by #pragmas. Some people may still 
want a switch that simply disables all warnings no matter how they are enabled.


Cheers,

Manuel.

Re: regression in C++ parsing performance between 4.9.3 and 5.3.1

[Jonathan Wakely]

> There is a significant slow down and increase in ram usage

Please report it to Bugzilla rather than this list, thanks.

Re: Listing a maintainer for libcilkrts, and GCC's Cilk Plus implementation generally?

[Thomas Schwinge]

Hi!

Just to remind: it had been announced in
,
but more than a year later, this has still not been resolved.  No merge
of libcilkrts has been done from the upstream Intel sources into GCC
trunk (to bring in my GNU Hurd portability patches, for example).  I
understand that a GNU Hurd port is not of great importance, but here it
seems the whole process of the Intel upstream/shared source repository is
broken.


Also, still nobody is listed in the GCC MAINTAINERS file as being
responsible for Cilk Plus in GCC, which for more than a year, a proposal
for has been pending/waiting for GCC Steering Committee approval,
.


Grüße
 Thomas


On Fri, 06 Mar 2015 10:13:11 -0700, Jeff Law  wrote:
> On 03/05/15 17:41, Thomas Schwinge wrote:
> > On Thu, 5 Mar 2015 13:39:44 -0700, Jeff Law  wrote:
> >> On 02/23/15 14:41, H.J. Lu wrote:
> >>> On Mon, Sep 29, 2014 at 4:00 AM, Jakub Jelinek  wrote:
>  On Mon, Sep 29, 2014 at 12:56:06PM +0200, Thomas Schwinge wrote:
> > On Tue, 23 Sep 2014 11:02:30 +, "Zamyatin, Igor" 
> >  wrote:
> >> Jeff Law wrote:
> >>> The original plan was for Balaji to take on this role; however, his 
> >>> assignment
> >>> within Intel has changed and thus he's not going to have time to work 
> >>> on
> >>> Cilk+ anymore.
> >>>
> >>> Igor Zamyatin has been doing a fair amount of Cilk+ 
> >>> maintenance/bugfixing
> >>> and it might make sense for him to own it in the long term if he's 
> >>> interested.
> >>
> >> That's right.
> >
> > Thanks!
> >
> >> Can I add 2 records (cilk plus and libcilkrts) to Various Maintainers 
> >> section?
> >
> > I understand Jeff's email as a pre-approval of such a patch.
> 
>  I think only SC can appoint maintainers, and while Jeff is in the SC,
>  my reading of that mail wasn't that it was the SC that has acked that, 
>  but
>  rather a question if Igor is willing to take that role, which then would
>  need to be acked by SC.
> >>>
> >>> Where are we on this?  Do we have a maintainer for Cilk Plus
> >>> and its run-time library?
> >> Not at this time.  There was a bit of blockage on various things with
> >> the steering committee (who approves maintainers).  I've got a
> >> half-dozen or so proposals queued (including Cilk maintainership).
> >
> > What's the process then, that I get my Cilk Plus (libcilkrts) portability
> > patches committed to GCC?  I was advisd this must be routed through Intel
> > (Barry M Tannenbaum CCed), which I have done months ago: I submitted the
> > patches to Intel, and -- as I understood it -- Barry and I seemed to
> > agree about them (at least I don't remember any requests for changes to
> > be made on my side), but I have not seen a merge from Intel to update
> > GCC's libcilkrts.  Should I now commit to GCC the pending patches,
> > 
> > and following?
> For the runtime, the canonical bits are the upstream Cilk Plus project. 
>   So any changes for the runtime go there first.  The comments WRT Cilk+ 
> maintainers were more for the bits in GCC itself (ie, front-end 
> extensions and related stuff up to gomp lowering/expansion.
> 
> There's the possibility of an update of the Cilk Plus runtime for gcc-5. 
>   Igor is going to summarize the situation for the release managers to 
> review and ultimately make a decision.
> 
> Jeff


signature.asc
Description: PGP signature