On Tue, Aug 1, 2017 at 6:00 PM, James Greenhalgh
wrote:
> On Tue, Aug 01, 2017 at 11:12:12AM -0400, Eric Gallager wrote:
>> On 8/1/17, Jakub Jelinek wrote:
>> > On Tue, Aug 01, 2017 at 07:08:41AM -0400, Eric Gallager wrote:
>> >> > Heh. I suspect -Os would benefit from a separate compilation pip
Status
==
The GCC 7 branch is now frozen for the upcoming release candidate
and release. All changes require release manager approval.
Link on this page https://gcc.gnu.org/gcc-7/changes.html for "Profile Mode":
* The libstdc++ Profile Mode has been deprecated and will be removed
in a future version.
gives:
Not Found
The requested URL
/onlinedocs/gcc-7.1.0/libstdc++/manual/profile_mode.html was not found
on this server.
Summary
===
This is an RFC about some C language changes to support ARM's Scalable
Vector Extension (SVE). A detailed description of SVE is available here:
https://static.docs.arm.com/ddi0584/a/DDI0584A_a_SVE_supp_armv8A.pdf
but the only feature that really matters for this RFC is that
On Tue, Aug 01, 2017 at 01:50:14PM +0200, David Brown wrote:
> I would not expect that to be good at all. With no optimisation (-O0),
> gcc produces quite poor code - local variables are not put in registers
> or "optimised away", there is no strength reduction, etc. For an
> architecture like th
On Wed, Aug 2, 2017 at 3:54 PM, Segher Boessenkool
wrote:
> On Tue, Aug 01, 2017 at 01:50:14PM +0200, David Brown wrote:
>> I would not expect that to be good at all. With no optimisation (-O0),
>> gcc produces quite poor code - local variables are not put in registers
>> or "optimised away", the
On Wed, 2 Aug 2017, Richard Sandiford wrote:
> (1) Does the approach seem reasonable?
>
> (2) Would it be acceptable in principle to add this extension to the
> GCC C frontend (only enabled where necessary)?
>
> (3) Should we submit this to the standards committee?
I think this only
Hi Joseph,
Thanks for the quick feedback.
Joseph Myers writes:
> On Wed, 2 Aug 2017, Richard Sandiford wrote:
>
>> (1) Does the approach seem reasonable?
>>
>> (2) Would it be acceptable in principle to add this extension to the
>> GCC C frontend (only enabled where necessary)?
>>
>>
On Wed, 2017-08-02 at 14:09 +0100, Richard Sandiford wrote:
> (1) Does the approach seem reasonable?
>
> (2) Would it be acceptable in principle to add this extension to the
> GCC C frontend (only enabled where necessary)?
>
> (3) Should we submit this to the standards committee?
I h
Torvald Riegel writes:
> On Wed, 2017-08-02 at 14:09 +0100, Richard Sandiford wrote:
>> (1) Does the approach seem reasonable?
>>
>> (2) Would it be acceptable in principle to add this extension to the
>> GCC C frontend (only enabled where necessary)?
>>
>> (3) Should we submit this
I'm writing a test to verify that multiple attribute aligned
specifiers on a function declaration are handled correctly
(bug 81566). In the test I need to know the default function
alignment for the target(*). I've the FUNCTION_BOUNDARY macro
used to set the default alignment for a function (IIU
On Wed, 2 Aug 2017, Martin Sebor wrote:
> If there is no way, would enhancing target-supports.exp to
> include a header that defines the macro? (I assume that would
> be gcc/target.h for FUNCTION_BOUNDARY).
target.h is for target hooks, not target macros, and we want to move away
from target mac
On 08/02/2017 11:37 AM, Joseph Myers wrote:
On Wed, 2 Aug 2017, Martin Sebor wrote:
If there is no way, would enhancing target-supports.exp to
include a header that defines the macro? (I assume that would
be gcc/target.h for FUNCTION_BOUNDARY).
target.h is for target hooks, not target macros,
On 07/21/2017 12:14 PM, Georg-Johann Lay wrote:
> Sebastian Huber schrieb:
>> Hello,
>>
>> there are some files in gcc/config/* that contain the GCC Runtime
>> Library Exception
>>
>> grep -r --include='*.[ch]' 'GCC Runtime Library Exception' -l
>> gcc/config | wc
>> 186 1865361
>>
>> a
On 26/07/17 18:54, Jeff Law wrote:
> On 07/17/2017 02:35 PM, Richard Henderson wrote:
>> On 07/17/2017 12:20 AM, Richard Biener wrote:
>>> On Sun, Jul 16, 2017 at 12:51 AM, Segher Boessenkool
Now what should it take as input? An rtx_insn, or just the pattern
(as insn_rtx_cost does)?
>>>
On 08/02/2017 12:34 PM, Richard Earnshaw wrote:
> I'm not sure if that's a good or a bad thing. Currently the mid-end
> depends on some rtx constructs having sensible costs even if there's no
> rtl pattern to match them (IIRC plus:QI is one such construct - RISC
> type machines usually lack such a
On Wed, Aug 02, 2017 at 08:34:20PM +0100, Richard Earnshaw wrote:
> >> A lot of really complex by-hand pattern matching goes away if you know
> >> the instruction is valid, and you can look up an insn attribute. That
> >> suggests passing the insn and not the PATTERN.
> > Good point. In fact, it
On Wed, Aug 02, 2017 at 12:56:58PM -0700, Richard Henderson wrote:
> On 08/02/2017 12:34 PM, Richard Earnshaw wrote:
> > I'm not sure if that's a good or a bad thing. Currently the mid-end
> > depends on some rtx constructs having sensible costs even if there's no
> > rtl pattern to match them (II
Hi Honza,
While testing improvements to GCC attribute handling I came
across the warning below:
In file included from
/ssd/src/gcc/81544/libstdc++-v3/src/c++98/mt_allocator.cc:31:0:
/ssd/build/gcc-81544/x86_64-pc-linux-gnu/libstdc++-v3/include/ext/mt_allocator.h:359:43:
warning: ‘const’ attrib
Snapshot gcc-6-20170802 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20170802/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6
Hi GCC developers,
As ChangeLog-2013 mentioned:
2013-08-05 David Malcolm
This is the automated part of the conversion of passes from C
structs to C++ classes.
...
* auto-inc-dec.c (pass_inc_dec): Convert from a global struct to a
subclass of rtl_opt_pass along with...
so I
I'm working on a patch to modify the testsuite to obey the
--load-average value if one is passed to make. It seems to work pretty
well, except for libstdc++ which doesn't load gcc/libs/gcc-defs.exp
since it defines it's own ${tool}_functions. I haven't dug too deeply
into libstdc++'s testsuite ye
22 matches
Mail list logo
