[Bug libgcc/78017] weak reference usage in gthr-posix.h (__gthread*) is broken

[b.r.longbons at gmail dot com]

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

Ben Longbons  changed:

   What|Removed |Added

 CC||b.r.longbons at gmail dot com

--- Comment #5 from Ben Longbons  ---
I just hit this in my testsuite, and it's worse than described for the dynamic
case:

if libpthread.so is dlopen'ed after libstdc++, __gthread_active_p() will *not*
become true - weak symbols are not rebound.

Note that plugins that indirectly pull in pthreads are very common in the wild.

Further, LD_PRELOAD=libpthread.so.0 does NOT help.

Thus, all C++ locks will do nothing despite the presence of multiple threads.
Correct code will experience race conditions.

Do note that, nowadays, all of the *other* symbols you're making weak are in
libc.so (for GLIBC at least, which AFAIK is the only dlopen'able pthread
implementation)

(I had falsely assumed the only danger was doing the dlopen while any lock is
held, leading to mismatched lock/unlock pairs, which would be fairly easy to
avoid)

Tested on Debian 10 (buster), with:

g++ (Debian 8.3.0-6) 8.3.0
GNU C Library (Debian GLIBC 2.28-10) stable release version 2.28.
GNU ld (GNU Binutils for Debian) 2.31.1



// link with -ldl
#include 

#include 
#include 

#include 

int main(void)
{
void *libpthread = dlopen(LIBPTHREAD_SO, RTLD_LAZY);
assert (libpthread);
assert (__gthread_active_p());
}

[Bug c/54433] New: bogus -Wmissing-format-attribute warnings when "first to check" is wrong

[b.r.longbons at gmail dot com]

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

 Bug #: 54433
   Summary: bogus -Wmissing-format-attribute warnings when "first
to check" is wrong
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com


For code like the following, GCC tries to convince me that any function taking
a ptr-to-char should be given the format attribute.

This is due to an incorrect fix for bug 1017 (the comments of which finally
made me realize the bug in my own code - it should be 2, not 0. Sigh, can't you
just autodetect the '...'? You give an error if any other nonzero number is
given)

((The correct fix is to check whether the ptr-to-char argument is being passed
to an attribute'd function. This seems to be almost, but not quite, entirely
unlike what happens when -Wmissing-format-attribute gives a correct warning.))

Bad: 4.3.6 .. 4.7.0

// compile with -Wmissing-format-attribute
#include 
#include 

__attribute__((format(printf, 1, 0) ))
void my_log(const char * fmt, ...)
{
va_list ap;
va_start(ap, fmt);
vfprintf(stderr, fmt, ap);
va_end(ap);
}

void not_a_log(const char *string __attribute__((unused)) )
{
my_log("this should not be a warning\n");
}

[Bug debug/54533] New: breakpoint on C-style variadic function not hit at -O0 on amd64

[b.r.longbons at gmail dot com]

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

 Bug #: 54533
   Summary: breakpoint on C-style variadic function not hit at -O0
on amd64
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com


Created attachment 28156
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28156
nonreduced test case

I am continuing to make compilers fail in new and interesting ways :)


Problem:
If I set (in gdb) a breakpoint on a one of my C-style variadic functions, it
will not get hit. Other variadic functions are fine.

In addition, using gdb's 'step' command will cause the rest of the program to
run, instead of actually stepping (now that I think about it this is probably
an additional bug, in gdb)

This occurs only at optimization level zero. I have reproduced with g++ 4.6 and
4.7 from Debian and from Gentoo.

This likely only happens on amd64 because it is dependent on the way va_list is
implemented.


Analysis:
The problem is because the breakpoint gets set on the line after a jump that
happens to be taken. Someone who knows a lot more about debuginfo than I could
probably automate this and take gdb out of the picture.

=

GNU gdb (GDB) 7.4.1-debian
Copyright (C) 2012 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
For bug reporting instructions, please see:
...
Reading symbols from /tmp/main...done.
(gdb) break cxxstdio::do_scanf
Breakpoint 1 at 0x401564: file src/common/cxxstdio.hpp, line 115.
(gdb) disassemble cxxstdio::do_scanf
Dump of assembler code for function cxxstdio::do_scanf(const_string, char
const*, ...):
   0x00401540 <+0>: push   rbp
   0x00401541 <+1>: movrbp,rsp
   0x00401544 <+4>: subrsp,0xf0
   0x0040154b <+11>:movQWORD PTR [rbp-0x98],rcx
   0x00401552 <+18>:movQWORD PTR [rbp-0x90],r8
   0x00401559 <+25>:movQWORD PTR [rbp-0x88],r9
   0x00401560 <+32>:test   al,al
   0x00401562 <+34>:je 0x401584

   0x00401564 <+36>:movaps XMMWORD PTR [rbp-0x80],xmm0  // <--
breakpoint is here, not reached if the 'je' is taken, i.e. if al is 0
   0x00401568 <+40>:movaps XMMWORD PTR [rbp-0x70],xmm1
   0x0040156c <+44>:movaps XMMWORD PTR [rbp-0x60],xmm2
   0x00401570 <+48>:movaps XMMWORD PTR [rbp-0x50],xmm3
   0x00401574 <+52>:movaps XMMWORD PTR [rbp-0x40],xmm4
   0x00401578 <+56>:movaps XMMWORD PTR [rbp-0x30],xmm5
   0x0040157c <+60>:movaps XMMWORD PTR [rbp-0x20],xmm6
   0x00401580 <+64>:movaps XMMWORD PTR [rbp-0x10],xmm7
   0x00401584 <+68>:movQWORD PTR [rbp-0xe8],rdx
   0x0040158b <+75>:movQWORD PTR [rbp-0xe0],rdi
   0x00401592 <+82>:movQWORD PTR [rbp-0xd8],rsi
   0x00401599 <+89>:movDWORD PTR [rbp-0xc8],0x18
   0x004015a3 <+99>:movDWORD PTR [rbp-0xc4],0x30
   0x004015ad <+109>:   learax,[rbp+0x10]
   0x004015b1 <+113>:   movQWORD PTR [rbp-0xc0],rax
   0x004015b8 <+120>:   learax,[rbp-0xb0]
   0x004015bf <+127>:   movQWORD PTR [rbp-0xb8],rax
   0x004015c6 <+134>:   learax,[rbp-0xe0]
   0x004015cd <+141>:   movrdi,rax
   0x004015d0 <+144>:   call   0x401628 ::data()>
   0x004015d5 <+149>:   leardx,[rbp-0xc8]
   0x004015dc <+156>:   movrcx,QWORD PTR [rbp-0xe8]
   0x004015e3 <+163>:   movrsi,rcx
   0x004015e6 <+166>:   movrdi,rax
   0x004015e9 <+169>:   call   0x400c90 
   0x004015ee <+174>:   leave  
   0x004015ef <+175>:   ret
End of assembler dump.
(gdb)

=

The attached testcase is 500kB. I tried to reduce it, but changing what gets
fed to the preprocessor makes the bug sometimes go away (however any single
source is stable).

[Bug c++/57646] New: bogus warning about uninitialized ‘saved_stack.1’ with gotos and VLAs

[b.r.longbons at gmail dot com]

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

