[Bug c++/41723] New: Error when using a qualified name to declare a nested template instantiation as a friend of the containing template

2009-10-15 Thread evaned at gmail dot com
The following code complies with GCC 4.3.0-2 and presumably older versions
(also tested with 3.4), but fails under GCC 4.4.0:

  template
  class C {
template  class D {};

friend class C::D;
  };

The message it outputs is:
  $ /s/gcc-4.4.0/bin/g++ test.cc
  test.cc:5: error: ‘typename C::D’ names ‘template template class C::D’, which is not a type

Here is compiler information (though it also failed under what IIRC is a Mingw
build of 4.5 experimental so I doubt this matters):

  $ /s/gcc-4.4.0/bin/g++ -v
  Reading specs from /../lib/gcc/i686-pc-linux-gnu/4.4.0/specs
  Target: i686-pc-linux-gnu
  Configured with: ../gcc-4.4.0/configure --prefix=/s/gcc-4.4.0/i386_rhel5
--enable-shared --enable-threads --with-pic --enable-languages=c,c++,fortran
--with-gmp=/s/gmp-4.3.0/ --with-mpfr=/s/mpfr-2.4.1/
--with-mpfr-include=/s/mpfr-2.4.1/include --with-mpfr-lib=/s/mpfr-2.4.1/lib
  Thread model: posix
  gcc version 4.4.0 (GCC) 


Things that allow the example to compile:

1. Remove the qualification (change 'C::D' to just 'D')
2. Make D not a template
3. Make C not a template


I can't say definitively that this is a bug and not just a change within an
ambiguity of the C++ standard (or even fixing a bug that used to permit illegal
code), but older versions of GCC, Intel CC 11, and Comeau's "try it out" online
thing all accept that snippet. However, it does have an easy fix, so even
though I encountered this issue in production code, it's not a big deal.


-- 
   Summary: Error when using a qualified name to declare a nested
template instantiation as a friend of the containing
template
   Product: gcc
   Version: 4.4.0
Status: UNCONFIRMED
  Severity: minor
  Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: evaned at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41723



[Bug c++/41723] Error when using a qualified name to declare a nested template instantiation as a friend of the containing template

2009-10-15 Thread evaned at gmail dot com


--- Comment #1 from evaned at gmail dot com  2009-10-15 23:10 ---
Created an attachment (id=18804)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18804&action=view)
The broken code


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41723



[Bug driver/118636] New: `-Werror` and `-w` do not affect linker warnings, but the docs say they should [docs bug?]

2025-01-23 Thread evaned at gmail dot com via Gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118636

Bug ID: 118636
   Summary: `-Werror` and `-w` do not affect linker warnings, but
the docs say they should [docs bug?]
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: driver
  Assignee: unassigned at gcc dot gnu.org
  Reporter: evaned at gmail dot com
  Target Milestone: ---

[Detailed information, including the input file, are at the end of the report.]

This could be considered either a behavior bug or a documentation bug. There
wasn't a Docs component to select and the bug writing guidelines don't provide
info on filing documentation bugs, so please excuse if this isn't quite the
format you want for that.

I discovered during an online discussion that `-Werror` does not affect linker
warnings:

/tmp$ gcc -Werror linker-warning.c -o linker-warning
/usr/bin/ld: warning: /tmp/cciBYjrB.o: requires executable stack (because
the .note.GNU-stack section is executable)

/tmp$ echo $?
0
/tmp$ ./linker-warning 
/tmp$ 

Should it? According to the documentation, yes.

There's a corresponding problem where `-w` does not suppress linker warnings,
even though the documentation says it should.


I'll argue that the docs do in fact say that `-Werror` should fail a
compilation when the linker warns, discuss if this is a behavior that should be
changed, propose doc changes, and then provide the detailed info about my
environment.


THE DOCS SAY IT SHOULD WORK
===
Here's what the docs say the flags should do:

-w
Inhibit all warning messages.
-Werror
Make all warnings into errors.

Emphasis on the word "all", and lack of any mention that linker warnings are
not included.

Maybe the section they are in has that qualification? Let's see:

3.9 Options to Request or Suppress Warnings

Warnings are diagnostic messages that report constructions that
are not inherently erroneous but that are risky or suggest there
may have been an error.

The following language-independent options do not enable specific
warnings but control the kinds of diagnostics produced by GCC.

I would say not really.

"Produced by GCC" is moving in that direction, but at best it's ambiguous. You
could read it as appling to just the compiler proper, but this has two
problems. First, I feel that this interpretation is one of those things where a
prerequisite to understanding something is to already understand it. Second,
and worse, is that the very first sentence of the "description" of GCC in the
manpage is "When you invoke GCC, it normally does preprocessing, compilation,
assembly and linking." But if "GCC" is supposed to refer to the compiler
proper, clearly the description of what GCC *is* is incorrect.

Further, even if the section intro had such a clarification, I think the
documentation would still be quite poor on this point, and not reflective of
how people most use reference docs like manpages, which is to search for the
specific thing of interest.

Ironically enough, I *was* going to say the following:

The closest thing to an unambiguous statement that `-Werror`
refers to just compiler warnings is if you note that it is part of
the output of `--help=warnings`, the behavior of which is
described as "Display all of the options controlling warning
messages produced by the compiler," with emphasis on "by the
compiler."

... but THAT IS WRONG! `-Werror` is actually NOT included in that output!
(Another bug?)

I feel quite confident in claiming that the documentation says that `-Werror`
should affect linker warnings.


DOC OR BEHAVIOR BUG?

This bug could be viewed in a couple of ways.

The first is a behavior bug, where the GCC driver should pass
`--fatal-warnings` to the linker. I think there are some obvious attractions to
this change, and it should be considered.

That said, I don't know how universal that flag is. I checked ld.bfd, ld.gold,
lld, and mold and all support that flag, so maybe it's universal enough (or any
remaining problems can be papered over in the linker script), but I don't say
that with confidence.

Potentially a bigger problem is that while `-Werror` would be improved, it
introduces a gulf with some other warning flags. I mentioned how `-w` doesn't
suppress linker warnings, but I don't see an analogue to `-w` for the linker
that the driver could pass; just a bunch of individual no-warning flags that
vary by linker and linker version. And of course the GCC driver allows
controlling compiler warnings with `-Wnonnull` or whatever, and I have
layperson concerns about if GCC could similarly control linker warnings; and
assuming those concerns are wel