[Bug c++/54021] [c++0x] __builtin_constant_p should be constexpr

[luto at mit dot edu]

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

--- Comment #8 from Andy Lutomirski  2012-09-09 06:05:34 
UTC ---
Did you mean "constexpr bool a" instead of "book const a"?  If so, I agree. 
But consider:

bool const a = something complicated

Is a a constant?

[Bug c++/54021] [c++0x] __builtin_constant_p should be constexpr

[david at doublewise dot net]

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

--- Comment #7 from David Stone  2012-09-09 
06:00:37 UTC ---
That seems to me like saying that `constexpr bool d = sizeof(x);` should be
disallowed because it uses a non-constexpr. You're not using the value of x,
just a property about it. Whether a value is constexpr is guaranteed to be
known at compile time, and so should be usable as a constexpr.

[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 libstdc++/54451] c++11/random.cc build failure when _GLIBCXX_USE_C99_STDINT_TR1 is not defined in config.h

[rbmj at verizon dot net]

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

rbmj at verizon dot net changed:

   What|Removed |Added

 CC||rbmj at verizon dot net

--- Comment #1 from rbmj at verizon dot net 2012-09-09 02:36:26 UTC ---
I can confirm that the build fails as reported.

A bit of searching - turns out that acinclude.m4 has the following:

if test x"$glibcxx_cv_c99_stdint_tr1" = x"yes"; then
  AC_DEFINE(_GLIBCXX_USE_C99_STDINT_TR1, 1,
[Define if C99 tyeps in  should be imported in
  in namespace std::tr1.])
fi

This is confirmed in include/tr1/cstdint:

#ifdef _GLIBCXX_USE_C99_STDINT_TR1

namespace std _GLIBCXX_VISIBILITY(default)
{
namespace tr1
{
  using ::int8_t;
  using ::int16_t;

etc.  However, this is also in include/c_global/cstdint:

#ifdef _GLIBCXX_USE_C99_STDINT_TR1

namespace std
{
  using ::int8_t;
  using ::int16_t;

etc.  Those are the only uses of it in code that I can find.  It seems like it
isn't exactly the best name for the define (it no longer just applies to TR1),
but it doesn't do too much.  I can't think of a case where this would not be
desired behavior (I don't remember, but I *think* that the C++ standard says
that those typenames should be in the standard namespace).

Anyway, it doesn't appear like removing that code will have any adverse
effects.

The relevant code is coming from revision 150312 (written by Paolo Carlini in
2009).  Since this just broke, I'm *guessing* that this is because of 4.8
moving more towards c++11, and because it was thought that this define was only
for tr1, it was removed from a default define set *somewhere* (I'm too scared
to venture too far into the build system...).  I can't seem to find any
evidence of this though... I know it worked ~3 months ago, but my git foo can't
seem to find the change.

[Bug c++/54532] [C++0x][constexpr] internal error when initializing static constexpr with pointer to non-static member variable

[cvs at cs dot utoronto.ca]

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

--- Comment #1 from Chris  2012-09-09 02:24:57 UTC 
---
Created attachment 28155
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28155
preprocessed source

[Bug c++/54532] New: [C++0x][constexpr] internal error when initializing static constexpr with pointer to non-static member variable

[cvs at cs dot utoronto.ca]

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

 Bug #: 54532
   Summary: [C++0x][constexpr] internal error when initializing
static constexpr with pointer to non-static member
variable
Classification: Unclassified
   Product: gcc
   Version: 4.7.1
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: c...@cs.utoronto.ca


Created attachment 28154
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28154
output of g++ -v

The following code triggers a segfault.

struct reg {
template 
constexpr reg(T CLS::*) {}
};

struct foo {
};

struct bar {
foo a;

// both of these trigger internal error
static constexpr foo bar::*reg_a = &bar::a;
static constexpr reg reg_a = &bar::a;
};

g++ --version
g++ (Debian 4.7.1-7) 4.7.1
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

4.6 seems to have the same problem.

[Bug libstdc++/54530] [4.8 regression] error: std::piecewise_construct causes a section type conflict with std::piecewise_construct

[paolo.carlini at oracle dot com]

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

--- Comment #1 from Paolo Carlini  2012-09-09 
00:35:25 UTC ---
This is a compiler (back end) issue isn't it? That line of stl_pair.h cannot
change - C++11  spells it out exactly like that - and is very very old. More
generally, the recent library commits (190355 included) have nothing to do with
it. Thus it really seems a latent compiler problem.

[Bug c++/54521] g++ fails to call explicit constructors in the second step of copy initialization

[redi at gcc dot gnu.org]

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

Jonathan Wakely  changed:

