Re: FW: Git repo lagging behing

[Marek Polacek]

On Tue, Feb 04, 2014 at 03:59:45PM +, Paulo Matos wrote:
> Don't know if anybody noticed but something's wrong with the git repo. It's 
> lagging behind. Last commit there was:
> 18 hours ago  tejohnson   2014-02-03 Teresa Johnson 
> 
> which was certainly not the last commit on trunk.

I believe one of the overseers I don't want to name (hi Frank) will
have a look at this.

Marek

Re: 4.8.3?

[Marek Polacek]

On Thu, Apr 03, 2014 at 04:34:00PM -0300, Daniel Gutson wrote:
>   is there any plan to release a gcc 4.8.3?

Yes.

Marek

Re: [PATCH] tell gcc optimizer to never introduce new data races

[Marek Polacek]

On Tue, Jun 10, 2014 at 04:53:27PM +0200, Peter Zijlstra wrote:
> On Tue, Jun 10, 2014 at 03:23:36PM +0200, Jiri Kosina wrote:
> > +# Tell gcc to never replace conditional load with a non-conditional one
> > +KBUILD_CFLAGS  += $(call cc-option,--param allow-store-data-races=0)
> > +
> 
> Why do we not want: -fmemory-model=safe? And should we not at the very
> least also disable packed-store-data-races?

Note that the option does not exist, even though it is mentioned in the
documentation.

Marek

Re: Got this one back (too large: 6.4 Mb) from gcc-results:

[Marek Polacek]

On Thu, Jul 03, 2014 at 07:06:29PM +0200, Toon Moene wrote:
> Compiler version: 4.10.0 20140702 (experimental) (GCC)
> Platform: x86_64-unknown-linux-gnu
> configure flags: --prefix=/home/toon/compilers/install --with-gnu-as
> --with-gnu-ld --with-build-config=bootstrap-ubsan --enable-languages=all
> --disable-multilib --disable-nls --with-arch=core-avx2 --with-tune=core-avx2
> 
> Note: --with-build-config=bootstrap-ubsan
> 
> Apparently, the bugs went wild ...

I suspect that's because:
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01549.html
which will go away if/when we fix:
https://gcc.gnu.org/ml/gcc-patches/2014-06/msg01624.html

But I'm only guessing.

Marek

Re: GCC version bikeshedding

[Marek Polacek]

On Sun, Jul 20, 2014 at 07:01:46PM +0200, Jakub Jelinek wrote:
> Ian/Jason, is that your understanding too?  In any case, we should mention
> it on gcc.gnu.org/index.html, in develop.html and perhaps a few other spots.

Also it'd be nice to create htdocs/gcc-5.0/changes.html, so we can
start adding new features there.  Gerald?

Marek

Re: C as intermediate language, signed integer overflow and -ftrapv

[Marek Polacek]

On Wed, Jul 23, 2014 at 04:56:06PM +0200, Thomas Mertes wrote:
> A sanitizer such as ubsan is good as tool to find errors in C
> programs. But I don't think that ubsan is well suited to do overflow
> detection with maximum performance. Is just not the goal of this
> tool.

That's true.  But if you only use
-fsanitize=signed-integer-overflow, then the overhead shouldn't be
that bad, especially on x86_64 where we try to make use of jo (jump if
overflow) instruction.  Perhaps use that option together with
-fsanitize-undefined-trap-on-error, so it doesn't call libubsan
routines at all.

Marek

Re: GCC version bikeshedding

[Marek Polacek]

On Wed, Aug 06, 2014 at 09:42:23AM +0200, Jakub Jelinek wrote:
> On Wed, Aug 06, 2014 at 09:25:48AM +0200, Eric Botcazou wrote:
> > > What do you propose that we do?
> > 
> > Probably just jump to 5.0 (or 5.1) without the subsequent acceleration.
> 
> That was my preference too.

FWIW, me too.  This way we'll get in a few years to 10.0 that was also 
suggested.
So please, can we finally settle on something? :)

Marek

Re: GCC version bikeshedding

[Marek Polacek]

