--- Comment #51 from seongbae dot park at gmail dot com 2008-01-17 21:31
---
Subject: Re: [4.3 regression] bad interaction between DF and SJLJ exceptions
In df_live_transfer_function:
Doesn't look like we need df_live_scratch - can't we do:
bitmap_and (out, gen, bb_lr_info-out
--- Comment #52 from seongbae dot park at gmail dot com 2008-01-17 22:31
---
Subject: Re: [4.3 regression] bad interaction between DF and SJLJ exceptions
I just talked to Kenny on the phone, and my suggestion is wrong
since it changes the return value - doing my naive suggestion
--- Comment #12 from seongbae dot park at gmail dot com 2007-10-08 20:18
---
Subject: Re: [4.3 Regression] Revision 128957 miscompiles 481.wrf
Please remove the extra blank line above the line 984 (in new file).
This patch is OK.
Seongbae
On 10/7/07, Kenneth Zadeck [EMAIL PROTECTED
--- Comment #22 from seongbae dot park at gmail dot com 2007-07-26 17:56
---
Subject: Re: [4.3 regression]: gfortran.dg/auto_array_1.f90
On 7/26/07, Kenneth Zadeck [EMAIL PROTECTED] wrote:
Seongbae Park (???, ???) wrote:
On 7/26/07, Kenneth Zadeck [EMAIL PROTECTED] wrote
--- Comment #20 from seongbae dot park at gmail dot com 2007-07-26 17:27
---
Subject: Re: [4.3 regression]: gfortran.dg/auto_array_1.f90
On 7/26/07, Kenneth Zadeck [EMAIL PROTECTED] wrote:
This patch extends the fix in
http://gcc.gnu.org/ml/gcc-patches/2007-06/msg01557.html
to bogus line number
in coverage.
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: seongbae dot park
--- Comment #2 from seongbae dot park at gmail dot com 2006-12-19 06:58
---
Yes, it looks like duplicate, although PR 15369 is against 3.4.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30257
--- Comment #5 from seongbae dot park at gmail dot com 2006-10-13 02:27
---
A modified and valid case which doesn't cause ICE:
template typename LHS, typename RHSbool operator( LHS lhs, RHS rhs );
struct ComputedAttribute {
int descriptor();
};
class AttributeDescriptor
--- Comment #6 from seongbae dot park at gmail dot com 2006-10-05 05:00
---
For example:
# cat m.c
int todouble(double a, double b) {
return (int)(a+b);
}
#
With 4.1.0 i686-unknown-linux-gnu target:
# gcc -O2 m.c -S
# cat m.s
...
.type todouble, @function
todouble
Component: target
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: seongbae dot park at gmail dot com
GCC host triplet: i686-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29337
--- Comment #2 from seongbae dot park at gmail dot com 2006-10-03 23:37
---
(In reply to comment #1)
(In reply to comment #0)
This makes a difference if/when the extra precision of 387 makes difference
for an extra prescision try to use a `long double'.
I'm afraid you're
--- Comment #5 from seongbae dot park at gmail dot com 2006-07-23 17:27
---
It seems that you didn't change libgcov.c,
which suggests that you didn't address __gcov_{pow2,interval}_profiler.
Without such change, -fprofile-generate will cause the mismatch between
the value counters
--- Comment #1 from seongbae dot park at gmail dot com 2006-06-26 20:46
---
I belive this is a bug in stor-layout.c:place_field() around line 10503
bitpos is calculated as bit_offset of rli-prev_field + type size.
However, the prev_field is not really the immediately previous field
--- Comment #2 from seongbae dot park at gmail dot com 2006-06-26 20:47
---
Oops. Mu previous comment is misplaced. It should have been on PR28161.
Please ignore it.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28160
--- Comment #1 from seongbae dot park at gmail dot com 2006-06-26 20:47
---
I belive this is a bug in stor-layout.c:place_field() around line 10503
bitpos is calculated as bit_offset of rli-prev_field + type size.
However, the prev_field is not really the immediately previous field
--- Comment #3 from seongbae dot park at gmail dot com 2006-06-26 21:08
---
The immediate cause of the problem is in stor-layout.c:place_field():
1118 if (DECL_SIZE (field) != NULL
1119host_integerp (TYPE_SIZE (TREE_TYPE (field)), 0)
1120
--- Comment #2 from seongbae dot park at gmail dot com 2006-06-26 21:10
---
More specifically:
1048 if (rli-remaining_in_alignment bitsize)
1049 {
1050 /* out of bits; bump up to next 'word'. */
1051 rli
--- Comment #4 from seongbae dot park at gmail dot com 2006-06-26 23:41
---
You're correct -I've overlooked the type mismatch.
One question though is the local variable type of place_field() is
TREE_TYPE (field), not DECL_BIT_FIELD_TYPE (field).
I'm not familiar with gcc type system
--- Comment #3 from seongbae dot park at gmail dot com 2006-06-23 18:26
---
I'm able to reproduce the problem with 4.2.0 on linux/x86.
valgrind-3.2.0/memcheck/mc_main.c has
359 static AuxMapEnt hacky_auxmaps[N_AUXMAPS];
...
362 static AuxMapEnt* auxmap = hacky_auxmaps
--- Comment #4 from seongbae dot park at gmail dot com 2006-06-23 18:43
---
The problem is causedby the extra DW_AT_const_value.
4.1.0 generates the following dwarf entry for auxmap:
1a30c: Abbrev Number: 31 (DW_TAG_variable)
DW_AT_name: (indirect string, offset: 0x35e
--- Comment #5 from seongbae dot park at gmail dot com 2006-06-23 23:55
---
Looks like this indeed is a duplicate of 27657.
In toplev.c:
1013 cgraph_varpool_assemble_pending_decls ();
...
1040 (*debug_hooks-finish) (main_input_filename);
dwarf2 finish ends up calling
21 matches
Mail list logo
