[Bug tree-optimization/57249] New: Unrolling too late for inlining

[glisse at gcc dot gnu.org]

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

Bug ID: 57249
   Summary: Unrolling too late for inlining
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: glisse at gcc dot gnu.org

Hello,

this code is a variant of the code at
http://stackoverflow.com/questions/16493290/why-is-inlined-function-slower-than-function-pointer

typedef void (*Fn)();

long sum = 0;

inline void accu() {
  sum+=4;
}

static const Fn map[4] = {&accu, &accu, &accu, &accu};

void f(bool opt) {
  const long N = 1000L;
  if (opt)
  {
for (long i = 0; i < N; i++)
{
  accu();
  accu();
  accu();
  accu();
}
  }
  else
  {
for (long i = 0; i < N; i++)
{
  for (int j = 0; j < 4; j++)
(*map[j])();
}
  }
}


In the first loop, g++ -O3 inlines the 4 accu() calls in the einline pass.
Later passes optimize the whole loop to a single +=. In the second loop, we
need to wait until the inner loop is unrolled to see the accu() calls, and
there is no inlining pass after that (and then it would still need the right
passes to optimize the outer loop to sum+=16000).

I am not sure what the right solution is, since too aggressive early unrolling
can be bad for other optimizations. Note that LLVM manages to optimize the
whole function to a single +=.

[Bug web/52239] Upgrade GCC Bugzilla to 4.4

[glisse at gcc dot gnu.org]

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

--- Comment #17 from Marc Glisse  ---
Hello,

the "Keywords" field auto-completes when editing an existing bug, but not in
the form to create a new bug. I seem to remember that it used to work...

[Bug c/57180] Structures with a flexible arrray member have wrong size

[mikpe at it dot uu.se]

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

--- Comment #3 from Mikael Pettersson  ---
According to
,
arrays of structures with trailing flex arrays are invalid and rejected. The
page also gives an example of that, but changing it to use a char array with
either a string literal initializer or a { } one shows that only the { } form
is rejected:

> cat pr57180-2.c
struct foo { int x; char y[]; };
struct foo a[1] = { { 1, "ab" } };
struct foo b[1] = { { 1, { 'a', 'b', '\0' } } };
> gcc -Wall -S pr57180-2.c
pr57180-2.c:3:8: error: initialization of flexible array member in a nested
context
 struct foo b[1] = { { 1, { 'a', 'b', '\0' } } };
^
pr57180-2.c:3:8: error: (near initialization for 'b[0].y')

Accepting the a[] initializer while rejecting the b[] one seems broken.

[Bug web/52239] Upgrade GCC Bugzilla to 4.4

[LpSolit at netscape dot net]

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