On Wed, Aug 06, 2014 at 11:04:14AM +0200, Richard Biener wrote:
> On Wed, Aug 6, 2014 at 10:48 AM, Jakub Jelinek  wrote:
> > - libstdc++ ABI changes (it is a significant user visible change,
> >   if you rebuild everything, no extra effort is needed, but otherwise
> >   if you want some C++ code built with older compilers work together
> >   with code built with newer compilers, it might require source code
> >   changes (the abi_tag attribute additions where needed and warning
> >   suggest to put those at), at least that is my current understanding
> >   of the plans
> 
> But that's only with -std=c++11?  Which had no compatibility
> guarantees before?
> 
> > - likely libgfortran ABI changes (different array descriptors)
> 
> Let's wait and see ...
> 
> We'll find a good reason to bump the major with every release.
> Like for 4.9 LTO defaults to slim-objects, or C++ rejecting even more
> invalid code, or libstdc++ header re-orgs, or defaulting to dwarf4+
> (or even support for it), or VTA, or ...
> 
> Where do we set the barrier?  GCC isn't a C++ (or Fortran) compiler
> only.
> 
> So if we change to 5.1 (please not .0) then let's switch the default
> optimization level to -O2!  _That's_ a user-visible change across
> the board.

I'm planning to move the default C standard from gnu90 to gnu11
(Currently it's blocked on the -Wc90-c99-compat warning).
That's a pretty big user-visible change as well, I suppose.

Marek

Re: Turning a single warning into an error in dejagnu test

[Marek Polacek]

On Wed, Aug 27, 2014 at 10:59:40AM +0100, Dominik Vogt wrote:
> I'm writing a dejagnu test and encounter this warning at one place:
> 
>   warning: passing argument 1 of '...' makes integer from pointer
>   without a cast [enabled by default]
> 
> Now, I have a "{ dg-error ... }" comment in that line.  The line
> is generated from a script among hundreds of others that are all
> expected to produce errors, not warnings.  It would be very
> inconvenient (= lots of work) to change the script to make an
> exception just for that single line (because there's no easy way
> to identify lines that produce the warning instead of an error).
> 
> So the question is:  Is it possible to turn only this one warning
> into an error inside a dejagnu test?  As I understand it, there
> are no -W... switches for "enabled by default" options, and I
> cannot use -Werror because that would break other tests in the
> file.

For C, I recently added the -Wint-conversion option, so with recent
enough GCC you should be able to use -Werror=int-conversion.

Marek

Re: GCC 4.9 internal compiler error

[Marek Polacek]

On Mon, Sep 29, 2014 at 11:43:47AM +0400, Игорь Пашев wrote:
> Hi all!
> 
> It was found that OA fails to build with GCC 4.9 on amd64 [1]
> I can confirm this with r3094 on bare metal too.
> 
> # gcc --version
> gcc-4.9.real (Debian 4.9.1-14) 4.9.1
> Copyright (C) 2014 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> I can imaging that this is a bug in OpenAxiom, but GCC should not crash.
> 
> GCC complains on this line
> https://sourceforge.net/p/open-axiom/code/HEAD/tree/trunk/src/include/storage.H#l273

Please provide a preprocessed source and file a bug.
https://gcc.gnu.org/bugs/

Marek

Towards GNU11

[Marek Polacek]

Hi!

I'd like to kick off a discussion about moving the default standard
for C from gnu89 to gnu11.

This really shouldn't be much of a surprise: the docs mention that
gnu11 is intended future default for a year now.  I would presume now
is a good time to make this move: together with the new naming scheme
this should make GCC more modern (C89 really is as old as the hills).
And we're still in stage1.

Prerequisites should be largely complete at this point:
- we have -Wc90-c99-compat option that warns about features not present
  in ISO C90, but present in ISO C99,
- we have -Wc99-c11-compat option that warns about features not present
  in ISO C99, but present in ISO C11,
- the testsuite has been adjusted so all the test that pass with gnu89
  default should pass with gnu11 default as well (see my recent batch
  of cleanup patches).  This unfortunately isn't correct for all archs,
  I just don't have enough resources to test everything.  But generally
  the fallout from moving to gnu11 is easy to fix: just add proper decls
  and return types (to fix defaulting to int), or for inline stuff use
  -fgnu89-inline/gnu_inline attribute.  I'd appreciate testing on other
  architectures than x86_64/ppc64.

The things I had to fix in the testsuite nicely reflect what we can expect
in the real life: mostly bunch of new warnings about missing declarations
and defaulting to int (this is probably going to be a pain with -Werror,
but I feel that people really should write proper declarations), different
inline semantics (in C99 semantics, the TU has to have the body of the inline
function etc.), new "return with no value, in function returning non-void"
warnings.  Different rules for constant expressions, the fact that in C90
non-lvalue arrays do not decay to pointers, slightly different rules for
compatible types (?) might come in game as well.

In turn, you can use all C99 and C11 features even with -pedantic.

Comments?

Regtested/bootstrapped on powerpc64-linux and x86_64-linux.

2014-10-07  Marek Polacek  

* doc/invoke.texi: Update to reflect that GNU11 is the default
mode for C.
* c-common.h (c_language_kind): Update comment.
c-family/
* c-opts.c (c_common_init_options): Make -std=gnu11 the default for C.

diff --git gcc/c-family/c-common.h gcc/c-family/c-common.h
index 1e3477f..a895084 100644
--- gcc/c-family/c-common.h
+++ gcc/c-family/c-common.h
@@ -445,7 +445,7 @@ struct GTY(()) sorted_fields_type {
 
 typedef enum c_language_kind
 {
-  clk_c= 0,/* C90, C94 or C99 */
+  clk_c= 0,/* C90, C94, C99 or C11 */
   clk_objc = 1,/* clk_c with ObjC features.  */
   clk_cxx  = 2,/* ANSI/ISO C++ */
   clk_objcxx   = 3 /* clk_cxx with ObjC features.  */
diff --git gcc/c-family/c-opts.c gcc/c-family/c-opts.c
index 3f295d8..eb078e3 100644
--- gcc/c-family/c-opts.c
+++ gcc/c-family/c-opts.c
@@ -250,6 +250,9 @@ c_common_init_options (unsigned int decoded_options_count,
 
   if (c_language == clk_c)
 {
+  /* The default for C is gnu11.  */
+  set_std_c11 (false /* ISO */);
+
   /* If preprocessing assembly language, accept any of the C-family
 front end options since the driver may pass them through.  */
   for (i = 1; i < decoded_options_count; i++)
diff --git gcc/doc/invoke.texi gcc/doc/invoke.texi
index 5fe7e15..fa84ed4 100644
--- gcc/doc/invoke.texi
+++ gcc/doc/invoke.texi
@@ -1692,8 +1692,7 @@ interfaces) and L (Analyzability).  The name @samp{c1x} 
is deprecated.
 
 @item gnu90
 @itemx gnu89
-GNU dialect of ISO C90 (including some C99 features). This
-is the default for C code.
+GNU dialect of ISO C90 (including some C99 features).
 
 @item gnu99
 @itemx gnu9x
@@ -1701,8 +1700,8 @@ GNU dialect of ISO C99.  The name @samp{gnu9x} is 
deprecated.
 
 @item gnu11
 @itemx gnu1x
-GNU dialect of ISO C11.  This is intended to become the default in a
-future release of GCC.  The name @samp{gnu1x} is deprecated.
+GNU dialect of ISO C11.  This is the default for C code.
+The name @samp{gnu1x} is deprecated.
 
 @item c++98
 @itemx c++03

Marek

Re: Towards GNU11

[Marek Polacek]

On Wed, Oct 08, 2014 at 09:16:18AM +0200, Richard Biener wrote:
> I think it makes sense to do this (and I expect C++ will follow
> with defaulting to -std=c++11 once the ABI stuff has settled).

Thanks.  Moving to -std=c++11 would be cool!
 
> Of course it would be nice to look at the actual fallout in
> a whole-distribution rebuild...

Yeah, I'm worried about that.  Many packages are using -std=gnu99
(e.g. glibc, elfutils, maybe emacs) and these won't be affected at
all.  But e.g. gdb/binutils use the default standard I think.  I
wonder about Linux kernel.
And of course, C++ packages should be out of the picture here.

Marek

Re: Towards GNU11

[Marek Polacek]

On Wed, Oct 08, 2014 at 08:39:40PM -0600, Jeff Law wrote:
> I like it.  And one could reasonably argue that now is the time to change
> since that maximizes the time for folks to find broken code.

Yep, this is definitely stage1 stuff.  We still have a few weeks, but
I wouldn't want to rush such a change in the nick of time.

> I'd go so far as to conditionally approve -- if other maintainers don't
> shout out in the next week or so against, then I feel this should go
> forward.
 
Thanks.  I will wait at least until the end of next week.

I'd like to hear from Joseph ;).

> I know it's really early, but a "porting to ..." document ought to be
> started and have something in it about these changes.  Both how to fix the
> broken code or how to go back to c89.

Absolutely.  I'll start something up once it's in.  I feel that
especially the inline semantics change should be addressed therein.

Marek

Re: Towards GNU11

[Marek Polacek]

On Thu, Oct 09, 2014 at 02:34:51PM -0700, Mike Stump wrote:
> On Oct 7, 2014, at 2:07 PM, Marek Polacek  wrote:
> > I'd like to kick off a discussion about moving the default standard
> > for C from gnu89 to gnu11.
> 
> I endorse the change of default.
 
Thanks for chiming in.

> A wiki page that has the types of changes people hit in real code with how to 
> fix it, would be useful, helpful.  Might be nice to have this in the 
> document, but, don’t know if people want to do that much work.  The wiki site 
> is nice, as if others do world builds, then can add what ever they hit in 
> easily, which then makes that even more complete.  This is a nice to have, I 
> don’t think the work going in should be gated on this.
 
Yeah.  I plan to write something into the "porting to" document.

> Two comment:
> 
>   Thank you for all your hard work.
> 
>   Yes please.

Thank you very much!

Marek

Re: Towards GNU11

[Marek Polacek]

On Tue, Oct 07, 2014 at 11:07:56PM +0200, Marek Polacek wrote:
> I'd like to kick off a discussion about moving the default standard
> for C from gnu89 to gnu11.

The consensus seems to be to go forward with this change.  I will
commit the patch in 24 hours unless I hear objections.

Thanks,

Marek

Re: Towards GNU11

[Marek Polacek]

On Tue, Oct 14, 2014 at 09:23:29AM +0200, Marek Polacek wrote:
> The consensus seems to be to go forward with this change.  I will
> commit the patch in 24 hours unless I hear objections.

I made the change.  Please report any fallout to me.

Enjoy.

Marek

Re: Towards GNU11

[Marek Polacek]

On Wed, Oct 15, 2014 at 11:05:45PM +0200, Jakub Jelinek wrote:
> On Wed, Oct 15, 2014 at 09:28:09PM +0200, Uros Bizjak wrote:
> > i686-linux-gnu testsuite trivially regressed [1]:

Thanks for the log Uros.
 
> I have half of that already in patch form, will test and send either later
> tonight or tomorrow.

Please don't force yourself into doing that, it's more up to me to fix
my fallout ;).  Feel free to send me the partial patch and I will finish
it tomorrow mornings (reproducing is easy with --target_board=unix/-m32).
In any case, thanks.

Marek

Re: Towards GNU11

[Marek Polacek]

On Wed, Oct 15, 2014 at 09:28:09PM +0200, Uros Bizjak wrote:
> Hello!
> 
> >> The consensus seems to be to go forward with this change.  I will
> >> commit the patch in 24 hours unless I hear objections.
> >
> > I made the change.  Please report any fallout to me.
> 
> i686-linux-gnu testsuite trivially regressed [1]:
> 
> FAIL: gcc.dg/20020122-2.c (test for excess errors)
> FAIL: gcc.dg/builtin-apply4.c (test for excess errors)
> FAIL: gcc.dg/ia64-sync-1.c (test for excess errors)
> FAIL: gcc.dg/ia64-sync-2.c (test for excess errors)
> FAIL: gcc.dg/ia64-sync-3.c (test for excess errors)
> FAIL: gcc.dg/pr32176.c (test for excess errors)
> FAIL: gcc.dg/sync-2.c (test for excess errors)
> FAIL: gcc.dg/sync-3.c (test for excess errors)
> FAIL: gcc.target/i386/20060125-1.c (test for excess errors)
> FAIL: gcc.target/i386/20060125-2.c (test for excess errors)
> FAIL: gcc.target/i386/980312-1.c (test for excess errors)
> FAIL: gcc.target/i386/980313-1.c (test for excess errors)
> FAIL: gcc.target/i386/990524-1.c (test for excess errors)
> FAIL: gcc.target/i386/avx512f-pr57233.c (test for excess errors)
> FAIL: gcc.target/i386/avx512f-typecast-1.c (test for excess errors)
> FAIL: gcc.target/i386/builtin-apply-mmx.c (test for excess errors)
> FAIL: gcc.target/i386/crc32-2.c (test for excess errors)
> FAIL: gcc.target/i386/crc32-3.c (test for excess errors)
> FAIL: gcc.target/i386/intrinsics_3.c (test for excess errors)
> FAIL: gcc.target/i386/loop-1.c (test for excess errors)
> FAIL: gcc.target/i386/memcpy-1.c (test for excess errors)
> FAIL: gcc.target/i386/pr26826.c (test for excess errors)
> FAIL: gcc.target/i386/pr37184.c (test for excess errors)
> FAIL: gcc.target/i386/pr40934.c (test for excess errors)
> FAIL: gcc.target/i386/pr44948-2a.c (test for excess errors)
> FAIL: gcc.target/i386/pr47564.c (test for excess errors)
> FAIL: gcc.target/i386/pr50712.c (test for excess errors)
> FAIL: gcc.target/i386/sse-5.c (test for excess errors)
> FAIL: gcc.target/i386/stackalign/asm-1.c -mno-stackrealign (test for
> excess errors)
> FAIL: gcc.target/i386/stackalign/asm-1.c -mstackrealign (test for excess 
> errors)
> FAIL: gcc.target/i386/stackalign/return-2.c -mno-stackrealign (test
> for excess errors)
> FAIL: gcc.target/i386/stackalign/return-2.c -mstackrealign (test for
> excess errors)
> FAIL: gcc.target/i386/vectorize4.c (test for excess errors)

Sorry about these, should be fixed now.

Marek

Re: Contributing to GCC

[Marek Polacek]

On Fri, Oct 17, 2014 at 09:55:28AM +0200, Krzesimir Nowak wrote:
> I was asking, because, in the beginning at least, somebody will have
> to commit the patch to trunk for me. I don't know if svn understands
> git patches.

No worries about that, we'll just apply the patch manually.

Marek

Re: [RFC] Detect most integer overflows.

[Marek Polacek]

Hi,

On Tue, Apr 22, 2014 at 01:58:00PM +0200, Hannes Frederic Sowa wrote:
> I'll play around and will post a new patch in the not too distant
> future. ;)

Are you still planning on posting the revised patch?  Perhaps I could
take and finish the patch, but I don't think I can do that because you
don't have a copyright assignment with FSF.

Marek

Re: Enabling -fextended-identifiers by default

[Marek Polacek]

On Mon, Nov 03, 2014 at 04:24:21PM +, Joseph Myers wrote:
> I propose enabling -fextended-identifiers by default for the appropriate 
> standard versions (i.e. all C++ versions, C99 and above for C - so enabled 
> by default for C now the default C version is gnu11).  Any comments or 
> objections?

Sounds good to me.

Marek

Re: [gimple-classes, committed 4/6] tree-ssa-tail-merge.c: Use gassign

[Marek Polacek]

On Fri, Nov 07, 2014 at 10:01:45PM +0100, Richard Biener wrote:
> Just a comment as these patches flow by - I think this is a huge step
> backwards from "enforcing" s1/s2 being a gimple_assign inside
> gimple_assign_rhs1 to this as_a  boilerplate at _each_ callsite!

FWIW, I feel the same way.  More to type, worse readability, a lot
more of line-wrapping.

Sorry,

Marek

Re: [RFC] UBSan unsafely uses VRP

[Marek Polacek]

On Wed, Nov 12, 2014 at 11:42:39AM +0300, Yury Gribov wrote:
> On 11/11/2014 05:15 PM, Jakub Jelinek wrote:
> >>There are also some unsafe code in functions
> >>ubsan_expand_si_overflow_addsub_check, ubsan_expand_si_overflow_mul_check
> >>which uses get_range_info to reduce checks number. As seen before vrp usage
> >>for sanitizers may decrease quality of error detection.
> >
> >Using VRP is completely intentional there, we don't want to generate too
> >slow code if you decide you want to optimize your code (for -O0 VRP isn't
> >performed of course).
> 
> On the other hand detection quality is probably more important than
> important regardless of optimization level. When I use a checker, I don't
> want it to miss bugs due to overly aggressive optimization.
 
Yes, but as said above, VRP is only run with >-O2 and -Os.

> I wish we had some test to check that sanitizer optimizations are indeed
> conservative.

I think most of the tests we have are tested with various optimization
levels.

Marek

Re: [RFC] UBSan unsafely uses VRP

[Marek Polacek]

On Wed, Nov 12, 2014 at 01:04:58PM +0300, Marat Zakirov wrote:
> 
> On 11/12/2014 11:45 AM, Marek Polacek wrote:
> >Yes, but as said above, VRP is only run with >-O2 and -Os.
> You meant >= -O2?

Yes.

Marek

Re: ICE in 4.8.2 with compound literal

[Marek Polacek]

On Tue, Nov 25, 2014 at 09:30:05AM +0100, Mason wrote:
> Hello,
> 
> This ICE may have gotten lost in the noise of my own message.
> https://gcc.gnu.org/ml/gcc-help/2014-11/msg00094.html
> 
> (The code snippet might be invalid C)
> 
> $ gcc -std=gnu99 -O3 -S test.c
> test.c: In function 'main':
> test.c:3:5: internal compiler error: in expand_expr_real_1, at expr.c:10540
>  int main() { return *(adds[0]); }
>  ^

I can reproduce the error.  Please do...

> Please submit a full bug report,

this, and don't forget about:

> with preprocessed source if appropriate.
> See  for instructions.
> Preprocessed source stored into /tmp/cc2RJY0y.out file, please attach this to 
> your bugreport.

(If you need to create a BZ account, please mail overseers and I'll
take care of that.)

Thanks,

Marek

Re: ICE in 4.8.2 with compound literal

[Marek Polacek]

On Tue, Nov 25, 2014 at 10:19:21AM +0100, Mason wrote:
> Aaah, you want me to post the bug report to BZ, not here...

Yep - the snippet + command-line options you posted was enough to reproduce
the bug.  The GCC mailing list is not for reporting bugs.

> When you have a minute, can you take a look at my other message?
> "Using Compound Literal + type-punning to initialize static const array"
> 
> You committed a patch that seems relevant just a few days ago. But the
> documentation lead me to believe that the feature I was looking for had
> been supported for a very long time (gcc 3.x at least)

I haven't read that in detail yet, but my patch just allowed the
initializing even for gnu99/gnu11 (formerly, it was only allowed in the
gnu89 mode).

Marek

Re: GCC 4.9.2 -O3 gives a seg fault / GCC 4.8.2 -O3 works

[Marek Polacek]

On Tue, Jan 06, 2015 at 11:28:52AM -0500, Paul Smith wrote:
> On Tue, 2015-01-06 at 09:43 +0100, Jakub Jelinek wrote:
> > GCC trunk -fsanitize=undefined (in particular
> > -fsanitize=nonnull-attribute)
> > diagnoses it:
> > /tmp/mystring.cpp:103:26: runtime error: null pointer passed as
> > argument 2, which is declared to never be null
> 
> Unfortunately adding -fsanitize=undefined in GCC 4.9.2 doesn't notice
> this (in fact it actually causes the segfault to go away).
> 
> I can try to build a trunk version for this test, I suppose.

Right: -fsanitize=nonnull-attribute is a GCC 5 only thing.

Marek

Re: Announcing Marek Polacek as C front-end reviewer

[Marek Polacek]

On Mon, Jan 12, 2015 at 10:23:16PM -0700, Jeff Law wrote:
> I'm pleased to announce that Marek Polacek has been appointed as a reviewer
> for the C front-end.
 
Thanks!

> Marek, please add yourself as a reviewer for the C front end in the
> MAINTAINERS file.

2015-01-13  Marek Polacek  

* MAINTAINERS (Reviewers): Add self as C front end reviewer.

diff --git gcc/MAINTAINERS gcc/MAINTAINERS
index e4696a1..52fcf5f 100644
--- gcc/MAINTAINERS
+++ gcc/MAINTAINERS
@@ -270,6 +270,7 @@ check in changes outside of the parts of the compiler they 
maintain.
 
Reviewers
 
+C front end    Marek Polacek   
 dataflow   Paolo Bonzini   
 dataflow   Seongbae Park   
 dataflow   Kenneth Zadeck  

Marek

Re: Serious Regressions tables on https://gcc.gnu.org

[Marek Polacek]

On Fri, Feb 13, 2015 at 03:12:22PM -0500, Jack Howarth wrote:
> Is there a reason why the Serious Regressions tables, displayed by
> the links in the 'Release Series and Status' section at
> https://gcc.gnu.org, no longer have a column for the priority
> (importance) of each bug? We used to have that and it was quite nice
> to be able to click on the priority column header to regenerate the
> table sorted by bug priority (to quickly see how many P1s are open).
> Any chance of getting that functionality back?

You probably need to enable the Priority column in Change Columns at
the bottom of the page.

Marek

Re: array bounds, sanitizer, safe programming, and cilk array notation

[Marek Polacek]

Sorry for late reply - I've found this in my inbox only today.

On Mon, Jan 26, 2015 at 11:53:59AM -0800, Martin Uecker wrote:
> 
> Hi all,
> 
> I am writing numerical code, so I am trying to make the use 
> of arrays in C (with gcc) suck a bit less. In general, the long term
> goal would be to have either a compile-time warning or the possibility
> to get a run-time error if one writes beyond the end of an array as 
> specified by its type.
> 
> So one example (see below) I looked at is where I pass an array of
> too small size to a function, to see how see can be diagnosed. In some
> cases, we can get a runtime error with the address sanitizer, but this
> is fairly limited (e.g. it does not work when the array is embedded
> in a struct) and I also got mixed results when the function
> is inlined.
> 
> For pointers to arrays with static size one can get an "incompatible
> pointer" warning - which is nice. With clang, I also get warning for 
> pointers which are declared as array parameters and use the 'static' 
> keyword to specify a minimum size. This a diagnostic we are currently
> missing.
> 
> The next step would be to have diagnostics also for the VLA
> case if the size is known at compilation time (as in the
> example below) and a run-time error when it is not (maybe 
> with the undefined behaviour sanitizer?).
> 
> If we have the later, I think this might also help with safer 
> programming in C, because one would get either a compile time or 
> runtime error when I passing a buffer which is too small to
> a function. For example, snprintf could have a prototype like
> this:
> 
> int snprintf(size_t size; char str[static size], size_t size, 
>   const char *format, ...);
> 
> That VLAs essentially provide the bounded pointer type C is
> missing has been pointed out before, e.g. there was a proposal
> by John Nagle, although he proposed rather intrusive language
> changes (e.g. adding references to C) which are not necessary
> in my opinion:
> 
> https://gcc.gnu.org/ml/gcc/2012-08/msg00360.html
> 
> 
> Finally, what is missing is a way to diagnose problems inside
> the called functions. -Warray-bounds=2 (with my recently
> accepted patch) helps with this, but - so far - only for static 
> arrays:
> 
> void foo(int (*x)[4])
> {
>   (*x)[4] = 5;// warning
> }
 
This is detected by -fsanitize=object-size, turned on by default in
-fsanitize=undefined.  Since it makes use of __builtin_object_size,
it is necessary to compile with optimizations turned on.

> It would be nice to also have these warning and runtime errors
> (with the undefined behaviour sanitizer) for VLAs. 
> 
> Finally, I think we should have corresponding warning also
> for pointers which are declared as array parameters:
> 
> void foo2(int x[4])
> {
>   x[4] = 5;
> }
 
Ditto.

> The later does not currently produce a warning, because x
> is converted to a pointer and the length is ignored. 
> 
> If it is not possible to have warning here for compatibility
> reasons, one possibility is to have an extension similar to 
> 'static' which makes 'x' a proper array in the callee, e.g. 

I think even the 'static in parameter array declarators' (ugly) C99 extension
isn't properly implemented yet (I don't think that the compiler makes
any optimization based on it).

So - if I understood this correctly - I think it's better to enhance
ubsan than to add any kind of language extensions.

Marek

Re: array bounds, sanitizer, safe programming, and cilk array notation

[Marek Polacek]

Sorry for late reply.

On Tue, Jan 27, 2015 at 12:07:58AM +, Joseph Myers wrote:
> On Mon, 26 Jan 2015, Martin Uecker wrote:
> 
> > extern void bar2(int (*x)[5]);
> 
> > int c = 4;
> > int y[c];
> 
> > bar2(&y);   // not diagnosed (found by asan)
> 
> This is the undefined behavior "If the two array types are used in a 
> context which requires them to be compatible, it is undefined behavior if 
> the two size specifiers evaluate to unequal values." (C11 6.7.6.2#6).  
> Yes, it would make sense for ubsan to detect this.  Generally, most forms 
> of runtime undefined behavior listed in J.2 should have ubsan detection 
> unless hard to detect / detected by some other sanitizer such as asan.
 
I have created a table to that effect some time ago:
http://people.redhat.com/mpolacek/www/analyzability.html
Obviously the question marks should be replaced by a -fsanitize=
option that detects a particular UB.  Or say that a particular UB is a
compile-time error (e.g. "declaring a function at block scope with an explicit
storage-class specifier other than extern").

I don't know what to do with the UBs on the library side - those 7.* ones.

> Does adding new forms of sanitization require upstream libsanitizer 
> changes as well or can arbitrary ubsan checks be added without needing 
> libsanitizer changes?

I think we also need libubsan changes.  But it is usually just about
printing an error message along with some values - nothing terribly
complex.

Marek

Re: A bug (?) with inline functions at O0: undefined reference

[Marek Polacek]

On Fri, Mar 06, 2015 at 07:12:48PM +0300, Ilya Verbin wrote:
> Hi All,
> 
> I've discovered a strange behaviour on trunk gcc, here is the reproducer:
> 
> inline int foo ()
> {
>   return 0;
> }
> 
> int main ()
> {
>   return foo ();
> }
> 
> $ gcc main.c
> /tmp/ccD1LeXo.o: In function `main':
> main.c:(.text+0xa): undefined reference to `foo'
> collect2: error: ld returned 1 exit status
> 
> Is this a bug?  If yes, is it known?
> GCC 4.8.3 works fine though.

Not a bug, just different inline semantics now that the default is
gnu11.  See https://gcc.gnu.org/gcc-5/porting_to.html for more info.

Marek

Re: Unnamed Struct / Union

[Marek Polacek]

On Mon, Mar 23, 2015 at 02:07:28PM +0530, Umesh Kalappa wrote:
> Hi All ,
> 
> GCC 4.8.3 ,pop up with below error
> 
> /home/i16382/an.c:13:18: error: duplicate member 'bOriginator'
>  unsigned bOriginator;
>   ^
> 
> for the case
> 
> union
> {
> struct
> {
> unsigned bStatusType;
> unsigned bOriginator;
> };
> struct
> {
> unsigned originator;
> unsigned memoryContentsChanged;
> unsigned interruptPending;
> unsigned bOriginator;
> };
> } USB_WORD;
> 
> is that expected behaviour ?

Yes.

Marek

Re: Change to C++11 by default?

[Marek Polacek]

On Thu, May 07, 2015 at 01:46:32PM -0500, Jason Merrill wrote:
> I think it's time to switch to C++11 as the default C++ dialect for GCC 6.
> Any thoughts?

Couldn't we switch directly to C++14 now that the support is complete?

Regardless, I support changing the default (obviously... ;)).

Marek

Re: Identifying Pure and Const Functions

[Marek Polacek]

On Fri, May 29, 2015 at 01:16:32PM +0530, Pritam Gharat wrote:
> How do we identify whether a function is a pure or a const function?
> Is there any flag associated with its cgraph_node or the tree node
> (decl of cgraph_node)?

You'll want to look into ipa-pure-const.c.

Marek

Re: How do we write unused arguments?

[Marek Polacek]

On Thu, Nov 05, 2015 at 10:32:11AM +0100, Bernd Schmidt wrote:
> When reviewing patches I'm never quite sure which of the following we should
> be using:
> 
> some_target_hook (tree decl, machine_mode mode ATTRIBUTE_UNUSED)
> 
> some_target_hook (tree decl, machine_mode ARG_UNUSED (mode))
> 
> some_target_hook (tree decl, machine_mode /* mode */)
> 
> some_target_hook (tree decl, machine_mode)
> 
> Any opinions? I'm leaning towards the last version since it's idiomatic in
> the language we're using and has the least amount of visual clutter. If no
> one comments, I'll start enforcing that in patch reviews. Currently no one
> seems sure and everything is getting totally inconsistent.

FWIW, I also like the last version best.

Marek

Re: Extraneous newline emitted between error messages in GCC 6

[Marek Polacek]

On Mon, Dec 21, 2015 at 01:12:33PM -0500, Patrick Palka wrote:
> GCC 6, compared to GCC 5, now emits an extra newline between error
> messages.  Is this intended?
> 
> $ cat error.c
> int x = a;
> int y = b;
> $ gcc-5 error.c
> error.c:1:9: error: ‘a’ undeclared here (not in a function)
>  int x = a;
>  ^
> error.c:2:9: error: ‘b’ undeclared here (not in a function)
>  int y = b;
>  ^
> $ gcc-6 error.c
> error.c:1:9: error: ‘a’ undeclared here (not in a function)
>  int x = a;
>  ^
> 
> error.c:2:9: error: ‘b’ undeclared here (not in a function)
>  int y = b;
>  ^
> 
> $

Started with r229884: Reimplement diagnostic_show_locus, introducing
rich_location classes.  I think it is a bug and should be fixed.

Marek

Re: void* vs void *

[Marek Polacek]

On Fri, Jan 29, 2016 at 07:13:00PM +0100, Magnus Fromreide wrote:
> I just noticed that the C and C++ compiler output pointer types differently:
> 
> Consider
> 
> int i;
> printf("%p", &i);
> 
> When compiled as C that gives the warning
> 
> format '%p' expects argument of type 'void *', but argument 2 has type 'int *'
> 
> but when compiled as C++ it gives the warning
> 
> format '%p' expects argument of type 'void*', but argument 2 has type 'int*'
> 
> Why are they different?

So, C and C++ have different printers (C has c_tree_printer and C++
cp_printer).  But in this case the difference comes from format_type_warning:

2657   p = (char *) alloca (pointer_count + 2);
2658   if (pointer_count == 0)
2659 p[0] = 0;
2660   else if (c_dialect_cxx ())
2661 {
2662   memset (p, '*', pointer_count);
2663   p[pointer_count] = 0;
2664 }
2665   else
2666 {
2667   p[0] = ' ';
2668   memset (p + 1, '*', pointer_count);
2669   p[pointer_count + 1] = 0;
2670 }

So the C FE gets the space but the C++ FE does not.  The reason for this is
probably to keep in sync with the C++ printer which doesn't put space before
'*'; in dump_type_prefix we have
 741 if (TYPE_PTR_P (t))
 742   pp_star (pp);
so there's no pp_cxx_whitespace before '*'.

I like the version with space more; maybe we could change this in the next
stage1.

Marek

Re: nonnull, -Wnonnull, and do/while

[Marek Polacek]

On Tue, Feb 16, 2016 at 10:43:08AM +0100, Stefan Sobernig wrote:
> Under a recent gcc 6 [*], we run into -Wnonnull warnings using the
> nonnull attribute:

Yes, this warning has been enhanced for GCC 6.
 
> test.c: In function 'f':
> test.c:16:14: warning: nonnull argument 's' compared to NULL [-Wnonnull]
>} while (s != NULL);
> 
> Am I missing sth.? Is this a false positive?

Well, it's just that "s" has the nonnull attribute so the compiler thinks it
should never be null in which case comparing it to null should be redundant.
Doesn't seem like a false positive to me, but maybe someone else feels
otherwise.

Marek

Re: nonnull, -Wnonnull, and do/while

[Marek Polacek]

On Tue, Feb 16, 2016 at 11:11:21AM +0100, Jakub Jelinek wrote:
> On Tue, Feb 16, 2016 at 11:04:38AM +0100, Marek Polacek wrote:
> > On Tue, Feb 16, 2016 at 10:43:08AM +0100, Stefan Sobernig wrote:
> > > Under a recent gcc 6 [*], we run into -Wnonnull warnings using the
> > > nonnull attribute:
> > 
> > Yes, this warning has been enhanced for GCC 6.
> >  
> > > test.c: In function 'f':
> > > test.c:16:14: warning: nonnull argument 's' compared to NULL [-Wnonnull]
> > >} while (s != NULL);
> > > 
> > > Am I missing sth.? Is this a false positive?
> > 
> > Well, it's just that "s" has the nonnull attribute so the compiler thinks it
> > should never be null in which case comparing it to null should be redundant.
> > Doesn't seem like a false positive to me, but maybe someone else feels
> > otherwise.
> 
> The nonnull attribute should be solely about the value that is passed to the
> function, it doesn't tell anything about the value of the argument after
> it is changed.  So IMHO this warning change should be reverted and instead
> we should warn somewhere soon after going into SSA, only when
> the SSA_NAME_IS_DEFAULT_DEF of the PARM_DECL which has non-NULL attribute
> is compared to NULL.

