[Bug c++/53594] [C++11] Spurious -Wuninitialized warning for member with NSDMI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53594 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #9 from Jakub Jelinek 2012-06-25 06:55:09 UTC --- Fixed.
[Bug c++/53594] [C++11] Spurious -Wuninitialized warning for member with NSDMI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53594 Jakub Jelinek changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #8 from Jakub Jelinek 2012-06-25 06:54:12 UTC --- Author: jakub Date: Mon Jun 25 06:54:08 2012 New Revision: 188926 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188926 Log: PR c++/53594 * class.c (check_bases_and_members): Avoid -Wuninitialized diagnostics for non-static const members or references if they use NSDMI. * g++.dg/cpp0x/nsdmi7.C: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/nsdmi7.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/class.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog --- Comment #9 from Jakub Jelinek 2012-06-25 06:55:09 UTC --- Fixed.
[Bug c++/53594] [C++11] Spurious -Wuninitialized warning for member with NSDMI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53594 --- Comment #8 from Jakub Jelinek 2012-06-25 06:54:12 UTC --- Author: jakub Date: Mon Jun 25 06:54:08 2012 New Revision: 188926 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188926 Log: PR c++/53594 * class.c (check_bases_and_members): Avoid -Wuninitialized diagnostics for non-static const members or references if they use NSDMI. * g++.dg/cpp0x/nsdmi7.C: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/g++.dg/cpp0x/nsdmi7.C Modified: branches/gcc-4_7-branch/gcc/cp/ChangeLog branches/gcc-4_7-branch/gcc/cp/class.c branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
[Bug c/53760] attribute packed doesn't pack inner structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53760 Jakub Jelinek changed: What|Removed |Added CC||jakub at gcc dot gnu.org --- Comment #5 from Jakub Jelinek 2012-06-25 06:51:12 UTC --- It is not a useless limitation. While you can't take address of a bitfield, you can take address of a struct field, even when it contains only bitfields.
[Bug c++/53594] [C++11] Spurious -Wuninitialized warning for member with NSDMI
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53594 --- Comment #7 from Jakub Jelinek 2012-06-25 06:48:09 UTC --- Author: jakub Date: Mon Jun 25 06:48:04 2012 New Revision: 188925 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=188925 Log: PR c++/53594 * class.c (check_bases_and_members): Avoid -Wuninitialized diagnostics for non-static const members or references if they use NSDMI. * g++.dg/cpp0x/nsdmi7.C: New test. Added: trunk/gcc/testsuite/g++.dg/cpp0x/nsdmi7.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/class.c trunk/gcc/testsuite/ChangeLog
[Bug c++/53765] Internal errror in build_call_a at cp/call.c:342
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53765 --- Comment #1 from Étienne 2012-06-25 05:40:22 UTC --- Same internal error on g++ 4.5.3.
[Bug c++/53765] New: Internal errror in build_call_a at cp/call.c:342
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53765 Bug #: 53765 Summary: Internal errror in build_call_a at cp/call.c:342 Classification: Unclassified Product: gcc Version: 4.6.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: svart.ridd...@gmail.com Created attachment 27697 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27697 Input file that triggers the internal error. Using command line "g++ gcc-bug.cpp -std=c++0x" with the given attachment, g++ fails with an internal error : gcc-bug.cpp: In function ‘T operation(T, T) [with T = int, bool m = false]’: gcc-bug.cpp:22:35: instantiated from here gcc-bug.cpp:17:17: erreur interne du compilateur: dans build_call_a, à cp/call.c:342 See attached file for a minimal test case which displays the bug. Regards, Étienne
[Bug debug/53740] [4.8 Regression] --enable-checking=yes,rtl bootstrap failure with ada
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53740 Alexandre Oliva changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #2 from Alexandre Oliva 2012-06-25 05:25:54 UTC --- Richard Sandiford has a patch that will probably cure this: http://gcc.gnu.org/ml/gcc-patches/2012-06/msg01530.html
[Bug target/53682] [4.7/4.8 Regression] ICE in cselib_lookup (SEGV) on i586-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53682 Alexandre Oliva changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED | --- Comment #8 from Alexandre Oliva 2012-06-25 03:54:48 UTC --- Yeah, sorry, closing it was a mistake. Testing it on the 4.7 branch now.
[Bug c++/53488] Incorrect code generated when capturing a constant by reference in a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53488
Daniel Lunow changed:
What|Removed |Added
CC||lunow at math dot
||hu-berlin.de
--- Comment #8 from Daniel Lunow 2012-06-25
00:32:00 UTC ---
Then you must have missed the example in 5.1.2 [expr.prim.lambda] p. 12.
[Example:
void f1(int i) {
int const N = 20;
auto m1 = [=]{
int const M = 30;
auto m2 = [i]{
int x[N][M]; // OK: N and M are not odr-used
// ...
};
};
// ...
}
- end example]
Sure its non-normative, but this is what has always worked through a
combination of
8.3.4 [dcl.array], 3.4.1p1,6 [basic.lookup.unqual], 3.3.1p1
[basic.scope.declarative], 3.3.3p1,3 [basic.scope.local] and 5.19p2
[expr.const].
By the way the bug is independent of capturing by value/reference and in my
second example nothing is captured at all. It is not necessary to capture,
because i is not odr-used (5.1.2p11, 3.2p2).
I just put it here because, it occurs under the same circumstances
* constant integral local variable
* initialized by an expression dependent on a template parameter, but not if
the initializer is the name of a non-template type parameter
* used (but not odr-used) inside lambda.
and of course gcc has no problems with both examples, if i's initialization
does not depend on a template parameter.
[Bug target/40134] symbols not resolved when building shared libraries (link with -lgcc_s -lgcc?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40134 --- Comment #8 from Thorsten Glaser 2012-06-24 23:27:34 UTC --- Looks like this is needed for all architectures having such symbols in libgcc.a only – I just backported those for m68k to gcc-4.6 and encountered this issue, which Mikael Pettersson helped to solve. Just so anyone who’ll encounter these later knows. (Also, rebuild *all* involved DLLs against the libgcc_s.so linker script, not just libstdc++.)
[Bug target/40134] symbols not resolved when building shared libraries (link with -lgcc_s -lgcc?)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40134 Thorsten Glaser changed: What|Removed |Added CC||tg at mirbsd dot org --- Comment #7 from Thorsten Glaser 2012-06-24 23:25:53 UTC --- Looks like this is needed for all architectures having such symbols in libgcc.a only – I just backported those for m68k to gcc-4.6 and encountered this issue, which Mikael Pettersson helped to solve.
[Bug c++/53488] Incorrect code generated when capturing a constant by reference in a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53488
--- Comment #7 from Jiří Paleček 2012-06-24 20:23:38
UTC ---
Daniel, sorry, but I don't think your second example is relevant. First this
bug occurs only when capturing by reference, not by value, but your second
example uses capture by value. Moreover, while reading the standard, I can't
find anything that mandates the usage like yours to work. AFAIK it allows the
compiler to treat the lambda from your second example akin to this:
int foo() {
const int i = 1;
struct Lambda {
const int i;
Lambda(int i_) : i(i_) {}
void operator()()const {
int x[i];
}
};
Lambda l(i);
}
which wouldn't work, and quite rightly. It couldn't even be modified to work,
as i must be static if it has to be both compile time constant and member of a
class.
[Bug c++/53488] Incorrect code generated when capturing a constant by reference in a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53488 Jiří Paleček changed: What|Removed |Added CC||lunow at math dot ||hu-berlin.de --- Comment #6 from Jiří Paleček 2012-06-24 20:12:43 UTC --- Daniel, sorry, but I don't think your second ex
[Bug c++/53763] Missing error check on decltype when used within variadic template argument list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53763 Daniel Krügler changed: What|Removed |Added CC||daniel.kruegler at ||googlemail dot com --- Comment #1 from Daniel Krügler 2012-06-24 18:38:50 UTC --- This problem seems not to exist in 4.8.x HEAD, the error message is: "25|error: template argument 1 is invalid"
[Bug c/53760] attribute packed doesn't pack inner structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53760 --- Comment #4 from Stas Sergeev 2012-06-24 18:20:00 UTC --- Is this mandated in some spec or doc? Any way to defeat that? :) Btw, why can't the "attribute packed" be allowed to pack on a bit boundary too? Sounds like a useless limitation, no?
[Bug c/53760] attribute packed doesn't pack inner structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53760 --- Comment #3 from Andrew Pinski 2012-06-24 18:12:39 UTC --- Because each inner struct has to be at a byte boundary.
[Bug c++/53762] pointer-casts don't always check null-pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53762 Andrew Pinski changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||INVALID --- Comment #3 from Andrew Pinski 2012-06-24 18:09:39 UTC --- Invalid as mentioned as: pa = &static_cast(*pb); ^^^ Deferences a null pointer at the caret.
[Bug c/53760] attribute packed doesn't pack inner structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53760
--- Comment #2 from Stas Sergeev 2012-06-24
18:09:18 UTC ---
Even if "attribute packed" have nothing to do with this,
then why doesn't it pack regardless?
Eg,
struct {
char a:1;
char b:1;
char c:1;
}
would be packed, no matter what.
Why does the same not happen to the struct?
Any way to force such a packing? There is an
obvious (IMHO) need for that.
[Bug c/53760] attribute packed doesn't pack inner structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53760 --- Comment #1 from Andrew Pinski 2012-06-24 17:59:08 UTC --- I think having a size of 4 is correct. Packed is on a byte boundary and not a bit boundary.
[Bug target/53758] Segfault at 'vmovaps' when setting pointer array in a loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53758 Jan Boon changed: What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID --- Comment #2 from Jan Boon 2012-06-24 17:06:44 UTC --- Apparently one of the base classes was making this class use a specific allocator that's not using the correct alignment.
[Bug translation/53764] New: Typo in translatable string: "literalto"
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53764 Bug #: 53764 Summary: Typo in translatable string: "literalto" Classification: Unclassified Product: gcc Version: 4.7.1 Status: UNCONFIRMED Severity: normal Priority: P3 Component: translation AssignedTo: unassig...@gcc.gnu.org ReportedBy: sti...@antcom.de Created attachment 27696 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27696 Patch that fixes it Typo in translatable string: "literalto": Comes from wrong C style string linebreak. gcc/go/gofrontend/parse.cc: 2900: Patch attached.
[Bug c++/53762] pointer-casts don't always check null-pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53762 --- Comment #2 from Jonathan Wakely 2012-06-24 16:30:54 UTC --- These are allowed: pa = static_cast(pb); pb = static_cast(pa); All the other casts are not because they involve dereferencing a null pointer which is not allowed by [expr.unary.op]/1 Also, GCC 4.2 is not supported or maintained so there's no point reporting bugs against it, you should check a newer release before reporting bugs.
[Bug c++/53762] pointer-casts don't always check null-pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53762 Jonathan Wakely changed: What|Removed |Added Severity|major |normal --- Comment #1 from Jonathan Wakely 2012-06-24 16:26:17 UTC --- Your program dereferences null pointers, that's undefined behaviour.
[Bug c++/53763] New: Missing error check on decltype when used within variadic template argument list
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53763
Bug #: 53763
Summary: Missing error check on decltype when used within
variadic template argument list
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: o.mang...@googlemail.com
In the example below, which is invalid code, no appropriate compiler error is
reported. The code is wrong, because "decltype(A::a(2))" is invalid as A is a
template class and would need template arguments.
The compiler seams to silently skip the function call to B::b as if it was not
there (it produces only a message for the first call of b). The only thing that
is reported, though, is that y is used uninitialized. Apparently a later stage
knows that the function was not called.
It seems necessary that B takes a variadic template argument list for the
problem to appear, but I couldn't nail it down further.
--- compiler output ---
> g++ -Wall -std=c++11 example.c
example.c: In function ‘int main()’:
example.c:26:12: warning: ‘y’ is used uninitialized in this function
[-Wuninitialized]
--- example.cxx ---
#include
template
struct A
{
static int a(TYPE value)
{
return value;
}
};
template
struct B
{
static int b(ARGS... args)
{
printf("hello world %i\n",args...);
return 0;
}
};
int main()
{
int x = B::a(1))>::b(A::a(1));
int y = B::b(A::a(2));
return x+y;
}
[Bug c++/53762] New: pointer-casts don't always check null-pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53762
Bug #: 53762
Summary: pointer-casts don't always check null-pointers
Classification: Unclassified
Product: gcc
Version: 4.2.1
Status: UNCONFIRMED
Severity: major
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: imzh...@vip.qq.com
Created attachment 27695
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27695
examples of lacking null-pointer check
under these situations, null-pointers are not converted to null-pointers as the
standard says;
1. with 'this' pointer:
class A
{
public:
int asomething; // important: if there's nothing in class A, the functions
seems right;
};
class B
: public A
{
public:
virtual ~B() {}
void* thisoffset() {
return static_cast(this);
}
void* offset() {
B * pb = this;
return static_cast(pb);
}
};
the two 'offset' function returns a 'offset of object of type A in objec of
type B ', and a null-pointer. i think null-point should be right.
2. with reference from DERIVED class to BASE class:
// class A & B defined as the above
A* pa = NULL; B*pb = NULL;
pa = &static_cast(*pb);
^^ will not perform null-pointer check;
A* pa = NULL; B*pb = NULL;
pa = static_cast(pb);
^ will perform null-pointer check;
[Bug target/53759] [4.7/4.8 Regression] gcc -mavx emits vshufps for __builtin_ia32_loadlps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53759 --- Comment #3 from H.J. Lu 2012-06-24 15:46:33 UTC --- It is caused by revision 172123: http://gcc.gnu.org/ml/gcc-cvs/2011-04/msg00316.html
[Bug target/53759] [4.7/4.8 Regression] gcc -mavx emits vshufps for __builtin_ia32_loadlps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53759
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-06-24
CC||areg.melikadamyan at gmail
||dot com, hjl.tools at gmail
||dot com, ubizjak at gmail
||dot com
Target Milestone|--- |4.7.2
Summary|gcc -mavx emits vshufps for |[4.7/4.8 Regression] gcc
|__builtin_ia32_loadlps |-mavx emits vshufps for
||__builtin_ia32_loadlps
Ever Confirmed|0 |1
--- Comment #2 from H.J. Lu 2012-06-24 14:54:44
UTC ---
GCC 4.6 doesn't have this problem:
[hjl@gnu-6 pr53759]$ cat x.i
typedef float v4sf __attribute__ ((vector_size (4*4)));
typedef float v2sf __attribute__ ((vector_size (4*2)));
v2sf mem[1];
int main()
{
v4sf reg = (v4sf){0,0,0,0};
reg = __builtin_ia32_loadlps(reg, mem);
return reg[0];
}
[hjl@gnu-6 pr53759]$ gcc -S -mavx -O x.i
[hjl@gnu-6 pr53759]$ cat x.s
.file"x.i"
.text
.globlmain
.typemain, @function
main:
.LFB0:
.cfi_startproc
vxorps%xmm0, %xmm0, %xmm0
vmovlpsmem(%rip), %xmm0, %xmm0
vcvttss2si%xmm0, %eax
ret
.cfi_endproc
.LFE0:
.sizemain, .-main
.commmem,8,8
.ident"GCC: (GNU) 4.6.3 20120306 (Red Hat 4.6.3-2)"
.section.note.GNU-stack,"",@progbits
[hjl@gnu-6 pr53759]$
[Bug c++/53488] Incorrect code generated when capturing a constant by reference in a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53488 --- Comment #5 from Daniel Lunow 2012-06-24 14:30:19 UTC --- Created attachment 27694 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27694 integral constant-expression not an integral constant-expression This test case should compile, but it does not. Its not the same as the constant not beeing captured, but I can imagine it is very close problem. C:\dev\projects\compiler test>g++ -std=c++11 gcc_test6.cpp gcc_test6.cpp: In instantiation of 'foo() [with T = void]::': gcc_test6.cpp:8:4: required from 'struct foo() [with T = void]::' gcc_test6.cpp:8:3: required from 'void foo() [with T = void]' gcc_test6.cpp:13:13: required from here gcc_test6.cpp:8:15: error: size of array is not an integral constant-expression
[Bug c++/53761] New: ICE (only with C++) on incorrect transparent union (first field has floating point type)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53761
Bug #: 53761
Summary: ICE (only with C++) on incorrect transparent union
(first field has floating point type)
Classification: Unclassified
Product: gcc
Version: 4.7.1
Status: UNCONFIRMED
Severity: minor
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: br+...@waldteufel.eu
While compiling
typedef union {
double x;
} __attribute__(( __transparent_union__ )) example_t;
void fail(example_t x) { }
int main() {
example_t x;
fail(x);
}
as C code results in a warning message (see below for detailed system
information)
> gcc fail.c
fail.c:1:9: warning: union cannot be made transparent [enabled by default]
compiling the same code as C++ results in an ICE
> g++ -v fail.cc
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: /build/src/gcc-4.7.1/configure --prefix=/usr --libdir=/usr/lib
--libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
--with-bugurl=https://bugs.archlinux.org/
--enable-languages=c,c++,ada,fortran,go,lto,objc,obj-c++ --enable-shared
--enable-threads=posix --with-system-zlib --enable-__cxa_atexit
--disable-libunwind-exceptions --enable-clocale=gnu --disable-libstdcxx-pch
--enable-libstdcxx-time --enable-gnu-unique-object --enable-linker-build-id
--with-ppl --enable-cloog-backend=isl --enable-lto --enable-gold
--enable-ld=default --enable-plugin --with-plugin-ld=ld.gold
--with-linker-hash-style=gnu --disable-multilib --disable-libssp
--disable-build-with-cxx --disable-build-poststage1-with-cxx
--enable-checking=release
Thread model: posix
gcc version 4.7.1 (GCC)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/cc1plus -quiet -v -D_GNU_SOURCE
fail.cc -quiet -dumpbase fail.cc -mtune=generic -march=x86-64 -auxbase fail
-version -o /tmp/cc6IkFB2.s
GNU C++ (GCC) version 4.7.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.1, GMP version 5.0.5, MPFR version 3.1.0-p10,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=97 --param ggc-min-heapsize=126590
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../x86_64-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/x86_64-unknown-linux-gnu
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/../../../../include/c++/4.7.1/backward
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include
/usr/local/include
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.1/include-fixed
/usr/include
End of search list.
GNU C++ (GCC) version 4.7.1 (x86_64-unknown-linux-gnu)
compiled by GNU C version 4.7.1, GMP version 5.0.5, MPFR version 3.1.0-p10,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=97 --param ggc-min-heapsize=126590
Compiler executable checksum: ed88b587bcb9a173af71789c9d103676
fail.cc: In function 'int main()':
fail.cc:9:11: internal compiler error: in convert_move, at expr.c:325
Please submit a full bug report,
with preprocessed source if appropriate.
See
[Bug target/53758] Segfault at 'vmovaps' when setting pointer array in a loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53758 H.J. Lu changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-06-24 CC||areg.melikadamyan at gmail ||dot com, hjl.tools at gmail ||dot com Ever Confirmed|0 |1 --- Comment #1 from H.J. Lu 2012-06-24 14:29:10 UTC --- Please provide a testcase.
[Bug debug/52857] DW_OP_GNU_regval_type is generated with INVALID_REGNUM
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52857 H.J. Lu changed: What|Removed |Added URL|http://gcc.gnu.org/ml/gcc-p |http://gcc.gnu.org/ml/gcc-p |atches/2012-04/msg00358.htm |atches/2012-04/msg01815.htm |l |l --- Comment #7 from H.J. Lu 2012-06-24 14:23:51 UTC --- The updated patch is at http://gcc.gnu.org/ml/gcc-patches/2012-04/msg01815.html
[Bug c++/53488] Incorrect code generated when capturing a constant by reference in a lambda
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53488 --- Comment #4 from Daniel Lunow 2012-06-24 14:21:31 UTC --- Created attachment 27693 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27693 small test case Just wanted to report the same bug with gcc 4.7.1. I found out, that it occurs, if the initializer depends on some template argument. C:\dev\projects\compiler test>g++ -std=c++11 gcc_test5.cpp -Wall -o gcc_test5.exe gcc_test5.cpp: In lambda function: gcc_test5.cpp:10:29: warning: 'i' is used uninitialized in this function [-Wuninitialized] C:\dev\projects\compiler test>gcc_test5.exe 0 which should have given 4.
[Bug c/53760] New: attribute packed doesn't pack inner structs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53760
Bug #: 53760
Summary: attribute packed doesn't pack inner structs
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: s...@users.sourceforge.net
The following code:
---
#include
struct A {
char a:1;
struct {
char a:1;
} __attribute__((packed)) s1;
struct {
char a:1;
} __attribute__((packed)) s2;
struct {
char a:1;
} __attribute__((packed)) s3;
} __attribute__((packed));
int main()
{
printf("%lu\n", sizeof(struct A));
return 0;
}
---
prints '4' instead of '1'.
Every bitfield seems to be occupying an entire byte.
[Bug target/53682] [4.7/4.8 Regression] ICE in cselib_lookup (SEGV) on i586-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53682 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #7 from Mikael Pettersson 2012-06-24 13:02:36 UTC --- I think this was closed as fixed too soon, as the regression is still present in 4.7-20120623. Backporting the 4.8 patch eliminates the ICE in 4.7 too.
[Bug target/53759] gcc -mavx emits vshufps for__builtin_ia32_loadlps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53759
--- Comment #1 from Dag Lem 2012-06-24 12:45:55 UTC ---
Test code as follows:
typedef float v4sf __attribute__ ((vector_size (4*4)));
typedef float v2sf __attribute__ ((vector_size (4*2)));
v2sf mem[1];
int main()
{
v4sf reg = (v4sf){0,0,0,0};
reg = __builtin_ia32_loadlps(reg, mem);
return reg[0];
}
With -msse, gcc emits the following code:
xorps%xmm0, %xmm0
movlpsmem, %xmm0
However with -mavx, gcc emits:
vxorps%xmm0, %xmm0, %xmm0
vmovlpsmem, %xmm1, %xmm1
vshufps$0xe4, %xmm0, %xmm1, %xmm0
Shouldn't this rather have been something like
vxorps%xmm0, %xmm0, %xmm0
vmovlpsmem, %xmm0, %xmm0
???
[Bug target/53759] New: gcc -mavx emits vshufps for__builtin_ia32_loadlps
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53759 Bug #: 53759 Summary: gcc -mavx emits vshufps for__builtin_ia32_loadlps Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: d...@nimrod.no
[Bug target/53758] New: Segfault at 'vmovaps' when setting pointer array in a loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53758
Bug #: 53758
Summary: Segfault at 'vmovaps' when setting pointer array in a
loop
Classification: Unclassified
Product: gcc
Version: 4.6.3
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: jan.b...@kaetemi.be
Created attachment 27692
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27692
Disassemly of function and list of registers.
Segfault in a simple loop that sets pointers in an array to NULL.
Target is -march=bdver1 -mtune=bdver1.
for(i = 0; i < NL_DLM_LIGHTMAP_TYPE_SIZE; i++)
{
_FreeBlocks[i] = NULL;
}
0x76ea4b00 <+608>:inc%edx
=> 0x76ea4b02 <+610>:vmovaps %xmm0,(%rcx)
0x76ea4b06 <+614>:add$0x10,%rcx
0x76ea4b0a <+618>:cmp%edx,%esi
0x76ea4b0c <+620>:ja 0x76ea4b00
edx0x11
rcx0x159106a4361825956
esi0x88
Full log in attachment.
[Bug tree-optimization/53663] 4.7 inconsistent inline handling of bool within union
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53663 --- Comment #4 from brendan.jones.it at gmail dot com 2012-06-24 07:56:59 UTC --- Hi, have you been able to replicate this issue with the second example I have sent? If so is there a known workaround that we can use? many thanks Brendan
