On Sat, Apr 18, 2020 at 8:45 AM Joe via Gcc wrote:
> test.c: In function ‘main’:
> test.c:5:1: error: insn does not satisfy its constraints:
The constrain_operands function is failing to match the insn to its
constraints. Try putting a breakpoint there, and stepping through the
code to see what
On Mon, Jun 1, 2020 at 3:33 PM Martin Sebor via Gcc wrote:
> So it sounds like you wouldn't expect the "agent refused operation"
> error either, and it's not just a poor error message that I should
> learn to live with. That makes me think I should try to figure out
> what's wrong. I think the ~
On Wed, Jul 1, 2020 at 8:40 PM wrote:
> GCC seems to overlap register bewteen DEST and SOURCE in different
> machine mode,
> Is there any target hooks to control this feature ?
> I use ‘&’ to forbid register allocator to
> overlap bewteen DEST and SOURCE,
> but t
On Wed, Sep 23, 2020 at 7:51 AM Ilya Leoshkevich via Gcc
wrote:
> Is this restriction still valid today? Is there a reason we can't
> introduce new pseudos in a splitter before LRA?
See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91683
for an example of what can go wrong when a splitter cre
On Tue, Sep 29, 2020 at 3:47 AM 夏 晋 via Gcc wrote:
> I tried to set the "vlen" after the add & multi, as shown in the following
> code:
> vf32 x3,x4;
> void foo1(float16_t* input, float16_t* output, int vlen){
> vf32 add = x3 + x4;
> vf32 mul = x3 * x4;
> __builtin_riscv_vlen(vlen);
On Tue, Sep 29, 2020 at 7:22 PM 夏 晋 wrote:
> vint16m1_t foo3(vint16m1_t a, vint16m1_t b){
> vint16m1_t add = a+b;
> vint16m1_t mul = a*b;
> vsetvl_e8m1(32);
> return add + mul;
> }
Taking another look at your example, you have type confusion. Using
vsetvl to specify an element width of 8
On Tue, Sep 29, 2020 at 11:40 PM Richard Biener
wrote:
> But this also doesn't work on GIMPLE. On GIMPLE riscv_vlen would
> be a barrier for code motion if you make it __attribute__((returns_twice))
> since then abnormal edges distort the CFG in a way preventing such motion.
At the gimple level,
On Wed, Sep 30, 2020 at 11:35 PM Richard Biener
wrote:
> On Wed, Sep 30, 2020 at 10:01 PM Jim Wilson wrote:
> > We have a lot of examples in gcc/testsuite/gcc.target/riscv/rvv that
> > we are using for testing the vector support.
>
> That doesn't seem to exist (but ma
On Mon, Nov 2, 2020 at 11:45 PM Jojo R wrote:
> From origin insn seqs, I think the insn 'r500=unspec[r100] 300’ is in
> Good place because of the bypass of my pipeline description, it is not
> needed to schedule.
> ...
> Is there any way to control my case ?
> Or my description of pipeline is not
I'm not aware of any other target that has a similar feature, so I thought
a bit of discussion first might be useful.
For most ISAs, there is one organization that owns it, and does development
internally, in private. For RISC-V, the ISA is owned by RISC-V
International which has no developers.
On Wed, Feb 24, 2021 at 6:18 AM Jiaxun Yang wrote:
> I found it's very difficult for GCC to generate this kind of pcrel_lo
> expression,
> RTX label_ref can't be lower into such LOW_SUM expression.
>
Yes, it is difficult. You need to generate a label, and put the label
number in an unspec in th
On Wed, Feb 24, 2021 at 9:30 AM Maciej W. Rozycki wrote:
> On Wed, 24 Feb 2021, Jiaxun Yang wrote:
>
> > For RISC-V, %pcrel_lo shall point to the label of corresponding
> %pcrel_hi,
> > like
> >
> > .LA0:
> > auipca0, %pcrel_hi(sym)
> > addi a0, a0, %pcrel_lo(.LA0)
>
> I comment
On Wed, Mar 31, 2021 at 8:27 AM PKU via Gcc wrote:
> I’m trying to get my school to sign the copyright disclaimer.
> Unfortunately the officials are reluctant to do that. Can anyone suggest
> what to do next?
>
Maybe the PLCT Lab at the Chinese Academy of Sciences can help. They are
doing GCC a
On Sat, Apr 3, 2021 at 6:24 PM Simon Marchi via Gcc wrote:
> The default debug format (when using only -g) for the AVR target is
> stabs. Is there a reason for it not being DWARF, and would it be
> possible to maybe consider possibly thinking about making it default to
> DWARF? I am asking beca
On 07/14/2015 02:13 AM, Jan Beulich wrote:
> I was quite surprised for my gcc 4.9.3 build (using binutils 2.25 instead
> of 2.24 as I had in use with 4.9.2) to fail in rather obscure ways.
in-tree/combined-tree builds aren't recommended anymore, and hence
aren't well maintained anymore. That is a
On Tue, Jul 14, 2015 at 10:08 AM, H.J. Lu wrote:
> Combined tree is useful when the latest binutils is needed by GCC.
If you build and install binutils using the same --prefix as used for
gcc, then gcc will automatically find that binutils and use it. You
don't need combined trees to make this w
On 07/16/2015 01:32 PM, Dmitry Grinberg wrote:
> WUMUL x, y which will multiply 32-bit register x by 32-bit
> register y, and produce a 64-bit result, storing the high bits into
> register x and low bits into register y
You can rewrite the RTL to make this easier. You can use a parallel to
do
On 07/23/2015 11:09 PM, Ajit Kumar Agarwal wrote:
> From the description of the definition of the macro
> RETURN_ADDRESS_POINTER_REGNUM ,
> Does this impact the performance or correctness of the compiler? On what
> cases it is applicable to define for the given architecture?
This is used to h
On 07/30/2015 09:54 PM, Paul Shortis wrote:
> Resulting in ...
> error: unable to find a register to spill in class ‘GP_REGS’
>
> enabling lra and inspecting the rtl dump indicates that both
> alternatives (R and r) seem to be equally appealing to the allocater so
> it chooses 'R' and fails.
The
On 08/25/2015 02:54 PM, Steve Ellcey wrote:
> Actually, it looks like is peephole2 that is eliminating the
> instructions (and .cfi psuedo-ops).
> I am not entirely sure I need the code or if I just need the .cfi
> psuedo-ops and that I need the code to generate the .cfi stuff.
Don't create any ne
On 09/01/2015 12:44 AM, DJ Delorie wrote:
> I expected gcc to see that the operation doesn't meet the constraints,
> and move operands into registers to make it work (alternative 1,
> "v/v/v").
It did match the first alternative (alternative 0), but it matched the
constraints Y/Y/m. Operands 1 an
On Tue, Sep 1, 2015 at 6:20 PM, DJ Delorie wrote:
>
>> It did match the first alternative (alternative 0), but it matched the
>> constraints Y/Y/m.
>
> It shouldn't match Y as those are for near addresses (unless it's only
> matching MEM==MEM), and the ones in the insn are far, but ...
Reload cho
On Mon, Sep 14, 2015 at 11:05 PM, DJ Delorie wrote:
> As a test, I added this API. It seems to work. I suppose there could
> be a better API where we determine if a constrain matches various
> memory spaces, then compare with the memory space of the operand, but
> I can't prove that's sufficient
On Tue, Sep 15, 2015 at 7:42 AM, Ulrich Weigand wrote:
> But the only difference between define_memory_constraint and a plain
> define_constraint is just that define_memory_constraint guarantees
> that any memory operand can be made valid by reloading the address
> into a base register ...
>
> If
On Tue, Sep 15, 2015 at 8:53 AM, Ulrich Weigand wrote:
> Jim Wilson wrote:
> In that case, you might be able to fix the bug by splitting the
> offending insns into two patterns, one only handling near mems
> and one handling one far mems, where the near/far-ness of the mem
> is
I'm looking at an ICE on SPEC 2006 464.h264ref slice.c that occurs
with -O3 for both aarch64 and armhf.
palantir:2080$ ./xgcc -B./ -O3 -S slice.i
slice.c: In function ‘poc_ref_pic_reorder’:
slice.c:838:6: error: incorrect type of vector CONSTRUCTOR elements
{_48, _55, _189, _59}
vect_no_reorder_
On Tue, Jan 12, 2016 at 2:22 PM, Jim Wilson wrote:
> I see a number of places in tree-vect-generic.c that add a
> VIEW_CONVERT_EXPR if useless_type_convertsion_p is false. That should
> work, except when I try this, I see that the VIEW_CONVERT_EXPR gets
> converted to a
On Thu, Jan 28, 2016 at 5:37 AM, Richard Biener wrote:
>> To workaround this, I defined a new hook expand_divmod_libfunc, which
>> targets must override for expanding call to target-specific dimovd.
>> The "default" hook default_expand_divmod_libfunc() expands call to
>> libgcc2.c:__udivmoddi4() s
On Sun, Jan 31, 2016 at 2:15 PM, Richard Henderson wrote:
> On 01/29/2016 12:37 AM, Richard Biener wrote:
>>>
>>> To workaround this, I defined a new hook expand_divmod_libfunc, which
>>> targets must override for expanding call to target-specific dimovd.
>>> The "default" hook default_expand_divm
On Sun, Jan 31, 2016 at 8:43 PM, Jim Wilson wrote:
>> Are we certain that the libcall is a win for any target?
>> I would have expected a default of
>> q = x / y
>> r = x - (q * y)
>> to be most efficient on modern machines. Even more so on targets
On Fri, Jan 29, 2016 at 12:09 AM, Richard Biener wrote:
> I wonder if rather than introducing a target hook ports could use
> a define_expand expanding to a libcall for this case?
Of the two divmod libcall APIs, one requires a stack temporary, which
would be awkward to allocate in a define_expand
On Mon, Feb 22, 2016 at 7:55 AM, David Edelsohn wrote:
> If I remove extendqihi2 (extend:HI pattern) from the PowerPC port,
> will that cause any problems for the GCC RTL type system or inhibit
> optimizations? I see that Alpha and SPARC define extendqihi2, but
> IA-64 and AArch64 do not, so the
On 04/04/2016 08:55 AM, Umesh Kalappa wrote:
We are in process of changing the gcc compiler for aarch64 abi ,w.r.t
varargs function arguments handling.
default(LP64) ,where 1,2,4 bytes args are promoted to word size i.e 4
bytes ,we need to change these behaviour to 8 bytes (double word).
we a
On Tue, Apr 5, 2016 at 2:45 AM, Umesh Kalappa wrote:
> I need to ,make the changes only to the function args(varargs),hence
> making the changes in TARGET_PROMOTE_FUNCTION_MODE will do ?.
If TARGET_PROMOTE_FUNCTION_MODE disagrees with PROMOTE_MODE, it is
possible that the middle end may generat
On 08/16/2016 03:10 AM, shmuel gutl wrote:
My hardware directly supports instructions of the form
subreg:SI(reg:VEC v1,3) = SI:a1
Subregs of hard registers should be avoided. They are primarily useful
for pseudo regs. Subregs that aren't lowpart subregs should be avoided
also. Except w
On 08/19/2016 12:55 PM, Umesh Kalappa via llvm-dev wrote:
We have the legacy code ,that uses the .stabs directive quiet often
in the source code like
.stabs "symbol_name", 100, 0, 0, 0 + .label_one f;
.label_one
stmt
and ,the above code is wrapped with the inline asm in the c source
On 10/20/2016 11:51 AM, Florian Weimer wrote:
exception handling region. Subtracting 1 is an extremely hackish way to
achieve that and likely is not portable at all.
Gdb has been doing this for over 25 years for every architecture. When
you use the backtrace command, it gets a return address
On 12/16/2016 10:06 AM, Jeff Law wrote:
That's likely the manual RMS kept asking folks (semi-privately) to
review. My response was consistently that such review should happen
publicly, which RMS opposed for reasons I don't recall.
I reviewed it, on the grounds that a happy rms is good for the
On 04/30/2015 03:59 PM, Steve Ellcey wrote:
I am curious, has anyone started seeing these messages in their GCC build
output:
Mode = sf\|df
Suffix = si\|2\|3
That comes from libgcc/config/t-hardfp. This is used to generate a list
of function names from operator, mode, and suffix, e.g. fixsf
On 05/05/2015 05:19 PM, Peter T. Breuer wrote:
Please .. where (in what file, dir) of the gcc (4.9.1) source should I
rummage in order to change the sequence of instructions eventually
emitted to do a function call?
Are you trying to change the caller or the callee?
For the callee, or1k_compu
On 05/17/2015 01:16 AM, Bin.Cheng wrote:
> On Sat, May 16, 2015 at 5:35 PM, Hans-Peter Nilsson wrote:
>> On Thu, 23 Apr 2015, Bin.Cheng wrote:
>>> Hi,
>>> In libstdc++ testsuite, I noticed that macro _GLIBCXX_RES_LIMITS is
>>> checked/set by GLIBCXX_CHECK_SETRLIMIT, which is further guarded by
>>>
On 05/18/2015 02:05 AM, Umesh Kalappa wrote:
> Getting a bus/hard error for the below case ,make sense since ldm/stm
> expects the address to be word aligned .
> --with-pkgversion='Cisco GCC c4.7.0-p1' --with-cisco-patch-level=1
The FSF doesn't support gcc-4.7.0 anymore. Generally, we only suppo
On 05/20/2015 10:00 AM, H.J. Lu wrote:
> By default, alignment of DImode and DFmode is set to 8 bytes.
> Intel MCU psABI specifies alignment of DImode and DFmode
> to be 4 bytes. I'd like to make get_mode_alignment to return
> 32 bits for DImode and DFmode. Is there a way to adjust alignment
> of
On 05/28/2015 01:39 AM, Maxim Kuvyrkov wrote:
> Hi,
>
> Akashi-san and I have been discussing required GCC changes to make kernel's
> livepatching work for AArch64 and other architectures. At the moment
> livepatching is supported for x86[_64] using the following options: "-pg
> -mfentry -mrec
On 06/02/2015 11:39 PM, shmeel gutl wrote:
> find_modifiable_mems was introduced to gcc 4.8 in september 2012. Is
> there any documentation as to how it is supposed to help the haifa
> scheduler?
The patch was submitted here
https://gcc.gnu.org/ml/gcc-patches/2012-08/msg00155.html
and this messa
On 09/10/2018 10:46 PM, Jason A. Donenfeld wrote:
Hello,
I'd like to have a compound literal exist inside a certain linker
section. However, it doesn't appear to work as I'd like:
#define __stuffdata __attribute__((__section__("stuff")))
const u8 works[] __stuffdata = { 0x1, 0x2, 0x3, 0x4 };
co
On Fri, Sep 14, 2018 at 7:44 AM Jason A. Donenfeld wrote:
> Assuming this is an array of a huge amount of
> chacha20poly1305_testvec, I'm not sure if there's a syntax for me to
> define the symbol inline with the declarations. Any ideas?
Don't do it inline.
u8[] __stuffdata key_value = ...
...
.
On 10/06/2018 06:07 AM, Tejas Joshi wrote:
I have gcc source code, stage1-build and test directories as siblings
and I've been trying to compile test.c in test/ using:
../stage1-build/gcc/cc1 test.c
That isn't expected to work. You need to use the compiler driver, which
is called xgcc in the
On 10/16/18 7:19 AM, Christophe Lyon wrote:
While reviewing one of my patches about FDPIC support for ARM, Richard
raised the concern of testing the patch on other uClinux targets [1].
I looked at uclinux.org and at the GCC maintainers file, but it's
still not obvious to me which uClinux targets
On 1/14/19 5:44 AM, MCC CS wrote:
I've been running the testsuite on my macOS, on which
it is especially unbearable. I want to (at least try to)
rewrite a DejaGNU replacement accepting the same
syntax and having no dependency, should therefore
be faster. I was wondering if there have been any
att
On 2/14/19 3:13 AM, Paulo Matos wrote:
If I compile this with -O2, sched1 groups all loads and all stores
together. That's perfect. However, if I change TYPE to unsigned char and
recompile, the stores and loads are interleaved.
Further investigation shows that for unsigned char there are extra
d
On Thu, Feb 14, 2019 at 11:33 PM Paulo Matos wrote:
> Are global variables not supposed to alias each other?
> If I indeed do that, gcc still won't group loads and stores:
> https://cx.rv8.io/g/rFjGLa
I meant something like
struct foo_t x, y;
and now they clearly don't alias. As global pointers
On 3/20/19 5:25 AM, Paulo Matos wrote:
I am working on trying to get RISC-V 32 emitting sibcalls even in the
present of `-msave-restore`, for a client concerned with generated code
size.
This won't work unless you define a new set of restore functions. The
current ones restore the return addr
On Mon, May 6, 2019 at 6:02 AM Алексей Хилаев via gcc wrote:
> Gcc riscv won`t emit my insns, binutils and spike(riscv sim) work correctly,
> but gcc don`t. I want to add min/max for integer, gcc compiling correct, sim
> executing correctly.
> (define_insn "*min_"
> [(set (match_operand:GPR 0 "r
On 5/8/19 3:34 AM, Matthew Malcomson wrote:
The cause seems to be a restriction in dejagnu where it stops reading
after a given read if its output buffer is greater than 512000 bytes.
This dejagnu restriction was removed in 2016. Try using a newer dejagnu
release.
2016-03-27 Ben Elliston
On Thu, 2019-06-13 at 09:09 -0600, Jeff Law wrote:
> On 6/13/19 5:13 AM, Richard Biener wrote:
> >
> > ia64 has no maintainer anymore so the following deprecates it
> > with the goal of eliminating the port for GCC 11 if no maintainer
> > steps up.
OK with me since I'm not the maintainer anymore.
On Thu, Jun 13, 2019 at 10:39 AM Joel Sherrill wrote:
> Ok with me if no one steps up and the downstream projects like Debian gets
> notice. This is just a reflection of this architecture's status in the
> world.
I sent email to the debian-ia64 list half an hour ago. Just got a
response. They m
On Mon, Jul 22, 2019 at 4:05 AM Maxim Blinov wrote:
> Is it possible, in the arch.opt file, to have GCC generate a bitmask
> relative to a user-defined variable without an associated name? To
> illustrate my problem, consider the following option file snippet:
> ...
> But, I don't want the user to
We got a change request for the RISC-V psABI to define the atomic
structure size and alignment. And looking at this, it turned out that
gcc and clang are implementing this differently. Consider this
testcase
rohan:2274$ cat tmp.c
#include
struct s { int a; int b; int c;};
int
main(void)
{
pri
I was pointed at
https://bugs.llvm.org/show_bug.cgi?id=26462
for the LLVM discussion of this problem.
Another issue here is that we should have ABI testing for atomic.
For instance, gcc/testsuite/gcc.dg/compat has no atomic testcases.
Likewise g++.dg/compat.
Jim
On Tue, Nov 12, 2019 at 8:06 AM Richard Sandiford
wrote:
> If the use of sizeless types does expand beyond SVE built-in types
> in future, the places that call the hook are the places that would
> need to deal directly with sizeless types.
We are using the same sizeless type infrastructure for th
On Tue, Nov 12, 2019 at 2:12 PM Richard Sandiford
wrote:
> Are both RVV intrinsic proposals like SVE in that all sizeless types
> can be/are built into the compiler? If so, do you think the target hook
> added in:
> https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00942.html
> would be enough fo
On 03/10/2017 03:08 AM, David Edelsohn wrote:
On Thu, Mar 9, 2017 at 8:48 PM, Ian Lance Taylor wrote:
On Thu, Mar 9, 2017 at 11:49 AM, David Edelsohn wrote:
As discussed at the last Cauldron, the first interest of the community
seems to be the shared infrastructure of Sourceware: hosting, sys
On 03/17/2017 03:28 PM, Jeff Law wrote:
On 03/17/2017 03:31 PM, Andrew Pinski wrote:
On Fri, Mar 17, 2017 at 11:47 AM, Bernd Schmidt
wrote:
On 03/17/2017 07:38 PM, Pinski, Andrew wrote:
One of the following revision caused a bootstrap comparison failure on
aarch64-linux-gnu:
r246225
r246226
On 03/17/2017 04:12 PM, Jim Wilson wrote:
I have access to a fast box that isn't otherwise in use at the moment so
I'm taking a look. r246225 builds OK. r246226 does not. So it is
Bernd's combine patch. A little experimenting shows that the compare
difference is triggere
On 06/01/2017 05:59 AM, Georg-Johann Lay wrote:
Hi, when I am running the gcc testsuite in $builddir/gcc then
$ make check-gcc RUNTESTFLAGS='ubsan.exp'
comes up with spurious fails.
This was discussed before, and the suspicion was that it was a linux
kernel bug. There were multiple kernel fix
On 06/06/2017 09:01 AM, Steve Ellcey wrote:
So the question remains, where is libat_have_strexbhd set? As near as
I can tell it isn't set, which would make the libatomic IFUNC pointless
on arm.
libat_have_strexbhd isn't set anywhere. It looks like this was a
prototype that was never fully fl
On 07/28/2017 04:51 AM, Geza Herman wrote:
There's an option in GCC "-mms-bitfields". The doc about it begins with:
"If packed is used on a structure, or if bit-fields are used, it may be
that the Microsoft ABI lays out the structure differently than the way
GCC normally does. Particularly whe
On 09/12/2017 02:32 AM, Jürg Billeter wrote:
To support applications that assume big-endian memory layout on little-
endian systems, I'm considering adding support for reversing the
storage order to GCC. In contrast to the existing scalar storage order
support for structs, the goal is to reverse
On 10/13/2017 12:06 AM, Sebastian Huber wrote:
The end-of-life of Solaris 2.6 was 2006. Is it worth to mention this here?
The reference to Solaris 2.6 is no longer useful. Just mention ELF here.
This "AIX may have these optimizations in the future." is there since at
least 1996. What is the
On Mon, Nov 6, 2017 at 6:39 PM, Palmer Dabbelt wrote:
>
> +riscv port Jim Wilson
>
>
It is jimw not jim for the email address. Please fix.
Jim
On 11/11/2017 05:33 PM, Fengguang Wu wrote:
CC gcc list. According to Alexei:
This is a known issue with gcc 7 on mips that is "optimizing"
normal 64-bit multiply into 128-bit variant.
Nothing to fix on the kernel side.
I filed a bug report. This is now
https
On 11/26/2017 11:09 PM, Marek wrote:
Hi,
while compiling 7.2.0 im getting the following:
cc1: error: no include path in which to search for stdc-predef.h
cc1: note: self-tests are not enabled in this build
This doesn't appear to be a build error. Configure runs the compiler to
check for fea
On 12/04/2017 01:11 PM, Marek wrote:
looking at config.log i see theses errors:
Configure does a number of feature tests to see what features are
available for use. It is expected that some of these feature tests will
fail. Some features are optional, and if that feature test fails there
i
On 01/15/2018 03:11 PM, Shahid Khan wrote:
Our team at Qualcomm Datacenter Technologies, Inc. is interested in
contributing patches to the upstream GCC compiler project. To get the process
started, we'd like to request a copyright assignment form as per contribution
guidelines outlined at http
On Tue, Jan 16, 2018 at 12:01 PM, Siddhesh Poyarekar
wrote:
> You need a separate assignment for every GNU project you intend to
> contribute to, so separate assignments for GCC, glibc, binutils, etc.
The form is the same for all GNU projects.
You can file an assignment that covers a single patc
On 04/08/2018 08:22 AM, Jeff Law wrote:
On 03/31/2018 12:27 PM, Richard W.M. Jones wrote:
I'd like to talk about what changes we (may) need to GCC in
Fedora to get it working on 64-bit RISC-V, and also (more
importantly) to ask your advice on things we don't fully
understand yet. However, I don
On 05/02/2018 10:21 AM, Damian Rouson wrote:
Could someone please point me to instructions for how to submit a change to the
gfortran changes list? I’d like to add the following bullet:
See also
https://gcc.gnu.org/contribute.html#webchanges
Jim
On 05/26/2018 06:04 AM, Sebastian Huber wrote:
Why is the default multilib and a variant identical?
This is supposed to be a single multilib, with two names. We use
MULTILIB_REUSE to map the two names to a single multilib.
rohan:1030$ ./xgcc -B./ -march=rv64imafdc -mabi=lp64d --print-libgcc
On 05/28/2018 06:32 AM, Sebastian Huber wrote:
I guess, that the resolution of the weak reference to the undefined
symbol __deregister_frame_info somehow sets __deregister_frame_info to
the absolute address 0 which is illegal in the following "call
__deregister_frame_info"? Is this construct wi
On 05/29/2018 04:19 AM, Sebastian Huber wrote:
Changing the code to something like this
void f(void) __attribute__((__weak__));
void _start(void)
{
void (*g)(void) = f;
if (g != 0) {
(*g)();
}
}
This testcase works for me also, using -mcmodel=medan
On Tue, May 29, 2018 at 11:43 AM, Sebastian Huber
wrote:
> would you mind trying this with -Ttext=0x9000?
This gives me for the weak call
9014: 7097 auipc ra,0x7
9018: fec080e7 jalr -20(ra) # 0 <__global_pointer$+0x6fffe7d4>
> Please have a look at:
> https
On Thu, May 31, 2018 at 7:23 AM, Matthew Fortune
wrote:
> I do actually have a solution for this but it is not submitted upstream.
> MIPS has basically the same set of problems that RISC-V does in this area
> and in an ideal world there would be no 'fallback' multilib such that if
> you use compil
On 06/08/2018 06:21 AM, Paul Koning wrote:
Interesting. The ChangeLog doesn't give any background. I suppose I should
plan to approximate the effect of this pattern with a define-peephole2 ?
The old RTL loop optimizer was replaced with a new RTL loop optimizer.
When the old one was written,
On Fri, Jun 8, 2018 at 1:12 PM, Paul Koning wrote:
> Thanks. I saw those sections and interpreted them as support for signal
> processor style fast hardware loops. If they can be adapted for dbra type
> looping, great. I'll give that a try.
The rs6000 port uses it for bdnz (branch decrement
On 08/09/2018 02:38 AM, daro...@o2.pl wrote:
Hello, I wanted to ask what model for
branch coverage does gcov use?
There is a comment at the start of gcc/profile.c that gives some details
on how it works. It is computing execution counts for edges in the
control flow graph. As for which ed
On 08/12/2018 02:38 PM, Dave Pitts wrote:
I've been hacking with version 7.2.0 of gcc trying to adapt some old md
files that I've got to this newer gcc. I've been getting errors from the
dwarf2out_frame_debug_expr() function in dwarf2cfi.c line 1790 calling
gcc_unreachable(). The expression bei
On 07/30/2009 07:38 AM, sumanth wrote:
How can I make sure the debugging information printed by my compiler for
extern variables is correct.
I am able to print them in gdb in with an _ (underscore). I am using
Gcc-4.3.4 and gdb 5.3
ELF targets usually don't prepend an underscore to symbol names
On 08/01/2009 04:28 AM, Robert Oeffner wrote:
I'm trying to port GCC 4.4.0 to interix. I have some issues with
libgomp. To save time rather than bootstrapping GCC each time I make a
change I would like to compile libgomp separately to make my amendments
take effect.
Configure with --disable-boo
On Mon, 2009-08-03 at 09:44 +0530, sumanth wrote:
>How can i make sure my tool chain knows the difference between
> global variable r0 and register r0.
The simple solution is to either add a prefix to variable names, or to
add a prefix to register names. In ELF, the convention is to not
On 08/03/2009 02:14 AM, Mohamed Shafi wrote:
short - 2 bytes
i am not able to implement the alignment for short.
The following is are the macros that i used for this
#define PARM_BOUNDARY 8
#define STACK_BOUNDARY 64
You haven't explained what the actual problem is. Is there a problem
with glo
On Tue, 2009-08-04 at 00:06 +0530, sumanth wrote:
> > mycompiler-gcc -g file1.c file2.c
> > mycompiler-gdb a.out
> >> when i print "a" in file1.c , i am able to see value 10;
> >> when i print "a" int file2.c, it prints , no symbol defined.
> Instead I can access it with " print _a"
This so
On Tue, 2009-08-04 at 11:09 +0530, Mohamed Shafi wrote:
> >> i am not able to implement the alignment for short.
> >> The following is are the macros that i used for this
> >> #define PARM_BOUNDARY 8
> >> #define STACK_BOUNDARY 64
> The target is 32bit . The first two parameters are passed in regis
On 03/10/2010 10:48 PM, fanqifei wrote:
For below piece of code, the instruction "clr.w a15" obviously doesn't
belong to the inner loop.
6: bd f4clr.w a15; #clear to zero
8: 80 af 00std.w a10 0x0 a15;
There is info lacking here. Did you compile with optimization
On 03/15/2010 01:00 AM, Amker.Cheng wrote:
1: In pattern "*mul_acc_si", there's constraint like "*?*?".
what does this supposed to do?
'*' is in the Constraint Modifier Characters section of the docs. It
means ignore the next character for register class preferencing. '?' is
in the Multipl
On Wed, 2010-03-17 at 11:27 +0800, fanqifei wrote:
> You are correct. The reload pass emitted the clr.w insn.
> However, I can see loop opt passes after reload:
> problem1.c.174r.loop2_invariant1
Not unless you have a modified toolchain. We don't run loop opt after
register allocation. See the l
On Tue, 2010-03-16 at 15:12 +0800, Amker.Cheng wrote:
> In my understanding, the macro GENERATE_MADD_MSUB is true when the processor
> has
> madd insn, rather than madd2. And the macro "ISA_HAS_MUL3" is false if it
> has
> no mul insn.
>
> for this kind processor, gcc will
> step 1 : generate in
On Thu, 2010-03-18 at 19:20 +0800, Amker.Cheng wrote:
> Does it possible that the method would ever result in register
> allocator failure?
> In my understanding, doesn't reload pass would do whatever it can to make
> all insns' constraints satisfied?
In theory, there should be no failure. In pra
On Fri, 2010-03-19 at 22:06 +0800, fanqifei wrote:
> 1. I add movsi expander in which function foor_expand_move is used to
> force the operands[1] to reg and emit the move insn.
> Another change is that in the define of insn “*mov_mode_insn" in which
> a condition is added to prevent a store c
On Sat, 2010-03-20 at 14:29 +0800, fanqifei wrote:
> I changed the condition in "*mov_insn_mode" to below:
> (register_operand(operands[0], SImode) ||
> register_operand(operands[1],SImode))
I think you need the same change in foor_expand_move. I.e., if neither
the source or dest is a regis
101 - 200 of 344 matches
Mail list logo
