[Bug c/50521] -fstrict-volatile-bitfields is not strict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521 --- Comment #13 from Tomohiro Kashiwada kikairoya at gmail dot com 2011-10-29 06:50:11 UTC --- (In reply to comment #12) Regarding the double load. In a statement like a = b, both a be should be individually accessed even if they refer to the same storage. So bitfield.bits.a = bitfield.bits.c should load the bitfield variable twice, once for reading the rvalue and once for masking the lvalue assignment. See 7.1.7.5 second and third paragraph and the note just after. Is that means a statement a = b; always should be treat as if tmp = b; a = tmp; two individual statements? Regarding STRICT_ALIGNMENT, not strictly needed on ARM i think. Smaller accesses than the base type is acceptable, as long as it's aligned to the matching access size (8/16/32/64 bit) and on ARMv7 unaligned access is allowed, but at a performance penalty. And this change is technically unrelated to strict-volatile-bitfields even if there is overlap. I think STRICT_ALIGNMENT is not only for ARM, but also MIPS, SH and others. I'll create new ticket later about STRICT_ALIGNMENT.
[Bug libgcj/35367] Linux x86 build (with --enable-targets=all, so also building with cross-to-x64 multilib configuration) fails in libjava (prims.cc)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35367
--- Comment #3 from Serge Belyshev belyshev at depni dot sinp.msu.ru
2011-10-29 06:55:58 UTC ---
Created attachment 25657
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25657
taken from debian's config-ml.diff
Similar bug in libffi (misdetection of target when using --enable-targets=all)
produces lots of failures in libgo and libffi testsuite.
Both issues are fixed with the attached hack, which is present in debian's set
of patches.
With this hack current trunk passess bootstrap with --enable-targets=all
--enable-languages=all,obj-c++,go and regtest with
RUNTESTFLAGS=--target_board 'unix{,-m64}' just fine on i686.
[Bug middle-end/50907] [4.7 Regression] EDGE_CROSSING incorrectly set across same section with -freorder-blocks-and-partition -fPIC -fprofile-use
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50907 Serge Belyshev belyshev at depni dot sinp.msu.ru changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-29 CC||rth at gcc dot gnu.org Known to work||4.6.0 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 Known to fail||4.7.0 --- Comment #1 from Serge Belyshev belyshev at depni dot sinp.msu.ru 2011-10-29 08:12:18 UTC --- git bisect points at r176696: http://gcc.gnu.org/viewcvs?view=revisionrevision=176696 2011-07-23 Richard Henderson r...@redhat.com * basic-block.h (EDGE_PRESERVE): New. (EDGE_ALL_FLAGS, EDGE_COMPLEX): Include it. * bb-reorder.c: Include except.h. (fix_up_crossing_landing_pad): New. ...
[Bug c/50521] -fstrict-volatile-bitfields is not strict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521
--- Comment #14 from Henrik Nordström henrik at henriknordstrom dot net
2011-10-29 10:45:53 UTC ---
(In reply to comment #13)
See 7.1.7.5 second and third paragraph and the note just after.
Is that means a statement
a = b;
always should be treat as if
tmp = b;
a = tmp;
two individual statements?
That's my understanding of the text.
Further, given
struct {
volatile int bits:32;
} a;
int result;
my understanding is that the note means that
result = ++a.bits;
should be translated into
int tmp = a.bits;
a.bits = tmp + 1;
result = a.bits;
and a++ into
result = a.bits;
tmp = a.bits;
a.bits = tmp + 1;
suitable expanded for aligned container loads stores on each access to
a.bits, with each access to the a container int handled as a volatile access.
Also, from in the second sentence of the note the load of the container on
write may not be optimized away even if it's entirely masked by the write
operation. I.e.
a.bits = x;
translates into
int tmp = *(int *)(int aligned address of a.bits);
tmp = ~0x;
tmp |= x;
*(int *)(int aligned address of a.bits) = tmp;
which is the same load store memory access sequence as used when a.bits is
not filling the entire container.
int tmp = *(int *)(int aligned address of a.bits);
tmp = ~a_bits_mask;
tmp |= (x shift) ~a_bits_mask;
*(int *)(int aligned address of a.bits) = tmp;
where it's not allowed to optimize away the initial load if the result of that
load is entirely masked away by the bit-field assignment (32 bit ~0x ==
0). Operations on tmp between the load store of the a.bits container may be
optimized freely as tmp itself is not a volatile.
I think STRICT_ALIGNMENT is not only for ARM, but also MIPS, SH and others.
I'll create new ticket later about STRICT_ALIGNMENT.
agreed
none of this is only about ARM I think. But the ARM AAPCS specification is
suitable to use as reference for the implementation as it's very detailed on
how to operate on volatile bit-fields and also alignment requirements on
bit-field accesses in general. Not sure the others are as detailed, and it's
very likely the rules from the ARM specification can be applied there as well.
[Bug tree-optimization/50644] ICE in set_is_used added today
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644 --- Comment #14 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-29 11:31:31 UTC --- Created attachment 25658 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25658 3 files I managed to reduce a test case to 3 LTO files now unpack the tar on x86-64 and gcc47 -O2 -flto arch/x86/kernel/tsc_sync.i arch/x86/kernel/smp.i arch/x86/kernel/smpboot.i
[Bug tree-optimization/50602] ICE in tree_nrv, at tree-nrv.c:155 during large LTO build
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50602 --- Comment #7 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-29 12:12:09 UTC --- Created attachment 25659 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25659 reproducer Managed to minimize now Unpack the tar file and on x86-64 % gcc47 -m32 -O2 -flto arch/x86/kernel/apic/io_apic.i -c % gcc47 -m32 -O2 -flto arch/x86/kernel/apic/io_apic.o In file included from :10:0: /home/ak/lsrc/git/linux-lto-2.6/arch/x86/kernel/apic/io_apic.c: In function 'ioapic_read_entry': /home/ak/lsrc/git/linux-lto-2.6/arch/x86/kernel/apic/io_apic.c:397:35: internal compiler error: in tree_nrv, at tree-nrv.c:155 The strange thing is that it doesn't reproduce if you copy the .i file to another file name?!? And see also the weird :10:0. Some memory corruption?
[Bug target/50910] New: [avr] inefficient division by 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50910
Bug #: 50910
Summary: [avr] inefficient division by 2
Classification: Unclassified
Product: gcc
Version: 4.7.0
Status: UNCONFIRMED
Keywords: missed-optimization
Severity: normal
Priority: P3
Component: target
AssignedTo: g...@gcc.gnu.org
ReportedBy: g...@gcc.gnu.org
CC: eric.wedding...@atmel.com
Target: avr
The following source
char c;
void bar_c (int x)
{
c = x ? x/2 : c+1;
}
reveals two issues
== 1 ==
Compiled with
$ avr-gcc -S -Os
there is a call to libgcc's division routine. RTX costs of division has to be
checked and costs of loading the constant added to the costs of division.
bar_c:
sbiw r24,0
breq .L2
ldi r22,lo8(2)
clr r23
rcall __divmodhi4
rjmp .L3
.L2:
lds r22,c
subi r22,lo8(-(1))
.L3:
sts c,r22
ret
== 1 ==
Compiled with
$ avr-gcc -S -O2
the code is happily jumping around to L7 and then back to L3.
bar_c:
sbiw r24,0
brne .L6
lds r24,c
subi r24,lo8(-(1))
sts c,r24
ret
.L6:
sbrc r25,7
rjmp .L7
.L3:
asr r25
ror r24
sts c,r24
ret
.L7:
adiw r24,1
rjmp .L3
Presumably, the cause is
#define BRANCH_COST 0
in avr.h, and the sequence could be instead:
...
.L6:
sbrc r25,7
adiw r24,1
.L3:
asr r25
ror r24
sts c,r24
ret
[Bug target/50910] [avr] inefficient division by 2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50910 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011-10-29 Target Milestone|--- |4.7.0 Ever Confirmed|0 |1 Known to fail||4.3.3, 4.5.2, 4.6.2, 4.7.0 Severity|normal |minor
[Bug rtl-optimization/50764] [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2243 with -O2 -fsched2-use-superblocks -ftree-tail-merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50764 vries at gcc dot gnu.org changed: What|Removed |Added Component|tree-optimization |rtl-optimization --- Comment #7 from vries at gcc dot gnu.org 2011-10-29 12:28:23 UTC --- Using this patch, the dead label introduced by cfg_layout_finalize is removed: ... Index: gcc/bb-reorder.c === --- gcc/bb-reorder.c (revision 180521) +++ gcc/bb-reorder.c (working copy) @@ -2328,6 +2328,7 @@ rest_of_handle_reorder_blocks (void) if (bb-next_bb != EXIT_BLOCK_PTR) bb-aux = bb-next_bb; cfg_layout_finalize (); + cleanup_cfg (0); /* Add NOTE_INSN_SWITCH_TEXT_SECTIONS notes. */ insert_section_boundary_note (); ... and the assert triggers for -O2 -fsched2-use-superblocks -fno-tree-tail-merge. Changing component to rtl-optimization.
[Bug rtl-optimization/50764] [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2243 with -O2 -fsched2-use-superblocks -ftree-tail-merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50764 --- Comment #8 from vries at gcc dot gnu.org 2011-10-29 12:32:37 UTC --- Using this patch, the dead label introduced by cfg_layout_finalize is removed: To be more precise: Using this patch, the dead label introduced by cfg_layout_finalize is removed before sched2 (in pass_reorder_blocks) rather than after sched2 (in pass_duplicate_computed_gotos).
[Bug tree-optimization/50644] ICE in set_is_used added today
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
Markus Trippelsdorf markus at trippelsdorf dot de changed:
What|Removed |Added
CC||markus at trippelsdorf dot
||de
--- Comment #15 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-10-29 12:58:43 UTC ---
Further reduced:
markus@x4 testcase % cat smpboot.i
struct _ddebug {
const char *modname;
const char *function;
const char *filename;
const char *format;
char enabled;
}
cpumask_t;
extern void check_tsc_sync_source(int cpu);
int native_cpu_up(unsigned int cpu)
{
int err;
static struct _ddebug descriptor = {
, __func__, , , 866, 0};
if (__builtin_expect(!!(descriptor.enabled), 0))
__dynamic_pr_debug(descriptor, , err);
check_tsc_sync_source(cpu);
}
markus@x4 testcase % cat smp.i
struct smp_ops {
void (*smp_prepare_boot_cpu)(void);
void (*smp_prepare_cpus)(unsigned max_cpus);
void (*smp_cpus_done)(unsigned max_cpus);
void (*stop_other_cpus)(int wait);
void (*smp_send_reschedule)(int cpu);
int (*cpu_up)(unsigned cpu);
int (*cpu_disable)(void);
void (*cpu_die)(unsigned int cpu);
void (*play_dead)(void);
void (*send_call_func_ipi)(const struct cpumask *mask);
void (*send_call_func_single_ipi)(int cpu);
};
int native_cpu_up(unsigned int cpunum);
void native_cpu_die(unsigned int cpu);
struct kernel_symbol {
unsigned long value;
};
struct smp_ops smp_ops = {
.cpu_up = native_cpu_up, .cpu_die = native_cpu_die,
};
static const char __kstrtab_smp_ops[] = smp_ops;
static const struct kernel_symbol
__ksymtab_smp_ops __attribute__((__used__)) = {
(unsigned long)smp_ops
};
markus@x4 testcase % cat tsc_sync.i
typedef struct {} atomic_t;
struct _ddebug {
const char *modname;
const char *function;
const char *filename;
const char *format;
char enabled;
};
extern __typeof__(int) cpu_number;
static atomic_t start_count;
void check_tsc_sync_source(int cpu)
{
if (unsynchronized_tsc()) return;
else {
do {
static struct _ddebug descriptor = {
, __func__, , 151, 0 };
if (__builtin_expect(!!(descriptor.enabled), 0))
__dynamic_pr_debug(descriptor, ,
(({
typeof(cpu_number) pfo_ret__;
switch (sizeof(cpu_number)) {
case 4:
asm(mov l %%gs: %P 1,%0 :
=r (pfo_ret__) : m (cpu_number));
}
pfo_ret__;
})), cpu);
} while (0);
}
atomic_set(start_count, 0);
}
markus@x4 testcase % gcc smpboot.i smp.i tsc_sync.i -w -Os -flto
In file included from :0:0:
smpboot.i: In function ‘native_cpu_up’:
smpboot.i:10:5: internal compiler error: Segmentation fault
Please submit a full bug report
[Bug target/47997] gcc on macosx: ld: warning: -fwritable-strings not compatible with literal CF/NSString
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47997 --- Comment #26 from Iain Sandoe iains at gcc dot gnu.org 2011-10-29 12:59:33 UTC --- Author: iains Date: Sat Oct 29 12:59:30 2011 New Revision: 180653 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180653 Log: gcc/objc: PR target/47997 * objc-act.c (objc_build_string_object): Remove redundant second call to fix_string_type (). Add a checking assert that we are, indeed, passed a STRING_CST. Modified: trunk/gcc/objc/ChangeLog trunk/gcc/objc/objc-act.c
[Bug target/47997] gcc on macosx: ld: warning: -fwritable-strings not compatible with literal CF/NSString
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47997 --- Comment #27 from Iain Sandoe iains at gcc dot gnu.org 2011-10-29 13:03:27 UTC --- let's give it a few weeks on trunk - and then back-port to 4.6 if all is OK (since we just missed the 4.6.2 release).
[Bug tree-optimization/50644] ICE in set_is_used added today
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50644
--- Comment #16 from Markus Trippelsdorf markus at trippelsdorf dot de
2011-10-29 13:08:13 UTC ---
Or as one file:
% cat test.i
struct _ddebug {
const char *modname;
const char *function;
const char *filename;
const char *format;
char enabled;
}
cpumask_t;
int native_cpu_up(unsigned int cpu)
{
int err;
static struct _ddebug descriptor = {
, __func__, , , 866, 0
};
if (__builtin_expect(!!(descriptor.enabled), 0))
__dynamic_pr_debug(descriptor, , err);
check_tsc_sync_source(cpu);
}
struct smp_ops {
int (*cpu_up)(unsigned cpu);
void (*cpu_die)(unsigned int cpu);
};
void native_cpu_die(unsigned int cpu);
struct kernel_symbol {
unsigned long value;
};
struct smp_ops smp_ops = {
.cpu_up = native_cpu_up, .cpu_die = native_cpu_die,
};
static const struct kernel_symbol
__ksymtab_smp_ops __attribute__((__used__)) = {
(unsigned long)smp_ops
};
typedef struct {
}
atomic_t;
extern __typeof__(int) cpu_number;
static atomic_t start_count;
void check_tsc_sync_source(int cpu)
{
if (unsynchronized_tsc()) return;
else {
do {
static struct _ddebug descriptor = {
, __func__, , 151, 0
};
if (__builtin_expect(!!(descriptor.enabled), 0))
__dynamic_pr_debug(descriptor, , (( {
typeof(cpu_number) pfo_ret__;
switch (sizeof(cpu_number)) {
case 4:
asm(mov l %%gs: %P 1,%0 :
=r (pfo_ret__) : m (cpu_number));
}
pfo_ret__;
}
)), cpu);
} while (0);
}
atomic_set(start_count, 0);
}
% gcc test.i -w -O2 -flto
In file included from :0:0:
test.i: In function ‘native_cpu_up’:
test.i:9:5: internal compiler error: Segmentation fault
Please submit a full bug report
[Bug middle-end/50708] Infinite loop between rshift_double and lshift_double if count is LONG_MIN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50708 Mikael Pettersson mikpe at it dot uu.se changed: What|Removed |Added CC||mikpe at it dot uu.se --- Comment #3 from Mikael Pettersson mikpe at it dot uu.se 2011-10-29 13:29:20 UTC --- The reduced test case throws 4.6.1 and 4.6-20111021 in a loop on i686-linux, but 4.4/4.5/4.7 don't loop. On m68k-linux both 4.6-20111021 and 4.7-20111022 loop. I haven't been able to reproduce the loop on armv5tel-linux-gnueabi with any of 4.4/4.5/4.6/4.7.
[Bug bootstrap/50903] configure:14607: error: GNU Fortran is not working;
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50903 Cynthia chadjidakis at gmail dot com changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #5 from Cynthia chadjidakis at gmail dot com 2011-10-29 13:32:12 UTC --- Thanks for the answers. And, indeed, running make check for gmp did not work using llvm-gcc system compiler in Lion. Following http://beardedcodewarrior.net/2011/07/25/building-gcc-4-6-1-on-mac-os-x-lion/ (using gcc-4.2 installed previously with Snow Leopard instead of llvm-gcc) makes gmp work. Cheers, Cynthia
[Bug debug/49951] [4.5/4.6/4.7 Regression] Debug stepping behavior regarding g++ Class destructor has changed for the worse starting at gcc 4.5.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49951 --- Comment #5 from asmwarrior asmwarrior at gmail dot com 2011-10-29 14:06:53 UTC --- Hi, all, I think this bug happened about more than one years, I have test in both gcc 4.5 and gcc 4.6.x under Windows. I have both post an issue in GDB maillist and GCC-help maillist. see: http://gcc.gnu.org/ml/gcc-help/2011-10/msg00239.html and http://sourceware.org/ml/gdb/2011-10/msg00209.html The GDB guys thoughts that this is a bug in GCC, and GCC emit wrong debug_line information. When I use GDB under Codeblocks, it will always do some extra jump to variable declaration, and quite unfriendly. asmwarrior ollydbg from codeblocks' forum
[Bug middle-end/50708] Infinite loop between rshift_double and lshift_double if count is LONG_MIN
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50708 --- Comment #4 from Ryan Mansfield rmansfield at qnx dot com 2011-10-29 14:28:57 UTC --- (In reply to comment #3) I haven't been able to reproduce the loop on armv5tel-linux-gnueabi with any of 4.4/4.5/4.6/4.7. arm eabi targets force 64bit HOST_WIDE_INT which is why the reduced testcase didn't fail.
[Bug target/50887] [avr] Support ACCUMULATE_OUTGOING_ARGS
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50887 --- Comment #2 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-10-29 14:36:05 UTC --- Author: gjl Date: Sat Oct 29 14:35:59 2011 New Revision: 180654 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180654 Log: PR target/50887 * config/avr/avr.opt (-maccumulate-args): New option. * config/avr/avr.h (STARTING_FRAME_OFFSET): Redefine to avr_starting_frame_offset. (ACCUMULATE_OUTGOING_ARGS): Define to avr_accumulate_outgoing_args. * config/avr/avr.md (UNSPECV_WRITE_SP_IRQ_ON): Remove. (UNSPECV_WRITE_SP_IRQ_OFF): Remove. (UNSPECV_WRITE_SP): New constant. (*addhi3_sp_R): Rewrite to... (*addhi3_sp): ...this new insn. (movhi_sp_r_irq_off, movhi_sp_r_irq_on): Combine to... (movhi_sp_r): ...this new insn. * config/avr/avr-protos.h (avr_accumulate_outgoing_args): New. (avr_starting_frame_offset): New. * config/avr/avr.c (avr_accumulate_outgoing_args): New function. (avr_starting_frame_offset): New function. (avr_outgoing_args_size): New static function. (avr_initial_elimination_offset): Use it. (avr_simple_epilogue): Use it. (avr_asm_function_end_prologue): Use it. (expand_epilogue): Use it. (expand_prologue): Use it. Break out code to... (avr_prologue_setup_frame): ...this new static function. (avr_can_eliminate): Allow eliminating to frame pointer if there is one. (avr_frame_pointer_required_p): Use frame pointer if target has a nonlocal label. * config/avr/constraints.md (R): Remove. (Csp): New constraint. * config/avr/predicates.md (avr_sp_immediate_operand): Use it. Modified: trunk/gcc/ChangeLog trunk/gcc/config/avr/avr-protos.h trunk/gcc/config/avr/avr.c trunk/gcc/config/avr/avr.h trunk/gcc/config/avr/avr.md trunk/gcc/config/avr/avr.opt trunk/gcc/config/avr/constraints.md trunk/gcc/config/avr/predicates.md
[Bug c/50521] -fstrict-volatile-bitfields is not strict
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50521 --- Comment #15 from Tomohiro Kashiwada kikairoya at gmail dot com 2011-10-29 14:37:15 UTC --- I see. Thanks detail exposition. I think the behavior of my patch seems correct and it should be merged.
[Bug fortran/50556] cannot save namelist group name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50556 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added Keywords||accepts-invalid CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-10-29 14:47:52 UTC --- One might argue that a SAVE namelist-group-name should mean that all namelist-group-objects associate this namelist-group-name gets the SAVE attribute. If this interpretation was correct, then one would expect that text in the Standard would make this clear. Well, I see in the standard: C553 An entity with the SAVE attribute shall be a common block, variable, or procedure pointer. And I would argue that a namelist-group-name is neither a common block, a variable nor a procedure pointer. Thus, I believe that the code in comment 0 is invalid. Regarding the patch in comment 1: I think it will not work if one swaps the order of NAMELIST and SAVE. Untested patch: --- a/gcc/fortran/symbol.c +++ b/gcc/fortran/symbol.c @@ -441,6 +441,7 @@ check_conflict (symbol_attribute *attr, const char *name, locus *where) case FL_LABEL: case FL_DERIVED: case FL_PARAMETER: + case FL_NAMELIST: a1 = gfc_code2string (flavors, attr-flavor); a2 = save; goto conflict; @@ -449,7 +450,6 @@ check_conflict (symbol_attribute *attr, const char *name, locus *where) /* Conflicts between SAVE and PROCEDURE will be checked at resolution stage, see resolve_fl_procedure. */ case FL_VARIABLE: - case FL_NAMELIST: default: break; }
[Bug fortran/50892] Internal compiler error: in gimplify_expr, at gimplify.c:7477
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50892
Tobias Burnus burnus at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-valid-code
CC||burnus at gcc dot gnu.org
Known to fail||4.3.4
--- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org 2011-10-29
15:04:34 UTC ---
(In reply to comment #0)
In addition to the internal compiler error, there is a problem mentioned in a
comment. According to a Fortran language lawyer, Fortran 2008 allows two
local
definitions of procedures to have the same binding label. This problem is
illustrated in a comment.
I think that's PR 48858.
I'm mainly filing this bug because of the internal compiler error
Simplified test case below. Dump shows:
test ()
{
character(kind=1)[1:1] * str;
void * text;
static void fortranchar (character(kind=1)[1:] * , integer(kind=4), void *);
{
character(kind=1)[1:MAX_EXPR D.1732, 0] * pstr.0;
integer(kind=4) D.1732;
void * D.1730;
D.1730 = text;
D.1732 = strlen (*D.1730);
fortranchar (pstr.0, MAX_EXPR D.1732, 0, D.1730);
str = (character(kind=1)[1:1] *) pstr.0;
}
}
program test
use, intrinsic :: ISO_C_Binding, only: c_ptr, c_int, c_char
type(c_ptr) :: text
character, pointer :: str
interface
pure integer(c_int) function strlen (c) bind(c,name='strlen')
import
type(c_ptr), intent(in), value :: c
end function strlen
end interface
str = FortranChar(text)
contains
function FortranChar ( C )
type(c_ptr), intent(in), value :: C
character(len=strlen(c),kind=c_char), pointer :: FortranChar
end function FortranChar
end program test
[Bug target/50911] New: [4.7 regression] assertion failure in expand_vec_perm_interleave2 with -msse
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50911 Bug #: 50911 Summary: [4.7 regression] assertion failure in expand_vec_perm_interleave2 with -msse Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: target AssignedTo: unassig...@gcc.gnu.org ReportedBy: ebotca...@gcc.gnu.org Target: i?86-*-* x86_64-*-* Created attachment 25660 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25660 Concatenated testcase This is a regression introduced by the recent changes in the x86 back-end which are related to vectorization. If you compile the to-be-gnatchoped testcase with -O3 -msse, you get: eric@atlantis:~/build/gcc gcc -S -gnatws -O3 -msse loop_optimization9.adb +===GNAT BUG DETECTED==+ | 4.7.0 20111028 (experimental) [trunk revision 180610] (i586-suse-linux-gnu) GCC error:| | in expand_vec_perm_interleave2, at config/i386/i386.c:35573 | | Error detected around gcc/ada/rts/s-string.ads:58:4 This compiles fine with -O3 -msse2 instead. The testcase can directly be added to the testsuite as gnat.dg/loop_optimization9.ad[sb].
[Bug fortran/50556] cannot save namelist group name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50556 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-10-29 15:17:19 UTC --- (In reply to comment #2) Well, I see in the standard: [Fortran 2008] C553 An entity with the SAVE attribute shall be a common block, variable, or procedure pointer. And I would argue that a namelist-group-name is neither a common block, a variable nor a procedure pointer. See also http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/07da50d1aaf3870d - there, the argument seems to be the same, though the reference is R544. * * * From c.l.f: Unfortunately, I also found that gfortran has interpreted something like namelist /cmd/ i, j, k save cmd to mean namelist /cmd/ i, j, k save i, j, k The question is whether one needs to allow it. g95 and gfortran allow the code ifort, NAG f95, g77 (!), pathf95/openf95/crayftn reject it. PGI warns Symbol, i, appears illegally in a SAVE statement Thus, I wouldn't mind breaking the backward compatibility.
[Bug fortran/50753] dshiftl/dshiftr: Rejects valid BOZ, accepts double BOZ
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50753 --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-10-29 15:18:28 UTC --- Submitted patch: http://gcc.gnu.org/ml/fortran/2011-10/msg00203.html
[Bug tree-optimization/50912] New: [4.7 regression] gimple assertion failure at gimple.h:1940 with -msse2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50912 Bug #: 50912 Summary: [4.7 regression] gimple assertion failure at gimple.h:1940 with -msse2 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Keywords: ice-on-valid-code Severity: normal Priority: P3 Component: tree-optimization AssignedTo: unassig...@gcc.gnu.org ReportedBy: ebotca...@gcc.gnu.org Target: i?86-*-* x86_64-*-* Created attachment 25661 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25661 Concatenated testcase This is a regression introduced by the recent changes related to vectorization. If you compile the to-be-gnatchoped testcase with -O3 -msse2, you get: eric@atlantis:~/build/gcc gcc/xgcc -Bgcc -S loop_optimization10.adb -O3 -msse2 +===GNAT BUG DETECTED==+ | 4.7.0 20111028 (experimental) [trunk revision 180610] (i586-suse-linux-gnu) GCC error:| | gimple check: expected gimple_assign(error_mark), have | | gimple_call(block) in gimple_assign_rhs_code, at gimple.h:1940 | | Error detected around loop_optimization10.adb:7:4 This compiles fine without -msse2. The testcase can directly be added to the testsuite as gnat.dg/loop_optimization10.ad[sb].
[Bug c/50913] New: ICE: compiling libgfortran for i686-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50913 Bug #: 50913 Summary: ICE: compiling libgfortran for i686-w64-mingw32 Classification: Unclassified Product: gcc Version: 4.7.0 Status: UNCONFIRMED Severity: critical Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: vanboxem.ru...@gmail.com Created attachment 25662 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25662 Preprocessed source for file causing ICE I get an ICE compiling this: /home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc/xgcc -B/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc/ -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib -L/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/lib -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/mingw/include -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/bin/ -B/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/lib/ -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/include -isystem /home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32/i686-w64-mingw32/sys-include -DHAVE_CONFIG_H -I. -I/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran -iquote/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/io -I/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/../gcc -I/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/../gcc/config -I/home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/../libquadmath -I../.././gcc -std=gnu99 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer -fgraphite-identity -floop-interchange -floop-block -floop-parallelize-all -MT spread_i2.lo -MD -MP -MF .deps/spread_i2.Tpo -c /home/ruben/mingw-w64/toolchain/src/gcc/libgfortran/generated/spread_i2.c -DDLL_EXPORT -DPIC -o ./libs/spread_i2.o xgcc -v output: Using built-in specs. COLLECT_GCC=/home/ruben/mingw-w64/toolchain/linux64mingw32/gcc/./gcc/xgcc Target: i686-w64-mingw32 Configured with: /home/ruben/mingw-w64/toolchain/src/gcc/configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --target=i686-w64-mingw32 --with-sysroot=/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32 --prefix=/home/ruben/mingw-w64/toolchain/linux64mingw32/mingw32 --with-libiconv-prefix=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install --with-gmp=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install --with-mpfr=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install --with-mpc=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install --with-ppl=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install --with-cloog=/home/ruben/mingw-w64/toolchain/linux64mingw32/prereq_install --enable-cloog-backend=isl --with-host-libstdcxx='-lstdc++ -lsupc++ -lm -lgcc_eh' --enable-shared --enable-static --enable-threads=posix --disable-multilib --enable-languages=c,lto,c++,fortran,objc,obj-c++,java --enable-libgomp --enable-sjlj-exceptions --enable-fully-dynamic-string --disable-nls --disable-werror --enable-checking=release CFLAGS='-O2 -mtune=core2 -fomit-frame-pointer -momit-leaf-frame-pointer -fgraphite-identity -floop-interchange -floop-block -floop-parallelize-all' LDFLAGS= Thread model: posix gcc version 4.7.0 20111029 (experimental) (GCC) Preprocessed source attached. Same thing happens for spread_i1.c.
[Bug target/50691] Incorrect argument evaluation in call with __thread argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50691 --- Comment #6 from John David Anglin danglin at gcc dot gnu.org 2011-10-29 15:57:04 UTC --- Author: danglin Date: Sat Oct 29 15:57:00 2011 New Revision: 180655 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180655 Log: PR target/50691 config/pa/pa.c (emit_move_sequence): Legitimize TLS symbol references. (pa_legitimate_constant_p): Return false for TLS_MODEL_GLOBAL_DYNAMIC and TLS_MODEL_LOCAL_DYNAMIC symbol references. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/pa.c
[Bug fortran/50556] cannot save namelist group name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50556
--- Comment #4 from Steve Kargl sgk at troutmask dot apl.washington.edu
2011-10-29 16:49:38 UTC ---
On Sat, Oct 29, 2011 at 02:47:52PM +, burnus at gcc dot gnu.org wrote:
One might argue that a SAVE namelist-group-name should mean that all
namelist-group-objects associate this namelist-group-name gets the SAVE
attribute. If this interpretation was correct, then one would expect that
text in the Standard would make this clear.
Well, I see in the standard:
C553 An entity with the SAVE attribute shall be a common block,
variable, or procedure pointer.
And I would argue that a namelist-group-name is neither a common block, a
variable nor a procedure pointer.
Well, spotted. I was scanning the standards for 'namelist-group',
so missed C553.
Thus, I believe that the code in comment 0 is invalid.
Regarding the patch in comment 1: I think it will not work if one swaps the
order of NAMELIST and SAVE.
Confirmed.
Untested patch:
--- a/gcc/fortran/symbol.c
+++ b/gcc/fortran/symbol.c
@@ -441,6 +441,7 @@ check_conflict (symbol_attribute *attr, const char *name,
locus *where)
case FL_LABEL:
case FL_DERIVED:
case FL_PARAMETER:
+ case FL_NAMELIST:
a1 = gfc_code2string (flavors, attr-flavor);
a2 = save;
goto conflict;
@@ -449,7 +450,6 @@ check_conflict (symbol_attribute *attr, const char *name,
locus *where)
/* Conflicts between SAVE and PROCEDURE will be checked at
resolution stage, see resolve_fl_procedure. */
case FL_VARIABLE:
- case FL_NAMELIST:
default:
break;
}
I tested the above. It catches both examples of invalid code
(namelist before save and save before namelist). However, the
error message is a bit strange:
ab.f90:2.12:
save i
1
Error: NAMELIST attribute conflicts with SAVE attribute in 'i' at (1)
NAMELIST is not an attribute. With the attached patch, I get
laptop:kargl[239] gfc4x -c namelist_74.f90
namelist_74.f90:5.15:
namelist /i/ ii! { dg-error cannot have a SAVE attribute }
1
Error: Namelist group name at (1) cannot have a SAVE attribute
namelist_74.f90:9.9:
save i ! { dg-error cannot have a SAVE attribute }
1
Error: Namelist group name at (1) cannot have a SAVE attribute
[Bug fortran/50556] cannot save namelist group name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50556 --- Comment #5 from Steve Kargl sgk at troutmask dot apl.washington.edu 2011-10-29 16:51:10 UTC --- On Sat, Oct 29, 2011 at 03:17:19PM +, burnus at gcc dot gnu.org wrote: From c.l.f: Unfortunately, I also found that gfortran has interpreted something like namelist /cmd/ i, j, k save cmd to mean namelist /cmd/ i, j, k save i, j, k The question is whether one needs to allow it. g95 and gfortran allow the code ifort, NAG f95, g77 (!), pathf95/openf95/crayftn reject it. PGI warns Symbol, i, appears illegally in a SAVE statement Thus, I wouldn't mind breaking the backward compatibility. I vote that gfortran should follow the majority and simply issue an error.
[Bug rtl-optimization/50764] [4.7 Regression] ICE: in maybe_record_trace_start, at dwarf2cfi.c:2243 with -O2 -fsched2-use-superblocks -ftree-tail-merge
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50764 --- Comment #9 from vries at gcc dot gnu.org 2011-10-29 17:16:11 UTC --- Using the bb-reorder patch, the assert is introduced/triggered by r177209: ... r177209 | rth | 2011-08-02 21:56:29 +0200 (Tue, 02 Aug 2011) | 5 lines h8300: Generate correct unwind info around swap_into/out_of_er6. Minimal bug fix is to unset RTX_FRAME_RELATED_P on the PUSH insn generated in h8300_swap_into_er6. But with a tiny bit of effort we can generate real unwind info around the sequence. ...
[Bug middle-end/50902] intVar/dinternal.cc ICEs at -O2 -ftree-vectorize
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50902 --- Comment #6 from Jack Howarth howarth at nitro dot med.uc.edu 2011-10-29 17:39:43 UTC --- Confirmed that both the dinternal.ii and MarvinNOEPotential.ii test cases reproduce this ICE using current gcc trunk under x86_64 Fedora 15.
[Bug c/50908] building emacs-23.3; gives msg: indent.c:1140:1: internal compiler error: in verify_dominators, at dominance.c:1041
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50908 Georg-Johann Lay gjl at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2011-10-29 CC||gjl at gcc dot gnu.org Ever Confirmed|0 |1 --- Comment #1 from Georg-Johann Lay gjl at gcc dot gnu.org 2011-10-29 18:15:02 UTC --- Confired on x86-pc-linux-gnu with trunk revision 180654
[Bug target/50617] [4.5/4.6/4.7 Regression] ICE: RTL flag check: INSN_ANNULLED_BRANCH_P used with unexpected rtx code 'simplify_immed_subreg' in output_bb, at config/pa/pa.c:6631
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50617 --- Comment #4 from John David Anglin danglin at gcc dot gnu.org 2011-10-29 18:58:52 UTC --- Author: danglin Date: Sat Oct 29 18:58:48 2011 New Revision: 180660 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180660 Log: PR target/50617 * config/pa/protos.h (attr_length_save_restore_dltp): Delete. (cmpib_comparison_operator): Likewise. (following_cal, output_and, output_ior, output_move_double, output_fp_move_double, output_block_move, output_block_clear, output_cbranch, output_lbranch, output_bb, output_bvb, output_dbra, output_movb, output_parallel_movb, output_parallel_addb, output_call, output_indirect_call, output_millicode_call, output_mul_insn, output_div_insn, output_mod_insn, singlemove_string, output_arg_descriptor, output_global_address, print_operand, legitimize_pic_address, hppa_encode_label, symbolic_expression_p, fmpyaddoperands, fmpysuboperands, emit_bcond_fp, emit_move_sequence, emit_hpdiv_const, is_function_label_plus_const, jump_in_call_delay, hppa_fpstore_bypass_p, attr_length_millicode_call, attr_length_call, attr_length_indirect_call, return_addr_rtx, function_arg_padding, insn_refs_are_delayed, get_deferred_plabel, ldil_cint_p, zdepi_cint_p, output_ascii, compute_frame_size, and_mask_p, cint_ok_for_move, hppa_expand_prologue, hppa_expand_epilogue, ior_mask_p, compute_zdepdi_operands, output_64bit_and, output_64bit_ior, reloc_needed, magic_milli, shadd_constant_p): Consistently prefix exported functions and variables with pa_. * config/pa/predicates.md: Likewise. * config/pa/pa64-hpux.h: likewise. * config/pa/som.h: Likewise. * config/pa/elf.h: Likewise. * config/pa/pa64-linux.h: Likewise. * config/pa/pa.md: Likewise. * config/pa/pa.c: Likewise. * config/pa/pa-linux.h: Likewise. * config/pa/pa.h: Likewise. * config/pa/constraints.md: Likewise. Modified: trunk/gcc/ChangeLog trunk/gcc/config/pa/constraints.md trunk/gcc/config/pa/elf.h trunk/gcc/config/pa/pa-linux.h trunk/gcc/config/pa/pa-protos.h trunk/gcc/config/pa/pa.c trunk/gcc/config/pa/pa.h trunk/gcc/config/pa/pa.md trunk/gcc/config/pa/pa64-hpux.h trunk/gcc/config/pa/pa64-linux.h trunk/gcc/config/pa/predicates.md trunk/gcc/config/pa/som.h
[Bug fortran/50914] New: Error while installing gcc-4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50914 Bug #: 50914 Summary: Error while installing gcc-4.3.0 Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: jdas...@gmail.com Created attachment 25664 -- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25664 The config.log file picked from specified location in the error. While installing gcc-4.3.0 following error had occurred. checking dynamic linker characteristics... GNU/Linux ld.so checking how to hardcode library paths into programs... immediate checking whether the GNU Fortran compiler is working... no configure: error: GNU Fortran is not working; please report a bug in http://gcc.gnu.org/bugzilla, attaching /home/dasu/gcc-4.3.0/i686-pc-linux-gnu/libgfortran/config.log make[1]: *** [configure-target-libgfortran] Error 1 make[1]: Leaving directory `/home/dasu/gcc-4.3.0' make: *** [all] Error 2 Regarding that error I am attching config.log with this report. Thank you, -- With regards, Dasu
[Bug fortran/50914] Error while installing gcc-4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50914 --- Comment #1 from jdasu86 at gmail dot com 2011-10-29 19:08:39 UTC --- I want to install ns-2.34 which requires gcc-4.3.0 but I am having gcc-4.6.0 in fedora 15. So I tried to install gcc-4.3.0, taht reported me above mentioned bug.
[Bug fortran/50914] Error while installing gcc-4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50914 kargl at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||kargl at gcc dot gnu.org Resolution||WONTFIX --- Comment #2 from kargl at gcc dot gnu.org 2011-10-29 19:13:55 UTC --- 4.3.0 is no longer supported version.
[Bug libstdc++/50915] New: gcc fails at run time due to undefined libintl_textdomain
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50915 Bug #: 50915 Summary: gcc fails at run time due to undefined libintl_textdomain Classification: Unclassified Product: gcc Version: 3.4.3 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ AssignedTo: unassig...@gcc.gnu.org ReportedBy: titu_senap...@yahoo.com Installed GCC 3.4.3 in one x86_64 machine with OS as Suse Linux SP1 I have configured as follows: ./configure --prefix=[path to installation] --host=x86_64-suse-linux --build=x86_64-suse-linux target=x86_64-suse-linux --with-included-gettext reason I have mentioned host, build and target is during configure it is not able to detect the os type hence it is setting target as x86_64-unknown-linux Now the problem is when I am invoking gcc after installation, it is throwing error /vobs/tsp/tools/GCC/LINUX/3.4.3_SLES11/bin/gcc -nodefaultlibs -m32 -o genbin genbin.o -lstdc++ -lgcc -lc /vobs/tsp/tools/GCC/LINUX/3.4.3_SLES11/lib/gcc/x86_64-suse-linux/3.4.3/../../../../lib/libstdc++.so: undefined reference to `libintl_textdomain' /vobs/tsp/tools/GCC/LINUX/3.4.3_SLES11/lib/gcc/x86_64-suse-linux/3.4.3/../../../../lib/libstdc++.so: undefined reference to `libintl_bindtextdomain' collect2: ld returned 1 exit status *** Error code 1 In my system there is a libintl.so available at /usr/local/lib. can it be a problem. Can you please suggest any solution.
[Bug target/50691] Incorrect argument evaluation in call with __thread argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50691 --- Comment #7 from John David Anglin danglin at gcc dot gnu.org 2011-10-29 20:19:46 UTC --- Author: danglin Date: Sat Oct 29 20:19:38 2011 New Revision: 180662 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180662 Log: PR target/50691 * config/pa/pa.c (emit_move_sequence): Legitimize TLS symbol references. * config/pa/pa.h (LEGITIMATE_CONSTANT_P): Return false for TLS_MODEL_GLOBAL_DYNAMIC and TLS_MODEL_LOCAL_DYNAMIC symbol references. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/pa/pa.c branches/gcc-4_6-branch/gcc/config/pa/pa.h
[Bug target/50617] [4.5/4.6/4.7 Regression] ICE: RTL flag check: INSN_ANNULLED_BRANCH_P used with unexpected rtx code 'simplify_immed_subreg' in output_bb, at config/pa/pa.c:6631
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50617 --- Comment #5 from John David Anglin danglin at gcc dot gnu.org 2011-10-29 20:23:04 UTC --- Author: danglin Date: Sat Oct 29 20:23:00 2011 New Revision: 180663 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180663 Log: PR target/50617 * config/pa/pa-protos.h (output_bb): Rename to pa_output_bb. * config/pa/pa.md: Likewise. * config/pa/pa.c: Likewise. Modified: branches/gcc-4_6-branch/gcc/ChangeLog branches/gcc-4_6-branch/gcc/config/pa/pa-protos.h branches/gcc-4_6-branch/gcc/config/pa/pa.c branches/gcc-4_6-branch/gcc/config/pa/pa.md
[Bug fortran/50914] Error while installing gcc-4.3.0
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50914 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org Resolution|WONTFIX |INVALID --- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org 2011-10-29 21:26:04 UTC --- (In reply to comment #0) Created attachment 25664 [details] The config.log file picked from specified location in the error. While installing gcc-4.3.0 following error had occurred. If you look into the attached file, you find the error: /home/dasu/gcc-4.3.0/host-i686-pc-linux-gnu/gcc/f951: symbol lookup error: /home/dasu/gcc-4.3.0/host-i686-pc-linux-gnu/gcc/f951: undefined symbol: mpfr_get_z_exp Thus, you do not have properly installed the MPFR library, which is (rather common) problem, but which you have to fix yourself. * * * I don't know whether Fedora also allows installing an old GCC parallel with a newer one; if so, you could try to install a 4.3 GCC from an old Fedora. If it does not have to be i686 but can also be x86_64-linux: There are also 4.3 builds available at http://gcc.gnu.org/wiki/GFortranBinaries
[Bug target/50691] Incorrect argument evaluation in call with __thread argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50691 --- Comment #8 from John David Anglin danglin at gcc dot gnu.org 2011-10-29 21:29:00 UTC --- Author: danglin Date: Sat Oct 29 21:28:57 2011 New Revision: 180664 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180664 Log: PR target/50691 * config/pa/pa.c (emit_move_sequence): Legitimize TLS symbol references. * config/pa/pa.h (LEGITIMATE_CONSTANT_P): Return false for TLS_MODEL_GLOBAL_DYNAMIC and TLS_MODEL_LOCAL_DYNAMIC symbol references. Modified: branches/gcc-4_5-branch/gcc/ChangeLog branches/gcc-4_5-branch/gcc/config/pa/pa.c branches/gcc-4_5-branch/gcc/config/pa/pa.h
[Bug target/50617] [4.5/4.6/4.7 Regression] ICE: RTL flag check: INSN_ANNULLED_BRANCH_P used with unexpected rtx code 'simplify_immed_subreg' in output_bb, at config/pa/pa.c:6631
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50617 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from John David Anglin danglin at gcc dot gnu.org 2011-10-29 21:44:24 UTC --- Revision 180663 was reverted. Fix is only needed for 4.7.
[Bug middle-end/50913] ICE: compiling libgfortran for i686-w64-mingw32
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50913 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Component|c |middle-end --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org 2011-10-29 22:35:55 UTC --- What was the ICE?
[Bug rtl-optimization/38644] [4.4/4.5/4.6/4.7 Regression] Optimization flag -O1 -fschedule-insns2 causes wrong code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38644 --- Comment #55 from Dave Murphy davem at devkitpro dot org 2011-10-29 23:27:02 UTC --- (In reply to comment #54) I tested with GCC 4.6.2 and the patch provided by Mikael Pettersson. It works for -march=armv4t and -march=armv5t, but not for -march=armv5te: For what it's worth I've been using Richard Earnshaw's patch from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30282#c8 with my own gcc builds and it's working fine for all -march values. There's also Joern's patch at http://gcc.gnu.org/ml/gcc/2011-07/msg00461.html which I haven't tested but looks like it should work. I still don't understand why there seems to be so much resistance to Richard's suggestion that targets with redzones should explicitly enable this behaviour. How can it be a hack to treat stack moves specially? Isn't the stack generally a special register?
[Bug other/50916] New: -Os, -D_FORTIFY_SOURCE breaks strcpy others if inlined
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50916
Bug #: 50916
Summary: -Os, -D_FORTIFY_SOURCE breaks strcpy others if
inlined
Classification: Unclassified
Product: gcc
Version: 4.6.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: dez...@gmail.com
Created attachment 25665
-- http://gcc.gnu.org/bugzilla/attachment.cgi?id=25665
The preprocessed source
Not totally sure if a glibc or gcc bug, but anyway: GCC 4.6.2 causes the
following code to get into an infinite loop in strcpy if compiled with
gcc -std=c99 -Os -D_FORTIFY_SOURCE=2
#include argp.h
#include string.h
int main (void) {
char buf[1024];
char* str = hello;
strcpy (buf, str);
return 0;
}
It seems that something in the #includes is pulling in the following definition
for strcpy:
extern __inline char *
strcpy (char *__restrict __dest, const char *__restrict __src)
{
return __builtin___strcpy_chk (__dest, __src, __builtin_object_size (__dest,
2 1));
}
...and then the __builtin_strcpy_chk seems to turn back into strcpy (due to
-Os?):
0035 strcpy:
35: 55 push %ebp
36: 89 e5 mov%esp,%ebp
38: 5d pop%ebp
39: e9 fc ff ff ff jmp3a strcpy+0x5
3a: R_386_PC32 strcpy
...which then causes the infinite loop.
gcc -v:
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/i486-linux-gnu/4.6/lto-wrapper
Target: i486-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Debian 4.6.2-2'
--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-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-objc-gc
--enable-targets=all --with-arch-32=i586 --with-tune=generic
--enable-checking=release --build=i486-linux-gnu --host=i486-linux-gnu
--target=i486-linux-gnu
Thread model: posix
gcc version 4.6.2 (Debian 4.6.2-2)
[Bug libstdc++/50915] gcc fails at run time due to undefined libintl_textdomain
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50915 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2011-10-30 Ever Confirmed|0 |1 --- Comment #1 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-30 00:18:24 UTC --- 3.4.x is very, very, old and not maintained anymore. Thus, before anything else, try something modern, like the just released 4.6.2.
[Bug c++/50901] [4.6/4.7 Regression] ICE: in build_new_op, at cp/call.c:5016
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50901 --- Comment #2 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-10-30 00:22:59 UTC --- Author: paolo Date: Sun Oct 30 00:22:53 2011 New Revision: 180670 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180670 Log: /cp 2011-10-29 Paolo Carlini paolo.carl...@oracle.com PR c++/50901 * call.c (build_new_op_1): Handle ABS_EXPR together with the other unary EXPR. /testsuite 2011-10-29 Paolo Carlini paolo.carl...@oracle.com PR c++/50901 * g++.dg/cpp0x/pr50901.C: New. Added: trunk/gcc/testsuite/g++.dg/cpp0x/pr50901.C Modified: trunk/gcc/cp/ChangeLog trunk/gcc/cp/call.c trunk/gcc/testsuite/ChangeLog
[Bug c++/50901] [4.6/4.7 Regression] ICE: in build_new_op, at cp/call.c:5016
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50901 --- Comment #3 from paolo at gcc dot gnu.org paolo at gcc dot gnu.org 2011-10-30 00:24:54 UTC --- Author: paolo Date: Sun Oct 30 00:24:51 2011 New Revision: 180671 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180671 Log: /cp 2011-10-29 Paolo Carlini paolo.carl...@oracle.com PR c++/50901 * call.c (build_new_op_1): Handle ABS_EXPR together with the other unary EXPR. /testsuite 2011-10-29 Paolo Carlini paolo.carl...@oracle.com PR c++/50901 * g++.dg/cpp0x/pr50901.C: New. Added: branches/gcc-4_6-branch/gcc/testsuite/g++.dg/cpp0x/pr50901.C Modified: branches/gcc-4_6-branch/gcc/cp/ChangeLog branches/gcc-4_6-branch/gcc/cp/call.c branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
[Bug c++/50901] [4.6/4.7 Regression] ICE: in build_new_op, at cp/call.c:5016
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50901 Paolo Carlini paolo.carlini at oracle dot com changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #4 from Paolo Carlini paolo.carlini at oracle dot com 2011-10-30 00:25:48 UTC --- Fixed 4.6.3 and mainline.
[Bug middle-end/45631] devirtualization with profile feedback does not work for function pointers
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45631 --- Comment #3 from Andi Kleen andi-gcc at firstfloor dot org 2011-10-30 02:33:29 UTC --- Honza, any further ideas how to proceed? Should the threshold just be lowered?
[Bug target/50691] Incorrect argument evaluation in call with __thread argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50691 --- Comment #9 from John David Anglin danglin at gcc dot gnu.org 2011-10-30 03:21:49 UTC --- Author: danglin Date: Sun Oct 30 03:21:45 2011 New Revision: 180672 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=180672 Log: PR target/50691 * config/pa/pa.c (emit_move_sequence): Legitimize TLS symbol references. * config/pa/pa.h (LEGITIMATE_CONSTANT_P): Return false for TLS_MODEL_GLOBAL_DYNAMIC and TLS_MODEL_LOCAL_DYNAMIC symbol references. Modified: branches/gcc-4_4-branch/gcc/ChangeLog branches/gcc-4_4-branch/gcc/config/pa/pa.c branches/gcc-4_4-branch/gcc/config/pa/pa.h
[Bug target/50691] Incorrect argument evaluation in call with __thread argument
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50691 John David Anglin danglin at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #10 from John David Anglin danglin at gcc dot gnu.org 2011-10-30 03:24:44 UTC --- Fixed.
