2018-06-27 23:47 GMT+02:00 Steve Kargl :
> On Wed, Jun 27, 2018 at 10:46:05PM +0200, Janus Weil wrote:
>> 2018-06-27 21:34 GMT+02:00 Thomas Koenig :
>> >
>> > And we are not going to change Fortran semantics. And I also oppose
>> > defining our own subset of Fortran in the hope that people will
[ Returning to an old patch... ]
On 02/14/2018 04:52 AM, Richard Biener wrote:
> On Tue, 13 Feb 2018, Jeff Law wrote:
>
>> On 01/30/2018 02:59 AM, Richard Biener wrote:
>>>
>>> This patch tries to deal with the "easy" part of a function ABI,
>>> the return value location, in vectorization
On 06/26/2018 05:32 PM, Martin Sebor wrote:
> Attached is an updated patch to tighten up the warning and also
> prevent ICEs in the middle-end like in PR 86308 or PR 86202.
>
> I took Richard's suggestion to add the POINTER_TYPE_P() check
> to detect pointer/integer conflicts. That also avoids
On 06/18/2018 09:37 AM, Qing Zhao wrote:
> Hi,
>
> this is the 3rd (and the last) patch for PR78809:
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78809
> Inline strcmp with small constant strings
>
> The design doc for PR78809 is at:
>
On 05/02/2018 03:55 AM, Nesterovskiy, Alexander wrote:
> This patch fixes false dependencies for vmovss, vmovsd, vrcpss, vrsqrtss,
> vsqrtss and vsqrtsd instructions.
>
> Tested on x86-64/Linux, no new test fails, some SPEC 2006/2017 performance
> gains.
> Please let me know if something is
On 06/27/2018 10:11 PM, Marc Glisse wrote:
> (why is there no mention of ABSU_EXPR in doc/* ?)
[ ... ]
Kugan,
Please address Marc's comments and repost.
Marc, thanks for chiming in.
jeff
(why is there no mention of ABSU_EXPR in doc/* ?)
--- a/gcc/match.pd
+++ b/gcc/match.pd
@@ -571,10 +571,12 @@ DEFINE_INT_AND_FLOAT_ROUND_FN (RINT)
(copysigns (op @0) @1)
(copysigns @0 @1
-/* abs(x)*abs(x) -> x*x. Should be valid for all types. */
-(simplify
- (mult (abs@1 @0) @1)
On 06/27/2018 06:25 PM, Kugan Vivekanandarajah wrote:
> Hi,
>
> This patch adds some of the missing patterns in match.pd for ABSU_EXPR.
>
> Bootstrap and regression testing on x86_64-linux-gnu. Is this OK if no
> regressions.
>
> Thanks,
> Kugan
>
> gcc/ChangeLog:
>
> 2018-06-28 Kugan
On 06/26/2018 07:10 AM, Stephan Bergmann wrote:
> Cannot identify what sorting is used for that list (if any), so putting
> it at the end (and -gsplit-dwarf also follows -fvar-tracking-assignments
> in the "Options for Debugging Your Program" section).
>
>
> Author: Stephan Bergmann
> Date:
On 06/23/2018 06:38 AM, Dimitar Dimitrov wrote:
> 2018-06-23 Dimitar Dimitrov
>
> * lra-eliminations.c (update_reg_eliminate): Mark all spanning hard
> registers for Pmode..
> * lra-lives.c (check_pseudos_live_through_calls): Mark all spanning
> hard registers for the
On 06/23/2018 06:26 AM, Dimitar Dimitrov wrote:
> On петък, 22 юни 2018 г. 19:41:55 EEST Jakub Jelinek wrote:
>> On Fri, Jun 22, 2018 at 11:33:06AM -0600, Jeff Law wrote:
>>> On 06/13/2018 12:58 PM, Dimitar Dimitrov wrote:
The PRU load/store instructions can access memory with byte
On 06/13/2018 07:56 AM, Matthew Fortune wrote:
> Hi,
>
> This patch was developed as part of preparing ever more complex multilib
> combinations for the MIPS architecture and aims to solve several problems
> in this area. I've attempted to be quite verbose in the description, so
> that I can
On 05/30/2018 09:51 AM, Prathamesh Kulkarni wrote:
> On 30 May 2018 at 18:12, Jonathan Wakely wrote:
>> On 30 May 2018 at 11:40, Prathamesh Kulkarni wrote:
>>> gcc with -Wmain warns for local variables named main.
>>>
>>> int foo()
>>> {
>>> int main = 0;
>>> return main;
>>> }
>>>
>>> a.c:
On 06/19/2018 08:11 AM, Tamar Christina wrote:
> Hi All,
>
> Previously GCC's no-op detection could would consider something a no-op even
> when the
> mode change is not directly possible. This caused subregs that shouldn't be
> removed
> to be treated as a no-op and deleted.
>
> Regtested on
On 06/22/2018 10:23 AM, Olivier Hainque wrote:
> Hello,
>
> getenv_spec_function features code to return a fake
> value for an undefined variable when we know that we
> shouldn't complain about the variable being undefined
> and that the variable value doesn't matter.
>
> This code is there to
On 06/24/2018 08:41 PM, Kugan Vivekanandarajah wrote:
> Hi Jeff,
>
> Thanks for the comments.
>
> On 23 June 2018 at 02:06, Jeff Law wrote:
>> On 06/22/2018 03:11 AM, Kugan Vivekanandarajah wrote:
>>> When we set niter with maybe_zero, currently final_value_relacement
>>> will not happen due to
On 06/27/2018 03:53 PM, Jeff Law wrote:
On 06/27/2018 09:27 AM, Jakub Jelinek wrote:
On Wed, Jun 27, 2018 at 09:17:07AM -0600, Jeff Law wrote:
About 115 tests fail due to incompatible declarations of
the built-in functions below (the number shows the number
of warnings for each functions):
On 06/27/2018 07:24 AM, Eric Botcazou wrote:
> Hi,
>
> the Ada compiler uses small functions defined in its runtime to implement
> various intrinsic operations and it always inlines them, even at -O0. But it
> doesn't want location information from the runtime files to appear in the
> debug
On 06/26/2018 02:12 PM, Alexander Monakov wrote:
> Hi,
>
> This adds Vim syntax highlighting rules for match.pd and packages them
> together
> with gcc-rtl.vim and gimple.vim, creating contrib/vim-gcc-dev subtree that can
> be installed as a common Vim plugin.
>
> Thanks.
> Alexander
>
>
On 06/23/2018 09:42 AM, Dimitar Dimitrov wrote:
>>
>> I've already asked about your copyright assignment status. So you know,
>> we can't go forward with any nontrivial contributions until the
>> assignment is in place.
> Yes, FSF has my assignment since November 2016.
Great. Thanks.
>> So
On 06/27/2018 12:44 PM, Eric Gallager wrote:
On 6/26/18, Martin Sebor wrote:
With the exception of built-ins with the ellipsis (like sprintf),
GCC silently accepts declarations of built-in functions without
prototypes as well as calls to such functions with any numbers
or types of arguments,
I was hoping to avoid the complexity but I appreciate
the desire for a more permissive solution, at least for
some transitional period.
I've reworked the patch to avoid diagnosing 'void abort();'
(the only library built-in that takes no arguments).
Instead, calls that pass arguments to it are
On Wed, 2018-06-27 at 21:13 -0400, David Malcolm wrote:
> On Thu, 2018-06-28 at 02:28 +0200, Paolo Carlini wrote:
> > Hi,
> >
> > On 28/06/2018 01:31, Jason Merrill wrote:
> > >
> > > > +/* Returns the smallest location. */
> > >
> > > This should probably say "...that is not
On Thu, 2018-06-28 at 02:28 +0200, Paolo Carlini wrote:
> Hi,
>
> On 28/06/2018 01:31, Jason Merrill wrote:
> >
> > > +/* Returns the smallest location. */
> >
> > This should probably say "...that is not UNKNOWN_LOCATION."
>
> I agree.
> > Actually, the places you use min_location would seem
Hi,
On 28/06/2018 01:31, Jason Merrill wrote:
+/* Returns the smallest location. */
This should probably say "...that is not UNKNOWN_LOCATION."
I agree.
Actually, the places you use min_location would seem to work fine with
max_location as well. What are your criteria for choosing one or
Hi,
This patch adds some of the missing patterns in match.pd for ABSU_EXPR.
Bootstrap and regression testing on x86_64-linux-gnu. Is this OK if no
regressions.
Thanks,
Kugan
gcc/ChangeLog:
2018-06-28 Kugan Vivekanandarajah
* match.pd (absu(x)*absu(x) -> x*x): Handle.
On Wed, Jun 27, 2018 at 12:53 PM, Marek Polacek wrote:
> This PR complains about us accepting invalid code like
>
> template struct A {};
> A<-1> a;
>
> Where we should detect the narrowing: [temp.arg.nontype] says
> "A template-argument for a non-type template-parameter shall be a converted
On 6/27/18 4:35 PM, Segher Boessenkool wrote:
>> +DEFHOOK
>> +(translate_mode_attribute,
>> + "Define this hook if the port should translate machine_mode @var{mode}\n\
>> +to another mode. For example, rs6000's @code{KFmode}, when it is the
>> same\n\
>> +as @code{TFmode}.\n\
>> +\n\
>> +The
On Wed, Jun 27, 2018 at 5:11 AM, Paolo Carlini wrote:
> Hi David,
>
> On 27/06/2018 01:52, David Malcolm wrote:
>>
>> On Tue, 2018-06-26 at 01:44 +0200, Paolo Carlini wrote:
>>>
>>> Hi,
>>>
>>> this includes straightforward tweaks to check_concept_fn and quite a
>>> bit
>>> of additional work on
On Tue, Jun 26, 2018 at 8:43 AM, Richard Biener wrote:
>
> A patch from Honza not LTO streaming DECL_ORIGINAL_TYPE ends up
> ICEing during LTO bootstrap because we end up not re-using the
> DIE we create late during LTRANS for a subprogram because its
> parent is a namespace rather than a CU DIE
On Wed, 27 Jun 2018, Wilco Dijkstra wrote:
> Joseph Myers wrote:
> > On Tue, 26 Jun 2018, Wilco Dijkstra wrote:
>
> > > That looks incorrect indeed but that's mostly a problem with -fmath-errno
> > > as it
> > > would result in GCC assuming the function is const/pure when in fact it
> > >
GCC Maintainers:
The following patch adds missing test cases for
vec_extract_fp32_from_shortl(), vec_extract_fp32_from_shorth(), and
vec_extract().
The patch has been run on:
powerpc64le-unknown-linux-gnu (Power 8 LE)
powerpc64le-unknown-linux-gnu (Power 9 LE)
without regressions.
Joseph Myers wrote:
> On Tue, 26 Jun 2018, Wilco Dijkstra wrote:
> > That looks incorrect indeed but that's mostly a problem with -fmath-errno
> > as it
> > would result in GCC assuming the function is const/pure when in fact it
> > isn't.
> > Does ATTR_MATHFN_FPROUNDING imply that errno is
This change converts the pdp11 back end to use CCmode rather than cc0. It is
functional and the testsuite compile sections runs at least as well as before.
There is additional work left to be done; for example, the compare elimination
pass, which this target uses, does not know how to deal
On 06/27/2018 09:27 AM, Jakub Jelinek wrote:
> On Wed, Jun 27, 2018 at 09:17:07AM -0600, Jeff Law wrote:
>>> About 115 tests fail due to incompatible declarations of
>>> the built-in functions below (the number shows the number
>>> of warnings for each functions):
>>>
>>> 428 abort
>>> 58
On Thu, Jun 21, 2018 at 2:22 PM, Marek Polacek wrote:
> The following testcase is rejected because, for this line:
>
> bool b = X() ?: false;
>
> arg2 is missing and arg1 is a TARGET_EXPR. A TARGET_EXPR is a class
> prvalue so we wrap it in a SAVE_EXPR. Later when building 'this' we
> call
On Wed, Jun 27, 2018 at 10:46:05PM +0200, Janus Weil wrote:
> 2018-06-27 21:34 GMT+02:00 Thomas Koenig :
> >
> > And we are not going to change Fortran semantics. And I also oppose
> > defining our own subset of Fortran in the hope that people will make
> > fewer mistakes.
> >
> > A function is
So as noted earlier, my son needed a project to occupy him, so he's
learning a bit of vi, git, & gcc by doing some of the easier parts of
cc0 -> REG_CC conversions.
I selected the v8 port as the first target based on the (flawed)
assumption that it would be the easiest. It turns out a fair
On Wed, Jun 27, 2018 at 03:26:42PM -0500, Peter Bergner wrote:
> The test case in PR86324 exposes a problem when long double is the same as
> __ieee128 and we attempt to use the KC mode attribute. A complimentary
> problem exists when long double is the same as __ibm128 and we try to use
> the IC
OK.
On Wed, Jun 27, 2018 at 3:01 PM, David Malcolm wrote:
> PR c++/86329 reports that the C++ frontend can offer bogus suggestions like:
>
> #include
>
> int compare()
> {
> return __n1 - __n2;
> }
>
> suggested.cc: In function 'int compare()':
> suggested.cc:5:10: error: '__n1' was not
One extension enabled by -fdec is the ability to interpret TYPE
as a PRINT statement for compatibility purposes. When PDTs were
introduced, the code that handles -fde TYPE matching was not updated.
This patch fixes TYPE matching to no longer interpret as a PRINT statement when -fdec is
The attached patch fixes PR fortran/83184, which is actually two
distinct bugs as described in the PR. Passes regtests.
The patch is attached. OK for trunk and 7/8-branch?
>From 238f0a0e80c93209bb4e62ba2f719f74f5da164f Mon Sep 17 00:00:00 2001
From: Fritz Reese
Date: Wed, 27 Jun 2018 16:16:31
On Mon, Jun 25, 2018 at 9:04 PM Steve Kargl
wrote:
> ... It does seem odd to me
> that BT_CLASS has !c->attr.allocatable and BT_DERIVED
> is c->attr.allocatable, i.e., bang vs no bang. Is this
> because class is not affected by -finit-derived?
>
I'm glad you raised the question. As a result I
Hi!
On Tue, Jun 26, 2018 at 02:56:40PM -0500, Kelvin Nilsen wrote:
> This patch, as revised in response to your suggestions, was committed to
> trunk on 4/17/2018.
>
> Is this ok for backporting to gcc8, gcc7, and gcc6?
Okay for all. Thanks!
Segher
> > 2018-04-13 Kelvin Nilsen
> >
> >
On 6/27/18 3:26 PM, Peter Bergner wrote:
> gcc/
> PR target/86324
> * target.def (translate_mode_attribute): New hook.
> * targhooks.h (default_translate_mode_attribute): Declare.
> * targhooks.c (default_translate_mode_attribute): New function.
> * doc/tm.texi.in
On 2018-06-27 21:22, Rainer Orth wrote:
> Hi Jeff,
>
>>> So add an option for disabling build and install of libgcov and the
>>> related host tools.
>>>
>>> 2018-06-10 Rasmus Villemoes
>>>
>>> gcc/
>>> * configure.ac: Add --disable-gcov option.
>>> * configure: Regenerate.
>>> *
On 27/06/2018 22:02, Jonathan Wakely wrote:
On 27/06/18 21:25 +0200, François Dumont wrote:
On 27/06/2018 02:13, Jonathan Wakely wrote:
On 26/06/18 17:03 +0100, Jonathan Wakely wrote:
On 18/06/18 23:01 +0200, François Dumont wrote:
Hi
I abandon the idea of providing Debug algos, it
Commited attached patch.
It fixes the missing noexcept qualification on a __gnu_debug::vector<>
constructor.
2018-06-27 François Dumont
* include/bits/stl_vector.h
(struct _Vector_base<>::_Vector_impl_data): New.
(struct _Vector_base<>::_Vector_impl): Inherit from latter.
The test case in PR86324 exposes a problem when long double is the same as
__ieee128 and we attempt to use the KC mode attribute. A complimentary
problem exists when long double is the same as __ibm128 and we try to use
the IC mode attribute. The problem is that for the type that long double
is
On Tue, 26 Jun 2018, Martin Sebor wrote:
> Attached is an updated patch to tighten up the warning and also
> prevent ICEs in the middle-end like in PR 86308 or PR 86202.
This patch adds two arguments to match_builtin_function_types, but doesn't
update the comment on that function to define
On Tue, 26 Jun 2018, Wilco Dijkstra wrote:
> > If the library does not set errno, clearly -fno-math-errno by default is
> > appropriate (and is the default on Darwin).
>
> Various librarys no longer set errno nowadays, for example BSD, MUSL, Bionic
> etc. For GLIBC 3.0 I'd propose to drop
On 27/06/18 21:25 +0200, François Dumont wrote:
On 27/06/2018 02:13, Jonathan Wakely wrote:
On 26/06/18 17:03 +0100, Jonathan Wakely wrote:
On 18/06/18 23:01 +0200, François Dumont wrote:
Hi
I abandon the idea of providing Debug algos, it would be too
much code to add and maintain.
On Mon, 25 Jun 2018, Martin Sebor wrote:
> Sure. I think we could easily exempt most of the tests from
> diagnosing without compromising the efficacy of the warning
> by silently accepting definitions of () functions that take no
> arguments (and diagnosing calls to them that pass some). What
>
> On 26 Jun 2018, at 07:38, Alexandre Oliva wrote:
>
> Here's the patch I'll install if nobody objects in the next few days.
> Tested on x86_64-linux-gnu with a gcc bootstrap tree, a gcc
> non-bootstrap tree, and a binutils+gdb tree.
Thanks a lot for this Alex!
Am 27.06.2018 um 21:15 schrieb Janne Blomqvist:
If the semantic model is unclear on whether a function with potential
side-effects might or might not be evaluated, then IMNSHO the semantic
model is shit, and should be fixed or replaced.
I disagree here, strongly. We are talking Fortran, and
On 27/06/2018 02:13, Jonathan Wakely wrote:
On 26/06/18 17:03 +0100, Jonathan Wakely wrote:
On 18/06/18 23:01 +0200, François Dumont wrote:
Hi
I abandon the idea of providing Debug algos, it would be too
much code to add and maintain. However I haven't quit on reducing
Debug mode
Hi Jeff,
>> So add an option for disabling build and install of libgcov and the
>> related host tools.
>>
>> 2018-06-10 Rasmus Villemoes
>>
>> gcc/
>> * configure.ac: Add --disable-gcov option.
>> * configure: Regenerate.
>> * Makefile.in: Honour @enable_gcov@.
>> *
On 27/06/18 21:03 +0200, François Dumont wrote:
On 26/06/2018 18:03, Jonathan Wakely wrote:
On 18/06/18 23:01 +0200, François Dumont wrote:
Hi
I abandon the idea of providing Debug algos, it would be too
much code to add and maintain. However I haven't quit on reducing
Debug mode
On Wed, Jun 27, 2018 at 8:26 PM, N.M. Maclaren wrote:
> On Jun 27 2018, Janus Weil wrote:
>
>> What is so complicated about putting a statement into the Fortran
>> standard that says: "Ok, if this function has side effects, we
>> definitely must evaluate it, otherwise we lose the side effects.
On Wed, Jun 27, 2018 at 7:46 PM, Steve Kargl <
s...@troutmask.apl.washington.edu> wrote:
> On Wed, Jun 27, 2018 at 11:09:56AM +0300, Janne Blomqvist wrote:
> >
> > How about committing a patch changing to use TRUTH_{AND|OR}_EXPR, and
> then
> > check benchmark results (polyhedron, spec etc.)? If
On 26/06/2018 18:03, Jonathan Wakely wrote:
On 18/06/18 23:01 +0200, François Dumont wrote:
Hi
I abandon the idea of providing Debug algos, it would be too much
code to add and maintain. However I haven't quit on reducing Debug
mode performance impact.
So this patch make use of the
On 6/26/18, Martin Sebor wrote:
> With the exception of built-ins with the ellipsis (like sprintf),
> GCC silently accepts declarations of built-in functions without
> prototypes as well as calls to such functions with any numbers
> or types of arguments, compatible or otherwise. Calls with
>
On 06/27/2018 10:01 AM, Kelvin Nilsen wrote:
> Hi Jeff,
>
> Is it ok to backport this patch to gcc 8? There are other backports of test
> programs that would like to use the new selector options.
Sure.
jeff
This is strictly an optimization patch. It adds flag setting variants
of key arithmetic, logical, extensions, shifts, etc. That in turn
allows the compare-elim pass to do its job.
At this point the v8 port is converted and should be functioning at the
same level it was before the conversion.
This is the bulk of the changes. With this change in installed the v850
port should be using the new mechanism for condition code handling
consistently, though without optimizing well.
This is a fairly large change which hits a great many patterns.
It's largely what one would expect. THe
This is a fairly mechanical change -- it removes a large amount of the
cc0 machinery, but not all of it. It's not really meant to stand
independently of the subsequent changes. I've broken it out merely to
aid anyone who perhaps wants to see the more significant changes in
subsequent patches
PR c++/86329 reports that the C++ frontend can offer bogus suggestions like:
#include
int compare()
{
return __n1 - __n2;
}
suggested.cc: In function 'int compare()':
suggested.cc:5:10: error: '__n1' was not declared in this scope
return __n1 - __n2;
^~~~
suggested.cc:5:10:
On Fri, Jun 15, 2018 at 4:21 PM, Jason Merrill wrote:
> This testcase was broken by the lambda rewrite. This turned out to be
> because the lambda in the template's default argument had namespace
> scope, while the instantiation had function scope, because of
> tsubst_default_argument calling
On Jun 27 2018, Janus Weil wrote:
I'm not completely sure what you deduce from all these quoted
paragraphs, but applied to the cases we're discussing here, e.g.
A = .false. .and. my_boldly_impure_function()
I read them as saying that a compiler does not have to invoke the
function if it
This PR complains about us accepting invalid code like
template struct A {};
A<-1> a;
Where we should detect the narrowing: [temp.arg.nontype] says
"A template-argument for a non-type template-parameter shall be a converted
constant expression ([expr.const]) of the type of the
On Wed, Jun 27, 2018 at 11:09:56AM +0300, Janne Blomqvist wrote:
>
> How about committing a patch changing to use TRUTH_{AND|OR}_EXPR, and then
> check benchmark results (polyhedron, spec etc.)? If performance worsens, we
> revert, if it improves, great, lets keep it?
>
> To clarify, I'm not
Hi Janus,
I don't think it's ok to not evaluate expressions that have side
effects
The Fortran standard disagrees with you (as you know, this has
been quoted previously).
Evaluating a function in such a case is a missed optimization.
> but as long as it is guarded by a non-default
>
Hi Jeff,
Is it ok to backport this patch to gcc 8? There are other backports of test
programs that would like to use the new selector options.
Thanks.
On 5/23/18 12:31 PM, Segher Boessenkool wrote:
> On Tue, May 22, 2018 at 03:21:30PM -0600, Jeff Law wrote:
>> On 05/21/2018 03:46 PM, Segher
On Wed, Jun 27, 2018 at 09:17:07AM -0600, Jeff Law wrote:
> > About 115 tests fail due to incompatible declarations of
> > the built-in functions below (the number shows the number
> > of warnings for each functions):
> >
> > 428 abort
> > 58 exit
> > 36 memcpy
> > 17 memmove
> > 15
On 06/26/2018 08:57 PM, Martin Sebor wrote:
> With the exception of built-ins with the ellipsis (like sprintf),
> GCC silently accepts declarations of built-in functions without
> prototypes as well as calls to such functions with any numbers
> or types of arguments, compatible or otherwise.
On Wed, Jun 27, 2018 at 08:15:13AM +0200, Jakub Jelinek wrote:
>
> I think best would be to change the above to
> code = TRUTH_AND_EXPR and code = TRUTH_OR_EXPR and have some
> non-default aggressive optimization option that would optimize
> away in the FE impure function calls from those
The v850 port has an option to increase alignment of objects. However,
from my testing it looks fundamentally broken. I suspect some kind of
dynamic stack/frame realignment is necessary for this to work properly.
As it stands using -m8byte-align can result in corrupted stack frames.
I'm
VxWorks' regs.h does include some files that need types defined in
vxTypesOld.h, and it does not itself include that header, directly or
indirectly. Moreover, vxTypesOld.h ends up pulling in definitions of
various cpufamily macros (from types/vxCpu.h) that are also needed
directly by regs.h.
2018-06-27 15:43 GMT+02:00 N.M. Maclaren :
> On Jun 27 2018, Janus Weil wrote:
>>
>>
>> It is very unfortunate, and it means that the Fortran standard simply
>> does not provide a measure for "more correct" here. (My common-sense
>> drop-in notion of correctness would be that an optimization is
>>
On Wed, Jun 27, 2018 at 04:50:33AM -0500, Kyrill Tkachov wrote:
> Hi all,
>
> The Cortex-A76 is an Armv8.2-A processor with dotproduct and FP16 support.
> It can be paired with the Cortex-A55 and hence the option
> -mcpu/-mtune=cortex-a76.cortex-a55 is also introduced.
>
> Bootstrapped and
I posted a patch for this on the PR in August 2010. Dominique pointed
out that it caused repeated error messages in some testcases; eg.
arithmetic_overflow_1.f90
As it happens, that seems to have crept in at some time even without
the patch for this PR. Nevertheless, I have modified the patch
On Jun 27 2018, Janus Weil wrote:
It is very unfortunate, and it means that the Fortran standard simply
does not provide a measure for "more correct" here. (My common-sense
drop-in notion of correctness would be that an optimization is
'correct' as long as it can be proven to not change any
Hi,
the Ada compiler uses small functions defined in its runtime to implement
various intrinsic operations and it always inlines them, even at -O0. But it
doesn't want location information from the runtime files to appear in the
debug info so it puts DECL_IGNORED_P on these functions.
Ping.
On Thu, Jun 21, 2018 at 02:22:31PM -0400, Marek Polacek wrote:
> The following testcase is rejected because, for this line:
>
> bool b = X() ?: false;
>
> arg2 is missing and arg1 is a TARGET_EXPR. A TARGET_EXPR is a class
> prvalue so we wrap it in a SAVE_EXPR. Later when building
The fourth and final patch adds functionality to search for
devices.csv in both
the path specified by the environment variable
"MSP430_GCC_INCLUDE_DIR", and
the directory "msp430-elf/include/devices" from the toolchain root. These
locations are searched if devices.csv is not found on an
The third patch adds functionality to search the include paths
specified with
-I for "devices.csv". If the file is found, and a device name has been
passed
to the -mmcu option, then devices.csv is parsed, and the MCU data for
the given
device is extracted.
>From
The second patch updates the hard-coded MCU data to the latest version.
>From 7da6e1edcffc1fa1a93dde5e23c87f9653132768 Mon Sep 17 00:00:00 2001
From: Jozef Lawrynowicz
Date: Mon, 25 Jun 2018 19:56:53 +0100
Subject: [PATCH 2/4] MSP430 - Devices 1.1 Update hard-coded MCU data
2018-06-27
The first patch keeps the hard-coded data as the only way of reading
MCU data,
but consolidates it in a single file. Extensions to the spec handling in
msp430.h mean that the hard-coded data is no longer needed in
't-msp430' for
multilib selection, or in the assembler. This is achieved by the
The following series of patches extends MCU device data handling for the msp430
target, allowing an external file to be read which describes the CPU ISA and
hardware multiply supported for different MCUs.
The current hard-coded solution means that new MCUs can only be supported by
updating the
Eric Botcazou wrote:
>> This test can easily be changed not to use optimize since it doesn't look
>> like it needs it. We really need to tests these builtins properly,
>> otherwise they will continue to fail on most targets.
>
> As far as I can see PR target/84521 has been reported only for
* include/bits/cpp_type_traits.h [__cplusplus >= 201703]
(__is_byte): Define specialization for std::byte.
This is used in to decide whether to optimize fills to
memset, so we want to enable it for std::byte.
It could also be used to simplify __is_byte_like in ,
which I might
On June 27, 2018 9:54:50 AM GMT+02:00, Eric Botcazou
wrote:
>Tested on x86-64/Linux, OK for the mainline?
OK.
Richard.
>
>2018-06-27 Eric Botcazou
>
> * gimple.h (gimple_return_retbnd): Delete.
> (gimple_return_set_retbnd): Likewise.
> * cgraphunit.c
Hi all,
The Cortex-A76 is an Armv8.2-A processor with dotproduct and FP16 support.
It can be paired with the Cortex-A55 and hence the option
-mcpu/-mtune=cortex-a76.cortex-a55 is also introduced.
Bootstrapped and tested on aarch64-none-linux-gnu.
Ok for trunk?
Thanks,
Kyrill
2018-06-27
Hi all,
The Cortex-A76 is an Armv8.2-A processor with dotproduct and FP16 support.
It can be paired with the Cortex-A55 and hence the option
-mcpu/-mtune=cortex-a76.cortex-a55 is also introduced.
Bootstrapped and tested on arm-none-linux-gnueabihf.
Committing to trunk.
Thanks,
Kyrill
Richard Sandiford writes:
> Richard Biener writes:
>> On Mon, Jun 18, 2018 at 5:04 PM Richard Sandiford
>> wrote:
>>>
>>> When following the definitions of SSA names, some recognisers
>>> already cope with statements that have been replaced by patterns.
>>> This patch makes that happen
Richard Sandiford writes:
> Richard Biener writes:
>> On Mon, Jun 18, 2018 at 5:04 PM Richard Sandiford
>> wrote:
>>>
>>> When following the definitions of SSA names, some recognisers
>>> already cope with statements that have been replaced by patterns.
>>> This patch makes that happen
2018-06-27 10:09 GMT+02:00 Janne Blomqvist :
> On Wed, Jun 27, 2018 at 10:52 AM, Janus Weil wrote:
>>
>> 2018-06-27 9:42 GMT+02:00 Jakub Jelinek :
>> > On Wed, Jun 27, 2018 at 09:35:59AM +0200, Janus Weil wrote:
>> >> > and have some non-default aggressive
>> >> > optimization option that would
Hi David,
On 27/06/2018 01:52, David Malcolm wrote:
On Tue, 2018-06-26 at 01:44 +0200, Paolo Carlini wrote:
Hi,
this includes straightforward tweaks to check_concept_fn and quite a
bit
of additional work on grokdeclarator: most of it is also rather
straightforward. In a few places there is
Hello Rasmus,
> On 26 Jun 2018, at 14:45, Rasmus Villemoes wrote:
>
> On 2018-06-19 18:45, Olivier Hainque wrote:
>>
>> Before we get there: are you familiar with the "munch" facility
>> of VxWorks ?
>
> Yes, but doing regexp match on nm output feels wrong (though I am aware
> that that is
> This test can easily be changed not to use optimize since it doesn't look
> like it needs it. We really need to tests these builtins properly,
> otherwise they will continue to fail on most targets.
As far as I can see PR target/84521 has been reported only for Aarch64 so I'd
just leave the
1 - 100 of 109 matches
Mail list logo
