Hi all,
Can gatekeeper help review following fix for bug833?
https://bugs.open64.net/show_bug.cgi?id=833
case:
struct in6_addr
{
unsigned char u6_addr8[16];
};
static const struct ip6addrlbl_init_table
{
const struct in6_addr *prefix;
int prefixlen;
} array_table =
{
.prefix = &(struct in6_addr)
Looks fine to me.
2011/8/24 朱庆
> Hi all,
> Can gatekeeper help review following fix for bug833?
> https://bugs.open64.net/show_bug.cgi?id=833
> case:
> struct in6_addr
> {
> unsigned char u6_addr8[16];
> };
>
> static const struct ip6addrlbl_init_table
> {
> const struct in6_addr *prefix;
> int
Hi all,
Can gatekeeper help review following fix for bug832?
https://bugs.open64.net/show_bug.cgi?id=832
small case, a.c:
struct obs_kernel_param {
const char *str;
};
const char str1[] = "acpi_parse_apic_instance=";
const char str2[] = "acpi_os_name";
struct obs_kernel_param var1
__attribute
can you send me the full symtab_defs.h?
Sun
On Wed, Aug 24, 2011 at 4:56 PM, 朱庆 wrote:
> Hi all,
>
> Can gatekeeper help review following fix for bug832?
> https://bugs.open64.net/show_bug.cgi?id=832
>
> small case, a.c:
> struct obs_kernel_param {
> const char *str;
> };
>
> const char str1[] =
All,
I have a query on the symbols(symbol #51 and symbol #53) open64
is creating for the " derived-type":
>>
MODULE module_quilt_outbuf_ops
TYPE varpatch
INTEGER, POINTER :: rptr
END TYPE varpatch
TYPE(varpatch) :: derived_type
END MODULE module_quilt_outbuf_ops
>>
Compile
Hi,
Could a gatekeeper please review the attached patch.
This patch fixes a problem in load folding optimization where the memory
location used in the load operation
is overwritten by a store operation. A check is added to prevent folding of
such load operations.
The test-case and the patch
Hi Yong-Chong,
I'm OK with your fix. It's better if you could get review from SL (or others).
Thanks,
Min
On Tue, Aug 23, 2011 at 2:02 AM, Wu Yongchong wrote:
> Hi, Min
> 1), yes, not only I4NEG, but also I4ABS, I4ADD... has the same
> problem. I have modify this part, add the following code
Author: ycwu
Date: 2011-08-24 22:01:39 -0400 (Wed, 24 Aug 2011)
New Revision: 3727
Modified:
trunk/osprey/common/com/MIPS/targ_const.cxx
trunk/osprey/common/com/NVISA/targ_const.cxx
trunk/osprey/common/com/SL/targ_const.cxx
trunk/osprey/common/com/ia64/targ_const.cxx
trunk/osprey/co
Hi Sun,
Attached symtab_defs.h.
Thanks
zhuqing
2011/8/24 Sun Chan :
> can you send me the full symtab_defs.h?
> Sun
>
> On Wed, Aug 24, 2011 at 4:56 PM, 朱庆 wrote:
>> Hi all,
>>
>> Can gatekeeper help review following fix for bug832?
>> https://bugs.open64.net/show_bug.cgi?id=832
>>
>> small case
The reason I asked for the file is that I think there has to be some
alignment attribute somewhere. I am sure data alignment has been dealt
with in the compiler. That it is due to user, or just language
attribute might be irrelevant from compiler point of view.
Mike or Murthy,
Do you remember wher
The alignment is stored in the ty_idx (see TY_align), and then there are
routines like Adjusted_Alignment in stblock that can modify it. I suspect the
problem here is that the alignment is being put on the object rather than the
type, and then is lost (but should still be possible, because the
This case comes from kernel. It requires a strict alignment for the data.
In Adjust_Alignment, we trend to increase the alignment (for example, to 16
byte) for better performance. Usually, it is OK. But if the code specifies a
special alignment like this example, we need to follow it.
在 2011年8月25日
If it is Adjust_Alignment that is causing this problem, and this is for kernel
compilation, why don’t we just use an option like �COPT:space to force the
smaller alignment, which kernel compiles could use?
From: Jian-Xin Lai [mailto:laij...@gmail.com]
Sent: Wednesday, August 24, 2011 9:33 PM
To:
alignment is not just for performance, and the compiler does alignment
for all kinds of reasons. What Mike said is that the alignment should
have been set in the TY. Adding alignment in symbol will only confuse
things.
Sun
2011/8/25 Jian-Xin Lai :
> This case comes from kernel. It requires a stric
The alignment is correct in .B file, but in Adjusted_Alignment there
are following code to modify the align. In our case we do not want
this happen.
else {
align = MAX(align, Aggregate_Alignment);
}
Best wishes
zhuqing
在 2011年8月25日 下午12:28，Mike Murphy 写道：
> The al
So Aggregate_Alignment is a settable option (defaults to 16 in some targets).
What if you compile with -TENV:align_aggregates=8, or don't default it to 16?
-Original Message-
From: 朱庆 [mailto:zqing1...@gmail.com]
Sent: Wednesday, August 24, 2011 10:53 PM
To: Mike Murphy
Cc: Sun Chan; op
yes, when with -TENV:align_aggregates=8 it is ok.
在 2011年8月25日 下午1:57，Mike Murphy 写道：
> So Aggregate_Alignment is a settable option (defaults to 16 in some targets).
> What if you compile with -TENV:align_aggregates=8, or don't default it to 16?
>
> -Original Message-
> From: 朱庆 [mailto
The reason we introduce the "user align" is to separate this kind of case
from the generic aggregate. So that we can do the two things well:
If user specifies an alignment, we follow the size. Otherwise, the compiler
can decide what's the proper alignment.
在 2011年8月25日 下午1:57，Mike Murphy 写道：
> So
18 matches
Mail list logo