   What|Removed |Added

 Status|WAITING |NEW

--- Comment #4 from Jonathan Wakely  2012-09-09 
00:29:45 UTC ---
Thanks, it would be magical if people could guess what options you used, that's
why the bug reporting guidelines ask you to provide that information!

I must have tested the wrong testcase earlier, I can confirm this fails to
compile.

[Bug target/54531] New: vpermilpd(x, 2 or 10) is a move

[glisse at gcc dot gnu.org]

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

 Bug #: 54531
   Summary: vpermilpd(x, 2 or 10) is a move
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org
Target: x86_64-linux-gnu


Hello,

it is quite easy to make gcc generate instructions that are equivalent to
moves, but gcc doesn't realize that. Simple examples include
_mm256_permute_pd(x,10) and _mm_permute_pd(x,2), but I also got it while trying
a patch that generated some vec_selects. I believe those instructions should be
optimized out.

#include 
__m256d f(__m256d x){
  return _mm256_permute_pd(x,2+8);
}

gcc -O3 -S -mavx
(with -mavx2 we get vpermpd(x,228) which is a similar issue)

[Bug c++/54021] [c++0x] __builtin_constant_p should be constexpr

[luto at mit dot edu]

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

--- Comment #6 from Andy Lutomirski  2012-09-08 22:29:17 
UTC ---
I think that's correct.  x isn't a standards-mandated constant expression, so
__builtin_constant_p depends on optimization level and probably shouldn't be
allowed as a constexpr.

[Bug libstdc++/54530] New: [4.8 regression] error: std::piecewise_construct causes a section type conflict with std::piecewise_construct

[sch...@linux-m68k.org]

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

 Bug #: 54530
   Summary: [4.8 regression] error: std::piecewise_construct
causes a section type conflict with
std::piecewise_construct
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Keywords: build
  Severity: normal
  Priority: P3
 Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: sch...@linux-m68k.org
CC: a...@google.com, fdum...@gcc.gnu.org
Target: powerpc*-*-*


$ /home/andreas/src/gcc/test/ppc/./gcc/g++ -shared-libgcc
-B/home/andreas/src/gcc/test/ppc/./gcc -nostdinc++
-L/home/andreas/src/gcc/test/ppc/powerpc64-linux/libstdc++-v3/src
-L/home/andreas/src/gcc/test/ppc/powerpc64-linux/libstdc++-v3/src/.libs
-B/usr/powerpc64-linux/bin/ -B/usr/powerpc64-linux/lib/ -isystem
/usr/powerpc64-linux/include -isystem /usr/powerpc64-linux/sys-include
-B/home/andreas/src/gcc/test/ppc/powerpc64-linux/./libstdc++-v3/src/.libs
-D_GLIBCXX_ASSERT -fmessage-length=0 -ffunction-sections -fdata-sections -O2 -g
-D_GNU_SOURCE -O2 -g -D_GNU_SOURCE -DLOCALEDIR="." -nostdinc++
-I/home/andreas/src/gcc/test/ppc/powerpc64-linux/libstdc++-v3/include/powerpc64-linux
-I/home/andreas/src/gcc/test/ppc/powerpc64-linux/libstdc++-v3/include
-I/home/andreas/src/gcc/test/gcc/libstdc++-v3/libsupc++
-I/home/andreas/src/gcc/test/gcc/libstdc++-v3/include/backward
-I/home/andreas/src/gcc/test/gcc/libstdc++-v3/testsuite/util
/home/andreas/src/gcc/test/gcc/libstdc++-v3/testsuite/23_containers/unordered_map/cons/moveable.cc
-std=gnu++0x ./libtestc++.a -Wl,--gc-sections -lm -o ./moveable.exe
In file included from
/home/andreas/src/gcc/test/ppc/powerpc64-linux/libstdc++-v3/include/utility:72:0,
 from
/home/andreas/src/gcc/test/ppc/powerpc64-linux/libstdc++-v3/include/unordered_map:38,
 from
/home/andreas/src/gcc/test/gcc/libstdc++-v3/testsuite/23_containers/unordered_map/cons/moveable.cc:25:
/home/andreas/src/gcc/test/ppc/powerpc64-linux/libstdc++-v3/include/bits/stl_pair.h:76:35:
error: std::piecewise_construct causes a section type conflict with
std::piecewise_construct
   constexpr piecewise_construct_t piecewise_construct =
piecewise_construct_t();
   ^

Caused by 190355.

[Bug c++/54021] [c++0x] __builtin_constant_p should be constexpr

[david at doublewise dot net]

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

David Stone  changed:

