On 11/15/13 06:47, Dominique Dhumieres wrote:
On Wed Nov 13 07:53:25 2013, Jeff Law wrote:
I'll have a patch going through testing overnight.
If you have a patch, could you post it please?
It's checked into the trunk. Ada, at least on x86_64 should be
functional again.
jeff
On Wed Nov 13 07:53:25 2013, Jeff Law wrote:
> I'll have a patch going through testing overnight.
If you have a patch, could you post it please?
TIA
Dominique
On Tue, Nov 12, 2013 at 8:42 AM, Jeff Law wrote:
> On 11/10/13 20:11, Jeff Law wrote:
>>
>> OK. It sounds like there's a pretty general consensus that we ought ot
>> go ahead and leave in a load/store of a NULL pointer. I'll go ahead and
>> run with that. I'll probably just emit SSA_NAME = *0,
On Wed, Nov 13, 2013 at 7:53 AM, Jeff Law wrote:
> On 11/12/13 15:33, Dominique Dhumieres wrote:
>>
>> Bootstrapping with ada id broken by revision 204708
>> (at least on x86_64-apple-darwin13):
>>
>> ...
>> # gnattools1
>> /Applications/Xcode.app/Contents/Developer/usr/bin/make -C
>> ../gcc/ada/t
On Wed, Nov 13, 2013 at 6:54 AM, Jeff Law wrote:
> On 11/12/13 15:33, Dominique Dhumieres wrote:
>>
>> Bootstrapping with ada id broken by revision 204708
>> (at least on x86_64-apple-darwin13):
>>
>> ...
>> # gnattools1
>> /Applications/Xcode.app/Contents/Developer/usr/bin/make -C
>> ../gcc/ada/t
On 11/12/13 15:33, Dominique Dhumieres wrote:
Bootstrapping with ada id broken by revision 204708
(at least on x86_64-apple-darwin13):
...
# gnattools1
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../gcc/ada/tools -f
../Makefile \
"CC=../../xgcc -B../../" "CXX=../../xg++
On 11/12/13 15:33, Dominique Dhumieres wrote:
Bootstrapping with ada id broken by revision 204708
(at least on x86_64-apple-darwin13):
...
# gnattools1
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../gcc/ada/tools -f
../Makefile \
"CC=../../xgcc -B../../" "CXX=../../xg++
On 11/12/13 15:33, Dominique Dhumieres wrote:
Bootstrapping with ada id broken by revision 204708
(at least on x86_64-apple-darwin13):
...
# gnattools1
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../gcc/ada/tools -f
../Makefile \
"CC=../../xgcc -B../../" "CXX=../../xg++
On Tue, 12 Nov 2013, Jeff Law wrote:
> On 11/12/13 16:42, Joseph S. Myers wrote:
> > On Tue, 12 Nov 2013, Dominique Dhumieres wrote:
> >
> > > Bootstrapping with ada id broken by revision 204708
> > > (at least on x86_64-apple-darwin13):
> >
> > I also see this on x86_64-unknown-linux-gnu.
> I'l
On 11/12/13 16:42, Joseph S. Myers wrote:
On Tue, 12 Nov 2013, Dominique Dhumieres wrote:
Bootstrapping with ada id broken by revision 204708
(at least on x86_64-apple-darwin13):
I also see this on x86_64-unknown-linux-gnu.
I'll look at it later tonight (presumably you're both seeing the same
On Tue, 12 Nov 2013, Dominique Dhumieres wrote:
> Bootstrapping with ada id broken by revision 204708
> (at least on x86_64-apple-darwin13):
I also see this on x86_64-unknown-linux-gnu.
--
Joseph S. Myers
jos...@codesourcery.com
Bootstrapping with ada id broken by revision 204708
(at least on x86_64-apple-darwin13):
...
# gnattools1
/Applications/Xcode.app/Contents/Developer/usr/bin/make -C ../gcc/ada/tools -f
../Makefile \
"CC=../../xgcc -B../../" "CXX=../../xg++ -B../../
-B../../../x86_64-apple-darwin13.0.0/
On 11/12/13 10:14, Marc Glisse wrote:
I assume the second LHS should be RHS. Don't you want to mark it somehow
so the next DCE doesn't remove it?
Sigh, yes DCE is removing the load.
That can be fixed by just marking the MEM_REF as volatile and updating
the statement. It's a pretty trivial ch
On Tue, Nov 12, 2013 at 07:08:22PM +0100, Marc Glisse wrote:
> On Tue, 12 Nov 2013, Jeff Law wrote:
>
> >On 11/12/13 10:14, Marc Glisse wrote:
> >>You didn't like Jakub's comment about __builtin_unreachable?
> >No, it's certainly not appropriate for this optimization. The
> >problem with using bu
On Tue, 12 Nov 2013, Jeff Law wrote:
On 11/12/13 10:14, Marc Glisse wrote:
You didn't like Jakub's comment about __builtin_unreachable?
No, it's certainly not appropriate for this optimization. The problem with
using builtin_unreachable is if you do reach that point, you fall into an
unrelat
On 11/12/13 10:14, Marc Glisse wrote:
On Tue, 12 Nov 2013, Jeff Law wrote:
Here's a patch which arranges to leave a null pointer dereferece in
the IL. For a memory load through a null pointer, we just leave the
statement as-is since the LHS is going to be a throw-away SSA_NAME.
For a store thro
On Tue, 12 Nov 2013, Jeff Law wrote:
Here's a patch which arranges to leave a null pointer dereferece in the IL.
For a memory load through a null pointer, we just leave the statement as-is
since the LHS is going to be a throw-away SSA_NAME. For a store through a
null pointer, we try to simpli
On 11/10/13 20:11, Jeff Law wrote:
OK. It sounds like there's a pretty general consensus that we ought ot
go ahead and leave in a load/store of a NULL pointer. I'll go ahead and
run with that. I'll probably just emit SSA_NAME = *0, unless someone
thinks we ought ot distinguish between loads an
18 matches
Mail list logo