Bug ID: 57646
   Summary: bogus warning about uninitialized ‘saved_stack.1’ with
gotos and VLAs
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com

Created attachment 30321
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30321&action=edit
minimal testcase

The attached reduced testcase gives a warning that a nonexistent variable,
'saved_stack.1', may be used uninitialized.

The testcase does not need any special compiler flags.

There are a bunch of bugs with similar descriptions, but they either don't
involve invented variables or were marked as fixed.
In particular, it looks fairly similar to bug 43013, which was fixed before
4.6.0. The differences I can see are that this only seems to happen in C++ with
VLAs.

Bad versions, all amd64:
Gentoo: 4.4.7, 4.5.4, 4.6.0, 4.6.1, 4.6.2, 4.6.3, 4.6.4, 4.7.0, 4.7.1, 4.7.2,
4.7.3
Debian: 4.6.4-2, 4.7.3-4, 4.8.1-2

4.3.6 does not exhibit this issue, but that's too old to compile the codebase
this is in. Since I haven't found a workaround short of disabling the warning,
I'm stuck with clang for now, which lacks support for a lot of other essential
warnings (*grumbles about old bug reports that still aren't fixed*).

[Bug debug/58150] New: debug info about definition of enum class not emitted if the declaration was already used in a template

[b.r.longbons at gmail dot com]

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

Bug ID: 58150
   Summary: debug info about definition of enum class not emitted
if the declaration was already used in a template
   Product: gcc
   Version: 4.8.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com

Created attachment 30649
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30649&action=edit
minimal testcase

If an enum class has a forward declaration and it is used as a class member
(functions seem to be okay), the full debuginfo is not emitted when the
definition appear later in the TU.

This makes debugging practically impossible.

enums are unusual in that they can be fully used even when they have just a
definition.

Tested gcc versions:
g++-4.6 (Debian 4.6.4-2) 4.6.4
g++-4.7 (Debian 4.7.3-4) 4.7.3
g++-4.8 (Debian 4.8.1-8) 4.8.1

Versions before 4.6 did not implement forward declarations of enum classes, so
this bug is primordial.

The relevant part of the debug information looks like:

 <1><34>: Abbrev Number: 3 (DW_TAG_enumeration_type)
<35>   DW_AT_name: (indirect string, offset: 0x84): ByteCode
<39>   DW_AT_enum_class  : 1
<39>   DW_AT_declaration : 1
<39>   DW_AT_byte_size   : 1
<3a>   DW_AT_decl_file   : 1
<3b>   DW_AT_decl_line   : 3

Whereas clang generates:

 <1><6f>: Abbrev Number: 6 (DW_TAG_enumeration_type)
<70>   DW_AT_type: <0x64>
<74>   DW_AT_enum_class  : 1
<75>   DW_AT_name: (indirect string, offset: 0x98): ByteCode
<79>   DW_AT_byte_size   : 1
<7a>   DW_AT_decl_file   : 1
<7b>   DW_AT_decl_line   : 10

[Bug c++/50248] New: gcc confused, tries to use variadic template to copy itself when it should use default constructor

[b.r.longbons at gmail dot com]

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

 Bug #: 50248
   Summary: gcc confused, tries to use variadic template to copy
itself when it should use default constructor
Classification: Unclassified
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com


Created attachment 25149
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25149
far smaller example than the 3 lines where I first encountered the bug

GCC is trying to instantiate the variadic template as if to copy itself, but
the only thing it should be doing is calling the default constructor.

It only happens when it is constexpr and uses rvalue references.

It only happens when it the parent class has a deleted copy constructor that
takes a *nonconst* reference.

4.5.3 compiles it, but that's because it actually ignores the constexpr
keyword.
Known bad: 4.6.0, 4.6.1-4 debian, svn trunk as of 20110804

Workarounds:
1. Don't use rvalue references.
2. Add a fixed parameter before the variadic one.

Error message:

bug.cpp: In constructor 'constexpr earray::earray(Elt2&& ...) [with
Elt2 = {earray&}, Elt = short int, unsigned int max = 11u]':
bug.cpp:25:30:   instantiated from here
bug.cpp:9:50: error: cannot convert 'earray' to 'short int' in
initialization
bug.cpp:9: confused by earlier errors, bailing out

[Bug c/50459] New: alignof doesn't work on plain old constant, works with expressions containing it

[b.r.longbons at gmail dot com]

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

 Bug #: 50459
   Summary: alignof doesn't work on plain old constant, works with
expressions containing it
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com


For certain types of constant, the exact form:

__attribute__((aligned(align)))

fails, even though 'align' can be used in other constant expressions.

Types of constants that fail:
// C
enum { align = 8 };
// C++
const int align = 8;
class Foo { static const int align = 8; };
// and lots of nasty template stuff

Anything that forms an expression succeeds, even if it's just (align).
sizeof() or a C++11 constexpr function also work.

Bad versions: 4.2.4, 4.3.6, 4.4.6, 4.5.3, 4.6.0, 4.6.1, and a couple of recent
builds from git.

Minimal testcase:
enum { align = 8 };
int succeeds __attribute__((aligned((align)) ));
int fails __attribute__((aligned(align) ));

[Bug c++/50593] New: improve __attribute__((format(printf)))

[b.r.longbons at gmail dot com]

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

 Bug #: 50593
   Summary: improve __attribute__((format(printf)))
Classification: Unclassified
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com


Created attachment 25398
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=25398
8 tests

There are a number of cases where the compiler should be able to use a constant
string to check the arguments of a printf-like function.

Expected Result:
GCC always warns about format argument errors, when it can.

Actual Result:
GCC only warns in a couple of cases.
In particular, note:
* const char[] works in C but not C++.
* Directly using the result of a constexpr function doesn't work, but assigning
it to a variable does.  (This is fortunate, because it allowed me to write the
most awesome code ever, a safe wrapper that allows passing e.g. a std::string
to printf!)

Versions tested:
All tests: 4.6.1 (gentoo), r179098 from branch 4.6, and trunk sometime near
that.
Tests 1,2,6,7,8 (without constexpr): 4.5.3, 4.4.6, 4.3.6 (gentoo)
Tests 1,2 (C++98): 4.2.4 (gentoo)
Tests 1,2 in C: all mentioned versions.

[Bug c++/53247] New: [regression, c++11] can't use a function from a base class of the same name in a different namespace

[b.r.longbons at gmail dot com]

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

 Bug #: 53247
   Summary: [regression, c++11] can't use a function from a base
class of the same name in a different namespace
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com


Created attachment 27318
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27318
testcase

With gcc 4.7 and -std=c++11, 
the 'using' statement fails to bring in a function from the base class into the
current class. This is useful to prevent hiding.

Error message:
base.cpp:12:19: error: type ‘A’ is not a base type for type ‘A’

Workaround:
Create a new member function and explicitly call the base class function.

Versions tested:
Arch gcc (GCC) 4.7.0 20120114 (prerelease)
gcc-4.7 (Debian 4.7.0-3) 4.7.0

[Bug libstdc++/52114] New: SFINAE out the rvalue iostream operators to give better error messages

[b.r.longbons at gmail dot com]

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

 Bug #: 52114
   Summary: SFINAE out the rvalue iostream operators to give
better error messages
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com


