public inbox for overseers@sourceware.org
 help / color / mirror / Atom feed
* Creating an account to report gcc bug
@ 2017-04-03  1:45 Gregory Nisbet
  0 siblings, 0 replies; only message in thread
From: Gregory Nisbet @ 2017-04-03  1:45 UTC (permalink / raw)
  To: overseers

Hi everyone,

I'd like to report a GCC bug affecting version 6.3.0 on OS X, as
distributed by macports. I do not believe it to be a packaging-related
problem.

I do not have an account. New account creation seems to be disabled.
I'd like to create one, but if I did it would only be to report
this bug.

Here's the output of gcc -v

    % gcc -v
    Using built-in specs.
    COLLECT_GCC=gcc
    COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin16/6.3.0/lto-wrapper
    Target: x86_64-apple-darwin16
    Configured with:
/opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc6/gcc6/work/gcc-6.3.0/configure
--prefix=/opt/local --build=x86_64-apple-darwin16
--enable-languages=c,c++,objc,obj-c++,lto,fortran
--libdir=/opt/local/lib/gcc6 --includedir=/opt/local/include/gcc6
--infodir=/opt/local/share/info --mandir=/opt/local/share/man
--datarootdir=/opt/local/share/gcc-6 --with-local-prefix=/opt/local
--with-system-zlib --disable-nls --program-suffix=-mp-6
--with-gxx-include-dir=/opt/local/include/gcc6/c++/
--with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local
--with-isl=/opt/local --enable-stage1-checking --disable-multilib
--enable-lto --enable-libstdcxx-time
--with-build-config=bootstrap-debug --with-as=/opt/local/bin/as
--with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar
--with-bugurl=https://trac.macports.org/newticket
--with-pkgversion='MacPorts gcc6 6.3.0_2'
    Thread model: posix
    gcc version 6.3.0 (MacPorts gcc6 6.3.0_2)

Here are the SHA-256s of the gcc and g++ executables exhibiting the
problematic behavior.

    % shasum -a 256 `which gcc`
    5678eb76461ff32f23d24b92b1f2222722fca506f8b3c593a4783c839e4ff179
/opt/local/bin/gcc

    % shasum -a 256 `which g++`
    a8411548475c707d9e7e9c1f24aa21687be4621e98c27137082bae0323c510d4
/opt/local/bin/g++

Here are the two files involved in the issue.

    numlike.hpp

    template <class T> struct Numlike {
      class type {
      private:
        T t;

      public:
        type() { this->t = T(); }
        T value() { return this->t; }
      };
    };

and the other file,

    numlike_test.cc

    #include "numlike.hpp"
    #include <cstdio>

    int main() {
      Numlike<int>::type hi;
      printf("%d\n", hi.value());
    }

The order of the includes is important here. If those two files are
included in a directory as is, then attempting to compile with `g++
numlike_test.cc` produces a few spurious fatal errors.


    % g++ numlike_test.cc
    numlike_test.cc: In function 'int main()':
    numlike_test.cc:5:3: error: 'Numlike' is not a template
       Numlike<int>::type hi;
       ^~~~~~~
    numlike_test.cc:5:22: error: qualified-id in declaration before 'hi'
       Numlike<int>::type hi;
                          ^~
    numlike_test.cc:6:18: error: 'hi' was not declared in this scope
       printf("%d\n", hi.value());
                      ^~
    Exit 1

`g++ -std=gnu++14 numlike_test.cc`, unsurprisingly, emits the same
error, however these all compiled without error and produce no
output.

    % g++ --std=gnu++17 numlike_test.cc
    % g++ --std=gnu++11 numlike_test.cc
    % g++ --std=c++17 numlike_test.cc
    % g++ --std=c++14 numlike_test.cc
    % g++ --std=c++11 numlike_test.cc
    % g++ --std=c++98 numlike_test.cc

Interestingly, running the preprocessor separately is enough
to prevent the expression of this bug.

    runs without error
    % gcc -E numlike_test.cc | g++ -x c++ --std=gnu++14 -

    this also runs without error
    % gcc -E numlike_test.cc > /tmp/a.cc ; g++ /tmp/a.cc

Reordering the includes in numlike_test.cc so
cstdio is included first also prevents the expression of the bug.

i.e. if numlike_test.cc is replaced with this, then the bug does
not occur.

    #include <cstdio>
    #include "numlike.hpp"

    int main() {
      Numlike<int>::type hi;
      printf("%d\n", hi.value());
    }

I don't know enough to try to fix this on my own and submit a patch,
but I would be more than happy to provide you with additional
information if necessary.

Thanks,
Gregory

P.S. Shar with file contents.

# This is a shell archive.  Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file".  Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# numlike.hpp
# numlike_test.cc
#
echo x - numlike.hpp
sed 's/^X//' >numlike.hpp << 'END-of-numlike.hpp'
Xtemplate <class T> struct Numlike {
X  class type {
X  private:
X    T t;
X
X  public:
X    type() { this->t = T(); }
X    T value() { return this->t; }
X  };
X};
END-of-numlike.hpp
echo x - numlike_test.cc
sed 's/^X//' >numlike_test.cc << 'END-of-numlike_test.cc'
X#include "numlike.hpp"
X#include <cstdio>
X
Xint main() {
X  Numlike<int>::type hi;
X  printf("%d\n", hi.value());
X}
END-of-numlike_test.cc
exit

^ permalink raw reply	[flat|nested] only message in thread

only message in thread, other threads:[~2017-04-03  1:45 UTC | newest]

Thread overview: (only message) (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-04-03  1:45 Creating an account to report gcc bug Gregory Nisbet

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).