from:"m101010a at gmail dot com"

[Bug c++/56671] New: Gcc uses large amounts of memory and processor power with large C++11 bitsets

2013-03-20 Thread m101010a at gmail dot com



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



 Bug #: 56671

   Summary: Gcc uses large amounts of memory and processor power

with large C++11 bitsets

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: m1010...@gmail.com





When I attempt to instantiate std::bitset<1024*1024*1024> in C++98 mode,

compilation takes a quarter-second and uses almost no RAM.  In C++11 mode, it

takes 8 seconds and almost 2GB of RAM.  The time and memory usage appear to

scale linearly with the size of the bitset.  No errors or warnings are reported

in either mode.



Full code:

#include 

int main()

{

std::bitset<1024*1024*1024> bs;

}



Compilation lines:

g++ -std=c++98 x.cpp

g++ -std=c++11 x.cpp



g++ -v:

Using built-in specs.

COLLECT_GCC=g++

COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: /build/src/gcc-4.7.2/configure --prefix=/usr --libdir=/usr/lib

--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info

--with-bugurl=https://bugs.archlinux.org/

--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared

--enable-threads=posix --with-system-zlib --enable-__cxa_atexit

--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch

--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id

--with-ppl --enable-cloog-backend=isl --disable-ppl-version-check

--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default

--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu

--enable-multilib --disable-libssp --disable-build-with-cxx

--disable-build-poststage1-with-cxx --enable-checking=release

Thread model: posix

gcc version 4.7.2 (GCC)

[Bug c++/54431] New: [C++11] g++ crashes when compiling the following file

2012-08-30 Thread m101010a at gmail dot com

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

 Bug #: 54431
   Summary: [C++11] g++ crashes when compiling the following file
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m1010...@gmail.com


$ cat y.cpp
template 
struct foo
{
public:
void bar()
{
[this]{bar();}();
}
};

int main()
{
foo ss;
ss.bar();
}
$ g++ -v -save-temps -std=c++11 y.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.7-20120721/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id
--with-ppl --enable-cloog-backend=isl --disable-ppl-version-check
--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default
--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu
--enable-multilib --disable-libssp --disable-build-with-cxx
--disable-build-poststage1-with-cxx --enable-checking=release
Thread model: posix
gcc version 4.7.1 20120721 (prerelease) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/cc1plus -E -quiet -v -D_GNU_SOURCE
y.cpp -mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess -o y.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1

/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/x86_64-unknown-linux-gnu

/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/backward
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/cc1plus -fpreprocessed y.ii -quiet
-dumpbase y.cpp -mtune=generic -march=x86-64 -auxbase y -std=c++11 -version -o
y.s
GNU C++ (GCC) version 4.7.1 20120721 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.1 20120721 (prerelease), GMP version 5.0.5,
MPFR version 3.1.1, MPC version 1.0
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.7.1 20120721 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.1 20120721 (prerelease), GMP version 5.0.5,
MPFR version 3.1.1, MPC version 1.0
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 8466381cd327359656bc3ec3a9c33398
y.cpp: In lambda function:
y.cpp:15:1: internal compiler error: in get_expr_operands, at
tree-ssa-operands.c:1035
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$ cat y.ii
# 1 "y.cpp"
# 1 ""
# 1 "y.cpp"
template 
struct foo
{
public:
 void bar()
 {
  [this]{bar();}();
 }
};

int main()
{
 foo ss;
 ss.bar();
}

Gcc doesn't crash if foo is not a templated class.

[Bug c++/54431] [C++11] g++ crashes when compiling the following file

2012-09-01 Thread m101010a at gmail dot com

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

--- Comment #1 from m101010a at gmail dot com 2012-09-01 22:04:04 UTC ---
Gcc also doesn't crash if the lambda line is changed to

[this]{this->bar();}();

Although the resulting program does.

[Bug c++/54080] New: g++ crashes when compiling the following file

2012-07-24 Thread m101010a at gmail dot com

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

 Bug #: 54080
   Summary: g++ crashes when compiling the following file
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: m1010...@gmail.com


$ cat y.cpp
template 
class vector
{
};

template  class Container,
 typename Func
 >
vector foo(const Container& input, const Func &func)
{
}

template  class OutType,
 typename Func1,
 typename FuncRest
 >
auto foo(const vector &input, const Func1 &func1, const FuncRest funcrest)
-> decltype(foo(foo(input, func1), funcrest))
{
return;
}

int main()
{
vector v1;
foo(v1, 1, 1);
}
$ g++ -v -save-temps -std=c++11 y.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.7-20120721/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id
--with-ppl --enable-cloog-backend=isl --disable-ppl-version-check
--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default
--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu
--enable-multilib --disable-libssp --disable-build-with-cxx
--disable-build-poststage1-with-cxx --enable-checking=release
Thread model: posix
gcc version 4.7.1 20120721 (prerelease) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/cc1plus -E -quiet -v -D_GNU_SOURCE
y.cpp -mtune=generic -march=x86-64 -std=c++11 -fpch-preprocess -o y.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1

/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/x86_64-unknown-linux-gnu

