[Bug target/49758] New: -O2 incorrectly swaps overlapping memory accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49758
Summary: -O2 incorrectly swaps overlapping memory accesses
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: arthur.j.odw...@gmail.com
Created attachment 24776
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24776
Output of ajo-gcc -w -O1 test.c -v
This failure reproduces for me with svn revision 176128 (2011-07-10). I'm on
Ubuntu 10.10, x86-64. It looks like bug 36043 may be related.
cat test.c EOF
static volatile struct S0 {
short f3[9];
unsigned f8 : 15;
} s = {1};
static unsigned short sh = 0x1234;
struct S0 a, b;
int vi = 0;
void func_4() {
s.f8 |= 1;
sh = 15;
if (vi) a = b;
}
int main() {
func_4();
printf(%hx\n, sh);
return 0;
}
EOF
gcc -w -O1 test.c ; ./a.out
gcc -w -O2 test.c ; ./a.out
With -O1, we correctly print f. With -O2, we incorrectly print 1234.
With -O1 we have the following assembly code:
[...]
movqs+16(%rip), %rax
andq$-2147418113, %rax
orq%rdx, %rax
movq%rax, s+16(%rip)
movw$15, sh(%rip)
[...]
With -O2 the scheduler has incorrectly swapped the movw into the middle of the
volatile struct access:
[...]
movqs+16(%rip), %rdx
movqs+16(%rip), %rax
movw$15, sh(%rip)
andl$2147352576, %edx
andq$-2147418113, %rax
orq$65536, %rdx
orq%rdx, %rax
movq%rax, s+16(%rip)
[...]
This test case is reduced from the output of Csmith 2.1.0 (git hash 01aa8b04,
https://github.com/Quuxplusone/csmith/), using the following command line:
csmith --paranoid --no-longlong --no-pointers --no-arrays --no-jumps
--no-consts --volatiles --checksum --no-divs --no-muls --bitfields
--packed-struct -s 320690328
[Bug target/49758] -O2 incorrectly swaps overlapping memory accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49758 --- Comment #1 from Arthur O'Dwyer arthur.j.odwyer at gmail dot com 2011-07-16 06:46:24 UTC --- Created attachment 24777 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24777 Output of ajo-gcc -w -O2 test.c -v
[Bug target/49758] -O2 incorrectly swaps overlapping memory accesses
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49758 Jakub Jelinek jakub at gcc dot gnu.org changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #2 from Jakub Jelinek jakub at gcc dot gnu.org 2011-07-16 07:28:40 UTC --- More probably dup of PR48124.
[Bug c++/49759] New: std::streampos == int should be ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49759
Summary: std::streampos == int should be ambiguous
Product: gcc
Version: 4.4.5
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: mathieu.malate...@gmail.com
I believe the following code should not compile:
#include fstream
int main()
{
std::ofstream f( bla.txt );
std::ifstream is( bla.txt );
if( is.tellg() == 0 ) {}
return 0;
}
the overload for 'operator==' is ambiguous and should be reported. Eg:
line 7: error: more than one operator == matches these operands:
built-in operator arithmetic == arithmetic
function std::operator==(const std::fposmbstate_t , const
std::fposmbstate_t )
operand types are: std::streampos == int
if( is.tellg() == 0 ) {}
^
or
error: ambiguous overload for 'operator==' in
'((std::istream*)is)-std::basic_istream_CharT, _Traits::tellg [with _CharT =
char, _Traits = std::char_traitschar]() == 0'
note: candidates are: operator==(std::streamoff, int) built-in
/Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.0.0/bits/postypes.h:138: note:
bool std::fpos_StateT::operator==(const std::fpos_StateT)
const [with _StateT = __mbstate_t]
[Bug tree-optimization/49760] New: vectorization inhibited if indices are references
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49760
Summary: vectorization inhibited if indices are references
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
in this simple example only the third function vectorize even if they look
semantically identical to me
c++ -Wall -ftree-vectorizer-verbose=7 -Ofast -c test/testSoA.cpp
gcc version 4.7.0 20110528 (experimental) (GCC)
struct SoA {
int * __restrict__ a;
float * __restrict__ b;
float * __restrict__ c;
int size;
};
struct SoB {
int * __restrict__ a;
float * __restrict__ b;
int size;
};
void foo(SoA const in, SoB out, int k) {
int N=in.size;
for (int i=0; i!=N; ++i) {
out.b[k] = in.a[i]+in.b[i];
out.a[k] = in.a[i];
++k;
}
}
void foo2(SoA const in, SoB out, int k) {
int j=k;
for (int i=0; i!=in.size; ++i) {
out.b[j] = in.a[i]+in.b[i];
out.a[j] = in.a[i];
++j;
}
k = j;
}
void foo3(SoA const in, SoB out, int k) {
int j=k;
int N=in.size;
for (int i=0; i!=N; ++i) {
out.b[j] = in.a[i]+in.b[i];
out.a[j] = in.a[i];
++j;
}
k = j;
}
messages are
test/testSoA.cpp:17: note: not vectorized: loop contains function calls or data
references that cannot be analyzed
test/testSoA.cpp:15: note: vectorized 0 loops in function.
test/testSoA.cpp:26: note: not vectorized: number of iterations cannot be
computed.
test/testSoA.cpp:24: note: vectorized 0 loops in function.
test/testSoA.cpp:38: note: cost model: epilogue peel iters set to vf/2 because
loop iterations are unknown .
…..
test/testSoA.cpp:38: note: Profitability threshold is 5 loop iterations.
….
test/testSoA.cpp:38: note: created 5 versioning for alias checks.
test/testSoA.cpp:38: note: LOOP VECTORIZED.
test/testSoA.cpp:35: note: vectorized 1 loops in function.
I will submit a different PR for the alias checks that looks not needed to me
[Bug tree-optimization/49761] New: restrict keyword ignored if in structure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49761
Summary: restrict keyword ignored if in structure
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: tree-optimization
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: vincenzo.innoce...@cern.ch
in this example no alias checks are generated for the first function while
there are generated when inlined in the second and third functions.
Is it correct to declare an array restricted in a structure?
compiled with
c++ -Wall -ftree-vectorizer-verbose=7 -Ofast -c
gcc version 4.7.0 20110528 (experimental) (GCC)
struct SoA {
int * __restrict__ a;
float * __restrict__ b;
float * __restrict__ c;
int size;
};
struct SoB {
int * __restrict__ a;
float * __restrict__ b;
int size;
};
void loop( int const * __restrict__ in_a,
float const * __restrict__ in_b,
float const * __restrict__ in_c,
int * __restrict__ out_a,
float * __restrict__ out_b,
int N, int k) {
int j=k;
for (int i=0; i!=N; ++i) {
out_b[j] = in_c[i]+in_b[i];
out_a[j] = in_a[i];
++ j;
}
k = j;
}
void loop2(SoA const in, SoB out, int k) {
loop(in.a,in.b,in.c,
out.a,out.b,
in.size, k);
}
void loop3(SoA const in, SoB out, int k) {
int j=k;
int N=in.size;
for (int i=0; i!=N; ++i) {
out.b[j] = in.c[i]+in.b[i];
out.a[j] = in.a[i];
++j;
}
k = j;
}
[Bug c++/49759] std::streampos == int should be ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49759 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-07-16 11:27:20 UTC --- Where in the standard does it say that behaviour is required? The standard says what operations streampos must support, it doesn't say (as far as I can see) that it can't also support that operation
[Bug tree-optimization/49725] [4.6 regression] ICE at -O2 on ACATS c34005a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49725 --- Comment #7 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-07-16 11:33:33 UTC --- Author: ebotcazou Date: Sat Jul 16 11:33:28 2011 New Revision: 176352 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176352 Log: PR tree-optimization/49725 Backport from mainline 2011-03-31 Eric Botcazou ebotca...@adacore.com * tree-ssa-pre.c (create_component_ref_by_pieces_1) ARRAY_REF: Drop a zero minimum index only if it is redundant. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/tree-ssa-pre.c
[Bug tree-optimization/49725] [4.6 regression] ICE at -O2 on ACATS c34005a
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49725 Eric Botcazou ebotcazou at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-07-16 11:34:45 UTC --- Presumably.
[Bug libstdc++/49762] New: symbols not kept in std namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49762
Summary: symbols not kept in std namespace
Product: gcc
Version: 4.6.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: domin...@poczta.onet.pl
Created attachment 24778
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=24778
preprocessed file
When I include cmath library the 'omega' symbol gets to global namespace
making me unable to define my own global variable(or constant) of the same
name. What I expect is all the symbols from included standard libraries stay in
std namespace.
code (gamma_gcc.cpp):
#include cmath
const double gamma=0;
int main(int argc, char *argv[]) {
return 0;
}
command:
g++ -v -save-temps gcc_gamma.cpp 2log.txt
log.txt:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.1-1'
--with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++,go --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-multiarch
--with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.6 --libdir=/usr/lib/x86_64-linux-gnu
--enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc
--with-arch-32=i586 --with-tune=generic --enable-checking=release
--build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.1 (Debian 4.6.1-1)
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus -E -quiet -v
-D_GNU_SOURCE gcc_gamma.cpp -mtune=generic -march=x86-64 -fpch-preprocess -o
gcc_gamma.ii
ignoring nonexistent directory /usr/local/include/x86_64-linux-gnu
ignoring nonexistent directory
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/../../../../../x86_64-linux-gnu/include
#include ... search starts here:
#include ... search starts here:
/usr/include/c++/4.6
/usr/include/c++/4.6/x86_64-linux-gnu
/usr/include/c++/4.6/backward
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/include
/usr/local/include
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/include-fixed
/usr/include/x86_64-linux-gnu
/usr/include
End of search list.
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-shared-libgcc' '-mtune=generic'
'-march=x86-64'
/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.6.1/cc1plus -fpreprocessed
gcc_gamma.ii -quiet -dumpbase gcc_gamma.cpp -mtune=generic -march=x86-64
-auxbase gcc_gamma -version -o gcc_gamma.s
GNU C++ (Debian 4.6.1-1) version 4.6.1 (x86_64-linux-gnu)
compiled by GNU C version 4.6.1, GMP version 5.0.1, MPFR version 3.0.1-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU C++ (Debian 4.6.1-1) version 4.6.1 (x86_64-linux-gnu)
compiled by GNU C version 4.6.1, GMP version 5.0.1, MPFR version 3.0.1-p3,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 0ad58bd6c0c247927e86db6007c69b16
gcc_gamma.cpp:3:14: error: ‘const double gamma’ redeclared as different kind of
symbol
/usr/include/bits/mathcalls.h:265:15: error: previous declaration of ‘double
gamma(double)’
[Bug libstdc++/49762] symbols not kept in std namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49762 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-07-16 12:37:53 UTC --- the standard has been changed to accept the fact that C++ implementations cannot control the C library headers, and so cmath is permitted to declare names in both the global namespace and nmespace std see http://www.open-std.org/JTC1/SC22/WG21/docs/lwg-defects.html#456
[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746 --- Comment #22 from dave.anglin at bell dot net 2011-07-16 13:13:45 UTC --- On 15-Jul-11, at 11:59 PM, h.m.brand at xs4all dot nl wrote: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746 --- Comment #20 from H.Merijn Brand h.m.brand at xs4all dot nl 2011-07-16 03:59:31 UTC --- On Fri, 15 Jul 2011 19:15:28 +, dave.anglin at bell dot net gcc-bugzi...@gcc.gnu.org wrote: I think the attached change will fix the bug. Apparently it did! Dave++ I guess this will be in 4.6.2 Yes. This is regression. I messed up fixing the handling of 64-bit add/sub conditions and incorrectly changed addi/subi. They don't have 64-bit conditions. This stemmed from a change to binutils that broke the handling of 64-bit conditions completely. For 64bit perl: Test Summary Report --- re/reg_eval.t (Wstat: 0 Tests: 7 Failed: 3) Failed tests: 4-6 ../cpan/CGI/t/tmpdir.t (Wstat: 0 Tests: 9 Failed: 0) TODO passed: 3-9 ../dist/IO/t/io_multihomed.t (Wstat: 7424 Tests: 1 Failed: 0) Non-zero exit status: 29 Parse errors: Bad plan. You planned 8 tests but ran 1. ../dist/IO/t/io_sock.t (Wstat: 7424 Tests: 1 Failed: 0) Non-zero exit status: 29 Parse errors: Bad plan. You planned 26 tests but ran 1. ../dist/IO/t/io_udp.t (Wstat: 9 Tests: 0 Failed: 0) Non-zero wait status: 9 Parse errors: Bad plan. You planned 7 tests but ran 0. ../dist/Net-Ping/t/450_service.t (Wstat: 7424 Tests: 3 Failed: 0) Non-zero exit status: 29 Parse errors: Bad plan. You planned 26 tests but ran 3. ../dist/Net-Ping/t/510_ping_udp.t (Wstat: 65280 Tests: 1 Failed: 0) Non-zero exit status: 255 Parse errors: Bad plan. You planned 2 tests but ran 1. ../ext/Socket/t/Socket.t (Wstat: 7424 Tests: 2 Failed: 0) Non-zero exit status: 29 Parse errors: Bad plan. You planned 26 tests but ran 2. Files=2144, Tests=465226, 1241 wallclock secs (272.44 usr 30.32 sys + 1799.09 cusr 204.72 csys = 2306.57 CPU) Result: FAIL So gcc-4 still fails the socket stuff Does aCC work in 64-bit mode? We need this narrowed to a C testcase if it's a GCC bug. I'm also seeing a socket test fail randomly in the Ada gnat testsuite with 32-bit hppa*-*-hpux*. Dave -- John David Anglindave.ang...@bell.net
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #25 from Mikael Pettersson mikpe at it dot uu.se 2011-07-16 13:20:49 UTC --- The first 4.6.1 bootstrap attempt failed at the very first Ada compilation step in stage 3, with a SEGV in gnat1 when compiling ada/a-charac.ads. This was with a straight forward-port of the working 4.5.3 patch. I'll keep digging...
[Bug rtl-optimization/47556] x86: fails to take advantage of high-byte addressing mode
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47556
H.J. Lu hjl.tools at gmail dot com changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2011.07.16 15:12:15
CC||ebotcazou at gcc dot
||gnu.org
Component|target |rtl-optimization
Ever Confirmed|0 |1
--- Comment #3 from H.J. Lu hjl.tools at gmail dot com 2011-07-16 15:12:15
UTC ---
Here is the simplified testcase:
--
[hjl@gnu-6 pr47556]$ cat x.c
typedef unsigned short int uint16_t;
typedef unsigned char uint8_t;
typedef uint8_t __ticket_t;
typedef uint16_t __ticketpair_t;
typedef struct arch_spinlock {
union {
__ticketpair_t head_tail;
struct __raw_tickets {
__ticket_t head, tail;
} tickets;
};
} arch_spinlock_t;
static struct __raw_tickets __ticket_spin_claim(struct arch_spinlock *lock)
{
register struct __raw_tickets tickets = { .tail = 1 };
if (sizeof(lock-tickets.head) == sizeof(uint8_t))
asm volatile (lock; xaddw %w0, %1\n
: +r (tickets), +m (lock-tickets)
: : memory, cc);
else
asm volatile (lock; xaddl %0, %1\n
: +r (tickets), +m (lock-tickets)
: : memory, cc);
return tickets;
}
void __ticket_spin_lock(struct arch_spinlock *lock)
{
register struct __raw_tickets inc;
inc = __ticket_spin_claim(lock);
for (;;) {
if (inc.head == inc.tail)
goto out;
asm volatile (pause);
inc.head = (*(volatile typeof(lock-tickets.head) *)(lock-tickets.head));
}
out:
asm volatile ( : : : memory);
}
[hjl@gnu-6 pr47556]$
---
The generated code is
---
__ticket_spin_lock:
.LFB1:
.cfi_startproc
movl$256, %eax
#APP
# 17 x.c 1
lock; xaddw %ax, (%rdi)
# 0 2
#NO_APP
movzbl%ah, %edx
cmpb%al, %dl
je.L2
.p2align 4,,10
.p2align 3
.L4:
#APP
# 33 x.c 1
pause
# 0 2
#NO_APP
movzbl(%rdi), %eax
cmpb%dl, %al
jne.L4
.L2:
ret
.cfi_endproc
---
The main issue is
cmpb%dl, %al
jne.L4
But %Xh registers aren't really allocated by register allocator.
They are expressed via
(set (reg:CCZ 17 flags)
(compare:CCZ (subreg:QI (zero_extract:SI (subreg:DI (reg/v:HI 62 [
tickets ]) 0)
(const_int 8 [0x8])
(const_int 8 [0x8])) 0)
(subreg:QI (reg/v:HI 62 [ tickets ]) 0)))
combine doesn't turn
(insn 10 9 11 2 (set (subreg:SI (reg:QI 61 [ tickets$tail ]) 0)
(zero_extract:SI (subreg:SI (reg/v:HI 62 [ tickets ]) 0)
(const_int 8 [0x8])
(const_int 8 [0x8]))) x.c:17 89 {*movsi_extzv_1}
(nil))
(insn 11 10 12 2 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:QI 61 [ tickets$tail ])
(subreg:QI (reg/v:HI 62 [ tickets ]) 0))) x.c:31 4 {*cmpqi_1}
(expr_list:REG_DEAD (reg/v:HI 62 [ tickets ])
(nil)))
(insn 17 15 18 3 (set (reg:CCZ 17 flags)
(compare:CCZ (reg:QI 59 [ inc$head ])
(reg:QI 61 [ tickets$tail ]))) x.c:31 4 {*cmpqi_1}
(expr_list:REG_DEAD (reg:QI 59 [ inc$head ])
(nil)))
into
(set (reg:CCZ 17 flags)
(compare:CCZ (subreg:QI (zero_extract:SI (subreg:DI (reg/v:HI 62 [
tickets ]) 0)
(const_int 8 [0x8])
(const_int 8 [0x8])) 0)
(subreg:QI (reg/v:HI 62 [ tickets ]) 0)))
(set (reg:CCZ 17 flags)
(compare:CCZ (reg:QI 59 [ inc$head ])
(subreg:QI (zero_extract:SI (subreg:DI (reg/v:HI 62 [ tickets
]) 0)
(const_int 8 [0x8])
(const_int 8 [0x8])) 0)))
[Bug ada/48835] Porting GNAT to GNU/Linux/m68k
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #26 from tg at mirbsd dot de tg at mirbsd dot de 2011-07-16 16:17:35 UTC --- mikpe at it dot uu.se dixit: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48835 --- Comment #25 from Mikael Pettersson mikpe at it dot uu.se 2011-07-16 13:20:49 UTC --- The first 4.6.1 bootstrap attempt failed at the very first Ada compilation step in stage 3, with a SEGV in gnat1 when compiling ada/a-charac.ads. This was Could this be related to that bug? http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=633754 bye, //mirabilos
[Bug c++/49763] New: [C++0x] A reference is not correctly captured by [=]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49763
Summary: [C++0x] A reference is not correctly captured by [=]
Product: gcc
Version: 4.6.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: iorate_st...@yahoo.co.jp
When a reference to an integral type (e.g. int) is captured by [=] of a lambda
expression, the value of the captured data is not one of the referenced object,
but the address of that.
int main()
{
int const i = 42;
[=] ()
{
std::cout i '\n';
*(int *)i '\n';
} ();
// 2293396
// 42
}
When the referenced type is a floating point type, ICE occurs.
int main()
{
double const d = 3.14;
[=] ()
{
std::cout d '\n';
} ();
}
-- ***.cpp: In function 'int main()':
-- ***.cpp:***:8: internal compiler error: in convert_move, at expr.c:324
-- Please submit a full bug report,
-- with preprocessed source if appropriate.
-- See http://gcc.gnu.org/bugs.html for instructions.
When the referenced type is a class type, or the reference is explictly
captured by name, it works.
[Bug c++/49763] [C++0x] A reference is not correctly captured by [=]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49763 --- Comment #1 from Jonathan Wakely redi at gcc dot gnu.org 2011-07-16 16:34:07 UTC --- looks like a duplicate of PR 49598
[Bug tree-optimization/49724] [4.6/4.7 Regression] FAIL: gnat.dg/socket1.adb execution test
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49724 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #4 from John David Anglin danglin at gcc dot gnu.org 2011-07-16 16:40:26 UTC --- Caused by incorrect name server configuration.
[Bug target/49764] New: [gcc-avr] Compiling for Arduino is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49764 Summary: [gcc-avr] Compiling for Arduino is not working Product: gcc Version: 4.6.1 Status: UNCONFIRMED Severity: critical Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: artem...@gmail.com Compiling any of the examples in arduino (IDE) gives this: In file included from /usr/share/arduino/hardware/arduino/cores/arduino/Tone.cpp:37:0: /usr/share/arduino/hardware/arduino/cores/arduino/pins_arduino.h:66:48: error: variable 'port_to_mode_PGM' must be const in order to be put into read-only section by means of '__attribute__((progmem))' /usr/share/arduino/hardware/arduino/cores/arduino/pins_arduino.h:67:49: error: variable 'port_to_input_PGM' must be const in order to be put into read-only section by means of '__attribute__((progmem))' /usr/share/arduino/hardware/arduino/cores/arduino/pins_arduino.h:68:50: error: variable 'port_to_output_PGM' must be const in order to be put into read-only section by means of '__attribute__((progmem))' /usr/share/arduino/hardware/arduino/cores/arduino/pins_arduino.h:70:54: error: variable 'digital_pin_to_port_PGM' must be const in order to be put into read-only section by means of '__attribute__((progmem))' /usr/share/arduino/hardware/arduino/cores/arduino/pins_arduino.h:72:58: error: variable 'digital_pin_to_bit_mask_PGM' must be const in order to be put into read-only section by means of '__attribute__((progmem))' /usr/share/arduino/hardware/arduino/cores/arduino/pins_arduino.h:73:55: error: variable 'digital_pin_to_timer_PGM' must be const in order to be put into read-only section by means of '__attribute__((progmem))' /usr/share/arduino/hardware/arduino/cores/arduino/Tone.cpp:108:45: error: variable 'tone_pin_to_timer_PGM' must be const in order to be put into read-only section by means of '__attribute__((progmem))' Additional info: Occures only on gcc-avr-4.6.1-1, reinstalling previous (gcc-avr-4.6.0-3) gives successful compilation. I checked the file files pins_arduino.h, pins_arduino.c and Tone.cpp on both gcc-avr-4.6.1-1 and gcc-avr-4.6.0-3 they are equal. So the issue is in the gcc-avr package. Steps to reproduce: 1. Open arduino (IDE) 2. Select any example from File-Examples 3. Click on play icon (compile) Step 2 can be left out, just clicking play icon (compile) on an empty sketch gives same error on gcc-avr-4.6.1-1
[Bug target/49765] New: Support x32 with TARGET_LEGITIMIZE_ADDRESS/LEGITIMIZE_RELOAD_ADDRESS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49765 Summary: Support x32 with TARGET_LEGITIMIZE_ADDRESS/LEGITIMIZE_RELOAD_ADDRESS Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: sergos@gmail.com The x32 implementation calls ix86_simplify_base_index_disp in ix86_decompose_address. We should investigate if we could handle translations in TARGET_LEGITIMIZE_ADDRESS (or maybe also LEGITIMIZE_RELOAD_ADDRESS).
[Bug target/49764] [gcc-avr] Compiling for Arduino is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49764 --- Comment #1 from _artem_ artemeas at gmail dot com 2011-07-16 16:47:01 UTC --- p.s. I'm using ArchLinux x86_64
[Bug target/49764] [gcc-avr] Compiling for Arduino is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49764 Jonathan Wakely redi at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011.07.16 17:25:59 Ever Confirmed|0 |1 --- Comment #2 from Jonathan Wakely redi at gcc dot gnu.org 2011-07-16 17:25:59 UTC --- http://gcc.gnu.org/bugs/
[Bug fortran/49766] New: Fortran w/ CPP: Add tracking locations of tokens resulting from macro expansion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49766 Summary: Fortran w/ CPP: Add tracking locations of tokens resulting from macro expansion Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: diagnostic Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: bur...@gcc.gnu.org The problem a patch should solve is described at http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00858.html Namely: Providing a better diagnostic output if an error occurs with code which is based on a macro expansion. Latest patch series (for C/C++): http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01316.html What needs to be done for gfortran is briefly described at cf. http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01330.html The C/C++ patch which adds the diagnostic for comparison http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01317.html
[Bug c++/49763] [C++0x] A reference is not correctly captured by [=]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49763 iorate iorate_stage at yahoo dot co.jp changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from iorate iorate_stage at yahoo dot co.jp 2011-07-16 17:29:41 UTC --- Sorry, indeed. I'll mark it as duplicate. *** This bug has been marked as a duplicate of bug 49598 ***
[Bug c++/49598] [C++0x] Ice on lambda with implicit capture by value.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49598 iorate iorate_stage at yahoo dot co.jp changed: What|Removed |Added CC||iorate_stage at yahoo dot ||co.jp --- Comment #7 from iorate iorate_stage at yahoo dot co.jp 2011-07-16 17:29:41 UTC --- *** Bug 49763 has been marked as a duplicate of this bug. ***
[Bug target/49764] [gcc-avr] Compiling for Arduino is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49764 --- Comment #3 from Jonathan Wakely redi at gcc dot gnu.org 2011-07-16 17:34:10 UTC --- I suppose I should be a bit more explicit - your bug report is no use to anyone. arduino (IDE) doesn't mean anything to GCC developers, and neither does gcc-avr-4.6.1-1, and noone here has the examples you're talking about You should either file a proper bug report following the instructions at the URL I provided, or report this to ArchLinux where it might mean something to someone Since you seem to be talking about ArchLinux packages and a version of GCC provided by ArchLinux, you should probably report it to them
[Bug target/49764] [gcc-avr] Compiling for Arduino is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49764 --- Comment #4 from _artem_ artemeas at gmail dot com 2011-07-16 17:57:28 UTC --- thank YOU master clearness! I did that before I posted the bug here. PROOF: https://bugs.archlinux.org/task/25136 Please don't be stupid, OK? And please do this on your machine: 1. go to arduino.cc 2. download the ide (EVEN IF YOU DON'T HAVE AN ARDUINO BOARD, just download it TO SEE and TO REALIZE that's a gcc-avr/avr-gcc (call it what you want) bug. 3. start the ide (you even don't need to install it, just extract and run) 4. CLICK ON THE COMPILE ICON (without loading any examples, you don't even need a line of code to reproduce the bug) please do this on gcc-avr 4.6.0 and then on gcc-avr 4.6.1 and then again on gcc-avr-4.6.1 to realize that you're a stupid moron. Second proof that you're a stupid and INCOMPETENT person: since gcc/gcc-avr 4.5.2 when you compile a arduino code and upload it to the microcontroller everything goes well, NO ERRORS, but the biggest fail is that on the board ANY delay() function freezes the board. When you upload the SAME (THE SAME) code from a windows (OS) machine the delay() function works as expected. So don't troll that's not a gcc issue, BECAUSE IT IS GCC bug. p.s. you won't die if you just download and run the above listed program to see that's a gcc bug and not ide bug. I repeat, everything works except delay() function on 4.6.0 but not on 4.6.1
[Bug target/49764] [gcc-avr] Compiling for Arduino is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49764 --- Comment #5 from Jonathan Wakely redi at gcc dot gnu.org 2011-07-16 18:10:11 UTC --- please follow the bug reporting instructions for GCC, I'm not downloading additional software to verify it if you won't provide the info requested
[Bug target/49764] [gcc-avr] Compiling for Arduino is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49764 --- Comment #6 from Jonathan Wakely redi at gcc dot gnu.org 2011-07-16 18:12:29 UTC --- and don't call people morons if you expect help
[Bug target/49723] gcc.c-torture/compile/pr46934.c: ICE in do_SUBST, at combine.c:707 at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49723 --- Comment #10 from John David Anglin danglin at gcc dot gnu.org 2011-07-16 18:33:46 UTC --- Author: danglin Date: Sat Jul 16 18:33:43 2011 New Revision: 176359 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176359 Log: PR target/49723 * config/pa/pa.md (casesi): Use gen_int_mode instead of GEN_INT. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/pa/pa.md
[Bug target/49723] gcc.c-torture/compile/pr46934.c: ICE in do_SUBST, at combine.c:707 at -O1 and above
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49723 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #11 from John David Anglin danglin at gcc dot gnu.org 2011-07-16 18:40:23 UTC --- Fixed.
[Bug boehm-gc/48494] FAIL: boehm-gc.c/gctest.c -O2 (test for excess errors)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48494 --- Comment #2 from John David Anglin danglin at gcc dot gnu.org 2011-07-16 18:54:34 UTC --- Candidate patch is here: http://gcc.gnu.org/ml/gcc-patches/2011-07/msg00740.html
[Bug target/49764] [gcc-avr] Compiling for Arduino is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49764 --- Comment #7 from _artem_ artemeas at gmail dot com 2011-07-16 19:05:46 UTC --- I don't understand what you want from me. I read that How to report, what we need and what we don't SO? What info you want from me in addition to the text I posted in the bug report? I don't know the complete command line that triggers the bug; because I don't know how to compile that code outside of IDE. I upgraded gcc (GCC not gcc-avr) from 4.6.0 to 4.6.1 couple of days ago, gcc-avr was still 4.6.0. I was able to compile for arduino (ATmega328P-PU). I installed 4.6.1 of gcc-avr and I'm unable to compile for ATmega328 from IDE. I downgraded ONLY gcc-avr to 4.6.0 result: IDE compiles code. upgraded to 4.6.1 again and I can't compile again. You would ONLY need 3 minutes to download and to run that IDE on both versions of gcc-avr. and You would know what's the reason is. I don't what is causing this errors, the only thing that was changed on my machine is the GCC-AVR version, from 4.6.0-4.6.1 lines 66-.. that are in the error: 66 extern const uint16_t PROGMEM port_to_mode_PGM[]; 67 extern const uint16_t PROGMEM port_to_input_PGM[]; 68 extern const uint16_t PROGMEM port_to_output_PGM[]; 69 70 extern const uint8_t PROGMEM digital_pin_to_port_PGM[]; 71 // extern const uint8_t PROGMEM digital_pin_to_bit_PGM[]; 72 extern const uint8_t PROGMEM digital_pin_to_bit_mask_PGM[]; 73 extern const uint8_t PROGMEM digital_pin_to_timer_PGM[]; on gcc-avr 4.6.0 I get no errors on that code, on gcc-avr 4.6.1 I get error listed in the first message. variable 'port_to_mode_PGM' must be const in order to be put into read-only produced from this: extern const uint16_t PROGMEM port_to_mode_PGM[]; was there something changed in gcc-avr that would give such an error?
[Bug target/49764] [gcc-avr] Compiling for Arduino is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49764 --- Comment #8 from Jonathan Wakely redi at gcc dot gnu.org 2011-07-16 19:36:11 UTC --- (In reply to comment #7) I don't understand what you want from me. I read that How to report, what we need and what we don't SO? What info you want from me in addition to the text I posted in the bug report? Exactly the info listed at that URL, which was missing from the bug report i.e. the preprocessed source of the code that fails to compile the output of 'gcc -v' etc. I don't know the complete command line that triggers the bug; because I don't know how to compile that code outside of IDE. Just because you don't know how to do it doesn't mean we don't want that information. You would ONLY need 3 minutes to download and to run that IDE on both versions of gcc-avr. and You would know what's the reason is. I don't what is causing this errors, the only thing that was changed on my machine is the GCC-AVR version, from 4.6.0-4.6.1 But the IDE doesn't come with gcc-avr, so I'd need to install that, and my distro doesn't have version 4.6.1, so I'd need to install avr-libc and build avr-gcc myself, and if you think I'm doing that just to help someone who calls me a stupid and incompetent moron then you're sorely mistaken. lines 66-.. that are in the error: 66 extern const uint16_t PROGMEM port_to_mode_PGM[]; 67 extern const uint16_t PROGMEM port_to_input_PGM[]; 68 extern const uint16_t PROGMEM port_to_output_PGM[]; 69 70 extern const uint8_t PROGMEM digital_pin_to_port_PGM[]; 71 // extern const uint8_t PROGMEM digital_pin_to_bit_PGM[]; 72 extern const uint8_t PROGMEM digital_pin_to_bit_mask_PGM[]; 73 extern const uint8_t PROGMEM digital_pin_to_timer_PGM[]; on gcc-avr 4.6.0 I get no errors on that code, on gcc-avr 4.6.1 I get error listed in the first message. variable 'port_to_mode_PGM' must be const in order to be put into read-only produced from this: extern const uint16_t PROGMEM port_to_mode_PGM[]; OK, now we're getting somewhere. Try putting just this in a file and compiling it with gcc-avr: extern const int __attribute__((progmem)) p[];
[Bug target/49764] [gcc-avr] Compiling for Arduino is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49764
--- Comment #9 from _artem_ artemeas at gmail dot com 2011-07-16 19:54:28 UTC
---
[_artem_@linux-void ~]$ avr-gcc -v
Using built-in specs.
COLLECT_GCC=avr-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/avr/4.6.1/lto-wrapper
Target: avr
Configured with: ../configure --disable-libssp --disable-nls
--enable-languages=c,c++ --infodir=/usr/share/info --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --prefix=/usr --target=avr
--with-gnu-as --with-gnu-ld --with-as=/usr/bin/avr-as --with-ld=/usr/bin/avr-ld
Thread model: single
gcc version 4.6.1 (GCC)
[_artem_@linux-void ~]$
I don't know how to compile that code with avr-gcc. I only compiled with gcc,
but never with avr-gcc.
[_artem_@linux-void ~]$ avr-gcc 1.c -o 2
[_artem_@linux-void ~]$ cat 2
��6����� ��6���=d(�D�D�D�D�D�D�
D�
D�D�D�D�D�d(�D�DD D D DD${standard
input}../../../libgcc/../gcc/config/avr/libgcc.S.symtab.strtab.shstrtab.text.stab.stabstrT(!|,
'�=�00�
H
(��,?��5��=��G��S��`t({(����(����`�����`���
`�#/`�6`�;`�.do_clear_bss_start.do_clear_bss_loop1.c__SREGSP_HSP_Ltmp_regzero_regtrampolines_start_etext__data_load_end__trampolines_end__data_load_start__dtors_end__bss_end__do_clear_bss__eeprom_end__data_end__ctors_start__do_copy_data__bss_start__dtors_start__ctors_end_edata_end__data_start[_artem_@linux-void
~]$
So I don't know why I can't compile and upload to the microcontroller.
p.s. when you don't have gcc-avr why are you then answering to my bug report?
[Bug libstdc++/49762] symbols not kept in std namespace
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49762 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-07-16 20:14:14 UTC --- Yes.
[Bug c++/49759] std::streampos == int should be ambiguous
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49759 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #2 from Paolo Carlini paolo.carlini at oracle dot com 2011-07-16 20:20:57 UTC --- Yep.
[Bug target/49764] [gcc-avr] Compiling for Arduino is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49764 --- Comment #10 from Jonathan Wakely redi at gcc dot gnu.org 2011-07-16 20:26:19 UTC --- (In reply to comment #9) p.s. when you don't have gcc-avr why are you then answering to my bug report? I have avr-gcc-4.5.3-1.fc15.x86_64 installed and it works fine for me. If you don't want my help that's fine.
[Bug tree-optimization/49452] [4.7 regression] comp-goto-2.c regresses in testing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49452
--- Comment #15 from Eric Botcazou ebotcazou at gcc dot gnu.org 2011-07-16
21:18:39 UTC ---
The machine-dependent reorg pass does something unexpected:
(insn 30 18 14 3 (set (reg/f:SI 11 fp)
(plus:SI (reg/f:SI 11 fp)
(const_int 36 [0x24]))) 4 {*arm_addsi3}
(nil))
(insn 14 30 16 3 (use (reg/f:SI 11 fp)) -1
(nil))
(insn 16 14 24 3 (unspec_volatile [
(const_int 0 [0])
] VUNSPEC_BLOCKAGE) 252 {blockage}
(nil))
(insn 24 16 27 3 (set (reg/i:SI 0 r0)
(mem/c:SI (plus:SI (reg/f:SI 11 fp)
(const_int -56 [0xffc8])) [6 %sfp+-20 S4 A32]))
comp-goto-2.c:26 176 {*arm_movsi_insn}
(nil))
is reordered into:
(insn 14 18 16 (use (reg/f:SI 11 fp)) -1
(nil))
(insn 16 14 24 (unspec_volatile [
(const_int 0 [0])
] VUNSPEC_BLOCKAGE) 252 {blockage}
(nil))
(insn 24 16 30 (set (reg/i:SI 0 r0)
(mem/c:SI (plus:SI (reg/f:SI 11 fp)
(const_int -20 [0xffec])) [6 %sfp+-20 S4 A32]))
comp-goto-2.c:26 176 {*arm_movsi_insn}
(nil))
(insn 30 24 27 (set (reg/f:SI 11 fp)
(plus:SI (reg/f:SI 11 fp)
(const_int 36 [0x24]))) 4 {*arm_addsi3}
(nil))
despite the blockage.
[Bug target/49764] [gcc-avr] Compiling for Arduino is not working
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49764 --- Comment #11 from _artem_ artemeas at gmail dot com 2011-07-17 00:30:11 UTC --- ok... sorry. it seams to be a avr-g++ bug or arduino bug. Or avr-g++ has changed something in 4.6.1 so const declarations changed. (Then it's arduino teams job to fix the headers) Ok now I know that the command line is: avr-g++ -c -g -Os -w -fno-exceptions -ffunction-sections -fdata-sections -mmcu=atmega328p -DF_CPU=1600L -DARDUINO=22 1.cpp 1.cpp (as you asked): extern const int __attribute__((progmem)) p[]; it gives: 1.cpp:1:45: error: variable 'p' must be const in order to be put into read-only section by means of '__attribute__((progmem))' when I add before the extern ... something like: const int p[]; it gives me: 1.cpp:1:11: error: uninitialized const 'p' [-fpermissive] 1.cpp:1:13: error: storage size of 'p' isn't known 1.cpp:2:45: error: variable 'p' must be const in order to be put into read-only section by means of '__attribute__((progmem))' So I have now no idea if it's arduino's headers, or avr-g++ is guilty. p.s. here is the thread I started on arduino forum (maybe it'll be usefull for you...): http://arduino.cc/forum/index.php/topic,66710.0.html
[Bug c++/48934] no rejection reason given for SFINAE
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48934 --- Comment #16 from Jason Merrill jason at gcc dot gnu.org 2011-07-17 02:34:15 UTC --- Author: jason Date: Sun Jul 17 02:34:10 2011 New Revision: 176365 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176365 Log: PR c++/45329 PR c++/48934 * cp-tree.h (fn_type_unification): Add `bool' parameter. * pt.c (enum template_base_result): Define. (unify_success, unify_unknown): Define. (unify_parameter_deduction_failure): Define. (unify_invalid, unify_cv_qual_mismatch, unify_type_mismatch): Define. (unify_parameter_pack_mismatch): Define. (unify_parameter_pack_inconsistent): Define. (unify_ptrmem_cst_mismatch, unify_vla_arg): Define. (unify_expression_unequal, unify_inconsistency): Define. (unify_method_type_error, unify_arity): Likewise. (unify_too_many_parameters, unify_too_few_parameters): Define. (unify_arg_conversion, unify_no_common_base): Define. (unify_illformed_ptrmem_cst_expr): Define. (unify_substitution_failure): Define. (unify_inconsistent_template_template_parameters): Define. (unify_template_deduction_failure): Define. (unify_template_argument_mismatch): Define. (unify_overload_resolution_failure): Define. (comp_template_args_with_info): New function, split out from... (comp_template_args): ...here.Call it. (deduction_tsubst_fntype): Add `complain' parameter'. Pass it to tsubst. (unify): Add `explain_p' parameter. Pass to all relevant calls. Call above status functions when appropriate. (resolve_overloaded_unification, try_one_overload): Likewise. (type_unification, type_unification_real): Likewise. (unify_pack_expansion): Likewise. (get_template_base, try_class_unification): Likewise. (get_bindings, more_specialized_fn): Pass false to unification calls. (get_class_bindings, do_auto_deduction): Likewise. (convert_nontype_argument): Likewise. (fn_type_unification): Likewise. Pass tf_warning_or_error if explain_p. (get_template_base): Add `explain_p' parameter and pass it to try_class_unification.Return an enum template_base_result. * class.c (resolve_address_of_overloaded_function): Pass false to fn_type_unification. * call.c (enum rejection_reason_code): Add new codes. (struct rejection_reason): Add template_unification field. Add template_instantiation field. (template_unification_rejection): Define. (template_unification_error_rejection): Define. (template_instantiation_rejection): Define. (invalid_copy_with_fn_template_rejection): Define. (add_template_candidate): Pass false to unify. Provide more rejection reasons when possible. (print_template_unification_rejection): Define. (print_arity_rejection): Define, split out from... (print_z_candidate): ...here. Add cases for new rejection reasons. Added: trunk/gcc/testsuite/g++.dg/overload/template5.C trunk/gcc/testsuite/g++.dg/template/overload12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/decltype29.C trunk/gcc/testsuite/g++.dg/cpp0x/error4.C trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice2.C trunk/gcc/testsuite/g++.dg/cpp0x/nullptr15.C trunk/gcc/testsuite/g++.dg/cpp0x/pr31431-2.C trunk/gcc/testsuite/g++.dg/cpp0x/pr31431.C trunk/gcc/testsuite/g++.dg/cpp0x/pr31434.C trunk/gcc/testsuite/g++.dg/cpp0x/sfinae11.C trunk/gcc/testsuite/g++.dg/cpp0x/sfinae26.C trunk/gcc/testsuite/g++.dg/cpp0x/temp_default2.C trunk/gcc/testsuite/g++.dg/cpp0x/trailing4.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic-ex3.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic-ex4.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic105.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-37737-2.C trunk/gcc/testsuite/g++.dg/ext/vla2.C trunk/gcc/testsuite/g++.dg/other/ptrmem10.C trunk/gcc/testsuite/g++.dg/other/ptrmem11.C trunk/gcc/testsuite/g++.dg/overload/unknown1.C trunk/gcc/testsuite/g++.dg/template/conv11.C trunk/gcc/testsuite/g++.dg/template/deduce3.C trunk/gcc/testsuite/g++.dg/template/dependent-expr5.C trunk/gcc/testsuite/g++.dg/template/error45.C trunk/gcc/testsuite/g++.dg/template/friend.C trunk/gcc/testsuite/g++.dg/template/incomplete2.C trunk/gcc/testsuite/g++.dg/template/local4.C trunk/gcc/testsuite/g++.dg/template/local6.C trunk/gcc/testsuite/g++.dg/template/operator9.C trunk/gcc/testsuite/g++.dg/template/ptrmem2.C trunk/gcc/testsuite/g++.dg/template/sfinae2.C trunk/gcc/testsuite/g++.dg/template/ttp25.C trunk/gcc/testsuite/g++.dg/template/unify10.C trunk/gcc/testsuite/g++.dg/template/unify11.C trunk/gcc/testsuite/g++.dg/template/unify6.C trunk/gcc/testsuite/g++.dg/template/unify7.C
[Bug c++/45329] When printing a list of candidate functions, explain why each function failed to match.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45329 --- Comment #6 from Jason Merrill jason at gcc dot gnu.org 2011-07-17 02:34:15 UTC --- Author: jason Date: Sun Jul 17 02:34:10 2011 New Revision: 176365 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=176365 Log: PR c++/45329 PR c++/48934 * cp-tree.h (fn_type_unification): Add `bool' parameter. * pt.c (enum template_base_result): Define. (unify_success, unify_unknown): Define. (unify_parameter_deduction_failure): Define. (unify_invalid, unify_cv_qual_mismatch, unify_type_mismatch): Define. (unify_parameter_pack_mismatch): Define. (unify_parameter_pack_inconsistent): Define. (unify_ptrmem_cst_mismatch, unify_vla_arg): Define. (unify_expression_unequal, unify_inconsistency): Define. (unify_method_type_error, unify_arity): Likewise. (unify_too_many_parameters, unify_too_few_parameters): Define. (unify_arg_conversion, unify_no_common_base): Define. (unify_illformed_ptrmem_cst_expr): Define. (unify_substitution_failure): Define. (unify_inconsistent_template_template_parameters): Define. (unify_template_deduction_failure): Define. (unify_template_argument_mismatch): Define. (unify_overload_resolution_failure): Define. (comp_template_args_with_info): New function, split out from... (comp_template_args): ...here.Call it. (deduction_tsubst_fntype): Add `complain' parameter'. Pass it to tsubst. (unify): Add `explain_p' parameter. Pass to all relevant calls. Call above status functions when appropriate. (resolve_overloaded_unification, try_one_overload): Likewise. (type_unification, type_unification_real): Likewise. (unify_pack_expansion): Likewise. (get_template_base, try_class_unification): Likewise. (get_bindings, more_specialized_fn): Pass false to unification calls. (get_class_bindings, do_auto_deduction): Likewise. (convert_nontype_argument): Likewise. (fn_type_unification): Likewise. Pass tf_warning_or_error if explain_p. (get_template_base): Add `explain_p' parameter and pass it to try_class_unification.Return an enum template_base_result. * class.c (resolve_address_of_overloaded_function): Pass false to fn_type_unification. * call.c (enum rejection_reason_code): Add new codes. (struct rejection_reason): Add template_unification field. Add template_instantiation field. (template_unification_rejection): Define. (template_unification_error_rejection): Define. (template_instantiation_rejection): Define. (invalid_copy_with_fn_template_rejection): Define. (add_template_candidate): Pass false to unify. Provide more rejection reasons when possible. (print_template_unification_rejection): Define. (print_arity_rejection): Define, split out from... (print_z_candidate): ...here. Add cases for new rejection reasons. Added: trunk/gcc/testsuite/g++.dg/overload/template5.C trunk/gcc/testsuite/g++.dg/template/overload12.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/cp/class.c trunk/gcc/cp/cp-tree.h trunk/gcc/cp/pt.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/cpp0x/decltype29.C trunk/gcc/testsuite/g++.dg/cpp0x/error4.C trunk/gcc/testsuite/g++.dg/cpp0x/lambda/lambda-ice2.C trunk/gcc/testsuite/g++.dg/cpp0x/nullptr15.C trunk/gcc/testsuite/g++.dg/cpp0x/pr31431-2.C trunk/gcc/testsuite/g++.dg/cpp0x/pr31431.C trunk/gcc/testsuite/g++.dg/cpp0x/pr31434.C trunk/gcc/testsuite/g++.dg/cpp0x/sfinae11.C trunk/gcc/testsuite/g++.dg/cpp0x/sfinae26.C trunk/gcc/testsuite/g++.dg/cpp0x/temp_default2.C trunk/gcc/testsuite/g++.dg/cpp0x/trailing4.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic-ex3.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic-ex4.C trunk/gcc/testsuite/g++.dg/cpp0x/variadic105.C trunk/gcc/testsuite/g++.dg/cpp0x/vt-37737-2.C trunk/gcc/testsuite/g++.dg/ext/vla2.C trunk/gcc/testsuite/g++.dg/other/ptrmem10.C trunk/gcc/testsuite/g++.dg/other/ptrmem11.C trunk/gcc/testsuite/g++.dg/overload/unknown1.C trunk/gcc/testsuite/g++.dg/template/conv11.C trunk/gcc/testsuite/g++.dg/template/deduce3.C trunk/gcc/testsuite/g++.dg/template/dependent-expr5.C trunk/gcc/testsuite/g++.dg/template/error45.C trunk/gcc/testsuite/g++.dg/template/friend.C trunk/gcc/testsuite/g++.dg/template/incomplete2.C trunk/gcc/testsuite/g++.dg/template/local4.C trunk/gcc/testsuite/g++.dg/template/local6.C trunk/gcc/testsuite/g++.dg/template/operator9.C trunk/gcc/testsuite/g++.dg/template/ptrmem2.C trunk/gcc/testsuite/g++.dg/template/sfinae2.C trunk/gcc/testsuite/g++.dg/template/ttp25.C trunk/gcc/testsuite/g++.dg/template/unify10.C trunk/gcc/testsuite/g++.dg/template/unify11.C trunk/gcc/testsuite/g++.dg/template/unify6.C trunk/gcc/testsuite/g++.dg/template/unify7.C
[Bug other/49767] New: __mulsc3 runs into infinite recursion if GCC is compiled with -O0 option
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49767
Summary: __mulsc3 runs into infinite recursion if GCC is
compiled with -O0 option
Product: gcc
Version: 4.3.2
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: waffle@gmail.com
The GCC built is of version 4.3.2 and is configured with option
``--enable-languages=c,c++,fortran --disable-libada' CFLAGS='-O0 -g' ''
`uname -a' : Linux f18 2.6.34.8-68.fc13.i686.PAE #1 SMP Thu Feb 17 14:54:10 UTC
2011 i686 i686 i386 GNU/Linux
The implementation of __mulsc3 in libgcc2.c is somehow contingent on certain
optimization to get rid of the infinite tail call recursion.
A simple test program is as follows.
#include stdio.h
int main (int argc, char **argv) {
_Complex float c = 2.5fi;
_Complex float d = 1.0;
_Complex float x, y;
float a = (float) argc;
x = c * d;
y = a * 1i;
printf (%f %f\n, __imag__ x, y);
return 0;
}