In that case I take back what I wrote, sorry.

Marek

Re: increase alignment of global structs in increase_alignment pass

[Marek Polacek]

On Tue, Feb 23, 2016 at 09:49:37PM +0530, Prathamesh Kulkarni wrote:

> diff --git a/gcc/tree-vectorizer.c b/gcc/tree-vectorizer.c
> index 2b25b45..a6af535 100644
> --- a/gcc/tree-vectorizer.c
> +++ b/gcc/tree-vectorizer.c
> @@ -794,6 +794,75 @@ make_pass_slp_vectorize (gcc::context *ctxt)
>   This should involve global alignment analysis and in the future also
>   array padding.  */
> 
> +static unsigned get_vec_alignment_for_decl (tree);

Why the forward decl?  Better to topologically sort the functions.

Also, the functions are missing comments.

> +static unsigned
> +get_vec_alignment_for_array_decl (tree array_decl)
> +{
> +  tree type = TREE_TYPE (array_decl);
> +  gcc_assert (TREE_CODE (type) == ARRAY_TYPE);
> +
> +  tree vectype = get_vectype_for_scalar_type (strip_array_types (type));
> +  return (vectype) ? TYPE_ALIGN (vectype) : 0;
> +}
> +
> +static unsigned
> +get_vec_alignment_for_record_decl (tree record_decl)
> +{
> +  tree type = TREE_TYPE (record_decl);
> +  gcc_assert (TREE_CODE (type) == RECORD_TYPE);
> +  unsigned max_align = 0, alignment;
> +  HOST_WIDE_INT offset;
> +
> +  if (DECL_ARTIFICIAL (record_decl) || TYPE_PACKED (type))
> +return 0;
> +
> +  for (tree field = first_field (type);
> +   field != NULL_TREE;
> +   field = DECL_CHAIN (field))
> +{
> +  /* C++FE puts node "._0" of code TYPE_DECL. skip that.  */
> +  if (TREE_CODE (field) != FIELD_DECL)
> + continue;
> +
> +  offset = int_byte_position (field);
> +  alignment = get_vec_alignment_for_decl (field);
> +  if (alignment
> +   && (offset % (alignment / BITS_PER_UNIT) == 0)
> +   && (alignment > max_align))
> + max_align = alignment;
> +}
> +
> +  return max_align;
> +}
> +
> +static unsigned
> +get_vec_alignment_for_decl (tree decl)
> +{
> +  if (decl == NULL_TREE)
> +return 0;
> +
> +  gcc_assert (DECL_P (decl));
> +
> +  static unsigned alignment = 0;
> +  tree type = TREE_TYPE (decl);
> +
> +  switch (TREE_CODE (type))
> +{
> +  case ARRAY_TYPE:
> + alignment = get_vec_alignment_for_array_decl (decl);
> + break;
> +  case RECORD_TYPE:
> + alignment = get_vec_alignment_for_record_decl (decl);
> + break;
> +  default:
> + alignment = 0;
> + break;
> +}
> +
> +  return (alignment > DECL_ALIGN (decl)) ? alignment : 0;
> +}
> +
>  static unsigned int
>  increase_alignment (void)
>  {
> @@ -804,23 +873,14 @@ increase_alignment (void)
>/* Increase the alignment of all global arrays for vectorization.  */
>FOR_EACH_DEFINED_VARIABLE (vnode)
>  {
> -  tree vectype, decl = vnode->decl;
> -  tree t;
> +  tree decl = vnode->decl;
>unsigned int alignment;
> 
> -  t = TREE_TYPE (decl);
> -  if (TREE_CODE (t) != ARRAY_TYPE)
> -continue;
> -  vectype = get_vectype_for_scalar_type (strip_array_types (t));
> -  if (!vectype)
> -continue;
> -  alignment = TYPE_ALIGN (vectype);
> -  if (DECL_ALIGN (decl) >= alignment)
> -continue;
> +  alignment = get_vec_alignment_for_decl (decl);
> 
> -  if (vect_can_force_dr_alignment_p (decl, alignment))
> +  if (alignment && vect_can_force_dr_alignment_p (decl, alignment))
>  {
> -   vnode->increase_alignment (TYPE_ALIGN (vectype));
> +   vnode->increase_alignment (alignment);
>dump_printf (MSG_NOTE, "Increasing alignment of decl: ");
>dump_generic_expr (MSG_NOTE, TDF_SLIM, decl);
>dump_printf (MSG_NOTE, "\n");


Marek

Re: Additional BOFs for the GNU Cauldron?

[Marek Polacek]

On Fri, Sep 02, 2016 at 11:19:54AM +0200, Richard Biener wrote:
> 
> There seems to be plenty of slots available on the 2nd track to
> schedule additional BOFs.  So I'd gather if there is interest
> in discussing
> 
>  A) Unit testing (GIMPLE FE, RTL FE, the existing unit-testing),
> basically how people feel about moving forward here and how
> this would affect the current testsuite structure
> 
>  B) GIMPLE evolution.  With LTO early debug we could finally remove
> some tree slack at some point in the compilation.  There is
> also increasing need to somehow represent multiple outputs
> from a GIMPLE stmt (we've used complex types as a workaround
> in some cases) -- esp. if we would consider moving GIMPLE further
> into the backend area by lowering it and for example performing
> instruction selection on GIMPLE (we'd need to represent flag
> registers, etc.)
> 
>  C) Vectorizer.  There's no vectorizer specific talk yet, the usual
> suspects would be an update from the we-rewrite-the-vectorizer
> folks and ideas about how to improve cost modeling.
> 
> If there's no strong interest in any of the above we can schedule
> stuf as needed at the Cauldron itself as well.

I'd be interested in all of them.

Marek

Re: tree-prof parallel make check failures

[Marek Polacek]

On Tue, Sep 20, 2016 at 05:29:03PM -0600, Martin Sebor wrote:
> I'm seeing a number of failures in different tests in the tree-prof
> directory when I run make check in parallel none of which are
> reproducible with -j1.  I don't see anything about in Bugzilla or
> in recent test results.  Has anyone noticed this or am I missing
> something?

I'm seeing those too and it's very bothering.  I think Andi Kleen
had some patches to fix these, but seems it needs to be fixed more.

Marek

Re: Problem with 447.dealII in spec2006 because of r240707

[Marek Polacek]

