On Thu, 29 Sep 2016, Kyrill Tkachov wrote:
> Hi Richard,
>
> Thanks for the detailed comments, I'll be working on addressing them.
> Below are answers to some of your questions:
>
> On 29/09/16 11:45, Richard Biener wrote:
> >
> > +
> > + /* If we're inserting a non-bytesized width or not at a
On Wed, 28 Sep 2016, Richard Biener wrote:
>
> This fixes the original request in PR77399, better handling of
>
> typedef int v4si __attribute__((vector_size(16)));
> typedef float v4sf __attribute__((vector_size(16)));
> v4sf vec_cast(v4si f)
> {
> return (v4sf){f[0], f[1], f[2], f[3]};
> }
I noticed we intersect ~[a_1, a_1] and [2, 2] to ~[a_1, a_1]. While
we don't generally want to choose an integral range a singleton integral
range is always preferable.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2016-09-30 Richard Biener
* tree-vrp.c (in
On Thu, Sep 29, 2016 at 4:48 PM, Thomas Schwinge
wrote:
> Hi Richard!
>
> On Mon, 19 Sep 2016 13:25:01 +0200, Richard Biener
> wrote:
>> On Mon, Sep 19, 2016 at 1:19 PM, Thomas Schwinge
>> wrote:
>> > On Mon, 19 Sep 2016 10:18:35 +0200, Richard Biener
>> > wrote:
>> >> On Fri, Sep 16, 2016 at
Hi,
this patch mitigates the excessive stack usage on arm in code
that does lots of int64 shift ops like sha512.
It reduces the stack usage in that example from 4K to 2K while
less than 0.5K would be expected.
In all cases the additional set instructions are optimized later
so that this caused n
Hi!
On Thu, Sep 29, 2016 at 10:57:07PM +, Joseph Myers wrote:
> This is missing documentation of the new -Wregister option in invoke.texi.
While I had it in my head when working on the patch, I forgot to do that in the
end.
Fixed thusly, ok for trunk?
2016-09-30 Jakub Jelinek
*
Hello.
Even though we enable by default asan-use-after-return parameter (when
-fsanitize=address is selected),
the runtime does not check use after return by default. I would consider it
useful to document.
It's quite similar to -fsanitize=recover and halt_on_error=0 situation: one has
to enab
On Fri, Sep 30, 2016 at 10:17:45AM +0200, Martin Liška wrote:
> Even though we enable by default asan-use-after-return parameter (when
> -fsanitize=address is selected),
> the runtime does not check use after return by default. I would consider it
> useful to document.
>
> It's quite similar to
> I wonder if we should warn for the TARGET_V2 case? Currently if the
> option is supplied on an ARCv2 (-mcompact-casesi) then the option is
> silently ignored. This might confuse some users.
Good idea, I will update the docs accordingly.
>
> In the non TARGET_V2 case I notice that the optio
On Fri, Sep 30, 2016 at 9:48 AM, Bernd Edlinger
wrote:
> Hi,
>
> this patch mitigates the excessive stack usage on arm in code
> that does lots of int64 shift ops like sha512.
>
> It reduces the stack usage in that example from 4K to 2K while
> less than 0.5K would be expected.
>
> In all cases th
Hi Fritz,
looks OK to me.
- Andre
On Thu, 29 Sep 2016 10:03:58 -0400
Fritz Reese wrote:
> ICE in [1] is due to an incomplete fix for PR fortran/77327 (r239819,
> see [2],[3]). Specifically in interface.c (gfc_compare_derived_types)
> I overlooked the case where FL_UNION type symbols could be c
Hi Fritz,
just out of curiosity: A structure typed can't be used for a class object? Like:
structure /T/
integer :: something
end structure
class(T), allocatable :: foo
end
When the above *is* allowed then I miss some CLASS_DATA (...) in the code. If
not, everything is fine.
- Andre
On Thu
> > + MPYHU DBL0H,r12,DBL0H
>
> Is there a reason that instruction should be uppercase?
>
Yes, MPYHU is a macro which selects the right mnemonic depending on which CPU
you are going to compile (i.e., mpyhu for ARCv1 and mpymu for ARCv2), see
arc-ieee-754.h.
Thanks,
Claudiu
> There's significant whitespace changes in lib1funcs.S that's not
> mentioned in the ChangeLog, and is in parts of the file not touched by
> the actual functional changes.
Yes, there are a lot of trailing spaces which are not complying to GNU
standards. I'm trying to correct those sloppy files
Dear Andre,
Looks good to me - OK for trunk.
Thanks
Paul
On 29 September 2016 at 14:03, Andre Vehreschild wrote:
> Hi all,
>
> attached patch fixes an addressing issue for coarrays *in* derived types.
> Before the patch the caf runtime reference chain was generated from the start
> of the symb
Hi Martin,
>> the testcase FAILs on Solaris 12 (both SPARC and x86):
>>
>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++11 gcov: 1 failures in line
>> counts, 0 i
>> n branch percentages, 0 in return percentages, 0 in intermediate format
>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++11 line 21: is #:
On Thu, Sep 29, 2016 at 10:16:33PM +0200, Jakub Jelinek wrote:
> Hi!
>
> The following patch does a few things:
> 1) fixes -Wimplicit-fallthrough -C
>(with -C the PREV_FALLTHROUGH flag is on the CPP_COMMENT token, we need
> to propagate it to the C/C++ token's flags in the FEs)
> 2) it acc
> A comment before the SETs and a testcase would be nice. IIRC
> we do have stack size testcases via using -fstack-usage.
Or -Wstack-usage, which might be more appropriate here.
--
Eric Botcazou
On Fri, Sep 30, 2016 at 11:26:27AM +0200, Marek Polacek wrote:
> On Thu, Sep 29, 2016 at 10:16:33PM +0200, Jakub Jelinek wrote:
> > The following patch does a few things:
> > 1) fixes -Wimplicit-fallthrough -C
> >(with -C the PREV_FALLTHROUGH flag is on the CPP_COMMENT token, we need
> > to
The recently added tests gcc.target/arm/aapcs-{3,4}.c are intended
to check the behaviour of th ARM Alternative FP16 format. They both
check for compiler support of FP16 using dg-require-effective-target
arm_fp16_ok This is too weak since the directive is true when
fp16-format=ieee is set, as it i
On 29/09/16 14:37, Andre Vieira (lists) wrote:
>
> On arm-none-eabi I'm seeing a failure for the long double type and inputs:
> { 1e-2l, 1e-4l, 1e-4l, 0.0150004999375l }
>
> The abs(frac) is higher than the toler: 1.73455e-16 vs 1e-16. Is that a
> reasonable difference? Should we raise to
> Clearly people are extremely creative with these comments, maybe it would be
> better to just remove the new additions from the patch I've posted (drop
> the else/intentational/intentationally/... around/!!! around etc., to force
> people to standardize on something), and just apply the fixes and
On Fri, Sep 30, 2016 at 11:42:12AM +0200, Eric Botcazou wrote:
> > Clearly people are extremely creative with these comments, maybe it would be
> > better to just remove the new additions from the patch I've posted (drop
> > the else/intentational/intentationally/... around/!!! around etc., to forc
On Fri, Sep 30, 2016 at 11:31:43AM +0200, Jakub Jelinek wrote:
> On Fri, Sep 30, 2016 at 11:26:27AM +0200, Marek Polacek wrote:
> > On Thu, Sep 29, 2016 at 10:16:33PM +0200, Jakub Jelinek wrote:
> > > The following patch does a few things:
> > > 1) fixes -Wimplicit-fallthrough -C
> > >(with -C
In case anybody missed it, the Linux kernel side to make use
of this has also been finished meanwhile. Of course it can not
be accepted without compiler support; and this feature patch
is much more versatile than just Linux kernel live patching
on a single architecture.
How is
On Tue, Sep 27, 2016 at 03:14:51PM -0600, Jeff Law wrote:
> With transposition issue addressed, the only blocker I see are some
> simple testcases we can add to the suite. They don't have to be real
> extensive. And one motivating example for the list archives, ideally
> the glibc malloc case.
On Fri, Sep 30, 2016 at 12:01:47PM +0200, Jose E. Marchesi wrote:
>
> How is this supposed to be exploited atomically in RISC arches such as
> sparc? In such architectures you usually need to patch several
> instructions to load an absolute address into a register.
http://mpe.github.io/posts/201
Eric Botcazou wrote:
>> A comment before the SETs and a testcase would be nice. IIRC
>> we do have stack size testcases via using -fstack-usage.
>
>Or -Wstack-usage, which might be more appropriate here.
Yes. good idea. I was not aware that we already have that kind of tests.
When trying to wr
Hi Paul,
thanks for the fast review. Committed as r240650.
Thanks again,
Andre
On Fri, 30 Sep 2016 11:16:48 +0200
Paul Richard Thomas wrote:
> Dear Andre,
>
> Looks good to me - OK for trunk.
>
> Thanks
>
> Paul
>
> On 29 September 2016 at 14:03, Andre Vehreschild wrote:
> > Hi a
On Sun, Sep 11, 2016 at 01:08:56PM +0100, Andrew Haley wrote:
> On 10/09/16 12:59, NightStrike wrote:
> > Could we at least reach out and see if there's someone else who could
> > be the maintainer? I noticed gcj patches recently, so there's still
> > interest.
>
> 1. It's too late. We have bee
[ whoops, message too big, resending with the attachment compressed ]
On Tue, Sep 27, 2016 at 03:14:51PM -0600, Jeff Law wrote:
> With transposition issue addressed, the only blocker I see are some
> simple testcases we can add to the suite. They don't have to be real
> extensive. And one moti
On 09/30/2016 11:45 AM, Jakub Jelinek wrote:
See Tom Tromey's explanation why accepting too much is bad (at least unless
we want multiple levels).
And I still don't buy it. The case where someone writes "Don't fall
through" is artificial to begin with, and also forgetting to put the
break; t
On Fri, Sep 30, 2016 at 12:42:20PM +0200, Bernd Schmidt wrote:
> On 09/30/2016 11:45 AM, Jakub Jelinek wrote:
>
> >See Tom Tromey's explanation why accepting too much is bad (at least unless
> >we want multiple levels).
>
> And I still don't buy it. The case where someone writes "Don't fall throu
As noted in Bugzilla (and pointed out in LLVM's bugzilla by Richard
Smith) we check for a ::gets() declaration with the default
-std=gnu++14 mode, so for glibc we don't find it, and then we declare
it ourselves in even though it's not meant to exist in C++14.
This adjusts the check to use C++11,
On 09/30/2016 12:51 PM, Jakub Jelinek wrote:
On Fri, Sep 30, 2016 at 12:42:20PM +0200, Bernd Schmidt wrote:
On 09/30/2016 11:45 AM, Jakub Jelinek wrote:
See Tom Tromey's explanation why accepting too much is bad (at least unless
we want multiple levels).
And I still don't buy it. The case
On Fri, Sep 30, 2016 at 12:42:20PM +0200, Bernd Schmidt wrote:
> On 09/30/2016 11:45 AM, Jakub Jelinek wrote:
>
> > See Tom Tromey's explanation why accepting too much is bad (at least unless
> > we want multiple levels).
>
> And I still don't buy it. The case where someone writes "Don't fall thr
On 09/30/2016 11:22 AM, Rainer Orth wrote:
> Hi Martin,
>
>>> the testcase FAILs on Solaris 12 (both SPARC and x86):
>>>
>>> +FAIL: g++.dg/gcov/pr16855.C -std=gnu++11 gcov: 1 failures in line
>>> counts, 0 i
>>> n branch percentages, 0 in return percentages, 0 in intermediate format
>>> +FAIL: g++
On 09/29/2016 07:32 PM, Denys Vlasenko wrote:
On 09/29/2016 04:45 PM, Bernd Schmidt wrote:
On 09/28/2016 02:57 PM, Denys Vlasenko wrote:
- /* Comes from final.c -- no real reason to change it. */
-#define MAX_CODE_ALIGN 16
-
case OPT_malign_loops_:
warning_at (loc, 0, "-malign-loo
It's unclear whether we'll handle /* Else, fall through. */ in the nearest
future, so I'll just change it to a recognizable format instead.
When this is in, I can remove the recently added -Wno-error lines in
Makefile.in.
Bootstrapped on aarch64-linux. I'm checking this in.
2016-09-30 Marek
On 09/30/16 05:22, Rainer Orth wrote:
While this would take care of the testsuite failures, this creates a
terrible user experience outside of the testsuite: if we know that
-fprofile-arcs -ftest-coverage cannot work on targets without
constructor priority support, the compiler should error out
In working on tile I noticed an unnecessary modulo operation for the calculation
of the outermost loop's user iteration variable. By construction the modulo
operator is useless here. Took the opportunity of moving the modulo and
division operations next to eachother so it'd be easier to make u
This adjusts the front page and the news page for each release to
clarify that past releases are no longer maintained.
OK for wwwdocs?
Index: htdocs/index.html
===
RCS file: /cvs/gcc/wwwdocs/htdocs/index.html,v
retrieving revision
On Fri, Sep 30, 2016 at 2:26 PM, Jonathan Wakely wrote:
> This adjusts the front page and the news page for each release to
> clarify that past releases are no longer maintained.
>
> OK for wwwdocs?
Ok.
Thanks,
Richard.
>
.long .LCFI33-.LFB1056
.byte 0xe
.byte 0x10
.byte 0x86
.byte 0x2
.byte 0x4
.long .LCFI34-.LCFI33
.byte 0xd
.byte 0x6
.byte 0x4
.long .LCFI35-.LCFI34
.byte 0xc
.byte 0x7
.byte 0x8
.align 8
.LEFDE23:
.hidden __dso_handle
.ident "GCC: (GNU) 7.0.0 20160930 (experimental) [trunk revision
240649]"
.section.text._ZN4TestC2Ev%_ZN4TestC5Ev,"ax",@progbits
_ZN4TestC5Ev:
.section.text._ZN4TestD2Ev%_ZN4TestD5Ev,"ax",@progbits
_ZN4TestD5Ev:
On 09/30/2016 02:31 PM, Rainer Orth wrote:
> this would be i386-pc-solaris2.12. I'm not sure if the constructor
> priority detection works in a cross scenario.
>
> I'm attaching the resulting assembly (although for Solaris as, the gas
> build is still running).
Hi. Sorry, I have a stupid mistake
On 30/09/16 11:27, Marek Polacek wrote:
> Can we move forward with this patch, then?
I've been travelling for several weeks. However, I'm back at my desk
now, so I can move this forward. I have all the approvals and
everybody has had time to respond. However, I'll need to pull some
more recent
Hi Martin,
> On 09/30/2016 02:31 PM, Rainer Orth wrote:
>> this would be i386-pc-solaris2.12. I'm not sure if the constructor
>> priority detection works in a cross scenario.
>>
>> I'm attaching the resulting assembly (although for Solaris as, the gas
>> build is still running).
>
> Hi. Sorry, I
On 30/09/16 10:31, Matthew Wahab wrote:
The recently added tests gcc.target/arm/aapcs-{3,4}.c are intended
to check the behaviour of th ARM Alternative FP16 format. They both
check for compiler support of FP16 using dg-require-effective-target
arm_fp16_ok This is too weak since the directive is
On 30/09/16 10:35, Szabolcs Nagy wrote:
> On 29/09/16 14:37, Andre Vieira (lists) wrote:
>>
>> On arm-none-eabi I'm seeing a failure for the long double type and inputs:
>> { 1e-2l, 1e-4l, 1e-4l, 0.0150004999375l }
>>
>> The abs(frac) is higher than the toler: 1.73455e-16 vs 1e-16. Is that
On 30/09/16 14:13 +0100, Szabolcs Nagy wrote:
On 30/09/16 10:35, Szabolcs Nagy wrote:
On 29/09/16 14:37, Andre Vieira (lists) wrote:
On arm-none-eabi I'm seeing a failure for the long double type and inputs:
{ 1e-2l, 1e-4l, 1e-4l, 0.0150004999375l }
The abs(frac) is higher than the to
Hi All,
This is v2 of the patch which adds an optimized route to the fpclassify builtin
for floating point numbers which are similar to IEEE-754 in format.
I have addressed most comments from everyone except for two things:
1) Providing a back-end hook to override the functionality. While certai
On 09/30/16 12:14, Bernd Edlinger wrote:
> Eric Botcazou wrote:
>>> A comment before the SETs and a testcase would be nice. IIRC
>>> we do have stack size testcases via using -fstack-usage.
>>
>> Or -Wstack-usage, which might be more appropriate here.
>
> Yes. good idea. I was not aware that we
std::abs isn't suitable for these functions because we need something
that works in constexpr functions and with unsigned types.
Also, is supposed to include .
PR libstdc++/77801
* include/experimental/numeric: Include .
(__abs): Define.
(gcd, lcm): Use __abs ins
This patch to libgo copies the locking code from the Go 1.7 master
library, replacing C code for locking with Go code. The result is
more efficient on most systems, though it is essentially the same on
GNU/Linux.
Add a shell script mkrsysinfo.sh to generate the runtime_sysinfo.go
file, so that we
Please find the updated patch,
Claudiu
gcc/
2016-05-09 Claudiu Zissulescu
* common/config/arc/arc-common.c (arc_option_optimization_table):
Remove compact casesi option.
* config/arc/arc.c (arc_override_options): Use compact casesi
option only for pre-ARCv2 core
In implementing tile I discovered two existing runtime tile tests. These were
only passing because tile was completely ignored. One of them exposes a latent
bug in collapse, in my WIP, but I don't want to get distracted by that right now.
Better to have tile tests test tile tiles.
nathan
201
Hi Richard,
On 29/09/16 11:45, Richard Biener wrote:
+
+ /* In some cases get_inner_reference may return a
+MEM_REF [ptr + byteoffset]. For the purposes of this pass
+canonicalize the base_addr to MEM_REF [ptr] and take
+byteoffset i
On 30/09/16 15:36, Kyrill Tkachov wrote:
Hi Richard,
On 29/09/16 11:45, Richard Biener wrote:
+
+ /* In some cases get_inner_reference may return a
+ MEM_REF [ptr + byteoffset]. For the purposes of this pass
+ canonicalize the base_addr to MEM_REF [ptr] and take
+
On 09/30/2016 01:20 PM, Bernd Schmidt wrote:
On 09/29/2016 07:32 PM, Denys Vlasenko wrote:
On 09/29/2016 04:45 PM, Bernd Schmidt wrote:
On 09/28/2016 02:57 PM, Denys Vlasenko wrote:
- /* Comes from final.c -- no real reason to change it. */
-#define MAX_CODE_ALIGN 16
-
case OPT_malign_l
On 05/09/16 17:25, Gerald Pfeifer wrote:
> And here is the patch for the web pages.
>
> Note I did not include all the removed java/* contents. Is there
> anything particular you'd like to retain there?
No, please delete it all.
Thanks,
Andrew.
On 29/09/16 21:59 +0200, François Dumont wrote:
Hi
I think _GLIBCXX_BEGIN_NAMESPACE_ALGO should default to
_GLIBCXX_BEGIN_NAMESPACE_VERSION when parallel mode is not active.
Same for _GLIBCXX_BEGIN_NAMESPACE_CONTAINER, no ?
Hmm, yes, I think this is correct, otherwise we're missing the VE
I haven't been following the discussion very closely so I may have
missed that what I'm about to suggest has been discussed and rejected
for some valid reason, but if not let me try.
It seems to me that the ultimate, long term goal should be to have
actively maintained code bases gradually migrat
Hi Tadek,
Looks good to me. Thank you.
Clear to send (push).
On Fri, Sep 30, 2016 at 10:10:55AM -0600, Martin Sebor wrote:
> I haven't been following the discussion very closely so I may have
> missed that what I'm about to suggest has been discussed and rejected
> for some valid reason, but if not let me try.
>
> It seems to me that the ultimate, long term
Pushed.
2016-09-30 Andrew Haley
* MAINTAINERS: Move Per Bothner, Andrew Haley, and Tom Tromey to
write-after approval after GCJ deletion.
Index: MAINTAINERS
===
--- MAINTAINERS (revision 240658)
+++ MAINTAINERS (w
On 09/30/2016 10:18 AM, Bruce Korb wrote:
Hi Tadek,
Looks good to me. Thank you.
Clear to send (push).
Committed on behalf of Tadek.
Thanks,
jeff
Hi Andrew,
> Pushed.
>
> 2016-09-30 Andrew Haley
>
> * MAINTAINERS: Move Per Bothner, Andrew Haley, and Tom Tromey to
> write-after approval after GCJ deletion.
but both Per and Tom are still libcpp maintainers, so no need to add
them to the write-after-approval list.
On 30/09/16 17:38, Rainer Orth wrote:
> but both Per and Tom are still libcpp maintainers, so no need to add
> them to the write-after-approval list.
Ooh, I had no idea. Will fix, thanks.
Andrew.
On Fri, Sep 23, 2016 at 10:31:33AM -0400, Jason Merrill wrote:
> On Fri, Sep 23, 2016 at 9:15 AM, Marek Polacek wrote:
> > On Wed, Sep 21, 2016 at 03:52:09PM -0400, Jason Merrill wrote:
> >> On Mon, Sep 19, 2016 at 2:49 PM, Jason Merrill wrote:
> >> > I suppose that an INTEGER_CST of character ty
On Thu, 2016-09-29 18:01:46 +0200, Marek Polacek wrote:
> My upcoming fix revealed more places that were missing a fall through marker.
>
> Bootstrapped/regtested on x86_64-linux, ppc64-linux, and aarch64-linux-gnu
> with
> my fix, applying to trunk.
>
> 2016-09-29 Marek Polacek
>
> *
On 09/29/2016 09:21 PM, Tadek Kijkowski wrote:
Can I have plain-text mode, please, gmail?
:-) Only because you're asking nicely...
# Directory in which the compiler finds libraries etc.
libsubdir =
$(libdir)/gcc/$(real_target_noncanonical)/$(version)$(accel_dir_suffix)
# Directory in whi
On Fri, Sep 30, 2016 at 06:49:17PM +0200, Jan-Benedict Glaw wrote:
> On Thu, 2016-09-29 18:01:46 +0200, Marek Polacek wrote:
> > My upcoming fix revealed more places that were missing a fall through
> > marker.
> >
> > Bootstrapped/regtested on x86_64-linux, ppc64-linux, and aarch64-linux-gnu
>
Hi,
This patch set enables the _Float16 type specified in ISO/IEC TS 18661-3
for AArch64.
To do this, we first need to update the excess precision logic to support
possibly computing _Float16 values in 16-bit range and precision, and to
set the FLT_EVAL_METHOD macro to "16" as appropriate. That r
Hi,
This option is added to control which values of FLT_EVAL_METHOD the
compiler is allowed to set.
ISO/IEC TS 18661-3 defines new permissible values for
FLT_EVAL_METHOD that indicate that operations and constants with
a semantic type that is an interchange or extended format should be
evaluated
Hi,
Now that we've worked on -fexcess-precision, the comment in targhooks.c
no longer holds. We can now permit _Float16 on any target which provides
HFmode and supports HFmode in libgcc.
Bootstrapped and tested on x86-64, and in series on AArch64.
OK?
Thanks,
James
---
2016-09-30 James Green
Hi,
This patch introduces TARGET_C_EXCESS_PRECISION. This hook takes a tri-state
argument, one of EXCESS_PRECISION_TYPE_IMPLICIT,
EXCESS_PRECISION_TYPE_STANDARD, EXCESS_PRECISION_TYPE_FAST. Which relate to
the implicit extra precision added by the target, the excess precision that
should be guara
Hi,
This patch moves the logic for excess precision from using the
TARGET_FLT_EVAL_METHOD macro to the TARGET_EXCESS_PRECISION hook
introduced earlier in the patch series.
These logic changes follow Joseph's comments at
https://gcc.gnu.org/ml/gcc-patches/2016-09/msg00410.html
Briefly; we have f
Hi,
We've removed all uses of TARGET_FLT_EVAL_METHOD, so we can remove it
and poison it.
Bootstrapped and tested on x86-64 and AArch64. Tested on s390 and m68k
to the best of my ability (no execute tests).
OK?
Thanks,
James
---
gcc/
2016-09-30 James Greenhalgh
* config/s390/s390.
Hi Richard,
On 29/09/16 11:45, Richard Biener wrote:
+ gimple_seq seq = NULL;
+ unsigned int num_stmts = 0;
+ tree offset_type = get_type_for_merged_store (group);
+ tree last_vdef, new_vuse;
+ last_vdef = gimple_vdef (group->last_stmt);
+ new_vuse = gimple_vuse (group->last_stmt);
+ loc
Hi,
This patch ports the logic from i386's TARGET_FLT_EVAL_METHOD to the new
target hook TARGET_C_EXCESS_PRECISION.
Bootstrapped and tested with no issues.
OK?
Thanks,
James
---
gcc/
2016-09-30 James Greenhalgh
* config/i386/i386.c (ix86_excess_precision): New.
(TARGET_C_
Hi,
This patch ports the logic from s390's TARGET_FLT_EVAL_METHOD to the new
target hook TARGET_C_EXCESS_PRECISION.
Patch tested by building an s390-none-linux toolchain and running
s390.exp (without the ability to execute) with no regressions, and manually
inspecting the output assembly code wh
On September 30, 2016 4:43:10 PM GMT+02:00, Kyrill Tkachov
wrote:
>
>On 30/09/16 15:36, Kyrill Tkachov wrote:
>> Hi Richard,
>>
>> On 29/09/16 11:45, Richard Biener wrote:
>>>
+
+ /* In some cases get_inner_reference may return a
+ MEM_REF [ptr + byteoffset]. For
Hi,
This patch ports the logic from m68k's TARGET_FLT_EVAL_METHOD to the new
target hook TARGET_C_EXCESS_PRECISION.
Patch tested by building an m68k-none-elf toolchain and running
m68k.exp (without the ability to execute) with no regressions, and manually
inspecting the output assembly code when
Hi,
This patch merges in the support added to glibc for HFmode conversions in
this patch:
commit 87ab10d6524fe4faabd7eb3eac5868165ecfb323
Author: James Greenhalgh
Date: Wed Sep 21 21:02:54 2016 +
[soft-fp] Add support for various half-precision conversion routines.
Hi,
This patch merges in the support added to glibc for HFmode conversions in
this patch:
commit 87ab10d6524fe4faabd7eb3eac5868165ecfb323
Author: James Greenhalgh
Date: Wed Sep 21 21:02:54 2016 +
[soft-fp] Add support for various half-precision conversion routines.
Hi,
Finally, this patch adds the back-end wiring to get AArch64 support for
the _Float16 type working.
Bootstrapped on AArch64 with no issues.
OK?
Thanks,
James
---
2016-09-30 James Greenhalgh
* config/aarch64/aarch64-c.c (aarch64_update_cpp_builtins): Update
__FLT_EVAL_ME
Hi,
This patch enables the conversion functions we need for AArch64's _Float16
support. To do that we need to implement TARGET_SCALAR_MODE_SUPPORTED_P,
so do that now.
OK?
Thanks,
James
---
gcc/
2016-09-30 James Greenhalgh
* config/aarch64/aarch64-c.c (aarch64_scalar_mode_supporte
+ permerror (input_location, "ISO C++11 only allows pointer "
+ "conversions for integer literals");
FWIW, I think it would be clearer to either mention the currently
selected language version or leave it out completely rather than
hardcoding C++11. When t
On 09/25/2016 03:13 AM, Bernd Edlinger wrote:
Hi!
Currently CHECKING_P is not a boolean flag but a ternary option.
However the _P in the name implies it is a boolean.
That should be cleaned up again IMHO.
So this patch splits CHECKING_P into CHECKING_P and a new flag
ENABLE_EXTRA_CHECKING.
On 09/29/2016 12:34 AM, Prasad Ghangal wrote:
Hi all,
I don't know if this is the right time to submit such patches.
But this patch attempts to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31566
I have successfully bootstrapped and tested on x86_64-pc-linux-gnu
testcases:
file:
-Wall
te
On 09/30/2016 10:56 AM, James Greenhalgh wrote:
Hi,
We've removed all uses of TARGET_FLT_EVAL_METHOD, so we can remove it
and poison it.
Bootstrapped and tested on x86-64 and AArch64. Tested on s390 and m68k
to the best of my ability (no execute tests).
OK?
Thanks,
James
---
gcc/
2016-09-3
On 09/30/2016 11:01 AM, James Greenhalgh wrote:
Hi,
This patch ports the logic from m68k's TARGET_FLT_EVAL_METHOD to the new
target hook TARGET_C_EXCESS_PRECISION.
Patch tested by building an m68k-none-elf toolchain and running
m68k.exp (without the ability to execute) with no regressions, and
On 09/30/2016 10:56 AM, James Greenhalgh wrote:
Hi,
Now that we've worked on -fexcess-precision, the comment in targhooks.c
no longer holds. We can now permit _Float16 on any target which provides
HFmode and supports HFmode in libgcc.
Bootstrapped and tested on x86-64, and in series on AArch64
On Fri, 30 Sep 2016, James Greenhalgh wrote:
>/* float.h needs to know this. */
> + /* We already have the option -fno-fp-int-builtin-inexact to ensure
> + certain built-in functions follow TS 18661-1 semantics. It might be
> + reasonable to have a new option to enable FLT_EVAL_METH
On 09/30/2016 10:56 AM, James Greenhalgh wrote:
Hi,
This option is added to control which values of FLT_EVAL_METHOD the
compiler is allowed to set.
ISO/IEC TS 18661-3 defines new permissible values for
FLT_EVAL_METHOD that indicate that operations and constants with
a semantic type that is an
On Fri, 30 Sep 2016, James Greenhalgh wrote:
> + case EXCESS_PRECISION_TYPE_STANDARD:
> + case EXCESS_PRECISION_TYPE_IMPLICIT:
> + /* Otherwise, the excess precision we want when we are
> +in a standards compliant mode, and the implicit precision we
> +provide can be
PR 66443 concerns C++14 DR1611. It is now permitted to use the base-ctor of an
abstract class whos complete ctor is deleted because of a virtual base issue.
Specifically, given
class A {
A (int);
// no default ctor in C++14
};
class B : virtual A {
virtual void Foo () = 0; // abstract
//
On 09/30/2016 11:34 AM, Joseph Myers wrote:
On Fri, 30 Sep 2016, James Greenhalgh wrote:
+ case EXCESS_PRECISION_TYPE_STANDARD:
+ case EXCESS_PRECISION_TYPE_IMPLICIT:
+ /* Otherwise, the excess precision we want when we are
+ in a standards compliant mode, and the impli
2016-09-27 Denys Vlasenko
* config/i386/i386-common.c (ix86_handle_option): Remove support
for obsolete -malign-loops, -malign-jumps and -malign-functions
options.
* config/i386/i386.opt: Likewise.
Index: gcc/common/config/i386/i386-common.c
These patches are for this bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66240
"RFE: extend -falign-xyz syntax"
The test program:
int g();
int f(int i) {
i *= 3;
while (--i > 100) {
L1:if (g()) goto L1;
if (g()) goto L2;
}
return i
1 - 100 of 135 matches
Mail list logo
