On 01/27/2016 12:12 AM, David Wohlferd wrote:
I started by just commenting out the code in ix86_md_asm_adjust that
unconditionally clobbered the flags. I figured this would allow the
'normal' "cc" handling to occur. But apparently there is no 'normal'
"cc" handling.
I have a dim memory that t
It is well known that on i386, the "cc" clobber is always set for
extended asm, whether it is specified or not. I was wondering how much
difference it might make if the generated code actually followed what
the user specified (expectation: not much). But implementing this
turned up a differen
Snapshot gcc-5-20160126 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/5-20160126/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5
On 26.01.2016 21:47, Richard Biener wrote:
>>> So, hookize and change to
>>>
>>> if (outgoing && POINTER_TYPE_P (TREE_TYPE (TREE_TYPE (func
>>> ...
>>> else if (POINTER_TYPE_P (valtype))
>>>...
>>> else
>>>...
>> Looks good and clean to me, but I expect my patch to have the sam
On January 26, 2016 8:03:35 PM GMT+01:00, Michael Karcher
wrote:
>On 26.01.2016 16:40, Richard Biener wrote:
>> No, the patch looks somewhat broken to me. A complete fix would
>replace
>> the target macro FUNCTION_VALUE implementation by implementing the
>> function_value hook instead (to also r
On Fri, 2016-01-22 at 08:27 +0100, Matthias Klose wrote:
> On 22.01.2016 06:09, Martin Michlmayr wrote:
> > In terms of build failures, I reported 520 bugs to Debian. Most of them
> > were new GCC errors or warnings (some packages use -Werror and many
> > -Werror=format-security).
> >
> > Here are
On 26.01.2016 16:40, Richard Biener wrote:
> No, the patch looks somewhat broken to me. A complete fix would replace
> the target macro FUNCTION_VALUE implementation by implementing the
> function_value hook instead (to also receive the function type called if no
> decl is available and to be able
On 01/21/2016 11:04 AM, Shiv Shankar Dayal wrote:
Hi,
I am a C/C++ programmer with 10 years of professional programming
experience. I have been using gcc since version 2.
I am not a compiler expert but would like to start contributing to gcc
for which I need forms which require submission from
On 01/26/2016 09:36 AM, Bin.Cheng wrote:
On Tue, Jan 26, 2016 at 4:26 PM, Jeff Law wrote:
On 01/26/2016 02:28 AM, Bin.Cheng wrote:
Yes, loop invariant now increased invariant cost if the invariant
can't be propagated into address expression. Problem is we check
propagation by simply replacin
On Tue, Jan 26, 2016 at 4:26 PM, Jeff Law wrote:
> On 01/26/2016 02:28 AM, Bin.Cheng wrote:
>>
>> Yes, loop invariant now increased invariant cost if the invariant
>> can't be propagated into address expression. Problem is we check
>> propagation by simply replacing use with def in memory referen
On 01/26/2016 02:28 AM, Bin.Cheng wrote:
Yes, loop invariant now increased invariant cost if the invariant
can't be propagated into address expression. Problem is we check
propagation by simply replacing use with def in memory reference then
verifying result insn with verify_changes. Apparently
On Tue, Jan 26, 2016 at 10:21 AM, John Paul Adrian Glaubitz
wrote:
> Hi Richard!
>
> On 01/26/2016 08:01 AM, Richard Biener wrote:
>>> I developed a gcc patch that does not change the code generation for
>>> conforming programs but fixes this non-conforming use-case by always
>>> taking the actual
On 01/26/2016 03:59 AM, John Paul Adrian Glaubitz wrote:
On 01/26/2016 11:07 AM, Andreas Schwab wrote:
John Paul Adrian Glaubitz writes:
Having gcc allow to work with such code would actually allow us
to bootstrap ghc on m68k again which would be awesome :).
The ghc code just needs to be fi
On 01/26/2016 02:21 AM, John Paul Adrian Glaubitz wrote:
Hi Richard!
On 01/26/2016 08:01 AM, Richard Biener wrote:
I developed a gcc patch that does not change the code generation for
conforming programs but fixes this non-conforming use-case by always
taking the actual return type in the call
On 01/26/2016 01:41 AM, Richard Biener wrote:
What I wanted to say is that we preserve the function type used for
the actual call at least until RTL expansion in gimple_call_fntype.
I fixed most of the call expansion code to honor that but back ends
may of course screw up as they still may someh
On Mon, Jan 25, 2016 at 10:47:10PM +0100, Michael Karcher wrote:
> Hello gcc developers,
>
> as discussed in https://ghc.haskell.org/trac/ghc/ticket/11395 (and
> forwarded as PR c/69221), ghc generates non-compliant C code that is not
> compiled as intended on m68k. This is because its internal Cm
On Tue, Jan 26, 2016 at 1:51 PM, Bin.Cheng wrote:
> On Tue, Jan 26, 2016 at 12:56 PM, Bernd Schmidt
> wrote:
>> On 01/26/2016 10:48 AM, Bin.Cheng wrote:
>>>
>>> Yes, I moved whole loop pass (also the pass_web) after combine and it
>>> worked. A combine pass before loop-invariant can fix this pr
On Tue, Jan 26, 2016 at 12:56 PM, Bernd Schmidt wrote:
> On 01/26/2016 10:48 AM, Bin.Cheng wrote:
>>
>> Yes, I moved whole loop pass (also the pass_web) after combine and it
>> worked. A combine pass before loop-invariant can fix this problem.
>> Below passes are currently between loop transform
On 01/26/2016 10:48 AM, Bin.Cheng wrote:
Yes, I moved whole loop pass (also the pass_web) after combine and it
worked. A combine pass before loop-invariant can fix this problem.
Below passes are currently between loop transform and combine:
NEXT_PASS (pass_web);
NEXT_PASS (pass_rt
On Mon, Jan 25 2016, Matthew Fortune wrote:
> My dwarf knowledge is not brilliant but I have had to recently consider
> it for MIPS floating point ABI changes aka FPXX and friends. I don't know
> exactly where this fits in to your whole description but in case it has
> a bearing on this we now hav
On 01/26/2016 12:07 PM, Andreas Schwab wrote:
>> If this bug is actually the same as the m68k bug,
>
> Where did I say that?
> The ghc code just needs to be fixed to not lie in such a blatant way.
> Just like it was changed when ppc64le flagged this as crap code.
John Paul Adrian Glaubitz writes:
> I could just find one bug report which mentions a fix for ppc64el [1],
> are you talking about this one?
Yes.
> If this bug is actually the same as the m68k bug,
Where did I say that?
> why is ghc still working fine on ppc64el?
Because ghc tweaked its crap
On 01/26/2016 11:07 AM, Andreas Schwab wrote:
> John Paul Adrian Glaubitz writes:
>
>> Having gcc allow to work with such code would actually allow us
>> to bootstrap ghc on m68k again which would be awesome :).
>
> The ghc code just needs to be fixed to not lie in such a blatant way.
> Just lik
John Paul Adrian Glaubitz writes:
> Having gcc allow to work with such code would actually allow us
> to bootstrap ghc on m68k again which would be awesome :).
The ghc code just needs to be fixed to not lie in such a blatant way.
Just like it was changed when ppc64le flagged this as crap code.
On Mon, Jan 25, 2016 at 8:05 PM, Bernd Schmidt wrote:
> On 01/25/2016 08:51 PM, Jeff Law wrote:
>>
>> No, the combiner works within a basic block only. There was a group, I
>> believe in Moscow, that worked on a cross-block combiner. It was
>> discussed at the Cauldron in California a few years
On Mon, Jan 25, 2016 at 7:51 PM, Jeff Law wrote:
> On 01/25/2016 11:42 AM, Bin.Cheng wrote:
>>
>>
>> Yuri Rumyantsev suggested we may add a hook to handle GOT related
>> instruction propagation specially so it won't be hoisted out. Is a
>> hook at this stage sounds feasible?
>
> I think that woul
Hi Richard!
On 01/26/2016 08:01 AM, Richard Biener wrote:
>> I developed a gcc patch that does not change the code generation for
>> conforming programs but fixes this non-conforming use-case by always
>> taking the actual return type in the call expression into account, even
>> if the function de
On January 26, 2016 8:25:50 AM GMT+01:00, Jeff Law wrote:
>On 01/26/2016 12:01 AM, Richard Biener wrote:
>> On January 25, 2016 10:47:10 PM GMT+01:00, Michael Karcher
> wrote:
>>> Hello gcc developers,
>>>
>>> as discussed in https://ghc.haskell.org/trac/ghc/ticket/11395 (and
>>> forwarded as PR c
28 matches
Mail list logo
