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 [
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
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)
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
> 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
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 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,
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 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
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 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: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/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
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/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
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 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
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
19 matches
Mail list logo