/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/backward
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-std=c++11' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/cc1plus -fpreprocessed y.ii -quiet
-dumpbase y.cpp -mtune=generic -march=x86-64 -auxbase y -std=c++11 -version -o
y.s
GNU C++ (GCC) version 4.7.1 20120721 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.1 20120721 (prerelease), GMP version 5.0.5,
MPFR version 3.1.1, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (GCC) version 4.7.1 20120721 (prerelease) (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.1 20120721 (prerelease), GMP version 5.0.5,
MPFR version 3.1.1, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 9968e81036a8f762508137542633c004
‘
Internal compiler error: Error reporting routines re-entered.
Please submit a full bug report,
with preprocessed source if appropriate.
See  for instructions.
$ cat y.ii
# 1 "y.cpp"
# 1 ""
# 1 "y.cpp"
template 
class vector
{
};

template  class Container,
  typename Func
  >
vector foo(const Container& input, const Func &func)
{
}

template  class OutType,
  typename Func1,
  typename FuncRest
  >
auto foo(const vector &input, const Func1 &func1, const FuncRest funcrest)
-> decltype(foo(foo(input, func1), funcrest))
{
 return;
}

int main()
{
 vector v1;
 foo(v1, 1, 1);
}



On a possibly unrelated note, changing the "return;" in foo to "return
vector();" will cause the file to compile without a compiler crash.

[Bug c/88568] New: GCC cannot dllimport variables with undefined types

2018-12-21 Thread m101010a at gmail dot com

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88568

Bug ID: 88568
   Summary: GCC cannot dllimport variables with undefined types
   Product: gcc
   Version: 8.1.0
Status: UNCONFIRMED
  Keywords: rejects-valid
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
CC: bangerth at apex68 dot ticam.utexas.edu,
gcc-bugs at gcc dot gnu.org, loewis at gcc dot gnu.org,
martin at loewis dot home.cs.tu-berlin.de, neil at gcc dot 
gnu.org,
unassigned at gcc dot gnu.org
  Target Milestone: ---

$ cat x.c
__attribute__((dllimport)) struct s var;
$ gcc -x c -fsyntax-only x.c
x.c:1:37: error: storage size of 'var' isn't known
 __attribute__((dllimport)) struct s var;
 ^~~
$ gcc -x c++ -fsyntax-only x.c
$ gcc -v
Using built-in specs.
COLLECT_GCC=C:\Program Files
(x86)\mingw-w64\i686-8.1.0-posix-dwarf-rt_v6-rev0\mingw32\bin\gcc.exe
COLLECT_LTO_WRAPPER=C:/Program\ Files\
(x86)/mingw-w64/i686-8.1.0-posix-dwarf-rt_v6-rev0/mingw32/bin/../libexec/gcc/i686
-w64-mingw32/8.1.0/lto-wrapper.exe
Target: i686-w64-mingw32
Configured with: ../../../src/gcc-8.1.0/configure --host=i686-w64-mingw32
--build=i686-w64-mingw32 --target=i686-w64-min
gw32 --prefix=/mingw32
--with-sysroot=/c/mingw810/i686-810-posix-dwarf-rt_v6-rev0/mingw32
--enable-shared --enable-stati
c --disable-multilib --enable-languages=c,c++,fortran,lto
--enable-libstdcxx-time=yes --enable-threads=posix --enable-li
bgomp --enable-libatomic --enable-lto --enable-graphite
--enable-checking=release --enable-fully-dynamic-string --enable
-version-specific-runtime-libs --disable-sjlj-exceptions --with-dwarf2
--disable-libstdcxx-pch --disable-libstdcxx-debug
 --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls
--disable-werror --disable-symvers --with-gnu
-as --with-gnu-ld --with-arch=i686 --with-tune=generic --with-libiconv
--with-system-zlib --with-gmp=/c/mingw810/prerequ
isites/i686-w64-mingw32-static
--with-mpfr=/c/mingw810/prerequisites/i686-w64-mingw32-static
--with-mpc=/c/mingw810/prer
equisites/i686-w64-mingw32-static
--with-isl=/c/mingw810/prerequisites/i686-w64-mingw32-static
--with-pkgversion='i686-p
osix-dwarf-rev0, Built by MinGW-W64 project'
--with-bugurl=https://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe
-fno-ident -I/c/mingw810/i686-810-posix-dwarf-rt_v6-rev0/mingw32/opt/include
-I/c/mingw810/prerequisites/i686-zlib-stati
c/include -I/c/mingw810/prerequisites/i686-w64-mingw32-static/include'
CXXFLAGS='-O2 -pipe -fno-ident -I/c/mingw810/i686
-810-posix-dwarf-rt_v6-rev0/mingw32/opt/include
-I/c/mingw810/prerequisites/i686-zlib-static/include -I/c/mingw810/prere
quisites/i686-w64-mingw32-static/include' CPPFLAGS='
-I/c/mingw810/i686-810-posix-dwarf-rt_v6-rev0/mingw32/opt/include -
I/c/mingw810/prerequisites/i686-zlib-static/include
-I/c/mingw810/prerequisites/i686-w64-mingw32-static/include' LDFLAGS
='-pipe -fno-ident
-L/c/mingw810/i686-810-posix-dwarf-rt_v6-rev0/mingw32/opt/lib
-L/c/mingw810/prerequisites/i686-zlib-s
tatic/lib -L/c/mingw810/prerequisites/i686-w64-mingw32-static/lib
-Wl,--large-address-aware'
Thread model: posix
gcc version 8.1.0 (i686-posix-dwarf-rev0, Built by MinGW-W64 project)

Since this works in C++, I would expect it to work in C as well.  This works in
Clang 7, and if the dllimport attribute is removed fails for both C and C++ in
both Clang and GCC.  If struct s is given a definition, it compiles fine.

[Bug c++/88804] New: Inconsistently diagnosed unused but set static variable in lambda

2019-01-11 Thread m101010a at gmail dot com

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88804

Bug ID: 88804
   Summary: Inconsistently diagnosed unused but set static
variable in lambda
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ cat x.cpp
void foo(int);
template  void call(T t) {
t(0);
}
void bar() {
static int x=3;
call([](auto){
foo(x);
});
}
$ cat y.cpp
void foo(int);
template  void call(T t) {
t(0);
}
void bar() {
static int x=3;
call([](int){
foo(x);
});
}
$ g++ -fsyntax-only -Wunused-but-set-variable x.cpp
x.cpp: In function ‘void bar()’:
x.cpp:6:13: warning: variable ‘x’ set but not used [-Wunused-but-set-variable]
  static int x=3;
 ^
$ g++ -fsyntax-only -Wunused-but-set-variable y.cpp
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC) 

x is incorrectly diagnosed as unused when used in a lambda with an auto
parameter, but not in a lambda with a type parameter (or no parameter).  This
happens even if the lambda isn't called, but does not happen if the lambda is
called in the same function where it is declared.

[Bug c++/88806] New: extern "C" variables declared in different namespaces are considered different

2019-01-11 Thread m101010a at gmail dot com

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88806

Bug ID: 88806
   Summary: extern "C" variables declared in different namespaces
are considered different
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ cat x.cpp
namespace A { extern "C" int g; }
namespace B { extern "C" int g; }
using namespace A;
using namespace B;
void f() { g; }
$ g++ -fsyntax-only x.cpp
x.cpp: In function ‘void f()’:
x.cpp:5:12: error: reference to ‘g’ is ambiguous
 void f() { g; }
^
x.cpp:2:30: note: candidates are: ‘int B::g’
 namespace B { extern "C" int g; }
  ^
