On 07/17/2018 12:48 PM, Ilya Leoshkevich wrote:
> Fixes unwind for mcount.
>
> 2018-07-17 Ilya Leoshkevich
>
> * config/s390/s390.c (s390_function_profiler):
> Generate CFI.
Applied. Thanks!
Andreas
OK.
On Thu, Jul 12, 2018 at 7:52 PM, Paolo Carlini wrote:
> Hi,
>
> the below resolves the bug report and its duplicates by implementing - in a
> rather straightforward way, I believe - the resolution of DR 136, which also
> made into C++17. Note that in the patch I used permerror instead of a pl
On Wed, Jul 18, 2018 at 11:34:30AM +1000, Jason Merrill wrote:
> On Wed, Jul 18, 2018 at 4:57 AM, Jakub Jelinek wrote:
> > The standard says:
> > "In the decl-specifier-seq of the lambda-declarator, each decl-specifier
> > shall
> > either be mutable or constexpr."
> > and the C++ FE has CP_PARSE
On Tue, 17 Jul 2018, Martin Sebor wrote:
> The attached update takes care of a couple of problems pointed
> out by Bernd Edlinger in his comments on the bug. The ICE he
> mentioned in comment #20 was due mixing sizetype, ssizetype,
> and size_type_node in c_strlen(). AFAICS, some of it predates
On 07/18/2018 05:52 AM, Michael Collison wrote:
> Hi Martin,
>
> Your alignment patch breaks the arm port. In the file arm.c, function
> 'get_label_padding' the code uses:
>
> static HOST_WIDE_INT
> get_label_padding (rtx label)
> {
> HOST_WIDE_INT align, min_insn_size;
>
> align = 1 << lab
On Tue, Jul 17, 2018 at 3:46 PM Kyrill Tkachov
wrote:
>
> Hi Richard,
>
> On 17/07/18 14:27, Richard Biener wrote:
> > On Tue, Jul 17, 2018 at 2:35 PM Kyrill Tkachov
> > wrote:
> >> Hi all,
> >>
> >> This is my first Fortran patch, so apologies if I'm missing something.
> >> The current expansion
On 18/07/18 10:44, Richard Biener wrote:
On Tue, Jul 17, 2018 at 3:46 PM Kyrill Tkachov
wrote:
Hi Richard,
On 17/07/18 14:27, Richard Biener wrote:
On Tue, Jul 17, 2018 at 2:35 PM Kyrill Tkachov
wrote:
Hi all,
This is my first Fortran patch, so apologies if I'm missing something.
The cur
On Wed, Jul 18, 2018 at 4:19 AM Kugan Vivekanandarajah
wrote:
>
> Attached patch fixes phi-opt not optimizing c++ testcase where we have
>
> if (b_4(D) == 0) instead of if (b_4(D) != 0) as shown in
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86544
>
> Patch bootstrapped and regression tested on
On Wed, Jul 18, 2018 at 8:53 AM Alexandre Oliva wrote:
>
> This patch is a rewrite of an earlier patch submitted at
> https://gcc.gnu.org/ml/gcc-patches/2012-11/msg02340.html
>
> With -gnateS, the Ada compiler sets itself up to output discriminators
> for different instantiations of generics, but
On Wed, Jul 18, 2018 at 11:50 AM Kyrill Tkachov
wrote:
>
>
> On 18/07/18 10:44, Richard Biener wrote:
> > On Tue, Jul 17, 2018 at 3:46 PM Kyrill Tkachov
> > wrote:
> >> Hi Richard,
> >>
> >> On 17/07/18 14:27, Richard Biener wrote:
> >>> On Tue, Jul 17, 2018 at 2:35 PM Kyrill Tkachov
> >>> wrote
On Fri, Jul 13, 2018 at 06:53:30PM +0200, Jakub Jelinek wrote:
> On Fri, Jul 13, 2018 at 12:24:02PM -0400, Nathan Sidwell wrote:
> > On 07/13/2018 09:49 AM, Jakub Jelinek wrote:
> > > Hi!
> > >
> > > I'd like to ping the following C++ patches:
> > >
> > > - PR c++/85515
> > >make range for te
Hi all,
Thank you for the feedback so far.
This version of the patch doesn't try to emit fmin/fmax function calls but
instead
emits MIN/MAX_EXPR sequences unconditionally.
I think a source of confusion in the original proposal (for me at least) was
that on aarch64 (that I primarily work on) we i
Richard Biener writes:
> On Wed, Jul 18, 2018 at 11:50 AM Kyrill Tkachov
> wrote:
>>
>>
>> On 18/07/18 10:44, Richard Biener wrote:
>> > On Tue, Jul 17, 2018 at 3:46 PM Kyrill Tkachov
>> > wrote:
>> >> Hi Richard,
>> >>
>> >> On 17/07/18 14:27, Richard Biener wrote:
>> >>> On Tue, Jul 17, 2018 a
Hi!
This patch adds support for C++ range for loops, including range for loops
with structured bindings for OpenMP constructs.
Tested on x86_64-linux, committed to gomp-5_0-branch.
2018-07-18 Jakub Jelinek
gcc/
* tree.h (OMP_CLAUSE_FIRSTPRIVATE_NO_REFERENCE): Define.
* gimpli
Hi again!
Well, since this hasn't been reviewed and I'm about to overhaul the
TYPE_OVERFLOW_WRAPS code anyhow, might as well lump it all in one patch.
On 07/16/2018 09:19 AM, Aldy Hernandez wrote:
Howdy!
I've abstracted out the cross product calculations into its own
function, and have adap
OK.
On Wed, Jul 18, 2018 at 6:20 PM, Jakub Jelinek wrote:
> On Wed, Jul 18, 2018 at 11:34:30AM +1000, Jason Merrill wrote:
>> On Wed, Jul 18, 2018 at 4:57 AM, Jakub Jelinek wrote:
>> > The standard says:
>> > "In the decl-specifier-seq of the lambda-declarator, each decl-specifier
>> > shall
>>
Hi Nagy/Ramana,
Please help us to review the attached patch and do let me know your comments .
No regress in the gcc.target suite for arm target.
Thank you
~Umesh
On Tue, Jul 17, 2018 at 4:01 PM, Umesh Kalappa wrote:
> Will do, thanks.
> Thanks
>
> On Tue, Jul 17, 2018, 3:24 PM Ramana Radhak
The following fixes the vectorizer part of PR86557, vectorizing
of EXACT_DIV_EXPR. The x86 backend still lacks arithmetic DImode
right shift support for vectors without AVX512.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2018-07-18 Richard Biener
PR tree
Hi,
The below patch fixes an ICE for the avr target when the setmemhi
expander is involved.
The setmemhi expander generated RTL ends up as an unrecognized insn
if the alignment of the destination exceeds that of a QI
mode const_int (127), AND the number of bytes to set fits in a QI
mode const_int
Hi Kyrlll,
> Am 18.07.2018 um 13:17 schrieb Kyrill Tkachov :
>
> Thomas, Janne, would this relaxation of NaN handling be acceptable given the
> benefits
> mentioned above? If so, what would be the recommended adjustment to the
> nan_1.f90 test?
I would be a bit careful about changing behavior
On 07/06/2018 12:28 PM, Richard Biener wrote:
> On Thu, Jul 5, 2018 at 4:12 PM Tom de Vries wrote:
>>
>> On 07/05/2018 01:39 PM, Richard Biener wrote:
>>> On Thu, Jul 5, 2018 at 1:25 PM Tom de Vries wrote:
[ was: Re: [testsuite/guality, committed] Prevent optimization of local in
v
On 18/07/18 14:26, Thomas König wrote:
Hi Kyrlll,
Am 18.07.2018 um 13:17 schrieb Kyrill Tkachov :
Thomas, Janne, would this relaxation of NaN handling be acceptable given the
benefits
mentioned above? If so, what would be the recommended adjustment to the
nan_1.f90 test?
I would be a bit c
On 07/18/2018 02:31 AM, Richard Biener wrote:
On Tue, 17 Jul 2018, Martin Sebor wrote:
The attached update takes care of a couple of problems pointed
out by Bernd Edlinger in his comments on the bug. The ICE he
mentioned in comment #20 was due mixing sizetype, ssizetype,
and size_type_node in
On Wed, Jul 18, 2018 at 5:03 PM, Kyrill Tkachov wrote:
>
> On 18/07/18 14:26, Thomas König wrote:
>
>> Hi Kyrlll,
>>
>> Am 18.07.2018 um 13:17 schrieb Kyrill Tkachov <
>>> kyrylo.tkac...@foss.arm.com>:
>>>
>>> Thomas, Janne, would this relaxation of NaN handling be acceptable given
>>> the benefi
Am 2018-07-18 um 01:50 schrieb Martin Sebor:
If there are no objections I'd like to backport the solution
for PR 85602 to avoid a class of unnecessary warnings for
safe uses of nonstring arrays. With the release coming up
later this week I'll go ahead and commit the patch tomorrow.
https://gcc.
On Wed, Jul 18, 2018 at 4:26 PM, Thomas König wrote:
> Hi Kyrlll,
>
> > Am 18.07.2018 um 13:17 schrieb Kyrill Tkachov <
> kyrylo.tkac...@foss.arm.com>:
> >
> > Thomas, Janne, would this relaxation of NaN handling be acceptable given
> the benefits
> > mentioned above? If so, what would be the rec
Thanks for doing this.
Kyrill Tkachov writes:
> + calc = build_call_expr_internal_loc (input_location, ifn, type,
> + 2, mvar, convert (type, val));
(indentation looks off)
> diff --git a/gcc/testsuite/gfortran.dg/max_fmaxl_aarch64.f90
> b/gcc/testsuite
In
struct ucontext;
typedef struct ucontext ucontext_t;
extern int (*bar) (ucontext_t *__restrict __oucp,
const ucontext_t *__restrict __ucp)
__attribute__((__indirect_return__));
extern int res;
void
foo (ucontext_t *oucp, ucontext_t *ucp)
{
res = bar (oucp, ucp);
}
bar
asan/asan_interceptors.cc has
...
int res = REAL(swapcontext)(oucp, ucp);
...
REAL(swapcontext) is a function pointer to swapcontext in libc. Since
swapcontext may return via indirect branch on x86 when shadow stack is
enabled, we need to call REAL(swapcontext) with indirect_return attribute
o
Hi.
This is aarch64 fix for PR83193. It's about setting of default options
so that --help=target -Q prints proper numbers:
Now this is seen on my cross-compiler:
--- /home/marxin/Downloads/options-2-before.txt 2018-07-18 14:53:11.658146543
+0200
+++ /home/marxin/Downloads/options-2.txt2
Hi.
This patch improves aarch64 feature modifier hints.
May I please ask ARM folks to test the patch?
Thanks,
Martin
gcc/ChangeLog:
2018-07-18 Martin Liska
PR driver/83193
* common/config/aarch64/aarch64-common.c (aarch64_parse_extension):
Set invalid_extension when
On 07/04/2018 04:23 AM, marxin wrote:
gcc/ChangeLog:
2018-07-11 Martin Liska
* align.h: New file.
Martin,
I'm seeing lots of warnings for this file:
/ssd/src/gcc/svn/gcc/align.h:53:32: warning: extended initializer lists
only available with -std=c++11 or -std=gnu++11
The code
Hi.
This introduces new ForceHelp option flag that helps to
print valid option enum values that are not directly
used as a type of an option.
May I please ask ARM folks to test the patch?
Thanks,
Martin
gcc/ChangeLog:
2018-07-18 Martin Liska
PR driver/83193
* config/arm/arm-
Hi Richard,
On 18/07/18 16:27, Richard Sandiford wrote:
Thanks for doing this.
Kyrill Tkachov writes:
+ calc = build_call_expr_internal_loc (input_location, ifn, type,
+ 2, mvar, convert (type, val));
(indentation looks off)
diff --git a/gcc/tes
Hi,
I've built the pretest of GDB 8.2 with MinGW today, and bumped into a
compilation error in libiberty:
if [ x"" != x ]; then \
gcc -c -DHAVE_CONFIG_H -O2 -gdwarf-4 -g3 -D__USE_MINGW_ACCESS -I.
-I./../include -W -Wall -Wwrite-strings -Wc++-compat -Wstrict-prototypes
-pedantic
Hi Martin,
Why is this needed when -mfpu does not seem to need it for instance?
Regarding the patch:
> -print "Name(processor_type) Type(enum processor_type)"
> -print "Known ARM CPUs (for use with the -mcpu= and -mtune= options):\n"
> +print "Name(processor_type) Type(enum processor_
On 07/18/2018 09:09 AM, Franz Sirl wrote:
Am 2018-07-18 um 01:50 schrieb Martin Sebor:
If there are no objections I'd like to backport the solution
for PR 85602 to avoid a class of unnecessary warnings for
safe uses of nonstring arrays. With the release coming up
later this week I'll go ahead a
Hi,
I've created a new git branch for developing the SVE ACLE (i.e. intrinsics)
implementation. Is the branches entry below OK to commit? Although the
branch is on git rather than svn, other git branches have also been
documented here.
Thanks,
Richard
Index: htdocs/svn.html
==
aarch64_float_const_representable_p was still returning false for
HFmode, so we wouldn't use 16-bit FMOV immediate. E.g. before the
patch:
__fp16 foo (void) { return 0x1.1p-3; }
gave:
mov w0, 12352
fmovh0, w0
with -march=armv8.2-a+fp16, whereas now it gives:
f
This patch adds the target framework for handling the SVE ACLE,
starting with four functions: svadd, svptrue, svsub and svsubr.
The ACLE has both overloaded and non-overloaded names. Without
the equivalent of clang's __attribute__((overloadable)), a header
file that declared all functions would n
On Wed, 18 Jul 2018, Richard Sandiford wrote:
> I've created a new git branch for developing the SVE ACLE (i.e.
> intrinsics) implementation. Is the branches entry below OK to commit?
Yes, thanks you!
(Perhaps ChangeLogs instead of changelogs, but I leave this to you.)
> Although the branch
What's ENDBR and do we really need to have it in compiler-rt?
As usual, I am opposed to any gcc compiler-rt that bypass upstream.
--kcc
On Wed, Jul 18, 2018 at 8:37 AM H.J. Lu wrote:
>
> asan/asan_interceptors.cc has
>
> ...
> int res = REAL(swapcontext)(oucp, ucp);
> ...
>
> REAL(swapcontext
On Wed, Jul 18, 2018 at 11:18 AM, Kostya Serebryany wrote:
> What's ENDBR and do we really need to have it in compiler-rt?
When shadow stack from Intel CET is enabled, the first instruction of all
indirect branch targets must be a special instruction, ENDBR. In this case,
int res = REAL(swapco
On Wed, Jul 18, 2018 at 11:40 AM H.J. Lu wrote:
>
> On Wed, Jul 18, 2018 at 11:18 AM, Kostya Serebryany wrote:
> > What's ENDBR and do we really need to have it in compiler-rt?
>
> When shadow stack from Intel CET is enabled, the first instruction of all
> indirect branch targets must be a speci
On Wed, 2018-07-04 at 10:53 +, Bernd Edlinger wrote:
Sorry for the delay in reviewing this.
> Hi,
>
> currently _Pragma("GCC diagnostic ...") does not properly
> work in macro expansions.
>
> Consider the following code:
>
> #define B _Pragma("GCC diagnostic push") \
> _Pragma("GCC
On Wed, Jul 18, 2018 at 11:45 AM, Kostya Serebryany wrote:
> On Wed, Jul 18, 2018 at 11:40 AM H.J. Lu wrote:
>>
>> On Wed, Jul 18, 2018 at 11:18 AM, Kostya Serebryany wrote:
>> > What's ENDBR and do we really need to have it in compiler-rt?
>>
>> When shadow stack from Intel CET is enabled, the
On Wed, Jul 18, 2018 at 12:29 PM H.J. Lu wrote:
>
> On Wed, Jul 18, 2018 at 11:45 AM, Kostya Serebryany wrote:
> > On Wed, Jul 18, 2018 at 11:40 AM H.J. Lu wrote:
> >>
> >> On Wed, Jul 18, 2018 at 11:18 AM, Kostya Serebryany
> >> wrote:
> >> > What's ENDBR and do we really need to have it in c
+ while (TREE_CODE (chartype) != INTEGER_TYPE)
+chartype = TREE_TYPE (chartype);
This is a bit concerning. First under what conditions is chartype not
going to be an INTEGER_TYPE? And under what conditions will extracting
its type ultimately lead to something that is an INTEGER_TYPE?
Ping, re these patches:
"[PATCH 1/2] v5: Add "optinfo" framework"
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00535.html
"[PATCH 2/2] Add "-fsave-optimization-record""
https://gcc.gnu.org/ml/gcc-patches/2018-07/msg00536.html
Thanks
Dave
On Wed, 2018-07-11 at 07:37 -0400, David Malcolm wr
On Wed, Jul 18, 2018 at 12:19:31PM +0200, Jakub Jelinek wrote:
> Shall I submit an incremental patch for the "abi_tag", "gnu", "begin", "end",
> "get",
> "tuple_size", "tuple_element" etc. identifiers?
Here it is in an incremental patch. I've tried to do it only for
get_identifier ("string liter
Hi Carl,
On Tue, Jul 17, 2018 at 04:39:58PM -0700, Carl Love wrote:
> I was requested to backport the patch for the AIX test case failures to
> GCC 8. The trunk patch applied cleanly to GCC 8. I updated the
> changelog patch, built and retested the patch on:
>
> powerpc64le-unknown-linux-gn
This is a patch to support the Aarch64 SIMD ABI [1] in GCC. I intend
to eventually follow this up with two more patches; one to define the
TARGET_SIMD_CLONE* macros and one to improve the GCC register
allocation/usage when calling SIMD functions.
The significant difference between the standard AR
So cool! Thanks.
Sorry for the top posting
nathan-- Nathan Sidwell
Original message From: Jakub Jelinek Date:
7/18/18 17:04 (GMT-05:00) To: Nathan Sidwell Cc: Jason
Merrill , gcc-patches@gcc.gnu.org Subject: [C++ PATCH]
Further get_identifier ("string literal") C++ FE cachin
On Wed, Jul 18, 2018 at 06:00:20PM -0400, Nathan Sidwell wrote:
> So cool! Thanks.
Ok for both patches or just this one?
Jakub
Hi Mike,
On Fri, Jul 13, 2018 at 04:56:13PM -0400, Michael Meissner wrote:
> This means rather than keeping the toc fusion around (that nobody used), I
> would prefer to delete the current code, and replace it with better code as I
> implement it.
> +++ gcc/config/rs6000/constraints.md (working
Hi,
This patch improves memset/memcpy strategy for Skylake. Ok for trunk?
* gcc/config/i386/x86-tune-costs.h (skylake_memcpy,
skylake_memcpy): Replace rep_prefix with unrolling on 512.
Thanks,
Julia
0001-memset.patch
Description: 0001-memset.patch
On Thu, Jul 19, 2018 at 7:00 AM, Koval, Julia wrote:
> Hi,
> This patch improves memset/memcpy strategy for Skylake. Ok for trunk?
Is this patch based on some benchmark data?
Uros.
> * gcc/config/i386/x86-tune-costs.h (skylake_memcpy,
> skylake_memcpy): Replace rep_prefix with u
if (TREE_CODE (idx) != INTEGER_CST
&& TREE_CODE (argtype) == POINTER_TYPE)
{
/* From a pointer (but not array) argument extract the variable
index to prevent get_addr_base_and_unit_offset() from failing
due to it.
Yes, it gives small improvements(~2%) on 557.xz on O2 and on
548.exchange(~2.5%) and 500.perlbench(~1%) on Ofast in rate mode.
> -Original Message-
> From: Uros Bizjak [mailto:ubiz...@gmail.com]
> Sent: Thursday, July 19, 2018 8:12 AM
> To: Koval, Julia
> Cc: GCC Patches
> Subject: Re:
On Thu, Jul 19, 2018 at 8:20 AM, Koval, Julia wrote:
> Yes, it gives small improvements(~2%) on 557.xz on O2 and on
> 548.exchange(~2.5%) and 500.perlbench(~1%) on Ofast in rate mode.
>
>> -Original Message-
>> From: Uros Bizjak [mailto:ubiz...@gmail.com]
>> Sent: Thursday, July 19, 2018
60 matches
Mail list logo