On Tue, Oct 04, 2016 at 08:38:00AM -0700, Andrew Pinski wrote:
> On Tue, Oct 4, 2016 at 8:33 AM, Bill Seurer  wrote:
> > parameter_handler.cc: In member function 'double
> > ParameterHandler::get_double(const string&) const':
> > parameter_handler.cc:777:28: error: ISO C++ forbids comparison between
> > pointer and integer [-fpermissive]
> >AssertThrow ((s.c_str()!='\0') || (*endptr == '\0'),
> > ^
> > With the recent revision r240707 comparing a pointer with \0 became an
> > error.  Unfortunately this is used in several spots in the test case
> > 447.dealII in spec2006 (one example above).  There doesn't appear to be a
> > way to disable this error check and we're not supposed to change the spec
> > test cases.  Any ideas on how to work around this?
> 
> Did you try -fpermissive ?  Because that seems like it was listed ...

-fpermissive ought to help, but really best would be to use NULL instead
of '\0'...

Marek

Re: History of GCC

[Marek Polacek]

I think you can learn a lot if you follow the Changes pages, so e.g.
, and go back down the history until
you reach the ancient .

Marek

Re: Delayed warning

[Marek Polacek]

On Mon, Apr 29, 2019 at 08:39:57AM -0600, Jeff Law wrote:
> On 4/29/19 8:24 AM, Thomas Koenig wrote:
> > Hi!
> > 
> > Is there a way to mark a TREE statement (or a variable) so that
> > a warning is issued at a later stage if the statement has not been
> > removed in the meantime?
> > 
> > I am thinking, for example, of Fortran's -Warray-temporaries, which
> > issues a warning in the front end even though the whole temporary
> > array may be optimized away later.  We could, for example, mark
> > a call to malloc in such a way.
> I'm not aware of one, but I recently suggested the concept of
> __builtin_warning which would allow us to effectively delay a warning.
> 
> The goal was to have the warning explicitly in the IL so that if the
> path to the warning was later determined infeasible the warning would
> just get removed by the standard unreachable code elimination optimization.
> 
> This would allow us to avoid false positives due to the IL not being
> well enough optimized at the point where we discover something is
> potentially amiss.

FYI, I also raised the idea of delayed warnings in the C FE some time ago:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68193#c3

Marek

Re: [PATCH] Deprecate -frepo option.

[Marek Polacek]

On Fri, Sep 06, 2019 at 08:58:48AM +0200, Martin Liška wrote:
> Ok, hopefully nobody is strongly against. I've just retested the
> patch and installed it as r275450.

--- a/gcc/c-family/c.opt
+++ b/gcc/c-family/c.opt
@@ -1763,8 +1763,8 @@ ObjC ObjC++ LTO Var(flag_replace_objc_classes)
 Used in Fix-and-Continue mode to indicate that object files may be swapped in 
at runtime.

 frepo
-C++ ObjC++
-Enable automatic template instantiation.
+C++ ObjC++ Deprecated
+Deprecated in GCC 10.  This switch has no effect.

But it's not just deprecated, it's removed now, so shouldn't this be Ignored?

Also, https://gcc.gnu.org/gcc-10/changes.html should be updated, both in
Caveats and the C++ section.  But I can do that.

Marek

Re: Boost build broken due to recent C++ change?

[Marek Polacek]

On Tue, Sep 24, 2019 at 10:16:27PM +, Steve Ellcey wrote:
> A recent g++ change (I haven't tracked down exactly which one, but in
> the last day or two) seems to have broken my boost build.  It is dying
> with lots of errors like:
> 
> ./boost/intrusive/list.hpp:1448:7:   required from here
> ./boost/intrusive/detail/list_iterator.hpp:93:41: error: call of
> overloaded 'get
> _next(boost::intrusive::list_node*&)' is ambiguous
>93 |   node_ptr p = node_traits::get_next(members_.nodeptr_);
>   |~^~~
> In file included from ./boost/intrusive/list_hook.hpp:20,
>  from ./boost/intrusive/list.hpp:20,
>  from ./boost/fiber/context.hpp:29,
>  from libs/fiber/src/algo/algorithm.cpp:9:
> 
> Has anyone else run into this?  I will try to create a cutdown test
> case.

I'm afraid this will be my

commit 5ac76b02008255b7f427e6309c2dc3e42bd64561
Author: mpolacek 
Date:   Mon Sep 23 17:37:54 2019 +

PR c++/91844 - Implement CWG 2352, Similar types and reference 
binding.
* call.c (reference_related_p): Use similar_type_p instead of
same_type_p.
(reference_compatible_p): Update implementation to match CWG 2352.
* cp-tree.h (similar_type_p): Declare.
* typeck.c (similar_type_p): New.

* g++.dg/cpp0x/pr33930.C: Add dg-error.
* g++.dg/cpp0x/ref-bind1.C: New test.
* g++.dg/cpp0x/ref-bind2.C: New test.
* g++.dg/cpp0x/ref-bind3.C: New test.
* g++.old-deja/g++.pt/spec35.C: Remove dg-error.


git-svn-id: svn+ssh://gcc.gnu.org/svn/gcc/trunk@276058 
138bc75d-0d04-0410-961f-82ee72b054a4

Please open a bug.

Marek

Re: GCC 10.0 Status Report (2019-10-22), Stage 1 to end Nov 16th

[Marek Polacek]

On Fri, Nov 01, 2019 at 04:01:12PM +0100, Romain Geissler wrote:
> Le mar. 22 oct. 2019 à 14:53, Richard Biener  a écrit :
> >
> > Please make sure to get features intended for GCC 10 finished
> > and reviewed before the end of stage 1.
> >
> 
> Hi,
> 
> I understand my question comes very (most likely too) late, but are
> there any plans to switch the default C++ dialect to -std=gnu++17 when
> invoking g++ ? C++17 support in gcc is now quite complete, has been
> out tested by some users since gcc 8, so shall it be switched on by
> default in gcc 10 ? Or gcc 11 ? However I fear doing that may break
> some tests in the testsuite, I hope not too many.

I plan to propose a switch to -std=gnu++17 in GCC 11.  I think it's way
too late for GCC 10.

Dealing with the testsuite fallout, and rebuilding Fedora packages is
of course part of that switch.

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

Re: GCC 10.0 Status Report (2019-10-22), Stage 1 to end Nov 16th

[Marek Polacek]

On Fri, Nov 01, 2019 at 09:31:07AM -0600, Jeff Law wrote:
> On 11/1/19 9:08 AM, Marek Polacek wrote:
> > On Fri, Nov 01, 2019 at 04:01:12PM +0100, Romain Geissler wrote:
> >> Le mar. 22 oct. 2019 à 14:53, Richard Biener  a écrit :
> >>>
> >>> Please make sure to get features intended for GCC 10 finished
> >>> and reviewed before the end of stage 1.
> >>>
> >>
> >> Hi,
> >>
> >> I understand my question comes very (most likely too) late, but are
> >> there any plans to switch the default C++ dialect to -std=gnu++17 when
> >> invoking g++ ? C++17 support in gcc is now quite complete, has been
> >> out tested by some users since gcc 8, so shall it be switched on by
> >> default in gcc 10 ? Or gcc 11 ? However I fear doing that may break
> >> some tests in the testsuite, I hope not too many.
> > 
> > I plan to propose a switch to -std=gnu++17 in GCC 11.  I think it's way
> > too late for GCC 10.
> > 
> > Dealing with the testsuite fallout, and rebuilding Fedora packages is
> > of course part of that switch.
> FWIW, we *could* do the rebuild test, we've got time for that.  What's
> far more interesting would be dealing with the fallout ;-)

I most definitely had your tester in mind ;).

> I'd tend to agree though, flip the default as soon as gcc-11 stage1
> opens.  That gives us plenty of time to deal with any fallout.

Sounds like we have a plan.

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

Re: Commit messages and the move to git

[Marek Polacek]

On Tue, Nov 05, 2019 at 11:27:50AM +, Jason Merrill wrote:
> On Tue, Nov 5, 2019 at 11:07 AM Jonathan Wakely  wrote:
> > On Mon, 4 Nov 2019 at 17:42, Joseph Myers wrote:
> > > On Mon, 4 Nov 2019, Segher Boessenkool wrote:
> > >
> > > > On Mon, Nov 04, 2019 at 04:19:25PM +, Jonathan Wakely wrote:
> > > > > I've already proposed a more specific format for libstdc++:
> > > > > https://gcc.gnu.org/ml/libstdc++/2019-09/msg00122.html
> > > >
> > > > PR libstdc++/12345 takes up the first 19 chars of the short subject,
> > > > adding no useful information (unless the reader knows all PRs by heart,
> > > > you need to look it up to know what it is).
> > > >
> > > > I usually put (PR12345) at the end of the subject.  The area is clear
> > > > from the rest of the subject already.
> > >
> > > Agreed.  (Hint to patch submitters: if the subject line of your patch
> > > submission is just "Fix PR12345" or similar, people are less likely to
> > > review your patch because nothing about the subject tells anyone that the
> > > patch is in their area and so something they should pay attention to.
> > > Patch submissions need to have subjects that make clear very quickly what
> > > the patch is about.  This is also why I don't care for [PATCH] tags at the
> > > start of subject lines - they take away space for saying what the patch is
> > > about, and on gcc-patches we can expect things are patches, [PATCH]
> > > doesn't add useful information.)
> >
> > I don't mind [PATCH] in the subject of patch emails (maybe because
> > nearly all my patches go to libstdc++@ as well, and not all mails on
> > that list are patches), but it has negative value in the commit log.
> 
> I actively like [PATCH] in the subject line because I see patch mail
> interleaved with other mail in my inbox.
> 
> > My mail to the libstdc++ list should have noted that [PATCH] tags in
> > the email subject should be omitted from the summary in the first line
> > of the commit log.
> 
> And git format-patch/git am automatically add and remove [PATCH] 
> appropriately.

Wrt [PATCH]: if we keep it, do we want to have a system to distinguish
C/C++/... patches?  Do we want [C++ PATCH] or [PATCH][C++] or [C++][PATCH],
something else?  (I find the latter two a bit ugly.)

Marek

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

[Marek Polacek]

On Thu, Dec 05, 2019 at 05:03:43PM +, Jonathan Wakely wrote:
> On Thu, 5 Dec 2019 at 16:44, Michael Matz  wrote:
> >
> > Hello,
> >
> > (oh a flame bait :) )
> >
> > On Thu, 5 Dec 2019, Thomas Schwinge wrote:
> >
> > > So, I formally propose that we lift this characters per line restriction
> > > from IBM punch card (80) to mainframe line printer (132).
> > >
> > > Tasks:
> > >
> > >   - Discussion.
> >
> > I object to cluttering code in excuse for using sensible function names or
> > temporaries that otherwise can help clearing up code.  Using 132-char
> > lines is cluttering code:
> > - long lines are harder to read/grasp: vertical eye movement is easier
> >   than horizontal, and source code should be optimized for
> >   reading, not writing
> > - long lines make it impossible to have two files next to each other at a
> >   comfortable font size
> > - long lines are incompatible with existing netiquette re emails, for
> >   instance
> >
> > So, at least for me, that my terminals are 80 wide (but not x24) has
> > multiple reasons, and the _least_ of it is because that's what punch cards
> > had.
> 
> C++17 introduces a nice feature, with rationale similar to declaring
> variables in a for-loop init-statement:
> 
> if (auto var = foo(); bar(var))
> 
> The variable is only in scope for the block where you need it, just
> like a for-loop.
> 
> Unfortunately nearly every time I've tried to use this recently, I've
> found it's impossible in 80 columns, e.g. this from yesterday:
> 
> if (auto __c = __builtin_memcmp(&*__first1, &*__first2, __len) <=>
> 0; __c != 0)
>   return __c;
> 
> When you're forced to uglify every variable with a leading __ you run
> out of characters pretty damn quickly.
> 
> I can either not use the feature (and have the variable defined in a
> larger scope than it needs to be) or add fairly arbitrary line breaks:
> 
> if (auto __c
> = __builtin_memcmp(&*__first1, &*__first2, __len)
> <=> 0; __c != 0)
>   return __c;
> 
> or try to give the variables shorter (and less meaningful) names.
> Adding line breaks or picking shorter names doesn't help readability.
> So I end up not using the feature.
> 
> I'm loosely in favour of relaxing the rule for libstdc++ code. I don't
> really care what the rest of GCC looks like ;-)

Not using such a nice feature just because of formatting sounds really
shameful.  Would the compromise of 100 chars make things any better here?

Marek

Re: [RFC] Characters per line: from punch card (80) to line printer (132) (was: [Patch][OpenMP/OpenACC/Fortran] Fix mapping of optional (present|absent) arguments)

[Marek Polacek]

On Thu, Dec 05, 2019 at 02:06:50PM -0600, Segher Boessenkool wrote:
> Hi!
> 
> On Thu, Dec 05, 2019 at 05:03:43PM +, Jonathan Wakely wrote:
> > C++17 introduces a nice feature, with rationale similar to declaring
> > variables in a for-loop init-statement:
> > 
> > if (auto var = foo(); bar(var))
> 
> Similar to GNU C statement expressions, which are *also* only a good
> idea to use in limited cases.
> 
> > The variable is only in scope for the block where you need it, just
> > like a for-loop.
> > 
> > Unfortunately nearly every time I've tried to use this recently, I've
> > found it's impossible in 80 columns, e.g. this from yesterday:
> > 
> > if (auto __c = __builtin_memcmp(&*__first1, &*__first2, __len) <=>
> > 0; __c != 0)
> >   return __c;
> > 
> > When you're forced to uglify every variable with a leading __ you run
> > out of characters pretty damn quickly.
> 
> If using this "nice feature" forces you to uglify your code, then maybe
> it is not such a nice feature, and you should not use it.

I disagree, it is a nice feature, without quotes.  It's Good Style not to
leak variables into enclosing scopes.

> If you have issues with scoping your functions are WAY too long already.

I don't think that's the case here.

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

Re: GCC static analysis branch now available on Compiler Explorer

[Marek Polacek]

On Tue, Dec 10, 2019 at 10:46:59AM -0500, David Malcolm wrote:
> For the adventurous/curious, my static analyzer branch of GCC [1] is
> now available on Compiler Explorer (aka godbolt.org) so you can try it
> out without building it yourself.  [Thanks to Matt Godbolt, Patrick
> Quist and others at the Compiler Explorer project]

Congrats!

> On https://godbolt.org/ within the C and C++ languages, select
>   "x86-64 gcc (static analysis)"
> as the compiler (though strictly speaking only C is in-scope right
> now).  It's configured to automatically inject -fanalyzer (just on this
> site; it isn't the default in the branch).
> 
> Some precanned examples:
>   * various malloc issues: https://godbolt.org/z/tnx65n
>   * stdio issues: https://godbolt.org/z/4BP-Tj
>   * fprintf in signal handler: https://godbolt.org/z/ew7mW6
>   * tainted data affecting control flow: https://godbolt.org/z/3v8vSj
>   * password-leakage: https://godbolt.org/z/pRPYiv
> (the non-malloc examples are much more in "proof-of-concept" territory)
> 
> Would it make sense to add an "analyzer" component to our bugzilla,
> even though this is still on a branch? (with me as default assignee)

I think so, we have it for e.g. JIT already, and it's probably just a matter
of time before the analyzer is merged.

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

Re: [PATCH, v2] wwwdocs: e-mail subject lines for contributions

[Marek Polacek]