Created attachment 26566
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26566
Use SFINAE in delayed return type to make sure there's an lvalue version

Currently, if there is no stream insertion/extraction operator defined for a
class, it tries to use the template that takes an rvalue istream or ostream and
anything on the right.

Actual Result:
error: cannot bind ‘std::ostream {aka std::basic_ostream}’ lvalue to
‘std::basic_ostream&&’
/usr/include/c++/4.6/ostream:581:5: error:   initializing argument 1 of
‘std::basic_ostream<_CharT, _Traits>&
std::operator<<(std::basic_ostream<_CharT, _Traits>&&, const _Tp&) [with _CharT
= char, _Traits = std::char_traits, _Tp = Foo]’

Expected Result:
error: no match for ‘operator<<’ in ‘std::cout << Foo()’
note: candidates are:

Note that this patch is not safe to apply to 4.6 because of bug 51878

[Bug c/52116] New: pragma GCC diagnostic only acts on some lines

[b.r.longbons at gmail dot com]

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

 Bug #: 52116
   Summary: pragma GCC diagnostic only acts on some lines
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com


Created attachment 26567
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26567
two and a half testcases

The attachment has two cases, but I think it might be the same bug. The second
case is much easier to understand.

Case 1. Wrapping a warning location in _Pragma("GCC diagnostic ignored
\"-Wshadow\"") does not work (sometimes). This precludes error suppression
during macro expansion. Oddly, it suppresses as expected (mostly) if both are
on the same line. (Although it behaves oddly if one is "warning" and one is
"ignored")

Case 2:
If an error has multiple locations, such as "-Wshadow", it will still be
reported at the original location, if it is suppressed at the new location.

This leads to a confusing, isolated message:
error: shadowed declaration is here [-Werror=shadow]

Tested: Debian GCC 4.6.2-11, GCC trunk r183363

[Bug c/52116] pragma GCC diagnostic only acts on some lines

[b.r.longbons at gmail dot com]

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

--- Comment #2 from Ben Longbons  2012-02-04 
18:30:46 UTC ---
ah, got home where I have a bunch of versions ...

GCC < 4.6 fail with error: #pragma GCC diagnostic not allowed inside functions

GCC 4.6.{0,1,2}, branch-4.6 r183147, and trunk r182496,r182728,r183173 also
fail as described in this report. (Note that I already mentioned Debian GCC
4.6.2-11, GCC trunk r183363)

[Bug libstdc++/52114] SFINAE out the rvalue iostream operators to give better error messages

[b.r.longbons at gmail dot com]

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

