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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37704
Eric Gallager changed:
What|Removed |Added
Keywords||build
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69179
--- Comment #4 from Eric Gallager ---
(In reply to Iain Sandoe from comment #3)
> (In reply to sandra from comment #0)
> > config/darwin.c defines attributes "apple_kext_compatibility" and
> > "weak_import" which have no documentation in the GCC
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60440
--- Comment #4 from Eric Gallager ---
(In reply to Martin Liška from comment #3)
> Thanks for CC. Patches are currently under review.
> About this PR: as 'b' is undeclared, the whole statement with the expression
> is ignored and we have:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36994
Eric Gallager changed:
What|Removed |Added
Keywords||build
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86552
--- Comment #2 from Martin Sebor ---
Created attachment 44407
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44407=edit
Preliminary patch.
Lightly tested patch to apply on top of the one for bug 86532.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86583
Bug ID: 86583
Summary: exception specification of explicitly defaulted
destructor does not match the calculated one
Product: gcc
Version: 9.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86578
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86582
Bug ID: 86582
Summary: [debug] vla size reported as 0 at Og
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86578
--- Comment #1 from Andrew Pinski ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=17743
GCC 4.3.x and above support this feature.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86581
Bug ID: 86581
Summary: constexpr variable is not checked
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86580
Bug ID: 86580
Summary: No warning for default arguments
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553
--- Comment #12 from Jonathan Wakely ---
Both. It's been low priority because I noticed it by observation, but it's
never been reported by users or caused any problems that I'm aware of (until
now, maybe).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86579
Bug ID: 86579
Summary: invalid operands to binary expression
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86578
Bug ID: 86578
Summary: requested alignment is dependent but declaration is
not dependent
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86577
Bug ID: 86577
Summary: non-ADL name lookup for operator<< at instantiation
time?
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86414
Carl Love changed:
What|Removed |Added
Status|RESOLVED|CLOSED
--- Comment #4 from Carl Love ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86414
Carl Love changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
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
Snapshot gcc-6-20180718 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/6-20180718/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 6 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86544
--- Comment #4 from kugan at gcc dot gnu.org ---
Author: kugan
Date: Wed Jul 18 22:11:24 2018
New Revision: 262864
URL: https://gcc.gnu.org/viewcvs?rev=262864=gcc=rev
Log:
gcc/ChangeLog:
2018-07-18 Kugan Vivekanandarajah
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86414
--- Comment #2 from Carl Love ---
Author: carll
Date: Wed Jul 18 22:12:20 2018
New Revision: 262865
URL: https://gcc.gnu.org/viewcvs?rev=262865=gcc=rev
Log:
gcc/testsuite/ChangeLog:
2018-07-18 Carl Love
Backport from mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86576
Bug ID: 86576
Summary: [F03][OOP] Sourced allocation of object array fails
with SEGFAULT
Product: gcc
Version: 8.1.0
Status: UNCONFIRMED
Severity: normal
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
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
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:
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57160
--- Comment #10 from janus at gcc dot gnu.org ---
(In reply to janus from comment #9)
> As noted already somewhere in the discussion of PR85599 on the mailing list,
> this breaks actual_pointer_function_1.f90 in the testsuite
... but apart from
On Wed, Jul 18, 2018 at 11:51:36AM +0200, Richard Biener wrote:
> We already conditionally require Perl for building for some targets so I
> wonder
> if using perl would be better ...
At least perl is GPL (Python is not).
What would the advantage of using Python be? I haven't heard any yet.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86469
--- Comment #15 from Jonny Grant ---
Hi Richard
I cannot reproduce DWARF errors without undefined references (by removing the
implementation of a function).
It is taking me a long time to reduce and still keep the error
Which has different
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86550
--- Comment #2 from Jakub Jelinek ---
Author: jakub
Date: Wed Jul 18 21:01:54 2018
New Revision: 262862
URL: https://gcc.gnu.org/viewcvs?rev=262862=gcc=rev
Log:
PR c++/86550
* parser.c (cp_parser_decl_specifier_seq): Diagnose
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57160
janus at gcc dot gnu.org changed:
What|Removed |Added
CC||janus at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599
janus at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #11 from Ian Lance Taylor ---
Sorry, you're right, it's -fdump-go-spec.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86574
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |WAITING
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #10 from Curtis Hamilton ---
Is it -fgo-dump-spec or -fdump-go-spec? Below is an extract of my build log:
checking for hypotf... /usr/ports/lang/gcc7/work/.build/./gcc/xgcc
-B/usr/ports/lang/gcc7/work/.build/./gcc/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86553
--- Comment #11 from The Written Word
---
(In reply to Jonathan Wakely from comment #7)
> As I suspected, something is doing:
>
> #define fabsl(X) fabs((double) (X))
> #define acosl(X) acos((double) (X))
> etc.
>
> This would probably be
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
+ 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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #9 from Ian Lance Taylor ---
I haven't tried to recreate the problem on FreeBSD. I've just tried various
inputs to GCC 7 -fgo-dump-spec.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518
--- Comment #9 from Alexander Monakov ---
One more: -Wimplicit-fallthrough issue uncovered by the testsuite: PR 86575.
So far all issues appeared in gcc-6 or more recent.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69558
--- Comment #25 from Bernd Edlinger ---
Author: edlinger
Date: Wed Jul 18 19:36:01 2018
New Revision: 262861
URL: https://gcc.gnu.org/viewcvs?rev=262861=gcc=rev
Log:
libcpp:
2018-07-18 Bernd Edlinger
PR 69558
* macro.c
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86535
--- Comment #8 from Curtis Hamilton ---
Based on you last comment, I attempted a build using FreeBSD 11.2 RC1 on the
same hardware (PowerMac G5 Quad) and got the same results.
Are you using native hardware or emulation?
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,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86570
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86573
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86575
Bug ID: 86575
Summary: -Wimplicit-fallthrough affects code generation
Product: gcc
Version: 7.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86573
--- Comment #2 from Marc Glisse ---
When passing by copy, gcc seems to manage with default flags, but your
-std=c++2a -fno-exceptions hinder it somehow.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86574
Bug ID: 86574
Summary: ICE on std::prev with ranges::view::transform
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86573
--- Comment #1 from Marc Glisse ---
Try renaming 'main' to any other name and gcc does optimize...
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") \
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81397
Eric Gallager changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #28 from Bernd Edlinger ---
Yes, agreed.
Should I send a patch to take out the statement in comment #17,
or will you do that in your follow-up patch?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86573
Bug ID: 86573
Summary: Failure to optimise passing simple values to inlined
function
Product: gcc
Version: tree-ssa
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86569
Martin Sebor changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
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
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 =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86571
Martin Sebor changed:
What|Removed |Added
Keywords||wrong-code
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85599
--- Comment #37 from janus at gcc dot gnu.org ---
Author: janus
Date: Wed Jul 18 18:31:59 2018
New Revision: 262860
URL: https://gcc.gnu.org/viewcvs?rev=262860=gcc=rev
Log:
2018-07-18 Janus Weil
Thomas Koenig
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86532
--- Comment #27 from Martin Sebor ---
I don't think it would be appropriate to introduce dependencies on the
sanitizer for the same reason we can't do that for warnings. But as I
mentioned in comment 16, I think performing these sorts of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86469
--- Comment #14 from Jonny Grant ---
Hello Richard
My archive of the original problem didn't show it. But when I tried to
re-create I got the following. I'll try also make a small test case for this
one while I have it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86572
Martin Sebor changed:
What|Removed |Added
See Also||https://gcc.gnu.org/bugzill
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);
> ...
>
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86572
Bug ID: 86572
Summary: unsafe strlen folding of const arguments with
non-const offset
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
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
Jonathan Wakely :
> I don't see any mention of avoiding dict comprehensions (not supported
> until 2.7, so unusable on RHEL6/CentOS6 and SLES 11).
That is correct. The HOWTO introduction does say that its techniques
won't guarantee 2.6 compatibility. That would have been a great deal more
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86571
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86571
Bug ID: 86571
Summary: AIX NaNQ and NaNS output format conflicts with
__builtin_sprintf
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
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
On 18.07.2018 19:29, Paul Koning wrote:
>
>
>> On Jul 18, 2018, at 1:22 PM, Boris Kolpackov wrote:
>>
>> Paul Koning writes:
>>
On Jul 18, 2018, at 11:13 AM, Boris Kolpackov
wrote:
I wonder what will be the expected way to obtain a suitable version of
Python if one
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:
Hi,
I tried doing as suggested
+ dfi.pflags = 0;
+ dump_switch_p_1 (arg, , false);
1.> the value of dfi.pflags is not changing even if different command
line options are passed like -fdump-blocks or -fdump-vops
2.> what is the significance of bool doglob?
Please find the diff file attached
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
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
> On Jul 18, 2018, at 1:22 PM, Boris Kolpackov wrote:
>
> Paul Koning writes:
>
>>> On Jul 18, 2018, at 11:13 AM, Boris Kolpackov
>>> wrote:
>>>
>>> I wonder what will be the expected way to obtain a suitable version of
>>> Python if one is not available on the build machine? With awk I
Paul Koning writes:
> > On Jul 18, 2018, at 11:13 AM, Boris Kolpackov
> > wrote:
> >
> > I wonder what will be the expected way to obtain a suitable version of
> > Python if one is not available on the build machine? With awk I can
> > build it from source pretty much anywhere. Is building
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86570
Bug ID: 86570
Summary: Conditional statement doesn't trigger sincos transform
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85602
--- Comment #14 from Martin Sebor ---
Author: msebor
Date: Wed Jul 18 17:20:05 2018
New Revision: 262859
URL: https://gcc.gnu.org/viewcvs?rev=262859=gcc=rev
Log:
Backport from trunk.
PR middle-end/85602 - -Wsizeof-pointer-memaccess for strncat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86566
--- Comment #3 from kargl at gcc dot gnu.org ---
The proper way to preprocess Fortran code is with the Fortran
compiler. You can and should use 'gfortran -cpp'. See the
documentation that comes with your compiler.
If you think you need to use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86555
Rich Felker changed:
What|Removed |Added
CC||bugdal at aerifal dot cx
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86518
--- Comment #8 from Alexander Monakov ---
Other files seem to miscompare due to -Wnonnull-compare: PR 86569.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86569
Bug ID: 86569
Summary: -Wnonnull-compare affects code generation
Product: gcc
Version: 6.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
> On Jul 18, 2018, at 11:13 AM, Boris Kolpackov wrote:
>
> On Tue, 2018-07-17 at 14:49 +0200, Martin Liška wrote:
>
>> My question is simple: can we starting using a scripting language like
>> Python and replace usage of the AWK scripts?
>
> I wonder what will be the expected way to obtain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59480
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On Tue, 17 Jul 2018 20:23:36 -0400
David Malcolm wrote:
> On Tue, 2018-07-17 at 16:37 -0400, David Niklas wrote:
> > > Hi.
> > >
> > > I've recently touched AWK option generate machinery and it's quite
> > > unpleasant to make any adjustments. My question is simple: can we
> > > starting using a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86450
--- Comment #26 from Jonathan Wakely ---
No, I needed far more than that. Obviously I needed the right versions of
autoconf and automake first in my PATH, which is simple. But I also needed to
use contrib/gcc_update to fix all the timestamps, so
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
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 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
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
*
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86568
Bug ID: 86568
Summary: -Wnonnull warnings should highlight the relevant
argument not the closing parenthesis
Product: gcc
Version: 9.0
Status: UNCONFIRMED
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
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.txt
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
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);
}
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
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86555
--- Comment #4 from Ramana Radhakrishnan ---
(In reply to Khem Raj from comment #2)
> we can avoid the problem by altering the structure, thats not an issue, but
> do you think compiler is right here by assuming to generate LDRD on a 4byte
>
1 - 100 of 209 matches
Mail list logo