On Wed, Jan 22, 2020 at 04:05:37PM +, Richard Sandiford wrote:
> "Richard Earnshaw (lists)"  writes:
> > On 21/01/2020 17:20, Jason Merrill wrote:
> >> On 1/21/20 10:40 AM, Richard Earnshaw (lists) wrote:
> >>> On 21/01/2020 15:39, Jakub Jelinek wrote:
>  On Tue, Jan 21, 2020 at 03:33:22PM +, Richard Earnshaw (lists) 
>  wrote:
> >> Some examples would be useful I'd say, e.g. it is unclear in what 
> >> way you
> >> want the PR number to be appended, shall it be
> >> something: whatever words describe it PR12345
> >> or
> >> something: whatever words describe it (PR12345)
> >> or
> >> something: whatever words describe it: PR12345
> >> or
> >> something: whatever words describe it [PR12345]
> >> or something else?
> >
> > Glibc use "[BZ #]" - obviously BZ becomes PR, but after that, 
> > I'm not
> > too worried.  I'd be happy with [PR #], but if folk want 
> > something else,
> > please say so quickly...
> 
>  [PR 12345] or [PR #12345] is bad, because the bugzilla won't 
>  underline it,
>  it needs to be either PR12345 word, or PR component/12345 .
> >>>
> >>> ok, lets go with [PR] then.
> >> 
> >> Doesn't this use of [] have the same problem with git am?
> >
> > No, because only 'leading' [] blocks are removed - git mailinfo --help
> >
> >> 
> >> My summaries are often describing the bug I'm fixing, i.e.
> >> 
> >> [PATCH] PR c++/91476 - anon-namespace reference temp clash between TUs.
> >> 
> >> which is also the first line of my ChangeLog entry.  I think you are 
> >> proposing
> >> 
> >> [COMMITTED] c++: Fix anon-namespace reference temp clash between TUs 
> >> (PR91476)
> >> 
> >> which can no longer be shared with the ChangeLog.
> >> 
> >
> > I was trying to unify this with glibc.  They specify the bug number at 
> > the end of the line.
> >
> > We can diverge if it's generally felt to be important, but details like 
> > this create needless friction for folk working in both communities.
> 
> +1 for "component: Summary [PRn]" FWIW.
> 
> PR bz-component/n works well for C++.  The problem is that so many
> other PRs come under tree-optimization and rtl-optimization, which
> eat up a lot of subject line characters without narrowing things down
> very much.  "cselib: ... [PRn]" is both shorter and more descriptive
> than "PR rtl-optimization/n - ", etc.

Yeah, the cselib version definitely looks preferable to me.

What if a patch touches more than just the C++ FE, do we want "c,c++:"?
Though kernel uses

net: sched: act_ctinfo: fix memory leak
locking/rwsem: Fix kernel crash when spinning on RWSEM_OWNER_UNKNOWN

If a patch touches various spots in the optimizers, maybe we can
just go with "tree-opt:" or "rtl:"?

Further, I suppose multiple PRs fixed by a single patch would look like:

c++: Implement DR 666 [PR57, PR12345]

Marek

Re: Warning on move and dereference of unique_ptr in the same expression

[Marek Polacek]

On Mon, Feb 03, 2020 at 09:26:40PM +0100, Allan Sandfeld Jensen wrote:
> Hello gcc
> 
> I have now twice hit obscure bugs in Chromium that crashed on some compilers 
> but not on others, and didn't produce any warnings on any compiler. I would 
> like to know if this code is as undefined as I think it is, and if it would 
> make sense to have gcc warn about it.
> 
> Both cases basically has this form:
> 
> std::unique_ptr a;
> 
> a->b->callMethod(something, bind(callback, std::move(a)));
> 
> This crashed with MSVC and gcc 5, but not with newer gcc or with clang.

You mean the application itself, not the compiler, presumably.

> When it crashes it is because the arguments and the move therein have been 
> evaluated before a->b is resolved.
> 
> I assume this is undefined behavior? So why isn't the warning for using and 
> modifying in the same expression triggered?

This should be defined in C++17, with P0145 in particular:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0145r3.pdf
which says that the expression that names the function is sequenced before every
argument expression and every default argument.

Marek

Re: Warning annoyances in list_read.c

[Marek Polacek]

On Mon, Mar 27, 2017 at 12:18:17PM +0200, Dominique d'Humières wrote:
> > > If he added a new option affecting libgfortran, then he should
> > > fix up libgfortran.
> >
> > He didn't add the warning to specifically annoy fortran developers.
> > It is trivial to add seven gcc_fallthrough() or breaks for someone who
> > knows the code and the person who added the warning obviously doesn't.
> The following patch fixes the warnings
> 
> --- ../_clean/libgfortran/io/list_read.c  2017-03-25 20:42:40.0 
> +0100
> +++ libgfortran/io/list_read.c2017-03-27 12:06:10.0 +0200
> @@ -51,7 +51,8 @@ typedef unsigned char uchar;
>  #define CASE_DIGITS   case '0': case '1': case '2': case '3': case '4': \
>case '5': case '6': case '7': case '8': case '9'
>  
> -#define CASE_SEPARATORS case ' ': case ',': case '/': case '\n': \
> +#define CASE_SEPARATORS /* Fall through. */ \
> + case ' ': case ',': case '/': case '\n': \
>   case '\t': case '\r': case ';'
>  
>  /* This macro assumes that we're operating on a variable.  */
> 
> Indeed before applying this patch, someone will have to check that the 
> warnings do not occur because of missing breaks.
> 
> Note that putting /* Fall through. */ before the use of the macro 
> CASE_SEPARATORS does not work. Is it a (known) bug?

Yes, it's known that the "falls through" comments don't work if they're
preceding a macro.

Marek

Re: Warning annoyances in list_read.c

[Marek Polacek]

On Mon, Mar 27, 2017 at 09:27:34AM -0700, Steve Kargl wrote:
> On Mon, Mar 27, 2017 at 05:22:12PM +0200, Markus Trippelsdorf wrote:
> > On 2017.03.27 at 06:49 -0700, Steve Kargl wrote:
> > > 
> > > Go scan the gcc-patches mailing list for "fallthrough".  I'll
> > > note other have concerns.  Here's one example:
> > > 
> > > https://gcc.gnu.org/ml/gcc-patches/2016-11/msg00300.html
> > > 
> > >Without Bernd's patch to set the default to 1 you will drown
> > >in false positives once you start using gcc-7 to build a whole
> > >distro. On my Gentoo test box anything but level 1 is simply
> > >unacceptable, because you will miss important other warnings
> > >in the -Wimplicit-fallthrough noise otherwise.
> > 
> > The quotation doesn't have anything to do with the current discussion,
> > which is the general usefulness of the warning.
> > It only talks about one of the (admittedly over-engineered) six
> > different levels of the warning.
> > 
> 
> Yes, it does.  See the part about "... drown in false positives ..."
> Whoever turned this option on should have been prepared to deal
> with the fallout by investigating each and every warning (i.e.,
> either fix a real bug or (un)fix valid code to prevent the false
> positive).  
 
Having spent hours on fixing various fallthrough cases throughout the codebase,
deciding whether or not a particular case is an intentional fallthru, and
pursuing various maintainers if I couldn't make a call, I find your statement,
erm, incorrect .  I'm sorry that apparently something has slipped through.
I would've fixed it if I'd hit it.

The warning had been discussed extensively on the ML, and you had the chance to
chime in, too.  There's a reason why the warning is only enabled by -Wextra and
not by -Wall.

> But that's okay.  I now understand that it is acceptable for
> a developer to commit a change that causes issues for other
> developers, and said developer can turn a blind eye.

Nonsense.

Marek

Re: Warning annoyances in list_read.c

[Marek Polacek]

On Mon, Mar 27, 2017 at 07:33:05PM +0200, Toon Moene wrote:
> On 03/27/2017 06:45 PM, Marek Polacek wrote:
> 
> > On Mon, Mar 27, 2017 at 09:27:34AM -0700, Steve Kargl wrote:
> 
> > > But that's okay.  I now understand that it is acceptable for
> > > a developer to commit a change that causes issues for other
> > > developers, and said developer can turn a blind eye.
> > 
> > Nonsense.
> 
> The person developing the warning could *at least* have bootstrapped all
> languages and detected, warned and helped the Fortran/Ada/whatever side to
> cope with it.

Of course "the person" had bootstrapped and tested all the languages before
adding the warning.  If only any of you bothered to check the fortran/
ChangeLogs:

2016-08-12  Marek Polacek  

PR c/7652
* decl.c (match_attr_spec): Add FALLTHRU.
* primary.c (match_arg_list_function): Likewise.
* resolve.c (resolve_operator): Adjust fall through comment.
(fixup_charlen): Add FALLTHRU.
(resolve_allocate_expr): Adjust fall through comment.
* trans-array.c (gfc_conv_ss_startstride): Add FALLTHRU.
* trans-intrinsic.c (gfc_conv_intrinsic_len): Adjust fall through
comment.

2016-09-26  Marek Polacek  

PR c/7652
* arith.c (eval_intrinsic): Add gcc_fallthrough.
* frontend-passes.c (optimize_op): Likewise.
(gfc_expr_walker): Likewise.
* parse.c (next_fixed): Likewise.
* primary.c (match_variable): Likewise.
* trans-array.c: Likewise.
* trans-expr.c (flatten_array_ctors_without_strlen): Likewise.
* trans-io.c (transfer_expr): Likewise.

2016-09-20  Marek Polacek  

* trans-intrinsic.c (conv_expr_ref_to_caf_ref): Adjust fall through
comment.

Marek

Re: Warning annoyances in list_read.c

[Marek Polacek]

On Mon, Mar 27, 2017 at 07:59:01PM +0200, Thomas Koenig wrote:
> Am 27.03.2017 um 19:41 schrieb Marek Polacek:
> 
> > Of course "the person" had bootstrapped and tested all the languages before
> > adding the warning.  If only any of you bothered to check the fortran/
> > ChangeLogs:
> 
> The problem is with libfortran, which apparently was not tested
> (or the problem would have been found and, presumably, dealt with).
 
I always build libgfortran when testing.  The warning was committed
months ago, so it's weird that I'm only hearing about this now.

I would've been happy to fix the warnings if anyone pointed out them to me.
I hadn't know of them until very recently.

> So, due to incomplete testing, a regression was caused.  This has
> probably happened a few thousand times before, so it is not an
> exceptionally big deal.
> 
> We should deal with this the same way we deal with other regressions -
> fix it or, if anything else fails, roll back the offending patch.
> The person who is responsible for the regression should usually take the
> lead in fixing it.
> 
> Since the fix appears to be rather trivial, I promise to review
> any patch that falls into my area of review (fortran, libfortran)
> within 48 hours.

https://gcc.gnu.org/ml/gcc/2017-03/msg00145.html

Marek

Re: Warning annoyances in list_read.c

[Marek Polacek]

On Mon, Mar 27, 2017 at 11:16:32AM -0700, Steve Kargl wrote:
> On Mon, Mar 27, 2017 at 07:41:12PM +0200, Marek Polacek wrote:
> > On Mon, Mar 27, 2017 at 07:33:05PM +0200, Toon Moene wrote:
> > > On 03/27/2017 06:45 PM, Marek Polacek wrote:
> > > 
> > > > On Mon, Mar 27, 2017 at 09:27:34AM -0700, Steve Kargl wrote:
> > > 
> > > > > But that's okay.  I now understand that it is acceptable for
> > > > > a developer to commit a change that causes issues for other
> > > > > developers, and said developer can turn a blind eye.
> > > > 
> > > > Nonsense.
> > > 
> > > The person developing the warning could *at least* have bootstrapped all
> > > languages and detected, warned and helped the Fortran/Ada/whatever side to
> > > cope with it.
> > 
> > Of course "the person" had bootstrapped and tested all the languages before
> > adding the warning.  If only any of you bothered to check the fortran/
> > ChangeLogs:
> > 
> 
> fortran/ != libgfortran/
 
I'm aware.  But it's unfair to say that I hadn't tested Fortran when I,
actually, had.

> "The person" also failed to post his changes to fortran/
> on the fortran@ mailing list.  So, the fortran changes were
> likely not reviewed.

It's entirely possible that I may have forgotten to CC fortran@, mea culpa;
although I see that this went to @fortran, but was committed as obvious anyway:
https://gcc.gnu.org/ml/fortran/2016-09/msg00113.html

Marek

Re: [RFC] GCC 8 Project proposal: Extensions supporting C Metaprogramming, pseudo-templates

[Marek Polacek]

On Thu, May 11, 2017 at 11:12:24AM +0100, Jonathan Wakely wrote:
> On 10 May 2017 at 23:14, Daniel Santos wrote:
> > Well my primary goal is programming with values that are constant in the
> > compiler.  There is no language in any C specification (that I'm aware of)
> > for a "compile-time constant", but the concept is very important.  So just
> > because some expression is a compile-time constant doesn't mean we morph
> > into a "constant expression" (as per the spec), even with
> > __attribute__((const)).
> 
> The C standard says "An implementation may accept other forms of
> constant expressions." That means rather than inventing some
> "constprop" you could just extend GCC to treat more expressions
> involving constants as constant-expressions.
> 
> There are enhancement requests for this in Bugzilla, because some
> compilers are already more catholic in what they accept in constant
> expressions (notably, Clang).

Right, at least:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69960
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66618

Marek

Re: 'make check' questions

[Marek Polacek]

On Thu, May 11, 2017 at 11:50:21AM +0100, Kyrill Tkachov wrote:
> 
> On 11/05/17 11:43, Simon Wright wrote:
> > I see from https://gcc.gnu.org/install/test.html that it's possible to run 
> > tests in parallel. I get the impression from gcc/Makefile that the check 
> > concerned has to be set up in the Makefile (in my build tree, configured 
> > with --target=x86_64-apple-darwin16 
> > --enable-languages=c,c++,ada,fortran,objc,obj-c++ , I see both lang_checks 
> > and lang_checks_parallelized set empty). So, is it necessary for check-ada 
> > or check-acats to cope with being run in parallel (i.e., will they ever see 
> > GCC_RUNTEST_PARALLELIZE_DIR set?)
> 
> I don't usually build Ada, but testing with "make -j check" works for me 
> where  is the parallelism I want

I have
export MAKEFLAGS='-j4'
in my environment.

Marek

Re: comparing parallel test runs

[Marek Polacek]

On Wed, May 17, 2017 at 09:13:40AM -0600, Jeff Law wrote:
> On 05/17/2017 04:23 AM, Aldy Hernandez wrote:
> > Hi folks.
> > 
> > I've been having troubles comparing the results of different test runs
> > for quite some time, and have finally decided to whine about it. Perhaps
> > someone can point out to whatever I may be doing wrong.
> > 
> > I generally do "make check -k -j60" on two different trees and compare
> Make sure you've got Andi's patch installed and report back.  It's
> supposed to help with smaller -j loads, but it's unclear if it's enough
> to address the problems with higher loads like you're using.

I'm still seeing spurious tree-prof failures there (with -j48).

Marek

Re: comparing parallel test runs

[Marek Polacek]

On Thu, May 18, 2017 at 05:22:50PM -0600, Martin Sebor wrote:
> On 05/17/2017 11:19 PM, Andi Kleen wrote:
> > Marek Polacek  writes:
> > 
> > > On Wed, May 17, 2017 at 09:13:40AM -0600, Jeff Law wrote:
> > > > On 05/17/2017 04:23 AM, Aldy Hernandez wrote:
> > > > > Hi folks.
> > > > > 
> > > > > I've been having troubles comparing the results of different test runs
> > > > > for quite some time, and have finally decided to whine about it. 
> > > > > Perhaps
> > > > > someone can point out to whatever I may be doing wrong.
> > > > > 
> > > > > I generally do "make check -k -j60" on two different trees and compare
> > > > Make sure you've got Andi's patch installed and report back.  It's
> > > > supposed to help with smaller -j loads, but it's unclear if it's enough
> > > > to address the problems with higher loads like you're using.
> > > 
> > > I'm still seeing spurious tree-prof failures there (with -j48).
> > 
> > Do they go away if you run first (as root)
> > 
> > echo 5000 > /proc/sys/kernel/perf_event_mlock_kb
> > 
> > first?
> 
> I tried three runs of the profiling tests and the failures did
> clear up with the increased setting.

I tried setting that but I still saw a very small number of tree-prof failures,
at least in one of the runs.  But it did help - thanks.

Marek

Re: Help with rich_location and GIMPLE stmts

[Marek Polacek]

On Thu, May 18, 2017 at 01:22:02PM +0200, Martin Liška wrote:
> On 05/16/2017 09:14 PM, David Malcolm wrote:
> > On Mon, 2017-05-15 at 15:36 +0200, Martin Liška wrote:
> >> Hi.
> >>
> >> I sent this email to David some time ago, but it should be probably
> >> answered
> >> on gcc mailing list.
> > 
> >> I have idea one to improve gcov tool and I'm interested in more
> >> precise locations for gimple
> >> statements. For gcov purpose, we dump location in ipa-profile pass,
> >> which is an early IPA
> >> pass and this data is used by gcov tool to map statements (blocks) to
> >> lines of code.
> >>
> >> I did a small experiment on the place we emit the location data:
> >>  inform (gimple_location (stmt), "output_location");
> >>
> >> and it shows for:
> >> $ cat m2.c
> >> unsigned int
> >> UuT (void)
> >> { unsigned int true_var = 1; unsigned int false_var = 0; unsigned int
> >> ret = 0; if (true_var) /* count(1) */ { if (false_var) /* count(1) */
> >> ret = 111; /* count(#) */ } else ret = 999; /* count(#) */
> >> return ret; }
> >>
> >> int
> >> main (int argc, char **argv)
> >> {
> >>   UuT ();
> >>   return 0;
> >> }
> >>
> >> $ gcc --coverage m2.c
> >> m2.c: In function ‘main’:
> >> m2.c:8:3: note: output_location
> >>UuT ();
> >>^~
> >> # .MEM_2 = VDEF <.MEM_1(D)>
> >> UuT ();
> >> m2.c:9:10: note: output_location
> >>return 0;
> >>   ^
> >> _3 = 0;
> >> m2.c: In function ‘UuT’:
> >> m2.c:3:16: note: output_location
> >>  { unsigned int true_var = 1; unsigned int false_var = 0; unsigned
> >> int ret = 0; if (true_var) /* count(1) */ { if (false_var) /*
> >> count(1) */ ret = 111; /* count(#) */ } else ret = 999; /*
> >> count(#) */ return ret; }
> >> ^~~~
> >> true_var_3 = 1;
> >> m2.c:3:43: note: output_location
> >>  { unsigned int true_var = 1; unsigned int false_var = 0; unsigned
> >> int ret = 0; if (true_var) /* count(1) */ { if (false_var) /*
> >> count(1) */ ret = 111; /* count(#) */ } else ret = 999; /*
> >> count(#) */ return ret; }
> >>^
> >> false_var_4 = 0;
> >> m2.c:3:71: note: output_location
> >>  { unsigned int true_var = 1; unsigned int false_var = 0; unsigned
> >> int ret = 0; if (true_var) /* count(1) */ { if (false_var) /*
> >> count(1) */ ret = 111; /* count(#) */ } else ret = 999; /*
> >> count(#) */ return ret; }
> >>  
> >>   ^~~
> >> ret_5 = 0;
> >> m2.c:3:83: note: output_location
> >>  { unsigned int true_var = 1; unsigned int false_var = 0; unsigned
> >> int ret = 0; if (true_var) /* count(1) */ { if (false_var) /*
> >> count(1) */ ret = 111; /* count(#) */ } else ret = 999; /*
> >> count(#) */ return ret; }
> >>  
> >>   ^
> >> if (true_var_3 != 0)
> >> m2.c:3:114: note: output_location
> >>  { unsigned int true_var = 1; unsigned int false_var = 0; unsigned
> >> int ret = 0; if (true_var) /* count(1) */ { if (false_var) /*
> >> count(1) */ ret = 111; /* count(#) */ } else ret = 999; /*
> >> count(#) */ return ret; }
> >>  
> >>  ^
> >> if (false_var_4 != 0)
> >> m2.c:3:145: note: output_location
> >>  { unsigned int true_var = 1; unsigned int false_var = 0; unsigned
> >> int ret = 0; if (true_var) /* count(1) */ { if (false_var) /*
> >> count(1) */ ret = 111; /* count(#) */ } else ret = 999; /*
> >> count(#) */ return ret; }
> >>  
> >>  
> >>^
> >> ret_7 = 111;
> >> m2.c:3:182: note: output_location
> >>  { unsigned int true_var = 1; unsigned int false_var = 0; unsigned
> >> int ret = 0; if (true_var) /* count(1) */ { if (false_var) /*
> >> count(1) */ ret = 111; /* count(#) */ } else ret = 999; /*
> >> count(#) */ return ret; }
> >>  
> >>  
> >> ^
> >> ret_6 = 999;
> >> m2.c:3:215: note: output_location
> >>  { unsigned int true_var = 1; unsigned int false_var = 0; unsigned
> >> int ret = 0; if (true_var) /* count(1) */ { if (false_var) /*
> >> count(1) */ ret = 111; /* count(#) */ } else ret = 999; /*
> >> count(#) */ return ret; }
> >>  
> >>  
> >>  
> >> ^~~
> >> _8 = ret_2;
> >> m2.c:3:215: note: output_location
> >> # VUSE <.MEM_9(D)>
> >> return _8;
> >>
> >> Which is not optimal, for some assignmen

Re: Getting spurious FAILS in testsuite?

[Marek Polacek]

On Thu, Jun 01, 2017 at 02:59:37PM +0200, Georg-Johann Lay wrote:
> Hi, when I am running the gcc testsuite in $builddir/gcc then
> 
> $ make check-gcc RUNTESTFLAGS='ubsan.exp'
> 
> comes up with spurious fails.
> 
> Running target unix
> Using /usr/share/dejagnu/baseboards/unix.exp as board description file for
> target.
> Using /usr/share/dejagnu/config/unix.exp as generic interface file for
> target.
> Using /home/georg/gnu/gcc.gnu.org/trunk/gcc/testsuite/config/default.exp as
> tool-and-target-specific interface file.
> Running
> /home/georg/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.dg/ubsan/ubsan.exp ...
> FAIL: c-c++-common/ubsan/float-cast-overflow-8.c   -O2  output pattern test
> FAIL: c-c++-common/ubsan/overflow-mul-4.c   -O0  output pattern test
> 
> ...
> 
> when I am running the 1st test alone, then it works:
> 
> $ make check-gcc RUNTESTFLAGS='ubsan.exp=float-cast-overflow-8.c'
> 
> In an older log file I found for a different test from the same folder:
> 
> /home/georg/gnu/gcc.gnu.org/trunk/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-7.h:149:1:
> runtime error: value  is outside the range of representable values
> of type 'unsigned int'
> /home/georg/gnu/gcc.gnu.org/trunk/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-7.h:149:1:
> runtime error: value  is outside the range of representable values
> of type 'long int'
> /home/georg/gnu/gcc.gnu.org/trunk/gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-7.h:149:1:
> runtime error: PASS: c-c++-common/ubsan
> 
> BANG: "PASS" output from previous test run shreds this one?
> 
> /float-cast-overflow-10.c   -O2 -flto -fuse-linker-plugin
> -fno-fat-lto-objects  execution test
> FAIL: c-c++-common/ubsan/float-cast-overflow-10.c   -O2 -flto
> -fuse-linker-plugin -fno-fat-lto-objects  output pattern test
> Output was:
> c-c++-common/ubsan/float-cast-overflow-7.h:147:1: runtime error: value
>  is outside the range of representable values of type 'signed char'
> ...
> c-c++-common/ubsan/float-cast-overflow-7.h:149:1: runtime error:
> Should match:
> 
> The last output line stops after "runtime error: ", i.e. at the place
> where the "PASS" appears.
> 
> Any ideas?

Does this help?

diff --git gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-8.c 
gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-8.c
index 4adb22a..746fe20 100644
--- gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-8.c
+++ gcc/testsuite/c-c++-common/ubsan/float-cast-overflow-8.c
@@ -140,4 +140,4 @@ main ()
 /* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of 
representable values of type 'long long int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value -1 is outside the range of representable values 
of type 'long long unsigned int'\[^\n\r]*(\n|\r\n|\r)" } */
 /* { dg-output "\[^\n\r]*value \[0-9.e+-]* is outside the range of 
representable values of type '__int128'\[^\n\r]*(\n|\r\n|\r)" { target { int128 
} } } */
-/* { dg-output "\[^\n\r]*value -1 is outside the range of representable values 
of type '__int128 unsigned'\[^\n\r]*(\n|\r\n|\r)" { target { int128 } } } */
+/* { dg-output "\[^\n\r]*value -1 is outside the range of representable values 
of type '__int128 unsigned'" { target { int128 } } } */

Marek

Re: https://gcc.gnu.org/gcc-7/changes.html

[Marek Polacek]

On Tue, Jul 11, 2017 at 09:51:19AM -0700, Jonny Grant wrote:
> Hello
> https://gcc.gnu.org/gcc-7/changes.html
> 
> snprintf (d, sizeof d, "%#02x", x & 0xff);
> 
>^^
> Should be:   sizeof(d)  ?

Why?  Both are correct.

Marek

Re: tests for GCC internal functions

[Marek Polacek]

On Wed, Aug 16, 2017 at 08:46:20AM -0600, Martin Sebor wrote:
> Is there a setup for writing and running as part of the test
> suite unit tests that exercise internal GCC functions like
> error and warning?  I ask because of a couple of bugs that
> were recently reported for the %s directive in GCC's
> diagnostics (81859 and 81586) that were only caught by running
> valgrind on GCC, but that could have been caught by GCC's own
> tests for these APIs if they existed.
> 
> I can't find any except some in the gcc.dg/plugin directory
> (though they weren't written to exercise the functions but
> rather the plugin interface).  Would adding a plugin for
> this sort of thing be the right way to do it?

Isn't -fself-test the thing you're looking for?

Marek

Re: Segfault generated by gcc-7

[Marek Polacek]

On Tue, Aug 29, 2017 at 12:31:39PM +0200, Marco Varlese wrote:
> Hi,
> 
> I got a SEGFAULT in my program when compiling it with gcc-7 but it
> is/was all good when using gcc-6.
> 
> The SEGFAULT happens due to the line below:
> d_point = *p;
> 
> And a fix for it (with gcc-7) has been:
> memcpy(&d_point, 
>   p, 
>   sizeof(d_point));
> 
> Does this make any sense to anybody?

Not without a stand-alone testcase.  See 
for more info.

Marek

Re: FYI: Latest gcc-8 snapshot gives ICE with later isl's

[Marek Polacek]

On Mon, Mar 05, 2018 at 12:58:23PM -0500, Donald Parsons wrote:
> 
> I am getting ICE bootstrapping gcc-8-20180304.tar.xz when using either
> isl-0.18 or isl-0.19.   I had never had a problem using latest isl over
> the past couple of years, so a change in gcc last week introduced the
> problem.
> 
> Normally I disable-bootstrap and use last weeks gcc-8 to build this
> weeks gcc-8 and avoid the extra long bootstrap time.  This actually
> worked, at least with isl-0.18 but the resulting gcc-8 gave ICE errors
> building latest "pari-gp" and the latest-rc4 Linux kernel.  So went
> back to bootstrapping with (Redhat gcc-7.3.1-2) and discovered the
> above.
> 
> Here is failure (using isl-0.18; 0.19 looks same):
> ...
> libtool: compile:  /home/don/src/gcc-8-20180304-obj/./prev-gcc/xgcc
> -B/home/don/src/gcc-8-20180304-obj/./prev-gcc/ -B/opt/gcc/gcc-8-
> 0304/x86_64-redhat-linux/bin/ -B/opt/gcc/gcc-8-0304/x86_64-redhat-
> linux/bin/ -B/opt/gcc/gcc-8-0304/x86_64-redhat-linux/lib/ -isystem
> /opt/gcc/gcc-8-0304/x86_64-redhat-linux/include -isystem /opt/gcc/gcc-
> 8-0304/x86_64-redhat-linux/sys-include -DHAVE_CONFIG_H -I. -I../../gcc-
> 8-20180304/isl -I../../gcc-8-20180304/isl/include -Iinclude/ -g -O2
> -gtoggle -MT isl_factorization.lo -MD -MP -MF
> .deps/isl_factorization.Tpo -c ../../gcc-8-
> 20180304/isl/isl_factorization.c -o isl_factorization.o
> during GIMPLE pass: pre
> ../../gcc-8-20180304/isl/isl_factorization.c: In function
> 'isl_basic_set_factorizer':
> ../../gcc-8-20180304/isl/isl_factorization.c:256:28: internal compiler
> error: in compute_antic_aux, at tree-ssa-pre.c:2148
>  __isl_give isl_factorizer *isl_basic_set_factorizer(
> ^~~~
> 0x11e6790 compute_antic_aux
>   ../../gcc-8-20180304/gcc/tree-ssa-pre.c:2148
> 0x11e713b compute_antic
>   ../../gcc-8-20180304/gcc/tree-ssa-pre.c:2364
> 0x11ec1b1 execute
>   ../../gcc-8-20180304/gcc/tree-ssa-pre.c:4131
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> make[5]: *** [Makefile:1463: isl_factorization.lo] Error 1
> make[5]: Leaving directory '/home/don/src/gcc-8-20180304-obj/isl'
> make[4]: *** [Makefile:1571: all-recursive] Error 1
> make[4]: Leaving directory '/home/don/src/gcc-8-20180304-obj/isl'
> make[3]: *** [Makefile:1167: all] Error 2
> make[3]: Leaving directory '/home/don/src/gcc-8-20180304-obj/isl'
> make[2]: *** [Makefile:6155: all-stage2-isl] Error 2
> make[2]: Leaving directory '/home/don/src/gcc-8-20180304-obj'
> make[1]: *** [Makefile:25157: stage2-bubble] Error 2
> make[1]: Leaving directory '/home/don/src/gcc-8-20180304-obj'
> make: *** [Makefile:947: all] Error 2

I bet this is https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84670 which is 
already
fixed.

Marek

Re: Next question: sizeof(char buf[2042])

[Marek Polacek]

On Wed, Jun 20, 2018 at 11:47:45AM -0700, Bruce Korb wrote:
> Yeah, I guess this is Clang, but is it a legal interpretation for Clang?
> 
> In file included from gnu-pw-mgr.c:24:
> 
> In file included from ./fwd.h:288:
> 
> *./seed.c:178:43: **warning: **sizeof on pointer operation will return size
> of 'const char *' instead of 'const char [2042]'*
> 
> *  [-Wsizeof-array-decay]*
> 
> char * tag = scribble_get(sizeof (tag_fmt) + strlen(OPT_ARG(TAG)));
> 
> *  ^~~*
> 
> 
> *It seems like a pretty brain damaged interpretation.*

We'd need to see the code but the warning seems legit.  What's the problem?

Marek

Re: Wabi warnings during GCC build

[Marek Polacek]

On Wed, Jun 27, 2018 at 08:53:48AM -0700, Steve Ellcey wrote:
> Are other people building GCC seeing these messages during the build:
> 
> cc1plus: warning: -Wabi won't warn about anything [-Wabi]
> cc1plus: note: -Wabi warns about differences from the most up-to-date ABI, 
> which is also used by default
> cc1plus: note: use e.g. -Wabi=11 to warn about changes from GCC 7
> 
> It doesn't seem to be causing any problems in the build (even bootstrap)
> but I am wondering why it is there.  It seems to be happening when
> using the latest (just built) g++ to build libstdc++ so it shouldn't
> be related to the system GCC that I am using to build with.
> 
> I didn't find any mention of it in the gcc or libstdc++ mailing lists
> when I looked or find any bugzilla report.

I see it too, started with r261571.
libstdc++/acinclude.m4 needs to be adjusted:
WARN_FLAGS='-Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi'
I guess to -Wabi=11?

Marek

Re: Implementing p0515 - spaceship operator

[Marek Polacek]

On Thu, Aug 30, 2018 at 08:07:05PM +0200, Jakub Jelinek wrote:
> On Thu, Jan 11, 2018 at 02:06:06PM +, Joseph Myers wrote:
> > On Thu, 11 Jan 2018, David Brown wrote:
> > 
> > > Maybe it is easier to say "gcc supports <=> in C++2a, and as an
> > > extension also supports it in C and C++ of any standard" ?  I don't
> > > believe there is any way for it to conflict with existing valid code, so
> > > it would do no harm as a gcc extension like that - and C users can then
> > > use it too.
> > 
> > As per previous IRC discussion, changing the lexing to support this 
> > pp-token can break valid code in previous standards, e.g. code 
> > concatenating <=> and >, then stringizing the result (the C++ proposal for 
> > adding this feature also notes some obscure cases where the character 
> > sequence <=> can actually occur as tokens, not just pp-tokens - 
> > "X<&Y::operator<=>" and "x+&operator<=>y" - so of course patches adding 
> > this feature should add testcases using such cases with older -std= 
> > options).
> > 
> > Changes to cpp_avoid_paste (so that preprocessed output does not put a 
> > pp-token starting with > immediately after <=) do not need to be 
> > conditional on the standard version, however.
> 
> Here is a patch that attempts to implement this (in libcpp + gcc/testsuite
> only so far).
> It needs to be parsed and handled in the C++ FE obviously, which is missing.

Thanks.

Tim, have you had any success with this, or should I (or somebody else) feel
free to take it over?

Marek

Re: GCC build error

[Marek Polacek]

On Thu, May 09, 2013 at 08:19:45PM +, Iyer, Balaji V wrote:
> Hello Everyone,
>   I am currently trying to build the GCC trunk (revision 198747) and it 
> is giving me the following error in make install for the java compiler. It 
> looks like it is not able to find a function. 
> 
> Thanks,
> 
> Balaji V. Iyer.
> 
> 
> libtool: link: /export/users/gcc-svn/b-trunk-gcc/./gcc/gcj 
> -B/export/users/gcc-svn/b-trunk-gcc/x86_64-unknown-linux-gnu/32/libjava/ 
> -B/export/users/gcc-svn/b-trunk-gcc/x86_64-unknown-linux-gnu/32/libjava/ 
> -B/export/users/gcc-svn/b-trunk-gcc/./gcc/ 
> -B/export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/bin/
>  
> -B/export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/lib/
>  -isystem 
> /export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/include
>  -isystem 
> /export/users/gcc-svn/install_dir/trunk-install/x86_64-unknown-linux-gnu/sys-include
>  -m32 -ffloat-store -fomit-frame-pointer -Usun -g -O2 -m32 -m32 -o 
> .libs/jv-convert --main=gnu.gcj.convert.Convert -shared-libgcc  
> -L/export/users/gcc-svn/b-trunk-gcc/x86_64-unknown-linux-gnu/32/libjava/.libs 
> -L/export/users/gcc-svn/b-trunk-gcc/x86_64-unknown-linux-gnu/32/libjava 
> ./.libs/libgcj.so -lpthread -ldl -lrt -Wl,-rpath 
> -Wl,/export/users/gcc-svn/install_dir/trunk-install/lib/../lib
> ./.libs/libgcj.so: undefined reference to `__cxa_throw_bad_array_length'
> collect2: error: ld returned 1 exit status
> make[5]: *** [jv-convert] Error 1

Should be already fixed by Jason.

Marek

Re: Documentation for loop header copying

[Marek Polacek]

On Fri, Jul 19, 2013 at 04:42:56PM +0200, Abdul Wahid Memon wrote:
> I am searching for some documentation (books, research papers, etc) on
> loop header copying compiler optimization.
> 
> Any hints on this please?

You may want to look at the comments in tree-ssa-loop-ch.c in the GCC
source tree.

Marek

Re: New file extension

[Marek Polacek]

On Sat, Jul 27, 2013 at 08:42:16AM -0500, Gabriel Dos Reis wrote:
> Hi,
> 
> I would like to suggest that new implementation files have
> the '.cc' extension, unless they are meant to be processed
> with a C compiler.  (I am not proposing wholesale renaming.)

Oh, I suppose this applies to ubsan, e.g.  (Haven't commited
it to trunk yet, but so far the files still have the '.c'
extension.)  Will rename it then, though I like '.c' more ;).

Marek

Re: New file extension

[Marek Polacek]

On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote:
> I do not care very much but I disagree.  Having some files with .c
> suffix and some with .cc suffix would imply some sort of difference
> where there is going to be none.

Yeah -- this sort of discrepancy I don't like either.  In gcc/, we
have 362 .c files and 0 .cc files, so every new .cc file will step out
of line...  That might be pain for people who are used to do
'grep foo gcc/*.c' and suchlike.

Marek

Re: New file extension

[Marek Polacek]

On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote:
> On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek  wrote:
> > On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote:
> >> I do not care very much but I disagree.  Having some files with .c
> >> suffix and some with .cc suffix would imply some sort of difference
> >> where there is going to be none.
> >
> > Yeah -- this sort of discrepancy I don't like either.  In gcc/, we
> > have 362 .c files and 0 .cc files, so every new .cc file will step out
> > of line...  That might be pain for people who are used to do
> > 'grep foo gcc/*.c' and suchlike.
> 
> Any issues with doing a mass rename then?

If various svn/git blame/log's would work, then I'm fine with it.
It's been discussed on gcc@ at some point; I don't remember any
major (dis)advantages.

Ok, I'll rename my new .c files to .cc.

Marek

Re: New file extension

[Marek Polacek]

On Tue, Jul 30, 2013 at 08:35:12AM -0400, Andrew MacLeod wrote:
> On 07/30/2013 08:27 AM, Marek Polacek wrote:
> >On Tue, Jul 30, 2013 at 07:13:22AM -0400, Diego Novillo wrote:
> >>On Tue, Jul 30, 2013 at 5:04 AM, Marek Polacek  wrote:
> >>>On Mon, Jul 29, 2013 at 10:08:26PM +0200, Martin Jambor wrote:
> >>>>I do not care very much but I disagree.  Having some files with .c
> >>>>suffix and some with .cc suffix would imply some sort of difference
> >>>>where there is going to be none.
> >>>Yeah -- this sort of discrepancy I don't like either.  In gcc/, we
> >>>have 362 .c files and 0 .cc files, so every new .cc file will step out
> >>>of line...  That might be pain for people who are used to do
> >>>'grep foo gcc/*.c' and suchlike.
> >>Any issues with doing a mass rename then?
> I'd suggest waiting for a mass rename until the next stage 1... (or
> stage 0.9 :-) I will want to mass rename a lot of the files (ie, a
> lot of tree-* will lose the tree- prefix), and I think we'll be
> moving directory structures around as well... and some include files
> will be split up... etc. etc.Seems like a logical time to change
> extensions too.
> 
> My point is, why go through the pain of changing a bunch of files
> now when we are probably going to do it again within a year.

On second thought, yes, waiting for mass rename sounds better than to
add one .cc file...

Marek

Re: [RFC] gcc feature request: Moving blocks into sections

[Marek Polacek]

On Mon, Aug 05, 2013 at 11:34:55AM -0700, Linus Torvalds wrote:
> On Mon, Aug 5, 2013 at 11:24 AM, Linus Torvalds
>  wrote:
> >
> > Ugh. I can see the attraction of your section thing for that case, I
> > just get the feeling that we should be able to do better somehow.
> 
> Hmm.. Quite frankly, Steven, for your use case I think you actually
> want the C goto *labels* associated with a section. Which sounds like
> it might be a cleaner syntax than making it about the basic block
> anyway.

FWIW, we also support hot/cold attributes for labels, thus e.g.

  if (bar ()) 
goto A;
  /* ... */
A: __attribute__((cold))
  /* ... */

I don't know whether that might be useful for what you want or not though...

Marek

Re: c++/linker problems maybe?

[Marek Polacek]

On Mon, Aug 05, 2013 at 10:05:22PM -0700, George R Goffe wrote:
> Hi,
> 
> I'm having trouble building or linking C++ code. Could one of you brains take 
> a peek at the enclosed and let me know where I'm goofing please?

This question is not appropriate for the mailing list gcc@gcc.gnu.org,
which is for the development of GCC.  It would be appropriate for
gcc-h...@gcc.gnu.org.  Please take any followups to gcc-help.  Thanks.

> [ 88%] Building CXX object src/CMakeFiles/k3b_bin.dir/k3bthemedlabel.cpp.o
>   
>  
> [ 88%] Building CXX object src/CMakeFiles/k3b_bin.dir/k3blsofwrapper.cpp.o
>   
>  
> [ 89%] Building CXX object 
> src/CMakeFiles/k3b_bin.dir/k3blsofwrapperdialog.cpp.o 
>     
> [ 89%] Building CXX object src/CMakeFiles/k3b_bin.dir/k3baction.cpp.o 
>   
>  
> [ 89%] Building CXX object src/CMakeFiles/k3b_bin.dir/k3bdevicemenu.cpp.o 
>   
>  
> [ 89%] Building CXX object 
> src/CMakeFiles/k3b_bin.dir/k3bviewcolumnadjuster.cpp.o
>     
> [ 90%] Building CXX object src/CMakeFiles/k3b_bin.dir/k3bmodelutils.cpp.o 
>   
>  
> Linking CXX executable k3b
> CMakeFiles/k3b_bin.dir/k3b.cpp.o: In function 
> `K3b::MainWindow::~MainWindow()':
> /tools/k3b/k3b/src/k3b.cpp:272: undefined reference to 
> `KXmlGuiWindow::~KXmlGuiWindow(void const**)'
> CMakeFiles/k3b_bin.dir/k3b.cpp.o: In function `K3b::MainWindow::MainWindow()':
> /tools/k3b/k3b/src/k3b.cpp:227: undefined reference to 
> `KXmlGuiWindow::KXmlGuiWindow(void const**, QWidget*, QFlags)'
> CMakeFiles/k3b_bin.dir/k3b.cpp.o: In function `K3b::MainWindow::MainWindow()':
> /tools/k3b/k3b/src/k3b.cpp:227: undefined reference to 
> `KXmlGuiWindow::KXmlGuiWindow(void const**, QWidget*, QFlags)'
> CMakeFiles/k3b_bin.dir/k3b.cpp.o: In function 
> `K3b::MainWindow::~MainWindow()':
> /tools/k3b/k3b/src/k3b.cpp:272: undefined reference to 
> `KXmlGuiWindow::~KXmlGuiWindow(void const**)'
> collect2: error: ld returned 1 exit status
> make[2]: *** [src/k3b] Error 1
> make[1]: *** [src/CMakeFiles/k3b_bin.dir/all] Error 2
> make: *** [all] Error 2

It just seems the library containing the definition of 
KXmlGuiWindow::KXmlGuiWindow isn't properly linked in.

Marek

Re: GNU Toolchain on Google+ and Twitter

[Marek Polacek]

On Tue, Sep 24, 2013 at 11:33:31AM -0400, David Edelsohn wrote:
> I have established Google+ and Twitter pages for the GNU Toolchain
> (GCC, Binutils, GDB) as additional, un-official communication channels
> for announcements and highlights of interesting mailing list
> discussions.
> 
> https://plus.google.com/108467477471815191158
> 
> https://twitter.com/gnutools
> 
> Anyone interested is welcome to follow.

I'm finding the twitter account to be really useful and the number of
followers is steadily increasing -- so thanks for doing that.  It's a
good thing to have.

Marek

Re: [RFC] Detect most integer overflows.

[Marek Polacek]

Or just wait till the integer overflow detection in ubsan is completed.

Marek

Re: Switch statement case range

[Marek Polacek]

On Sun, Apr 08, 2012 at 08:59:46AM -0700, Rick Hodgin wrote:
> What are the possibilities of adding a GCC extension to allow:
> 
> switch (foo) {
> case 1:
> case 2:
> case 3 to 8:
> case 9:
> default:
> }

This already exists (and is a GNU extension):

  switch (foo)
{
case 1:
  break;
case 3 ... 8:
  break;
default:
  break;
}

Marek

Re: Switching to C++ by default in 4.8

[Marek Polacek]

On Tue, Apr 10, 2012 at 10:54:01AM -0700, Xinliang David Li wrote:
> manipulation -- be it C or C++. However I think this is really more
> about the general perceptions and how future developers feel about it.

If GCC would ever be in C++, that would be a very strong argument for
me _not_ to touch it.

Marek

Re: New mklog script

[Marek Polacek via Gcc]

On Fri, May 15, 2020 at 10:59:56AM +0200, Martin Liška wrote:
> Hi.
> 
> Since we moved to git world and we're in the preparation for ChangeLog 
> messages
> being in git commit messages, I think it's the right time to also simplify 
> mklog
> script.
> 
> I'm sending a new version (which should eventually replace contrib/mklog and 
> contrib/mklog.pl).
> Changes made in the version:
> 
> - the script uses unifdiff - it rapidly simplifies parsing of the '+-!' lines 
> that is done
>   in contrib/mklog

Nice!

> - no author nor date stamp is used - that all can be get from git

This is good.

> - --inline option is not supported - I don't see a use-case for it now

I actually use mklog -i all the time.  But I can work around it if it
disappears.

--
Marek Polacek • Red Hat, Inc. • 300 A St, Boston, MA

Re: New mklog script

[Marek Polacek via Gcc]

On Fri, May 15, 2020 at 03:12:27PM +0200, Martin Liška wrote:
> On 5/15/20 2:42 PM, Marek Polacek wrote:
> > I actually use mklog -i all the time.  But I can work around it if it
> > disappears.
> 
> Ah, I can see a consumer.
> There's an updated version that supports that.
> 
> For the future, will you still use the option? Wouldn't be better
> to put the ChangeLog content directly to commit message? Note
> that you won't have to copy the entries to a particular ChangeLog file.

The way I do it is to generate a patch using format-patch, use mklog -i
on it, then add the ChangeLog entry to the commit message via commit --amend.

Anything that has to do with ChangeLogs is pointless make-work, so the less
I have to do, the better.  ;-)

Marek

Re: ERR: file not changed in a patch:"gcc/cp/cp-tree.c"

[Marek Polacek via Gcc]

On Tue, May 19, 2020 at 01:03:09PM -0600, Martin Sebor via Gcc wrote:
> I'm having trouble with the commit hook that tries to enforce
> ChangeLog contents.  It fails with an error that doesn't make
> sense to me: the file it complains isn't mentioned clearly is
> listed there and I can't tell what about how it's mentioned
> the hook is having a problem with.
> 
> Thanks
> Martin
> 
> $ git push
> Enumerating objects: 23, done.
> Counting objects: 100% (23/23), done.
> Delta compression using up to 16 threads
> Compressing objects: 100% (12/12), done.
> Writing objects: 100% (12/12), 2.41 KiB | 2.41 MiB/s, done.
> Total 12 (delta 11), reused 0 (delta 0)
> remote: *** ChangeLog format failed:
> remote: ERR: file not changed in a patch:"gcc/cp/cp-tree.c"
> remote: ERR: changed file not mentioned in a ChangeLog:"gcc/cp/tree.c"
> remote:
> remote: Please see: https://gcc.gnu.org/codingconventions.html#ChangeLogs
> remote:
> remote: error: hook declined to update refs/heads/master
> To git+ssh://gcc.gnu.org/git/gcc.git
>  ! [remote rejected] master -> master (hook declined)
> error: failed to push some refs to
> 'git+ssh://mse...@gcc.gnu.org/git/gcc.git'
> 
> $ head gcc/cp/ChangeLog
> 2020-05-18  Martin Sebor  
> 
>   PR c++/94923
>   * call.c ((maybe_warn_class_memaccess): Use is_byte_access_type.
>   * cp-tree.h (is_dummy_object): Return bool.
>   (is_byte_access_type): Declare new function.
>   * cp-tree.c (is_dummy_object): Return bool.

There's no cp/cp-tree.c; does it work with just "tree.c" in the ChangeLog?

Re: [IMPORTANT] ChangeLog related changes

[Marek Polacek via Gcc]

On Wed, Jun 10, 2020 at 01:34:54PM +, Tamar Christina wrote:
> Hi All,
> 
> We've been wondering since we no longer list authors in the changelog (at 
> least mklog doesn't generate it),
> How do we handle multi author patches nowadays?
> 
> Tried searching for it on the website but couldn’t find anything.

You can add Co-authored-by: name  to your commit.

If we don't already document it, we should.

Marek

Re: gcc __attribute__

[Marek Polacek via Gcc]

On Thu, Aug 06, 2020 at 04:15:10PM +0100, Philip R Brenan via Gcc wrote:
> Hi *GCC*:
> 
> On page:
> 
> https://gcc.gnu.org/onlinedocs/gcc-3.2/gcc/Function-Attributes.html
> 
> you show the attribute coming after the parameter list.  But when I try
> this, I  get the following:

That manual is for version 3.2, which is ancient.  See
https://gcc.gnu.org/onlinedocs/gcc-10.2.0/gcc/Attribute-Syntax.html#Attribute-Syntax

Marek

Re: is there a reason why "explicit specialization in non-namespace scope" is still an error in gcc-trunk?

[Marek Polacek via Gcc]

On Wed, Sep 23, 2020 at 02:42:01PM +0200, Dennis Luehring wrote:
> i've read that scoped template specalization is allowed in C++17
> 
> 
> clang supports it starting with release 7
> 
> MSVC supports it with VS2017(i don't know what revision)
> 
> Intel does not like it

Because CWG 727 isn't implemented yet:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85282

Marek

Re: What is pex_run

[Marek Polacek via Gcc]

On Thu, Feb 25, 2021 at 09:57:55PM +, Gary Oblock via Gcc wrote:
> I've got collect2 finding a linker error and I'm out of
> other options so I'm poking around in the collect2
> sources. I'm wondering what pex_run is (since it's
> getting handed the arguments this might mater?)

See libiberty/pex-common.c.

Marek

Re: Remove RMS from the GCC Steering Committee

[Marek Polacek via Gcc]

On Fri, Mar 26, 2021 at 04:02:30PM -0400, Nathan Sidwell wrote:
> [double sigh, attaching a pdf causes it to be blocked, and I guess the
> number of URLs is also triggering a spam trap for the follow up.  I have
> removed many of the URLS from this, you'll have to use your google-fu for
> sources.  I emailed several members of the SC, and don't want to bomb them
> with yet a third copy. ]
> 
> Dear members of the GCC Steering Committee (SC),  I ask you to remove
> Richard Stallman (RMS) from the SC, or, should you chose not to do so, make
> a clear statement as to why he remains.

[...]

> I am writing this publicly, as it is important we address the issue. In
> 2019, when RMS resigned from the FSF, I asked the SC about his status on the
> SC (the web site continued to list his affiliation as FSF).  I never saw as
> response. I failed to follow up. (FWIW, I never received a response to a
> technical licensing issue I asked in 2020. Something seems amiss.)
> In the alternative, I want you to make a definitive statement about why you
> choose not to make such a change.  Do not hide behind silence.  Silence is
> agreeing with the status quo.  Further, if you choose not to make a change,
> do not hide behind a technicality. (My understanding is that RMS has veto
> power.) The rules of the SC are not immutable laws of the universe, nor does
> humanity have immutable laws cast in stone.  The EGCS project showed that we
> can make changes with GCC’s social organization.  If we fail to do so, it
> will continue to be harder and harder to attract new talent to GCC
> development.

I support this and believe we ought to act now.

Marek

Re: help debug hash_map garbage collection issue

[Marek Polacek via Gcc]

On Tue, Apr 20, 2021 at 02:03:00PM -0600, Martin Sebor via Gcc wrote:
> I have a static hash_map object that needs to persist across passes:
> 
>   static GTY(()) hash_map *map;
> 
> I initialize the map like so:
> 
>   map = hash_map::create_ggc (4);
> 
> But I see crashes when accessing the map after adding and removing
> some number of entries in a few passes.  The crashes are due to
> the map having been garbage-collected and the memory allocated to
> it poisoned (it has the 0xa5a5a5a5a5a5a5a5 bit pattern that I see
> in GDD being written into the map by poison_pages()).
> 
> I assumed marking the map pointer GTY(()) would keep the garbage
> collector from touching the map.  Is there something else I need
> to do to keep it from doing that?
> 
> Thanks
> Martin
> 
> PS Just in case it matters, the bitmap in the table is allocated
> via BITMAP_ALLOC() with a bitmap_obstack variable defined alongside
> the map.

My sense is that this is the problem.  What happens if you use
BITMAP_GGC_ALLOC?

Marek

Re: where is PRnnnn required again?

[Marek Polacek via Gcc]

On Tue, Jul 06, 2021 at 03:20:26PM -0600, Martin Sebor via Gcc wrote:
> I came away from the recent discussion of ChangeLogs requirements
> with the impression that the PR bit should be in the subject
> (first) line and also above the ChangeLog part but doesn't need
> to be repeated again in the ChangeLog entries.  But my commit
> below was rejected last Friday with the subsequent error.  Adding
> PR middle-end/98871 to the ChangeLog entry let me push the change:
> 
> https://gcc.gnu.org/g:6feb628a706e86eb3f303aff388c74bdb29e7381
> 
> I just had the same error happen now, again with what seems like
> a valid commit message.  Did I misunderstand something or has
> something changed recently?
> 
> Martin
> 
> commit 8a6d08bb49c2b9585c2a2adbb3121f6d9347b780 (HEAD -> master)
> Author: Martin Sebor 
> Date:   Fri Jul 2 16:16:31 2021 -0600
> 
> Improve warning suppression for inlined functions [PR98512].
> 
> Resolves:
> PR middle-end/98871 - Cannot silence -Wmaybe-uninitialized at
> declaration si
> te
> PR middle-end/98512 - #pragma GCC diagnostic ignored ineffective in
> conjunct
> ion with alias attribute

This should be just

PR middle-end/98871
PR middle-end/98512

, no?  Either here, or...

> gcc/ChangeLog:

...here.
 
> * diagnostic.c (get_any_inlining_info): New.
> (update_effective_level_from_pragmas): Handle inlining context.
> (diagnostic_enabled): Same.
> (diagnostic_report_diagnostic): Same.
> * diagnostic.h (struct diagnostic_info): Add ctor.
> (struct diagnostic_context): Add new member.
> * tree-diagnostic.c (set_inlining_locations): New.
> (tree_diagnostics_defaults): Set new callback pointer.
> 
> 
> 
> Enumerating objects: 11, done.
> Counting objects: 100% (11/11), done.
> Delta compression using up to 16 threads
> Compressing objects: 100% (6/6), done.
> Writing objects: 100% (6/6), 3.37 KiB | 3.37 MiB/s, done.
> Total 6 (delta 5), reused 0 (delta 0)
> remote: *** The following commit was rejected by your
> hooks.commit-extra-checker script (status: 1)
> remote: *** commit: 8a6d08bb49c2b9585c2a2adbb3121f6d9347b780
> remote: *** ChangeLog format failed:
> remote: *** ERR: PR 98512 in subject but not in changelog: "Improve warning
> suppression for inlined functions [PR98512]."
> remote: ***
> remote: *** Please see:
> https://gcc.gnu.org/codingconventions.html#ChangeLogs
> remote: ***
> remote: error: hook declined to update refs/heads/master
> To git+ssh://gcc.gnu.org/git/gcc.git
>  ! [remote rejected] master -> master (hook declined)
> error: failed to push some refs to
> 'git+ssh://mse...@gcc.gnu.org/git/gcc.git'
> 

Marek

Re: where is PRnnnn required again?

[Marek Polacek via Gcc]

On Wed, Jul 07, 2021 at 03:35:35PM -0600, Martin Sebor wrote:
> On 7/7/21 2:42 PM, Jonathan Wakely wrote:
> > 
> > 
> > On Wed, 7 Jul 2021, 17:39 Martin Sebor,  > <mailto:mse...@gmail.com>> wrote:
> > 
> > On 7/6/21 4:09 PM, Jonathan Wakely wrote:
> >  >
> >  >
> >  > On Tue, 6 Jul 2021, 22:45 Martin Sebor via Gcc,  > <mailto:gcc@gcc.gnu.org>
> >  > <mailto:gcc@gcc.gnu.org <mailto:gcc@gcc.gnu.org>>> wrote:
> >  >
> >  >     On 7/6/21 3:36 PM, Marek Polacek wrote:
> >  >      > On Tue, Jul 06, 2021 at 03:20:26PM -0600, Martin Sebor via
> > Gcc wrote:
> >  >      >> I came away from the recent discussion of ChangeLogs
> > requirements
> >  >      >> with the impression that the PR bit should be in the
> > subject
> >  >      >> (first) line and also above the ChangeLog part but
> > doesn't need
> >  >      >> to be repeated again in the ChangeLog entries.  But my commit
> >  >      >> below was rejected last Friday with the subsequent
> > error.  Adding
> >  >      >> PR middle-end/98871 to the ChangeLog entry let me push
> > the change:
> >  >      >>
> >  >      >>
> > https://gcc.gnu.org/g:6feb628a706e86eb3f303aff388c74bdb29e7381
> >  >      >>
> >  >      >> I just had the same error happen now, again with what
> > seems like
> >  >      >> a valid commit message.  Did I misunderstand something or has
> >  >      >> something changed recently?
> >  >      >>
> >  >      >> Martin
> >  >      >>
> >  >      >> commit 8a6d08bb49c2b9585c2a2adbb3121f6d9347b780 (HEAD ->
> > master)
> >  >      >> Author: Martin Sebor  > <mailto:mse...@redhat.com> <mailto:mse...@redhat.com
> > <mailto:mse...@redhat.com>>>
> >  >      >> Date:   Fri Jul 2 16:16:31 2021 -0600
> >  >      >>
> >  >      >>      Improve warning suppression for inlined functions
> > [PR98512].
> >  >      >>
> >  >      >>      Resolves:
> >  >      >>      PR middle-end/98871 - Cannot silence
> > -Wmaybe-uninitialized at
> >  >      >> declaration si
> >  >      >> te
> >  >      >>      PR middle-end/98512 - #pragma GCC diagnostic ignored
> >  >     ineffective in
> >  >      >> conjunct
> >  >      >> ion with alias attribute
> >  >      >
> >  >      > This should be just
> >  >      >
> >  >      >       PR middle-end/98871
> >  >      >       PR middle-end/98512
> >  >      >
> >  >      > , no?
> >  >
> >  >     Does it matter if there's text after the PR ...?
> >  >
> >  >
> >  >
> >  > Yes. With extra text the whole line is just treated as arbitrary
> > text,
> >  > not a "PR component/" string. So with the extra text it won't be
> >  > added to the ChangeLog file, and won't match the PR in the
> > subject line.
> >  >
> >  >        I managed to push
> >  >
> >  > https://gcc.gnu.org/pipermail/gcc-cvs/2021-July/350316.html
> >  >
> >  >     that uses the same style earlier today
> >  >
> >  >
> >  > But will it add the PR numbers to the ChangeLog? I think the
> > answer is
> >  > no (in which case you could edit the ChangeLog tomorrow if you
> > want them
> >  > to be in there).
> > 
> > It updated Bugzilla but it didn't add the PR numbers to the ChangeLog
> > entries.  I still don't (obviously) understand the rules the hook uses
> > for what to update or the rationale for them.  It seems as though
> > the PR in the subject is used to update only Bugzilla but not also
> > update the ChangeLogs (why not?)
> > 
> > 
> > Because they are two completely separate processes. Verifying the commit
> > message format is done by a git hook, and you can run exactly the same
> > checks locally before pushing a commit.
> > 
> > Updating bugzilla is done by a separat

Re: How to run C++ IPA tests?

[Marek Polacek via Gcc]

On Wed, Oct 27, 2021 at 04:29:32PM +0200, Erick Ochoa via Gcc wrote:
> Hi,
> 
> I have been adding tests to the gcc/testsuite/gcc.dg/ipa folder
> successfully for a while now. I am starting to add some tests into
> gcc/testsuite/g++.dg/ipa now but I am having some issues.
> 
> 1. Using `make check-g++` returns the following error message "No rule
> to make target 'check-g++'".
> 2. While `make check-gcc` works, this seems to be only for C tests
> (which is correct).
> 3. When I type `make check RUNTESTS="ipa.exp"`  but the section "g++
> Summary" looks empty.
> 4. I have added a test that I know will fail, but I don't see it
> (because I don't think I have run g++ tests correctly).
> 
> To make sure that I haven't changed anything with my transformation I
> actually checked out releases/gcc-11.2.0
> 
> Can someone tell me how to run the C++ IPA tests? I'm sure there is
> something silly that I'm doing wrong, but can't find out what it is.

There's no ipa.exp in gcc/testsuite/g++.dg/ipa.  Instead you probably
want

make check-c++ RUNTESTFLAGS=dg.exp=ipa/*

Marek

Re: What replaces FOR_EACH_LOOP_FN

[Marek Polacek via Gcc]

On Wed, Mar 02, 2022 at 10:04:40PM +, Gary Oblock via Gcc wrote:
> Guys,
> 
> I've been working on an optimization for quite a bit of time and
> in an attempt to move it to GCC 12 I found that FOR_EACH_LOOP_FN
> no longer exists. I poked around in the archives and tried a Google
> search but found nothing on it.
> 
> It suited my needs and I'd hate to have to rewrite a bunch of stuff.
> What replaces it and how do I use?

Look at this commit:

commit e41ba804ba5f5ca433e09238d561b1b4c8b10985
Author: Kewen Lin 
Date:   Thu Jul 29 22:26:25 2021 -0500

Use range-based for loops for traversing loops

This patch follows Martin's suggestion here[1], to support
range based loop for iterating loops, analogously to the
patch for vec[2].

For example, use below range-based for loop

for (auto loop : loops_list (cfun, 0))

to replace the previous macro FOR_EACH_LOOP

FOR_EACH_LOOP (loop, 0)

which shows a number of examples like

-  loop_p loop;
-  FOR_EACH_LOOP_FN (fn, loop, LI_INCLUDE_ROOT)
+  for (auto loop : loops_list (fn, LI_INCLUDE_ROOT))

Marek

Re: passing command-line arguments, still

[Marek Polacek via Gcc]

On Wed, Mar 16, 2022 at 02:34:09PM -0400, James K. Lowden wrote:
> [I sent this to gcc-help by mistake. I'm reposting it here in case
> anyone has a suggestion. I did take dje's advice, and deleted the build
> directory, except that I preserved config.status and regenerated
> Makefile.  The observed behavior remains unchanged.  TIA.]
> 
> https://git.symas.net:443/cobolworx/gcc-cobol/
> 
> My first question regards command-line options.  I've had no trouble
> defining switches (-f-foo), but no luck defining an option that takes
> an argument.  The latter are accepted by gcobol and not passed to
> cobol1.  

Let's avoid -f-foo; use -ffoo instead, like the rest of GCC.
 
> In cobol/lang.opt, I have:
> 
> indicator-column

Make this 'findicator-column='.  Does that help?

> Cobol Joined Separate UInteger Var(indicator_column) Init(0)
> IntegerRange(0, 8) -indicator-column=  Column after which
> Region B begins
> 
> strace(1) shows the problem:
> 
> [pid 683008] execve("../../../build/gcc/gcobol",
> ["../../../build/gcc/gcobol", "-main", "-o", "obj/SG105A", "-B",
> "../../../build/gcc/", "-f-flex-debug", "-f-yacc-debug",
> "-indicator-column", "1", "cbl/SG105A.cbl", "-lgcobol", "-lm", "-ldl"],
> 0x55a19b487940 /* 36 vars */ 
> 
> gcobol is being invoked with 3 options used by cobol1:
>   "-f-flex-debug", "-f-yacc-debug", "-indicator-column", "1"
> 
> where -indicator-column takes an argument, "1".  But it's not  passed to
> cobol1: 
> 
> [pid 683008] <... execve resumed>)  = 0
> [pid 683009] execve("../../../build/gcc/cobol1",
> ["../../../build/gcc/cobol1", "cbl/SG105A.cbl", "-quiet", "-dumpbase",
> "SG105A.cbl", "-main", "-mtune=generic", "-march=x86-64", "-auxbase",
> "SG105A", "-f-flex-debug", "-f-yacc-debug", "-o", "/tmp/ccIBQZv1.s"],
> 0x1578290 /* 40 vars */ 
> 
> The stanza in cobol/lang.opt looks similar to others in
> fortran/lang.opt. The gcc internals don't mention anything else that I
> could find that needs to be done.  I've done a complete rebuild after
> "make distclean".  And still no joy.

doc/options.texi describes options relative well, I think.
 
> We are working with a gcc fork of 10.2.  Our log message says (in part):
> 
> The "tiny" branch was started with the 10.2.1
> origin/releases/gcc-10 branch> c806314b32987096d79de21e72dc0cf783e51d57)
> 
> What am I missing, please?
> 
> --jkl
> 

Marek