   What|Removed |Added

 CC||david at doublewise dot net

--- Comment #5 from David Stone  2012-09-08 
21:36:10 UTC ---
I'm running into some issues with this bug, and it's much broader than the test
cases suggest. On gcc 4.7.0, this is what happens:

int main() {
int x = 0;
// This assigns false to a:
bool const a = __builtin_constant_p(x);
// This assigns true to b:
bool const b = __builtin_constant_p(__builtin_constant_p(x));
// This causes "error: the value of 'x' is not usable in a constant
expression"
constexpr bool c = __builtin_constant_p(x);
}

[Bug preprocessor/54528] [4.8 Regression] system.h:288:78: error: integer overflow in expression

[danglin at gcc dot gnu.org]

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

John David Anglin  changed:

   What|Removed |Added

 CC||crowl at gcc dot gnu.org

--- Comment #1 from John David Anglin  2012-09-08 
20:49:37 UTC ---
Introduced in revision 191047 (change to new double_int interface).

[Bug c/54529] dead code elimination deletes code adressed by referenced labels

[pinskia at gcc dot gnu.org]

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

Andrew Pinski  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||INVALID

--- Comment #1 from Andrew Pinski  2012-09-08 
16:36:59 UTC ---
Addresses of labels are only designed to work with computed gotos.

[Bug c/54529] New: dead code elimination deletes code adressed by referenced labels

[Wasserthal at nefkom dot net]

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

 Bug #: 54529
   Summary: dead code elimination deletes code adressed by
referenced labels
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: wassert...@nefkom.net


given the code:

extern void __attribute__((sysv_abi)) breakfree(long long input);

void submaker(long long input)
{
breakfree(input);
}

void mainloop()
{
goto skipper;
;
hidden:
printf("Hello");
asm("nop; nop; int3; int3; int3; int3; int3; nop; nop; nop; nop");
asm("ret");
exit(1);
skipper:
submaker(&&hidden);
}

(breakfree is an assembler snippet that sets the basepointer to the one of the
over-overliying function and calls the parameter.)

the problem is that any stuff between ,,hidden'' and ,,skipper'' is removed.

there is no 90 90 CC CC CC CC CC 90 90 90 90 in the resulting elf binary.

Problem: there is no safe work-around because you cannot switch off dead code
elimination even on -O0!
you cannot declare the labels as extern, either.
The problem disappears when you add one calculated goto jump to the function,
but if that should not be taken, it is eliminated, too!

[Bug preprocessor/54528] New: [4.8 Regression] system.h:288:78: error: integer overflow in expression

[danglin at gcc dot gnu.org]

gcc/mcf.c:543:23: note: in expansion of macro 'CAP_INFINITY'
   CAP_INFINITY);
   ^
../../gcc/gcc/mcf.c: In function ‘bool cancel_negative_cycle(fixup_graph_type*,
int*, gcov_type*, int*)’:
../../gcc/gcc/system.h:288:78: error: integer overflow in expression
[-Werror=overflow]
  ? ~ (t) 0 << (sizeof(t) * CHAR_BIT - 1) : (t) 0))
  ^
