[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #18 from wilson at gcc dot gnu dot org 2006-04-12 22:10 --- Subject: Bug 26483 Author: wilson Date: Wed Apr 12 22:10:49 2006 New Revision: 112900 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=112900 Log: Fix IA-64 problems with denorms getting clobbered by type conversions. PR libgcj/26483 * src/ia64/ffi.c (stf_spill, ldf_fill): Rewrite as macros. (hfa_type_load): Call stf_spill. (hfa_type_store): Call ldf_fill. (ffi_call): Adjust calls to above routines. Add local temps for macro result. Modified: trunk/libffi/ChangeLog trunk/libffi/src/ia64/ffi.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #19 from wilson at gcc dot gnu dot org 2006-04-12 22:21 --- IA-64. Mine. -- wilson at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-04-12 22:21:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #20 from wilson at gcc dot gnu dot org 2006-04-12 22:22 --- Fixed on mainline. Testcase added to mainline. The fix should probably be backported to one or more active release branches. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC|wilson at gcc dot gnu dot | |org | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug libgcj/26483] Wrong parsing of doubles when interpreted on ia64
--- Comment #22 from wilson at gcc dot gnu dot org 2006-06-01 22:36 --- Subject: Bug 26483 Author: wilson Date: Thu Jun 1 22:36:19 2006 New Revision: 114319 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=114319 Log: Fix broken denorm support. PR libgcj/26483 * src/ia64/ffi.c (stf_spill, ldf_fill): Rewrite as macros. (hfa_type_load): Call stf_spill. (hfa_type_store): Call ldf_fill. (ffi_call): Adjust calls to above routines. Add local temps for macro result. Modified: branches/gcc-4_1-branch/libffi/ChangeLog branches/gcc-4_1-branch/libffi/src/ia64/ffi.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26483
[Bug debug/27851] Hour-long segfault with -O1 -g on gcc.dg/parm-impl-decl-1.c
--- Comment #3 from wilson at gcc dot gnu dot org 2006-06-10 01:19 ---
This is a C front end bug. The C front end is creating a circular symbol
table, where the function h is defined both in the external scope and inside
itself. The dwarf2out.c code then goes into an infinite recursion trying to
tree walk the circular symbol table.
The syntax error is not needed to reproduce the problem. You just need two
functions with implicit function declarations in their parameter list. For
instance:
foo (int (*p)[sizeof(j())])
{
}
h (int (*p)[sizeof(i())])
{
}
The C front end problem can be reproduced with only one function, but you need
two to trigger the dwarf2out.c failure.
You also don't need a checking enabled build to reproduce this.
The dwarf code works in the presence of a single circular reference in the
symbol table because there is code in gen_subprogram_die that catches the case
where we try to define a function twice. This doesn't work when we have two
circular references. Now the function h is defined in 3 places, externally,
inside itself, and inside foo. The one inside foo is turned into a
declaration, and now the short circuit code in gen_subprogram_die doesn't work,
and we get the infinite recursion.
The problem occurs in get_parm_info and store_parm_decls_newstyle in c-decl.c.
The first function tears apart the binding scope for parameters. When it sees
a function, it puts it on the others list. Then store_parm_decls_newstyle
reinserts it in the proper place in the proper scope with nested=0 regardless
of what the original value of nested was. This appears to be the bug.
When the function i, for instance, was inserted into binding scopes, it was put
in two of them. It was put in the external scope with nested=0, and it was put
in the param scope with nested=1. If this info was preserved by get_parm_info
and store_parm_decls_newstyle, then the bug would not occur.
The circular refernence is created in pop_scope. When popping the scope for
the function h, i is inserted into the BLOCK_VARS for the function body because
nested is 0. When popping the external scope, i is inserted into the
BLOCK_VARS for the external scope, because nested is 0. Now we have the same
decl in two places in the symbol table. When we handle the function h for the
external scope, it is chained to i, and now since i is also declared inside the
function h, the function h is also declared inside itself. When we add foo, h
is now also declared inside foo, and foo inside h.
I don't see an easy way to fix this without adding aanother datastructure. We
could change the others field to be a structure containing a tree and the
nested info, and then store_parm_decls_newstyle can get the nested value
correct when it reinserts the tree into the symbol table.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
CC| |wilson at gcc dot gnu dot
| |org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-06-10 01:19:03
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27851
[Bug rtl-optimization/27761] combine miscompiles
--- Comment #5 from wilson at gcc dot gnu dot org 2006-06-10 02:49 --- If a combination is successful, we will delete i1 and i2, so it doesn't matter if they changed accidentally. If a combination fails, then we go through undobuf and revert all changes, so it doesn't matter if i1 or i2 changed accidentally. They will be restored to their original values when we are done. The only case where it matters is if added_sets_2 or added_sets_1 is true. In this case, we will re-add the patterns from i1 and/or i2 after the combination. So in this case, we need to make sure we still have the original patterns. We already make a copy of the i2 pattern for this purpose. i2pat is a copy, and is only used if added_sets_2 is true. So we just need to do the same for i1pat. I agree the comment before the i2pat is a bit confusing. It looks like the copy was originally added to fix an obscure problem, but it also happens to fix this one too. It looks like there is an unnecessary gen_rtx_SET call, as i2pat will only be used if added_sets_2 is true. So the code setting i2pat should be moved inside the added_sets_2 if statement. The new i1pat code should work the same way. The actual modification of the if_then_else rtl happens inside force_to_mode, as called from simplify_and_const_int. See the uses of SUBST in the if_then_else case in force_to_mode. This problem could be fixed if we generated new rtl here instead of using SUBST, but I don't think that is helpful, as there are other places that also call SUBST. It is safer to make the i1pat copy. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC| |wilson at gcc dot gnu dot | |org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2006-06-10 02:49:49 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27761
[Bug target/27883] [4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips
--- Comment #4 from wilson at gcc dot gnu dot org 2006-06-27 03:02 ---
This only fails for --enable-checking builds, which is the default for
mainline, but not release branches. I was able to reproduce this with gcc-4.0,
but not gcc-3.4. The difference between the two is that gcc-4.0 has the
__builtin_copysign support, which emits the RTL that triggers the error. The
error has probably been latent for a while.
The insn that causes the problem is
(jump_insn 99 98 113 15 (set (pc)
(if_then_else (ge:SI (subreg:SI (reg:DF 32 $f0) 4)
(const_int 0 [0x0]))
(label_ref 101)
(pc))) 261 {*branch_zerosi} (insn_list:REG_DEP_TRUE 94 (nil))
(expr_list:REG_DEAD (reg:SI 33 $f1)
(expr_list:REG_BR_PROB (const_int 5000 [0x1388])
(nil
On a 32-bit mips target, DFmode $f0 is a register pair $f0/$f1, so technically
this is correct. There is a corresponding REG_UNUSED for $f0 on the insn that
sets (reg:DF 32 $f0).
However, flow doesn't track individual regs in subregs, it only tracks the
whole subreg. Note that mark_used_reg ignores subregs. So when we execute the
second life pass, we end up with
(jump_insn 98 97 112 17 (set (pc)
(if_then_else (ge (subreg:SI (reg:DF 32 $f0) 4)
(const_int 0 [0x0]))
(label_ref 100)
(pc))) 271 {*branch_ordersi} (insn_list:REG_DEP_TRUE 93 (nil))
(expr_list:REG_DEAD (reg:DF 32 $f0)
(expr_list:REG_DEAD (reg:SI 33 $f1)
(expr_list:REG_BR_PROB (const_int 5000 [0x1388])
(nil)
Note that we now have two overlapping REG_DEAD notes plus an overlapping
REG_UNUSED note on a previous insn. When sched runs, it deletes both REG_DEAD
notes, but only readds one, resulting in the abort for a REG_DEAD note
consistency problem.
A subreg of a hard register is normally not allowed, but it is created in this
case because CANNOT_CHANGE_CLASS_MODE is defined, and HARD_REGNO_MODE_OK says
that an SImode $f1 is not OK. The result is that simplify_subreg doesn't
simplify this. The other part is that register_operand says it is OK.
Eventually, this gets fixed by reload.
Fixing combine to get this right looks complicated. Combine has to know that
the register was used inside a subreg, and then figure out that the subreg
wasn't simplified because of CANNOT_CHANGE_CLASS_MODE, etc.
I think a simpler solution here is to note that the life2 pass would have
worked correctly if it deleted all prior REG_UNUSED/REG_DEAD notes before it
started. Incidentally, the comments for the life2 pass say it was explicitly
added to fix REG_UNUSED/REG_DEAD problems with distribute_notes in combine, so
it was apparently added to fix a related problem. It just isn't working the
way it was originally intended.
It is curious that life2 is running immediately before sched, instead of
immediately after combine. If we ran it immediately after combine, we could
get rid of the REG_DEAD/REG_UNUSED support in distribute_notes, which is
probably the most complicated, and most buggy, part of combine. This would
also speed up the compiler a little bit.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
CC| |wilson at gcc dot gnu dot
| |org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2006-06-27 03:02:40
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
[Bug target/27883] [4.0/4.1/4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips
--- Comment #5 from wilson at gcc dot gnu dot org 2006-07-11 01:32 --- This is already fixed on dataflow-branch. At the end of combine_instructions, it runs a global dataflow pass that removes all REG_DEAD and REG_UNUSED notes before creating new ones. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
[Bug target/27883] [4.0/4.1/4.2 regression] in schedule_insns, at sched-rgn.c:3038 on mips
--- Comment #6 from wilson at gcc dot gnu dot org 2006-07-11 01:41 --- Created an attachment (id=11857) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=11857&action=view) Delete old REG_DEAD notes before creating new ones. This works for the testcase, but is otherwise untested. This just deletes the old REG_DEAD notes for a local life update before creating new ones. I believe this could be made simpler by eliminating UPDATE_LIFE_GLOBAL_RM_NOTES, and then calling count_or_remove_death_notes if PROP_DEATH_NOTES is set for both global and local updates. However, assuming we want what is on dataflow-branch, it seems better to go with a safer non-conflicting patch for now, and let dataflow-branch be the long term fix. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27883
[Bug middle-end/27313] Does not emit conditional moves for stores
--- Comment #6 from wilson at gcc dot gnu dot org 2009-05-09 01:21 --- It looks like this was fixed by Michael Matz here: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg01978.html This patch was added to gcc-4.3, and the gcc-4.2 branch is closed, so I think this bug should be closed resolved. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27313
[Bug bootstrap/40706] gcc doesn't compile on centos3 64bit
--- Comment #4 from wilson at gcc dot gnu dot org 2009-07-18 20:05 --- > build/genmodes -h> tmp-modes.h > /bin/sh: line 1: build/genmodes: No such file or directory > make: *** [s-modes-h] Error 127 This is the error you can get when a program interpreter does not exist. More recent linux versions will print a better error message, but old ones do give this ambiguous message for this problem. For an ELF binary linked against glibc, the program interpreter is ld.so. Maybe you are missing some library files? build/genmodes is incidentally the first binary we will run that was compiled by the just built gcc, so a configure error sometimes shows up as a build/genmodes failure. Try running "ldd build/genmodes". You might also try "objdump --full-contents --section .interp build/genmodes". If either of these list non-existent files in the output, then that is the problem. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC| |wilson at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40706
[Bug preprocessor/15220] [3.4 regression] "gcc -E -MM -MG" reports missing system headers in source directory
--- Comment #17 from wilson at gcc dot gnu dot org 2005-11-07 19:49 --- Subject: Bug 15220 Author: wilson Date: Mon Nov 7 19:49:04 2005 New Revision: 106608 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=106608 Log: Fix problem with -MM -MG and missing system header files. PR preprocessor/15220 * cppfiles.c (_cpp_find_file): New parameter angle_brackets. Fix all callers. Pass to open_file_failed. (open_file_failed): New parameter angle_brackets. Fix all callers. use in print_dep assignment. * cpphash.h (_cpp_find_file): Add new parm to declaration. * cppinit.c (cpp_read_main_file): Pass another arg to _cpp_find_file. Modified: branches/gcc-3_4-branch/gcc/ChangeLog branches/gcc-3_4-branch/gcc/cppfiles.c branches/gcc-3_4-branch/gcc/cpphash.h branches/gcc-3_4-branch/gcc/cppinit.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15220
[Bug preprocessor/15220] [3.4 regression] "gcc -E -MM -MG" reports missing system headers in source directory
--- Comment #18 from wilson at gcc dot gnu dot org 2005-11-07 19:51 --- Mine. -- wilson at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2004-04-30 12:53:54 |2005-11-07 19:51:09 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15220
[Bug preprocessor/15220] [3.4 regression] "gcc -E -MM -MG" reports missing system headers in source directory
--- Comment #19 from wilson at gcc dot gnu dot org 2005-11-07 19:52 --- Fixed on gcc-3.4.x branch, gcc-4.0.x branch, and mainline. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|4.0.3 4.1.0 |4.0.3 4.1.0 3.4.5 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=15220
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #1 from wilson at gcc dot gnu dot org 2005-11-08 01:41 --- See the thread on the gcc list discussing this bug. http://gcc.gnu.org/ml/gcc/2005-11/msg00331.html I suspect this is a bug in patches applied to the gcc-3.4.x sources as I do not see this problem in the FSF sources. I do not have an ia64-hpux machine, so I can not easily investigate this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug target/24718] Shared libgcc not used for linking by default
--- Comment #7 from wilson at gcc dot gnu dot org 2005-11-09 01:45 ---
I see the problem now. It is present in the FSF gcc-3.4.x sources.
The problem is that init_gcc_specs in gcc.c rewrites the LIBGCC_SPEC rule. It
looks for the first -lgcc, and replaces it with target independent rules for
shared and static libgcc.
The config/ia64/hpux.h file redefines LIBGCC_SPEC as
#define LIBGCC_SPEC \
"%{shared-libgcc:%{!mlp64:-lgcc_s}%{mlp64:-lgcc_s_hpux64} -lgcc} \
%{!shared-libgcc:-lgcc}"
So after the substitution, we now have %{shared-libgcc ... %{static-libgcc
...}} which is obviously wrong.
If the config/ia64/hpux.h file is changed to look something like
#define LIBGCC_SPEC \
"%{shared-libgcc:%{!mlp64:-lgcc_s}%{mlp64:-lgcc_s_hpux64}} -lgcc"
then it will work much better. I think this can be simplified further without
loss of functionality to
#define LIBGCC_SPEC \
"%{shared-libgcc:%{mlp64:-lgcc_s_hpux64}} -lgcc"
The important part here is that -lgcc must not appear inside any braces,
because it will be substituted by init_gcc_specs.
Alternatively, we could try disabling the init_gcc_specs rewriting for the
ia64-hpux target, and then putting the entire rule we want in the
config/ia64/hpux.h file, but I don't think that big of a patch is needed.
A better alternative would be deleting the LIBGCC_SPEC rule in
config/ia64/hpux.h, but I don't know if that will work. That might result in
the libgcc_s_hpux64 file not being used anymore. I also don't know whether
that matters. I would guess that the multilibbing support should find and use
it automatically, so in theory it shouldn't be needed, but I am unable to
check.
gcc-4.0 and later do not have a problem, because they don't define LIBGCC_SPEC
in the config/ia64/hpux.h file.
I can't test the suggested patches, as I don't have an ia64-hpux machine.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
------------
CC||wilson at gcc dot gnu dot
||org
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last reconfirmed|-00-00 00:00:00 |2005-11-09 01:45:26
date||
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24718
[Bug debug/24490] [4.1 Regression] gcc / gdb backtrace problem
--- Comment #9 from wilson at gcc dot gnu dot org 2005-11-14 21:09 --- Not a gcc bug. This is a gdb bug, and I already have an approved patch for gdb that will be checked in shortly. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24490
[Bug target/24934] [4.1/4.2 Regression] profilebootstrap failure
--- Comment #17 from wilson at gcc dot gnu dot org 2005-11-23 00:16 --- The hot/cold section partitioning stuff has no support for generating unwind info. See for instance in opts.c where this is turned off when flag_exceptions is true, which means it is always turned off by default for C++. This is because C++ requires unwind info for the EH support, and we can't generate correct unwind info when host/cold section partitioning is on. This is true for all targets. The reason why there is an IA-64 issue here is because unwind info is a required part of the ABI. We must always generate unwind info, even for C, and thus this option is never safe on IA-64. But it will work for all other targets as they don't require unwind info for C code. I believe the correct fix here is to turn off the hot/cold partitioning support when flag_unwind_tables is defined. This is turned on by default in the IA-64 backend. This can also be turned on by the user. There are also some peripheral issues here. We should reconsider whether profiledbootstrap should include an option that does not support all targets and all languages. This could be trouble later. Also, the IA-64 assembler should not be core dumping here. -- wilson at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-11-20 00:38:48 |2005-11-23 00:16:39 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24934
[Bug target/24934] [4.1/4.2 Regression] profilebootstrap failure
--- Comment #18 from wilson at gcc dot gnu dot org 2005-11-23 00:20 --- Created an attachment (id=10320) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10320&action=view) Turn off partitioning optimization when flag_unwind_tables true. Suggested untested patch. Gives different message for user requested unwind info versus target requested unwind info. This part is optional, and only affects IA-64 when flag_unwind_tables is the default. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24934
[Bug target/25008] New: problems with "S" constraint in asms
The following testcase compiles with gcc-4.0, but generates an error with
optimization with gcc-4.1.
int *
sub (int *i, int k)
{
int j;
for (j = 0; j < 16; j++)
{
asm volatile ("foo %0" : "=S" (*i));
i += k;
}
return i;
}
aretha$ ./xgcc -B./ -O2 -S -da tmp.c
tmp.c: In function sub:
tmp.c:7: error: asm operand requires impossible reload
This was broken by my patch that defined EXTRA_MEMORY_CONSTRAINT.
http://gcc.gnu.org/ml/gcc-patches/2005-08/msg00714.html
I didn't have a testcase for that at the time, but now that I've run into
trouble, I went to the effort of creating of creating one. It required adding
two letters, and deleting one. The following testcase fails when compiled
without optimization with gcc-4.0.
int *
sub (int *i, int k)
{
int j;
for (j = 0; j < 16; j++)
{
asm volatile ("foo %0" : : "S" (*i));
i += k;
}
return i;
}
aretha$ ./xgcc -B./ -S -da tmp2.c
tmp2.c: In function sub:
tmp2.c:7: error: impossible constraint in asm
The reason why defining EXTRA_MEMORY_CONSTRAINT fails for the first example is
because asm_operand_ok has code that says any memory operand is OK if
EXTRA_MEMORY_CONSTRAINT is true because it can be reloaded to fit. This is
true in theory. Unfortunately, reload doesn't know how to fix a MEM with a
POST_MODIFY address. It fixes all MEMs that didn't quite match a MEM
constraint where an offsettable address is OK by reloading the address.
else if (goal_alternative_matched[i] == -1
&& goal_alternative_offmemok[i]
&& MEM_P (recog_data.operand[i]))
{
operand_reloadnum[i]
= push_reload (XEXP (recog_data.operand[i], 0), NULL_RTX,...
So if we have an operand (MEM (POST_MODIFY ...)) it is fixed by emitting an
insn (set (reg) (POST_MODIFY ...)) which fails to be recognized triggering the
error. find_reloads_address knows how to fix this, but of course did not do
anything because this address is accepted by GO_IF_LEGITIMATE_ADDRESS.
The second example fails without EXTRA_MEMORY_CONSTRAINT defined because of
parse_input_constraint in stmt.c. If EXTRA_CONSTRAINT_STR is not defined, then
it decides that no operand is acceptable. When I posted the earlier patch, I
mentioned that it looked like we had a misplaced #endif, since the default here
should be to just accept all operands if we can't handle the constraint letter.
Unfortunately, taking a second look, I see that a parse_input_constraint change
doesn't work, because gimplify_asm_expr gives me the MEM operand I need only if
!allows_reg.
So it looks like I have to try to fix reload if I want this to work.
--
Summary: problems with "S" constraint in asms
Product: gcc
Version: 4.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: wilson at gcc dot gnu dot org
GCC target triplet: ia64-*-*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25008
[Bug target/24961] No constraint letter for destination_operand
--- Comment #1 from wilson at gcc dot gnu dot org 2005-11-23 22:05 --- Confirmed. I believe 25008 will have to be fixed before we can add a working constraint letter for this. It should be possible to generate a testcase for this by taking the example from 25008, changing the "S" to an "m", and then changing foo to a valid store instruction syntax so as to get the desired assembler error. I'll worry about that later when I need a testcase. -- wilson at gcc dot gnu dot org changed: What|Removed |Added BugsThisDependsOn||25008 Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-11-23 22:05:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24961
[Bug middle-end/24804] [3.4 Regression] Produces wrong code
--- Comment #4 from wilson at gcc dot gnu dot org 2005-11-29 03:39 ---
The failure happens in store_motion in gcse.c.
We have two objects on the stack with disjoint lifetimes that overlap. They
have different MEM_EXPRS, and some of the mems also have different alias sets.
They have different MEM_EXPRs as they are from different objects.
(insn 34 3 37 0 (set (mem/s/j:SI (plus:SI (reg/f:SI 20 frame)
(const_int -32 [0xffe0])) [0 .X0+0 S4
A32\])
(const_int 0 [0x0])) 43 {*movsi_1_nointernunit} (nil)
(nil))
(insn 92 89 99 0 (set (mem/s/j:SI (plus:SI (reg/f:SI 20 frame)
(const_int -32 [0xffe0])) [0 .X4+0 S4
A32\])
(const_int 0 [0x0])) 43 {*movsi_1_nointernunit} (nil)
(nil))
(insn 116 162 117 2 (set (mem/s/j:SI (plus:SI (reg/f:SI 20 frame)
(const_int -32 [0xffe0])) [0 f2.X4+0 S4 A128])
(const_int 0 [0x0])) 43 {*movsi_1_nointernunit} (nil)
(nil))
This in itself is fairly harmless. However, a problem occurs when we try to
keep track of mems. We call ldst_entry which computes a hash code, which is
identical for the two mems, and then puts them into the same ls_expr structure.
This ls_expr structure only holds one mem rtx. Which means the aliasing info
is now wrong for the other mem rtx. Eventually we call true_dependence with a
read for the other mem, and it decides that they can't alias because of the
differing MEM_EXPRs.
It appears that the solution here is to somehow combine the aliasing info when
putting multiple mems into a single ls_expr structure. If we put two MEMs with
differing MEM_EXPRs into the same ls_expr structure, then we should create a
new mem with a cleared MEM_EXPR field. Similarly, if we have two MEMs with
different alias sets, then we may need to say that they can alias anything.
There is a comment that indicates that we are deliberately ignoring the alias
sets when computing the hash codes, as this caused problems for profile
feedback directed optimization. I haven't looked at the details here.
The testcase doesn't fail with gcc-4.0 and up, because after tree-ssa opts
there isn't anything left for the RTL gcse pass to do. However, I believe the
bug is still there in the code, it is just very much harder to reproduce now.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24804
[Bug middle-end/24804] [3.4 Regression] Produces wrong code
--- Comment #6 from wilson at gcc dot gnu dot org 2005-11-29 05:57 --- PR 25130 is a gcse problem, and there are some curious similarities. We have two objects on the stack with the same address, and gcse is emitting new RTL referring to the "wrong" one, which means we have mems with bad MEM_EXPR fields after gcse is finished. However, the underlying failure is different here. It seems to be a problem with the load motion logic. I will put some details into that PR. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC| |wilson at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24804
[Bug rtl-optimization/25130] [4.1/4.2 Regression] miscompilation in GCSE
--- Comment #3 from wilson at gcc dot gnu dot org 2005-11-29 06:10 ---
This is indeed a gcse problem. It is a problem with the load motion support.
There are some similarities to PR 24804 here. We have multiple overlapping
objects on the stack, that have mems with different MEM_EXPR fields, that are
being treated as the same object because they have the same hash code. This
results in some new RTL being emitted by gcse that has mems with incorrect
MEM_EXPR fields. This doesn't cause the failure though, and seems to be
harmless for this testcase. This is potentially a problem for other testcases
though.
The problem happens shortly before the printf call. We have before gcse
(insn 60 58 61 3 (parallel [
(set (mem/s/j/c:SI (plus:SI (reg/f:SI 20 frame)
(const_int -8 [0xfff8])) [0
clusters.D.1787\._M_impl._M_finish_cur+0 S4 A32])
(plus:SI (mem/s/j/c:SI (plus:SI (reg/f:SI 20 frame)
(const_int -8 [0xfff8])) [0
clusters.D.\1787._M_impl._M_finish_cur+0 S4 A32])
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) 208 {*addsi_1} (nil)
(nil))
;; End of basic block 3, registers live:
(nil)
;; Start of basic block 4, registers live: (nil)
(code_label 61 60 62 4 4 "" [1 uses])
(note 62 61 64 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 64 62 65 4 (set (reg:SI 72 [ clusters.D.1787._M_impl._M_finish_cur ])
(mem/s/j/c:SI (plus:SI (reg/f:SI 20 frame)
(const_int -8 [0xfff8])) [0
clusters.D.1787._M_impl\._M_finish_cur+0 S4 A32])) 40 {*movsi_1} (nil)
(nil))
and after gcse we have
(insn 60 58 124 3 (parallel [
(set (mem/s/j/c:SI (plus:SI (reg/f:SI 20 frame)
(const_int -8 [0xfff8])) [0
clusters.D.1787\._M_impl._M_finish_cur+0 S4 A32])
(plus:SI (mem/s/j/c:SI (plus:SI (reg/f:SI 20 frame)
(const_int -8 [0xfff8])) [0
clusters.D.\1787._M_impl._M_finish_cur+0 S4 A32])
(const_int 4 [0x4])))
(clobber (reg:CC 17 flags))
]) 208 {*addsi_1} (nil)
(nil))
(jump_insn 124 60 125 3 (set (pc)
(label_ref 61)) -1 (nil)
(nil))
;; End of basic block 3, registers live:
(nil)
(barrier 125 124 127)
;; Start of basic block 4, registers live: (nil)
(code_label 127 125 126 4 12 "" [1 uses])
(note 126 127 121 4 [bb 4] NOTE_INSN_BASIC_BLOCK)
(insn 121 126 61 4 (set (reg:SI 79 [ clusters.D.1787._M_impl._M_finish_cur ])
(mem/s/j:SI (plus:SI (reg/f:SI 20 frame)
(const_int -8 [0xfff8])) [0
._M_impl._M_s\tart_node+0 S4 A32])) 40 {*movsi_1} (nil)
(nil))
;; End of basic block 4, registers live:
(nil)
;; Start of basic block 5, registers live: (nil)
(code_label 61 121 62 5 4 "" [1 uses])
(note 62 61 65 5 [bb 5] NOTE_INSN_BASIC_BLOCK)
(insn 65 62 66 5 (set (mem:SI (plus:SI (reg/f:SI 7 sp)
(const_int 8 [0x8])) [0 S4 A32])
(reg:SI 79 [ clusters.D.1787._M_impl._M_finish_cur ])) 40 {*movsi_1}
(n\il)
(nil))
For some reason, gcse thought that insn 64 was redundant, and deleted it,
adding a new basic block with a load as compensation code. This results in reg
79 having the wrong value when we go from the increment to the printf.
I haven't pinpointed an exact cause of the problem. The gcse algorithmics are
complicated. I think the underlying failure is that we are adding mems to the
expression table, and adding their load/store insns to the ldst_table. When we
find a load/store we can't handle, we remove it from the ldst_table. However,
we never remove entries from the expression table. Since there are still mems
in the expression table, gcse still tries to optimize them. And this results
in bad code, because some load/store insns needs fixups when their mems are
optimized, and these fixups do not happen because the load/store insns are no
longer in the ldst_table. The fixups are supposed to be emitted in
update_ld_motion_stores.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
CC| |wilson at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=25130
[Bug middle-end/21059] Bogus warning about clobbered variable
--- Comment #4 from wilson at gcc dot gnu dot org 2005-12-02 02:24 ---
The spurious warning is a problem because binutils is compiled by -Werror by
default now, when compiled by gcc. This spurious warning thus causes a build
failure for binutils. This build failure does not show up in a native
ia64-linux build fortunately, it only shows up for cross builds, or if
--enable-targets=all is used. Still, this means it is a problem for people
trying to do binutils development on an ia64-linux host. This may also cause
problems with other programs as use of -Werror spreads.
Also, the spurious warning is a problem because the warning is inherently
unportable. Different targets and/or different optimization options can result
in different sets of warnings. So what happens is that one person compiles the
code and gets no warning. Another compiles the code for a different target,
gets a warning, and submits a patch. Then the first person points out that the
code isn't broken, that the patch shouldn't necessary, and recommends that the
compiler should be fixed. Hence this PR.
The failure happens for ia64 because of the lack of reg+offset addressing
modes. We have a parameter info, copied into pseudo-reg 345, that is
dereferenced twice, once for the fprintf_func field and once for the stream
field. These fields are at offset 0 and 4. Normally, we would get two mems
one with address (reg 345) and one with address (plus (reg 345) (const_int 4)).
But IA-64 does not have reg+offset, so we end up with a post-increment of reg
345. This means reg 345 is now set twice. Once before the setjmp, and once
afterwards. This triggers the code in regno_clobbered_at_setjmp which has a
test "REG_N_SETS (regno) > 1" which is now true for IA-64, but not for most
other targets.
The best fix I see is to improve the CFG to include info about which block
after setjmp is the fallthrough and which is the return from longjmp path.
Once we have the improved CFG, then we can implement a more accurate test, such
as the one tft mentioned in comment #3. It may be easier and/or more
appropriate to do this work in the tree-ssa part of the compiler. This is
likely more work than I can do at the moment for this PR.
A more limited solution may be possible by adjusting the setjmp warning code to
take these post-inc sets into account. We could keep track of sets created by
auto-inc optimizations, and then subtract them in the setjmp warning code.
This would ensure the same results for all targets, regardless of addressing
modes. The flaw here is that if auto-inc opts do modify a register, then we
really do have a problem, and really should have emitted a warning. So this
doesn't seem worth pursuing.
Alternatively, we could disable auto-inc optimization for pseudo regs that live
across setjmp. Such pseudo regs won't be allocated to hard regs, so use of
auto-inc addressing modes isn't profitable here anyways. I think this is a
much better idea. Unfortunately, it can't be easily implemented, as we can
perform auto-inc optimizations before regs_live_at_setjmp is set. We would
need another update_life_info call to do this. Not clear if this is
worthwhile. I think it is worth investigating though.
Another alternative is to just remove the warning code. Most warnings emitted
by this code are probably spurious. This may not be a viable solution though,
since the warnings are actually useful on some occasions, and the lack of
warnings for problematic code could be considered a regression. This is
probably not feasible.
--
wilson at gcc dot gnu dot org changed:
What|Removed |Added
CC| |wilson at gcc dot gnu dot
||org
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21059
[Bug middle-end/21059] Bogus warning about clobbered variable
--- Comment #5 from wilson at gcc dot gnu dot org 2005-12-02 04:12 --- Created an attachment (id=10387) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=10387&action=view) Delay auto-inc generation until after determining which regs live across setjmp. This is my proposed untested patch. While writing this, I realized that we have an actual optimization bug here, in addition to the spurious warning problem. ISO C says that if a variable is not set in between setjmp and longjmp, then its value is preserved by the longjmp. GCC implements this by forcing all such variables into stack slots. Now suppose we have code like this, where reg100 is a user variable. (set reg100 ...) (call setjmp) ... (mem reg100) ... (set (reg101) (plus (reg100) (const_int 8))) ... (mem reg101) ... (call longjmp) The value of reg100 should be unchanged. On IA-64 however, gcc converts this code to (set reg100 ...) (call setjmp) ... (mem (post_inc (reg100) (const_int 8)) ... ... (mem reg101) ... (call longjmp) and now the value of reg100 is being modified, which violates the ISO C spec. If program execution can return to the mems after the longjmp, then the code will not function correctly. The wrong values will be read from memory. This could be a very hard bug to diagnose if it occured in real programs, and if the longjmp call was in an exception path that rarely occured. There is also an addition problem here that performing auto-inc optimization on variables that are forced to stack slots is a de-optimization, as now we need an additional memory store that we did not need before. Without my patch, I get ld8 r14 = [r15] ;; adds r14 = 8, r14 ;; st8 [r15] = r14 adds r14 = -8, r14 ;; ld8 r34 = [r14], 8 ;; ld8 r33 = [r14] with my patch I get ld8 r15 = [r15] ;; ld8 r33 = [r15] adds r14 = 8, r15 ;; ld8 r34 = [r14] which is much better. Not all cases are as lucky as this though. In some cases the use of auto-inc addresses would have been better. Since this only affects functions that call setjmp, it shouldn't be a serious problem. One more note, I noticed that we are setting regs_live_at_setjmp, but never clearing it. This means it could contain more registers than it should. But since this only affects functions that call setjmp, I'm not going to worry about it. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21059
[Bug middle-end/21059] Bogus warning about clobbered variable
--- Comment #6 from wilson at gcc dot gnu dot org 2005-12-02 19:16 --- Oops. That patch should have a "| PROP_AUTOINC" in the new update_life_info call. That would explain why I was seeing some unexpected de-optimizations with the patch. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21059
[Bug target/24934] [4.1/4.2 Regression] profilebootstrap failure
--- Comment #19 from wilson at gcc dot gnu dot org 2005-12-06 05:31 --- Subject: Bug 24934 Author: wilson Date: Tue Dec 6 05:31:39 2005 New Revision: 108103 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108103 Log: PR target/24934 * opts.c (decode_options): Turn off partitioning if flag_unwind_tables is set. Modified: trunk/gcc/ChangeLog trunk/gcc/opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24934
[Bug target/24934] [4.1/4.2 Regression] profilebootstrap failure
--- Comment #20 from wilson at gcc dot gnu dot org 2005-12-06 05:41 --- Subject: Bug 24934 Author: wilson Date: Tue Dec 6 05:41:33 2005 New Revision: 108104 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=108104 Log: PR target/24934 * opts.c (decode_options): Turn off partitioning if flag_unwind_tables is set. Modified: branches/gcc-4_1-branch/gcc/ChangeLog branches/gcc-4_1-branch/gcc/opts.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24934
[Bug target/24934] [4.1/4.2 Regression] profilebootstrap failure
--- Comment #21 from wilson at gcc dot gnu dot org 2005-12-06 05:55 --- Fixed on mainline and the gcc-4.1 branch. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24934
[Bug target/28495] [4.2 regression] ICE in final_scan_insn, at final.c:2448
--- Comment #10 from wilson at gcc dot gnu dot org 2006-08-04 01:49 --- This is the same bug as PR 28490. I verified that my prototype patch for PR 28490 fixes it. *** This bug has been marked as a duplicate of 28490 *** -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28495
[Bug target/28490] [4.0/4.1/4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #13 from wilson at gcc dot gnu dot org 2006-08-04 01:49 --- *** Bug 28495 has been marked as a duplicate of this bug. *** -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug target/28490] [4.0/4.1/4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #14 from wilson at gcc dot gnu dot org 2006-08-04 01:55 --- Steve Ellcey posted a patch here: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00016.html I posted a better patch here: http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00054.html This patch has not been tested yet. There are also some follow up questions raised in this thread that need to be answered. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug target/28490] [4.0/4.1/4.2 regression] ICE in ia64_expand_move, at config/ia64/ia64.c:1088
--- Comment #17 from wilson at gcc dot gnu dot org 2006-09-15 23:05 --- Subject: Bug 28490 Author: wilson Date: Fri Sep 15 23:05:40 2006 New Revision: 116983 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=116983 Log: Short term fix for PR 28490. * config/ia64/ia64.c (ia64_legitimate_constant_p, cast CONST): Handle symbol offsets same as they are handled in ia64_expand_move and move_operand. Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/ia64.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28490
[Bug middle-end/18071] [4.0/4.1/4.2 Regression] -Winline does not respect -fno-default-inline
--- Comment #24 from wilson at gcc dot gnu dot org 2006-10-02 19:23 --- Created an attachment (id=12372) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12372&action=view) improved patch for inline warning Works for simple testcases. Needs full bootstrap regression test. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18071
[Bug c/30592] New: -fmudflap and -Wnested-externs conflict
Using both -fmudflap and -Wnested-externs generates spurious errors. localhost$ touch tmp.c localhost$ gcc -fmudflap -Wnested-externs -S tmp.c :0: warning: nested extern declaration of __mf_lookup_cache :0: warning: nested extern declaration of __mf_lc_shift :0: warning: nested extern declaration of __mf_lc_mask :0: warning: nested extern declaration of __mf_check :0: warning: nested extern declaration of __mf_register :0: warning: nested extern declaration of __mf_unregister :0: warning: nested extern declaration of __mf_init :0: warning: nested extern declaration of __mf_set_options cc1: error: mf-runtime.h: No such file or directory You can ignore the mf-runtime.h error. The ones I'm concerned about here are all of the false nested extern warnings. I can reproduce the problem with all gcc versions from 4.0.x to mainline 4.3. This problem exists only with the C (and maybe C++) front end because of how the C front end handles scoping. The problem here is that the function mudflap_init creates some variables via pushdecl. However, the C front end has an implicit assumption that no variables will be created until after we start parsing, at which time push_file_scope is called. Since mudflap creates variables before push_file_scope is called, they end up being placed in the wrong scope, and the C front end gets confused and emits the warning. A possible solution is to add a builtin_variable hook similar to the existing builtin_function hook. Note that the C front end builtin_function hook calls bind directly, instead of calling pushdecl which then calls bind. A builtin_variable hook could do something similar which would solve the problem. There are also other simpler but less elegant ways to solve the problem. We could mark these mudflap variables with the DECL_IN_SYSTEM_HEADER bit to disable the -Wnested-externs warning for them. Or we could maybe disable the warning for variables in the external_scope, which I think can only happen in this case, though I haven't tried to verify that. -- Summary: -fmudflap and -Wnested-externs conflict Product: gcc Version: 4.3.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: wilson at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30592
[Bug target/30687] undocumented attributes on ia64
--- Comment #1 from wilson at gcc dot gnu dot org 2007-02-05 22:10 --- Model and version_id are already documented. It is only syscall_linkage that is undocmented, and that would be my fault. Meanwhile, you can find info about it in the gcc sources, in the file gcc/config/ia64/ia64.c. The overlapping register windows implemented by the IA-64 architecture can cause kernel internal data to leak out to user processes if one is not careful. The syscall_linkage attribute modies the ABI slightly to prevent this, and it should be used on user entry points to the kernel. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-02-05 22:10:56 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30687
[Bug c/31233] obstack.h typo
--- Comment #2 from wilson at gcc dot gnu dot org 2007-03-19 21:32 --- In theory, obstack.h is imported from the FSF gnulib package, though unfortunately that isn't documented in our codingconventions.html web page, and it looks like people have just been modifying it in place. The parent package is here http://savannah.gnu.org/projects/gnulib#options Looking at the cvs history, it looks like this was broken in revision 1.24 and fixed in revision 1.32, so we should be able to import a fixed version of this file to fix this bug report. Except that we will have to deal with local changes somehow. They really should be pushed to the FSF is they aren't already there. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-19 21:32:30 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31233
[Bug c/31273] Erroneous bitfield conversions to boolean values
--- Comment #1 from wilson at gcc dot gnu dot org 2007-03-19 23:49 --- I'm not a C++ expert, so I'm not the right person to say for sure, but this looks like an accidental bug to me. There were patches added to change the bitfield type representation, the is_bitfield_expr_with_lowered_type change, which is for PR 26534. I believe these patches have a bug. It looks to me like the bug is in standard_conversion in cp/calls.c at these lines if (bitfield_type) from = strip_top_quals (bitfield_type); This sets from, but fails to set fcode, resulting in an inconsistency. In this case, fcode is INTEGER_TYPE and from is now an enumeral type after originally being an integer type. This causes a failure further down in the tcode == BOOLEAN_TYPE code where we fail to match the conditions due to this inconsistency. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31273
[Bug c/31273] Erroneous bitfield conversions to boolean values
--- Comment #2 from wilson at gcc dot gnu dot org 2007-03-19 23:52 --- Created an attachment (id=13236) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13236&action=view) proposed cp/call.c patch for suspected standard_conversion bug This is the proposed patch I referred to in my analysis. It works for the testcase, but has not otherwise been tested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31273
[Bug debug/31230] debug information depends on gc parameters
--- Comment #2 from wilson at gcc dot gnu dot org 2007-03-30 22:44 --- I can reproduce the problem using the provided testcase. It looks like all we have to do is mark the array type TYPE_DOMAIN as used, to prevent it from being garbage collected. This just requires adding an equate_type_number_to_die call, which should be harmless by itself, I think. This solves the problem for the provided testcase. I haven't done a bootstrap or gdb testsuite run to test the patch yet. It might be nice to try to reuse this info, via lookup_type_die, now that we have saved it. Unfortunately, the dwarf3 standard doesn't have any provision for this. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC| |wilson at gcc dot gnu dot | |org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-30 22:44:06 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31230
[Bug debug/31230] debug information depends on gc parameters
--- Comment #3 from wilson at gcc dot gnu dot org 2007-03-30 22:49 --- Created an attachment (id=13304) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13304&action=view) Add equate_type_number_to_die call to prevent garbage collection. This patch is untested, but works for the testcase in the bug report. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31230
[Bug bootstrap/31235] Bootstrap comparison failure with -gstabs
--- Comment #2 from wilson at gcc dot gnu dot org 2007-03-31 02:23 --- I was able to reproduce this on an x86_64-linux machine following the instructions. Assuming this is the same conceptual problem as 31230, I tried the same patch, in another file. Just marking the array type domain type as used so it wouldn't be garbage collected. It was a little harder here since we didn't have a convenient subroutine to call, so I had to move some code out of dbxout_type into a new function, but effectively there is only a one line actual code change here. This survived a C-only BOOT_CFLAGS=-gstabs bootstrap, which seems to be good evidence that it is working. This patch is otherwise untested. It needs a full bootstrap, gcc testsuite run, and gdb testsuite run. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-03-31 02:23:00 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31235
[Bug bootstrap/31235] Bootstrap comparison failure with -gstabs
--- Comment #3 from wilson at gcc dot gnu dot org 2007-03-31 02:24 --- Created an attachment (id=13305) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13305&action=view) Mark array TYPE_DOMAIN as used to prevent garbage collection. This has been tested with a C only BOOT_CFLAGS=-gstabs bootstrap. It needs a full bootstrap, gcc testsuite run, and gdb testsuite run. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31235
[Bug target/33532] bogus escape
--- Comment #5 from wilson at gcc dot gnu dot org 2007-09-24 22:53 --- Echoing what Andrew Pinski already said, this isn't C code, this is RTL code, the format of which is specified by the read-rtl.c file. Specifically, see the read_brace_string function, which accepts backslash quoting exactly the same as the read_quoted_string function. Unless you are proposing a change to the read_brace_string function, there is nothing wrong with this code. Though I will admit that the backslashes are unnecessary here and could optionally be removed without harm. If you are proposing changes to the read_brace_string function, it would have been nice to mention that. If you want to find all such problems, changing this function is probably the easiest way to do that. If you want to prevent such problems from being reintroduced later, then you would definitely have to change this function. Maybe add an argument to the read_escape function so that we can handle calls from read_quoted_string differently than calls from read_brace_string? I have no idea at the moment why this matters to you. A little context might be helpful. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot | |org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-09-24 22:53:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33532
[Bug tree-optimization/33655] [4.3 Regression] ICE in bitfield_overlaps_p, at tree-sra.c:2901
--- Comment #7 from wilson at gcc dot gnu dot org 2007-10-08 22:19 --- Created an attachment (id=14324) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14324&action=view) add another conversion to bitsizetype Here is an patch to fix the IA-64 failure for this testcase. This makes the testcase work (i.e. gcc doesn't ICE), but has not been otherwise tested as yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=33655
[Bug tree-optimization/18977] [4.0 regression] LAPACK test xeigtsts segfaults with optimization
--- Additional Comments From wilson at gcc dot gnu dot org 2005-02-18 20:53 --- This is a tree-optimization problem not a target problem. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Component|target |tree-optimization Last reconfirmed|2005-02-12 04:00:42 |2005-02-18 20:53:32 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977
[Bug tree-optimization/18977] [4.0 regression] LAPACK test xeigtsts segfaults with optimization
--- Additional Comments From wilson at gcc dot gnu dot org 2005-02-18 23:11 --- As previously noted, it was fixed by a patch from Zdenek Dvorak which had no testcase. This testcase has been added, and this bug report can be closed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Known to fail|4.0.0 | Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977
[Bug fortran/5900] [g77 & gfortran] Lapack regressions since g77 2.95.2
-- Bug 5900 depends on bug 18977, which changed state. Bug 18977 Summary: [4.0 regression] LAPACK test xeigtsts segfaults with optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977 What|Old Value |New Value Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5900
[Bug fortran/19292] [meta-bug] g77 features lacking in gfortran
-- Bug 19292 depends on bug 18977, which changed state. Bug 18977 Summary: [4.0 regression] LAPACK test xeigtsts segfaults with optimization http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18977 What|Old Value |New Value Status|UNCONFIRMED |NEW Status|NEW |ASSIGNED Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19292
[Bug target/19724] ICE when building a m68hc11 cross-compiler on ia64
--- Additional Comments From wilson at gcc dot gnu dot org 2005-02-20 00:34 --- I built an m68hc11 cross compiler from mainline, last updated Thursday, without binutils/newlib, on an IA-64 Debian unstable system whose system compiler is gcc-3.3.5 (Debian 1:3.3.5-2). The result can compile your testcase with -S, -O -S, and -O2 -S. I do not get any ICE. There is some ambiguity in this bug report. It requires building a m68hc11 cross compiler, but does not specify the sources used for this cross compiler. It includes a testcase, but does not give the compiler options used to compile it. There may also be other things missing that are relvent. I can't help fix a problem if I can't reproduce it. I suggest that you try being more precise about what exactly you did to produce the error. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19724
[Bug middle-end/20364] [3.4 Regression] Segfault with -Xpreprocessor argument
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-08 20:53 --- Hint taken. I'm testing the patch with gcc-3.4, and then will check it in if there are no problems. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-03-07 18:58:59 |2005-03-08 20:53:54 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20364
[Bug middle-end/20364] [3.4 Regression] Segfault with -Xpreprocessor argument
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-09 01:10 --- Fix by the patch I just checked in. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20364
[Bug middle-end/20217] Switching off the optimization triggers undefined reference at link time when building Linux kernel.
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-10 02:48 --- The linux kernel requires optimization to be correctly compiled. This is a deliberate design decision by the linux kernel developers. Part of the reason is the kernel's use of extern inline as already mentioned. If used as intended, extern inline works without -O. The linux kernel however slightly abuses the feature in the interest of reducing kernel code size, thus resulting in code that can't be compiled correctly without -O. I believe there is also another issue. I think there is a process creation routine that takes advantage of the fact that gcc won't create a stack frame with optimization in a leaf routine, thus allowing them to have C code to set the initial stack pointer for the new process. Normally, setting the stack pointer would cause all kinds of havoc, but it works in this one special case, and it only works if you compile with optimization. I don't recall exactly where I saw this trick, but I think it was in the linux kernel. Anyways, a linux kernel developer could answer these kinds of questions better than a gcc developer. There may be other reasons why they require optimization. -- What|Removed |Added Status|WAITING |RESOLVED Resolution||INVALID http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20217
[Bug preprocessor/20281] [3.4 Regression] cpp segfaults on directory input
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-10 04:47 --- The segfault is the same problem as PR 20364, which I fixed on the gcc-3.4 branch two days ago. The error message problem is now PR 20285. So closing as a duplicate. *** This bug has been marked as a duplicate of 20364 *** -- What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20281
[Bug middle-end/20364] [3.4 Regression] Segfault with -Xpreprocessor argument
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-10 04:47 --- *** Bug 20281 has been marked as a duplicate of this bug. *** -- What|Removed |Added CC||marcolz at stack dot nl http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20364
[Bug driver/13464] -i8 and -r8 not passed correctly to compiler proper. and -d8 does not work
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-11 05:31 --- See http://gcc.gnu.org/ml/gcc/2005-03/msg00513.html for relevant comments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=13464
[Bug middle-end/11375] rtl_dump_file problems in rest_of_compilation
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-13 01:32 --- This open_dump_file change looks like a sufficient solution to me. That prevents us from accidentally trying to open two dump files at the same time. The equivalent problem with close_dump_file is not serious, and unlikely to happen without triggering the open_dump_file abort, so I don't think it needs a solution. -- What|Removed |Added Status|NEW |RESOLVED Known to work||4.0.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11375
[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-13 03:11 --- Dan's example doesn't work because 'int' is a predefined type. Use a unique structure type put the function call back in the inline function, and I get a nice little example (22 lines) that can reproduce the problem. If I compile it with ./xgcc -B./ -O -g tmp.cc and then run gdb on the a.out file, I get a gdb internal error. Looking at the debug info, I now have 4 DIEs for the variable i. There are the same 3 as Dan's example, plus a fourth one, with global scope, that has the abstract origin pointing back at the declaration inside the inline function. It is this fourth one that confuses gdb. This is using mainline, last updated Thursday March 10, on an x86-64 linux machine. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769
[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-16 03:46 --- I confirmed that I don't see the problem if I compile with -m32 on a x86-64 system. This happens with 32-bit x86 code because update_equiv_regs deletes and reinserts the instruction that loads the value of the variable i. This causes us to lose the block info for this insn, as block info is based on insn uid. This does not happen for 64-bit code because CLASS_LIKELY_SPILLED_P is true for the register destination. For 32-bit code, the register has a preferred class of GENERAL_REGS, and for 64-bit code, the register has a preferred class of DIREG_CLASS. So the 32-bit x86 case doesn't fail because we lost some debug info. I can make the 32-bit case fail by adding the -fpic option, which prevents update_equiv_regs from optimizing this instructions. So ./xgcc -B./ -O -g -fpic -m32 tmp.cc reproduces the problem for me on an x86_64 machine. It should do likewise on a 32-bit machine, without the -m32 option. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769
[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-16 03:54 --- Part of the problem here is the way that declare_in_namespace works. gen_variable_die, calls declare_in_namespace, which checks to see if the variable has a namespace, and if so emits it into that namespace. declare_in_namespace then returns, and gen_variable_die finishes normally, which means we end up with DIEs for one variable. The local one in the current context, and the one emitted into the namespace. The variable in question here has a namespace of "::". When we process the abstract instance of f, we emit a local die for i into f, and a namespace one into :: the global context. This one has line 3. Then we see the global redeclaration, and emit another die into the global context. This one has line 6. Then when we handle the function main, we see the inlined version of f, and we get a decl of i with an abstract origin pointing at the function f, and emit two more dies, one local one in the inlined version of f that points at the abstract instance of f, and one global one that also points at the abstract instance of f. This last one is very wrong. Note that there are 5 dies not 4 as I claimed earlier, I missed the one in 'main' when I was counting them. It seems very silly to try to emit a namespace version of a decl with an abstract origin. One possible solution is for declare_in_namespace to ignore any decl with an abstract origin. If I try this, I get only 4 dies, and gdb is happy. We still have two global dies, with different line numbers, but we can live with that for now. I haven't yet tried to trace the history of this, to determine what change caused the problem to appear. There might be something else wrong here. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769
[Bug debug/20268] With optimization, generating incomplete debug information
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-18 05:11 --- Created an attachment (id=8414) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=8414&action=view) use DW_AT_ranges in DW_AT_inlined_subroutine Using -dA will add comments to the debug info in the .s file. This is easy for gcc hackers to create and read. I tried looking at one of the problems with your example. I picked the tmp.cc:8 line, which is followed by a line from stl_vector.h:221 which claims to be in function main. Looking at the .s file, I see that there are two LBBX/LBEX block labels around the instruction, but no debug info that refers to these block labels. Investigating, I find that the situation is as Dan described earlier. We have DW_AT_ranges support, but only for lexical blocks, not for inlined subroutine blocks. This is trivial to fix. The patch I am attaching to the pr does this. Recompiling, the .s file looks reasonable now, the stray insn now is inside a block that is in the DW_AT_ranges of a DW_AT_inlined_subroutine which should give the result we want. Trying addr2line again, I see no difference, but this turns out to be a bfd issue. The scan_unit_for_functions code in bfd/dwarf2.c handles DW_AT_lo_pc and DW_AT_high_pc, but not DW_AT_ranges, which means it is not able to find this block when it checks address ranges. Presumably this is something you can fix. Without DW_AT_ranges support here, my patch will likely make things worse than they already are. With DW_AT_ranges support here, my patch should make things better. There is also the issue of whether gdb will be happy with this. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20268
[Bug c++/19769] [4.0/4.1 Regression] GCC produces wrong dwarf2 output that breaks gdb
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-18 06:05 --- I got four additional gdb testsuite failures with the patch. I will have to figure out what went wrong, and then rebuild and retest. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769
[Bug c++/19769] [4.0 Regression] GCC produces wrong dwarf2 output that breaks gdb
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-23 03:15 --- May as well take it, seeing as how I wrote a patch for it. The gdb failures do not seem related to my change, and when I reran the gdb testsuite, they disappeared. I don't know what happened, but as far as I am concerned the patch has passed the test and I'm checking it in. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-02-02 23:50:07 |2005-03-23 03:15:13 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769
[Bug c++/19769] [4.0 Regression] GCC produces wrong dwarf2 output that breaks gdb
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-23 03:20 --- My net connection died when trying to check in the patch, and it was a Friday evening... I'm a little surprised that the mainline check in actually worked. I thought it hadn't. I've also added it to the 4.0 branch now. Fixed on mainline and the gcc-4.0 branch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19769
[Bug target/20286] [3.3 only] gcc panic with __thread attribute
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-24 00:09 --- That patch that fixed this in gcc-3.4 is too large to backport, particularly when considering that it depends on other stuff (such as default_encode_section_info) which is not already present in gcc-3.3. However, it can be fixed with a simpler patch. The underlying problem is that a variable changes state from TLS_MODEL_INTIAL_EXEC (extern) to TLS_MODEL_LOCAL_EXEC (static). This is an allowable transition. This unfortunately triggers an abort in the ia64.c backend in ia64_encode_section_info. The comment next to the abort makes it clear that this is checking for transitions between thread data and small data. So the fix is to tighten the conditions under which we call the abort to match the conditions documented in the comments. The same INITIAL_EXEC to LOCAL_EXEC transition happens in gcc-3.4, there just isn't a corresponding abort in default_encode_section_info. Technically, this isn't a regression, as gcc-3.2 did not have TLS support, and gcc-3.3 is only open for regression fixes, so there is the question of whether this patch is OK to install on the branch. A strict interpretation of the rules says this is not OK, at least not without approval of the branch maintainer, Gaby. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-03-02 16:48:16 |2005-03-24 00:09:55 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20286
[Bug middle-end/19225] [3.4/4.0/4.1 regression] g++.dg/eh/omit-frame-pointer2.C fails with -fpic/-fPIC on i686-pc-linux-gnu
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-24 20:37 --- See http://gcc.gnu.org/ml/gcc/2005-03/msg01081.html This fails because exception handling and -fdefer-pop don't work well together. The easy solution is to disable the defer pop optimization when we have function calls that can throw. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19225
[Bug target/20286] [3.3 only] gcc panic with __thread attribute
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-28 22:40 --- The patch passed testing, and has been submitted to gcc-patches here: http://gcc.gnu.org/ml/gcc-patches/2005-03/msg02542.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20286
[Bug target/20286] [3.3 only] gcc panic with __thread attribute
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-29 00:33 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Known to work|3.4.0 4.0.0 |3.4.0 4.0.0 3.3.6 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20286
[Bug c++/20505] [4.0/4.1 Regression] internal error when compiling with -ggdb2 and no error with -ggdb1
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-30 02:16 --- See http://gcc.gnu.org/ml/gcc/2005-03/msg01274.html for comments. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20505
[Bug target/20670] IA-64 exception mechanism erase $f29
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-30 03:40 --- Egads. Register corruption when unwinding. This looks like a serious problem. Not a regression, but I'm tempted to try to fix it in every current release. A work around is to use the libunwind package instead. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-30 03:40:37 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20670
[Bug debug/20268] With optimization, generating incomplete debug information
-- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-03-30 23:08:11 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20268
[Bug debug/20268] With optimization, generating incomplete debug information
--- Additional Comments From wilson at gcc dot gnu dot org 2005-03-30 23:18 --- Fixed. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20268
[Bug target/20632] GCC should avoid generating F- and B-unit NOPs
--- Additional Comments From wilson at gcc dot gnu dot org 2005-04-01 01:35 --- IA-64. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-01 01:35:08 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20632
[Bug target/20632] GCC should avoid generating F- and B-unit NOPs
--- Additional Comments From wilson at gcc dot gnu dot org 2005-04-01 01:35 --- Fixed by Vlad's patch. -- What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED Target Milestone|--- |4.1.0 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20632
[Bug c++/20505] [4.0/4.1 Regression] internal error when compiling with -ggdb2 and no error with -ggdb1
--- Additional Comments From wilson at gcc dot gnu dot org 2005-04-01 04:04 --- Fixed on mainline. Still needs to be fixed on the gcc-4.0 branch, which I assume Nathan is doing. I had to back off a bit from my earlier plans. Aggregate types and constructor initializers pose complications that don't appear to be worth fixing, so I only handle integral types, scalar real types, and STRING_CST. I commonized the code in rtl_for_decl_location and tree_add_const_value_attribute so that they both work the same. The testcase by the way isn't portable. It requires that int and pointer be the same size. I had to do s/int/long to make it work on my ia64 and x86_64 systems. But still that assumes long and pointers are the same size which is not true for all ABIs supported by all targets. This is why I didn't already add the testcase to the testsuite on mainline. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20505
[Bug other/19180] How to Add New GCC option
--- Additional Comments From wilson at gcc dot gnu dot org 2005-04-04 21:38 --- See also a thread on the gcc list http://gcc.gnu.org/ml/gcc/2005-03/msg00234.html -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19180
[Bug target/20717] [4.1 Regression] Many C++ testsuite failures on ia64-hpux
--- Additional Comments From wilson at gcc dot gnu dot org 2005-04-05 04:04 --- The patch seems to have been incompletely checked in. The ChangeLog entry claims to be removing code from final.c, but the code is still there. I laboriously tracked down the problem to the fact that cgraphunit handles ADDR_EXPR but not FDESC_ADDR. Hence, only targets that use function descriptors are affected. Like IA-64. -- What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed||1 Last reconfirmed|-00-00 00:00:00 |2005-04-05 04:04:14 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20717
[Bug target/20670] IA-64 exception mechanism erase $f29
--- Additional Comments From wilson at gcc dot gnu dot org 2005-04-05 04:22 --- Yes, that is the same patch I independently wrote and started testing over the weekend. It has already passed testing for the gcc-3.4 and gcc-4.0 branches. I have yet to do mainline and gcc-3.3 testing. Also, I have yet to seek approval for older branches, which I will be doing shortly. -- What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-03-30 03:40:37 |2005-04-05 04:22:47 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20670
[Bug c++/20805] Another debug info emitting bug
--- Additional Comments From wilson at gcc dot gnu dot org 2005-04-08 03:01 --- The testcase works if the variable declaration is moved after the function. This is the case I fixed a few weeks ago, which was breaking java debugging. The declare_in_namespace design causes us to get two DIEs for one declaration. The first DIE is in the variable namespace, and the second one is in the current context. When we emit the second one, lookup_decl_die in gen_variable_die will find the first one. It is important not to confuse this with a declaration followed by a definition, which requires DW_AT_specification. The difference between putting the definition before or after the function is whether DECL_STATIC is set. If it is declared before, DECL_STATIC is set. If it is declared after, DECL_STATIC is not set. So in first case we get DW_AT_specification which is wrong and confuses gdb, and in the second case we don't get DW_AT_specification, and gdb is happy. A possible way to resolve this is to add an addition check !declaration before emitting DW_AT_specification. The patch I am attaching to the PR does this, and works for Jakub's last reduced testcase. I haven't tried this with a bootstrap or make check or gdb make check yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20805
[Bug target/20670] IA-64 exception mechanism erase $f29
--- Additional Comments From wilson at gcc dot gnu dot org 2005-04-13 00:58 --- Fixed on all active release branches and mainline. -- What|Removed |Added Status|ASSIGNED|RESOLVED Known to work||3.3.6 3.4.4 4.0.0 Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20670
[Bug libgcj/28009] libjava cannot be cross-built; X_CFLAGS includes /usr/include
--- Comment #6 from wilson at gcc dot gnu dot org 2008-02-01 23:39 --- Configuring --without-x is a possible workaround. I haven't tried it. I also haven't tried to reproduce the problem. The problem comes from the AC_PATH_XTRA call in libjava/configure.ac. This is a documented autoconf feature to get info about X header files and libraries. So now we have to look in the autoconf sources. AC_PATH_XTRA calls AC_PATH_X. If X is enabled, and x_includes/x_libraries have not already been specified, then _AC_PATH_X is called. _AC_PATH_X then calls _AC_PATH_X_XMKMF. _AC_PATH_X_XMKMF then does something clever. It creates an Imakefile that just echos the value of some Imakefile variables, it runs xmkmf to convert the Imakefile into an X makefile, then it runs make to echo out the expanded values of the X Imakefile variable values, and uses them to set x_includes and x_libraries. The problem here of course is that xmkmf is a host tool, which is being run directly (i.e. no macro to override), and will always return paths valid on the host. Which is wrong for a cross compiler. Though I suppose we could try overriding the _AC_PATH_X_XMKMF function itself. I only took a quick look at this, so I don't know why this is breaking for some and working for others. Perhaps it matters whether you have X headers and libraries in your sysroot. Perhaps it matters whether you use a sysroot. It clearly does matter whether you have xmkmf installed on your host machine. If you don't have xmkmf installed (which is part of the imake package), then you presumably won't have this problem. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC| |wilson at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28009
[Bug testsuite/35512] [4.4 Regression]: gcc.target/ia64/visibility-1.c
--- Comment #2 from wilson at gcc dot gnu dot org 2008-03-18 04:02 --- Subject: Bug 35512 Author: wilson Date: Tue Mar 18 04:01:21 2008 New Revision: 133301 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133301 Log: PR testsuite/35512 * gcc.target/ia64/visibility-1.c (foo): Change return type to void. Write variables instead of reading them. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gcc.target/ia64/visibility-1.c -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35512
[Bug testsuite/35512] [4.4 Regression]: gcc.target/ia64/visibility-1.c
--- Comment #3 from wilson at gcc dot gnu dot org 2008-03-18 04:06 --- Mine. IA-64. -- wilson at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35512
[Bug testsuite/35512] [4.4 Regression]: gcc.target/ia64/visibility-1.c
--- Comment #4 from wilson at gcc dot gnu dot org 2008-03-18 04:06 --- Fixed. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35512
[Bug target/35695] [4.3/4.4 Regression] -funroll-loops breaks inline float divide
--- Comment #3 from wilson at gcc dot gnu dot org 2008-03-27 05:54 --- Created an attachment (id=15385) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15385&action=view) Itanium reciprocal approximation bug fix Untested patch produced with wrong (default) svn diff options. Should probably make the same change to the other recip approx patterns in ia64.md. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35695
[Bug target/35695] [4.3/4.4 Regression] -funroll-loops breaks inline float divide
--- Comment #6 from wilson at gcc dot gnu dot org 2008-03-31 19:52 --- Subject: Bug 35695 Author: wilson Date: Mon Mar 31 19:51:50 2008 New Revision: 133772 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=133772 Log: PR target/35695 * config/ia64/div.md (recip_approx_rf): Use UNSPEC not DIV. * config/ia64/ia64.c (rtx_needs_barrier): Handle UNSPEC_FR_RECIP_APPROX_RES. * config/ia64/ia64.md (UNSPEC_FR_RECIP_APPROX_RES): Define. Modified: trunk/gcc/ChangeLog trunk/gcc/config/ia64/div.md trunk/gcc/config/ia64/ia64.c trunk/gcc/config/ia64/ia64.md -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35695
[Bug target/35695] [4.3/4.4 Regression] -funroll-loops breaks inline float divide
-- wilson at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2008-03-31 20:22:40 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35695
[Bug middle-end/35781] [4.4 Regression]: Revision 133759 breaks ia64
--- Comment #4 from wilson at gcc dot gnu dot org 2008-04-01 02:54 --- Created an attachment (id=15400) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15400&action=view) patch for cfun->emit rtl.emit changes I tested this patch with a C only bootstrap on an ia64-linux system. The bootstrap completed successfully. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35781
[Bug target/35364] ICE on ia64 with vector declaration inside #pragma omp parallel
--- Comment #5 from wilson at gcc dot gnu dot org 2008-04-01 06:31 --- Created an attachment (id=15401) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15401&action=view) tree-eh.c optimize_double_finally patch This patch works for the testcase, but is otherwise untested. My knowledge in this area is limited, so this needs to be reviewed by someone with more tree-ssa and tree-eh knowledge than me. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35364
[Bug rtl-optimization/35785] gcc.c-torture/compile/pr11832.c doesn't work for Linux/ia64
--- Comment #2 from wilson at gcc dot gnu dot org 2008-04-03 06:27 --- Created an attachment (id=15418) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15418&action=view) ia64.h patch to define REGNO_OK_FOR_INDIRECT_JUMP_P Obvious definition of the REGNO_OK_FOR_INDIRECT_JUMP_P macro. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35785
[Bug rtl-optimization/35785] gcc.c-torture/compile/pr11832.c doesn't work for Linux/ia64
--- Comment #3 from wilson at gcc dot gnu dot org 2008-04-03 06:29 --- Created an attachment (id=15419) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15419&action=view) rtl-factoring.c patch to allocate second reg for IA-64 This allocates a second register if REGNO_OK_FOR_INDIRECT_JUMP_P is defined, and then adjusts the code appropriately to use the second reg. This obviously needs some cleanup, I didn't give it much thought. It seems to be working for the simple testcase though. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35785
[Bug target/35695] [4.3 Regression] -funroll-loops breaks inline float divide
--- Comment #7 from wilson at gcc dot gnu dot org 2008-04-07 23:48 --- Anyone care whether this gets fixed in 4.3? If so, are you willing to test it? I'll approve it for 4.3 with proper testing, which is not easy for me to do. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35695
[Bug target/31684] [4.3 Regression] ICE in get_attr_first_insn, at config/ia64/itanium2.md:1839 at -O2
--- Comment #1 from wilson at gcc dot gnu dot org 2007-05-01 01:53 --- It dies in recog because of an invalid extended asm insn rtl. In an asm with 2 or more outputs, we end up with 2 or more copies of the input vector. These vectors must be shared. They are not in this case. The problem occurs in haifa-sched, in the speculative instruction support. It uses copy_rtx to make a copy of an insn when speculatively scheduling it. However, copy_rtx does not preserve the special sharing semantics of asm operands, so the result is a corrupted insn. There exists a special routine copy_insn to solve this problem. So the solution here is to just replace the copy_rtx call with a copy_insn call. This works on mainline for this testcase but is not otherwise tested. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC||wilson at gcc dot gnu dot ||org Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-05-01 01:53:27 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31684
[Bug target/31684] [4.3 Regression] ICE in get_attr_first_insn, at config/ia64/itanium2.md:1839 at -O2
--- Comment #2 from wilson at gcc dot gnu dot org 2007-05-01 01:56 --- Created an attachment (id=13466) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13466&action=view) Replace copy_rtx call with copy_insn call. This works on mainline for the testcase, but has not otherwise been tested. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31684
[Bug target/32552] Runtime failure in SPEC CPU2000 benchmark fma3d and applu
--- Comment #7 from wilson at gcc dot gnu dot org 2007-07-02 20:34 --- Created an attachment (id=13831) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13831&action=view) enable INCOMING_RETURN_ADDR_RTX for ia64 This is a patch based on Kenny's suggestion. I think this patch solves the problem nicely, but it hasn't been tested with an ia64 build yet. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32552
[Bug target/24193] [4.1 Regression] ICE in extract_insn while compiling libgfortran
--- Comment #6 from wilson at gcc dot gnu dot org 2005-10-06 17:41 --- Loads can have post_increment addresses with an immediate or register increment. Stores can have post_increment address with only an immediate increment. We have a special predicate, destination_operand, that checks for this. Unfortunately, we haven't been using it consistently. And people who have noticed this problem have fixed only the one pattern that they noticed was broken, instead of fixing all of them. Scanning the md file, I see that movbi and movti_internal at least are broken. There may be more. I think gr_spill_internal is also broken. I'm off to a meeting and will have to finish this later. -- wilson at gcc dot gnu dot org changed: What|Removed |Added CC| |wilson at gcc dot gnu dot | |org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24193
[Bug target/24193] [4.1 Regression] ICE in extract_insn while compiling libgfortran
--- Comment #10 from wilson at gcc dot gnu dot org 2005-10-07 19:57 --- Mine. IA-64. -- wilson at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|NEW |ASSIGNED Last reconfirmed|2005-10-04 18:17:34 |2005-10-07 19:57:46 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24193
[Bug target/24193] [4.1 Regression] ICE in extract_insn while compiling libgfortran
--- Comment #11 from wilson at gcc dot gnu dot org 2005-10-07 19:58 --- Fixed on mainline. -- wilson at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24193
[Bug target/23644] IA-64 hardware models and configuration options documentation error for 3.4.x and 4.0.x
--- Comment #5 from wilson at gcc dot gnu dot org 2005-10-08 00:25 --- Mine. IA-64. Confirmed. A typo in the patch adding docs for this option. -- wilson at gcc dot gnu dot org changed: What|Removed |Added AssignedTo|unassigned at gcc dot gnu |wilson at gcc dot gnu dot |dot org |org Status|UNCONFIRMED |ASSIGNED Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2005-10-08 00:25:17 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=23644
