Looks great to me. Just noticed one small nit: in the extended asm
section, "=irm" isn't valid, since you can't assign to an immediate.
Doh! I probably copied this from the Input section. Good catch.
Also, in the section about clobbers:
It causes the compiler to flush all registers to
Is there some way to get insight into which alternatives get used
during a coverage run?
On Thu, Mar 27, 2014 at 07:51:06PM -0400, Niranjan Hasabnis wrote:
> Hi DJ Delorie,
>
> Thank you for your answer. It is useful. One more question: so does the
> main testsuite cover all md entries? Meaning all possible assembly
> instructions that could be generated by that md are checked by the
Hi DJ Delorie,
Thank you for your answers. It is very much the information that
I was looking for.
On Thu, Mar 27, 2014 at 7:57 PM, DJ Delorie wrote:
>
> The main testsuite doesn't have tests specifically to cover all the md
> entries. What I meant was, I suspect it covers enough plain C test
>
The main testsuite doesn't have tests specifically to cover all the md
entries. What I meant was, I suspect it covers enough plain C test
cases to happen to use all the usual md entries.
Since each target has different md entries (both "which are used" and
"how each is used"), it would be nearly
Hi DJ Delorie,
Thank you for your answer. It is useful. One more question: so does the
main testsuite cover all md entries? Meaning all possible assembly
instructions that could be generated by that md are checked by the
main testsuite? Thank you again.
On Thu, Mar 27, 2014 at 7:22 PM, DJ Delorie
I've thought about making a dejagnu testsuite specifically for helping
with new ports, which would mean lots of md-specific tests, but
really, the main testsuite probably covers everything you'd need to
test. All patches are supposed to be regression tested anyway, which
means running the full de
Snapshot gcc-4.8-20140327 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.8-20140327/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.8 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
On Thu, Mar 27, 2014 at 6:48 AM, Manuel López-Ibáñez
wrote:
> On 27/03/14 09:52, Florian Weimer wrote:> On 03/27/2014 08:44 AM,
> Andrew Haley wrote:
>>
>>> On 03/26/2014 03:05 PM, Daniel Gutson wrote:
>>>
assigning a negative literal to an unsigned variable issues no
warning:
Hello,
I am very curious to know what kind of testing techniques are applied to
machine description files. To be precise, is there any unit-testing environment
when some instructions are added/removed from MD file, or any other testing
technique is applied? Also, when MD file is patched to fix a b
other
On 03/27/2014 02:50 PM, Felix Yang wrote:
I find DCE in sched2 is disabled for C6X backend. Is this a
performance consideration? Or a GCC BUG?
As far as I remember, it's a problem due to how delayed instructions are
represented to the final scheduler. Just before that scheduling pass is
Quoting Andrew Haley :
On 03/27/2014 08:52 AM, Florian Weimer wrote:
On 03/27/2014 08:44 AM, Andrew Haley wrote:
On 03/26/2014 03:05 PM, Daniel Gutson wrote:
assigning a negative literal to an unsigned variable issues
no warning:
unsigned int x;
x =- 4;
This is specially
On Thu, 27 Mar 2014 16:02:49 +
Julian Brown wrote:
> On Thu, 27 Mar 2014 09:41:28 -0600
> Jeff Law wrote:
>
> > On 03/27/14 07:50, Felix Yang wrote:
> > > Hello,
> > >
> > > I find DCE in sched2 is disabled for C6X backend. Is this a
> > > performance consideration? Or a GCC BUG?
> > >
On Thu, 27 Mar 2014 09:41:28 -0600
Jeff Law wrote:
> On 03/27/14 07:50, Felix Yang wrote:
> > Hello,
> >
> > I find DCE in sched2 is disabled for C6X backend. Is this a
> > performance consideration? Or a GCC BUG?
> > And under what situations should we disable DCE in sched2?
> > C
On 03/27/14 07:50, Felix Yang wrote:
Hello,
I find DCE in sched2 is disabled for C6X backend. Is this a
performance consideration? Or a GCC BUG?
And under what situations should we disable DCE in sched2?
Can anyone explain this? Many thanks.
In general, if a port is disabling an o
On Mar 27, 2014, at 6:38 AM, Renato Golin wrote:
> On 27 March 2014 10:29, Andreas Schwab wrote:
>> Depends on what you need the value for.
>
> Mostly unwind code that uses both FP and SP, example:
But unwind code is inherently platform-dependent. Your objection to the inline
asm that refer
On 27 March 2014 15:06, wrote:
> But unwind code is inherently platform-dependent. Your objection to the
> inline asm that references SP by name is that it's platform dependent. The
> builtin would reduce the amount of platform dependent code by one line, i.e.,
> probably much less than one
On 27 March 2014 14:44, Behan Webster wrote:
> That is what led to this proposal.
I'm having a go at implementing named registers, and I also have
started a thread in the LLVM mailing list. Let's see how it goes...
> For the existing cases this is true. However such a builtin would allow it
> t
On 03/27/14 03:44, Andrew Pinski wrote:
On Thu, Mar 27, 2014 at 3:25 AM, Renato Golin wrote:
On 27 March 2014 10:12, Andreas Schwab wrote:
Can't you use __builtin_frame_address (0) instead?
That would give me the frame pointer, not the stack pointer, and the
user would have to calculate manu
On 03/27/14 04:20, Renato Golin wrote:
Hi Jakub,
Just to make it clear, I'm not an official representative of Clang, or
LLVM, nor I was involved in all discussions about implementing
extensions either. I do not have an agenda to promote LLVM changes.
I also don't speak for either clang nor the L
Hello,
I find DCE in sched2 is disabled for C6X backend. Is this a
performance consideration? Or a GCC BUG?
And under what situations should we disable DCE in sched2?
Can anyone explain this? Many thanks.
The code snippet:
static void
c6x_reorg (void)
{
basic_block bb;
rtx *call_
Hi,
Look at the attributes as defining the interface provided by AST to the code
generator.
The code generator will work with any AST providing this interface. As you want
to reuse the
existing code, its structure affects the way in which you define this interface
(i.e. the
attributes).
The
On 27 March 2014 11:33, Jakub Jelinek wrote:
> Sure, normally register keyword is just a hint, that e.g. GCC I think
> ignores whenever optimizing (for -O0 it means a variable doesn't have to
> be allocated on the stack), but when it is part of the GNU global/local
> register
> variable extension
On Thu, Mar 27, 2014 at 11:20:09AM +, Renato Golin wrote:
> On 27 March 2014 10:44, Jakub Jelinek wrote:
> > I don't see what is wrong with this, this isn't inline asm, it is
> > the local register var GNU extension,
>
> The argument I remember hearing of is the joint of:
> 1. The "register"
On 27 March 2014 10:25, Renato Golin wrote:
> On 27 March 2014 10:12, Andreas Schwab wrote:
>> Can't you use __builtin_frame_address (0) instead?
>
> That would give me the frame pointer, not the stack pointer, and the
> user would have to calculate manually the offset to get the actual
> stack p
Hi Jakub,
Just to make it clear, I'm not an official representative of Clang, or
LLVM, nor I was involved in all discussions about implementing
extensions either. I do not have an agenda to promote LLVM changes.
> To me this sounds like clang proposing extensions because they aren't
> willing to
On Thu, Mar 27, 2014 at 03:44:39AM -0700, Andrew Pinski wrote:
> > (so you need to split by arch with ifdefs),
>
> Except it is already in the kernel anyways; not even by ifdefs but by
> different files so the reasoning adding a new builtin is not useful.
Not to mention that the kernel probably w
On Thu, Mar 27, 2014 at 11:25:29AM +0100, Svante Signell wrote:
> Of course not, but what's hindering upgrading the build system tools
> when new source versions are released. And again, will the autotools
> ever be backwards compatible?
The autotools required versions change over time, but alway
On 27 March 2014 10:47, Andrew Pinski wrote:
> Please don't add a close list to the CC of GCC lists it is annoying.
I didn't realise this list was closed, sorry.
--renato
On Thu, Mar 27, 2014 at 3:44 AM, Andrew Pinski wrote:
> On Thu, Mar 27, 2014 at 3:25 AM, Renato Golin wrote:
>> On 27 March 2014 10:12, Andreas Schwab wrote:
>>> Can't you use __builtin_frame_address (0) instead?
>>
>> That would give me the frame pointer, not the stack pointer, and the
>> user
On Thu, Mar 27, 2014 at 3:25 AM, Renato Golin wrote:
> On 27 March 2014 10:12, Andreas Schwab wrote:
>> Can't you use __builtin_frame_address (0) instead?
>
> That would give me the frame pointer, not the stack pointer, and the
> user would have to calculate manually the offset to get the actual
On Thu, Mar 27, 2014 at 09:38:11AM +, Renato Golin wrote:
> There is a common pattern on bare-metal code to refer to the value of
> registers directly in a variable:
>
> register unsigned long current_stack_pointer asm("sp");
I don't see what is wrong with this, this isn't inline asm, it is
On 27 March 2014 10:25, Svante Signell wrote:
> On Thu, 2014-03-27 at 10:10 +, Jonathan Wakely wrote:
>> On 27 March 2014 09:35, Svante Signell wrote:
>> > - In an ideal situation no generated files should be shipped with a
>> > distribution, i.e. only configure.ac and Makefile.am, no configure
On 27 March 2014 10:29, Andreas Schwab wrote:
> Depends on what you need the value for.
Mostly unwind code that uses both FP and SP, example:
http://git.linuxfoundation.org/?p=llvmlinux/kernel.git;a=commit;h=a875939682dc43bf244bd39a356bca76ac190d77
http://git.linuxfoundation.org/?p=llvmlinux/ker
Renato Golin writes:
> On 27 March 2014 10:12, Andreas Schwab wrote:
>> Can't you use __builtin_frame_address (0) instead?
>
> That would give me the frame pointer, not the stack pointer, and the
> user would have to calculate manually the offset to get the actual
> stack pointer, which would be
On 27 March 2014 10:12, Andreas Schwab wrote:
> Can't you use __builtin_frame_address (0) instead?
That would give me the frame pointer, not the stack pointer, and the
user would have to calculate manually the offset to get the actual
stack pointer, which would be target-specific, possibly making
On 03/27/2014 08:52 AM, Florian Weimer wrote:
> On 03/27/2014 08:44 AM, Andrew Haley wrote:
>
>> On 03/26/2014 03:05 PM, Daniel Gutson wrote:
>>
>>> assigning a negative literal to an unsigned variable issues no warning:
>>>
>>>
>>> unsigned int x;
>>> x =- 4;
>>>
>>> This is speciall
On Thu, 2014-03-27 at 10:10 +, Jonathan Wakely wrote:
> On 27 March 2014 09:35, Svante Signell wrote:
> > - In an ideal situation no generated files should be shipped with a
> > distribution, i.e. only configure.ac and Makefile.am, no configure,
> > Makefile.in Makefile when not needed!
>
> Bu
On 27 March 2014 08:52, Florian Weimer wrote:
> Yes, this warning needs to take whitespace into account. But then, I
> suppose it would be fine.
That's what I was thinking. I've never seen someone write x =- 4 intentionally.
People who write x=-4 without any whitespace at all would just have to
Renato Golin writes:
> Basically, introducing the builtin: __builtin_stack_pointer() which
> will return the stack pointer register's value. There's no guarantee
> that the register will contain the information you want (for example,
> if the surrounding code uses it) and is only meant to replace
On 27 March 2014 09:35, Svante Signell wrote:
> - In an ideal situation no generated files should be shipped with a
> distribution, i.e. only configure.ac and Makefile.am, no configure,
> Makefile.in Makefile when not needed!
But then end users need to have the autotools installed.
Installing alt
On 27/03/14 09:52, Florian Weimer wrote:> On 03/27/2014 08:44 AM,
Andrew Haley wrote:
>
>> On 03/26/2014 03:05 PM, Daniel Gutson wrote:
>>
>>> assigning a negative literal to an unsigned variable issues no warning:
>>>
>>>
>>> unsigned int x;
>>> x =- 4;
>>>
>>> This is specially impor
Previous patch is wrong, I did a mistake in name ;)
Martin
On 03/27/2014 09:52 AM, Martin Liška wrote:
On 03/25/2014 09:50 PM, Jan Hubicka wrote:
Hello,
I've been compiling Chromium with LTO and I noticed that WPA
stream_out forks and do parallel:
http://gcc.gnu.org/ml/gcc-patches/2013-11
Hi there,
There is a common pattern on bare-metal code to refer to the value of
registers directly in a variable:
register unsigned long current_stack_pointer asm("sp");
But not only that depends on the register names (so you need to split
by arch with ifdefs), but it also uses a non-guaranteed
On Thu, 2014-03-27 at 13:36 +0800, Chung-Ju Wu wrote:
> 2014-03-26 18:24 GMT+08:00 Svante Signell :
> > Hi,
> >
> > With the recent changes of not using automake for the build, only
> > auto{re}conf I have problems generating an updated Makefile.in from a
> > modified Makfile.am. Source is gcc-4.9-
On 03/27/2014 08:44 AM, Andrew Haley wrote:
On 03/26/2014 03:05 PM, Daniel Gutson wrote:
assigning a negative literal to an unsigned variable issues no warning:
unsigned int x;
x =- 4;
This is specially important in typos when -= was intended instead of =-
Would be acceptable
On 03/25/2014 09:50 PM, Jan Hubicka wrote:
Hello,
I've been compiling Chromium with LTO and I noticed that WPA
stream_out forks and do parallel:
http://gcc.gnu.org/ml/gcc-patches/2013-11/msg02621.html.
I am unable to fit in 16GB memory: ld uses about 8GB and lto1 about
6GB. When WPA start t
> From: Andrew Haley [mailto:a...@redhat.com]
>
> The trouble with warnings like this is that they trigger far too
> frequently on good (i.e. correct, reasonable, just as the programmer
> intended) code. They bring warnings into disrepute. They also cause
> people to do extra work just to shut t
On 03/27/2014 08:05 AM, Thomas Preud'homme wrote:
>> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
>> Andrew Haley
>>
>> Assigning a negative literal to an unsigned variable is well-defined
>> standard C. Is it really appropriate to warn for correct code?
>
> There is lo
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> Andrew Haley
>
> Assigning a negative literal to an unsigned variable is well-defined
> standard C. Is it really appropriate to warn for correct code?
There is lots of cases where gcc warn construct in correct code. Thin
dw writes:
>> I think it really is general though. In:
>>> The same problem can occur if one output parameter (@var{a}) allows a
>>> register constraint, is updating the parameter value, and references an
>>> address while another output parameter (@var{b}) allows a memory
>>> constraint.
>
> Yep,
Hi,
On 03/26/2014 03:05 PM, Daniel Gutson wrote:
> assigning a negative literal to an unsigned variable issues no warning:
>
>
>unsigned int x;
>x =- 4;
>
> This is specially important in typos when -= was intended instead of =-
>
> Would be acceptable if I add a new warning to ha
53 matches
Mail list logo