../../gcc/gcc/system.h:289:44: note: in expansion of macro 'INTTYPE_MINIMUM'
 #define INTTYPE_MAXIMUM(t) ((t) (~ (t) 0 - INTTYPE_MINIMUM (t)))
^
../../gcc/gcc/mcf.c:55:22: note: in expansion of macro 'INTTYPE_MAXIMUM'
 #define CAP_INFINITY INTTYPE_MAXIMUM (HOST_WIDEST_INT)
  ^
../../gcc/gcc/mcf.c:806:14: note: in expansion of macro 'CAP_INFINITY'
   d[i] = CAP_INFINITY;
  ^
../../gcc/gcc/system.h:288:78: error: integer overflow in expression
[-Werror=overflow]
  ? ~ (t) 0 << (sizeof(t) * CHAR_BIT - 1) : (t) 0))
  ^
../../gcc/gcc/system.h:289:44: note: in expansion of macro 'INTTYPE_MINIMUM'
 #define INTTYPE_MAXIMUM(t) ((t) (~ (t) 0 - INTTYPE_MINIMUM (t)))
^
../../gcc/gcc/mcf.c:55:22: note: in expansion of macro 'INTTYPE_MAXIMUM'
 #define CAP_INFINITY INTTYPE_MAXIMUM (HOST_WIDEST_INT)
  ^
../../gcc/gcc/mcf.c:822:34: note: in expansion of macro 'CAP_INFINITY'
 && d[pfedge->src] != CAP_INFINITY
  ^
../../gcc/gcc/system.h:288:78: error: integer overflow in expression
[-Werror=overflow]
  ? ~ (t) 0 << (sizeof(t) * CHAR_BIT - 1) : (t) 0))
  ^
../../gcc/gcc/system.h:289:44: note: in expansion of macro 'INTTYPE_MINIMUM'
 #define INTTYPE_MAXIMUM(t) ((t) (~ (t) 0 - INTTYPE_MINIMUM (t)))
^
../../gcc/gcc/mcf.c:55:22: note: in expansion of macro 'INTTYPE_MAXIMUM'
 #define CAP_INFINITY INTTYPE_MAXIMUM (HOST_WIDEST_INT)
  ^
../../gcc/gcc/mcf.c:845:32: note: in expansion of macro 'CAP_INFINITY'
   && d[pfedge->src] != CAP_INFINITY
^
../../gcc/gcc/system.h:288:78: error: integer overflow in expression
[-Werror=overflow]
  ? ~ (t) 0 << (sizeof(t) * CHAR_BIT - 1) : (t) 0))
  ^
../../gcc/gcc/system.h:289:44: note: in expansion of macro 'INTTYPE_MINIMUM'
 #define INTTYPE_MAXIMUM(t) ((t) (~ (t) 0 - INTTYPE_MINIMUM (t)))
^
../../gcc/gcc/mcf.c:55:22: note: in expansion of macro 'INTTYPE_MAXIMUM'
 #define CAP_INFINITY INTTYPE_MAXIMUM (HOST_WIDEST_INT)
  ^
../../gcc/gcc/mcf.c:886:16: note: in expansion of macro 'CAP_INFINITY'
   cycle_flow = CAP_INFINITY;
^
../../gcc/gcc/mcf.c: In function ‘gcov_type find_max_flow(fixup_graph_type*,
int, int)’:
../../gcc/gcc/system.h:288:78: error: integer overflow in expression
[-Werror=overflow]
  ? ~ (t) 0 << (sizeof(t) * CHAR_BIT - 1) : (t) 0))
  ^
../../gcc/gcc/system.h:289:44: note: in expansion of macro 'INTTYPE_MINIMUM'
 #define INTTYPE_MAXIMUM(t) ((t) (~ (t) 0 - INTTYPE_MINIMUM (t)))
^
../../gcc/gcc/mcf.c:55:22: note: in expansion of macro 'INTTYPE_MAXIMUM'
 #define CAP_INFINITY INTTYPE_MAXIMUM (HOST_WIDEST_INT)
  ^
../../gcc/gcc/mcf.c:1056:29: note: in expansion of macro 'CAP_INFINITY'
   gcov_type increment = CAP_INFINITY;
 ^
