On Wed, Feb 20, 2019 at 01:58:58PM -1000, Jason Merrill wrote:
> On 2/20/19 11:52 AM, Jakub Jelinek wrote:
> > On Wed, Feb 20, 2019 at 11:12:07AM -1000, Jason Merrill wrote:
> > > > (z = REALPART_EXPR >;, (bool)
> > > > IMAGPART_EXPR >;);
> > > > which is not potential_constant_expression, but not
On 2/20/19 4:33 PM, David Malcolm wrote:
On Tue, 2019-02-19 at 20:37 +0100, Jakub Jelinek wrote:
On Tue, Feb 19, 2019 at 02:44:55PM -0500, David Malcolm wrote:
How about something like this? (on top of Jakub's patch)
I had following queued for regtest, so if you want to go for the
make_locati
PR89313 exposes a bug in the asmcons pass where it replaces input operands
with matching constraints with their associated output operands, as well as
all other uses of its pseudo registers. This is normally fine. However, if
the matched output operand is marked as early clobber, then we cannot r
This also looks mostly OK to me with only some minor issues that need
to be fixed.
On Tue, Feb 12, 2019 at 11:17 PM Kito Cheng wrote:
>
> From: Kito Cheng
>
> This patch added a configure time option,
> --with-riscv-attribute=[yes|no|default],
> run time option, -mriscv-attribute to control the
This looks pretty good to me, and looks like it works the same way as
the binutils patches that already went in before the binutils-2.32
release. I just see some minor issues that need fixing.
On Tue, Feb 12, 2019 at 11:17 PM Kito Cheng wrote:
>
> From: Kito Cheng
>
> Kito Cheng
> Monk Chiang
c_parse_final_cleanups checks DECL_IN_AGGR_P to avoid trying to emit a
static data member that has not been defined. The inline variable
patch changed that to exempt inline variables. But in this case we
haven't instantiated the variable yet, so we really don't have a
definition.
I've taken diff
On Mon, Feb 18, 2019 at 2:53 AM Rainer Orth
wrote:
>
> > On Feb 18 2019, Rainer Orth wrote:
> >
> >> diff --git a/libgo/testsuite/gotest b/libgo/testsuite/gotest
> >> --- a/libgo/testsuite/gotest
> >> +++ b/libgo/testsuite/gotest
> >> @@ -627,13 +627,13 @@ symtogo() {
> >>
On Tue, 2019-02-19 at 20:37 +0100, Jakub Jelinek wrote:
> On Tue, Feb 19, 2019 at 02:44:55PM -0500, David Malcolm wrote:
> > How about something like this? (on top of Jakub's patch)
>
> I had following queued for regtest, so if you want to go for the
> make_location ^~, you should change more spot
On Sat, Feb 16, 2019 at 1:28 PM Jakub Jelinek wrote:
>
> On Sat, Feb 16, 2019 at 08:42:11AM +0100, Jakub Jelinek wrote:
> > On Fri, Feb 15, 2019 at 08:59:29PM +0100, Matthias Klose wrote:
> > > On 15.02.19 15:52, Ian Lance Taylor wrote:
> > > > This patch by Robin Dapp adds S/390 support to the in
On 2/20/19 12:38 PM, Jakub Jelinek wrote:
Hi!
On the following testcase we ICE, because expand_or_defer_fn is called
multiple times on the same ctor (once from instantiation of constexpr
functions, once from c_parse_final_cleanups) and this calls maybe_clone_body
which isn't really prepared to b
On 2/20/19 12:25 PM, Jakub Jelinek wrote:
Hi!
The following testcase ICEs with -fno-weak, because maybe_commonize_var
clears TREE_PUBLIC/DECL_COMMON, but later we assume that if
!DECL_INTERFACE_KNOWN that TREE_PUBLIC is true.
Other spots that clear TREE_PUBLIC also set DECL_INTERFACE_KNOWN,
e.g.
On 2/20/19 11:52 AM, Jakub Jelinek wrote:
On Wed, Feb 20, 2019 at 11:12:07AM -1000, Jason Merrill wrote:
(z = REALPART_EXPR >;, (bool) IMAGPART_EXPR >;);
which is not potential_constant_expression, but nothing called it again
and cxx_eval_constant_expression can handle it.
Yeah, that seems lik
On 2/20/19 10:31 AM, Marek Polacek wrote:
Here we ICE when substituting a deferred noexcept-specifier, because it
contains 'this', a PARM_DECL, in an evaluated context. This is different
from "noexcept(noexcept(this))" where the noexcept operator's operand is
an unevaluated operand. We crash wi
On 2/20/19 3:29 PM, Jakub Jelinek wrote:
> Hi!
>
> The following testcase ICEs, because we have *pbitsize 65 and
> lang_hooks.types.type_for_size returns NULL for that. The following patch
> punts in that case, but makes sure we punt before overwriting *exp_, because
> the caller uses it regardle
On 2/20/19 3:32 PM, Jakub Jelinek wrote:
> Hi!
>
> On the following testcase we ICE in simplify_gen_subreg, when result has
> BLKmode and we want to convert it to some complex mode (e.g. DCmode or
> in theory XCmode or TCmode too).
> Such SUBREGs are invalid, but BLKmode can only live in memory an
On Wed, Feb 20, 2019 at 03:26:01PM -0700, Jeff Law wrote:
> Assuming we didn't reintroduce the original issue with 88074, OK since
> it just widens the exponents range.
Yeah, the original issue which has a testcase in the testsuite now still
compiles instantly. The default mpfr emin is -107374182
Hi!
On the following testcase we ICE, because expand_or_defer_fn is called
multiple times on the same ctor (once from instantiation of constexpr
functions, once from c_parse_final_cleanups) and this calls maybe_clone_body
which isn't really prepared to be called multiple times. In particular,
whe
There was a rather obvious bug in the logic for checking the arguments
to the OPEN statement when NEWUNIT= was specified, which prohibited
the generation of the appropriate error message.
Regtested successfully.
OK for trunk?
Thanks,
Harald
2019-02-20 Harald Anlauf
PR fortran/83057
Hi!
On the following testcase we ICE in simplify_gen_subreg, when result has
BLKmode and we want to convert it to some complex mode (e.g. DCmode or
in theory XCmode or TCmode too).
Such SUBREGs are invalid, but BLKmode can only live in memory and when it
is a MEM, we don't really need to create a
Hi!
The following testcase ICEs, because we have *pbitsize 65 and
lang_hooks.types.type_for_size returns NULL for that. The following patch
punts in that case, but makes sure we punt before overwriting *exp_, because
the caller uses it regardless of whether decode_field_reference returns NULL
or
On 2/20/19 3:22 PM, Jakub Jelinek wrote:
> On Wed, Feb 20, 2019 at 06:29:06PM +, Joseph Myers wrote:
>> On Wed, 20 Feb 2019, Jakub Jelinek wrote:
>>
>>> + /* mpc_norm assumes it can square a number without bothering with
>>> +with range scaling, so until that is fixed, double the minim
Hi!
The following testcase ICEs with -fno-weak, because maybe_commonize_var
clears TREE_PUBLIC/DECL_COMMON, but later we assume that if
!DECL_INTERFACE_KNOWN that TREE_PUBLIC is true.
Other spots that clear TREE_PUBLIC also set DECL_INTERFACE_KNOWN,
e.g. twice in optimize.c:
cp/optimize.c- TR
On Wed, Feb 20, 2019 at 06:29:06PM +, Joseph Myers wrote:
> On Wed, 20 Feb 2019, Jakub Jelinek wrote:
>
> > + /* mpc_norm assumes it can square a number without bothering with
> > +with range scaling, so until that is fixed, double the minimum
> > +and maximum exponents, plus add
Tested on SPARC64/Linux, OK for the mainline?
2019-02-20 Eric Botcazou
* configure.host (abi_baseline_pair): Adjust for SPARC64/Linux.
* config/abi/post/sparc64-linux-gnu: New directory.
* config/abi/post/sparc64-linux-gnu/baseline_symbols.txt: New file.
* conf
TARGET_SSE_MATH does not imply TARGET_SSE. Attached patch fixes a
couple of places where this rule is violated.
BTW: There is no testcase, since the test in the PR triggers bogus
warning about register return with disabled register set on x86_64.
This is an orthogonal issue.
--cut here--
float z,
On Wed, Feb 20, 2019 at 11:12:07AM -1000, Jason Merrill wrote:
> > (z = REALPART_EXPR >;, (bool)
> > IMAGPART_EXPR >;);
> > which is not potential_constant_expression, but nothing called it again
> > and cxx_eval_constant_expression can handle it.
>
> Yeah, that seems like a bug; C++11 shouldn't
Attached patch implements the same approach that x86_64 implements to
properly cast 'mcontext_t *' &rt_->uc.uc_mcontext to 'struct
sigcontext *'.
BTW: Other targets (e.g. Mips) probably need similar patch to avoid warning.
2019-02-20 Uroš Bizjak
* config/alpha/linux-unwind.h (alpha_fallba
On Wed, Feb 20, 2019 at 09:37:52PM +0100, Thomas König wrote:
> Am 20.02.19 um 21:36 schrieb Steve Kargl:
> > On Wed, Feb 20, 2019 at 09:10:51PM +0100, Thomas König wrote:
> >> Hello world,
> >>
> >> the attached patch implements a few versions of debug for Fortran data
> >> structures. It lets yo
On Mon, Feb 18, 2019 at 12:47:04PM +, Kyrill Tkachov wrote:
> Ok.
>
> Thanks for working on this.
Sorry for the endless story here, but I've realized that the *arm_ldrd and
*arm_strd instructions are the only remaining uses of the undocumented
internal constraint q and that it isn't really ne
On 2/18/19 6:31 PM, Jakub Jelinek wrote:
On Mon, Feb 18, 2019 at 04:04:15PM -1000, Jason Merrill wrote:
--- gcc/cp/constexpr.c.jj 2019-02-17 17:09:47.113351897 +0100
+++ gcc/cp/constexpr.c 2019-02-18 19:34:57.995136395 +0100
@@ -1269,6 +1301,49 @@ cxx_eval_builtin_function_call (const co
On 2/20/19, Jeff Law wrote:
> On 2/1/19 1:31 PM, Marc Glisse wrote:
>>
>> I am not surprised, but I had to at least start the conversation. Would
>> you mind providing a patch that changes the definition of -Wall, since
>> the current one doesn't quite match reality anymore? Also, what do you
>> r
On 2/19/19 12:03 PM, Jakub Jelinek wrote:
On Tue, Feb 19, 2019 at 11:28:22AM -1000, Jason Merrill wrote:
On Tue, Feb 19, 2019 at 4:00 AM Jakub Jelinek wrote:
On Mon, Feb 18, 2019 at 03:01:14PM -1000, Jason Merrill wrote:
But it's not clear to me that the standard actually allows this. I don'
On Tue, Feb 19, 2019 at 11:49 PM Thomas Koenig wrote:
>
> Hello world,
>
> the attached patch fixes the 8/9 regression by inserting the conversion
> at the right place. Regression-tested. OK for trunk, and for 8 when it
> re-opens?
Ok, except that the PR numbers in the ChangeLog entries are wron
Am 20.02.19 um 21:36 schrieb Steve Kargl:
On Wed, Feb 20, 2019 at 09:10:51PM +0100, Thomas König wrote:
Hello world,
the attached patch implements a few versions of debug for Fortran data
structures. It lets you type, for example
(gdb) call debug (expr)
and get some output which is readable,
On Wed, Feb 20, 2019 at 09:10:51PM +0100, Thomas König wrote:
> Hello world,
>
> the attached patch implements a few versions of debug for Fortran data
> structures. It lets you type, for example
>
> (gdb) call debug (expr)
>
> and get some output which is readable, instead of having to look at
Here we ICE when substituting a deferred noexcept-specifier, because it
contains 'this', a PARM_DECL, in an evaluated context. This is different
from "noexcept(noexcept(this))" where the noexcept operator's operand is
an unevaluated operand. We crash within tsubst_copy's PARM_DECL handling
of a '
Hello world,
the attached patch implements a few versions of debug for Fortran data
structures. It lets you type, for example
(gdb) call debug (expr)
and get some output which is readable, instead of having to look at
the structures yourself.
This has no user impact, because thsese functions
PR c/89410 reports various issues with #line directives with very
large numbers; one of them is an ICE inside diagnostic-show-locus.c
when emitting a diagnostic at line 0x.
The issue is that the arithmetic in layout::calculate_line_spans to
determine if two line spans are sufficiently clos
Hi Martin,
I would change "among" to "between" in the sentence below. OK otherwise
(not that I think an OK is really needed in this case).
+ The purpose of the directive is to provide an API among the GCC
compiler and
+the GNU C Library which would define vector implementations of math
rou
This patch by Ben Shi fixes a typo in a comment in the Go frontend.
Bootstrapped on x86_64-pc-linux-gnu, committed to mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 269027)
+++ gcc/go/gofron
Here build_offset_ref calls build_qualified_name to make a SCOPE_REF because
the dependent template arguments make type_dependent_expression_p (member)
true. We could probably work hard to prevent this, but it doesn't seem
necessary, and it's easy to fix write_expression to handle the result.
Tes
Here 'skipped' was set to -1 to force an explicit initializer for 'uninit'
before the initializer for 'initialized', and so we also tried to emit an
explicit initializer for the flexible array, for which build_zero_init
returns error_mark_node. We should ignore flexarrays even when
skipped < 0.
T
On Tue, Feb 19, 2019 at 10:53 PM Richard Biener
wrote:
> On Wed, Feb 20, 2019 at 2:58 AM Jason Merrill wrote:
> >
> > A type in an anonymous namespace can never be merged with one from
> > another translation unit, so a member of such a type is always its own
> > prevailing decl.
> >
> > I don't
On Wed, 20 Feb 2019, Jakub Jelinek wrote:
> + /* mpc_norm assumes it can square a number without bothering with
> + with range scaling, so until that is fixed, double the minimum
> + and maximum exponents, plus add some buffer for arithmetics
> + on the squared numbers. */
No
On Tue, 2019-02-19 at 20:37 +0100, Jakub Jelinek wrote:
> On Tue, Feb 19, 2019 at 02:44:55PM -0500, David Malcolm wrote:
> > How about something like this? (on top of Jakub's patch)
>
> I had following queued for regtest, so if you want to go for the
> make_location ^~, you should change more spot
The patch looks good, but still needs a ChangeLog entry. And please
send patches to the mailing list even if you're also attaching them to
the PR.
It also looks like you don't have a copyright assignment on file yet;
this patch is small enough to go in without it, but you probably want
to get tha
I've updated the patch to address both comments; the first conditional
now deals only with C++98, an extra 'else if' block deals with both
empty scalar var init and scalar sub-object init with too many braces.
I'll bump from 'preview' to 'proposed' -
please review for inclusion on trunk and possib
The underlying cause of PR 89170 is a bug that appears to have existed
since 2001, when the function decode_addr_const was changed to call
output_constant_def. The problem is that output_constant_def calls
compare_constant, and when compare_constant sees an ADDR_EXPR, it
calls decode_addr_const.
I have managed to reproduce the issue now, and the patch does appear
to fix the ICE.
There is a second issue, which will need more investigation: When
compiled with '-flto' the extra internal functions that VTV generates,
and which are necessary for it to work correctly, do not get
propagated in
On Wed, 20 Feb 2019 at 15:59, Jeff Law wrote:
>
> On 2/20/19 6:17 AM, Jakub Jelinek wrote:
> > On Wed, Feb 20, 2019 at 11:13:54AM +, Andrew Stubbs wrote:
> >> This patch causes a number of test regressions for (at least) arm and
> >> amdgcn. I've run a bisect and confirmed this is the first co
On 2/1/19 1:31 PM, Marc Glisse wrote:
>
> I am not surprised, but I had to at least start the conversation. Would
> you mind providing a patch that changes the definition of -Wall, since
> the current one doesn't quite match reality anymore? Also, what do you
> recommend people do when they hit fa
On 2/2/19 1:20 PM, Segher Boessenkool wrote:
> On Fri, Feb 01, 2019 at 12:27:57PM -0700, Jeff Law wrote:
>> On 2/1/19 7:01 AM, Marek Polacek wrote:
>>> On Fri, Feb 01, 2019 at 07:19:25AM -0600, Segher Boessenkool wrote:
On Fri, Feb 01, 2019 at 12:32:45PM +0100, Marc Glisse wrote:
> My opin
On 2/3/19 3:02 AM, Marc Glisse wrote:
> On Sat, 2 Feb 2019, Martin Sebor wrote:
>
>> I don't feel too strongly about whether -Wmaybe-uninitialized should
>> be in -Wall or in -Wextra, and I might even be somewhat more inclined
>> to expect to find it in the latter. But since you sound like you ar
On Wed, Feb 20, 2019 at 03:36:18PM +0100, Jakub Jelinek wrote:
> On Wed, Feb 20, 2019 at 08:34:41AM -0600, Segher Boessenkool wrote:
> > [ Don't top-post please ]
> >
> > On Wed, Feb 20, 2019 at 12:35:37PM +0800, Li Jia He wrote:
> > > >I believe you will also want to get permission to backport th
On Wed, Feb 20, 2019 at 03:53:37AM -0800, H.J. Lu wrote:
> Cherry-pick compiler-rt revision 354451:
>
> PR sanitizer/89409
> * sanitizer_common/sanitizer_linux.cc (internal_readlink): Put
> back the (uptr) cast on path and buf.
Please use the above in the ChangeLog, so
P
On Tue, Feb 19, 2019 at 9:14 PM H.J. Lu wrote:
>
> On Tue, Feb 19, 2019 at 6:16 AM Uros Bizjak wrote:
> >
> > On Tue, Feb 19, 2019 at 2:49 PM H.J. Lu wrote:
> > >
> > > ix86_fpmath should be set to combination of FPMATH_387 and FPMATH_SSE.
> > > When SSE is disabled, it should be set to FPMATH_3
On 2/20/19 8:11 AM, Martin Sebor wrote:
> On 2/20/19 7:25 AM, Jeff Law wrote:
>> On 2/20/19 5:36 AM, Pedro Alves wrote:
>>> On 02/05/2019 05:07 PM, Jeff Law wrote:
FWIW, I've been doing Fedora rawhide builds with gcc-9 since early Jan.
Not everything builds with -Wall -Werror, but lots
On 2/20/19 7:25 AM, Jeff Law wrote:
On 2/20/19 5:36 AM, Pedro Alves wrote:
On 02/05/2019 05:07 PM, Jeff Law wrote:
FWIW, I've been doing Fedora rawhide builds with gcc-9 since early Jan.
Not everything builds with -Wall -Werror, but lots of packages do.
I've only seen one maybe-uninit warning
On 2/20/19 6:17 AM, Jakub Jelinek wrote:
> On Wed, Feb 20, 2019 at 11:13:54AM +, Andrew Stubbs wrote:
>> This patch causes a number of test regressions for (at least) arm and
>> amdgcn. I've run a bisect and confirmed this is the first commit where it
>> doesn't work.
>
> The following, so far
On Wed, 20 Feb 2019 at 15:17, Wilco Dijkstra wrote:
>
> Hi Christophe,
>
> > Option overrides are appended/prepended depending on dejagnu version :-(
>
> Why stop there? Dejagnu could increase the fun of testing by randomizing
> option ordering.
>
> > But my question was more: why skip the test if
On Wed, Feb 20, 2019 at 3:35 PM H.J. Lu wrote:
>
> On Wed, Feb 20, 2019 at 08:12:35AM +0100, Uros Bizjak wrote:
> > On Tue, Feb 19, 2019 at 9:14 PM H.J. Lu wrote:
> > >
> > > On Tue, Feb 19, 2019 at 6:16 AM Uros Bizjak wrote:
> > > >
> > > > On Tue, Feb 19, 2019 at 2:49 PM H.J. Lu wrote:
> > >
On Wed, Feb 20, 2019 at 6:44 AM Uros Bizjak wrote:
>
> On Wed, Feb 20, 2019 at 3:35 PM H.J. Lu wrote:
> >
> > On Wed, Feb 20, 2019 at 08:12:35AM +0100, Uros Bizjak wrote:
> > > On Tue, Feb 19, 2019 at 9:14 PM H.J. Lu wrote:
> > > >
> > > > On Tue, Feb 19, 2019 at 6:16 AM Uros Bizjak wrote:
> >
On 2/20/19 8:36 AM, Jakub Jelinek wrote:
> On Wed, Feb 20, 2019 at 08:34:41AM -0600, Segher Boessenkool wrote:
>> [ Don't top-post please ]
>>
>> On Wed, Feb 20, 2019 at 12:35:37PM +0800, Li Jia He wrote:
I believe you will also want to get permission to backport this to GCC 8.
It looks l
[ Don't top-post please ]
On Wed, Feb 20, 2019 at 12:35:37PM +0800, Li Jia He wrote:
> >I believe you will also want to get permission to backport this to GCC 8.
> >It looks like the problem was introduced there, correct?
> Yes, you are correct. If there is no question with this patch,
> I will
On Wed, Feb 20, 2019 at 08:34:41AM -0600, Segher Boessenkool wrote:
> [ Don't top-post please ]
>
> On Wed, Feb 20, 2019 at 12:35:37PM +0800, Li Jia He wrote:
> > >I believe you will also want to get permission to backport this to GCC 8.
> > >It looks like the problem was introduced there, correct
On Wed, Feb 20, 2019 at 08:12:35AM +0100, Uros Bizjak wrote:
> On Tue, Feb 19, 2019 at 9:14 PM H.J. Lu wrote:
> >
> > On Tue, Feb 19, 2019 at 6:16 AM Uros Bizjak wrote:
> > >
> > > On Tue, Feb 19, 2019 at 2:49 PM H.J. Lu wrote:
> > > >
> > > > ix86_fpmath should be set to combination of FPMATH_3
On Tue, 19 Feb 2019, Caroline Tice wrote:
> On Tue, Feb 19, 2019 at 1:57 AM Richard Biener wrote:
>
> >
> > Looks like vtv_generate_init_routine calls symtab->process_new_functions
> > () which has seriously bad effects on GCCs internal memory state.
> >
> > VTV has zero testsuite coverage it se
On 2/20/19 5:36 AM, Pedro Alves wrote:
> On 02/05/2019 05:07 PM, Jeff Law wrote:
>> FWIW, I've been doing Fedora rawhide builds with gcc-9 since early Jan.
>> Not everything builds with -Wall -Werror, but lots of packages do.
>> I've only seen one maybe-uninit warning cause problems -- it was
>> s
On 2/20/19 6:51 AM, Jakub Jelinek wrote:
> On Wed, Feb 20, 2019 at 06:45:51AM -0700, Jeff Law wrote:
>> On 2/20/19 6:22 AM, Jakub Jelinek wrote:
>>> On Wed, Feb 20, 2019 at 11:13:54AM +, Andrew Stubbs wrote:
This patch causes a number of test regressions for (at least) arm and
amdgcn.
Hi Christophe,
> Option overrides are appended/prepended depending on dejagnu version :-(
Why stop there? Dejagnu could increase the fun of testing by randomizing
option ordering.
> But my question was more: why skip the test if one forces
> -mfloat-abi=softfp while you have this very same optio
On 20/02/2019 13:22, Jakub Jelinek wrote:
On Wed, Feb 20, 2019 at 11:13:54AM +, Andrew Stubbs wrote:
This patch causes a number of test regressions for (at least) arm and
amdgcn. I've run a bisect and confirmed this is the first commit where it
doesn't work.
The following, so far untested
On 2/20/19 10:36 AM, Thomas König wrote:
> Hi Martin,
>
>> Thank you both useful comments! I installed that as r269035.
>
> Excellent work, thanks!
;)
>
> Now a final step: Could you also add a short sentence to gcc-9/changes.html ?
> In German, we have a saying „Tue Gutes und rede darüber“,
Hi All,
Commandline options on AArch64 don't get canonicalized into the smallest
possible set before output to the assembler. This means that overlapping feature
sets are emitted with superfluous parts.
Normally this isn't an issue, but in the case of crypto we have retro-actively
split it into a
Hi All,
This patch updates the Armv8.4-a FP16 FML intrinsics's suffixes from u32 to f16
to be more consistent with the naming convention for intrinsics.
The specifications for these intrinsics have not been published yet so we do
not need to maintain the old names.
The patch was created with the
Hi All,
This patch updates the Armv8.4-a FP16 FML intrinsics's suffixes from u32 to f16
to be more consistent with the naming convention for intrinsics.
The specifications for these intrinsics have not been published yet so we do
not need to maintain the old names.
The patch was created with the
On Wed, 20 Feb 2019 at 14:51, Jakub Jelinek wrote:
>
> On Wed, Feb 20, 2019 at 06:45:51AM -0700, Jeff Law wrote:
> > On 2/20/19 6:22 AM, Jakub Jelinek wrote:
> > > On Wed, Feb 20, 2019 at 11:13:54AM +, Andrew Stubbs wrote:
> > >> This patch causes a number of test regressions for (at least) ar
On Wed, Feb 20, 2019 at 06:45:51AM -0700, Jeff Law wrote:
> On 2/20/19 6:22 AM, Jakub Jelinek wrote:
> > On Wed, Feb 20, 2019 at 11:13:54AM +, Andrew Stubbs wrote:
> >> This patch causes a number of test regressions for (at least) arm and
> >> amdgcn. I've run a bisect and confirmed this is the
On 2/20/19 6:22 AM, Jakub Jelinek wrote:
> On Wed, Feb 20, 2019 at 11:13:54AM +, Andrew Stubbs wrote:
>> This patch causes a number of test regressions for (at least) arm and
>> amdgcn. I've run a bisect and confirmed this is the first commit where it
>> doesn't work.
>
> The following, so far
On Wed, 20 Feb 2019 at 12:14, Andrew Stubbs wrote:
>
> On 19/02/2019 12:45, Richard Biener wrote:
> >
> > The following limits mpfr operations to the maximum exponent range as
> > determined by available float modes. This avoids excessive work
> > for evaluating functions like ctan for large argu
On Wed, 20 Feb 2019 at 13:35, Wilco Dijkstra wrote:
>
> Hi Christophe,
>
> > +/* { dg-skip-if "do not override -mfloat-abi" { *-*-* } { "-mfloat-abi=*"
> } {"-mfloat-abi=soft" } } */
> > Does this mean the test would be skipped if one forces
> > -mfloat-abi=softfp and not if one uses -mfloat-abi
On Wed, Feb 20, 2019 at 11:13:54AM +, Andrew Stubbs wrote:
> This patch causes a number of test regressions for (at least) arm and
> amdgcn. I've run a bisect and confirmed this is the first commit where it
> doesn't work.
The following, so far untested (except for x86_64->armv7hl-linux-gnueab
On 02/05/2019 05:07 PM, Jeff Law wrote:
> FWIW, I've been doing Fedora rawhide builds with gcc-9 since early Jan.
> Not everything builds with -Wall -Werror, but lots of packages do.
> I've only seen one maybe-uninit warning cause problems -- it was
> spurious and for a memory object. I didn't di
Hi Christophe,
> +/* { dg-skip-if "do not override -mfloat-abi" { *-*-* } { "-mfloat-abi=*" }
> {"-mfloat-abi=soft" } } */
> Does this mean the test would be skipped if one forces
> -mfloat-abi=softfp and not if one uses -mfloat-abi=soft ?
Yes it seems it is. No idea why the testsuite is so br
On Wed, Feb 20, 2019 at 10:04:04AM +, Richard Sandiford wrote:
> Martin Liška writes:
> > About the SVE: isn't the ABI dependent on the bit width of vectors?
>
> It's dependent on the types. There are ABI types for Advanced SIMD
> vectors and ABI types for SVE vectors. The two end up being
Martin Liška writes:
> On 2/20/19 11:04 AM, Richard Sandiford wrote:
>> Martin Liška writes:
>>> On 2/19/19 11:32 PM, Steve Ellcey wrote:
I am not sure if we
need all of those but it seemed better to have them and not use them
than to find out we need them later.
>>>
>>> Hi.
>>>
>>
Cherry-pick compiler-rt revision 354451:
r316591 has
@@ -389,13 +383,11 @@ uptr internal_dup2(int oldfd, int newfd) {
}
uptr internal_readlink(const char *path, char *buf, uptr bufsize) {
-#if SANITIZER_NETBSD
- return internal_syscall_ptr(SYSCALL(readlink), path, buf, bufsize);
-#elif SANITI
On 2/20/19 11:04 AM, Richard Sandiford wrote:
> Martin Liška writes:
>> On 2/19/19 11:32 PM, Steve Ellcey wrote:
>>> I am not sure if we
>>> need all of those but it seemed better to have them and not use them
>>> than to find out we need them later.
>>
>> Hi.
>>
>> About the SVE: isn't the ABI de
On 19/02/2019 12:45, Richard Biener wrote:
The following limits mpfr operations to the maximum exponent range as
determined by available float modes. This avoids excessive work
for evaluating functions like ctan for large arguments.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied
On 2/20/19 11:45 AM, Bernhard Reutner-Fischer wrote:
> On 20 February 2019 10:57:29 CET, "Martin Liška" wrote:
>> On 2/20/19 10:52 AM, Bernhard Reutner-Fischer wrote:
>>> Marin,
>>>
>>> +
>>> +@smallexample
>>> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64')
>>> +@
Hi Chung-Lin!
On Tue, 22 Jan 2019 22:53:47 +0800, Chung-Lin Tang
wrote:
> These are the testsuite changes. After the last review round, the amount of
> additional changes have been greatly reduced.
Yes. And I think should be further reduced:
> * testsuite/libgomp.oacc-c-c++-common/asyncw
On 20 February 2019 10:57:29 CET, "Martin Liška" wrote:
>On 2/20/19 10:52 AM, Bernhard Reutner-Fischer wrote:
>> Marin,
>>
>> +
>> +@smallexample
>> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64')
>> +@end smallexample
>> +
>> +The purpose of the directive
Martin Liška writes:
> On 2/19/19 11:32 PM, Steve Ellcey wrote:
>> I am not sure if we
>> need all of those but it seemed better to have them and not use them
>> than to find out we need them later.
>
> Hi.
>
> About the SVE: isn't the ABI dependent on the bit width of vectors?
It's dependent on
On 2/20/19 10:52 AM, Bernhard Reutner-Fischer wrote:
> Marin,
>
> +
> +@smallexample
> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64')
> +@end smallexample
> +
> +The purpose of the directive is to provide an API among the GCC
compiler and
> +the G
Marin,
> >>> +
> >>> +@smallexample
> >>> +!GCC$ builtin (sinf) attributes simd (notinbranch) if('x86_64')
> >>> +@end smallexample
> >>> +
> >>> +The purpose of the directive is to provide an API among the GCC
> >> compiler and
> >>> +the GNU C Library which would define vector implementation of
Ping. Thomas, is this OK for openacc-gcc-8-branch? It would be great if
I could commit this before Friday.
Thanks,
Gergö
On 12/02/2019 20:02, Gergö Barany wrote:
Hi all,
The attached patch fixes a bug in recent work on OpenACC "kernels"
regions. Jumps within nested binds or try statements w
Hi Martin,
> Thank you both useful comments! I installed that as r269035.
Excellent work, thanks!
Now a final step: Could you also add a short sentence to gcc-9/changes.html ?
In German, we have a saying „Tue Gutes und rede darüber“, do good deeds and
talk about it 😉
Regards, Thomas
On 2/19/19 11:32 PM, Steve Ellcey wrote:
> I am not sure if we
> need all of those but it seemed better to have them and not use them
> than to find out we need them later.
Hi.
About the SVE: isn't the ABI dependent on the bit width of vectors?
Martin
On 2/20/19 8:06 AM, Bernhard Reutner-Fischer wrote:
> On 19 February 2019 19:18:21 CET, Steve Kargl
> wrote:
>> On Mon, Feb 18, 2019 at 02:23:34PM +0100, Martin Liška wrote:
>>>
>>> As I installed all needed patches, I'm sending a documentation entry
>>> for the new functionality.
>>>
>>> Thought
Hi Wilco,
On Tue, 19 Feb 2019 at 19:44, Wilco Dijkstra wrote:
>
> Fix pr88850.c testcase which was failing in hardfp environments.
>
> Committed as obvious.
>
> ChangeLog:
> 2019-02-19 Wilco Dijkstra
>
> * gcc.target/arm/pr88850.c: Block -mfloat-abi override.
>
> --
> diff --git a/gcc/
On 2/19/19 2:25 PM, Martin Jambor wrote:
> Hi,
>
> On Tue, Feb 19 2019, Martin Liška wrote:
>> On 2/14/19 11:19 AM, Jan Hubicka wrote:
>>>
>
> ...
>
>>> Next stage1 we should also teach the callback to ignore edges of calls
>>> that are not being optimized.
>>
>> I'm sending patch for that.
>
>
1 - 100 of 104 matches
Mail list logo