x.cpp:1:30: note: ‘int A::g’
 namespace A { extern "C" int g; }
  ^
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC) 

This is part of the example from the C++ standard section 9.7.3
(namespace.udir) paragraph 6, with g changed from a function to a variable. 
Since A::g and B::g refer to the same entity, there should be no ambiguity
between them.

[Bug c++/89050] New: GCC sometimes requires this to be captured when doing overload resolution but selecting a static member function

2019-01-24 Thread m101010a at gmail dot com

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89050

Bug ID: 89050
   Summary: GCC sometimes requires this to be captured when doing
overload resolution but selecting a static member
function
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ cat x.cpp
template  struct A {
static void f();
void f(int);

void foo() {
[]{ f(); };
}
};

void foo(A &a) {
a.foo();
}
$ g++ -fsyntax-only x.cpp
x.cpp: In lambda function:
x.cpp:6:15: error: ‘this’ was not captured for this lambda function
 []{ f(); };
   ^
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC)

If A is not a template or there is no competing non-static member named f, this
works fine.  This is basically bug 51494 but with templates and overload
resolution.

[Bug c++/55319] Using -fwhole-program inhibits optimization

2019-01-24 Thread m101010a at gmail dot com

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55319

m101010a at gmail dot com changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from m101010a at gmail dot com ---
This is no longer an issue in GCC 8.2.1

[Bug c/89051] New: -Wno-error= does not work for warning groups

2019-01-24 Thread m101010a at gmail dot com

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89051

Bug ID: 89051
   Summary: -Wno-error= does not work for warning groups
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ cat x.c
void f() { g(1); }
$ gcc -fsyntax-only -Wall -Wno-implicit x.c
$ gcc -fsyntax-only -Werror=all -Wno-error=implicit x.c
x.c: In function ‘f’:
x.c:1:12: error: implicit declaration of function ‘g’
[-Werror=implicit-function-declaration]
 void f() { g(1); }
^
cc1: some warnings being treated as errors
$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC) 

-Wno-error=* should work like -Wno-* and disable errors for more specific
groups of warnings.

[Bug c++/89144] New: GCC emits undefined references when a constexpr initializer_list appears in a template function

2019-01-31 Thread m101010a at gmail dot com

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89144

Bug ID: 89144
   Summary: GCC emits undefined references when a constexpr
initializer_list appears in a template function
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ cat x.cpp
#include 
template  void b() {
constexpr std::initializer_list c{};
}
int main() { b(); }
$ g++ x.cpp
/bin/ld: /tmp/ccqq90fA.o: in function `void b()':
x.cpp:(.text._Z1bIiEvv[_Z1bIiEvv]+0x7): undefined reference to `._0'
collect2: error: ld returned 1 exit status
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC) 

This happens whether or not the initializer list has any elements.  It does not
happen if the list is not constexpr, and does not happen if b is not a
template.  This also happens when using mingw.

[Bug c/89051] -Wno-error= does not work for warning groups

2019-02-07 Thread m101010a at gmail dot com

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89051

--- Comment #2 from m101010a at gmail dot com ---
(In reply to Martin Sebor from comment #1)
> I don't think GCC has an internal representation of warning groups

It has to have some representation, because it can tell which warning group is
more specific (the documentation specifically mentions this, and it works in
practice).  That representation might be able to be re-used to mark which
groups are also errors.

[Bug c++/91873] New: -Wreturn-type diagnostic location changes depending on optimization level and destructor declaration

2019-09-23 Thread m101010a at gmail dot com

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91873

Bug ID: 91873
   Summary: -Wreturn-type diagnostic location changes depending on
optimization level and destructor declaration
   Product: gcc
   Version: 9.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ cat x.cpp
struct s {
#ifdef HAS_DESTRUCTOR
~s();
#endif
};
bool f();
int g()
{
s buf;
if (f())
return 0;
}
$ g++ -Werror=return-type -O0 x.cpp
x.cpp: In function ‘int g()’:
x.cpp:12:1: error: control reaches end of non-void function
[-Werror=return-type]
   12 | }
  | ^
cc1plus: some warnings being treated as errors
$ g++ -Werror=return-type -O1 x.cpp
x.cpp: In function ‘int g()’:
x.cpp:12:1: error: control reaches end of non-void function
[-Werror=return-type]
   12 | }
  | ^
cc1plus: some warnings being treated as errors
$ g++ -Werror=return-type -DHAS_DESTRUCTOR -O0 x.cpp
x.cpp: In function ‘int g()’:
x.cpp:12:1: error: control reaches end of non-void function
[-Werror=return-type]
   12 | }
  | ^
cc1plus: some warnings being treated as errors
$ g++ -Werror=return-type -DHAS_DESTRUCTOR -O1 x.cpp
x.cpp: In function ‘int g()’:
x.cpp:9:7: error: control reaches end of non-void function
[-Werror=return-type]
9 | s buf;
  |   ^~~
cc1plus: some warnings being treated as errors
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/9.1.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --with-isl --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--disable-libssp --enable-gnu-unique-object --enable-linker-build-id
--enable-lto --enable-plugin --enable-install-libiberty
--with-linker-hash-style=gnu --enable-gnu-indirect-function --enable-multilib
--disable-werror --enable-checking=release --enable-default-pie
--enable-default-ssp --enable-cet=auto
Thread model: posix
gcc version 9.1.0 (GCC) 

When -Wreturn-type locates the end of a function that has a variable with a
non-trivial destructor, it will point at the closing brace when compiling with
-O0, but points at the variable at -O1 and higher.  This behavior was
introduced in GCC 8; GCC 7 always pointed at the closing brace.

[Bug libstdc++/83607] New: std::boyer_moore_searcher is slow searching through arrays of std::byte

2017-12-27 Thread m101010a at gmail dot com

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83607

Bug ID: 83607
   Summary: std::boyer_moore_searcher is slow searching through
arrays of std::byte
   Product: gcc
   Version: 7.2.1
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

Created attachment 42975
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=42975&action=edit
C++17 program demonstrating the issue

When using std::boyer_moore_searcher on an array of std::bytes, it is 3 times
as slow as memmem.  When using std::boyer_moore_searcher on an array of
unsigned char, it is faster them memmem.  This is because the searcher uses an
array when searching through unsigned chars, but uses a hash table when
searching through std::byte.  Searches through std::byte should also use an
array, since it has the same size and equality semantics as unsigned char.