cc1plus: all warnings being treated as errors
make[3]: *** [mcf.o] Error 1

dave@mx3210:~/gnu/gcc/objdir/prev-gcc$ ./xgcc -B./ -v
Reading specs from ./specs
COLLECT_GCC=./xgcc
COLLECT_LTO_WRAPPER=./lto-wrapper
Target: hppa-linux-gnu
Configured with: ../gcc/configure --with-gnu-as --with-gnu-ld --enable-shared
--enable-multiarch --with-multiarch-defaults=hppa-linux-gnu
--enable-linker-build-id --build=hppa-linux-gnu --host=hppa-linux-gnu
--target=hppa-linux-gnu --prefix=/home/dave/opt/gnu/gcc/gcc-4.8.0
--with-local-prefix=/home/dave/opt/gnu --enable-threads=posix
--enable-__cxa_atexit --build=hppa-linux-gnu --enable-clocale=gnu
--enable-java-gc=boehm --without-cloog --without-ppl
--enable-languages=c,c++,objc,fortran,obj-c++,java,ada,lto
Thread model: posix
gcc version 4.8.0 20120908 (experimental) [trunk revision 191088] (GCC)

[Bug bootstrap/39572] x86_64-*-openbsd* is not supported yet

[rob1weld at aol dot com]

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

--- Comment #4 from Rob  2012-09-08 15:17:11 UTC ---
Thank you, one and all.

[Bug c++/54527] wcout breaks on win32 console

[vurentjie at gmail dot com]

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

--- Comment #1 from vurentjie  2012-09-08 14:19:45 
UTC ---
i did try follow this deeper, but the __ostream_insert specialization for
wchar_t is not in ostream_insert.h,

but it seems to be declared in ostream-inst.cc (libstd++ implementation)

i may decide to look further but first want to hear if there is something i am
missing

[Bug c++/54527] New: wcout breaks on win32 console

[vurentjie at gmail dot com]

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

 Bug #: 54527
   Summary: wcout breaks on win32 console
Classification: Unclassified
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: blocker
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vurent...@gmail.com


this case does not seem to work... 

the wide character does not print, nor does the "...done" part, 

this is only an issue for windows console...

#include 
#include 

int main(int argc, char** argv){

SetConsoleOutputCP(1200);

wchar_t out[3]={0,0x000a,wchar_t()};
int characters = 1000;

while(characters--){
out[0]=wchar_t(characters);
std::wcout << out << "...done";
}

}


...this case does work however, and where no glyph is found for the character
the square replacement is used


#include 
#include 

int main(int argc, char** argv){

SetConsoleOutputCP(1200);

wchar_t out[10]={0,0x000a,'.','.','.','d','o','n','e',wchar_t()};
int characters = 1000;

   HANDLE stdout = GetStdHandle(STD_OUTPUT_HANDLE);
DWORD n;
while(characters--){
out[0]=wchar_t(characters);
WriteConsoleW( stdout, out, 10, &n, NULL );
}

return 0;

}



i am not sure if this has anything to do with the default locale, 

or how to fix it without resorting to windows-specific api instead of
std::wcout

[Bug c++/54521] g++ fails to call explicit constructors in the second step of copy initialization

[tsoae at mail dot ru]

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

--- Comment #3 from Nikolka  2012-09-08 13:25:20 UTC ---
In both cases (for g++ v4.7.1 and v4.8.0) the only compiler option was
-std=c++11. Nothing magical.

[Bug rtl-optimization/54524] Spurious add on sum of bitshifts

[jan.sm...@alcatel-lucent.com]

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

--- Comment #1 from Jan Smets  2012-09-08 
13:18:48 UTC ---
Created attachment 28152
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28152
testcase

The result is correct with -fno-forward-propagate

tUint64 is unsigned long long I meant. 


An even more reduced testcase is attached. Compile it with a MIPS cross
compiler:

./gcc  -nostdinc -funsigned-char  -fno-builtin -G 0 -mno-gpopt -msoft-float
-fno-merge-constants -pipe -Wall -O2 -fno-optimize-sibling-calls
-fno-partial-inlining -fno-reorder-blocks -fno-strict-aliasing  -c /tmp/test.c
-o test -mabi=32

