[Bug c++/52816] New: Access to private members inside decltype in the signature of a member template causes access control error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52816
Bug #: 52816
Summary: Access to private members inside decltype in the
signature of a member template causes access control
error
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jewil...@osl.iu.edu
When using decltype inside the return type of a member function template, I
receive access control errors for references to private member variables. Here
is a simple example of a failing program:
class c {
int f;
public:
template typename A
decltype(f) m(A) const;
};
decltype(c{}.m(0)) i;
The use of old- vs. new-style function declarations does not change the
behavior; neither does whether the class itself is a template. The error I get
from GCC 4.7.0 is:
test.cpp:2:7: error: ‘int c::f’ is private
test.cpp:8:20: error: within this context
I think that is likely to be incorrect since the reference to f is from inside
the body of the class definition itself.
[Bug rtl-optimization/44141] Redundant loads and stores generated for AMD bdver1 target
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=44141
--- Comment #15 from Venkataramanan venkataramanan.kumar at amd dot com
2012-04-01 07:55:24 UTC ---
Hi Uros,
I had a look at reload pass.
I have an RTL sequence that look like this.
(insn 32 31 33 2 (set (subreg:V4SF (reg:V2DF 284) 0) == psuedo reguster
(unspec:V4SF [
(mem/c:V4SF (plus:DI (reg/f:DI 20 frame)
(const_int -568 [0xfdc8])) [3
MEM[(real(kind=8)[26] *)dsroo + 120B]+0 S16 A64])
] UNSPEC_MOVU)) test.f90:16 1106 {*sse_movups}
(nil))
(insn 33 32 371 2 (set (reg:V2DF 285) = pseudo register
(div:V2DF (reg:V2DF 284) == pseudo register
(mem/c:V2DF (plus:DI (reg/f:DI 20 frame)
(const_int -576 [0xfdc0])) [3
MEM[(real(kind=8)[26] *)dsroo + 112B]+0 S16 A128]))) test.f90:16 1146
{sse2_divv2df3}
(nil))
Now reload examines the first RTL.
(insn 32 31 33 2 (set (subreg:V4SF (reg:V2DF 284) 0) == psuedo reguster
(unspec:V4SF [
(mem/c:V4SF (plus:DI (reg/f:DI 20 frame)
(const_int -568 [0xfdc8])) [3
MEM[(real(kind=8)[26] *)dsroo + 120B]+0 S16 A64])
] UNSPEC_MOVU)) test.f90:16 1106 {*sse_movups}
(nil))
This did not get an Hard register and so at reload it chooses xmm0 and
generates an output reload as follows.
(insn 393 0 0 (set (reg:V2DF 284)
(reg:V2DF 21 xmm0)) -1
There is possiblity of reload inheritenace and we can avoid input reload for
the next RTL insn 33
(insn 33 32 371 2 (set (reg:V2DF 285)
(div:V2DF (reg:V2DF 284)
(mem/c:V2DF (plus:DI (reg/f:DI 20 frame)
(const_int -576 [0xfdc0])) [3
MEM[(real(kind=8)[26] *)dsroo + 112B]+0 S16 A128]))) test.f90:16 1146
{sse2_divv2df3}
(nil))
But It is not happening and input reload gets generated again before this RTL
as follows:
(insn 395 0 0 (set (reg:V2DF 21 xmm0)
(reg:V2DF 284)
Also another outpout reload gets emitted after the insn 33 for its output
reload as
(insn 394 0 0 (set (reg:V2DF 285)
(reg:V2DF 21 xmm0)) -1. But I am not sure If this computation prevented input
reload inheritence in the insn 33 .
I suspect emit_reload_insns is not preserving output reloads in insn32 for
further inheritence insn33.
Please povide your opinion.
[Bug c++/52817] New: g++ do not call a method with same name on some platforms(see small example source attached)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52817
Bug #: 52817
Summary: g++ do not call a method with same name on some
platforms(see small example source attached)
Classification: Unclassified
Product: gcc
Version: 4.5.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: nospamn...@web.de
See below testprogram for C++.this give on X86 cygwin correct output and i
guess it work on some other platforms too
( this codestyle is used in dunelegacy game). All Compiler i test run on same
OS (windows - cygwin).Only Compiler Options that use. -Wall and -Wextra. But
they give no report on all compilers.
BTW: this is no April joke, i ask about Problem in GCC ML, and i get the answer
to write a Bugreport.
Output from X86 cygwin build (this is ok)
constructor wsafile
readdata 1 called
readdata 2 called
12345678 ( should be 0x12345678) 1 (should be 1)
But with all 68k compilers for amigaos (i test from GCC 3.4.0 to 4.5.x Version
and some between) this execute always wrong.readdata 1 Funtion
is never called and the transfer of the adrress fail
Output from all m68k amigaos g++ cygwin hostet (this is wrong)
constructor wsafile
readdata 2 called
0 ( should be 0x12345678) 1 (should be 1)
What can be the problem.I dont understand wy the backend can cause such a
problem. How is that possible
here is the test program
#include stdarg.h
#include stdio.h
class Wsafile
{
public:
Wsafile(long* RWop);
Wsafile(long* RWop0, long* RWop1);
Wsafile(int num,...);
virtual ~Wsafile();
private:
void readdata(int NumFiles, ...);
void readdata(int NumFiles, va_list args);
};
/// Constructor
/**
The constructor reads from the RWop all data and saves them internal. The
SDL_RWops can be readonly but must support
seeking. Immediately after the Wsafile-Object is constructed RWop can be
closed. All data is saved in the class.
\paramRWopSDL_RWops to the wsa-File. (can be readonly)
*/
Wsafile::Wsafile(long *RWop)
{
printf(constructor wsafile\n);
readdata(1,RWop);
}
/// Destructor
Wsafile::~Wsafile()
{
printf(free reach\n);
}
void Wsafile::readdata(int NumFiles, ...) {
printf(readdata 1 called \n);
va_list args;
va_start(args,NumFiles);
readdata(NumFiles,args);
va_end(args);
}
void Wsafile::readdata(int NumFiles, va_list args) {
long * RWop;
printf(readdata 2 called \n);
RWop = va_arg(args,long *);
printf (%x ( should be 0x12345678) %d (should be 1) \n,(unsigned
int)RWop,NumFiles); // should print 0x12345678
}
int
main()
{
long * addr = ( long *)0x12345678;
new Wsafile(addr);
}
[Bug inline-asm/52813] %rsp in clobber list is silently ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52813 Uros Bizjak ubizjak at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #1 from Uros Bizjak ubizjak at gmail dot com 2012-04-01 09:21:09 UTC --- The compiler doesn't analyse asm string.
temacs segfaults w/MALLOC_PERTURB_!=0 when compiling with gcc-4.8.0
I bootstrap emacs from bzr every two or three days, using whatever gcc happens to be in my PATH. The last successful build/install was on March 28th. However, as far as I can see, the new problem is coming from the tools I'm using, and not from emacs, since attempting to build that previously-succeeding commit now evokes a segfault. It's easy to paper over the problem. My (failing) build procedure does this to cancel the effect of my always-set MALLOC_CHECK_ envvar: make bootstrap RUN_TEMACS='MALLOC_CHECK_=0 ./temacs' also making it turn off MALLOC_PERTURB_ works around the immediate problem. With this, the build completes normally: make bootstrap RUN_TEMACS='MALLOC_PERTURB_=0 MALLOC_CHECK_=0 ./temacs' But that probably just masks the real problem. This is happening on an x86_64 F17 system, when I use built-from-svn gcc-4.8.0 20120327 or newer (confirmed segfault also with today's 4.8.0 20120401). However, using the stock gcc, (aka gcc-4.7.0-1.fc17.x86_64), there is no problem. Using valgrind the problem does not arise. Same story when using gdb directly, so below I let it generate a core file and ran gdb on that. It suggests that alloc.c's mark_object is dereferencing a freed pointer, due to the pattern of 0x22 bytes scribbled into the pointer: #0 mark_object (arg=optimized out) at /h/j/w/co/emacs/trunk/src/alloc.c:5616 5616if (ptr-gcmarkbit) (gdb) p *ptr Cannot access memory at address 0x2220 I.e., to reproduce this failure, you would run this: ./configure CC=/path-to-gcc-4.8.0/bin \ env MALLOC_PERTURB_=88 \ make bootstrap RUN_TEMACS='MALLOC_CHECK_=0 ./temacs' If no one beats me to it, later in the week I'll bisect gcc until I find the commit that changes whether ./temacs segfaults. Here's the tail of the build log and the temacs backtrace: --- cd ../lisp; make -w --jobserver-fds=3,4 - --jobserver-fds=3,4 - --jobserver-fds=3,4 - --jobserver-fds=3,4 -j update-subdirs make[3]: Entering directory `/t/jt-dzv4F3/emacs/lisp' cd /h/j/w/co/emacs/trunk/lisp; subdirs=`(find . -type d -print)`; for file in $subdirs; do case $file in */.* | */.*/* | */=* | */cedet* ) ;; *) wins=$wins $file ;; esac; done; \ for file in $wins; do \ /h/j/w/co/emacs/trunk/update-subdirs $file; \ done; make[3]: Leaving directory `/t/jt-dzv4F3/emacs/lisp' if test no = yes; then \ ln -f temacs bootstrap-emacs; \ else \ MALLOC_CHECK_=0 ./temacs --batch --load loadup bootstrap || exit 1; \ mv -f emacs bootstrap-emacs; \ fi Loading loadup.el (source)... Using load-path (/h/j/w/co/emacs/trunk/lisp /h/j/w/co/emacs/trunk/lisp/emacs-lisp /h/j/w/co/emacs/trunk/lisp/language /h/j/w/co/emacs/trunk/lisp/international /h/j/w/co/emacs/trunk/lisp/textmodes) Loading emacs-lisp/byte-run (source)... Loading emacs-lisp/backquote (source)... Loading subr (source)... Loading version.el (source)... Loading widget (source)... Loading custom (source)... Loading emacs-lisp/map-ynp (source)... Loading cus-start (source)... Loading international/mule (source)... Loading international/mule-conf (source)... Loading env (source)... Loading format (source)... Loading bindings (source)... Loading window (source)... Loading /h/j/w/co/emacs/trunk/lisp/files.el (source)... Loading /h/j/w/co/emacs/trunk/lisp/cus-face.el (source)... Loading /h/j/w/co/emacs/trunk/lisp/faces.el (source)... Loading /h/j/w/co/emacs/trunk/lisp/button.el (source)... Loading /h/j/w/co/emacs/trunk/lisp/startup.el (source)... Loading /h/j/w/co/emacs/trunk/lisp/ldefs-boot.el (source)... Loading /h/j/w/co/emacs/trunk/lisp/minibuffer.el (source)... Loading /h/j/w/co/emacs/trunk/lisp/abbrev.el (source)... Loading /h/j/w/co/emacs/trunk/lisp/simple.el (source)... Loading /h/j/w/co/emacs/trunk/lisp/help.el (source)... Loading /h/j/w/co/emacs/trunk/lisp/jka-cmpr-hook.el (source)... Loading /h/j/w/co/emacs/trunk/lisp/epa-hook.el (source)... Loading /h/j/w/co/emacs/trunk/lisp/international/mule-cmds.el (source)... Loading /h/j/w/co/emacs/trunk/lisp/case-table.el (source)... Loading /h/j/w/co/emacs/trunk/lisp/international/charprop.el (source)... Loading /h/j/w/co/emacs/trunk/lisp/international/characters.el (source)... /bin/sh: line 5: 22643 Segmentation fault (core dumped) MALLOC_CHECK_=0 ./temacs --batch --load loadup bootstrap make[2]: *** [bootstrap-emacs] Error 1 make[2]: Leaving directory `/t/jt-dzv4F3/emacs/src' make[1]: *** [src] Error 2 make[1]: Leaving directory `/t/jt-dzv4F3/emacs' make: *** [bootstrap] Error 2 [2] + exit 2 ( prefix=/p/p/$pkg-$date ; set -e; local cc; cc=gcc ; cc=/usr/bin/gcc ; ; $ rlo ioui11 $ rlo iou11 $ pwd /t/jt-dzv4F3/emacs $ cvu $ [Exit 1] $ cd src $ ulimit -c unlimited $ MALLOC_CHECK_=0 ./temacs --batch --load loadup bootstrap Loading loadup.el (source)... Using load-path (/h/j/w/co/emacs/trunk/lisp /h/j/w/co/emacs/trunk/lisp/emacs-lisp /h/j/w/co/emacs/trunk/lisp/language /h/j/w/co/emacs/trunk/lisp/international /h/j/w/co/emacs/trunk/lisp
[Bug c++/52818] New: printf format %lf is erroneously rejected by C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52818
Bug #: 52818
Summary: printf format %lf is erroneously rejected by C++11
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: trivial
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joedoefawnb...@googlemail.com
C99, and thus C++11, allow %lf as a synonym for %f as a printf format
specifier. However, with `-pedantic -Wformat -std=c++11`, GCC 4.7. emits a
warning:
#include cstdio
int main() { return std::printf(%lf, 0.0); }
warning: ISO C++ does not support the ‘%lf’ gnu_printf format [-Wformat]
The same holds for -std=c99 and -std=c11.
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #26 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-01 11:24:14 UTC --- (In reply to comment #24) Personally, I don't believe Gaby is open to other solutions outside the full-fledged caret diagnostics context, thus for the time being at least I'm personally going to stand to his judgment (as diagnostics maintainer). The caret is not a solution to this problem, because what Gabriel wants is to not reconstruct expressions ONLY when the caret is shown, but he has said in the past that the caret should default to OFF to not change the current output for IDEs and other software parsing the output of gcc like emacs, so we are back to printing the monsters mentioned above by default. This is another reason why I am not motivated to keep working on the caret. What is the point if it is going to default to OFF anyway? That and that moving line-map out of libcpp to create a source-location library has been rejected in the past. And there is no compromise solution. The only argument in favor of pretty-printing expressions is to help identify the culprit in a complex expression, so printing only expressions that have non-expression operands will surely be rejected by Gabriel. Even if the caret was the solution, nobody has worked on it in the last 25 years, and now that we have good column information, I don't expect that there will be anyone working on it in the next 25. Specially now that there is a better alternative, because if you want nice diagnostics, why don't just use Clang?
[Bug c++/52818] printf format %lf is erroneously rejected by C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52818 --- Comment #1 from Kerrek SB joedoefawnbuck at googlemail dot com 2012-04-01 12:09:34 UTC --- Correction: The warnings do NOT appear (correctly so) for C99 and C11.
[Bug c++/52819] New: ICE: tree check: expected tree that contains 'decl minimal' structure, have 'nop_expr' in decl_linkage, at cp/tree.c:3136
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52819
Bug #: 52819
Summary: ICE: tree check: expected tree that contains 'decl
minimal' structure, have 'nop_expr' in decl_linkage,
at cp/tree.c:3136
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gessos.p...@yahoo.gr
--- g++ -v ---
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=../libexec/gcc/x86_64-w64-mingw32
/4.7.0/lto-wrapper.exe
Target: x86_64-w64-mingw32
Configured with: .../build/gcc/src/configure --target=x86_64-w64-mingw32 --
prefix=/c/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root
--with-sysroot=/c
/bb/vista64-mingw32/mingw-x86-x86_64/build/build/root
--enable-languages=all,obj
-c++ --enable-fully-dynamic-string --disable-multilib
Thread model: win32
gcc version 4.7.0 20111220 (experimental) (GCC)
--
--- g++ -std=c++11 code.cpp ---
typedef void (*cfi)(void*);
void function(int *a) {}
templatecfi Func
void get() { Func(0); }
int main()
{
get(cfi) function();
return 0;
}
[Bug c++/52817] g++ do not call a method with same name on some platforms(see small example source attached)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52817
--- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-01
12:37:00 UTC ---
(In reply to comment #0)
void Wsafile::readdata(int NumFiles, va_list args) {
long * RWop;
printf(readdata 2 called \n);
RWop = va_arg(args,long *);
printf (%x ( should be 0x12345678) %d (should be 1) \n,(unsigned
int)RWop,NumFiles); // should print 0x12345678
This line is probably the problem, unsigned int is too small to hold a pointer
value, so the value is not preserved.
Stop using unsafe casts between incompatible types.
[Bug c++/52817] g++ do not call a method with same name on some platforms(see small example source attached)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52817
--- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-01
12:43:56 UTC ---
(In reply to comment #1)
(In reply to comment #0)
void Wsafile::readdata(int NumFiles, va_list args) {
long * RWop;
printf(readdata 2 called \n);
RWop = va_arg(args,long *);
printf (%x ( should be 0x12345678) %d (should be 1) \n,(unsigned
int)RWop,NumFiles); // should print 0x12345678
This line is probably the problem, unsigned int is too small to hold a pointer
value, so the value is not preserved.
Stop using unsafe casts between incompatible types.
Or it could just be the difference between pointer and integer modes for m68k,
does it help if you change it to this?
printf (%p ( should be 0x12345678) %d (should be 1) \n, RWop,NumFiles);
[Bug c++/52817] g++ do not call a method with same name on some platforms(see small example source attached)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52817 --- Comment #3 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-01 12:46:58 UTC --- (In reply to comment #1) Stop using unsafe casts between incompatible types. That is the least of the worries here. The real issue is how is va_list implemented on some target. There is no one right way of implementing va_list. It could be implemented as an array or a struct. Can you provide the preprocessed source? It might be a bug in the headers you are using or it could be just the way va_list is implemented (as a void*).
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #27 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-01 12:55:34 UTC --- (In reply to comment #26) because if you want nice diagnostics, why don't just use Clang? Because G++ gives much better diagnostics for template argument deduction failures, so just use clang isn't a solution even if all you care about is better diagnostics.
[Bug middle-end/52820] New: [4.8 Regression] ICE in create_preheader, at cfgloopmanip.c:1363
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52820
Bug #: 52820
Summary: [4.8 Regression] ICE in create_preheader, at
cfgloopmanip.c:1363
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middle-end
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mar...@trippelsdorf.de
% cat test.i
int **fn1 () __attribute__ ((__const__));
main () {
int i;
i = 0;
for (;; i++)
if (*fn1 ()[i] !'a' = 0 i = 'z' || *fn1 ()[0] 'a' = 'z')
return;
}
% gcc -c -O2 -fprofile-use test.i
test.i: In function ‘main’:
test.i:8:1: note: file /var/tmp/test.gcda not found, execution counts estimated
test.i:2:1: internal compiler error: in create_preheader, at
cfgloopmanip.c:1363
[Bug c++/52817] g++ do not call a method with same name on some platforms(see small example source attached)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52817 Andreas Schwab sch...@linux-m68k.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #4 from Andreas Schwab sch...@linux-m68k.org 2012-04-01 13:20:36 UTC --- Not a bug. An ellipses conversion sequence is worse than a standard conversion sequence, thus readdata(int,void*) is preferred over readdata(int,...) when the actual arguments are (int,long*).
[Bug c++/52817] g++ do not call a method with same name on some platforms(see small example source attached)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52817 --- Comment #5 from bernd_afa nospamname at web dot de 2012-04-01 13:22:22 UTC --- Created attachment 27057 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27057 preproc file
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152
--- Comment #28 from Manuel López-Ibáñez manu at gcc dot gnu.org 2012-04-01
13:23:01 UTC ---
(In reply to comment #27)
(In reply to comment #26)
because if you want nice diagnostics, why don't just use
Clang?
Because G++ gives much better diagnostics for template argument deduction
failures, so just use clang isn't a solution even if all you care about is
better diagnostics.
I am talking about the perspective of a new contributor that starts from zero
knowledge in both Clang and GCC. Then, it looks easier and it is in fact much
less effort to fix Clang to give the same diagnostics as g++ for template
argument deduction than to add caret diagnostics to GCC.
But my main point is that it is not a matter of effort: Even if g++ indeed
gives better diagnostics in some cases, this is either recognized as a bug in
Clang that can be fixed or it is a matter of opinion (more information versus
conciseness, assume users know the language standard terminology vs. use less
precise but more widely understandable language).
On the other hand, the current status is that the output of G++ is broken by
design and no patches will be accepted to change the design. Quoting
http://clang.llvm.org/diagnostics.html:
No Pretty Printing of Expressions in Diagnostics
Since Clang has range highlighting, it never needs to pretty print your code
back out to you. GCC can produce inscrutible error messages in some cases when
it tries to do this. In this example P and Q have type int*:
$ gcc-4.2 -fsyntax-only t.c
#'exact_div_expr' not supported by pp_c_expression#'t.c:12: error: called
object is not a function
$ clang -fsyntax-only t.c
t.c:12:8: error: called object type 'int' is not a function or function
pointer
(P-Q)();
~^
This can be particularly bad in G++ which often emits errors containing lowered
vtable references:
$ gcc-4.2 t.cc
t.cc: In function 'void test(foo*)':
t.cc:9: error: no match for 'operator+' in '(((a*)P) + (*(long
int*)(P-foo::anonymous.a::_vptr$a + -0x00020)))-a::bar() + * P'
t.cc:9: error: return-statement with a value, in function returning 'void'
$ clang t.cc
t.cc:9:18: error: invalid operands to binary expression ('int' and 'foo')
return P-bar() + *P;
^ ~~
[Bug c++/52817] g++ do not call a method with same name on some platforms(see small example source attached)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52817
--- Comment #6 from bernd_afa nospamname at web dot de 2012-04-01 13:26:40
UTC ---
Not a bug. An ellipses conversion sequence is worse than a standard conversion
sequence, thus readdata(int,void*) is preferred over readdata(int,...) when the
actual arguments are (int,long*).
The bad cast i only do to avoid extern include files. normaly it use SDL.
The problem happen because the address of the SDL_RWops structure is transfer
wrong. Same in the SDL program, because the 1. method Wsafile::readdata(int
NumFiles, ...) is not call on amigaos target.
Wsafile::Wsafile(SDL_RWops* RWop)
{
readdata(1,RWop);
}
I attach complete preprocessed file, va-list is used with
__builtin_va_list.currently i have test with 4.5.0 now but other compiler have
same include.
The include for stdarg.h come from the compiler build.
command line was this:
m68k-amigaos-g++ eh-vararg-3.cpp -Wall -Wextra -E preproc
the result
# 1 eh-vararg-3.cpp
# 1 built-in
# 1 command-line
# 1 eh-vararg-3.cpp
# 1 /usr/local/amiga/lib/gcc/m68k-amigaos/4.5.0/include/stdarg.h 1 3 4
# 43 /usr/local/amiga/lib/gcc/m68k-amigaos/4.5.0/include/stdarg.h 3 4
typedef __builtin_va_list __gnuc_va_list;
# 105 /usr/local/amiga/lib/gcc/m68k-amigaos/4.5.0/include/stdarg.h 3 4
typedef __gnuc_va_list va_list;
# 2 eh-vararg-3.cpp 2
...
this is the mail i write to GCC ML. This show more code about the real program
that fail
hello
there is a C++ game called dunelegacy which work on other GCC architecture ok
On G++ 68k it compile ok, but produce wrong code, because there seem something
diffrent in
va_list. The value of
SDL_RWops is transfer wrong.
I do not understand what backend problem is possible to cause this. Please
help.va_list use the
builtin GCC functions
this happen on all 68k compilers i test. (3.x and some 4.x)
See also the source attached of this class
the program flow of the critical part begin here.
Wsafile::Wsafile(SDL_RWops* RWop)
{
readdata(1,RWop);
}
..
now there are 2 Methods named readdata, and gcc call the 2. one. This work
wrong. Only when called
the first is ok.
.
void Wsafile::readdata(int NumFiles, ...) {
va_list args;
va_start(args,NumFiles);
readdata(NumFiles,args);
va_end(args);
}
/// Helper method for reading and concatinating various WSA-Files.
/**
This methods reads from the RWops all data and concatinates all the frames
to one animation. The
SDL_RWops
can be readonly but must support seeking.
\param NumFilesNumber of SDL_RWops
\param argsSDL_RWops for each wsa-File should be in this va_list.
(can be readonly)
*/
void Wsafile::readdata(int NumFiles, va_list args) {
unsigned char** Filedata;
Uint32** Index;
Uint16* NumberOfFrames;
bool* extended;
if((Filedata = (unsigned char**) malloc(sizeof(unsigned char*) * NumFiles))
== NULL) {
fprintf(stderr, Wsafile::readdata(): Unable to allocate memory!\n);
exit(EXIT_FAILURE);
}
.
when i change code to this and rename the first readdata method to
readdata_first then it work
Wsafile::Wsafile(SDL_RWops* RWop)
{
readdata_first(1,RWop); I change that line
}
now there is called this method before and all work ok
void Wsafile::readdata_frist(int NumFiles, ...) { I rename readdata to
readdata_first.
va_list args;
va_start(args,NumFiles);
readdata(NumFiles,args);
va_end(args);
}
/// Helper method for reading and concatinating various WSA-Files.
/**
This methods reads from the RWops all data and concatinates all the frames
to one animation. The
SDL_RWops
can be readonly but must support seeking.
\param NumFilesNumber of SDL_RWops
\param argsSDL_RWops for each wsa-File should be in this va_list.
(can be readonly)
*/
void Wsafile::readdata(int NumFiles, va_list args) {
unsigned char** Filedata;
Uint32** Index;
Uint16* NumberOfFrames;
bool* extended;
if((Filedata = (unsigned char**) malloc(sizeof(unsigned char*) * NumFiles))
== NULL) {
fprintf(stderr, Wsafile::readdata(): Unable to allocate memory!\n);
exit(EXIT_FAILURE);
}
..
int WsaFilesize;
RWop = va_arg(args,SDL_RWops*);
Filedata[i] = readfile(RWop,WsaFilesize); --- here crash, when not
the 1. method is called
before
Bye
[Bug c++/52817] g++ do not call a method with same name on some platforms(see small example source attached)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52817 --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-01 13:33:25 UTC --- there is a C++ game called dunelegacy which work on other GCC architecture ok Yes so the ABI for the 68k says va_list is a void* which is a valid choice as far as the C++ standard is concerned. I think you need to rethink the function names so that ... is chosen over void*. as Andreas said, the conversion to void* is chosen over a ... function.
[Bug c++/9050] [DR 147] Can't explicitly specialize C++ constructor templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9050 Johannes Schaub schaub.johannes at googlemail dot com changed: What|Removed |Added CC||schaub.johannes at ||googlemail dot com --- Comment #13 from Johannes Schaub schaub.johannes at googlemail dot com 2012-04-01 14:03:40 UTC --- Jason, does http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1435 not render the explicit specialization ill-formed for C++11TC1? It only allows a simple identifier, and not a template-id.
[Bug c++/9050] [DR 147] Can't explicitly specialize C++ constructor templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9050 --- Comment #14 from Johannes Schaub schaub.johannes at googlemail dot com 2012-04-01 14:14:46 UTC --- (In reply to comment #13) Jason, does http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_active.html#1435 not render the explicit specialization ill-formed for C++11TC1? It only allows a simple identifier, and not a template-id. FWIW I don't like the resolution of that issue. For a qualified-id, the injected-class-name is an excellent way for us to know when and when not we name a constructor, and it is entirely based on name-lookup rules; I don't see the need to dictate that in clause 12. Only for an unqualified-id, we actually need the rule to know when we declare a constructor. The allowed decl-specifiers in a constructor declaration can be stated separately.
[Bug c++/52817] g++ do not call a method with same name on some platforms(see small example source attached)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52817 --- Comment #8 from bernd_afa nospamname at web dot de 2012-04-01 14:16:15 UTC --- (In reply to comment #7) there is a C++ game called dunelegacy which work on other GCC architecture ok Yes so the ABI for the 68k says va_list is a void* which is a valid choice as far as the C++ standard is concerned. I think you need to rethink the function names so that ... is chosen over void*. as Andreas said, the conversion to void* is chosen over a ... function. I think you need to rethink the function names so that ... is chosen over void*. as Andreas said, the conversion to void* is chosen over a ... function. I like to change this for the compiler, to be compatible and at least to test if there run more C++ Programs on 68k. How is that possible when i use buildin va_list ? there is AROS a amiga replacement OS.It is platform independent and run currently on X86, arm, ppc and 68k and use GCC as compiler on all platforms.here can see what platforms it support http://aros.sourceforge.net/download.php But the OWB webbrowser and dunelegacy do not work on 68k. OWB is based on webkit engine. somebody else compile it for amiga OS. It compile ok, but crash. it was too hard to find the Problem in this big program. I search not long and give up. some weeks later i get a report, that dunelegacy do not work on 68k. It was not so large and i find the problems.I see OWB use lots va_list. maybe change va_list to mainstraim behavior in the amigaos or AROS compiler build let more C++ programs get working without changes. A problem too is that GCC give no warning, about a unused depatcher method or sow. So please help and tell me what i can do. I can compile GCC 68k
[Bug c++/52817] g++ do not call a method with same name on some platforms(see small example source attached)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52817 --- Comment #9 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-01 14:31:37 UTC --- maybe change va_list to mainstraim behavior in the amigaos or AROS compiler build let more C++ programs get working without changes. You cannot change va_list without changing the ABI and that is not going to fly anywhere. You just need to take better into account what va_list can be (which is mostly anything from char* to void* to an array of a struct to a struct).
[Bug java/52810] gcj -C -g failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52810 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Component|classpath |java Version|0.98|4.7.0 Resolution||INVALID Product|classpath |gcc --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-01 14:56:24 UTC --- You need to install the Eclipse front-end. There is a script in contrib in GCC's sources which does this.
[Bug inline-asm/52813] %rsp in clobber list is silently ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52813
Josh Haberman jhaberman at gmail dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |
--- Comment #2 from Josh Haberman jhaberman at gmail dot com 2012-04-01
15:54:27 UTC ---
I don't expect the compiler to analyze the asm string. I expect the compiler
to respect my clobber list.
I told GCC that I would clobber %rsp. Any other register that I put in the
clobber list causes GCC to save that register to the stack or to another
register before the asm and restore it from the stack/register after the asm.
For example:
--
#include stdlib.h
int main() {
int x = rand();
asm volatile (movq $0, %%rax : : : %rax);
return x;
}
$ gcc -Wall -O3 -fomit-frame-pointer -c -o test.o test.c
$ objdump -d -r -M intel test.o
test.o: file format elf64-x86-64
Disassembly of section .text.startup:
main:
0:48 83 ec 08 subrsp,0x8
4:e8 00 00 00 00 call 9 main+0x9
5: R_X86_64_PC32rand-0x4
9:89 c2movedx,eax
b:48 c7 c0 00 00 00 00 movrax,0x0
12:89 d0moveax,edx
14:48 83 c4 08 addrsp,0x8
18:c3 ret
--
Notice that it saved eax to edx before my asm and restored it afterwards. This
works for every register except %rsp, which is silently ignored if you try to
list it in the clobber list. This is a bug.
[Bug middle-end/52820] [4.8 Regression] ICE in create_preheader, at cfgloopmanip.c:1363
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52820 --- Comment #1 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-04-01 16:04:29 UTC --- Most likely a dup of PR52808.
[Bug bootstrap/52808] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52808 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added CC||markus at trippelsdorf dot ||de --- Comment #4 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-04-01 16:09:09 UTC --- Most likely PR52820 is also a dup.
[Bug c++/52817] g++ do not call a method with same name on some platforms(see small example source attached)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52817 --- Comment #10 from bernd_afa nospamname at web dot de 2012-04-01 16:12:28 UTC --- (In reply to comment #9) You cannot change va_list without changing the ABI and that is not going to fly anywhere. You just need to take better into account what va_list can be (which is mostly anything from char* to void* to an array of a struct to a struct). I see in the amigaos _G_config.h this typedef void * _G_va_list; Are there other mainstream targets with webkit and many C++ programs running that use void * for va_list ? And what type va_list is on most mainstream OS /ABI ?
[Bug bootstrap/52808] [4.8 Regression] LTO bootstrap failed with bootstrap-profiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52808 --- Comment #5 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-04-01 16:14:15 UTC --- *** Bug 52820 has been marked as a duplicate of this bug. ***
[Bug middle-end/52820] [4.8 Regression] ICE in create_preheader, at cfgloopmanip.c:1363
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52820 Markus Trippelsdorf markus at trippelsdorf dot de changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Markus Trippelsdorf markus at trippelsdorf dot de 2012-04-01 16:14:15 UTC --- dup *** This bug has been marked as a duplicate of bug 52808 ***
[Bug middle-end/52821] New: [4.8 Regression] 191.fma3d in SPEC CPU 2000 failed to build with LTO
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52821 Bug #: 52821 Summary: [4.8 Regression] 191.fma3d in SPEC CPU 2000 failed to build with LTO Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: areg.melikadam...@gmail.com On Linux/x86-64, revision 186029 failed to build 191.fma3d in SPEC CPU 2000 with LTO: gfortran -O3 -funroll-loops -ffast-math -fwhole-program -flto=jobserver -fuse-linker-plugin -DSPEC_CPU2000_LP64 fma3d.o beam_.o include_file_.o penta_.o segment_set_.o body_force_.o indx_.o periodic_bc_.o sliding_interface_.o constrained_node_.o layering_.o plate_pair_.o sliding_node_.o contact_node_.o location_.o platq_.o spot_weld_.o contact_surface_.o lsold_.o platt_.o spring_.o coord_.o massprop_.o pressure_bc_.o spring_bc_.o damper_.o material_.o property_.o state_variables_.o damper_bc_.o mean_stress_.o shared_common_data.o stress_.o displacement_bc_.o membq_.o qa_record_.o tabulated_function_.o element_set_.o membt_.o relink_scratch_.o tetra_.o enumerated_sets_.o motion_.o results_.o tied_bc_.o force_.o nodal_point_mass_.o rigid_body_.o truss_.o force_bc_.o node_.o rigid_body_mass_.o value_.o gauge1d_.o node_set_.o rigid_wall_bc_.o velocity_ic_.o gauge2d_.o nonreflecting_bc_.o section_1d_.o gauge3d_.o nrbc_data_.o section_2d_.o hexah_.o output_.o segment_.o lsold.o damper.o spring.o material_00.o material_10.o material_11.o material_17.o material_22.o material_25.o material_32.o material_33.o material_34a.o material_36.o material_38.o material_dm.o material_sp.o sort.o pdb.o beam.o membq.o membt.o penta.o tetra.o hexah.o platq.o truss.o platt.o fma1.o getirv.o relink.o output.o fma2.o partition.o strain.o slide.o -o fma3d ... sort.f90: In function 'ivsort_.constprop.16': sort.f90:172:0: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html for instructions. make[4]: *** [/tmp/ccFwYfY7.ltrans5.ltrans.o] Error 1 lto-wrapper: make returned 2 exit status /usr/local/bin/ld: lto-wrapper failed collect2: error: ld returned 1 exit status specmake[3]: *** [fma3d] Error 1 Revision 185836 is OK.
[Bug java/52805] [4.8 Regression] 243 new GCC HEAD@185977 regressions (libjava failures)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52805
--- Comment #2 from Iain Sandoe iains at gcc dot gnu.org 2012-04-01 17:28:47
UTC ---
I suspect you might have altered the priority of class discovery methods
inadvertently.
e.g. AFAICT, although darwin defines JCR_SECTION_NAME, there is no crt
machinery to deal with it [darwin has it's own crt code] - it's on my TODO to
look at that confirm/deny/fix as appropriate.
not sure why i686-pc-linux is failing tho (since crtstuff does seem to have
provision for JCR - but not checked in any depth).
Darwin folks might like to try:
Index: gcc/config/darwin.h
===
--- gcc/config/darwin.h (revision 186018)
+++ gcc/config/darwin.h (working copy)
@@ -847,6 +847,7 @@ enum machopic_addr_class {
/* Java runtime class list. */
#define JCR_SECTION_NAME __DATA,jcr,regular,no_dead_strip
+#define TARGET_USE_JCR_SECTION 0
#undef ASM_PREFERRED_EH_DATA_FORMAT
#define ASM_PREFERRED_EH_DATA_FORMAT(CODE,GLOBAL) \
[Bug c++/52818] printf format %lf is erroneously rejected by C++11
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52818 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Keywords||diagnostic Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-01 Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-01 17:35:16 UTC --- Confirmed. The format checking code doesn't currently distinguish between C++ standards: /* The C standard version C++ is treated as equivalent to or inheriting from, for the purpose of format features supported. */ #define CPLUSPLUS_STD_VER STD_C94
[Bug libstdc++/52822] New: [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52822
Bug #: 52822
Summary: [C++11] stable_partition destroys sequence due to
inappropriate self-move-assignment
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jyass...@gcc.gnu.org
The following test program should print 1 twice, since stable_partition is
only supposed to rearrange values, not modify them.
$ cat test.cc
#include vector
#include utility
#include algorithm
#include iostream
using namespace std;
bool pred(const vectorint) { return true; }
int main() {
vectorvectorint v(1);
v[0].push_back(7);
cout v[0].size() '\n';
stable_partition(v.begin(), v.end(), pred);
cout v[0].size() '\n';
}
$ g++-4.6pre --version
g++-4.6pre (GCC) 4.6.4 20120330 (prerelease)
$ g++-4.6pre -std=c++98 -g3 test.cc -o test ./test
1
1
$ g++-4.6pre -std=c++0x -g3 test.cc -o test ./test
1
0
$ g++-4.7pre --version
g++-4.7pre (GCC) 4.7.1 20120330 (prerelease)
$ g++-4.7pre -std=c++0x -g3 test.cc -o test ./test
1
0
$ g++-4.8pre --version
g++-4.8pre (GCC) 4.8.0 20120330 (experimental)
$ g++-4.8pre -std=c++0x -g3 test.cc -o test ./test
1
0
I believe this happens because
http://gcc.gnu.org/viewcvs/trunk/libstdc%2B%2B-v3/include/bits/stl_algo.h?revision=184997view=markup#l1827
move-assigns *__result1 from *__first even when those are the same object,
which violates
http://www.open-std.org/jtc1/sc22/wg21/docs/lwg-defects.html#1204.
I haven't audited the rest of the library to look for more instances of this
mistake. I'm planning to switch the default compilation mode to c++0x and run
the gcc-4.6 test suite to look for more problems, but I'm not currently
planning to do the same for 4.7 or trunk.
[Bug inline-asm/52813] %rsp in clobber list is silently ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52813 --- Comment #3 from Uros Bizjak ubizjak at gmail dot com 2012-04-01 18:58:27 UTC --- (In reply to comment #2) I don't expect the compiler to analyze the asm string. I expect the compiler to respect my clobber list. I told GCC that I would clobber %rsp. Any other register that I put in the clobber list causes GCC to save that register to the stack or to another register before the asm and restore it from the stack/register after the asm. For example: %rsp is considered a fixed register, used for fixed purposes all throughout the compiled code and are therefore not available for general allocation. So, save %rsp at the beginning of your asm code and restore it at the end.
[Bug inline-asm/52813] %rsp in clobber list is silently ignored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52813 --- Comment #4 from Josh Haberman jhaberman at gmail dot com 2012-04-01 19:23:14 UTC --- I understand that GCC may not be able to save/restore %rsp like it does other registers. But if that's the case, GCC should throw an error if the user puts %rsp in the clobber list, instead of silently ignoring it. Otherwise how is the user supposed to know that %rsp will not be saved except through trial and error?
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 Marc Glisse marc.glisse at normalesup dot org changed: What|Removed |Added CC||marc.glisse at normalesup ||dot org --- Comment #29 from Marc Glisse marc.glisse at normalesup dot org 2012-04-01 20:28:14 UTC --- (In reply to comment #24) Personally, I don't believe Gaby is open to other solutions outside the full-fledged caret diagnostics context, He didn't seem opposed to _adding_ the type information (without removing the current information).
[Bug middle-end/52823] New: [4.8 Regression] FAIL: gnat.dg/renaming5.adb scan-tree-dump-times optimized goto 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52823 Bug #: 52823 Summary: [4.8 Regression] FAIL: gnat.dg/renaming5.adb scan-tree-dump-times optimized goto 2 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: domi...@lps.ens.fr CC: ebotca...@gcc.gnu.org, ia...@gcc.gnu.org, rgue...@gcc.gnu.org At revision 185913, the test gnat.dg/renaming5.adb fails on x86_64-apple-darwin10: FAIL: gnat.dg/renaming5.adb scan-tree-dump-times optimized goto 2 [macbook] f90/bug% grep goto renaming5.adb.149t.optimized goto bb 5; goto bb 4; goto bb 3; AFAICT the test passes at r185912 on s390-ibm-linux-gnu default (see http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg03204.html), but fails at r185969 (see http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg03354.html) as well as on x86_64-unknown-linux-gnu (see http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg03405.html). Note that gnat.dg/return3.adb fails on s390-ibm-linux-gnu default and x86_64-unknown-linux-gnu: FAIL: gnat.dg/return3.adb scan-assembler loc 1 6 I did not checked if a pr has already been filled for it or not. If not, since I don't see it on darwin, I'll let a linux user fill it.
[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52822 --- Comment #1 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-04-01 20:41:43 UTC --- Running the 4.6 testsuite with -std=c++0x as the default was unsuccessful, in that it found only one error in an execution test, which was already known, and didn't find the stable_partition bug. Manual inspection it is. :(
[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52822 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2012-04-01 Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-01 21:14:46 UTC --- Yeah, I run the whole testsuite with -std=c++0x every now and then, and I think Paolo does so more often. Confirming this one though - thanks for finding it.
[Bug c++/52824] New: [C++11] expanding variadic template arguments into non-variadic template
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52824
Bug #: 52824
Summary: [C++11] expanding variadic template arguments into
non-variadic template
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zeratul...@hotmail.com
The fix to PR 35722 fixed many cases of expanding variadic template arguments
into a non-variadic template.
However, the following example (a simple modification of the PR 35722 example,
I just removed the default template arguments from 'foo') gives a bogus error:
templatetypename G, typename H
struct foo
{};
templatetypename... G
struct bar : fooG...
{};
int main() {
barint, float f;
}
The error is:
test.cpp:6:22: error: wrong number of template arguments (1, should be 2)
test.cpp:2:8: error: provided for 'templateclass G, class H struct foo'
[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52822 --- Comment #3 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-01 21:50:42 UTC --- Lately, in 4.6 too, in the occasion of a similar issue, we also added a check for self-move assignment to __gnu_test::rvalstruct. Evidently, the small testcases we have got already do not trigger the offending case, unfortunately. Anyway, luckily these issues are normally easy to fix. If Jeffrey, you are able to quickly prepare a patch and send it to the mailing list, Jon can approve and commit it (I will be traveling for a few days). Should be definitely suited for 4.7.1 and maybe 4.6 too, if small enough.
[Bug libstdc++/52591] [C++0x] [4.7 Regression] moving std::vector relies on movable elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52591 --- Comment #11 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-01 22:04:59 UTC --- Author: redi Date: Sun Apr 1 22:04:54 2012 New Revision: 186057 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186057 Log: PR libstdc++/52591 * include/bits/stl_vector.h (vector::operator=(vector)): Dispatch to _M_move_assign depending on whether allocator is moved. (vector::_M_move_assign): Add overloaded functions. * testsuite/23_containers/vector/52591.cc: New. * testsuite/23_containers/vector/requirements/dr438/assign_neg.cc: Adjust dg-error line number. * testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/constructor_2_neg.cc: Likewise. * testsuite/23_containers/vector/requirements/dr438/insert_neg.cc: Likewise. Added: trunk/libstdc++-v3/testsuite/23_containers/vector/52591.cc - copied, changed from r186055, trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/insert_neg.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/include/bits/stl_vector.h trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/assign_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_1_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/constructor_2_neg.cc trunk/libstdc++-v3/testsuite/23_containers/vector/requirements/dr438/insert_neg.cc
[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52822 --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-01 22:09:45 UTC --- PS: then shall we just do the assignment only when __result1 != __first, or algorithmically we can do better? In case we can also imagine having the trivial fix for 4.6 and maybe even 4.7.1 and committing it to mainline too without considering the issue resolved, in case later on somebody figures out something smarter algorithmically.
[Bug libstdc++/52591] [C++0x] [4.7 Regression] moving std::vector relies on movable elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52591 --- Comment #12 from Jonathan Wakely redi at gcc dot gnu.org 2012-04-01 22:12:29 UTC --- fixed on the trunk so far
[Bug java/52805] [4.8 Regression] 243 new GCC HEAD@185977 regressions (libjava failures)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52805 --- Comment #3 from Dominique d'Humieres dominiq at lps dot ens.fr 2012-04-01 22:30:33 UTC --- Nice working patch! Though I doubt it'll work for linux;-) (both i686 and x86_64). === libjava Summary for unix/-m64 === # of expected passes2574 === libjava Summary === # of expected passes5148
[Bug middle-end/52823] [4.8 Regression] FAIL: gnat.dg/renaming5.adb scan-tree-dump-times optimized goto 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52823 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||WONTFIX --- Comment #1 from Eric Botcazou ebotcazou at gcc dot gnu.org 2012-04-01 23:00:07 UTC --- AFAICT the test passes at r185912 on s390-ibm-linux-gnu default (see http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg03204.html), but fails at r185969 (see http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg03354.html) as well as on x86_64-unknown-linux-gnu (see http://gcc.gnu.org/ml/gcc-testresults/2012-03/msg03405.html). It probably fails everywhere, this is known, no point in opening a PR for such a benign regression during stage #1. Note that gnat.dg/return3.adb fails on s390-ibm-linux-gnu default and x86_64-unknown-linux-gnu: FAIL: gnat.dg/return3.adb scan-assembler loc 1 6 I did not checked if a pr has already been filled for it or not. If not, since I don't see it on darwin, I'll let a linux user fill it. Likewise, let's avoid cluttering up the database for this.
[Bug tree-optimization/52797] [4.8 Regression] Revision 185913 causes ICE in get_loop_body, at cfgloop.c:831 on PowerPC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52797 David Edelsohn dje at gcc dot gnu.org changed: What|Removed |Added CC||dje at gcc dot gnu.org --- Comment #4 from David Edelsohn dje at gcc dot gnu.org 2012-04-01 23:05:07 UTC --- powerpc-aix as well.
[Bug c/52825] New: incorrect message for incompatible pointer type with typedeffed structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52825
Bug #: 52825
Summary: incorrect message for incompatible pointer type with
typedeffed structs
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: gu...@mailinator.com
presented with the following code:
typedef struct
{
/*doesn't matter what's here*/
}
foo;
void f(foo*);
void main(int argc, char** argv)
{
struct foo* bar;
f(bar);
}
compiled with gcc -c test.c, the following warning is produced:
test.c: In function 'main':
test.c:12:2: warning: passing argument 1 of 'f' from incompatible pointer type
[enabled by default]
test.c:7:6: note: expected 'struct foo *' but argument is of type 'struct foo
*'
The two types printed are the same, but the actual types are more like foo*
vs struct foo* (which are what clang mentions in its warning here).
[Bug c++/52826] New: Implement core/1170
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52826 Bug #: 52826 Summary: Implement core/1170 Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: paolo.carl...@oracle.com Another internal reminder: http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#1170 Should be also rather doable...
[Bug c++/50043] [C++0x] Implement core/1123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50043 --- Comment #9 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2012-04-02 00:13:35 UTC --- Author: paolo Date: Mon Apr 2 00:13:30 2012 New Revision: 186058 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=186058 Log: /cp 2012-04-01 Paolo Carlini paolo.carl...@oracle.com PR c++/50043 * class.c (deduce_noexcept_on_destructor, deduce_noexcept_on_destructors): New. (check_bases_and_members): Call the latter. * decl.c (grokfndecl): Call the former. * method.c (implicitly_declare_fn): Not static. * cp-tree.h (deduce_noexcept_on_destructor, implicitly_declare_fn): Declare /testsuite 2012-04-01 Paolo Carlini paolo.carl...@oracle.com PR c++/50043 * g++.dg/cpp0x/noexcept17.C: New. * g++.old-deja/g++.eh/cleanup1.C: Adjust. * g++.dg/tree-ssa/ehcleanup-1.C: Likewise. * g++.dg/cpp0x/noexcept01.C: Likewise. * g++.dg/eh/init-temp1.C: Likewise. * g++.dg/eh/ctor1.C: Likwise. Added: trunk/gcc/testsuite/g++.dg/cpp0x/noexcept17.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/decl.c trunk/gcc/cp/method.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/noexcept01.C trunk/gcc/testsuite/g++.dg/eh/ctor1.C trunk/gcc/testsuite/g++.dg/eh/init-temp1.C trunk/gcc/testsuite/g++.dg/tree-ssa/ehcleanup-1.C trunk/gcc/testsuite/g++.old-deja/g++.eh/cleanup1.C
[Bug c++/50043] [C++0x] Implement core/1123
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50043 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #10 from Paolo Carlini paolo.carlini at oracle dot com 2012-04-02 00:19:43 UTC --- Done. Library clean-ups will follow.
[Bug c/52827] New: -mx32 is not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52827 Bug #: 52827 Summary: -mx32 is not recognized Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: jeng...@medozas.de Observed: $ gcc-4.7 -mx32 -c clock.c /usr/lib64/gcc/x86_64-suse-linux/4.7/../../../../x86_64-suse-linux/bin/as: unrecognized option '--x32' Expected: Either recognize option, or say -mx32 is unknown. But --x32 is not what I specified, in any case. $ gcc-4.7 -v Using built-in specs. COLLECT_GCC=gcc-4.7 COLLECT_LTO_WRAPPER=/usr/lib64/gcc/x86_64-suse-linux/4.7/lto-wrapper Target: x86_64-suse-linux Configured with: ../configure --prefix=/usr --infodir=/usr/share/info --mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64 --enable-languages=c,c++,objc,fortran,obj-c++,java,ada --enable-checking=yes --with-gxx-include-dir=/usr/include/c++/4.7 --enable-ssp --disable-libssp --disable-libitm --disable-plugin --with-bugurl=http://bugs.opensuse.org/ --with-pkgversion='SUSE Linux' --disable-libgcj --disable-libmudflap --with-slibdir=/lib64 --with-system-zlib --enable-__cxa_atexit --enable-libstdcxx-allocator=new --disable-libstdcxx-pch --enable-version-specific-runtime-libs --enable-linker-build-id --program-suffix=-4.7 --enable-linux-futex --without-system-libunwind --with-arch-32=i586 --with-tune=generic --build=x86_64-suse-linux Thread model: posix gcc version 4.7.0 20120322 [gcc-4_7-branch revision 185687] (SUSE Linux)
[Bug c/52827] -mx32 is not recognized
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52827 Jan Engelhardt jengelh at medozas dot de changed: What|Removed |Added CC||hjl.tools at gmail dot com Severity|normal |minor
[Bug c/52827] Document requirements for -mx32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52827 Jan Engelhardt jengelh at medozas dot de changed: What|Removed |Added Summary|-mx32 is not recognized |Document requirements for ||-mx32 Severity|minor |enhancement --- Comment #1 from Jan Engelhardt jengelh at medozas dot de 2012-04-02 01:57:38 UTC --- Guess I missed the requirement for binutils = 2.22. If this could be documented in the gcc manpage for -mx32 that would be welcome. (As would a canonicalization of the path to as which, since it has been so long, kinda gets ignored.)
[Bug c/52827] Document requirements for -mx32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52827 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org 2012-04-02 02:00:31 UTC --- You need more than just a binutils that is able to assemble x32 code, you will need a glibc which also supports it too. No distro has that yet.
[Bug libstdc++/52822] [C++11] stable_partition destroys sequence due to inappropriate self-move-assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52822 --- Comment #5 from Jeffrey Yasskin jyasskin at gcc dot gnu.org 2012-04-02 02:15:24 UTC --- Created attachment 27058 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27058 Fix by skipping past true-predicate values Here's an algorithmic fix that passes check-c++. As a side-effect, it makes __find_if_not available outside C++11 mode. Look good for trunk? Would you want the simpler __result1!=__first fix for 4.6 and/or 4.7, or is this approach good for them too?
[Bug target/52828] New: powerpc -m32 -Os writes register saves below stack
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52828 Bug #: 52828 Summary: powerpc -m32 -Os writes register saves below stack Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: amo...@gmail.com An example is gcc.c-torture/compile/20020604-1.c compiled with -m32 -g -Os -fno-omit-frame-pointer. (The -fno-omit-frame-pointer is there just to get a reg saved. An asm volatile reg clobber gives the same result.) The relevant part of the prologue code looks like lis 0,0x mr 12,1 ori 0,0,32736 stw 31,-4(12) stwux 1,1,0 .cfi_def_cfa_offset 32800 .cfi_offset 31, 32796 Notice the r31 save before the stack adjust. Another consequence of the reordering is wrong debug/eh_frame info for r31.
[Bug c/52829] New: gcc releases up to 4.6.2 triggers ICE when compiling Gambit Scheme at -O2 on ppc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52829 Bug #: 52829 Summary: gcc releases up to 4.6.2 triggers ICE when compiling Gambit Scheme at -O2 on ppc64 Classification: Unclassified Product: gcc Version: 4.6.2 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: sali...@fedoraproject.org Created attachment 27059 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27059 Build log for Gambit 4.6.5 With GCC 4.4.6 (used by Red Hat Enterprise Linux 6) and GCC 4.6.2 (installed on Fedora's test PowerPC machine's Fedora 16 target), building Gambit Scheme with -O2 -- which is the default since their 4.6.4 release -- triggers an internal compiler error. This is fixed in GCC 4.7.0 (as tested on our PowerPC machine's Rawhide target). For reference: Gambit bug report: http://www.iro.umontreal.ca/~gambit/bugzilla/show_bug.cgi?id=155 Red Hat bug report: https://bugzilla.redhat.com/show_bug.cgi?id=808285
[Bug c/52829] gcc releases up to 4.6.2 triggers ICE when compiling Gambit Scheme at -O2 on ppc64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52829 --- Comment #1 from Michel Alexandre Salim salimma at fedoraproject dot org 2012-04-02 04:10:22 UTC --- Created attachment 27060 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=27060 Preprocessed source file that triggers ICE
[Bug c++/49152] Unhelpful diagnostic for iterator dereference
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49152 --- Comment #30 from Jason Merrill jason at gcc dot gnu.org 2012-04-02 05:16:05 UTC --- (In reply to comment #26) The caret is not a solution to this problem, because what Gabriel wants is to not reconstruct expressions ONLY when the caret is shown, but he has said in the past that the caret should default to OFF to not change the current output for IDEs and other software parsing the output of gcc like emacs, so we are back to printing the monsters mentioned above by default. I think I've said before that caret should default to on when the output is a terminal. That and that moving line-map out of libcpp to create a source-location library has been rejected in the past. I don't remember the discussion about this. What was the goal? Even if the caret was the solution, nobody has worked on it in the last 25 years, and now that we have good column information, I don't expect that there will be anyone working on it in the next 25. Well, we didn't have the competitive pressure from clang in the past 25 years; now we do. Good column information is equivalent to caret diagnostics; the column number tells you where the caret goes, so an IDE can put the cursor there. As I've suggested before, one quick way to get caret diagnostics given the column information would be to write a quick perl postprocessor that just prints the designated line and puts a caret under the designated column. Range highlighting like clang has is something further; we would need two source locations per expression, rather than the one we currently have. And G++ still needs some work to track expression locations better, it hasn't gotten as much work on that as the C front end.
[Bug c++/9050] [DR 147] Can't explicitly specialize C++ constructor templates
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9050 Jason Merrill jason at gcc dot gnu.org changed: What|Removed |Added Known to fail|| --- Comment #15 from Jason Merrill jason at gcc dot gnu.org 2012-04-02 05:41:08 UTC --- (In reply to comment #14) Good point, I've pointed out the problem with the proposed resolution.
