2018-06-27 8:15 GMT+02:00 Jakub Jelinek :
> On Wed, Jun 27, 2018 at 07:52:59AM +0200, Janus Weil wrote:
>> >> with your patch, we would only warn about
>> >>
>> >> var .and. func()
>> >>
>> >> and not about
>> >>
>> >> func() .and. var.
>> >>
>> >> AFAIK, TRUTH_AND_EXPR does not guarantee that func
On Wed, Jun 27, 2018 at 09:35:59AM +0200, Janus Weil wrote:
> > and have some non-default aggressive
> > optimization option that would optimize away in the FE impure function calls
>
> IMHO an optimization to remove functions calls is unproblematic only
> for pure functions, but as long as it is
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 optimize away in the FE impure function
>> > calls
>>
>> IMHO an optimization to remove functions calls is unproblem
Tested on x86-64/Linux, OK for the mainline?
2018-06-27 Eric Botcazou
* gimple.h (gimple_return_retbnd): Delete.
(gimple_return_set_retbnd): Likewise.
* cgraphunit.c (cgraph_node::expand_thunk): Remove call to
gimple_return_set_retbnd.
* gimple-pretty-p
On Wed, Jun 27, 2018 at 09:52:04AM +0200, 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 optimize away in the FE impure function
> >> > c
Ping.
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org
> On Behalf Of Tamar Christina
> Sent: Tuesday, June 19, 2018 15:11
> To: gcc-patches@gcc.gnu.org
> Cc: nd ; l...@redhat.com; rguent...@suse.de; i...@airs.com
> Subject: [PATCH][GCC][mid-end] Correct subreg no-op handling fo
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 optimize away in the FE impure
> function calls
> >>
>
Eric Botcazou wrote:
> > The AArch64 parts are OK. I've been holding off approving the patch while
> > I wait for Eric to reply on the x86_64 fails with your new testcase.
>
> The test is not portable in any case since it uses the "optimize" attribute
> so
> I'd just make it specific to Aarch64
> 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 oth
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 how
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 the
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 op
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 automatic
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 automatic
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 Kyryl
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
2018-06-
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 (cgraph_node::expand
* 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 do
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 Aarch6
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 GCC
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 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 Jozef
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 7e24ade1d4d16d71dca3f4d7d3e
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 includ
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 'th
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. final.c
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 resu
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
slig
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 tested
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
>>
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.
Howev
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 leavin
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 operands
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. Calls
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
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 B
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
> optimiza
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 obje
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 template-parame
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 doesn'
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 pus
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: note:
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 wit
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 compar
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. A
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
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
> arg
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 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 p
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. Th
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 perform
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@.
>> * doc/in
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 perform
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 no
> 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!
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 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. Howev
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 settin
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 their
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 s
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.
(
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 would
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.
>>> * Mak
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 (TAR
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 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 lo
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 -0
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 assert
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 declar
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
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 amou
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 som
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 bui
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 exit
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 with
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 dead
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.
Pl
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
> > > isn't
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, 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 g
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 defa
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
>
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.
(absu(absu
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
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
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 UNKNOWN_LOCATION."
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 dia
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, co
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 i
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/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 in
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):
428
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/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 pr
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 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: In
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 expla
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
g
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 cl
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: Tu
1 - 100 of 111 matches
Mail list logo