--- Comment #5 from Ben Longbons  2012-02-04 
22:36:54 UTC ---
(In reply to comment #2)
> Yesterday I was wondering: is there something in C++11 saying explicitly that
> these tricks are allowed,
In N3242, 14.8.2/{7,8}

[Bug c/51676] New: -Wsuggest-attribute={pure,const} should give line number of declaration, not definition

[b.r.longbons at gmail dot com]

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

 Bug #: 51676
   Summary: -Wsuggest-attribute={pure,const} should give line
number of declaration, not definition
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com


Created attachment 26184
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26184
minimal testcase for both attributes

Although it's obvious why GCC does what it does, it would be much more useful
if these warnings would give the location at which the attribute would be
added.

Expected result:
Warnings at the (first) declaration. In attached testcase, on lines 2 and 3
(which would usually be in a header file).

Actual result:
Warnings at the definition. In testcase, on lines 4 and 5 (which are usually in
the implementation file).

Tested with: 4.6.0, 4.6.1, 4.6.2, and trunk r182496

[Bug c/51677] New: don't suggest giving main() __attribute__((const))

[b.r.longbons at gmail dot com]

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

 Bug #: 51677
   Summary: don't suggest giving main() __attribute__((const))
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com


With -O -Wsuggest-attribute=const, the following line will generate a warning:
int main() {}

This behavior is bad for 2 reasons:
1. Having an empty main() is quite useful for testing, as it allows linking to
succeed.
2. __attribute__((const)) is only meaningful when you can call the function.

Tested: 4.6.{0..2}, trunk r182496

[Bug c++/51706] New: default copy assignment incorrectly deleted

[b.r.longbons at gmail dot com]

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

 Bug #: 51706
   Summary: default copy assignment incorrectly deleted
Classification: Unclassified
   Product: gcc
   Version: 4.7.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com


Created attachment 26200
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26200
minimal testcase

If a move constructor is defined, then the copy assignment operator is deleted,
even if a copy constructor is defined.

In the n3092 draft, it is:
12.8 "Copying and moving class objects" [class.copy], paragraphs 20,25
which doesn't say move constructors should affect copy assignment.

(Background: I used "= default" on my copy and move constructors to work around
a bug in GCC 4.6)

testcase also at http://ideone.com/U1nvV

[Bug c/51676] -Wsuggest-attribute={pure,const} should give line number of declaration, not definition

[b.r.longbons at gmail dot com]

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

--- Comment #3 from Ben Longbons  2012-01-02 
20:27:41 UTC ---
I'm not familiar with GCC internals, but would it be as easy as adding and
using a second field for "first declaration"?

If the first (possibly only) declaration is the definition, then just remember
it.

If there are one or more declarations before the definition, then just remember
the first one.

[Bug c++/51878] New: ICE or OOM with decltype + variadic templates + "indirect" function call

[b.r.longbons at gmail dot com]

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

 Bug #: 51878
   Summary: ICE or OOM with decltype + variadic templates +
"indirect" function call
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com


Created attachment 26347
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26347
testcase that is probably minimal

(Bugzilla is suggesting lots of duplicates for me, but they all seem to be old
...)

While trying to work around what may or may not be bug 44175, I tried not
calling the function directly. I hit compile and my computer became
unresponsive. With a little investigation, I discovered GCC was trying to
allocate an infinite amount of memory. Running gcc with niceness 19, my system
was responsive enough for me to watch 'top' until it consumed all my swap and
got OOM'ed.

Interestingly, after reducing my testcase, it allocates a lot of memory, but
eventually ICEs instead (SEGV in cc1plus). I swear I didn't change anything in
the testcase since the last time I got an OOM. Nonetheless, I've left an #error
for your safety.

Also, at least in some variants (including the original), the memory explosion
can happen after an Error. Sadly, reproducing this bug with after an error has
occurred is not possible with this minimal testcase. (The particular error was
caused by forgetting to include the pack in one of my if-branches, so it was
calling the functor with too few arguments, leading to "no match found for
apply, candidates are" and then listed the one candidate.)

Expected result:
The following code works (but is admittedly unnecessary if other GCC bugs are
fixed)

template
auto indirect_call(F f, T... t) -> decltype(f(t...))
{
return f(t...);
}

Actual result:
If you're lucky, ICE. Else, an unresponsive system and eventually OOM.

Versions:
Here's where it gets interesting ...
* gcc <= 4.6.0 fail for various reasons unrelated to this bug.
* 4.6.1 and 4.6.2 from Gentoo, and svn branch 4.6 r183147, and whatever svn
snapshot Debian is using, have the effect described in this bug report, but
work if the call is made directly.
* svn trunk (r182728 and r183173) has some sort of regression such that even
the direct call ICEs. My gut says that should probably file a separate bug
about whatever causes that (if there isn't one already), but I don't feel I
know enough.
(My workaround for bug 44175 that works in 4.6 is also broken on trunk. I don't
know if that is the same regression that makes this one fail)

[Bug c++/51878] ICE or OOM with decltype + variadic templates + "indirect" function call

[b.r.longbons at gmail dot com]

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

--- Comment #1 from Ben Longbons  2012-01-17 
08:48:12 UTC ---
Created attachment 26348
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26348
variant of the testcase that compiles with gcc 4.6.{1,2}

[Bug libstdc++/51956] New: [patch] improve shared_ptr and weak_ptr pretty-printers for gdb

[b.r.longbons at gmail dot com]

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

 Bug #: 51956
   Summary: [patch] improve shared_ptr and weak_ptr
pretty-printers for gdb
Classification: Unclassified
   Product: gcc
   Version: 4.6.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com


Created attachment 26422
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26422
show weak count as well as strong

Some ignorant guy was complaining about how GDB was inferior because it didn't
print smart pointers and such "properly". Although we easily proved him wrong,
he *did* bring up that it would be nice to see the weak count as well as the
strong.

I don't even know python, but I managed to make this patch so it shows both the
strong and weak refcount.

I think this patch is trivial, so copyright assignment shouldn't be an issue.
But if it need be, just send me the form.

[Bug jit/71334] New: gccjit's sized integers have different underlying types than stdint.h

[b.r.longbons at gmail dot com]

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

Bug ID: 71334
   Summary: gccjit's sized integers have different underlying
types than stdint.h
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: jit
  Assignee: dmalcolm at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com
  Target Milestone: ---

Created attachment 38594
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38594&action=edit
Utility to print underlying types of GCC vs GCCJIT

When constructed from size + signedness, gccjit should return the same
underlying types as  uses, but doesn't.

Additionally, it appears to return some completely distinct type for size_t,
rather than following the typedef.

Actual output of the attached tool:

underlying size_t: gcc long unsigned int, gccjit unknown
underlying uint32_t: gcc unsigned int, gccjit unsigned int
underlying uint64_t: gcc long unsigned int, gccjit long long unsigned int

[Bug jit/71334] gccjit's sized integers have different underlying types than stdint.h

[b.r.longbons at gmail dot com]

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

--- Comment #3 from Ben Longbons  ---
What I'm trying to do is:

* parse some source code from a new language I'm developing.
* Emit that to machine code via some backend (C, GCCJIT, LLVM, firm, etc.)
* Also emit a header file so that the library is callable from C code.

Doing this requires knowing what the underlying type was, in order to have
compatible function declarations. In future I suspect it will also be useful
for C++-compatible mangling, which is also used for
__attribute__((overloaded)).

Functions to get the size/align of any given primitive type would also be very
useful.

Dealing with all the edge-cases with cross-compiling is hard, especially when
the target supports multilib ... even if target-gcc exists, it might not be the
same version, and in general (if the preprocessor doesn't have a way to emit
that info) you can only get 1 bit of information out per fork+exec.

Enumerating possible target info is already way too hard in general, e.g. I
can't even find a way to get the current -m32 or -mx32 target names ... with
clang at least I can inspect the output of `clang -m32 -x c - -S -emit-llvm -o
- <<< ''`

[Bug c++/81787] New: `#pragma GCC diagnostic warning "-fpermissive"` no longer works since gcc 4.8

[b.r.longbons at gmail dot com]

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

Bug ID: 81787
   Summary: `#pragma GCC diagnostic warning "-fpermissive"` no
longer works since gcc 4.8
   Product: gcc
   Version: 7.1.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com
  Target Milestone: ---

This worked with 4.7, but fails with 4.8 through 7.1.


Original reports on StackOverflow:

https://stackoverflow.com/questions/10932479/in-gcc-how-to-mute-the-fpermissive-warning

https://stackoverflow.com/questions/45600368/how-to-supress-a-fpermissive-error-using-modern-gcc

[Bug debug/80466] New: template<> using loses template argument in debuginfo

[b.r.longbons at gmail dot com]

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

Bug ID: 80466
   Summary: template<> using loses template argument in debuginfo
   Product: gcc
   Version: 7.0.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: debug
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com
  Target Milestone: ---

// BAD: g++-6 -std=c++0x -gusing-template.cpp   -o using-template -gdwarf-4
// BAD: g++-6 -std=c++0x -gusing-template.cpp   -o using-template -gdwarf-5
// BAD: g++-7 -std=c++0x -gusing-template.cpp   -o using-template -gdwarf-4
// ?BAD?: g++-7 -std=c++0x -gusing-template.cpp   -o using-template
-gdwarf-5
// (My `readelf` and `dwarfdump` both barf on the last, but `strings -n 3`
looks like there's no change)

// An example speaks louder than words for this sort of thing:


template
class qux
{
};

template
using foo = qux;

qux works_int;
foo fails_int;

qux works_void;
foo fails_void;

int main()
{
}

/*
readelf -wi using-template

Contents of the .debug_info section:

  Compilation Unit @ offset 0x0:
   Length:0xdc (32-bit)
   Version:   4
   Abbrev Offset: 0x0
   Pointer Size:  8
 <0>: Abbrev Number: 1 (DW_TAG_compile_unit)
   DW_AT_producer: (indirect string, offset: 0x38): GNU C++11 7.0.1
20170407 (experimental) [trunk revision 246759] -mtune=generic -march=x86-64 -g
-gdwarf-4 -std=c++11
<10>   DW_AT_language: 4(C++)
<11>   DW_AT_name: (indirect string, offset: 0x0):
using-template.cpp
<15>   DW_AT_comp_dir: (indirect string, offset: 0x26): /tmp/dl
<19>   DW_AT_low_pc  : 0x61a
<21>   DW_AT_high_pc : 0xb
<29>   DW_AT_stmt_list   : 0x0
 <1><2d>: Abbrev Number: 2 (DW_TAG_class_type)
<2e>   DW_AT_name: (indirect string, offset: 0x13): qux
<32>   DW_AT_byte_size   : 1
<33>   DW_AT_decl_file   : 1
<34>   DW_AT_decl_line   : 2
<35>   DW_AT_sibling : <0x41>
 <2><39>: Abbrev Number: 3 (DW_TAG_template_type_param)
<3a>   DW_AT_name: T
<3c>   DW_AT_type: <0xd8>
 <2><40>: Abbrev Number: 0
 <1><41>: Abbrev Number: 4 (DW_TAG_variable)
<42>   DW_AT_name: (indirect string, offset: 0x1c): works_int
<46>   DW_AT_decl_file   : 1
<47>   DW_AT_decl_line   : 9
<48>   DW_AT_type: <0x2d>
<4c>   DW_AT_external: 1
<4c>   DW_AT_location: 9 byte block: 3 29 10 20 0 0 0 0 0  
(DW_OP_addr: 201029)
 <1><56>: Abbrev Number: 5 (DW_TAG_typedef)
<57>   DW_AT_name: foo
<5b>   DW_AT_decl_file   : 1
<5c>   DW_AT_decl_line   : 7
<5d>   DW_AT_type: <0x2d>
 <1><61>: Abbrev Number: 4 (DW_TAG_variable)
<62>   DW_AT_name: (indirect string, offset: 0xb2): fails_int
<66>   DW_AT_decl_file   : 1
<67>   DW_AT_decl_line   : 10
<68>   DW_AT_type: <0x56>
<6c>   DW_AT_external: 1
<6c>   DW_AT_location: 9 byte block: 3 2a 10 20 0 0 0 0 0  
(DW_OP_addr: 20102a)
 <1><76>: Abbrev Number: 2 (DW_TAG_class_type)
<77>   DW_AT_name: (indirect string, offset: 0x2e): qux
<7b>   DW_AT_byte_size   : 1
<7c>   DW_AT_decl_file   : 1
<7d>   DW_AT_decl_line   : 2
<7e>   DW_AT_sibling : <0x86>
 <2><82>: Abbrev Number: 6 (DW_TAG_template_type_param)
<83>   DW_AT_name: T
 <2><85>: Abbrev Number: 0
 <1><86>: Abbrev Number: 4 (DW_TAG_variable)
<87>   DW_AT_name: (indirect string, offset: 0xbc): works_void
<8b>   DW_AT_decl_file   : 1
<8c>   DW_AT_decl_line   : 12
<8d>   DW_AT_type: <0x76>
<91>   DW_AT_external: 1
<91>   DW_AT_location: 9 byte block: 3 2b 10 20 0 0 0 0 0  
(DW_OP_addr: 20102b)
 <1><9b>: Abbrev Number: 5 (DW_TAG_typedef)
<9c>   DW_AT_name: foo
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 7
   DW_AT_type: <0x76>
 <1>: Abbrev Number: 4 (DW_TAG_variable)
   DW_AT_name: (indirect string, offset: 0xc7): fails_void
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 13
   DW_AT_type: <0x9b>
   DW_AT_external: 1
   DW_AT_location: 9 byte block: 3 2c 10 20 0 0 0 0 0  
(DW_OP_addr: 20102c)
 <1>: Abbrev Number: 7 (DW_TAG_subprogram)
   DW_AT_external: 1
   DW_AT_name: (indirect string, offset: 0xad): main
   DW_AT_decl_file   : 1
   DW_AT_decl_line   : 15
   DW_AT_type: <0xd8>
   DW_AT_low_pc  : 0x61a
   DW_AT_high_pc : 0xb
   DW_AT_frame_base  : 1 byte block: 9c (DW_OP_call_frame_cfa)
   DW_AT_GNU_all_call_sites: 1
 <1>: Abbrev Number: 8 (DW_TAG_base_type)
   DW_AT_byte_size   : 4
   DW_AT_encoding: 5(signed)
   DW_AT_name: int
 <1>: Abbrev Number: 0
*/

// In particular, note the identical DW_AT_name of each DW_TAG_typedef.

[Bug c/82542] New: -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C

[b.r.longbons at gmail dot com]

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

Bug ID: 82542
   Summary: -fdump-lang-raw (formerly -fdump-translation-unit) no
longer available for C
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com
  Target Milestone: ---

With the refactoring to (sensibly I guess?) make it somehow language-specific,
it got dropped from the C FE, via which probably has more users than via the
C++ FE.

There are a *lot* of people relying on this (Debian and Glibc use it for ABI
checking; I and others use it to help generate C bindings for my toy language
without having to write a C parser for no reason).

A partial workaround is to compile as C++ with an `extern "C" { }` block around
the whole thing, but there is a lot of C syntax that doesn't compile in C++ ...
not to mention certain headers that deliberately behave *differently* in C++
mode (e.g. strchr).

Also, would it hurt to keep the old option around as an alias? That's what most
options seem to do (-std=c++0x comes to mind). That just seems like gratuitous
breakage.

[Bug c/71996] -fdump-translation-unit fails to dump string literals of type char16_t/char32_t/wchar_t

[b.r.longbons at gmail dot com]

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

--- Comment #2 from Ben Longbons  ---
It's now called -fdump-lang-raw, and for some reason it's only active in C++
mode (filed bug #82542).

But this bug is still present with those changes made.

[Bug libstdc++/82554] New: uniform_real_distribution can generate the upper endpoint

[b.r.longbons at gmail dot com]

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

Bug ID: 82554
   Summary: uniform_real_distribution can generate the upper
endpoint
   Product: gcc
   Version: 8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com
  Target Milestone: ---

This is related to #64351 and #63176, for which a totally-bogus fix was
applied.

There is actually a defect in the standard: it requires `generate_canonical` to
return at *least* `bits` (e.g. 53), but correct operation is only possible when
it generates *exactly* `bits` since floating-point math rounds rather than
truncating like integer math.

Furthermore, when `std::uniform_real_distribution`'s parameters have different
exponents, the difference must be *subtracted* from the number of bits
requested (not possible since `bits` is only a template parameter).

I have not considered *all* the details when uniform_real_distribution crosses
0 or its parameters are not exact powers of 2, but the principle of requesting
less-than-53 bits certainly still applies.

Consider the following horrible, but valid RNG (for easy testing):

#include 
#include 
#include 
#include 


int main()
{
// seed with -2 instead of -1 because it returns the post-advance state
// produces -1, 0, 1, 2, ...
std::linear_congruential_engine engine(-2ULL);

std::cout << std::setprecision(std::numeric_limits::max_digits10);

std::uniform_real_distribution dist(1.0, 2.0);

for (int i = 0; i < 2; ++i)
std::cout << dist(engine) << std::endl;
// just to prove that yes, they are exact, here are the next values
// the different discards are because 1.0 has a different exponent
engine.discard(1 << 11);
std::cout << dist(engine) << std::endl;
engine.discard(1 << 12);
std::cout << dist(engine) << std::endl;
}

[Bug libstdc++/82554] uniform_real_distribution can generate the upper endpoint

[b.r.longbons at gmail dot com]

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

--- Comment #1 from Ben Longbons  ---
Ugh, part of my explanation was wrong: it's not the difference of exponents,
it's the number of common bits between the min and the (inclusive) max. That
just happens to both be 1 bit when the (exclusive) max is twice the min.

[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C

[b.r.longbons at gmail dot com]

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

--- Comment #7 from Ben Longbons  ---
I saw that mailing list post, but it only explains *what*, not *why*.

I never really gave consideration to DWARF, since in my little experience it is
very unportable for a "standard". I suppose I could investigate it more, but
... that would require a very significant code change (since DWARF has a
completely different mindset), and I don't even know if *all* the interesting
trees survive that long (one of my long-term goals is to allow using C++
templates).

Also, bugs that get filed against GCC's DWARF support tend to just go unfixed
forever (I've filed at least 3 of them).

The only real infelicity I've found in the TU dump *format* (after the high/low
integers went away) is that strings aren't quoted, but that only becomes a
problem if " lngt: MM\n@" occurs in the string with appropriate integers MM
and . (There is also a bug I filed about wide strings not dumping).

I certainly wouldn't complain if it was replaced with an XML-based format with
the same general structure (don't try to make it nice, keep it raw) - parsing
is the easiest part of tooling.

Finally - even if GCC's internal tree layout is *theoretically* unstable - any
such changes will cause more problems for people working on the compiler
itself, and in practice have always been trivial to update for.

[Bug c/82542] -fdump-lang-raw (formerly -fdump-translation-unit) no longer available for C

[b.r.longbons at gmail dot com]

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

--- Comment #9 from Ben Longbons  ---
The ones I've filed are: #54533, #58150, #80466

But there are quite a few more at
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=__open__&component=debug&list_id=190134&product=gcc

[Bug libstdc++/82554] uniform_real_distribution can generate the upper endpoint

[b.r.longbons at gmail dot com]

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

--- Comment #3 from Ben Longbons  ---
There is DR2524 for the [0, 1) case. Otherwise, filing bugs there looks really
complicated.

I've given you a reproducer. That's as much as I'm capable of.

[Bug other/83150] New: GCC's internal use of `abort`is unsafe in several ways

[b.r.longbons at gmail dot com]

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

Bug ID: 83150
   Summary: GCC's internal use of `abort`is unsafe in several ways
   Product: gcc
   Version: 6.4.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: other
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com
  Target Milestone: ---

1. if the `fancy_abort` redefinition is used, exit() is called (and thus atexit
handlers), violating the assumptions of both plugins and later system headers
(including macros) that expect abort() to prevent further code execution, since
invariants may be broken.

Either using `_exit` or `abort` would fix this (in
`diagnostic_action_after_output`, on the ICE case).

The only other alternative would be to write your own libc on all platforms.

2. if the real `abort` is used, GCC installs a signal handler, which calls
async-signal-unsafe functions, such as malloc.

For the async latter case, the first offenders are:
(usual case, e.g. LANG=en_US.UTF-8)
#0  __GI___libc_malloc (bytes=50) at malloc.c:2917
#1  0x7689f4d6 in _nl_make_l10nflist
(l10nfile_list=l10nfile_list@entry=0x76c07b78 <_nl_loaded_domains>,
dirlist=dirlist@entry=0x769d7890 <_nl_default_dirname> "/usr/share/locale",
dirlist_len=18, 
mask=mask@entry=0, language=language@entry=0x7fffcac0 "en_US.UTF-8",
territory=territory@entry=0x0, codeset=0x0, normalized_codeset=0x0,
modifier=0x0, filename=0x7fffcae0 "LC_MESSAGES/libc.mo", do_allocate=0)
at ../intl/l10nflist.c:166
#2  0x7689d2c7 in _nl_find_domain (dirname=dirname@entry=0x769d7890
<_nl_default_dirname> "/usr/share/locale", locale=locale@entry=0x7fffcac0
"en_US.UTF-8", 
domainname=domainname@entry=0x7fffcae0 "LC_MESSAGES/libc.mo",
domainbinding=domainbinding@entry=0x0) at finddomain.c:91
#3  0x7689cb73 in __dcigettext (domainname=0x769d0860
<_libc_intl_domainname> "libc", msgid1=0x769d14c8 "Aborted", msgid2=0x0,
plural=0, n=0, category=5) at dcigettext.c:722
#4  0x00993f01 in ?? ()
#5  

(LC_ALL=C)
#0  __GI___libc_malloc (bytes=146) at malloc.c:2917
#1  0x01050368 in xmalloc ()
#2  0x01050517 in xvasprintf ()
#3  0x00ff9cbc in build_message_string(char const*, ...) ()
#4  0x0084fe4e in lhd_print_error_function(diagnostic_context*, char
const*, diagnostic_info*) ()
#5  0x009d16a1 in ?? ()
#6  0x00ffadbd in diagnostic_report_diagnostic(diagnostic_context*,
diagnostic_info*) ()
#7  0x00ffc2de in internal_error(char const*, ...) ()
#8  0x00993f10 in ?? ()
#9  


Frankly, writing signal handlers correctly is hard, and usually not worth it
(just `write(2)` a short message, then bail out). Especially since you've got
the driver watching your exit code, *and* most ICEs go through the
`fancy_abort` path anyway.


I did most of my testing against GCC 6.4.0, but visual inspection of trunk
looks like all the relevant code is unchanged.

[Bug other/83150] GCC's internal use of `abort`is unsafe in several ways

[b.r.longbons at gmail dot com]

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

--- Comment #3 from Ben Longbons  ---
(In reply to Andrew Pinski from comment #1)
> The signal handler will always be sync unless someone decides to do a kill
> from the command line.

You're assuming that no library ever calls abort(). Glibc certainly does,
notably in its malloc() implementation.

Also, there's SIGSEGV, which was pointed out *cannot* be handled synchronously.
For that, you probably need to implement an `__attribute__((signal_safe))` as a
slightly-extended version of `__attribute__((pure))`.

Plus ... are you really willing to bet that *no* internal callers of abort()
expect sane semantics?


(In reply to Andrew Pinski from comment #2)
> Plugins are not well defined in GCC.  

That excuse is getting *really* old.

So far, the main difficulties I'm hitting are when GCC goes out of its way to
be difficult.

(and yet so far it's *still* easier to use than LLVM, though if this attitude
of "we categorically refuse to fix bugs" continues, that might change)

> Also system headers should not be
> using abort really.  Can you find one which uses abort?

Why not? It's a perfectly legitimate function, and headers can implement
anything as an inline function.

And in the real world, some that *do*: libstdc++, libbfd, boost, LLVM ...

[Bug debug/58150] debug info about definition of enum class not emitted if the declaration was already used in a class

[b.r.longbons at gmail dot com]

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

--- Comment #1 from Ben Longbons  ---
Still present in gcc 4.9 as of 2014-03-22

Currently I'm hacking around this by using a gdb pretty printer that hard-codes
the enum values and turns them into strings, but that only works for printing,
not calls.

[Bug c++/49604] forward-declared enum's elements in class scope gets default access (class vs struct)

[b.r.longbons at gmail dot com]

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

--- Comment #2 from Ben Longbons  ---
Still an issue with 4.9 as of 2014-03-22

[Bug c++/60835] New: Please support __attribute__((format_arg)) on class types as well as char*

[b.r.longbons at gmail dot com]

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

Bug ID: 60835
   Summary: Please support __attribute__((format_arg)) on class
types as well as char*
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com

It would be nice if GCC could remember if an "opaque" class contains a format
string.

The logical extension of this is that a function with __attribute__((format()))
could take a class type that was returned from the __attribute__((format_arg))
function.

Other than ordinary functions, the low-level cases are:
- constructor: std::string::string(const char *)(possibly complicated)
- member function: const char *std::string::c_str() (probably easy)
- UDL: std::string operator "" s (const char *, size_t) (already works for
non-class return types)

Some high level uses:
- Returning an owned string from a gettext()-like function.
- Completely forbidding char* and char[] for strings in a codebase (currently,
I'm using a nop UDL on the format strings and a real UDL on all others, which
isn't terrible but it would be nice to complete it).


Testcase:
// compile with -Wformat=2 -std=c++11
#include 

struct String
{
const char *str;

// 'this' is arg 1; there is no return type for a ctor
__attribute__((format_arg(2)))
String(const char *s) : str(s) {}

__attribute__((format_arg(1)))
const char *c_str() const { return str; }
};

static __attribute__((format_arg(1)))
String operator "" _s(const char *s, size_t)
{
return String(s);
}

int main()
{
printf("Hello, world!\n"_s.c_str());
}

[Bug c++/61038] New: g++ -E is unusable with UDL strings

[b.r.longbons at gmail dot com]

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

Bug ID: 61038
   Summary: g++ -E is unusable with UDL strings
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: critical
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com

The following program is legal and compiles correctly. However, if preprocessed
only, the .ii file in invalid because it fails to escape the ""s

gcc 4.7, 4.8, and 4.9 all fail. Earlier versions did not support UDLs.

I am marking this as "critical" because it makes reducing testcases for other
bugs very difficult.

// compile with -std=c++11
void operator "" _s(const char *, unsigned long)
{
}

#define QUOTE(s) #s

int main()
{
QUOTE("hello"_s);
}

[Bug c++/61040] New: internal compiler error: in gimplify_init_ctor_preeval, at gimplify.c:3320

[b.r.longbons at gmail dot com]

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

Bug ID: 61040
   Summary: internal compiler error: in
gimplify_init_ctor_preeval, at gimplify.c:3320
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com

The following valid program ICEs with g++ 4.9.0.
Previous versions (4.6.4, 4.7.3, 4.8.2) compile it just fine.
Older versions did not implement constexpr.

// compile with -std=c++0x

struct VString
{
VString();
};

struct IP4Address
{
unsigned int _addr;
constexpr IP4Address() : _addr{} {}
};

struct mmo_char_server
{
VString name;
IP4Address ip;
};

mmo_char_server& get_ref();

void parse_login(void)
{
get_ref() = mmo_char_server{};
}

[Bug c++/61038] g++ -E is unusable with UDL strings

[b.r.longbons at gmail dot com]

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

--- Comment #8 from Ben Longbons  ---
(In reply to Ed Smith-Rowland from comment #7)
> Note to self: you DO need to take care of char...

What about multi-char constants, or are they not permitted in C++ UDLs?
Normally they get converted to int, so they're not *meaningful*, but ...

Also, remember the different prefixes: L for wchar_t, u8 for char-but-utf8, u
for char16_t, and U for char32_t

unsigned int fourcc = 'ABCD';

[Bug sanitizer/67941] calls on function pointer from a captureless lambda cause ubsan warning

[b.r.longbons at gmail dot com]

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

Ben Longbons  changed:

   What|Removed |Added

 CC||b.r.longbons at gmail dot com

--- Comment #1 from Ben Longbons  ---
Regression since gcc 4.9

Also fails with gcc 5.2

Untested on trunk (gcc 6)

[Bug c++/64574] New: ICE (stack overflow SEGV) with bad template specialization

[b.r.longbons at gmail dot com]

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

Bug ID: 64574
   Summary: ICE (stack overflow SEGV) with bad template
specialization
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com

Created attachment 34429
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34429&action=edit
reduced testcase

The attached C++ code is illegal because TraitCheckImpl> requires
TraitCheckImpl> to be complete already for Swappable's
defaulted second argument.

But it's still a compiler bug because it causes a stack overflow (-> segv ->
ICE) in cc1plus.

Bad versions:
g++-4.4.real (Debian 4.4.7-8) 4.4.7
g++-4.6.real (Debian 4.6.4-7) 4.6.4
g++-4.7.real (Debian 4.7.4-3) 4.7.4
g++-4.8.real (Debian 4.8.3-13) 4.8.3
g++-4.9.real (Debian 4.9.1-19) 4.9.1

Clang successfully errors out with a message about exceeding maximum template
instantiation depth (which is not the error I would've expected - something
about incomplete types).

The repeating portion of the backtrace (in gcc 4.9):

#11 0x0060bafe in complete_type(tree_node*) ()
#12 0x005a3a02 in tsubst(tree_node*, tree_node*, int, tree_node*) ()
#13 0x005a8673 in ?? ()
#14 0x005a8b98 in ?? ()
#15 0x005a3447 in tsubst(tree_node*, tree_node*, int, tree_node*) ()
#16 0x005a8673 in ?? ()
#17 0x005a31ec in tsubst(tree_node*, tree_node*, int, tree_node*) ()
#18 0x005afa2f in ?? ()
#19 0x005afd24 in ?? ()
#20 0x005b4891 in instantiate_class_template(tree_node*) ()

[Bug c++/64626] New: C++14 single quote should not always be a digit separator

[b.r.longbons at gmail dot com]

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

Bug ID: 64626
   Summary: C++14 single quote should not always be a digit
separator
   Product: gcc
   Version: 5.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com

Created attachment 34459
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34459&action=edit
informative testcase

During preprocessing, single quote (') should only be considered a digit
separator if it is followed by a digit or nondigit.

If it is followed by any other character, it should be considered as the start
of a new character-literal, not part of the current pp-number.

I am aware of exactly 2 other cases where a preprocessing-token needs to
consume 2 characters or none at all (. -> ... and %: -> %:%:), and gcc seems to
handle them correctly. (There is also the <:: case which looks ahead two
characters to *not* consume a character).


Unimplemented: gcc 4.8
Bad: Debian gcc 4.9.1-19
Bad: gcc 5.0.0 snapshot from 20141228
Good: Debian clang 3.4, 3.5, and svn snapshot of 3.6

[Bug c++/64626] C++14 single quote should not always be a digit separator

[b.r.longbons at gmail dot com]

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

--- Comment #1 from Ben Longbons  ---
Demostration that gcc correctly preprocesses the other tokens:

#define JOIN(a, b) a##b
JOIN(.., .)
// error about pasting . and .

#define JOIN3(a, b, c) a##b##c
JOIN3(%:%, :, %:)
// successfully results in %: %:%:
// (though note that the order of evaluation of ## is unspecified so if b##c
were evaluated first a compliant implementation could fail to paste :%:)

[Bug c++/64826] New: Better diagnostics for when ADL/overloading doesn't apply as desired

[b.r.longbons at gmail dot com]

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

Bug ID: 64826
   Summary: Better diagnostics for when ADL/overloading doesn't
apply as desired
   Product: gcc
   Version: 4.9.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com

Created attachment 34596
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34596&action=edit
test set 1, regressions on namespace splitting

Recently I refactored a fair bit of code between namespaces, and found a number
of situations that could use better error messages.

Additionally, it would be nice if at least some attempt was made to provide a
warning when even *before* the namespace.

I mostly understand *why*, but in real world code bases it is often harder than
in these reduced testcases.

Attached are 3 files, each with testcases of similar code inside and outside
namespaces. One version of each test fails, the other works (except for
works-both-ways tests, which are type sensitive).

[Bug c++/64826] Better diagnostics for when ADL/overloading doesn't apply as desired

[b.r.longbons at gmail dot com]

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

--- Comment #2 from Ben Longbons  ---
Created attachment 34598
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34598&action=edit
test set 3, regressions on namespace splitting

[Bug c++/64826] Better diagnostics for when ADL/overloading doesn't apply as desired

[b.r.longbons at gmail dot com]

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

--- Comment #1 from Ben Longbons  ---
Created attachment 34597
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34597&action=edit
test set 2, regressions on namespace merging (I don't understand this)

[Bug c++/63455] New: decltype of statement expression internal compiler error: in cp_parser_abort_tentative_parse, at cp/parser.c:25062

[b.r.longbons at gmail dot com]

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

Bug ID: 63455
   Summary: decltype of statement expression  internal compiler
error: in cp_parser_abort_tentative_parse, at
cp/parser.c:25062
   Product: gcc
   Version: 4.9.2
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com

good: Debian 4.6.4-7
bad: Debian 4.7.4-3
bad: Debian 4.8.3-11
bad: Debian 4.9.1-15


int main()
{
int x = 0;

// without '+0', gcc 4.6 gives a different error (no ICE though)
decltype(({ int y = x; y; })+0) v1 = 0;
}

[Bug lto/49571] New: -flto -Wl,--as-needed drops needed libraries

[b.r.longbons at gmail dot com]

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

   Summary: -flto -Wl,--as-needed drops needed libraries
   Product: gcc
   Version: 4.6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: lto
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com


Created attachment 24624
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24624
Minimal testcase demonstrating the error

Description:
-flto does something funny that makes --as-needed drop more libraries than it
should. See the attached file

Context:
I originally encountered this bug in a big C++ project with -m32, but quickly
reduced it to the attached minimal testcase.
Only in the original project, I got this misleading error:
/usr/bin/ld: /tmp/ccPEhCnW.ltrans4.ltrans.o: undefined reference to symbol
'sqrt@@GLIBC_2.0'
/usr/bin/ld: note: 'sqrt@@GLIBC_2.0' is defined in DSO
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/../../../../../lib32/libm.so
so try adding it to the linker command line
despite -lm *being* explicitly on the command line (which is normally not
needed in C++? Is that standard behavior or is it relying on the indirect
linking thing that *usually* generates that error?)

but this was replaced in the minimal case by the more typical
ccp7SO9X.ltrans0.o:(.text+0x29): undefined reference to `sqrt'


Workaround:
Identify which libraries are *actually* needed and pass them after
-Wl,--no-as-needed.
This works for my particular case (I am building multiple binaries, only one of
which requires -lm) since libm would be loaded indirectly by libstdc++ anyway,
but could be problematic in the general case




System information 1:
Using built-in specs.
COLLECT_GCC=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0/gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.6.0/work/gcc-4.6.0/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-ppl --without-cloog --enable-lto --disable-nls
--with-system-zlib --disable-werror --enable-secureplt --enable-multilib
--enable-libmudflap --disable-libssp --enable-libgomp --enable-cld
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/python
--enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.6.0 p1.2, pie-0.4.5'
Thread model: posix
gcc version 4.6.0 (Gentoo 4.6.0 p1.2, pie-0.4.5) 

System information 2:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.0-13'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/x86_64-linux-gnu
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc
--with-arch-32=i586 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 20110611 (prerelease) (Debian 4.6.0-13)

[Bug c++/49604] New: forward-declared enum in class scope is private in context of constexpr

[b.r.longbons at gmail dot com]

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

   Summary: forward-declared enum in class scope is private in
context of constexpr
   Product: gcc
   Version: 4.6.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: b.r.longb...@gmail.com


Created attachment 24652
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24652
Minimal testcase

If an enum is forward-declared as a public member of a class (but not a
struct), and the values are defined afterward, then the enum values cannot be
be used in the context of a constexpr:

enum-broken.cpp:9:26: error: 'Foo::impl_t Foo::X' is private
enum-broken.cpp:11:27: error: within this context

(see attachment)

Workaround:
Use 'struct' instead of 'class'.

What works:
It works fine if 'struct' is used instead of 'class'.
It works fine without the constexpr.
It works fine if the enum values are defined in the declaration.
It works find if the nested type is a struct with a static member.

Versions:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-pc-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-pc-linux-gnu
Configured with: /var/tmp/portage/sys-devel/gcc-4.6.0/work/gcc-4.6.0/configure
--prefix=/usr --bindir=/usr/x86_64-pc-linux-gnu/gcc-bin/4.6.0
--includedir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/include
--datadir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0
--mandir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/man
--infodir=/usr/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/info
--with-gxx-include-dir=/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.0/include/g++-v4
--host=x86_64-pc-linux-gnu --build=x86_64-pc-linux-gnu --disable-altivec
--disable-fixed-point --without-ppl --without-cloog --enable-lto --disable-nls
--with-system-zlib --disable-werror --enable-secureplt --enable-multilib
--enable-libmudflap --disable-libssp --enable-libgomp --enable-cld
--with-python-dir=/share/gcc-data/x86_64-pc-linux-gnu/4.6.0/python
--enable-checking=release --disable-libgcj --enable-languages=c,c++,fortran
--enable-shared --enable-threads=posix --enable-__cxa_atexit
--enable-clocale=gnu --with-bugurl=http://bugs.gentoo.org/
--with-pkgversion='Gentoo 4.6.0 p1.2, pie-0.4.5'
Thread model: posix
gcc version 4.6.0 (Gentoo 4.6.0 p1.2, pie-0.4.5) 


Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-1'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/x86_64-linux-gnu
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc
--with-arch-32=i586 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 (Debian 4.6.1-1)

[Bug c++/45923] constexpr diagnostics, more more

[b.r.longbons at gmail dot com]

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

Ben Longbons  changed:

   What|Removed |Added

 CC||b.r.longbons at gmail dot
   ||com

--- Comment #13 from Ben Longbons  2011-07-05 
03:52:15 UTC ---
Also it seems the destructor must be defaulted. I thought (incorrectly) that
only constructors mattered, so tried:
protected:
~Base() {}

which yields for members:
error: enclosing class of '...' is not a literal type

and for nonmembers:
error: invalid return type 'Derived' of constexpr function '...'

but this works:
protected:
~Base() = default;

specifically, a 'literal type' requires literal members and bases and:
* a trivial default constructor or at least one constexpr constructor besides
the copy/move constructors (3.9 #10).
* a trivial destructor: non-virtual, non-deleted, non-user-provided (12.4 #3)

[Bug c/71996] New: -fdump-translation-unit fails to dump string literals of type char16_t/char32_t/wchar_t

[b.r.longbons at gmail dot com]

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

Bug ID: 71996
   Summary: -fdump-translation-unit fails to dump string literals
of type char16_t/char32_t/wchar_t
   Product: gcc
   Version: 6.1.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
  Assignee: unassigned at gcc dot gnu.org
  Reporter: b.r.longbons at gmail dot com
  Target Milestone: ---

$ cat dump.c
#include 
#include 

char string1[] = "1string";
wchar_t string2[] = L"2string";
char16_t string3[] = u"3string";
char32_t string4[] = U"4string";

# Output for a little-endian host.
$ gcc dump.c -fdump-translation-unit=stdout -c -o /dev/null | grep string_cst
@2810   string_cst   type: @2808   strg: 1string  lngt: 8   
@2823   string_cst   type: @2821   strg: 2lngt: 32  
@2831   string_cst   type: @2829   strg: 3lngt: 16  
@2837   string_cst   type: @2836   strg: 4lngt: 32  

###

Some decisions also should be made about what exactly lngt should mean (bytes
or characters) - and what to do about string values that contain embedded
newlines, nonprintable characters, or NULs.

Personally, I would prefer the strings to be escaped all the way to something
similar to the input, including the L"" - and the lngt moved before it, if not
removed entirely.