Jovan Dmitrovic 于2023年5月29日周一 19:00写道：
>
> This patch changes alignment for typedef types when passed as
> arguments, making the alignment equal to the alignment of
> original (aliased) types.
>
> This change makes it impossible for a typedef type to have
> alignment that is less than its size.
>
Jie Mei 于2023年5月19日周五 16:07写道：
>
> From: Simon Dardis
>
> Support for __attribute__ ((code_readable)). Takes up to one argument of
> "yes", "no", "pcrel". This will change the code readability setting for just
> that function. If no argument is supplied, then the setting is 'yes'.
>
> gcc/Chan
Jovan Dmitrovic 于2023年6月6日周二 18:29写道：
>
> I suppose that it is possible to check assembly.
>
Great.
> Following is part of diff before and after my patch:
>
> 29,32c29,32
> < sd $6,0($2)
> < sd $7,8($2)
> < sd $8,16($2)
> < sd $9,24($2)
> ---
> >
Richard Biener via Gcc-patches 于2023年7月19日周三 14:27写道：
>
> On Wed, 19 Jul 2023, YunQiang Su wrote:
>
> > PR #104914
> >
> > When work with
> > int val;
> > ((unsigned char*)&val)[3] = *buf;
> > if (val > 0) ...
> > The RTX mode is obtained from REG instead of SUBREG, which make
> > D is used
Richard Biener 于2023年7月19日周三 15:22写道：
>
> On Wed, 19 Jul 2023, YunQiang Su wrote:
>
> > Richard Biener via Gcc-patches ?2023?7?19???
> > 14:27???
> > >
> > > On Wed, 19 Jul 2023, YunQiang Su wrote:
> > >
> > > > PR #104914
> > > >
> > > > When work with
> > > > int val;
> > > > ((unsigned ch
YunQiang Su 于2023年7月19日周三 16:21写道：
>
> Richard Biener 于2023年7月19日周三 15:22写道：
> >
> > On Wed, 19 Jul 2023, YunQiang Su wrote:
> >
> > > Richard Biener via Gcc-patches ?2023?7?19???
> > > 14:27???
> > > >
> > > > On Wed, 19 Jul 2023, YunQiang Su wrote:
> > > >
> > > > > PR #104914
> > > > >
> > >
I am not sure this patch is best, while I think that I am sure the
initial RTL is not correct,
the initial RTL of ARM64 is like
(insn 8 7 9 2 (set (zero_extract:SI (reg/v:SI 98 [ val ])
^^
(const_int 8 [0x8])
(const_int 0 [0
Richard Biener 于2023年7月19日周三 17:23写道：
>
> On Wed, 19 Jul 2023, YunQiang Su wrote:
>
> > Richard Biener ?2023?7?19??? 15:22???
> > >
> > > On Wed, 19 Jul 2023, YunQiang Su wrote:
> > >
> > > > Richard Biener via Gcc-patches ?2023?7?19???
> > > > 14:27???
> > > > >
> > > > > On Wed, 19 Jul 2023,
Eric Botcazou 于2023年7月19日周三 17:45写道：
>
> > I don't see that. That's definitely not what GCC expects here,
> > the left-most word of the doubleword should be unchanged.
> >
> > Your testcase should be a dg-do-run and probably more like
> >
> > NOMIPS16 int __attribute__((noipa)) test (const unsign
YunQiang Su 于2023年8月3日周四 11:18写道：
>
> PR #104914
>
> On TRULY_NOOP_TRUNCATION_MODES_P (DImode, SImode)) == true platforms,
> zero_extract (SI, SI) can be sign-extended. So, if a zero_extract (DI,
> DI) following with an sign_extend(SI, DI) can be merged to a single
> zero_extract (SI, SI).
>
The
>
> Like I mentioned in the other thread, I think things went wrong when
> we generated the subreg in this sign_extend. The operation should
> have been a truncate of (reg/v:DI 200) followed by a sign extension
> of the result.
>
Sorry for my misunderstanding.
So you mean that in the RTL, for th
Jovan Dmitrovic 于2023年6月7日周三 18:29写道：
>
> I see what you mean now, so I've made adjustment in order for testcase to work
> on assembly. Following is the updated patch.
>
> Regards,
> Jovan
>
> From 2744357b5232c61bf1f780c4915d47b19d71f993 Mon Sep 17 00:00:00 2001
> From: Jovan Dmitrovic
> Date: F
Jovan Dmitrovic 于2023年6月27日周二 16:54写道：
>
> Hi,
> I am sending a revised patch, now with different tests for N64/N32 and O32
> ABIs.
> For the O32 ABI, I've skipped the -O0 and -Os pipelines, considering there is
> a
> difference between exact offsets for store instructions (the registers used
>
YunQiang Su 于2023年6月29日周四 14:04写道：
>
> Jovan Dmitrovic 于2023年6月27日周二 16:54写道：
> >
> > Hi,
> > I am sending a revised patch, now with different tests for N64/N32 and O32
> > ABIs.
> > For the O32 ABI, I've skipped the -O0 and -Os pipelines, considering there
> > is a
> > difference between exact
Jie Mei 于2023年7月4日周二 17:52写道：
>
> A mips16e2 related test fails after the ifcvt change. The mips16e2
> addition also causes a test for unrelated module to fail.
>
> This patch adjusts branch costs when running the two affected tests.
>
> These tests should not require the -mbranch-cost option, and
Arnaud Charlet 于2021年2月23日周二 下午5:07写道：
>
> > For MIPS N64 and N32:
> > add GNATRTL_128BIT_PAIRS to LIBGNAT_TARGET_PAIRS
> > add GNATRTL_128BIT_OBJS to EXTRA_GNATRTL_NONTASKING_OBJS
> >
> > gcc/ada/ChangeLog:
> > PR ada/98996
> > * Makefile.rtl: add 128Bit operation file to MIPS
>
Arnaud Charlet 于2021年2月23日周二 下午5:33写道：
>
> > > > For MIPS N64 and N32:
> > > > add GNATRTL_128BIT_PAIRS to LIBGNAT_TARGET_PAIRS
> > > > add GNATRTL_128BIT_OBJS to EXTRA_GNATRTL_NONTASKING_OBJS
> > > >
> > > > gcc/ada/ChangeLog:
> > > > PR ada/98996
> > > > * Makefile.rtl: add 128B
Jeff Law via Gcc-patches 于2021年2月26日周五 上午10:57写道：
>
>
>
> On 2/23/21 3:05 AM, YunQiang Su wrote:
> > It is found by ada s-pack96.adb ftbfs, due to 96bit load: 96 = 64 + 32.
> > While the 32bit pair of l r is mark as SUBREG, so they are
> > not in SImode, make it fail to find suitable insn.
> >
> >
Chen Li 于2021年3月8日周一 下午2:35写道：
>
>
> When execute libstdc++ testcases on mips, I notice that last_write_time
> alawys failed, and the failed VERIFY is "VERIFY(
> approx_equal(last_write_time(f.path), time) );" where testing time before
> than epoch.
>
> Below is the minimal case:
>
> ```
> // gcc
Jonathan Wakely via Gcc-patches 于2021年3月8日周一 下午6:57写道：
>
> On 08/03/21 14:35 +0800, Chen Li wrote:
> >
> >When execute libstdc++ testcases on mips, I notice that last_write_time
> >alawys failed, and the failed VERIFY is "VERIFY(
> >approx_equal(last_write_time(f.path), time) );" where testing ti
Xi Ruoyao via Gcc-patches 于2022年9月21日周三 23:09写道：
>
> On Wed, 2022-09-21 at 11:31 +, YunQiang Su wrote:
> > On platforms that support multiarch, such as Debian,
> > the filesystem hierarchy doesn't fellow the old Irix style:
> > lib & lib/ for native
> > lib64 for N64 on N32/O32
When working on LLVM, I found this problem
https://github.com/llvm/llvm-project/issues/64974.
Maybe it's time for us to reconsider the way of getting GOT address
for PIC code.
1.Background[1]:
All of the accessing of global variables and normal function calls
needs help from GOT.
So normally, the
> I think that is too new.
> We still allow building gcc e.g. with GCC 4.8 from ~ 10 years ago and
> I think various boxes where people regularly build gcc will have similarly
> old other tools.
> So, bumping requirement from ~ 20 years old tools to ~ 10 years old tools
> might be ok, but requiring
23 matches
Mail list logo
