> On 8 May 2018, at 02:58, Andre Vieira (lists)
> wrote:
>
> Hi Richard,
>> On 07/05/18 11:14, Richard Sandiford wrote:
>> "Andre Vieira (lists)" writes:
>>> Hi,
>>>
>>> See below a patch to address PR 83009.
>>>
>>> Tested with aarch64-linux-gnu bootstrap and regtests for c, c++ and fortran
While testing a series of patches to add Mingw support for
std::filesystem I discovered that codecvt_utf8 was producing
wchar_t values with the wrong endianness. This fixes it.
* src/c++11/codecvt.cc (__codecvt_utf8_base::do_in)
[__SIZEOF_WCHAR_T__==2 && __BYTE_ORDER__!=__ORDER_BI
On 17/05/18 16:10 +0100, Jonathan Wakely wrote:
On 15/05/18 07:30 +0200, François Dumont wrote:
Here it is again even more simplified. Should I backport the Debug
mode fix to 8 branch ?
Yes, please do backport the include/debug/* changes.
* include/bits/stl_tree.h
(_Rb_tree_impl(_Rb
On Mon, May 14, 2018 at 08:38:40AM -0500, Kyrill Tkachov wrote:
> Hi all,
>
> This patch implements the usadv16qi and ssadv16qi standard names.
> See the thread at on g...@gcc.gnu.org [1] for background.
>
> The V16QImode variant is important to get right as it is the most commonly
> used patter
Hi,
On 19/05/2018 01:40, Jason Merrill wrote:
On Fri, May 18, 2018 at 1:40 PM, Paolo Carlini wrote:
Hi again,
I'm playing with a wild, wild idea: would it make sense to try *first* an
expression? Because, a quickly hacked draft appears to handle very elegantly
all the possible cases of "junk"
The -Walloc-size-larger-than= option is supposed make it possible
to disable the warning by specifying a limit that's larger than
the default of PTRDIFF_MAX (the handler for the option argument
gets around the INT_MAX maximum for numeric arguments by accepting
suffixes like MB or GB). Unfortunate
On Fri, May 18, 2018 at 1:40 PM, Paolo Carlini wrote:
> Hi again,
>
> I'm playing with a wild, wild idea: would it make sense to try *first* an
> expression? Because, a quickly hacked draft appears to handle very elegantly
> all the possible cases of "junk" after the declarator, eg:
>
> void f
Here is patch 2 of 2 to make __ibm128 a distinct type. This patch makes the
long double pack and unpack builtins only work if the long double type is IBM
extended double. It adds two new builtins to pack and unpack __ibm128 types.
This has been tested on a little endian power8 system with bootst
This adds support for -march=rv32e and -mabi=ilp32e. This is mostly the work
of Kito Cheng and Monk Chiang. I forward ported the patch to current sources,
which needed a few fixes. I fixed the mask clearing/setting so that using
multiple -march/-mabi options works right. I added some docs for t
This patch is the first of two patches to make the __ibm128 type a distict
type. Previously, when I impemented __ibm128, I had defined it to be long
double on systems where long double used the IBM extended double format.
Segher asked that I always create the type as a distinct type. For C++, I h
> + /* If the next declaration is a PARM_DECL pointing to theDECL,
> +we need to adjust its VALUE_EXPR directly, since chains of
> +VALUE_EXPRs run afoul of garbage collection. This occurs
> +in Ada for Out parameters that aren't copied i
On Thu, May 17, 2018 at 02:40:11PM -0700, Carl Love wrote:
> On Thu, 2018-05-17 at 15:31 -0500, Segher Boessenkool wrote:
> > On Wed, May 16, 2018 at 12:53:13PM -0700, Carl Love wrote:
> > > diff --git a/gcc/testsuite/gcc.target/powerpc/altivec-12.c
> > > b/gcc/testsuite/gcc.target/powerpc/altivec-
Hello again!
Thanks to the feedback of Mr. Myers and those on the PR, I have
created a version 3 of this patch. This version introduces a new
warning flag (enabled at Wall) -Wignored-asm-name that will flag cases
where the user specifies an ASM name that the compiler ignores.
Test cases included.
This patch improves additional cases of FP to integer conversions with
-ffast-math enabled.
Example 1:
double
f5 (int x)
{
return (double)(float) x;
}
At -O2 with -ffast-math
Trunk generates:
f5:
scvtf s0, w0
fcvtd0, s0
ret
With the patch we can merge the co
This patch improves additional cases of FP to integer conversions.
Example 1:
unsigned long
f7 (double x)
{
return (unsigned) y;
}
At -O2
Trunk generates:
f7:
fcvtzu w0, d0
uxtwx0, w0
ret
With the patch we can merge the zero-extend and reduce the sequence to on
On 05/18/2018 04:07 PM, Rainer Orth wrote:
Please fix.
Thanks for the report, will install obvious fix.
Martin
>From af8fbed777a1583fc2ac865e0e15cbb24fee6a81 Mon Sep 17 00:00:00 2001
From: marxin
Date: Fri, 18 May 2018 16:27:22 +0200
Subject: [PATCH] Fix typo in test-case.
gcc/testsuite/Chan
Under some apparently rare conditions a DECL can have a non-
constant size that the fix for bug 85753 committed last week
into trunk was not prepared for. The attached change removes
the assumption to avoid the ICE that otherwise results.
Martin
PS The test case that triggers the ICE makes use
Hi again,
I'm playing with a wild, wild idea: would it make sense to try *first*
an expression? Because, a quickly hacked draft appears to handle very
elegantly all the possible cases of "junk" after the declarator, eg:
void foo()
{
if (void bar()JUNK);
}
and the parenth
On 18 May 2018 at 19:13, Jonathan Wakely wrote:
> In C++11 and C++14 any odr-use of these constants requires a definition
> at namespace-scope. In C++17 they are implicitly inline and so the
> namespace-scope redeclarations are redundant (and allowing them is
> deprecated).
>
> PR libstdc
In C++11 and C++14 any odr-use of these constants requires a definition
at namespace-scope. In C++17 they are implicitly inline and so the
namespace-scope redeclarations are redundant (and allowing them is
deprecated).
PR libstdc++/85098
* include/bits/regex.h [__cplusplus < 2017
On 18/05/18 11:58 -0400, Jason Merrill wrote:
On Fri, May 18, 2018 at 11:55 AM, Jason Merrill wrote:
On Fri, May 18, 2018 at 10:51 AM, Jonathan Wakely wrote:
On 18/05/18 10:29 -0400, Jason Merrill wrote:
The second patch is some libstdc++ changes to avoid warnings from uses
of the standard
On Fri, May 18, 2018 at 11:55 AM, Jason Merrill wrote:
> On Fri, May 18, 2018 at 10:51 AM, Jonathan Wakely wrote:
>> On 18/05/18 10:29 -0400, Jason Merrill wrote:
>>>
>>> The second patch is some libstdc++ changes to avoid warnings from uses
>>> of the standard library when this warning is on. M
On Fri, May 18, 2018 at 10:51 AM, Jonathan Wakely wrote:
> On 18/05/18 10:29 -0400, Jason Merrill wrote:
>>
>> The second patch is some libstdc++ changes to avoid warnings from uses
>> of the standard library when this warning is on. More are almost
>> certainly needed. Jonathan, how would you l
On Fri, May 18, 2018 at 08:30:44AM -0700, Cesar Philippidis wrote:
> Ping.
Ok.
> For reference, I've attached the patch for gcc7.
Jakub
Ping.
For reference, I've attached the patch for gcc7.
Cesar
On 05/15/2018 07:11 AM, Cesar Philippidis wrote:
> This patch resolves the issue in PR85782, which involves a C++ ICE
> caused by OpenACC loops which contain continue statements. The problem
> is that genericize_continue_stmt expects a
Hi,
On 18/05/2018 16:45, Jason Merrill wrote:
I guess it's desirable to also give this error when the declarator is
followed by ) or ; rather than other tokens that could be more
expression (like in A(a).x in the comment).
I can certainly try to implement this, maybe just something minimal to b
On 30/04/18 15:12, Tamar Christina wrote:
> Hi All,
>
> This patch adds the missing neon intrinsics for all 128 bit vector Integer
> modes for the
> three-way XOR and negate and xor instructions for Arm8.2-a to Armv8.4-a.
>
> Bootstrapped and regtested on aarch64-none-linux-gnue and no issues.
>
On 05/18/2018 02:49 AM, Prathamesh Kulkarni wrote:
> Hi,
> In r260250, the condition
>
> if (integer_zerop (retval))
> continue;
>
> was added before checking retval was of pointer type which caused
> functions having return type apart from void *, to be marked as
> malloc. The attached patch g
On 18/05/18 10:29 -0400, Jason Merrill wrote:
The second patch is some libstdc++ changes to avoid warnings from uses
of the standard library when this warning is on. More are almost
certainly needed. Jonathan, how would you like me to handle this WRT
the library? Check in both patches and let
On 27/03/18 13:58, Sudakshina Das wrote:
> Hi
>
> This patch adds the no variant to -mstrict-align and the corresponding
> function attribute. To enable the function attribute, I have modified
> aarch64_can_inline_p () to allow checks even when the callee function
> has no attribute. The need for
On Fri, May 18, 2018 at 10:30 AM, Paolo Carlini
wrote:
> Hi,
>
> On 18/05/2018 16:19, Jason Merrill wrote:
>>
>> On Fri, May 18, 2018 at 10:05 AM, Paolo Carlini
>> wrote:
>>>
>>> Hi,
>>>
>>> On 18/05/2018 15:56, Jason Merrill wrote:
I had in mind moving the call to cp_parser_check_condi
C++11 specified that the implicitly-declared copy constructor and
assignment operator are deprecated if one of them, or the destructor,
is user-provided. This patch implements that; I've recently been
fixing some uses in the compiler of those deprecated copies.
Rather than bundle this into -Wdepr
Hi,
On 18/05/2018 16:19, Jason Merrill wrote:
On Fri, May 18, 2018 at 10:05 AM, Paolo Carlini
wrote:
Hi,
On 18/05/2018 15:56, Jason Merrill wrote:
I had in mind moving the call to cp_parser_check_condition_declarator
into the block controlled by cp_parser_parse_definitely; this is a
semantic
On Fri, May 18, 2018 at 10:05 AM, Paolo Carlini
wrote:
> Hi,
>
> On 18/05/2018 15:56, Jason Merrill wrote:
>>
>> I had in mind moving the call to cp_parser_check_condition_declarator
>> into the block controlled by cp_parser_parse_definitely; this is a
>> semantic check that should follow the synt
On 05/18/2018 03:55 PM, Rainer Orth wrote:
> Hi Martin,
>
>> So the patch looks fine, only very very slightly binary is produced. I'm
>> going to install the patch so that
>> I can carry on more complex patches based on this one.
>
> it seems you didn't properly test the testsuite part: I see
>
On 05/18/2018 10:12 AM, Jakub Jelinek wrote:
Or is it invalid to dereference s before it has been constructed?
Yes, Marc found:
"During the construction of an object, if the value of the object or any
of its subobjects is accessed through a glvalue that is not obtained,
directly or indirect
On Fri, May 18, 2018 at 09:57:42AM -0400, Jason Merrill wrote:
> > But what is invalid on:
> > struct S { int foo (S *); int a; } s { 2 };
> > int S::foo (S *x)
> > {
> > int b = this->a;
> > x->a = 5;
> > b += this->a;
> > return b;
> > }
> > int main ()
> > {
> > if (s.foo (&s) != 7)
>
Hi Martin,
> On 05/16/2018 03:39 PM, Alexander Monakov wrote:
>> On Wed, 16 May 2018, Martin Liška wrote:
Hm, is the off-by-one in the new explanatory text really intended? I think
the previous text was accurate, and the new text should say "9th and 10th"
and then "first 10 invocati
On 05/18/2018 09:21 AM, Marc Glisse wrote:
what about comparisons to this? I thought restrict implied such a
comparison was 'never the same'?
ie. if the ctor was:
selfie (selfie *ptr) : me (ptr==this ? 0 : ptr) {}
It is tempting to think so, but I don't see any language to that effect.
O
Hi,
On 18/05/2018 15:56, Jason Merrill wrote:
I had in mind moving the call to cp_parser_check_condition_declarator
into the block controlled by cp_parser_parse_definitely; this is a
semantic check that should follow the syntactic checks. If there's no
initializer, it doesn't parse as a conditi
On Fri, 18 May 2018, Jakub Jelinek wrote:
On Fri, May 18, 2018 at 09:02:08AM -0400, Nathan Sidwell wrote:
On 05/18/2018 08:53 AM, Marc Glisse wrote:
As long as you do not dereference ptr in the constructor, that shouldn't
contradict 'restrict'. The PR gives this quote from the standard:
"Dur
On Fri, May 18, 2018 at 9:53 AM, Jakub Jelinek wrote:
> On Fri, May 18, 2018 at 09:02:08AM -0400, Nathan Sidwell wrote:
>> On 05/18/2018 08:53 AM, Marc Glisse wrote:
>>
>> > As long as you do not dereference ptr in the constructor, that shouldn't
>> > contradict 'restrict'. The PR gives this quote
On Fri, May 18, 2018 at 4:41 AM, Paolo Carlini wrote:
> Hi,
>
>>> On 18/05/2018 01:21, Jason Merrill wrote:
On Thu, May 17, 2018 at 5:54 PM, Paolo Carlini
wrote:
>
> On 17/05/2018 16:58, Jason Merrill wrote:
>>
>> On Thu, May 17, 2018 at 10:27 AM, Paolo Carlini
Hi Martin,
> So the patch looks fine, only very very slightly binary is produced. I'm
> going to install the patch so that
> I can carry on more complex patches based on this one.
it seems you didn't properly test the testsuite part: I see
+UNRESOLVED: gcc.dg/tree-prof/update-loopch.c scan-tree-
On Fri, May 18, 2018 at 09:02:08AM -0400, Nathan Sidwell wrote:
> On 05/18/2018 08:53 AM, Marc Glisse wrote:
>
> > As long as you do not dereference ptr in the constructor, that shouldn't
> > contradict 'restrict'. The PR gives this quote from the standard:
> >
> > "During the construction of an
On 05/18/2018 02:49 AM, Prathamesh Kulkarni wrote:
> Hi,
> In r260250, the condition
>
> if (integer_zerop (retval))
> continue;
>
> was added before checking retval was of pointer type which caused
> functions having return type apart from void *, to be marked as
> malloc. The attached patch g
On Fri, May 18, 2018 at 8:34 AM, Marc Glisse wrote:
> On Fri, 18 May 2018, Richard Biener wrote:
>> On Fri, May 18, 2018 at 2:25 PM Marc Glisse wrote:
>>
>>> this lets alias analysis handle the implicit 'this' parameter in C++
>>> constructors as if it was restrict.
>>
>> OK. Please give C++ fol
Hi
Since Richard Biener's commit from 16th May:
commit 2f05c3c7324cd293b7b2ba197e0a88d9749361cc
Author: rguenth
Date: Wed May 16 13:08:04 2018 +
the test case slp_5.c had started showing a couple of XPASS failures.
XPASS: gcc.target/aarch64/sve/slp_5.c -march=armv8.2-a+sve scan-assembler
On Fri, 18 May 2018, Nathan Sidwell wrote:
On 05/18/2018 08:53 AM, Marc Glisse wrote:
As long as you do not dereference ptr in the constructor, that shouldn't
contradict 'restrict'. The PR gives this quote from the standard:
"During the construction of an object, if the value of the object o
On Fri, 2018-05-18 at 13:11 +0200, Richard Biener wrote:
> The following adds a simple alloc/free_flag machinery allocating
> bits from an int typed pool and applies that to bb->flags and edge-
> >flags.
> This should allow infrastructure pieces to use egde/bb flags
> temporarily
> without worrying
On 05/18/2018 02:46 PM, Nathan Sidwell wrote:
> On 05/18/2018 08:29 AM, Martin Liška wrote:
>> Hi.
>>
>> It's requested by LCOV folks, they want to be able to print to stdout
>> instead of into a file.
>>
>> Survives make check -k -j10 RUNTESTFLAGS="gcov.exp"
>
> I guess you looked at abstracting
On 05/18/2018 08:53 AM, Marc Glisse wrote:
As long as you do not dereference ptr in the constructor, that shouldn't
contradict 'restrict'. The PR gives this quote from the standard:
"During the construction of an object, if the value of the object or any
of its subobjects is accessed through
On Fri, 18 May 2018, Nathan Sidwell wrote:
On 05/18/2018 08:34 AM, Marc Glisse wrote:
(Cc: said C++ folks)
On Fri, 18 May 2018, Richard Biener wrote:
On Fri, May 18, 2018 at 2:25 PM Marc Glisse wrote:
Hello,
this lets alias analysis handle the implicit 'this' parameter in C++
construct
On 05/18/2018 08:29 AM, Martin Liška wrote:
Hi.
It's requested by LCOV folks, they want to be able to print to stdout
instead of into a file.
Survives make check -k -j10 RUNTESTFLAGS="gcov.exp"
I guess you looked at abstracting the output file a bit earlier, and
passing in a FILE* to the out
On 05/18/2018 08:42 AM, Martin Liška wrote:
V2: pwd is renamed to cwd, which is a better name.
Martin
ok thanks.
nathan
--
Nathan Sidwell
On 05/18/2018 08:34 AM, Marc Glisse wrote:
(Cc: said C++ folks)
On Fri, 18 May 2018, Richard Biener wrote:
On Fri, May 18, 2018 at 2:25 PM Marc Glisse wrote:
Hello,
this lets alias analysis handle the implicit 'this' parameter in C++
constructors as if it was restrict.
I think the foll
V2: pwd is renamed to cwd, which is a better name.
Martin
>From a42365bc6987fc13d3a3cd4b98d7d64d94f7f318 Mon Sep 17 00:00:00 2001
From: marxin
Date: Fri, 18 May 2018 13:58:58 +0200
Subject: [PATCH] Print working directory to gcov files (PR
gcov-profile/84846).
gcc/ChangeLog:
2018-05-18 Martin
(Cc: said C++ folks)
On Fri, 18 May 2018, Richard Biener wrote:
On Fri, May 18, 2018 at 2:25 PM Marc Glisse wrote:
Hello,
this lets alias analysis handle the implicit 'this' parameter in C++
constructors as if it was restrict.
Bootstrap+regtest on powerpc64le-unknown-linux-gnu.
OK.
I forgot to document the option. Fixed that.
Martin
>From 81236af4d1fac4c278b29e65162b3f73593a7d08 Mon Sep 17 00:00:00 2001
From: marxin
Date: Fri, 18 May 2018 14:22:06 +0200
Subject: [PATCH] gcov: add new option -t that prints output to stdout (PR
gcov-profile/84846).
gcc/ChangeLog:
2018-05-1
Hi.
It's requested by LCOV folks, they want to be able to print to stdout
instead of into a file.
Survives make check -k -j10 RUNTESTFLAGS="gcov.exp"
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2018-05-18 Martin Liska
PR gcov-profile/84846
* gcov.c (print_usage): Add new
On Fri, May 18, 2018 at 2:25 PM Marc Glisse wrote:
> Hello,
> this lets alias analysis handle the implicit 'this' parameter in C++
> constructors as if it was restrict.
> Bootstrap+regtest on powerpc64le-unknown-linux-gnu.
OK. Please give C++ folks the chance to chime in on the semantics.
Th
Hi.
Simple format extension which prints working directory of TU when it was
compiled.
It's requested by LCOV folks.
Survives make check -k -j10 RUNTESTFLAGS="gcov.exp"
Ready for trunk?
Thanks,
Martin
gcc/ChangeLog:
2018-05-18 Martin Liska
PR gcov-profile/84846
* coverage.
Hello,
this lets alias analysis handle the implicit 'this' parameter in C++
constructors as if it was restrict.
Bootstrap+regtest on powerpc64le-unknown-linux-gnu.
2018-05-18 Marc Glisse
PR c++/82899
gcc/
* tree-ssa-structalias.c (create_variable_info_for_1): Extra argumen
On Fri, May 4, 2018 at 5:23 PM, Bin Cheng wrote:
> Hi,
> Based on previous patch, this one implements live range, reg pressure
> computation
> class in tree-ssa-live.c. The user would only need to instantiate the class
> and
> call the computation interface as in next patch.
> During the work,
While working on somehow re-ordering the first VRP pass after loop-header
copying I noticed that EVRP doesn't do VRP stmt simplifications. The
following adds this alongside the usual testsuite adjustments.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-05-18 Richa
On Thu, May 17, 2018 at 10:32:56AM -0700, H.J. Lu wrote:
> On Mon, May 14, 2018 at 8:00 PM, Martin Sebor wrote:
> > On 05/14/2018 01:10 PM, H.J. Lu wrote:
> >>
> >> On Mon, May 14, 2018 at 10:40 AM, H.J. Lu wrote:
> >>
> >> $ cat c.i
> >> struct B { int i; };
> >> struct C { struct B
Hi.
Following patch enables to generate more parallel profiles for applications
that do intensive # of invocations. There's some discussion in the PR.
So one example:
$ gcc -fprofile-generate=/tmp/slavia/%p/%q{CPU}/ empty.c -O2 && ./a.out
$ l /tmp/slavia/22234/x86_64/empty.gcda
-rw-r--r-- 1 marx
The following adds a simple alloc/free_flag machinery allocating
bits from an int typed pool and applies that to bb->flags and edge->flags.
This should allow infrastructure pieces to use egde/bb flags temporarily
without worrying that users might already use it as for example
BB_VISITED and friend
On 17/05/18 11:26, Kyrill Tkachov wrote:
> Hi all,
>
> We deprecated architecture versions earlier than Armv4T in GCC 6 [1].
> This patch removes support for architectures lower than Armv4.
> That is the -march values armv2, armv2a, armv3, armv3m are removed
> with this patch. I did not remove ar
On 17/05/18 11:26, Kyrill Tkachov wrote:
> Hi all,
>
> The -march=armv5 and armv5e options have been deprecated in GCC 7 [1].
> This patch removes support for them.
> It's mostly mechanical stuff. The functionality that was previously
> gated on arm_arch5 is now gated on arm_arch5t and the functio
On Thu, 17 May 2018, Richard Biener wrote:
>
> The following makes use of range-info to improve the basic building
> block of the alias-oracle so we can tell that in
>
> a[0] = 1;
> for (int i = 5; i < 17; ++i)
> a[i] = i;
> a[0] = 2;
>
> the ao_ref for a[i] does not alias the a[0] ac
On Fri, 18 May 2018, Prathamesh Kulkarni wrote:
> Hi,
> In r260250, the condition
>
> if (integer_zerop (retval))
> continue;
>
> was added before checking retval was of pointer type which caused
> functions having return type apart from void *, to be marked as
> malloc. The attached patch get
On 15/05/2018 18:56, Jonathan Wakely wrote:
As I said in the bugzilla PR, these assertions are all to catch our
own mistakes, not user error.
If we're comfortable the code is correct then we should remove them.
Should we wait until near the end of stage 1, to get more time with
these checks in
Hi,
In r260250, the condition
if (integer_zerop (retval))
continue;
was added before checking retval was of pointer type which caused
functions having return type apart from void *, to be marked as
malloc. The attached patch gets rid of the above check since we do not
wish to mark function retu
On Fri, May 4, 2018 at 5:21 PM, Bin Cheng wrote:
> Hi,
> This is the second patch computing available/clobber registers for register
> classes.
> It's the same as the original patch posted
> @https://gcc.gnu.org/ml/gcc-patches/2017-05/msg01022.html
>
> Bootstrap and test on x86_64 and AArch64 on
Hi,
On 18/05/2018 01:21, Jason Merrill wrote:
On Thu, May 17, 2018 at 5:54 PM, Paolo Carlini
wrote:
On 17/05/2018 16:58, Jason Merrill wrote:
On Thu, May 17, 2018 at 10:27 AM, Paolo Carlini
wrote:
PS: maybe better using function_declarator_p?
I think so, yes. The relevant rule seems to b
On Fri, May 4, 2018 at 5:21 PM, Bin Cheng wrote:
> Hi,
> This is the updated version patch set computing register pressure on TREE SSA
> and use that information to direct other loop optimizers (predcom only for
> now).
> This version of change is to follow Jeff's comment that we should reuse
>
In this PR we have:
c_5 = c_4(D) + 4;
c_12 = c_5 + 1;
*c_5 = 2;
a = 2;// A
c_21 = c_12 + 1;
*c_12 = 2;
a = 2;// B
c_28 = c_21 + 1;
*c_21 = 2;
a = 2;
c_7 = c_28 + 1;
*c_28 = 2;
where a is a global int. We decide that A can't clobber *c_5 ==
On Fri, May 18, 2018 at 9:43 AM Eric Botcazou wrote:
> Hi,
> the compiler has had built-in support for nested functions for a long
time,
> which makes it possible to support them in GNU C (as an extension) and in
Ada;
> Fortran uses them too but marginally. The support was entirely rewritten
fo
On 01/13/2016 05:21 PM, Tom de Vries wrote:
On 17/12/15 13:08, Tom de Vries wrote:
Hi,
Consider this patch, which reduces max_len of the oacc function
attribute to 0:
...
diff --git a/gcc/fortran/f95-lang.c b/gcc/fortran/f95-lang.c
index 8556b70..60f4ad3 100644
--- a/gcc/fortran/f95-lang.c
+++
On 04/25/2018 03:16 PM, Jan Hubicka wrote:
>> Hi.
>>
>> Sending GCC 6 branch backports.
>> Patches can bootstrap on ppc64le-redhat-linux and survives regression tests.
>> I'm going to install the patches.
>>
>> Martin
>
>> >From e0d32b1f9e0dd0486e63040e1ab8f5d8e9f0fbd5 Mon Sep 17 00:00:00 2001
>>
On Fri, May 18, 2018 at 4:37 AM Kugan Vivekanandarajah <
kugan.vivekanandara...@linaro.org> wrote:
> Hi Richard,
> Thanks for the review. I am revising the patch based on Andrew's comments
too.
> On 17 May 2018 at 20:36, Richard Biener
wrote:
> > On Thu, May 17, 2018 at 4:56 AM Andrew Pinski w
Hi,
the compiler has had built-in support for nested functions for a long time,
which makes it possible to support them in GNU C (as an extension) and in Ada;
Fortran uses them too but marginally. The support was entirely rewritten for
GCC 4 and a few rough edges have remained since then, whic
On Thu, May 17, 2018 at 8:36 PM Toon Moene wrote:
> The documentation of both options is still inconsistent, in both the
> trunk and the gcc-8 branch.
> The following is my suggestion to clear this up (and move
> -floop-unroll-and-jam close to -floop-interchange.
> ChangeLog:
> 2018-05-17 Too
On Thu, May 17, 2018 at 5:49 PM Bin.Cheng wrote:
> On Thu, May 17, 2018 at 3:04 PM, Richard Biener
> wrote:
> > On Tue, May 15, 2018 at 5:44 PM Bin.Cheng wrote:
> >
> >> On Fri, May 11, 2018 at 1:53 PM, Richard Biener
> >> wrote:
> >> > On Fri, May 4, 2018 at 6:23 PM, Bin Cheng wrote:
> >> >>
85 matches
Mail list logo
