I'd like to introduce a project we've been working on for the past year
an a half.
The original project goal was to see if we could derived accurate range
information from the IL without requiring much effort on the client
side. The idea being that a pass could simply ask "what is the range of
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
Hello Jim,
- Am 29. Mai 2018 um 20:27 schrieb Jim Wilson j...@sifive.com:
> 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
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
Question about proper target maintainer procedures...
The pdp11 target needs udivhi3 in libgcc. There's udivsi3, and it's really
easy to tweak those files for HImode. And that works.
Should I add the HI files to the libgcc directory, or under config/pdp11?
There's nothing target specific abo
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/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/29/2018 07:38 PM, Martin Liška wrote:
$ nm main.o
T main
T mystring
C pole
Or we can be inspired by readelf:
$ readelf -s a.out
[snip]
Symbol table '.symtab' contains 74 entries:
Num:Value Size TypeBind Vis Ndx Name
66: 00
On 05/29/2018 07:17 PM, Prathamesh Kulkarni wrote:
Shouldn't fdump-lto-list be enabled only if fdump is enabled ?
The option is dummy, and eventually all do options will be moved
to a separate tool called lto-dump. Thus all the prefixed '-fdump-lto-foo'
will be replaced with -foo is guess.
Ma
On 05/29/2018 07:03 PM, Hrishikesh Kulkarni wrote:
Hi,
My exams have finally ended and I have started working on the GSOC project.
I have forked GCC mirror (https://github.com/hrisearch/gcc) and
created a option for dumping functions and variables used in IL.
Please find the patch attached herew
On 29 May 2018 at 22:33, Hrishikesh Kulkarni wrote:
> Hi,
>
> My exams have finally ended and I have started working on the GSOC project.
> I have forked GCC mirror (https://github.com/hrisearch/gcc) and
> created a option for dumping functions and variables used in IL.
> Please find the patch att
Hi,
My exams have finally ended and I have started working on the GSOC project.
I have forked GCC mirror (https://github.com/hrisearch/gcc) and
created a option for dumping functions and variables used in IL.
Please find the patch attached herewith.
Regards,
Hrishikesh
diff --git a/gcc/lto/lang.o
On Dienstag, 29. Mai 2018 16:57:56 CEST Richard Biener wrote:
>
> so the situation improves but isn't fully fixed (STLF issues maybe?)
>
That raises the question if it helps in these cases even in -O3?
Anyway it doesn't look good for it. Did the binary size at least improve with
prefer-avx128,
On Tue, May 29, 2018 at 11:32 AM Richard Biener
wrote:
> On Mon, May 28, 2018 at 5:50 PM Allan Sandfeld Jensen
> wrote:
> > On Montag, 28. Mai 2018 12:58:20 CEST Richard Biener wrote:
> > > compile-time effects of the patch on that. Embedded folks may want to
> rhn
> > > their favorite benchmar
> On May 29, 2018, at 5:49 AM, Richard Biener
> wrote:
> ...
> It might be a "regression" with the POINTER_MINUS_EXPR introduction.
> You can debug this with gdb when you break on 'pointer_diff'. For me
> on x86_64 this builds a POINTER_DIFF_EXPR: (char *) &s.f - &s.b
> of ptrdiff_t. That a
Changing the code to something like this
void f(void) __attribute__((__weak__));
void _start(void)
{
void (*g)(void) = f;
if (g != 0) {
(*g)();
}
}
doesn't work either, since this is optimized to
.option nopic
.text
.align 1
Jeff Law writes:
> Now that we're in stage1 I do want to revisit the CLOBBER_HIGH stuff.
> When we left things I think we were trying to decide between
> CLOBBER_HIGH and clobbering the appropriate subreg. The problem with
> the latter is the dataflow we compute is inaccurate (overly pessimistic)
On Mon, May 28, 2018 at 8:34 PM Paul Koning wrote:
> > On May 28, 2018, at 12:03 PM, Richard Biener
>
wrote:
> >
> > On May 28, 2018 12:45:04 PM GMT+02:00, Andreas Schwab
wrote:
> >> On Mai 28 2018, Richard Biener wrote:
> >>
> >>> It means there's no relocation that can express the result o
On Mon, May 28, 2018 at 5:50 PM Allan Sandfeld Jensen
wrote:
> On Montag, 28. Mai 2018 12:58:20 CEST Richard Biener wrote:
> > compile-time effects of the patch on that. Embedded folks may want to
rhn
> > their favorite benchmark and report results as well.
> >
> > So I did a -O2 -march=haswell [
19 matches
Mail list logo