[Bug c++/54526] New: <:: is incorrectly treated as digraph <: followed by colon

[tsoae at mail dot ru]

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

 Bug #: 54526
   Summary: <:: is incorrectly treated as digraph <: followed by
colon
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: ts...@mail.ru


g++ 4.8.0 20120826 (experimental) fails to compile the following well-defined
code:

template 
struct X {};

struct A {};

int main()
{
X<::A> x; // error: ‘<::’ cannot begin a template-argument list
}

According to C++11 - 2.5 p3, bullet 2:

If the input stream has been parsed into preprocessing tokens up to a given
character:
... if the next three characters are <:: and the subsequent character is
neither : nor >, the < is treated as a preprocessor token by itself and not as
the first character of the alternative token <:.

Compiler version info:

Target: i686-pc-linux-gnu
Configured with: .../configure --prefix=.../target --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120826 (experimental) (GCC)

Command line:

g++ test.cpp -std=c++11 -pedantic-errors

Diagnostic message:

test.cpp: In function ‘int main()’:
test.cpp:8:10: error: ‘<::’ cannot begin a template-argument list
[-fpermissive]
 X<::A> x;
  ^
test.cpp:8:10: note: ‘<:’ is an alternate spelling for ‘[’. Insert whitespace
between ‘<’ and ‘::’
test.cpp:8:10: note: (if you use ‘-fpermissive’ G++ will accept your code)

[Bug c++/54521] g++ fails to call explicit constructors in the second step of copy initialization

[tsoae at mail dot ru]

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

--- Comment #2 from Nikolka  2012-09-08 12:36:29 UTC ---
(In reply to comment #1)
> Works fine with 4.6.3, 4.7.2 20120716 (prerelease) and 
> 4.8.0 20120716 (experimental)
> 
> As requested when submitting the bug, please provide the information requested
> at http://gcc.gnu.org/bugs/ including the command line and output of gcc -v

1) Version info:

Target: i686-pc-mingw32
Configured with: ../src/configure --prefix=/c/temp/gcc/dest
--with-gmp=/c/temp/gcc/gmp --with-mpfr=/c/temp/gcc/mpfr
--with-mpc=/c/temp/gcc/mpc --enable-languages=c,c++ --with-arch=i686
--with-tune=generic --disable-libstdcxx-pch --disable-nls --disable-shared
--disable-sjlj-exceptions --disable-win32-registry --enable-checking=release
--enable-lto
Thread model: win32
gcc version 4.7.1 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-std=c++11' '-mtune=generic' '-march=i686'

c:/common/c++/mingw/mingw-gcc-4.7.1/bin/../libexec/gcc/i686-pc-mingw32/4.7.1/cc1plus.exe
-quiet -v -iprefix ..\bin\../lib/gcc/i686-pc-mingw32/4.7.1/ test.cpp -quiet
-dumpbase test.cpp -mtune=generic -march=i686 -auxbase test -std=c++11 -version
-o
GNU C++ (GCC) version 4.7.1 (i686-pc-mingw32)
compiled by GNU C version 4.7.1, GMP version 5.0.5, MPFR version 3.1.0-p10,
MPC version 0.9

Diagnostic message:

test.cpp: In function 'int main()':
test.cpp:9:15: error: no matching function for call to 'X::X(X)'
test.cpp:9:15: note: candidate is:
test.cpp:3:9: note: X::X(int)
test.cpp:3:9: note:   no known conversion for argument 1 from 'X' to 'int'

2) Version info:

Target: i686-pc-linux-gnu
Configured with: .../configure --prefix=.../target --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120826 (experimental) (GCC)

Diagnostic message:

test.cpp: In function ‘int main()’:
test.cpp:9:15: error: no matching function for call to ‘X::X(X)’
 X x = 1; // error: no matching function for call to 'X::X(X)'
   ^
test.cpp:9:15: note: candidate is:
test.cpp:3:9: note: X::X(int)
 X(int) {}
 ^
