Hi Janne,
On 11 December 2015 at 12:12, Janne Blomqvist wrote:
> On Wed, Dec 9, 2015 at 4:27 PM, Yvan Roux wrote:
>> Hi,
>>
>> as it was raised in
>> https://gcc.gnu.org/ml/gcc-patches/2015-10/msg01540.html we experiment
>> random failures in gfortran validation when it is run in parallel (-j
>>
Hi,
On 15. Dezember 2015 23:43, Joseph Myers wrote:
> I think the typical use of basic asm is: you want to manipulate I/O
> registers or other such state unknown to the compiler (not any registers
> the compiler might use itself), and you want to do it in a way that is
> maximally compatible with
Snapshot gcc-4.9-20151216 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.9-20151216/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.9 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On 12/15/2015 12:42 PM, paul_kon...@dell.com wrote:
In the codebase for the product I work on, I see about 200 of them. Many of those are the likes of
asm("sync") for MIPS, which definitely wants to be treated as if it were asm ("sync" : :
: "memory").
That's right, I meant to ask you about
On 12/15/2015 1:13 PM, Jeff Law wrote:
Sadly, I'm putting most of this discussion into my gcc-7 queue anyway.
Fair enough. If "clobbers" is what we're going to do, that sounds more
like a phase 1 thing.
That said, some people who have this problem may prefer to fix it sooner
rather than la
On 12/15/2015 5:01 PM, paul_kon...@dell.com wrote:
On Dec 15, 2015, at 5:22 PM, David Wohlferd wrote:
On 12/14/2015 1:53 AM, Andrew Haley wrote:
This just seems like another argument for deprecating basic asm and pushing
people to extended.
Yes. I am not arguing against deprecation. We sho
On 12/15/2015 2:43 PM, Joseph Myers wrote:
On Tue, 15 Dec 2015, David Wohlferd wrote:
Unlike top level, using basic asm within a function is deprecated. No new code
should use this feature, but should use extended asm instead. Existing code
should begin replacing such usage. Instances of affec
Hi,
PR 68948 shows a case which has been broken for a long time and very
hard to see. So I am recommending that we introduce an assert inside
the gimplifier if we process an error_mark_node and there was no
errors or sorrys from the front-end; I will send a patch if there is a
general feeling th
