[Bug target/52883] ICE in simplify_const_unary_operation, at simplify-rtx.c:1464
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52883 Uros Bizjak changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | --- Comment #8 from Uros Bizjak 2012-04-09 07:29:10 UTC --- (In reply to comment #7) > "For all conversion operations, X must not be `VOIDmode' because the > mode in which to do the conversion would not be known. The conversion > must either be done at compile-time or X must be placed into a register. I was not aware of this little detail... Taking the bug.
[Bug rtl-optimization/48496] [4.7/4.8 Regression] 'asm' operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496
--- Comment #19 from Eric Botcazou 2012-04-09
08:04:40 UTC ---
> However, recog.c contains in various places checks that will *accept* -during
> reload- a pseudo in places where a memory constraint is required; exactly
> because such pseudos will actually get replaced by a MEM:
>
> case TARGET_MEM_CONSTRAINT:
> [snip]
> /* During reload, accept a pseudo */
> else if (reload_in_progress && REG_P (op)
> && REGNO (op) >= FIRST_PSEUDO_REGISTER)
> win = 1;
>
> Note that those checks were originally added in the same patch that added this
> asm validity check ...
OK, this makes sense.
> So really that validity check shouldn't have failed just because of the
> presence of a spilled pseudo. The question is, why doesn't this work for the
> ia64 test case as expected?
Because the reload insns are of the form:
(insn 119 66 120 4 (set (reg:DI 136 f8)
(reg:DI 406 [ MEM[(const mp_limb_t *)mip_6(D) + 8B] ])) pr52657.c:27 5
{movdi_internal}
and the matching alternative would be (f, Q) with
;; Note that while this accepts mem, it only accepts non-volatile mem,
;; and so cannot be "fixed" by adjusting the address. Thus it cannot
;; and does not use define_memory_constraint.
(define_constraint "Q"
"Non-volatile memory for FP_REG loads/stores"
(and (match_operand 0 "memory_operand")
(match_test "!MEM_VOLATILE_P (op)")))
bool
insn_extra_memory_constraint (enum constraint_num c)
{
switch (c)
{
case CONSTRAINT_S:
return true;
default: break;
}
return false;
}
[Bug target/52883] ICE in simplify_const_unary_operation, at simplify-rtx.c:1464
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52883 --- Comment #9 from Uros Bizjak 2012-04-09 08:07:47 UTC --- Created attachment 27116 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27116 Untested patch Patch in testing.
[Bug target/52908] xop-mul-1:f9 miscompiled on bulldozer (-mxop)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52908 Uros Bizjak changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2012-04-09 AssignedTo|unassigned at gcc dot |ubizjak at gmail dot com |gnu.org | Ever Confirmed|0 |1 --- Comment #1 from Uros Bizjak 2012-04-09 08:16:26 UTC --- (In reply to comment #0) > I've no idea how best to solve this, either deactivating the sse4.1 pattern > when TARGET_XOP, or rewriting the latter to not early-clobber result, or > something else entirely. I've tested that the first way fixes this problem. We have attribute enabled for these case. I can take this bug, if you don't mind.
[Bug target/52717] thunk referenced in discarded section when building samba with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717 --- Comment #8 from Eric Botcazou 2012-04-09 08:53:33 UTC --- Author: ebotcazou Date: Mon Apr 9 08:53:27 2012 New Revision: 186237 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186237 Log: PR target/52717 * config/sparc/sparc.c (sparc_file_end): Set TREE_PUBLIC explicitly on the DECL generated for the special GOT helper. Modified: trunk/gcc/ChangeLog trunk/gcc/config/sparc/sparc.c
[Bug target/52717] thunk referenced in discarded section when building samba with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717 --- Comment #10 from Eric Botcazou 2012-04-09 08:53:54 UTC --- Author: ebotcazou Date: Mon Apr 9 08:53:49 2012 New Revision: 186239 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186239 Log: PR target/52717 * config/sparc/sparc.c (sparc_file_end): Set TREE_PUBLIC explicitly on the DECL generated for the special GOT helper. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/sparc/sparc.c
[Bug target/52717] thunk referenced in discarded section when building samba with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717 --- Comment #11 from Eric Botcazou 2012-04-09 08:54:07 UTC --- Author: ebotcazou Date: Mon Apr 9 08:54:03 2012 New Revision: 186240 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186240 Log: PR target/52717 * config/sparc/sparc.c (sparc_file_end): Set TREE_PUBLIC explicitly on the DECL generated for the special GOT helper. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/sparc/sparc.c
[Bug target/52717] thunk referenced in discarded section when building samba with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717 --- Comment #9 from Eric Botcazou 2012-04-09 08:53:40 UTC --- Author: ebotcazou Date: Mon Apr 9 08:53:37 2012 New Revision: 186238 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186238 Log: PR target/52717 * config/sparc/sparc.c (sparc_file_end): Set TREE_PUBLIC explicitly on the DECL generated for the special GOT helper. Modified: branches/gcc-4_7-branch/gcc/ChangeLog branches/gcc-4_7-branch/gcc/config/sparc/sparc.c
[Bug target/52717] thunk referenced in discarded section when building samba with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52717 Eric Botcazou changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.5.4 --- Comment #12 from Eric Botcazou 2012-04-09 08:57:04 UTC --- Thanks for reporting the problem.
[Bug target/52883] ICE in simplify_const_unary_operation, at simplify-rtx.c:1464
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52883 --- Comment #10 from uros at gcc dot gnu.org 2012-04-09 09:57:18 UTC --- Author: uros Date: Mon Apr 9 09:57:13 2012 New Revision: 186243 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186243 Log: PR target/52883 * config/i386/predicates.md (x86_64_zext_general_operand): Prevent VOIDmode immediate operands. * config/i386/constraints.md (Wz): New constraint. * config/i386/i386.md (*zero_extendsidi2_rex64): Use Wz instead of Z. testsuite/ChangeLog: PR target/52883 * gcc.target/i386/pr52883.c: New testcase. Added: trunk/gcc/testsuite/gcc.target/i386/pr52883.c Modified: trunk/gcc/ChangeLog trunk/gcc/config/i386/constraints.md trunk/gcc/config/i386/i386.md trunk/gcc/config/i386/predicates.md trunk/gcc/testsuite/ChangeLog
[Bug target/52883] ICE in simplify_const_unary_operation, at simplify-rtx.c:1464
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52883 Uros Bizjak changed: What|Removed |Added Target||x86 Status|ASSIGNED|RESOLVED URL||http://gcc.gnu.org/ml/gcc-p ||atches/2012-04/msg00424.htm ||l Resolution||FIXED --- Comment #11 from Uros Bizjak 2012-04-09 10:02:40 UTC --- Fixed.
[Bug java/49258] -ffunction-sections and --gc-sectinons have no effect at gcj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49258
--- Comment #6 from licheng.1212 at gmail dot com 2012-04-09 11:14:56 UTC ---
(In reply to comment #5)
> (In reply to comment #4)
> > Yes,but why we can't remove the function notused() form vtable, since this
> > function will never used.
>
> How can you tell? Without the full exectuable and knowing the entry point,
> there is no way (-fwhole-program can help but it becomes a turning machine at
> that point).
class hello{
public void notused()
{
System.out.println("not used");
}
public static void main(String argv[])
{
System.out.println("Hello");
}
}
this is a full execlutable program,and it hava only one entry point "main"!
and i test a c++ file,it will remove the unused funcitons "notused":
[licheng@Soft04 ~]$ cat hello.cpp
#include
class hello
{
public:
hello()
{
}
void notused()
{
std::cout << "not used";
}
void used()
{
std::cout << "used";
}
~hello()
{
}
}hi;
int main()
{ hello t;
t.used();
return 0;
}
[licheng@Soft04 ~]$
[Bug target/52908] xop-mul-1:f9 miscompiled on bulldozer (-mxop)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52908
--- Comment #2 from Uros Bizjak 2012-04-09 11:48:05
UTC ---
Created attachment 27117
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27117
Proposed patch
There are indeed two problems with XOP patterns:
a) duplication of *sse4_1_mulv2siv2di3 pattern
b) wrong order of operands in all (!!!) XOP patterns. XOP patterns consider
element 0 as MSB.
Attached patch solves this by simply removing fake xop_mulv2div2di3_{low,high}
patterns, expanding to (fixed) xop_pmacsdq{h,l} patterns directly. There is
simply no need to use vpmacsdql instead of vpmuldq. For consistency, the patch
expands to xop_pmacsdql pattern, but gcc figures out that addition of 0 is
unneeded and substitutes MAC insn with plain MUL.
Attached patch does not even try to fix other intrinsics. Someone familiar with
AMD documentation should review all these, since the documentation (43479.pdf)
is somehow inconsistent (i.e. the figure that explains VPMADCSSWD is
inconsistent with the description).
Since I don't have XOP processor, I can only eyeball the asm, in this case:
vpxor %xmm3, %xmm3, %xmm3
xorl%eax, %eax
.L3:
vpshufd $216, c2(%rax), %xmm1
vpshufd $216, c3(%rax), %xmm0
vpmuldq %xmm0, %xmm1, %xmm2
vpmacsdqh %xmm3, %xmm0, %xmm1, %xmm0
vmovdqa %xmm2, e1(%rax,%rax)
vmovdqa %xmm0, e1+16(%rax,%rax)
addq$16, %rax
cmpq$2048, %rax
jne .L3
Please also note hoisting of constant load.
[Bug c/52911] New: gcc 4.7.0 (ppc32 e500mc) when compile a c file, after a lot of time, gcc failed and internal compiler error occurs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52911
Bug #: 52911
Summary: gcc 4.7.0 (ppc32 e500mc) when compile a c file, after
a lot of time, gcc failed and internal compiler error
occurs.
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: zuog...@huawei.com
Created attachment 27118
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27118
the processed file
gcc 4.7.0, on ppc32 target freescale p4080 processor . when compile a c file
with inline asm, internal compiler error occurs.
gcc version and configure options:
[@localhost tomsfastmath-0.12]$ gcc -v
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/powerpc-unknown-linux-gnu/4.7.0/lto-wrapper
Target: powerpc-unknown-linux-gnu
Configured with: /mnt/sda2/backup/gcc-4.7.0/configure --prefix=/usr
--libexecdir=/usr/lib
Thread model: posix
gcc version 4.7.0 (GCC)
how the error can be reproduced:
[@localhost tomsfastmath-0.12]$ time cc -Wall -W -Wshadow -Isrc/headers
-O3 -funroll-loops -fomit-frame-pointer -c -o src/mul/fp_mul_comba_48.o
src/mul/fp_mul_comba_48.c
src/mul/fp_mul_comba_48.c: In function 'fp_mul_comba48':
src/mul/fp_mul_comba_48.c:398:1: error: insn does not satisfy its constraints:
(insn 61208 61207 6542 2 (set (mem/c:DI (plus:SI (reg:SI 16 16)
(const_int 32760 [0x7ff8])) [5 %sfp+98296 S8 A64])
(reg:DI 14 14)) src/mul/fp_mul_comba_48.c:195 340 {*movdi_internal32}
(nil))
src/mul/fp_mul_comba_48.c:398:1: internal compiler error: in
reload_cse_simplify_operands, at postreload.c:403
Please submit a full bug report,
with preprocessed source if appropriate.
See for instructions.
real13m22.735s
user13m22.292s
sys 0m0.424s
[@localhost tomsfastmath-0.12]$
ppc32 cpu info:
[@localhost tomsfastmath-0.12]$ cat /proc/cpuinfo
processor : 0
cpu : e500mc
clock : 1499.985000MHz
revision: 2.0 (pvr 8023 0020)
bogomips: 99.99
processor : 1
cpu : e500mc
clock : 1499.985000MHz
revision: 2.0 (pvr 8023 0020)
bogomips: 99.99
processor : 2
cpu : e500mc
clock : 1499.985000MHz
revision: 2.0 (pvr 8023 0020)
bogomips: 99.99
processor : 3
cpu : e500mc
clock : 1499.985000MHz
revision: 2.0 (pvr 8023 0020)
bogomips: 99.99
processor : 4
cpu : e500mc
clock : 1499.985000MHz
revision: 2.0 (pvr 8023 0020)
bogomips: 99.99
processor : 5
cpu : e500mc
clock : 1499.985000MHz
revision: 2.0 (pvr 8023 0020)
bogomips: 99.99
processor : 6
cpu : e500mc
clock : 1499.985000MHz
revision: 2.0 (pvr 8023 0020)
bogomips: 99.99
processor : 7
cpu : e500mc
clock : 1499.985000MHz
revision: 2.0 (pvr 8023 0020)
bogomips: 99.99
total bogomips : 799.99
timebase: 4500
platform: P4080 DS
model : fsl,P4080DS
Memory : 4096 MB
[Bug fortran/52909] [F03] Procedure pointers not private to modules
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52909
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
AssignedTo|unassigned at gcc dot |janus at gcc dot gnu.org
|gnu.org |
--- Comment #2 from janus at gcc dot gnu.org 2012-04-09 14:40:12 UTC ---
Preliminary patch, which makes the test case work:
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c(revision 186243)
+++ gcc/fortran/trans-decl.c(working copy)
@@ -1536,6 +1536,14 @@ get_proc_pointer_decl (gfc_symbol *sym)
VAR_DECL, get_identifier (sym->name),
build_pointer_type (gfc_get_function_type (sym)));
+ if (sym->module)
+{
+ /* Do name mangling. */
+ gfc_set_decl_assembler_name (decl, gfc_sym_mangled_identifier (sym));
+ if (sym->attr.use_assoc)
+DECL_IGNORED_P (decl) = 1;
+}
+
if ((sym->ns->proc_name
&& sym->ns->proc_name->backend_decl == current_function_decl)
|| sym->attr.contained)
[Bug fortran/52679] [4.6 Regression] ICE in gfortran 4.6.3, x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52679 janus at gcc dot gnu.org changed: What|Removed |Added Severity|blocker |normal
[Bug fortran/52622] ICE in gfortran 4.6.3, x86_64
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52622 janus at gcc dot gnu.org changed: What|Removed |Added Severity|blocker |normal
[Bug c/52912] New: ICE: verify_ssa failed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52912
Bug #: 52912
Summary: ICE: verify_ssa failed
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
[regehr@dyson r14]$ current-gcc -Os small.c
small.c: In function 'fn2':
small.c:12:1: error: AUX pointer initialized for edge 3->4
small.c:12:1: internal compiler error: verify_ssa failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[regehr@dyson r14]$ cat small.c
int a, b, c;
int
fn1 (p1)
{
lbl_549:
if (p1)
goto lbl_549;
return 0;
}
void
fn2 ()
{
b = (c && a) > fn1 (c) >= c;
}
int
main ()
{
return 0;
}
[regehr@dyson r14]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r186233-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r186233-install
--program-prefix=r186233- --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120409 (experimental) (GCC)
[Bug c/52911] gcc 4.7.0 (ppc32 e500mc) when compile a c file, after a lot of time, gcc failed and internal compiler error occurs.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52911 Mikael Pettersson changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #1 from Mikael Pettersson 2012-04-09 15:56:10 UTC --- I can reproduce the ICE with gcc 4.4.7, 4.5.3, 4.6.3, 4.7.0, and 4.8-20120408, built as crosses to ppc-linux hosted on i686-linux. gcc 4.1.2, 4.2.4, and 4.3.6 don't ICE.
[Bug tree-optimization/50439] gfortran infinite loop with -floop-interchange
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50439 --- Comment #10 from William J. Schmidt 2012-04-09 16:03:27 UTC --- FWIW, my original compile did eventually complete (after 31.5 hours)...
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #27 from dodji at seketeli dot org 2012-04-09 16:04:46 UTC --- "manu at gcc dot gnu.org" a écrit: > Dodji, are you planning to propose to enable -ftrack-macro-expansion > by default in GCC 4.8? Wow, what a timing! I am working on a patch-set to enable -ftrack-macro-expansion by default for GCC 4.8. It appeared that quite some fixes were still needed for that ;-) It seems to pass bootstrap for C/C++ at the moment, so I think I'll start polishing & flushing it out to gcc-patches shortly. For the curious, my current tree is browsable at http://seketeli.net/git/~dodji/gcc.git/log/?h=track-locs-by-default To get the code, do: git clone git://seketeli.net/~dodji/gcc gcc.git cd gcc.git git checkout track-locs-by-default
[Bug c/52913] New: segfault due to null ptr deref
pilation(tree_node*)
(tree-optimize.c:422)
==10207==by 0x616239: cgraph_expand_function(cgraph_node*)
(cgraphunit.c:1784)
==10207==by 0x6180FB: cgraph_optimize() (cgraphunit.c:1851)
==10207== Address 0x50 is not stack'd, malloc'd or (recently) free'd
==10207==
small.c: In function 'fn1':
small.c:16:1: 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.
[regehr@dyson r12]$ cat small.c
int a, b, c, d, e;
void
fn1 ()
{
lbl_101:
e = 0;
lbl_274:
for (c = 0; c < 1; c = a)
if (d)
if (b)
goto lbl_101;
else
break;
d = 1;
goto lbl_274;
}
[regehr@dyson r12]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r186233-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r186233-install
--program-prefix=r186233- --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120409 (experimental) (GCC)
[Bug c/52914] New: ICE in simplify_const_unary_operation, at simplify-rtx.c:1464
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52914
Bug #: 52914
Summary: ICE in simplify_const_unary_operation, at
simplify-rtx.c:1464
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: reg...@cs.utah.edu
CC: cheny...@cs.utah.edu
[regehr@dyson r13]$ current-gcc -O1 -c small.c
small.c: In function 'fn3':
small.c:16:1: internal compiler error: in simplify_const_unary_operation, at
simplify-rtx.c:1464
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.
[regehr@dyson r13]$ cat small.c
int a, b, c, f, g, h, i;
unsigned d;
int e[0];
int
fn1 ()
{
return 0;
}
static char fn2 ();
void
fn3 ()
{
for (; c; c += 1)
fn2 ();
}
char
fn2 ()
{
int j = -3L;
d = 0;
for (;; d = 1)
{
if (e[d])
g = fn1 ();
i = (b ^ 1) < 0 ? b : h;
i || (a = 1) ? 0 : 0;
if (0 >= f <= j)
;
else
return 0;
}
}
[regehr@dyson r13]$ current-gcc -v
Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r186233-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.8.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r186233-install
--program-prefix=r186233- --enable-languages=c,c++
Thread model: posix
gcc version 4.8.0 20120409 (experimental) (GCC)
[Bug c++/24985] caret diagnostics
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24985 --- Comment #28 from dodji at seketeli dot org 2012-04-09 16:19:15 UTC --- "manu at gcc dot gnu.org" a écrit: > Of course, it needs some fine-tuning to avoid repetitions, but this is > a problem with the locations given by the macro expansion unwinder, > which, in my opinion, doesn't give the best location for each message > and already produces repetitions. See: > > /home/manuel/macro-caret.c: In function ‘g’: > /home/manuel/macro-caret.c:5:14: error: invalid operands to binary << (have > ‘double’ and ‘int’) >OPERATE (A,<<,B) > ^ > /home/manuel/macro-caret.c:2:9: note: in expansion of macro 'OPERATE' >OPRD1 OPRT OPRD2; > ^ > /home/manuel/macro-caret.c:5:3: note: expanded from here >OPERATE (A,<<,B) >^ > /home/manuel/macro-caret.c:5:14: note: in expansion of macro 'SHIFTL' >OPERATE (A,<<,B) > ^ > /home/manuel/macro-caret.c:8:3: note: expanded from here >SHIFTL (A,1) >^ > /home/manuel/macro-caret.c:8:3: note: in expansion of macro 'MULT' >SHIFTL (A,1) >^ > /home/manuel/macro-caret.c:13:3: note: expanded from here >MULT (1.0);// 1.0 << 1; <-- so this is an error. >^ Could you please file a specific bug for this and CC me? I'd be interested to give this a look. Thanks.
[Bug c/52913] segfault due to null ptr deref
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52913 John Regehr changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from John Regehr 2012-04-09 16:18:46 UTC --- Gah, sorry, thought this was different but didn't look carefully enough. *** This bug has been marked as a duplicate of bug 52881 ***
[Bug middle-end/52881] [4.8 Regression] ICE due to null pointer deref in cfgloop.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52881 --- Comment #1 from John Regehr 2012-04-09 16:18:46 UTC --- *** Bug 52913 has been marked as a duplicate of this bug. ***
[Bug c++/52915] New: [C++11] Deleted default-constructor of anonymous unions not honored
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52915
Bug #: 52915
Summary: [C++11] Deleted default-constructor of anonymous
unions not honored
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: daniel.krueg...@googlemail.com
gcc 4.8.0 20120318 (experimental) in C++11 mode accepts the following code:
//---
struct S {
int val;
S(int v) : val(v) {}
};
void f() {
union { S a; };
}
//---
This seems to violate to what the standard says. According to 9.5 p5:
"A union of the form
union { member-specification } ;
is called an anonymous union; it defines an unnamed object of unnamed type."
combined with 12.1 p5 b6:
"A defaulted default constructor for class X is defined as deleted if:
[..]
— any [..] non-static data member with no brace-or-equal-initializer, has class
type M [..] and [..] M has no default constructor [..]"
The last item has the effect that the anonymous union defined in f() is a
union-like class that has a deleted default constructor, but the definition in
f() also defines an unnamed object of that type which is default-initialized.
It seems that gcc does not respect the last part of the semantics of this
declaration.
[Bug rtl-optimization/48496] [4.7/4.8 Regression] 'asm' operand requires impossible reload
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48496 --- Comment #20 from Leif Leonhardy 2012-04-09 16:42:38 UTC --- (In reply to comment #16) > It is time to do something as GCC 4.7 is quite hampered by this on IA-64. Indeed. Besides MPIR (hence presumably also GMP) and NTL, also MPFR, GMP-ECM, PARI, FLINT and some other less prominent packages fail to build due to this error (unless one specifies `-O0 ...`).
[Bug fortran/52916] New: [4.8 Regression] 481.wrf in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52916 Bug #: 52916 Summary: [4.8 Regression] 481.wrf in SPEC CPU 2006 failed to build Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: hjl.to...@gmail.com CC: areg.melikadam...@gmail.com On Linux/x86-64, revision 186226 gave gfortran -O2 -ffast-math -DSPEC_CPU_LINUX -DSPEC_CPU_CASE_FLAG -DSPEC_CPU_LOGICAL_STRICT -frecord-marker=4 wrf_num_bytes_between.o pack_utils.o module_driver_constants.fppized.o module_domain.fppized.o module_integrate.fppized.o module_timing.fppized.o module_configure.fppized.o module_tiles.fppized.o module_machine.fppized.o module_nesting.fppized.o module_wrf_error.fppized.o module_state_description.fppized.o module_sm.fppized.o module_io.fppized.o module_dm_stubs.fppized.o module_quilt_outbuf_ops.fppized.o module_io_quilt.fppized.o module_bc.fppized.o module_io_wrf.fppized.o module_date_time.fppized.o module_io_domain.fppized.o module_bc_time_utilities.fppized.o module_model_constants.fppized.o module_soil_pre.fppized.o module_bl_mrf.fppized.o module_sf_myjsfc.fppized.o module_bl_myjpbl.fppized.o module_bl_ysu.fppized.o module_cu_bmj.fppized.o module_mp_kessler.fppized.o module_mp_ncloud5.fppized.o module_ra_sw.fppized.o module_sf_sfclay.fppized.o module_cu_kf.fppized.o module_cu_kfeta.fppized.o module_mp_lin.fppized.o module_mp_wsm3.fppized.o module_mp_wsm5.fppized.o module_mp_wsm6.fppized.o module_surface_driver.fppized.o module_cu_gd.fppized.o module_sf_sfcdiags.fppized.o module_ra_gsfcsw.fppized.o module_sf_slab.fppized.o module_sf_noahlsm.fppized.o module_sf_ruclsm.fppized.o module_mp_ncloud3.fppized.o module_mp_etanew.fppized.o module_ra_rrtm.fppized.o module_ra_gfdleta.fppized.o module_physics_init.fppized.o module_physics_addtendc.fppized.o module_solvedebug_em.fppized.o module_bc_em.fppized.o module_advect_em.fppized.o module_diffusion_em.fppized.o module_small_step_em.fppized.o module_big_step_utilities_em.fppized.o module_em.fppized.o module_init_utilities.fppized.o module_optional_si_input.fppized.o ESMF_Alarm.fppized.o ESMF_Base.fppized.o ESMF_BaseTime.fppized.o ESMF_Calendar.fppized.o ESMF_Clock.fppized.o ESMF_Fraction.fppized.o ESMF_Mod.fppized.o ESMF_Time.fppized.o ESMF_TimeInterval.fppized.o Meat.fppized.o wrf_shutdown.fppized.o collect_on_comm.o mediation_integrate.fppized.o mediation_feedback_domain.fppized.o mediation_force_domain.fppized.o mediation_interp_domain.fppized.o mediation_wrfmain.fppized.o wrf_auxhist1in.fppized.o wrf_auxhist1out.fppized.o wrf_auxhist2in.fppized.o wrf_auxhist2out.fppized.o wrf_auxhist3in.fppized.o wrf_auxhist3out.fppized.o wrf_auxhist4in.fppized.o wrf_auxhist4out.fppized.o wrf_auxhist5in.fppized.o wrf_auxhist5out.fppized.o wrf_auxinput1in.fppized.o wrf_auxinput1out.fppized.o wrf_auxinput2in.fppized.o wrf_auxinput2out.fppized.o wrf_auxinput3in.fppized.o wrf_auxinput3out.fppized.o wrf_auxinput4in.fppized.o wrf_auxinput4out.fppized.o wrf_auxinput5in.fppized.o wrf_auxinput5out.fppized.o wrf_bdyin.fppized.o wrf_bdyout.fppized.o wrf_histin.fppized.o wrf_histout.fppized.o wrf_inputin.fppized.o wrf_inputout.fppized.o wrf_restartin.fppized.o wrf_restartout.fppized.o couple_or_uncouple_em.fppized.o interp_domain_em.fppized.o interp_fcn.fppized.o nest_init_utils.fppized.o set_timekeeping.fppized.o sint.fppized.o solve_interface.fppized.o start_domain.fppized.o module_pbl_driver.fppized.o module_radiation_driver.fppized.o module_cumulus_driver.fppized.o module_microphysics_driver.fppized.o solve_em.fppized.o start_em.fppized.o internal_header_util.fppized.o io_int.fppized.o init_modules_em.fppized.o init_modules.fppized.o wrf_io.o field_routines.o wrf.fppized.o netcdf/attr.o netcdf/dim.o netcdf/error.o netcdf/fort-attio.o netcdf/fort-control.o netcdf/fort-dim.o netcdf/fort-genatt.o netcdf/fort-geninq.o netcdf/fort-genvar.o netcdf/fort-lib.o netcdf/fort-misc.o netcdf/fort-v2compat.o netcdf/fort-var1io.o netcdf/fort-varaio.o netcdf/fort-vario.o netcdf/fort-varmio.o netcdf/fort-varsio.o netcdf/libvers.o netcdf/nc.o netcdf/ncx.o netcdf/posixio.o netcdf/putget.o netcdf/string.o netcdf/v1hpg.o netcdf/v2i.o netcdf/var.o netcdf/typeSizes.o netcdf/netcdf.o -o wrf module_integrate.fppized.o: In function `__module_integrate_MOD_integrate': module_integrate.fppized.f90:(.text+0x83): undefined reference to `__esmf_timemod_MOD_esmf_timelt' module_integrate.fppized.f90:(.text+0x2c4): undefined reference to `__esmf_timemod_MOD_esmf_timedec' module_nesting.fppized.o: In function `__module_nesting_MOD_nests_to_open': module_nesting.fppized.f90:(.text+0x3eb): undefined reference to `__esmf_timemod_MOD_esmf_timele' module_nesting.fppized.f90:(.text+0x40e): undefined reference to `__esmf_timemod_MOD_esmf_timegt' module_io_wrf.fpp
[Bug target/52607] v4df __builtin_shuffle with {0,2,1,3} or {1,3,0,2}
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52607
--- Comment #27 from Marc Glisse 2012-04-09
16:50:47 UTC ---
Notes to self (or other):
- Intel's SDE makes it possible to test without appropriate hardware;
- for V4DF shuffles, there seems to be a very simple generic solution that
performs two vperm2f128 and then one vshufpd.
permutation (a,b,c,d), input (x,y):
t1 = vperm2f128(x,y,(a/2)+16*(c/2));
t2 = vperm2f128(x,y,(b/2)+16*(d/2));
return vshufpd(t1,t2,(a%2)+2*(b%2)+4*(c%2)+8*(d%2));
(when t1 or t2 is equal to x or y, it generates only 2 insn in cases that the
current code doesn't detect, like {3,1,2,2})
[Bug lto/52722] ICE in lto_output_varpool_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52722 --- Comment #4 from Jan Hubicka 2012-04-09 18:57:49 UTC --- This seems to be another manifestation of the alias partitioning issues. I am testing a fix. Honza
[Bug target/52883] ICE in simplify_const_unary_operation, at simplify-rtx.c:1464
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52883 --- Comment #12 from Uros Bizjak 2012-04-09 18:59:50 UTC --- *** Bug 52914 has been marked as a duplicate of this bug. ***
[Bug c/52914] ICE in simplify_const_unary_operation, at simplify-rtx.c:1464
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52914 Uros Bizjak changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #1 from Uros Bizjak 2012-04-09 18:59:50 UTC --- Dup of PR 52883. *** This bug has been marked as a duplicate of bug 52883 ***
[Bug fortran/52916] [4.8 Regression] 481.wrf in SPEC CPU 2006 failed to build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52916 Thomas Koenig changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2012-04-09 CC||tkoenig at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Thomas Koenig 2012-04-09 19:09:51 UTC --- Reduced test case?
[Bug libstdc++/52476] [DR 518] Unordered multimap reorders equivalent elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52476 --- Comment #6 from François Dumont 2012-04-09 19:12:23 UTC --- Author: fdumont Date: Mon Apr 9 19:12:18 2012 New Revision: 186249 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186249 Log: 2012-04-09 François Dumont PR libstdc++/52476 * include/bits/hashtable.h (_Hashtable<>::_M_rehash_aux): Add. (_Hashtable<>::_M_rehash): Use the latter. * testsuite/23_containers/unordered_multimap/insert/52476.cc: New. * testsuite/23_containers/unordered_multiset/insert/52476.cc: New. Added: branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/unordered_multimap/insert/52476.cc branches/gcc-4_7-branch/libstdc++-v3/testsuite/23_containers/unordered_multiset/insert/52476.cc Modified: branches/gcc-4_7-branch/libstdc++-v3/ChangeLog branches/gcc-4_7-branch/libstdc++-v3/include/bits/hashtable.h
[Bug java/49258] -ffunction-sections and --gc-sectinons have no effect at gcj
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49258
--- Comment #7 from Andrew Pinski 2012-04-09
19:40:41 UTC ---
(In reply to comment #6)
> and i test a c++ file,it will remove the unused funcitons "notused":
But that is not the same as there is no vtable for hello.
Try:
#include
class hello
{
public:
hello()
{
}
virtual void notused()
{
std::cout << "not used";
}
virtual void used()
{
std::cout << "used";
}
virtual ~hello()
{
}
}hi;
int main()
{ hello t;
t.used();
return 0;
}
And see the result.
[Bug libstdc++/52917] New: explicitly stated return type in std::mem_fn cannot be compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52917
Bug #: 52917
Summary: explicitly stated return type in std::mem_fn cannot be
compiled
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: freunddeslic...@web.de
#include
struct X {
int a;
int& easy() {return a;}
int& get() {return a;}
const int& get() const {return a;}
};
int main(void)
{
auto x = std::mem_fn (&X::easy); // (1) works
auto y = std::mem_fn (&X::get ); // (2) ERROR!!
auto z = std::mem_fun(&X::get ); // (3) deprecated in c++11, but works:
return 0;
}
(2) needs the return type to diffrentiate between the const and the non-const
getter.
The specification for mem_fn is
template< class R, class T >/*unspecified*/ mem_fn(R T::* pm);
template< class R, class T, class... Args > /*unspecified*/ mem_fn(R (T::*
pm)(Args...));
[ ... some more overloads for const, volatile and references]
(2) should result in an instantiation of the second version with
sizeof...(Args)==0, because argument to the first version is a "pointer to
member data", not "pointer to member function".
Both g++-4.7 and clang++-3.1 (when compiling with libstdc++) try to instantiate
the first version by mistake.
This definitely a library error, because clang when compiling with libc++
correctly instantiates the second version of mem_fn.
##
g++-4.7 -std=c++0x bug.cpp
bug.cpp: In function ‘int main()’:
bug.cpp:17:39: error: no matching function for call to ‘mem_fn()’
bug.cpp:17:39: note: candidate is:
In file included from bug.cpp:3:0:
/usr/include/c++/4.7/functional:821:5: note: template
std::_Mem_fn<_Tp _Class::*> std::mem_fn(_Tp _Class::*)
/usr/include/c++/4.7/functional:821:5: note: template argument
deduction/substitution failed:
/usr/include/c++/4.7/functional: In substitution of ‘template std::_Mem_fn<_Tp _Class::*> std::mem_fn(_Tp _Class::*) [with _Tp =
int&; _Class = ]’:
bug.cpp:17:39: required from here
/usr/include/c++/4.7/functional:821:5: error: creating pointer to member
reference type ‘int&’
bug.cpp:17:39: error: unable to deduce ‘auto’ from ‘’
clang++ -std=c++0x bug.cpp
bug.cpp:17:12: error: no matching function for call to 'mem_fn'
auto y = std::mem_fn (&X::get ); // (2) ERROR!!
^~
/usr/lib/gcc/i686-linux-gnu/4.7/../../../../include/c++/4.7/functional:820:5:
note: candidate template ignored: substitution failure [with _Tp = int &]
mem_fn(_Tp _Class::* __pm)
^
1 error generated.
[Bug c++/52918] New: ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52918 Bug #: 52918 Summary: ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: bsco...@ieee.org SVN revision 186249, while compiling gcc for MinGW-w64 (Win64) in the x86_64-w64-mingw32/libstdc++-v3/libsupc++ runtime, encouters this ICE backtrace: (gdb) bt #0 add_bb_to_loop (bb=0x84018b8, loop=0x0) at ../../../gcc/gcc/cfgloop.c:1652 #1 0x0098dcea in split_block (bb=0x8401870, i=0x840b270) at ../../../gcc/gcc/cfghooks.c:450 #2 0x00a03dcf in find_bb_boundaries (bb=0x8401870) at ../../../gcc/gcc/cfgbuild.c:474 #3 find_many_sub_basic_blocks (blocks=0x82339a0) at ../../../gcc/gcc/cfgbuild.c:594 #4 0x008399a1 in break_superblocks () at ../../../gcc/gcc/cfglayout.c:1345 #5 0x00712779 in finish_eh_generation () at ../../../gcc/gcc/except.c:1431 #6 0x00cd5d95 in gimple_expand_cfg () at ../../../gcc/gcc/cfgexpand.c:4652 #7 0x00864243 in execute_one_pass (pass=0x102c3c0) at ../../../gcc/gcc/passes.c:2079 #8 0x008645a5 in execute_pass_list (pass=0x102c3c0) at ../../../gcc/gcc/passes.c:2134 #9 0x009e54f6 in tree_rest_of_compilation (fndecl=0x8203d00) at ../../../gcc/gcc/tree-optimize.c:422 #10 0x00869364 in cgraph_expand_function (node=0x833ef18) at ../../../gcc/gcc/cgraphunit.c:1784 #11 0x0086afe7 in cgraph_expand_all_functions () at ../../../gcc/gcc/cgraphunit.c:1851 #12 cgraph_optimize () at ../../../gcc/gcc/cgraphunit.c:2542 #13 0x0086b88c in cgraph_finalize_compilation_unit () at ../../../gcc/gcc/cgraphunit.c:2628 #14 0x004faa17 in cp_write_global_declarations () at ../../../gcc/gcc/cp/decl2.c:4077 #15 0x0087395a in compile_file () at ../../../gcc/gcc/toplev.c:572 #16 do_compile () at ../../../gcc/gcc/toplev.c:1936 #17 toplev_main (argc=49, argv=0x2f4c40) at ../../../gcc/gcc/toplev.c:2012 #18 0x010037e8 in main (argc=49, argv=0x2f4c40) at ../../../gcc/gcc/main.c:36 Compiler diagnostic output: ../../../../../gcc/libstdc++-v3/libsupc++/eh_alloc.cc: In function 'void* __cxxabiv1::__cxa_allocate_exception(std::size_t)': ../../../../../gcc/libstdc++-v3/libsupc++/eh_alloc.cc:138:1: internal compiler error: Segmentation fault Compiler command line: /c/scottm/mingw64-build/gcc/./gcc/xgcc -v -shared-libgcc -B/c/scottm/mingw64-build/gcc/./gcc -nostdinc++ -L/c/scottm/mingw64-build/gcc/x86_64-w64-mingw32/libstdc++-v3/src -L/c/scottm/mingw64-build/gcc/x86_64-w64-mingw32/libstdc++-v3/src/.libs -L/c/mingw64-devel/x86_64-w64-mingw32/lib -L/c/mingw64-devel/mingw/lib -isystem /c/mingw64-devel/x86_64-w64-mingw32/include -isystem /c/mingw64-devel/mingw/include -B/c/mingw64-devel/x86_64-w64-mingw32/bin/ -B/c/mingw64-devel/x86_64-w64-mingw32/lib/ -isystem /c/mingw64-devel/x86_64-w64-mingw32/include -isystem /c/mingw64-devel/x86_64-w64-mingw32/sys-include -I/c/scottm/gcc/libstdc++-v3/../libgcc -I/c/scottm/mingw64-build/gcc/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32 -I/c/scottm/mingw64-build/gcc/x86_64-w64-mingw32/libstdc++-v3/include -I/c/scottm/gcc/libstdc++-v3/libsupc++ -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=eh_alloc.lo -g -O2 -c ../../../../../gcc/libstdc++-v3/libsupc++/eh_alloc.cc -o eh_alloc.o Verbose xgcc output: Reading specs from c:/scottm/mingw64-build/gcc/gcc/specs COLLECT_GCC=c:\scottm\mingw64-build\gcc\gcc\xgcc.exe Target: x86_64-w64-mingw32 Configured with: ../../gcc/configure --target=x86_64-w64-mingw32 --enable-targets=all --with-sysroot=/c/mingw64-devel --prefix=/c/mi ngw64-devel Thread model: win32 gcc version 4.8.0 20120409 (experimental) (GCC) COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-B' 'c:/scottm/mingw64-build/gcc/gcc' '-nostdinc++' '-Lc:/scottm/mingw64-build/gcc/x86_64 -w64-mingw32/libstdc++-v3/src' '-Lc:/scottm/mingw64-build/gcc/x86_64-w64-mingw32/libstdc++-v3/src/.libs' '-Lc:/mingw64-devel/x86_64- w64-mingw32/lib' '-Lc:/mingw64-devel/mingw/lib' '-isystem' 'c:/mingw64-devel/x86_64-w64-mingw32/include' '-isystem' 'c:/mingw64-deve l/mingw/include' '-B' 'c:/mingw64-devel/x86_64-w64-mingw32/bin/' '-B' 'c:/mingw64-devel/x86_64-w64-mingw32/lib/' '-isystem' 'c:/ming w64-devel/x86_64-w64-mingw32/include' '-isystem' 'c:/mingw64-devel/x86_64-w64-mingw32/sys-include' '-I' 'c:/scottm/gcc/libstdc++-v3/ ../libgcc' '-I' 'c:/scottm/mingw64-build/gcc/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32' '-I' 'c:/scottm/mingw64-bui ld/gcc/x86_64-w64-mingw32/libstdc++-v3/include' '-I' 'c
[Bug c++/52918] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52918 B. Scott Michel changed: What|Removed |Added Severity|normal |blocker
[Bug c++/52918] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52918 --- Comment #1 from B. Scott Michel 2012-04-09 20:31:53 UTC --- Patch to check bb->loop_father is relatively obvious, but not clear that the patch would do the right thing.
[Bug libstdc++/52476] [DR 518] Unordered multimap reorders equivalent elements
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52476 Jonathan Wakely changed: What|Removed |Added Target Milestone|--- |4.7.1
[Bug libstdc++/52917] [DR 2048] explicitly stated return type in std::mem_fn cannot be compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52917
Jonathan Wakely changed:
What|Removed |Added
Status|UNCONFIRMED |SUSPENDED
Last reconfirmed||2012-04-09
Summary|explicitly stated return|[DR 2048] explicitly stated
|type in std::mem_fn cannot |return type in std::mem_fn
|be compiled |cannot be compiled
Ever Confirmed|0 |1
--- Comment #1 from Jonathan Wakely 2012-04-09
21:18:11 UTC ---
(In reply to comment #0)
> (2) needs the return type to diffrentiate between the const and the non-const
> getter.
Or you can do
auto y = std::mem_fn((int& (X::*)())&X::get );
Which also works in this case where specifying the return type doesn't help:
struct X {
int get() { return 0; }
int get() const { return 1; }
};
> The specification for mem_fn is
>
> template< class R, class T >/*unspecified*/ mem_fn(R T::* pm);
> template< class R, class T, class... Args > /*unspecified*/ mem_fn(R (T::*
> pm)(Args...));
> [ ... some more overloads for const, volatile and references]
Maybe not for long: http://cplusplus.github.com/LWG/lwg-active.html#2048
The libstdc++ implementation exactly matches that issue's proposed resolution,
which has been voted Tentatively Ready.
> (2) should result in an instantiation of the second version with
> sizeof...(Args)==0, because argument to the first version is a "pointer to
> member data", not "pointer to member function".
No, it's a pointer to member, which can match either a pointer to member data
or pointer to member function.
If the second overload exists (as it presumably does in libc++) then it's a
better match than the first overload, but the first overload is still viable.
> Both g++-4.7 and clang++-3.1 (when compiling with libstdc++) try to
> instantiate
> the first version by mistake.
Not by mistake, by design, that overload can match any pointer to member.
I'm suspending this because I believe the resolution to DR 2048 would make
libstdc++ correct.
[Bug libstdc++/52917] [DR 2048] explicitly stated return type in std::mem_fn cannot be compiled
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52917 --- Comment #2 from Jonathan Wakely 2012-04-09 21:35:07 UTC --- (In reply to comment #1) > Or you can do > > auto y = std::mem_fn((int& (X::*)())&X::get ); Or auto y = std::mem_fn (&X::get ); Which should also work with either libstdc++ or libc++
[Bug middle-end/52919] New: shift expansion mishandles SHIFT_COUNT_TRUNCATED on partial integer modes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52919 Bug #: 52919 Summary: shift expansion mishandles SHIFT_COUNT_TRUNCATED on partial integer modes Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: middle-end AssignedTo: unassig...@gcc.gnu.org ReportedBy: big...@acm.org The code for SHIFT_COUNT_TRUNCATED in expmed.c:expand_shift_1 improperly uses GET_MODE_BITSIZE instead of GET_MODE_PRECISION when calculating the truncation value. This can result in failure to identify an acceptable shift operation; e.g. with a PSImode with 20 bits of precision, a shift of 20 may be requested.
[Bug middle-end/52919] shift expansion mishandles SHIFT_COUNT_TRUNCATED on partial integer modes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52919 --- Comment #1 from Peter A. Bigot 2012-04-09 22:30:20 UTC --- Created attachment 27119 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27119 Replace GET_MODE_BITSIZE with GET_MODE_PRECISION where necessary
[Bug middle-end/52856] misuse of MODE_SIZE vice MODE_PRECISION in get_mode_bounds
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52856 --- Comment #1 from Peter A. Bigot 2012-04-09 22:31:59 UTC --- Created attachment 27120 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27120 Replace GET_MODE_BITSIZE with GET_MODE_PRECISION where necessary
[Bug lto/51765] Testsuite ICEs with -flto
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51765 --- Comment #4 from Jan Hubicka 2012-04-09 23:39:16 UTC --- Author: hubicka Date: Mon Apr 9 23:39:11 2012 New Revision: 186252 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186252 Log: PR lto/52722 PR lto/51765 PR lto/52634 * lto-cgraph.c (compute_ltrans_boundary): When alias is in the boundary, add its target too. * lto.c (add_references_to_partition): Add also aliased nodes. (add_cgraph_node_to_partition, add_varpool_node_to_partition): Work on nodes, not functions/variables; when adding alias, add also the aliased object. * gcc.dg/lto/pr52634_1.c: New testcase. * gcc.dg/lto/pr52634_0.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/lto/pr52634_0.c trunk/gcc/testsuite/gcc.dg/lto/pr52634_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/lto-cgraph.c trunk/gcc/lto/lto.c trunk/gcc/testsuite/ChangeLog
[Bug lto/52634] multiple definition error when using alias
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52634 --- Comment #8 from Jan Hubicka 2012-04-09 23:39:15 UTC --- Author: hubicka Date: Mon Apr 9 23:39:11 2012 New Revision: 186252 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186252 Log: PR lto/52722 PR lto/51765 PR lto/52634 * lto-cgraph.c (compute_ltrans_boundary): When alias is in the boundary, add its target too. * lto.c (add_references_to_partition): Add also aliased nodes. (add_cgraph_node_to_partition, add_varpool_node_to_partition): Work on nodes, not functions/variables; when adding alias, add also the aliased object. * gcc.dg/lto/pr52634_1.c: New testcase. * gcc.dg/lto/pr52634_0.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/lto/pr52634_0.c trunk/gcc/testsuite/gcc.dg/lto/pr52634_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/lto-cgraph.c trunk/gcc/lto/lto.c trunk/gcc/testsuite/ChangeLog
[Bug lto/52722] ICE in lto_output_varpool_node
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52722 --- Comment #5 from Jan Hubicka 2012-04-09 23:39:15 UTC --- Author: hubicka Date: Mon Apr 9 23:39:11 2012 New Revision: 186252 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186252 Log: PR lto/52722 PR lto/51765 PR lto/52634 * lto-cgraph.c (compute_ltrans_boundary): When alias is in the boundary, add its target too. * lto.c (add_references_to_partition): Add also aliased nodes. (add_cgraph_node_to_partition, add_varpool_node_to_partition): Work on nodes, not functions/variables; when adding alias, add also the aliased object. * gcc.dg/lto/pr52634_1.c: New testcase. * gcc.dg/lto/pr52634_0.c: New testcase. Added: trunk/gcc/testsuite/gcc.dg/lto/pr52634_0.c trunk/gcc/testsuite/gcc.dg/lto/pr52634_1.c Modified: trunk/gcc/ChangeLog trunk/gcc/lto-cgraph.c trunk/gcc/lto/lto.c trunk/gcc/testsuite/ChangeLog
[Bug tree-optimization/52571] vectorizer changes alignment of common symbols
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52571 m...@gcc.gnu.org changed: What|Removed |Added CC||mrs at gcc dot gnu.org --- Comment #11 from mrs at gcc dot gnu.org 2012-04-09 23:52:54 UTC --- Ah, I had another thought. COMDAT and LINKONCE things I don't think can be realigned for all the same reasons that one cannot align COMMON. I've not thought about this long and hard, so, could be wrong, so, would be good to have a C++ or a vectorizer person review the idea. The idea is, if you compile one translation unit with a vectorizor on, and another with it off, we wind up with two instantiations, each with different alignment, and the one picked at the end need not be either of them, but rather an explicit instantiation. This seems identical to what happens to common to me.
[Bug c/52920] New: function call optimized away with ftree-loop-distribute-patterns
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52920 Bug #: 52920 Summary: function call optimized away with ftree-loop-distribute-patterns Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: garfiel...@gmail.com Created attachment 27121 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27121 Archive of source code (temp.c), assembly (temp.s and temp2.s), preprocessed source (temp.e), and verbose compilation logs (in case they are of use). I've set this to critical, but I certainly acknowledge the possibility that the fault lies somewhere on my end (so I apologize in advance if this isn't an issue when you try to reproduce it). I searched for this issue to see if someone else had already seen similar, but didn't find it, and, if it is a real issue, it seems like it could be important to pass on. I've attached a simple (16 line) test example with a loop containing a printf (the one that prints "Hi\n") that is optimized away in the presence of the -ftree-loop-distribute-patterns flag in GCC 4.7.0 (I've tried this on Linux, specifically CentOS 5.6 x86_64 and Ubuntu 10.10 x86). I compiled the attached code using the following: gcc -O1 -ftree-loop-distribute-patterns temp.c What I see when executable is run: 0 What I believe I should see when executable is run: Hi Hi Hi 0 If the upper bound on the loop is changed to 1 (and 2 on the 32-bit Ubuntu system), this code will work as expected, but as 3 or more (at least for the few examples I tried), the printf is optimized away. Looking at the attached assembly (generated from the 64-bit CentOS system) for when the loop bound is 1 and when it is 2, you can see the printf call and even the string are not present. However, the zeros are written correctly (as evidenced by the last printf and confirmed in the assembly). I originally noticed this when calling a custom malloc function, so I don't believe the behavior to be specific to printf/IO functions. This problem also occurred for me with -O3 and I was able to whittle it down to the -O1 -ftree-loop-distribute-patterns, but I couldn't do the same for -O1 (namely, without -O1, even when including all flags enabled in gcc -Q --help=optimizers, the problem doesn't show up). Also, the previous compiler I had was GCC 4.5.3, which doesn't have the -ftree-loop-distribute-patterns, and this issue doesn't occur, even when compiling with -O3. I tried removing the "A[i] = 0" or "B[i] = 0" lines...removing either one makes the loop work as expected (no issue). Similarly, removing the "int * test = A" lines (and printing the value using A[0] instead of *test) works fine (no issue). However, just changing the "*test" to "A[0]" doesn't fix the issue. I also attached the pre-processed source as well as the output of compiling with -v in case these are of interest.
[Bug other/52777] [4.8 Regression] ./options.h:3546:0: error: "MASK_SIO" redefined [-Werror]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52777 --- Comment #4 from dave.anglin at bell dot net 2012-04-10 00:51:35 UTC --- On 29-Mar-12, at 2:26 PM, hjl.tools at gmail dot com wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52777 > > --- Comment #2 from H.J. Lu 2012-03-29 > 18:26:06 UTC --- > Created attachment 27037 > --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27037 > A patch > > We don't need SIO and GNU_LD in pa.opt any more. Please > try this. Patch is ok with a ChangeLog entry. Thanks, Dave -- John David Anglindave.ang...@bell.net
[Bug other/52777] [4.8 Regression] ./options.h:3546:0: error: "MASK_SIO" redefined [-Werror]
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52777 --- Comment #5 from hjl at gcc dot gnu.org 2012-04-10 00:56:37 UTC --- Author: hjl Date: Tue Apr 10 00:56:27 2012 New Revision: 186257 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186257 Log: Remove SIO and GNU_LD from config/pa/pa.opt 2012-04-09 H.J. Lu PR other/52777 * config/pa/pa.opt: Remove SIO and GNU_LD. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.opt
[Bug fortran/52921] New: Memory errors when compiled with -fstrict-overflow flag
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52921 Bug #: 52921 Summary: Memory errors when compiled with -fstrict-overflow flag Classification: Unclassified Product: gcc Version: 4.8.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: alipasha.cele...@gmail.com The following test code generates memory errors (valgrind : "Conditional jump or move depends on uninitialised value(s)") when assigning the values to %CMP components without allocating it first, if it is compiled with flag -fstrict-overflow. PROGRAM QUICK_TEST TYPE COMP INTEGER, ALLOCATABLE :: CMP(:) END TYPE COMP TYPE COMP_ARRAY TYPE (COMP), ALLOCATABLE :: ARR(:) END TYPE COMP_ARRAY INTEGER :: I TYPE (COMP_ARRAY), TARGET :: MY_ARR READ *, I ALLOCATE (MY_ARR%ARR(I)) MY_ARR%ARR(I)%CMP = [1, 2] END PROGRAM QUICK_TEST However, if "READ *, I" is replaced with "I = 10", i.e. allocation size and the array index are known at compile time, then no memory errors are generated. Furthermore, this flag is included in -O3 optimization flag, but it is not shown when compiling with -Q --help=optimizers .
[Bug c++/52922] New: failed to build gcc 4.7 on SL6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922 Bug #: 52922 Summary: failed to build gcc 4.7 on SL6.1 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: sc...@smedleyfamily.net I am trying to build gcc 4.7.0 on a Scientific Linux 6.1 system, but keep getting the following compilation error: gcc -c -DHAVE_CONFIG_H -g -O2 -I. -I../../../libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes -pedantic ../../../libiberty/fnmatch.c -o fnmatch.o In file included from ../../../libiberty/floatformat.c:31:0: /usr/include/string.h:548:5: error: unknown type name '__locale_t' /usr/include/string.h:552:18: error: unknown type name '__locale_t' No errors were detected during the configure phase, only during the build phase. ../configure --prefix=/usr/local/gcc-4.7.0 --enable-cloog-backend --enable-lto --enable-languages=c,c++ --enable-locale=generic Also tried without --enable-locale & got same result. Any help would be muchly appreciated. Scott. :)
[Bug c++/52922] failed to build gcc 4.7 on SL6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922 --- Comment #1 from scott at smedleyfamily dot net 2012-04-10 05:41:18 UTC --- Created attachment 27122 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27122 config.log
[Bug c++/52922] failed to build gcc 4.7 on SL6.1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52922
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed||2012-04-10
Ever Confirmed|0 |1
--- Comment #2 from Andrew Pinski 2012-04-10
06:10:28 UTC ---
Can you try the following simple program with your current compiler:
#include "string.h"
#include "stdio.h"
int main(void)
{
printf ("Hello world.\n");
}
--- CUT ---
And compile it with -pedantic ?