test.cpp:3:9: note:   no known conversion for argument 1 from ‘X’ to ‘int’

[Bug c++/54506] Defaulted move constructors and move assignment operators are erroneously defined as deleted

[tsoae at mail dot ru]

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

--- Comment #2 from Nikolka  2012-09-08 12:17:24 UTC ---
(In reply to comment #1)
> How are you calling g++?

/mingw-gcc-4.7.1/bin/g++ test.cpp -std=c++11

> What version are you using?

Target: i686-pc-mingw32
Configured with: ../src/configure --prefix=/c/temp/gcc/dest
--with-gmp=/c/temp/gcc/gmp --with-mpfr=/c/temp/gcc/mpfr
--with-mpc=/c/temp/gcc/mpc --enable-languages=c,c++ --with-arch=i686
--with-tune=generic --disable-libstdcxx-pch --disable-nls --disable-shared
--disable-sjlj-exceptions --disable-win32-registry --enable-checking=release
--enable-lto
Thread model: win32
gcc version 4.7.1 (GCC) 

> What is the diagnostic you get?

test.cpp: In function 'int main()':
test.cpp:25:17: error: use of deleted function 'B::B(B&&)'
test.cpp:19:9: note: 'B::B(B&&)' is implicitly deleted because the default
definition would be ill-formed:
test.cpp:19:9: error: non-static data member 'B::a' does not have a move
constructor or trivial copy constructor
test.cpp:26:15: error: use of deleted function 'B& B::operator=(B&&)'
test.cpp:20:12: note: 'B& B::operator=(B&&)' is implicitly deleted because the
default definition would be ill-formed:
test.cpp:20:12: error: non-static data member 'B::a' does not have a move
assignment operator or trivial copy assignment operator

[Bug tree-optimization/54525] New: Recognize (vec_)cond_expr in mask operation

[glisse at gcc dot gnu.org]

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

 Bug #: 54525
   Summary: Recognize (vec_)cond_expr in mask operation
Classification: Unclassified
   Product: gcc
   Version: 4.8.0
Status: UNCONFIRMED
  Severity: enhancement
  Priority: P3
 Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gli...@gcc.gnu.org


Hello,

it would be nice to recognize cond_expr and vec_cond_expr in (a&mask)|(b&~mask)
where mask is (a vector of) 0 or -1. It would be particularly useful for
vectors, for which we don't have any explicit way (yet?) to ask for a
vec_cond_expr.

unsigned f(unsigned x,unsigned y,_Bool b){
  unsigned m=b?-1:0;
  return (x&m)|(y&~m);
}
unsigned g(unsigned x,unsigned y,_Bool b){
  return b?x:y;
}

typedef long vec __attribute__((vector_size(16)));
vec h(vec x, vec y, vec z, vec t){
  vec m=(z >= and even
with a ~ in front) generate a combination of gt and eq, never just gt)

while avx has vpblendvb.

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[redi at gcc dot gnu.org]

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

--- Comment #54 from Jonathan Wakely  2012-09-08 
11:00:36 UTC ---
I've tested the patch myself now, it's ok, please commit it asap (but in future
remember to send patches to the libstdc++ list as well as gcc-patches, I could
have approved it sooner had I seen it)

[Bug bootstrap/54419] [4.8 Regression] Compiling libstdc++-v3/src/c++11/random.cc fails on platforms not knowing rdrand

[redi at gcc dot gnu.org]

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

--- Comment #53 from Jonathan Wakely  2012-09-08 
10:40:31 UTC ---
Please post the patch to the right list and I'll approve it, all libstdc++
patches need to go to the libstdc++ list.

[Bug rtl-optimization/54524] New: Spurious add on sum of bitshifts

[jan.sm...@alcatel-lucent.com]

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

 Bug #: 54524
   Summary: Spurious add on sum of bitshifts
Classification: Unclassified
   Product: gcc
   Version: 4.6.3
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: rtl-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.sm...@alcatel-lucent.com


There is an spurious addiua2,a2,1   which causes the result to be
incorrect.


tUint32 is unsigned long long


MIPS O32
GCC 4.6.3

 -nostdinc -funsigned-char  -fno-builtin -march=mips2 -G 0 -mno-gpopt
-msoft-float -fno-merge-constants -pipe -Wall -O2 -fno-optimize-sibling-calls
-fno-partial-inlining -fno-reorder-blocks -fno-strict-aliasing 


PUBLIC void function(
tUint32  index160,
tUint8 * data)
{
tUint8temp_data[160/8];
tUint32   scrambled_address;

*(tUint64*)(temp_data+8)  = *(tUint64*)(data+8);

scrambled_address = index160;

printf("%16llX.\n",
   0x4040ull +
   (((tUint64)*(tUint16*)(temp_data+12)) << 24) +
   ((tUint64)(scrambled_address & 0xFF) << 56));
}


0x364c70c  27bdffd0addiusp,sp,-48
0x364c710  afbf002csw   ra,44(sp)
0x364c714  8ca8000clw   t0,12(a1)   t0 = pp qq rr ss
0x364c718  3c030040lui  v1,0x40 v1 = 00 40 00 00
0x364c71c  3c024000lui  v0,0x4000   v0 = 40 00 00 00
0x364c720  00085402srl  t2,t0,16t2 = 00 00 pp qq
0x364c724  000a4e00sll  t1,t2,24t1 = qq 00 00 00
0x364c728  01233821addu a3,t1,v1a3 = qq 40 00 00
0x364c72c  000a5202srl  t2,t2,8 t2 = 00 00 00 pp
0x364c730  00e9482bsltu t1,a3,t1t1 = carry?
0x364c734  01421021addu v0,t2,v0v0 = 40 00 00 pp
0x364c738  00042600sll  a0,a0,24a0 = index160 << 24
0x364c73c  8ca30008lw   v1,8(a1)
0x364c740  01221021addu v0,t1,v0v0 += carry
0x364c744  00443021addu a2,v0,a0a2 = v0 + index160 << 24
0x364c748  3c04066elui  a0,0x66e\_ String address
0x364c74c  24842084addiua0,a0,8324  /
0x364c750  24c60001addiua2,a2,1 - Spurious add
0x364c754  afa30018sw   v1,24(sp)
0x364c758  0cb402e1jal  printf  - Takes a0 = string. a1 = low word,
a2 = high word
0x364c75c  afa8001csw   t0,28(sp)
0x364c760  8fbf002clw   ra,44(sp)
0x364c764  8fe0lw   zero,0(ra)   (internal extension)
0x364c768  03e8jr   ra
0x364c76c  27bd0030addiusp,sp,48

[Bug fortran/54208] [4.6/4.7/4.8 Regression] compilation error for ubound construct in PARAMETER statements

[mikael at gcc dot gnu.org]

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

--- Comment #6 from Mikael Morin  2012-09-08 
09:23:00 UTC ---
Author: mikael
Date: Sat Sep  8 09:22:54 2012
New Revision: 191090

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=191090
Log:
fortran/
PR fortran/54208
* simplify.c (simplify_bound_dim): Resolve array spec before
proceeding with simplification.

testsuite/
PR fortran/54208
* gfortran.dg/bound_simplification_3.f90: New test.


Added:
   
branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/bound_simplification_3.f90
Modified:
branches/gcc-4_7-branch/gcc/fortran/ChangeLog
branches/gcc-4_7-branch/gcc/fortran/simplify.c
branches/gcc-4_7-branch/gcc/testsuite/ChangeLog

[Bug c++/54518] A problem using -O2 with g++4.5.0 and g++4.6.0 (see titi.cc)

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 Resolution||FIXED

--- Comment #5 from Paolo Carlini  2012-09-08 
08:54:51 UTC ---
Fixed.

[Bug libstdc++/54523] srand() initializing seed for random() function

[paolo.carlini at oracle dot com]

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

Paolo Carlini  changed:

   What|Removed |Added

 Status|UNCONFIRMED |RESOLVED
 CC|jm3dev at gmail dot com |
 Resolution||MOVED

--- Comment #1 from Paolo Carlini  2012-09-08 
08:38:03 UTC ---
If anything, this is a glibc problem.