[Bug c++/90161] New: GCC does not always dllexport constexpr member variables in C++17 mode

2019-04-18 Thread m101010a at gmail dot com

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90161

Bug ID: 90161
   Summary: GCC does not always dllexport constexpr member
variables in C++17 mode
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ cat x.cpp
struct __attribute__((dllexport)) foo {
static constexpr int i = 3;
};
constexpr int foo::i;
$ cat y.cpp
struct __attribute__((dllimport)) foo {
static constexpr int i = 3;
};
int main() {
volatile auto v = &foo::i;
}
$ i686-w64-mingw32-g++ x.cpp -shared -o libx.dll
$ i686-w64-mingw32-g++ y.cpp -o y.exe -L. -lx
$ rm -f libx.dll y.exe
$ i686-w64-mingw32-g++ -std=c++17 x.cpp -shared -o libx.dll
$ i686-w64-mingw32-g++ -std=c++17 y.cpp -o y.exe -L. -lx
/usr/lib/gcc/i686-w64-mingw32/8.3.0/../../../../i686-w64-mingw32/bin/ld:
/tmp/cc8oSAlw.o:y.cpp:(.text+0xf): undefined reference to `_imp___ZN3foo1iE'
collect2: error: ld returned 1 exit status
$ i686-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=i686-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-w64-mingw32/8.3.0/lto-wrapper
Target: i686-w64-mingw32
Configured with: /home/marc/.cache/aurman/mingw-w64-gcc/src/gcc/configure
--prefix=/usr --libexecdir=/usr/lib --target=i686-w64-mingw32
--enable-languages=c,lto,c++,objc,obj-c++,fortran,ada --enable-shared
--enable-static --enable-threads=posix --enable-fully-dynamic-string
--enable-libstdcxx-time=yes --with-system-zlib --enable-cloog-backend=isl
--enable-lto --enable-dw2-exceptions --disable-sjlj-exceptions --enable-libgomp
--disable-multilib --enable-checking=release
Thread model: posix
gcc version 8.3.0 (GCC) 


This difference is likely because in C++17, foo::i is an inline variable due to
being constexpr.  If there is a function in libx.dll which uses foo::i's
address, the address is exported properly and linking y.exe works fine.  This
works fine on Linux using the visibility attribute.  GCC appears to have
stopped exporting foo::i in GCC 7 (https://godbolt.org/z/yatDtS).

[Bug c++/90410] New: [feature request] -fdiagnostics-show-template-tree should expand mismatched reference parameters

2019-05-09 Thread m101010a at gmail dot com

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90410

Bug ID: 90410
   Summary: [feature request] -fdiagnostics-show-template-tree
should expand mismatched reference parameters
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ cat x.cpp
template struct s{};
void byval(s);
void byref(s&);
void bycref(const s&);
void g(s v)
{
byval(v);
byref(v);
bycref(v);
}
$ g++ -fsyntax-only -fdiagnostics-show-template-tree x.cpp
x.cpp: In function 'void g(s)':
x.cpp:7:11: error: could not convert 'v' from 's' to 's'
  s<
[int != long int],
[...]>
 byval(v);
   ^
x.cpp:8:11: error: invalid initialization of reference of type 's&' from expression of type 's'
 byref(v);
   ^
x.cpp:3:6: note: in passing argument 1 of 'void byref(s&)'
 void byref(s&);
  ^
x.cpp:9:12: error: invalid initialization of reference of type 'const s&' from expression of type 's'
 bycref(v);
^
x.cpp:4:6: note: in passing argument 1 of 'void bycref(const s&)'
 void bycref(const s&);
  ^~
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.2.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.2.1 20181127 (GCC) 


When taking s by value, -fdiagnostics-show-template-tree expands the template
tree and shows exactly which parts differ between the declaration and the
caller.  When taking s by reference the tree is not expanded, and the similar
parts are not elided.

This behavior started in GCC 8.1 and persists in 9.1 and trunk.

[Bug other/90411] New: Colored diagnostics can omit characters

2019-05-09 Thread m101010a at gmail dot com

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90411

Bug ID: 90411
   Summary: Colored diagnostics can omit characters
   Product: gcc
   Version: 8.2.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

gcc prints EL (\33[K) every time it changes the text color to erase the rest of
the line.  If the cursor is at the end of the line, EL will clear the last
character on the line (tested in xterm 344, urxvt 19.22, and even the Windows
10 terminal).  This can cause diagnostic information to be incorrect.

To reproduce:

1. Set your terminal to 64 columns wide (an easy way to do this is to run
"printf '\e[8;25;64t'")
2. Run "printf 'void g(int); void f(){g((int*)0);}' | env LC_ALL=C gcc -x c -
-fdiagnostics-color=always -fsyntax-only"
Note the line that says ":1:8: note: expected 'int' but argument is of
type 'int  '"
3. Resize the terminal to 66 columns or wider
4. Run "printf 'void g(int); void f(){g((int*)0);}' | env LC_ALL=C gcc -x c -
-fdiagnostics-color=always -fsyntax-only" again
Note that the line is now ":1:8: note: expected 'int' but argument is of
type 'int *'"

This can be fixed by only printing ELs at the end of lines and ending all
colored lines with a space, but that will cause tabs to have the wrong color
(see the comment at the top of gcc/color-macros.h) and will cause lines that
would be exactly the terminal width to be followed by a blank line.

[Bug other/90411] Colored diagnostics can omit characters

2019-05-10 Thread m101010a at gmail dot com

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90411

--- Comment #2 from m101010a at gmail dot com ---
When I said to put spaces ELs at the end of lines, I meant the end of logical
lines (e.g. \n), not the end of screen lines.  Sorry for the confusion.

You can't see this issue in gnome-terminal because they special-cased this
behavior as an intentional deviation from xterm.  See
https://gitlab.gnome.org/GNOME/vte/commit/916964e .  If you follow the links
from there you'll get to the grep bug https://savannah.gnu.org/bugs/?36831
which seems to be the justification for that change.  In fact, it looks like
this behavior was taken from grep, since the justification block comment is
almost identical.

[Bug c++/90508] New: GCC does not produce full template backtraces when instantiating but not calling virtual functions

2019-05-16 Thread m101010a at gmail dot com

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90508

Bug ID: 90508
   Summary: GCC does not produce full template backtraces when
instantiating but not calling virtual functions
   Product: gcc
   Version: 8.3.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ cat x.cpp
template  struct a {
virtual b g() { return 0; }
};
template 
void foo() {
a();
}
void bar() {
foo();
}
$ g++ -fsyntax-only x.cpp
x.cpp: In instantiation of ‘b a::g() [with b = void]’:
x.cpp:2:15:   required from here
x.cpp:2:28: error: return-statement with a value, in function returning ‘void’
[-fpermissive]
 virtual b g() { return 0; }
^
$ cat y.cpp
template  struct a {
virtual b g() { return 0; }
};
template 
void foo() {
a().g();
}
void bar() {
foo();
}
$ g++ -fsyntax-only y.cpp
y.cpp: In instantiation of ‘b a::g() [with b = void]’:
y.cpp:6:5:   required from ‘void foo() [with T = void]’
y.cpp:9:15:   required from here
y.cpp:2:28: error: return-statement with a value, in function returning ‘void’
[-fpermissive]
 virtual b g() { return 0; }
^
$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/8.3.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
--enable-cet=auto
Thread model: posix
gcc version 8.3.0 (GCC) 
$ 

Both x.cpp and y.cpp fail to instantiate a::g(), but y.cpp's failure
gives the full template stack whereas x.cpp's failure just gives the location
of g.  This also happens in GCC 9 and trunk.  However, in 7 and below it would
point at the end of the function at the bottom of the template stack (e.g.
x.cpp:10:1 instead of x.cpp:2:15).

[Bug c++/85011] New: GCC complains that 2 identical function prototypes are different

2018-03-20 Thread m101010a at gmail dot com

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85011

Bug ID: 85011
   Summary: GCC complains that 2 identical function prototypes are
different
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Keywords: diagnostic
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ cat x.cpp
template  struct foo {
int x;
auto f1() -> decltype(x);
};
template  auto foo::f1() -> decltype ((this)->foo::x) {}

$ g++ -v -fsyntax-only x.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.3.1 20180312 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-fsyntax-only' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/cc1plus -quiet -v -D_GNU_SOURCE x.cpp
-quiet -dumpbase x.cpp -mtune=generic -march=x86-64 -auxbase x -version
-fsyntax-only -o /dev/null
GNU C++14 (GCC) version 7.3.1 20180312 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180312, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1

/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include-fixed
 /usr/include
End of search list.
GNU C++14 (GCC) version 7.3.1 20180312 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180312, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 7db9d5d3f13a1b145edda774ba2b8b66
x.cpp:5:25: error: prototype for ‘decltype (((foo*)this)->foo::x)
foo::f1()’ does not match any in class ‘foo’
 template  auto foo::f1() -> decltype ((this)->foo::x) {}
 ^~
x.cpp:3:7: error: candidate is: decltype (((foo*)this)->foo::x)
foo::f1()
  auto f1() -> decltype(x);
   ^~

This error message is nonsensical, since it claims that the prototype for f1 on
lines 3 and 5 differ, yet the error messages list the same prototype for each.

[Bug c++/85012] New: GCC does not inline extern "C" functions defined in a different namespace

2018-03-20 Thread m101010a at gmail dot com

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85012

Bug ID: 85012
   Summary: GCC does not inline extern "C" functions defined in a
different namespace
   Product: gcc
   Version: 7.3.1
Status: UNCONFIRMED
  Keywords: missed-optimization
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ cat x.cpp
namespace foo { extern "C" void f(); }
extern "C" void f() {}
void f1()
{
foo::f();
foo::f();
}
void f2()
{
f();
f();
}

$ g++ -v -S -O1 x.cpp
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.3.1 20180312 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-S' '-O1' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/cc1plus -E -quiet -v -D_GNU_SOURCE
x.cpp -mtune=generic -march=x86-64 -O1 -fpch-preprocess -o x.ii
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1

/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../include/c++/7.3.1/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/include-fixed
 /usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-S' '-O1' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/cc1plus -fpreprocessed x.ii -quiet
-dumpbase x.cpp -mtune=generic -march=x86-64 -auxbase x -O1 -version -o x.s
GNU C++14 (GCC) version 7.3.1 20180312 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180312, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++14 (GCC) version 7.3.1 20180312 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.3.1 20180312, GMP version 6.1.2, MPFR
version 4.0.1, MPC version 1.1.0, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 7db9d5d3f13a1b145edda774ba2b8b66
COMPILER_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.3.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-S' '-O1' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'


The generated assembly for f2 contains only a return.  The generated assembly
for f1 contains 2 calls to f.  Since ::f and foo::f refer to the same
function^[1], the same optimizations should be applied to calls using either
name.

[1] n4659 section 10.5 [dcl.link] paragraph 6: Two declarations for a function
with C language linkage with the same function name (ignoring the namespace
names that qualify it) that appear in different namespace scopes refer to the
same function.

[Bug c++/55319] New: Using -fwhole-program inhibits optimization

2012-11-13 Thread m101010a at gmail dot com



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



 Bug #: 55319

   Summary: Using -fwhole-program inhibits optimization

Classification: Unclassified

   Product: gcc

   Version: 4.7.2

Status: UNCONFIRMED

  Severity: normal

  Priority: P3

 Component: c++

AssignedTo: unassig...@gcc.gnu.org

ReportedBy: m1010...@gmail.com





Created attachment 28681

  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28681

The preprocessed source



The attached code is a template-based brainfuck interpreter, and the brainfuck

code in it prints "Hello world!".  When the attached code is compiled with "g++

-std=c++11 -O2 bf.ii", it produces a series of calls to _IO_putc which directly

print "Hello World!".  However, when compiled with "g++ -std=c++11 -O2

-fwhole-program bf.ii", it produces a more direct and less optimized

interpretation of the associated brainfuck.



$ gcc -v

Using built-in specs.

COLLECT_GCC=gcc

COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/lto-wrapper

Target: x86_64-unknown-linux-gnu

Configured with: /build/src/gcc-4.7.2/configure --prefix=/usr --libdir=/usr/lib

--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info

--with-bugurl=https://bugs.archlinux.org/

--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared

--enable-threads=posix --with-system-zlib --enable-__cxa_atexit

--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch

--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id

--with-ppl --enable-cloog-backend=isl --disable-ppl-version-check

--disable-cloog-version-check --enable-lto --enable-gold --enable-ld=default

--enable-plugin --with-plugin-ld=ld.gold --with-linker-hash-style=gnu

--enable-multilib --disable-libssp --disable-build-with-cxx

--disable-build-poststage1-with-cxx --enable-checking=release

Thread model: posix

gcc version 4.7.2 (GCC)

[Bug c++/55319] Using -fwhole-program inhibits optimization

2012-11-18 Thread m101010a at gmail dot com



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



--- Comment #2 from m101010a at gmail dot com 2012-11-18 22:13:23 UTC ---

Actually, it does depend on IO; the optimizations aren't performed in either

case if I declare but don't define putchar, and if do something simple like

assigning to a volatile int in putchar then the optimizations are performed in

both cases.  If I assert(false) in putchar, gcc optimizes the fwhole-program

version to a failed assert, but doesn't without fwhole-program, which is the

opposite of what it does with IO.

[Bug c++/82336] New: GCC requires but does not emit defaulted constructors in certain cases

2017-09-26 Thread m101010a at gmail dot com

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82336

Bug ID: 82336
   Summary: GCC requires but does not emit defaulted constructors
in certain cases
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

When compiling the following source file, gcc requires a definition for
bar::bar() but does not emit one, causing a linker error:

$ cat x.cpp
struct foo { int x = 5; };
struct bar : foo { bar() = default; };
struct baz { bar x; };
void qux(baz = {}){}
int main() { qux(); }
$ g++ -v -Wall -Wextra x.cpp
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc-multilib/src/gcc/configure --prefix=/usr
--libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man
--infodir=/usr/share/info --with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --enable-libmpx --with-system-zlib --with-isl
--enable-__cxa_atexit --disable-libunwind-exceptions --enable-clocale=gnu
--disable-libstdcxx-pch --disable-libssp --enable-gnu-unique-object
--enable-linker-build-id --enable-lto --enable-plugin
--enable-install-libiberty --with-linker-hash-style=gnu
--enable-gnu-indirect-function --enable-multilib --disable-werror
--enable-checking=release --enable-default-pie --enable-default-ssp
Thread model: posix
gcc version 7.1.1 20170630 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-Wall' '-Wextra' '-g' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/cc1plus -quiet -v -D_GNU_SOURCE x.cpp
-quiet -dumpbase x.cpp -mtune=generic -march=x86-64 -auxbase x -g -Wall -Wextra
-std=c++11 -version -o /tmp/ccwPoekN.s
GNU C++11 (GCC) version 7.1.1 20170630 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.1 20170630, GMP version 6.1.2, MPFR
version 3.1.5-p2, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1

/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/x86_64-pc-linux-gnu
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../include/c++/7.1.1/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/include-fixed
 /usr/include
End of search list.
GNU C++11 (GCC) version 7.1.1 20170630 (x86_64-pc-linux-gnu)
compiled by GNU C version 7.1.1 20170630, GMP version 6.1.2, MPFR
version 3.1.5-p2, MPC version 1.0.3, isl version isl-0.18-GMP

GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 53125f87ce78f0cf5a177bd50a2fd619
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-Wall' '-Wextra' '-g' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 as -v --64 -o /tmp/ccXARTmy.o /tmp/ccwPoekN.s
GNU assembler version 2.28.0 (x86_64-pc-linux-gnu) using BFD version (GNU
Binutils) 2.28.0.20170506
COMPILER_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-Wall' '-Wextra' '-g' '-shared-libgcc'
'-mtune=generic' '-march=x86-64'
 /usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/collect2 -plugin
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/liblto_plugin.so
-plugin-opt=/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccvOLjqj.res -plugin-opt=-pass-through=-lgcc_s
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pass-through=-lgcc --build-id
--eh-frame-hdr --hash-style=gnu -m elf_x86_64 -dynamic-linker
/lib64/ld-linux-x86-64.so.2 -pie
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/Scrt1.o
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/crtbeginS.o
-L/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1
-L/usr/lib/gcc/x86_64-pc-linux-gnu/7.1.1/../../../../lib -L/lib/

[Bug target/81015] New: Bad codegen for __builtin_clz(unsigned short)

2017-06-07 Thread m101010a at gmail dot com

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81015

Bug ID: 81015
   Summary: Bad codegen for __builtin_clz(unsigned short)
   Product: gcc
   Version: 7.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

When compiling with "-O1 -mlzcnt", __builtin_clz applied to an unsigned short
generates the lzcntw instruction instead of lzcntl.  Given the following source
code:

int main()
{
// volatile ensures the clz happens at runtime
volatile unsigned short bits_ = 1;
return __builtin_clz(bits_);
}

Compiling with no optimization produces a binary that correctly returns 31, as
does compiling it with gcc 6.3, but with gcc 7.1 and optimization the binary
returns 15 instead.  This happens for both 64-bit and 32-bit code, for both C
and C++, and for -O1, -O2, and -O3.

[Bug c++/97720] New: Sometimes std::current_exception does not work properly in the terminate handler

2020-11-04 Thread m101010a at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97720

Bug ID: 97720
   Summary: Sometimes std::current_exception does not work
properly in the terminate handler
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC) 
$ cat x.cpp
#include 

struct has_destructor {
~has_destructor();
};

void do_nothing();

inline int throwing_function() {
#ifdef DESTRUCTOR
has_destructor hd;
#endif
throw "";
}

class C {
public:
C() noexcept;
~C();
};

C::C() noexcept {throwing_function();}
inline C::~C() { do_nothing(); }

static void term_handler() {
const char *f = "Died without exception\n";
auto e = std::current_exception();
if (e)
f = "Died with exception\n";
std::cout << f << std::flush;
quick_exit(0);
}

int main() {
std::set_terminate(&term_handler);
C{};
}
$ cat y.cpp
struct has_destructor {
~has_destructor();
};

void do_nothing();

has_destructor::~has_destructor() = default;
void do_nothing() {}
$ g++ x.cpp y.cpp -O1
$ ./a.out
Died with exception
$ g++ -DDESTRUCTOR x.cpp y.cpp -O1
$ ./a.out
Died without exception
$ 

This bug is very sensitive to small changes.  For example, it will correctly
get the exception_ptr when compiling with -O0 or -O2, or if C's constructor is
inline, or if C's destructor is not inline.  This is probably the underlying
cause of bug 97339.

[Bug c++/97720] Sometimes std::current_exception does not work properly in the terminate handler

2020-11-04 Thread m101010a at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97720

--- Comment #2 from m101010a at gmail dot com ---
> when the compiler can see there is no matching handler for the exception, 
> it doesn't perform stack unwinding

This is fine, it's implementation-defined whether the stack is unwound.

> it just calls std::terminate without throwing anything.

This is not fine.  According to N4868 there is an implicit exception handler
active when std::terminate is called due to a throw (14.4/7), and
std::current_exception returns the currently handled exception (17.9.7/8).  So
even if the compiler is going to optimize the throw to a call to terminate it
still needs to behave as if something is being thrown.  This interpretation is
corroborated by comments from MSVC devs in a similar bug: see
https://developercommunity.visualstudio.com/comments/305900/view.html and
https://developercommunity.visualstudio.com/comments/579784/view.html

Also I just looked at the assembly, and it still calls __cxa_throw, even in
cases where it warns that the throw will always terminate:
https://godbolt.org/z/9hja8r .  Between that and how very small changes cause
the test program to report the exception in the terminate handler, this doesn't
look like intentional behavior.

[Bug libstdc++/97339] New: std::async sometimes prevents std::current_exception from working properly in the terminate handler

2020-10-08 Thread m101010a at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97339

Bug ID: 97339
   Summary: std::async sometimes prevents std::current_exception
from working properly in the terminate handler
   Product: gcc
   Version: 10.2.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

If std::async is called with a noexcept function that throws an exception and
contains a catch block which catches exceptions of a different type,
std::current_exception returns an empty exception pointer when called from the
terminate handler.

$ g++ -v
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-pc-linux-gnu/10.2.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 10.2.0 (GCC) 
$ cat y.cpp
#include 
#include 

void term_handler() {
auto e = std::current_exception();
if (e)
std::cout << "Died with exception" << std::endl;
else
std::cout << "Died without exception" << std::endl;
std::abort();
}

void bar() noexcept {
try {
throw "";
}
catch (int) { }
}

int main() {
std::set_terminate(&term_handler);
std::async(std::launch::async, &bar).get();
}

$ g++ y.cpp -pthread
$ ./a.out
Died without exception
Aborted (core dumped)
$ 


This happens regardless of whether launch::async or launch::deferred is used,
but does not happen if the function is called directly or is run by a
std::thread.

[Bug c++/106395] [12/13 regression] [mingw] "redeclared without dllimport attribute: previous dllimport ignored" on C++ friend

2022-08-01 Thread m101010a at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106395

m101010a at gmail dot com changed:

   What|Removed |Added

 CC||m101010a at gmail dot com

--- Comment #1 from m101010a at gmail dot com ---
Git bisect indicates this was caused by commit
a0fdff3cf33f72848d3f894272431a5d49fe6a16 "c++: Fix friend attributes
[PR51344]".
Also, you don't need a member variable to trigger this; I was able to reproduce
it with just

__attribute__((dllimport)) void f();
struct s
{
friend __attribute__((dllimport)) void f();
};

[Bug c++/108116] New: internal compiler error: in check_noexcept_r, at cp/except.cc:1074

2022-12-14 Thread m101010a at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108116

Bug ID: 108116
   Summary: internal compiler error: in check_noexcept_r, at
cp/except.cc:1074
   Product: gcc
   Version: 12.2.0
Status: UNCONFIRMED
  Keywords: ice-on-valid-code
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

When compiling the code

#include 
struct c {
  c(int);
  ~c();
};
struct d {
  d(std::initializer_list);
};
struct e {
  d f{0};
};
template  void h() {
  e{};
}

GCC 12 fails with an internal compiler error.  This happens with GCC 12.1,
12.2, and when built off of the recent git commit
f17ddf2c484427e6ddfd994b62fefcdac27ac02f.  It does not happen with GCC 11.3 or
before.  The full error details and preprocessed source are in the attachment.

[Bug c++/108116] internal compiler error: in check_noexcept_r, at cp/except.cc:1074

2022-12-14 Thread m101010a at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108116

m101010a at gmail dot com changed:

   What|Removed |Added

  Attachment #54098|0   |1
is obsolete||

--- Comment #1 from m101010a at gmail dot com ---
Created attachment 54099
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54099&action=edit
Bug report produced by -freport-bug

[Bug c++/55918] Stack partially unwound when noexcept causes call to std::terminate

2022-12-16 Thread m101010a at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=55918

m101010a at gmail dot com changed:

   What|Removed |Added

 CC||m101010a at gmail dot com

--- Comment #7 from m101010a at gmail dot com ---
I have written a GCC plugin (available at
https://github.com/m42a/gcc-noexcept-plugin ) based on comment #6 that
consistently prevents stack unwinding in this case.

[Bug c++/97720] Sometimes std::current_exception does not work properly in the terminate handler

2022-12-16 Thread m101010a at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97720

--- Comment #3 from m101010a at gmail dot com ---
After looking into this more, I have confirmed that this is definitely the
cause of bug 97339, and found a simpler reproduction in bug 55918 comment #4:

#include 
class Foo
{
public:
Foo() { std::cout << "Foo::Foo()\n"; }
~Foo() { std::cout << "Foo::~Foo()\n"; }
};

void bad_guy() noexcept {
  try {
Foo foo;
throw 0;
  } catch (float) {
// Don't catch int.
  }
}

void level1() {
  bad_guy();
  throw "dead code";
}

int main() {
  try {
level1();
  } catch (int) {
  }
}

[Bug c++/101831] New: Spurious maybe-uninitialized warning on std::array::size

2021-08-09 Thread m101010a at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101831

Bug ID: 101831
   Summary: Spurious maybe-uninitialized warning on
std::array::size
   Product: gcc
   Version: 11.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: m101010a at gmail dot com
  Target Milestone: ---

When calling std::array::size on an uninitialized array, gcc emits a warning:

$ cat x.cpp
#include 
int f() {
std::array a;
return a.size();
}
$ g++ -v -S -o /dev/null -Wmaybe-uninitialized x.cpp
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-pc-linux-gnu
Configured with: /build/gcc/src/gcc/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++,d --with-isl
--with-linker-hash-style=gnu --with-system-zlib --enable-__cxa_atexit
--enable-cet=auto --enable-checking=release --enable-clocale=gnu
--enable-default-pie --enable-default-ssp --enable-gnu-indirect-function
--enable-gnu-unique-object --enable-install-libiberty --enable-linker-build-id
--enable-lto --enable-multilib --enable-plugin --enable-shared
--enable-threads=posix --disable-libssp --disable-libstdcxx-pch
--disable-libunwind-exceptions --disable-werror
gdc_include_dir=/usr/include/dlang/gdc
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.1.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-S' '-o' '/dev/null' '-Wmaybe-uninitialized'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' '/dev/'
 /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/cc1plus -quiet -v -D_GNU_SOURCE x.cpp
-quiet -dumpdir /dev/ -dumpbase x.cpp -dumpbase-ext .cpp -mtune=generic
-march=x86-64 -Wmaybe-uninitialized -version -o /dev/null
GNU C++17 (GCC) version 11.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 11.1.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

warning: MPFR header version 4.1.0 differs from library version 4.1.0-p13.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../x86_64-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0

/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/x86_64-pc-linux-gnu

/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../include/c++/11.1.0/backward
 /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include
 /usr/local/include
 /usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/include-fixed
 /usr/include
End of search list.
GNU C++17 (GCC) version 11.1.0 (x86_64-pc-linux-gnu)
compiled by GNU C version 11.1.0, GMP version 6.2.1, MPFR version
4.1.0, MPC version 1.2.1, isl version isl-0.24-GMP

warning: MPFR header version 4.1.0 differs from library version 4.1.0-p13.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 45eb9a71cc15bfdc579557bea4b77e51
x.cpp: In function ‘int f()’:
x.cpp:4:22: warning: ‘a’ may be used uninitialized [-Wmaybe-uninitialized]
4 | return a.size();
  |~~^~
In file included from x.cpp:1:
/usr/include/c++/11.1.0/array:176:7: note: by argument 1 of type ‘const
std::array*’ to ‘constexpr std::array<_Tp, _Nm>::size_type
std::array<_Tp, _Nm>::size() const [with _Tp = char; long unsigned int _Nm =
1]’ declared here
  176 |   size() const noexcept { return _Nm; }
  |   ^~~~
x.cpp:3:29: note: ‘a’ declared here
3 | std::array a;
  | ^
COMPILER_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/
LIBRARY_PATH=/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../../lib/:/lib/../lib/:/usr/lib/../lib/:/usr/lib/gcc/x86_64-pc-linux-gnu/11.1.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-S' '-o' '/dev/null' '-Wmaybe-uninitialized'
'-shared-libgcc' '-mtune=generic' '-march=x86-64' '-dumpdir' '/dev/'

It also happens on the following reduced test case:

struct array {
  int d;
  int e() const { return 1; }
};
int f() {
  array a;
  return a.e();
}

This does not happen when optimization is enabled, and does not happen if
"-fsyntax-only" is used instead of "-S -o /dev/null".  This also happens with
GCC 11.2, but does not happen with GCC 10.

[Bug c++/97720] throw in try in noexcept fn calls terminate without handling the exception

2023-05-23 Thread m101010a at gmail dot com via Gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97720

--- Comment #6 from m101010a at gmail dot com ---
> represent the second case in the action table as an empty exception 
> specification like C++98 throw()

That will deal with this issue and PR88218, but won't solve PR55918 since using
throw() causes the stack to unwind.  I don't believe there's a way to solve
PR55918 without modifying the personality function in some way; if terminate is
called in the handler then we're already in phase 2, which means the stack has
already been unwound.

[Bug c++/56671] New: Gcc uses large amounts of memory and processor power with large C++11 bitsets

[Bug c++/54431] New: [C++11] g++ crashes when compiling the following file

[Bug c++/54431] [C++11] g++ crashes when compiling the following file

[Bug c++/54080] New: g++ crashes when compiling the following file

[Bug c/88568] New: GCC cannot dllimport variables with undefined types

[Bug c++/88804] New: Inconsistently diagnosed unused but set static variable in lambda

[Bug c++/88806] New: extern "C" variables declared in different namespaces are considered different

[Bug c++/89050] New: GCC sometimes requires this to be captured when doing overload resolution but selecting a static member function

[Bug c++/55319] Using -fwhole-program inhibits optimization

[Bug c/89051] New: -Wno-error= does not work for warning groups

[Bug c++/89144] New: GCC emits undefined references when a constexpr initializer_list appears in a template function

[Bug c/89051] -Wno-error= does not work for warning groups

[Bug c++/91873] New: -Wreturn-type diagnostic location changes depending on optimization level and destructor declaration

[Bug libstdc++/83607] New: std::boyer_moore_searcher is slow searching through arrays of std::byte

[Bug c++/90161] New: GCC does not always dllexport constexpr member variables in C++17 mode

[Bug c++/90410] New: [feature request] -fdiagnostics-show-template-tree should expand mismatched reference parameters

[Bug other/90411] New: Colored diagnostics can omit characters

[Bug other/90411] Colored diagnostics can omit characters

[Bug c++/90508] New: GCC does not produce full template backtraces when instantiating but not calling virtual functions

[Bug c++/85011] New: GCC complains that 2 identical function prototypes are different

[Bug c++/85012] New: GCC does not inline extern "C" functions defined in a different namespace

[Bug c++/55319] New: Using -fwhole-program inhibits optimization

[Bug c++/55319] Using -fwhole-program inhibits optimization

[Bug c++/82336] New: GCC requires but does not emit defaulted constructors in certain cases

[Bug target/81015] New: Bad codegen for __builtin_clz(unsigned short)

[Bug c++/97720] New: Sometimes std::current_exception does not work properly in the terminate handler

[Bug c++/97720] Sometimes std::current_exception does not work properly in the terminate handler

[Bug libstdc++/97339] New: std::async sometimes prevents std::current_exception from working properly in the terminate handler

[Bug c++/106395] [12/13 regression] [mingw] "redeclared without dllimport attribute: previous dllimport ignored" on C++ friend

[Bug c++/108116] New: internal compiler error: in check_noexcept_r, at cp/except.cc:1074

[Bug c++/108116] internal compiler error: in check_noexcept_r, at cp/except.cc:1074

[Bug c++/55918] Stack partially unwound when noexcept causes call to std::terminate

[Bug c++/97720] Sometimes std::current_exception does not work properly in the terminate handler

[Bug c++/101831] New: Spurious maybe-uninitialized warning on std::array::size

[Bug c++/97720] throw in try in noexcept fn calls terminate without handling the exception

35 matches

Site Navigation

Mail list logo

Footer information