Hello,
There are a few EXTRA_SPECS rules that are used to custom target runtime
support. For instance, "ldruntime" is used on superh for board
configurations and dynamically support different runtime behaviors.
Illustration of this use with a silly reduced spec
*ldruntime:
+ %{mfoo: -lfoo}
The
On Mon, 7 May 2012, Christian Bruel wrote:
> Making the driver aware about all possible user defined options seems
> unpredictable. Was there any justification on removing this
> functionality or did I miss a point with the EXTRA_SPECS ?
There are several motivations behind requiring all options
On 05/07/2012 12:09 PM, Joseph S. Myers wrote:
> On Mon, 7 May 2012, Christian Bruel wrote:
>
>> Making the driver aware about all possible user defined options seems
>> unpredictable. Was there any justification on removing this
>> functionality or did I miss a point with the EXTRA_SPECS ?
>
>
On Mon, May 7, 2012 at 6:08 AM, Christian Bruel wrote:
>
>
> On 05/07/2012 12:09 PM, Joseph S. Myers wrote:
>> On Mon, 7 May 2012, Christian Bruel wrote:
>>
>>> Making the driver aware about all possible user defined options seems
>>> unpredictable. Was there any justification on removing this
>>>
> I think http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49858 is
> essentially this issue. It can probably be closed as "won't fix",
> though I notice the spec file format is still documented in the user
> manual.
>
> Peter
>
yes, same root problem, although BSP design is a different usage (yet
q
On Mon, 7 May 2012, Christian Bruel wrote:
> > * It would be useful for the compiler to be able to export structured
> > information about all its options for use by tools such as IDEs.
>
> If the option is only supported by a BSP, and not by the compiler, I
> don't see how the compiler could re
FWIW RTEMS has long used BSP provided spec files from the command line. We have
issues with using them in that they are a clear place where we depend on
something that is compiler specific. But we do use them. If the support for the
-specs option suddenly disappeared, we would have a problem.
> What about a generic name such as -fextension- (or both -fextension- and
> -mextension-) for options that GCC itself will ignore, if -mbsp= is
> considered inappropriate? I'd prefer that to delimiting such options with
> --start-specs and --end-specs.
>
you mean, gcc would ignore options
On 05/07/2012 03:11 PM, Christian Bruel wrote:
>
>
>> What about a generic name such as -fextension- (or both -fextension- and
>> -mextension-) for options that GCC itself will ignore, if -mbsp= is
>> considered inappropriate? I'd prefer that to delimiting such options with
>> --start-specs
On 05/07/2012 05:09 AM, Joseph S. Myers wrote:
On Mon, 7 May 2012, Christian Bruel wrote:
Making the driver aware about all possible user defined options seems
unpredictable. Was there any justification on removing this
functionality or did I miss a point with the EXTRA_SPECS ?
There are sever
On 04/26/2012 04:49 AM, Bin.Cheng wrote:
On Wed, Apr 25, 2012 at 10:46 PM, Vladimir Makarov wrote:
On 04/24/2012 11:56 PM, Bin.Cheng wrote:
Hi,
In scan_one_insn, gcc checks whether an insn loads a parameter from
its stack slot, and then
record the fact by decrease the memory cost.
What I do n
On Mon, 7 May 2012, Christian Bruel wrote:
> > What about a generic name such as -fextension- (or both -fextension- and
> > -mextension-) for options that GCC itself will ignore, if -mbsp= is
> > considered inappropriate? I'd prefer that to delimiting such options with
> > --start-specs and --
04/05/2012 09:37, Aurelien Buhrig :
> 03/05/2012 14:14, Aurelien Buhrig :
>> 02/05/2012 21:36, Eric Botcazou :
I have an issue (gcc 4.6.3, private bacakend) when reloading operands of
this insn:
(set (subreg:SI (reg:QI 21 [ iftmp.1 ]) 0)
(lshiftrt:SI (reg/v:SI 24 [ w ]) (co
On 17 December 2009 21:53, Bill Wendling wrote:
> On Dec 16, 2009, at 1:26 AM, Paolo Bonzini wrote:
>
>> On 12/16/2009 03:21 AM, John Regehr wrote:
>>> Hopefully the results are more fair and useful now. Again, feedback is
>>> appreciated.
>>
>> I would also avoid testcases using volatile. Small
Hello,
GCC is well into stage 1 for GCC 4.8, but I haven't seen any proposals
for targets to be deprecated. I have one I would like to put on the
list, so here's something to start a discussion with:
Deprecate all support for 32-bits HP-PA. This includes HP-UX10, and
PA-7000 and older.
To name
On 05/07/2012 11:33 AM, Steven Bosscher wrote:
Hello,
GCC is well into stage 1 for GCC 4.8, but I haven't seen any proposals
for targets to be deprecated. I have one I would like to put on the
list, so here's something to start a discussion with:
Deprecate all support for 32-bits HP-PA. This in
> Hello,
>
> GCC is well into stage 1 for GCC 4.8, but I haven't seen any proposals
> for targets to be deprecated.
All 32-bit Sun Microsystems sun4m systems such as the old
SPARCstation 20 and 10 units. These are still running out there
however Solaris 9 was the last OS to support them. All
On 07.05.2012 19:33, Steven Bosscher wrote:
> Hello,
>
> GCC is well into stage 1 for GCC 4.8, but I haven't seen any proposals
> for targets to be deprecated. I have one I would like to put on the
> list, so here's something to start a discussion with:
>
> Deprecate all support for 32-bits HP-PA
On 05/07/2012 12:45 PM, Dennis Clarke wrote:
Hello,
GCC is well into stage 1 for GCC 4.8, but I haven't seen any proposals
for targets to be deprecated.
All 32-bit Sun Microsystems sun4m systems such as the old
SPARCstation 20 and 10 units. These are still running out there
however Solaris
On 5/7/2012 1:33 PM, Steven Bosscher wrote:
Hello,
GCC is well into stage 1 for GCC 4.8, but I haven't seen any proposals
for targets to be deprecated. I have one I would like to put on the
list, so here's something to start a discussion with:
Deprecate all support for 32-bits HP-PA. This inclu
On Mon, May 7, 2012 at 7:42 PM, Jeff Law wrote:
> On 05/07/2012 11:33 AM, Steven Bosscher wrote:
>>
>> Hello,
>>
>> GCC is well into stage 1 for GCC 4.8, but I haven't seen any proposals
>> for targets to be deprecated. I have one I would like to put on the
>> list, so here's something to start a
On 5/7/2012 1:42 PM, Jeff Law wrote:
On 05/07/2012 11:33 AM, Steven Bosscher wrote:
Hello,
GCC is well into stage 1 for GCC 4.8, but I haven't seen any proposals
for targets to be deprecated. I have one I would like to put on the
list, so here's something to start a discussion with:
Deprecate
On 05/07/2012 12:25 PM, John David Anglin wrote:
There is also a 32-bit netbsd port that a limited number of users are
still using.
Do you know if they're using the open-sourced SOM linker or the 32 bit
ELF stuff?
PA linux runs on both PA 1.1 and 2.0 machines. The runtime is 32-bit.
Kernels
Hello,
I am trying to port some legacy C++ code to properly work in the face of thread
cancellation. Based on information I have gleaned from searching the net, it
appears that any catch(...) handlers that try to finalize the exception must be
augmented to first catch abi::_forced_unwind and si
On 5/7/2012 2:29 PM, Jeff Law wrote:
On 05/07/2012 12:25 PM, John David Anglin wrote:
There is also a 32-bit netbsd port that a limited number of users are
still using.
Do you know if they're using the open-sourced SOM linker or the 32 bit
ELF stuff?
ELF.
PA linux runs on both PA 1.1 and 2
On Mon, May 7, 2012 at 9:14 PM, John David Anglin wrote:
> The maintenance problems that occur are usually not related to the code
> generation. They largely occur because the target is big endian, strict
> alignment, callee copies, etc. The delayed branch support has caused
> many subtle bugs.
On 5/7/2012 2:19 PM, Steven Bosscher wrote:
I didn't find that. These are all the TARGET_PA_11 tests I removed for
my experiment:
- "TARGET_PA_11&& ! TARGET_SOFT_FLOAT"
The setting of the flags is quite subtle. If you look at the pattern
for the first case,
you will see the following:
(def
This is the beta release of binutils 2.22.52.0.3 for Linux, which is
based on binutils 2012 0507 in CVS on sourceware.org plus various
changes. It is purely for Linux.
All relevant patches in patches have been applied to the source tree.
You can take a look at patches/README to see what have been
This patch adds the microblaze-*-rtems* target to gcc.
OK to apply?
2012-05-07 Joel Sherrill
* config.gcc (microblaze-*-rtems*): New target.
* config/microblaze/rtems.h: New file
--
Joel Sherrill, Ph.D. Director of Research& Development
joel.sherr...@oarcorp.comO
Hi,
I noticed gcc predicts huge sizes for asm statements on ix86. This is
due to define_asm_attributes in i386.md, where the length *per single
instruction* in the asm is set to 128. That doesn't look realistic to
me. Is there a good reason for this large value? Or should something
like the patch
On Mon, May 7, 2012 at 3:02 PM, Steven Bosscher wrote:
> Hi,
>
> I noticed gcc predicts huge sizes for asm statements on ix86. This is
> due to define_asm_attributes in i386.md, where the length *per single
> instruction* in the asm is set to 128. That doesn't look realistic to
> me. Is there a go
>
> > Index: config/i386/i386.md
> > ===
> > --- config/i386/i386.md (revision 187257)
> > +++ config/i386/i386.md (working copy)
> > @@ -661,7 +661,7 @@
> >
> > ;; Describe a user's asm statement.
> > (define_asm_attributes
> > -
On Mon, May 7, 2012 at 4:28 PM, Jan Hubicka wrote:
> >
>> > Index: config/i386/i386.md
>> > ===
>> > --- config/i386/i386.md (revision 187257)
>> > +++ config/i386/i386.md (working copy)
>> > @@ -661,7 +661,7 @@
>> >
>> > ;; Describ
On Mon, May 7, 2012 at 10:20 PM, Vladimir Makarov wrote:
> On 04/26/2012 04:49 AM, Bin.Cheng wrote:
>>
>> On Wed, Apr 25, 2012 at 10:46 PM, Vladimir Makarov
>> wrote:
>>>
>>> On 04/24/2012 11:56 PM, Bin.Cheng wrote:
Hi,
In scan_one_insn, gcc checks whether an insn loads a parameter
34 matches
Mail list logo