--- Comment #18 from Frédéric Buclin  ---
(In reply to Marc Glisse from comment #17)
> the "Keywords" field auto-completes when editing an existing bug, but not in
> the form to create a new bug. I seem to remember that it used to work...

That's weird. I can indeed reproduce the problem on GCC Bugzilla, but not on my
local copy of GCC Bugzilla nor in a vanilla 4.4 installation. Investigating!

[Bug tree-optimization/57236] Missed optimization: weird pointer update after the loop

[petschy at gmail dot com]

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

--- Comment #5 from petschy at gmail dot com ---
I spotted a minor size inefficiency in the code:

   0x00400720 <+32>:jle0x4007c5 <_Z6write2R6Streamj+197>
   0x00400726 <+38>:mov%rdx,%rsi
   0x00400729 <+41>:test   %r12b,%r12b
...
   0x004007c5 <+197>:mov(%rbx),%rsi
   0x004007c8 <+200>:mov%rbx,%rdi
   0x004007cb <+203>:callq  0x4005d0 <_ZN6Stream5WriteEPhS0_>
   0x004007d0 <+208>:mov(%rbx),%rdx
   0x004007d3 <+211>:mov%rdx,0x8(%rbx)
   0x004007d7 <+215>:mov%rdx,%rsi
   0x004007da <+218>:jmpq   0x400729 <_Z6write2R6Streamj+41>

The mov at +215 would not be needed if the jump went to +38 instead of +41.

[Bug web/52239] Upgrade GCC Bugzilla to 4.4

[LpSolit at netscape dot net]

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

--- Comment #19 from Frédéric Buclin  ---
(In reply to Marc Glisse from comment #17)
> the "Keywords" field auto-completes when editing an existing bug, but not in
> the form to create a new bug. I seem to remember that it used to work...

Fixed!

[Bug libstdc++/57250] New: [C++11] std::shared_ptr misses atomic_* support

[daniel.kruegler at googlemail dot com]

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

Bug ID: 57250
   Summary: [C++11] std::shared_ptr misses atomic_* support
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libstdc++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: daniel.kruegler at googlemail dot com

Consider this as a reminder bug entry to provide the atomic_* overloads for
std::shared_ptr. A minimal test case could be:

#include 

int main() {
  const std::shared_ptr p;
  bool is_lock_free = std::atomic_is_lock_free(&p);
  std::shared_ptr p2 = std::atomic_load(&p);
  std::shared_ptr p3 = std::atomic_load_explicit(&p,
std::memory_order_seq_cst);
  std::atomic_store(&p2, p);
  std::atomic_store_explicit(&p2, p, std::memory_order_seq_cst);
  std::shared_ptr p4 = std::atomic_exchange(&p2, p);
  p4 = std::atomic_exchange_explicit(&p2, p, std::memory_order_seq_cst);
  bool chk = std::atomic_compare_exchange_weak(&p2, &p3, p);
  chk = std::atomic_compare_exchange_strong(&p2, &p3, p);
  chk = std::atomic_compare_exchange_weak_explicit(&p2, &p3, p,
std::memory_order_seq_cst, std::memory_order_seq_cst);
  chk = std::atomic_compare_exchange_strong_explicit(&p2, &p3, p,
std::memory_order_seq_cst, std::memory_order_seq_cst);
}

[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class

[daniel.kruegler at googlemail dot com]

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

Daniel Krügler  changed:

   What|Removed |Added

 CC||daniel.kruegler@googlemail.
   ||com

--- Comment #1 from Daniel Krügler  ---
The report misses a complete example. The following is a reduced form and free
of library stuff:

//---
struct true_type { enum { value = true }; };
struct false_type { enum { value = false }; };

template
struct Foo {};

template
struct is_instantiation_of_nontypes
{
  template class TT, typename T>
  struct check : false_type {};

  template class TT, Ts... Args>
  struct check> : true_type {};
};

static_assert(is_instantiation_of_nontypes::check >::value, "Ouch");
//---

compiled with gcc 4.9.0 20130505 (experimental) gives the error

"main.cpp|14|error: 'Ts ...' is not a valid type for a template non-type
parameter|
main.cpp|14|error: template argument 2 is invalid|
main.cpp|17|error: type/value mismatch at argument 1 in template parameter list
for 'template template >
class TT, class T> template template > class
TT, class T> struct is_instantiation_of_nontypes::check'|
\main.cpp|17|error:   expected a template of type 'template
template > class TT', got 'template struct Foo'"

[Bug c++/57239] cannot handle inner/nested class templates with non-type parameter packs that were declared in the outer/containing class

[scottbaldwin at gmail dot com]

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

--- Comment #2 from etherice  ---
(In reply to Daniel Krügler from comment #1)
> The report misses a complete example. The following is a reduced form and
> free of library stuff:
> 
> //---
> ...

The reason I provided two separate examples (which both appear complete to me,
and only use standard headers  and ) was to demonstrate
that the bug can either result in compilation errors, but in some cases not
have any compilation errors at all (in which case incorrect code is generated
unless explicitly checked for with a static_assert or template
metaprogramming-based error).

The "compile-time error demo" (the one you reduced), by itself, does not
demonstrate the latter case since the test (whether it's a static or runtime
test) can never be "reached" due to the compile error ("'Ts ...' is not a valid
type for a template non-type parameter", which is essentially the same in
4.7/4.8/4.9). So both examples were needed to show the full extent.

[Bug rtl-optimization/55278] [4.8/4.9 Regression] Botan performance regressions, other compilers generate better code than gcc

[steven at gcc dot gnu.org]

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

Steven Bosscher  changed:

   What|Removed |Added

   Last reconfirmed|2013-03-23 00:00:00 |2013-05-11 0:00
Summary|[4.8/4.9 Regression] Botan  |[4.8/4.9 Regression] Botan
   |performance regressions |performance regressions,
   |apparently due to LRA   |other compilers generate
   ||better code than gcc

--- Comment #13 from Steven Bosscher  ---
Per comment #11, not an LRA issue.

[Bug fortran/51591] Strange output from STOP statement in OpenMP region

[bdavis at gcc dot gnu.org]

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

--- Comment #4 from Bud Davis  ---
Upon closer reflection, the underlying problems is the OpenMP threads doing I/O
while the units are being closed.
So, stop shows in the output, followed by output from threads whose units have
been destroyed, but the call to exit() handler has not yet terminated.

[Bug tree-optimization/57251] New: ICE in optab_handler, at optabs.h:258

[antoine.balestrat at gmail dot com]

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

Bug ID: 57251
   Summary: ICE in optab_handler, at optabs.h:258
   Product: gcc
   Version: 4.9.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: tree-optimization
  Assignee: unassigned at gcc dot gnu.org
  Reporter: antoine.balestrat at gmail dot com

Hello !
Using GCC 4.9.0 as of 20130511 :

$ cat optab.c
short a, b;
int f()
{
long long i = 2;
a ? f() ? : 0 : b--;
b &= i *= a |= 0;
}

$ xgcc -O2 -ftracer -m32 optab.c
optab.c: In function ‘f’:
optab.c:6:7: internal compiler error: in optab_handler, at optabs.h:258
 b &= i *= a |= 0;
   ^
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug libstdc++/57250] [C++11] std::shared_ptr misses atomic_* support

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2013-05-11
 Ever confirmed|0   |1

--- Comment #1 from Jonathan Wakely  ---
Yes, this is documented as incomplete:
http://gcc.gnu.org/onlinedocs/libstdc++/manual/status.html#status.iso.2011

(Although I can't remember why it says "Partial" rather than "No")

[Bug c++/57252] New: GCC does not treat ref-qualified overload set as ambiguous

[lucdanton at free dot fr]

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

Bug ID: 57252
   Summary: GCC does not treat ref-qualified overload set as
ambiguous
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr

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

$ g++-snapshot --version
g++-snapshot (Debian 20130509-1) 4.9.0 20130509 (experimental) [trunk revision
198734]

$ cat main.cpp 
struct foo {
void bar() & {}
void bar() && {}
};

int main()
{
// No complaints
auto p = &foo::bar;
// error: pointer-to-member-function type 'void (foo::*)() &' requires an
lvalue
(foo{}.*p)();
}

$ g++-snapshot -std=c++11 main.cpp 
main.cpp: In function 'int main()':
main.cpp:11:13: error: pointer-to-member-function type 'void (foo::*)() &'
requires an lvalue
 (foo{}.*p)();
 ^

I would have thought &foo::bar would have been ambiguous outside of any
context.

[Bug inline-asm/39440] User Manual: describe asm ("%a0,%c0"::)

[gccbugzilla at limegreensocks dot com]

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

David  changed:

   What|Removed |Added

 CC||gccbugzilla@limegreensocks.
   ||com

--- Comment #4 from David  ---
(In reply to Ian Lance Taylor from comment #3)

Since I am working on the extended asm docs, this might be something I could
look at.  The question is, which ones get doc'ed?  The letters acln are
platform neutral (see output_asm_insn in final.c).  Anything beyond that is
platform specific.  Do we really want to doc every letter for every platform?
(yikes!)

I don't own a vax, pdp, sparc, or most of the other 40 odd platforms supported
by gcc.  There's no way I could test modifiers to see if they produce what I
think they do for most platforms, which makes doc'ing them problematical. 

I could take a look at the ones for i386, but there's no point in even doing
that until there's agreement about which ones to doc.  

Who decides?  Or if I'm the person doing the work, do I get to?

[Bug c++/57253] New: GCC ignores ref-qualifiers of pseudo-function types in explicit specializations

[lucdanton at free dot fr]

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

Bug ID: 57253
   Summary: GCC ignores ref-qualifiers of pseudo-function types in
explicit specializations
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr

$ g++-snapshot --version
g++-snapshot (Debian 20130509-1) 4.9.0 20130509 (experimental) [trunk revision
198734]

$ cat main.cpp 
template struct foo;

template<> struct foo {};
template<> struct foo {};

int main()
{}

$ g++-snapshot -std=c++11 main.cpp 
main.cpp:4:19: error: redefinition of 'struct foo'
 template<> struct foo {};
   ^
main.cpp:3:19: error: previous definition of 'struct foo'
 template<> struct foo {};
   ^

Aren't the specializations different, much like specializing on void() and
void() const?

[Bug target/57232] wcstol.c:213:1: internal compiler error

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Target||rx-elf
 Status|WAITING |UNCONFIRMED
  Component|debug   |target
 Ever confirmed|1   |0
   Severity|blocker |normal

[Bug c++/57254] New: Overload resolution failure when member function tempate is defined out-of-line

[lucdanton at free dot fr]

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

Bug ID: 57254
   Summary: Overload resolution failure when member function
tempate is defined out-of-line
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
  Assignee: unassigned at gcc dot gnu.org
  Reporter: lucdanton at free dot fr

Using 4.9.0 20130509 (experimental) [trunk revision 198734] and -std=c++11 the
following is rejected:

//---
struct foo {
template
void bar(T) &;

template
void bar(T) &&;
};

template
void foo::bar(T) & {}

template
void foo::bar(T) && {}

int main()
{
foo f;
// error: call of overloaded 'bar(int)' is ambiguous
f.bar(0);
}
//---

Output is:

main.cpp: In function 'int main()':
main.cpp:19:12: error: call of overloaded 'bar(int)' is ambiguous
 f.bar(0);
^
main.cpp:19:12: note: candidates are:
main.cpp:10:6: note: void foo::bar(T) [with T = int]
 void foo::bar(T) & {}
  ^
main.cpp:13:6: note: void foo::bar(T) [with T = int]
 void foo::bar(T) && {}
  ^

If on the other hand the members are defined inline, the code is accepted.
Similarly if bar is made a set of non-template functions and e.g. T is an alias
for int.