On Sat, 25 Oct 2014, Martin Uecker wrote:
Strictly speaking the C standard considers such pointers to be
incompatible. This seems to be an unintentional consequence
of how qualifiers are always attached to the element type.
(I am trying to get the standard revised too.) The new
behaviour
On 27 October 2014 13:10, Joseph S. Myers wrote:
On Sat, 25 Oct 2014, Martin Uecker wrote:
Strictly speaking the C standard considers such pointers to be
incompatible. This seems to be an unintentional consequence
of how qualifiers are always attached to the element type.
(I am trying to get
Jonathan Wakely jwakely@gmail.com:
On 27 October 2014 13:10, Joseph S. Myers wrote:
On Sat, 25 Oct 2014, Martin Uecker wrote:
Strictly speaking the C standard considers such pointers to be
incompatible. This seems to be an unintentional consequence
of how qualifiers are always
On Mon, 27 Oct 2014, Martin Uecker wrote:
3.9.3(5) ...
Cv-qualifiers applied to an array type attach to the
underlying element type, so the notation cv T, where
T is an array type, refers to an array whose elements
are so-qualified. Such array types can be said to be
more (or less)
Am 10/24/2014 08:29 PM, schrieb Jakub Jelinek:
On Fri, Oct 24, 2014 at 08:19:57PM +0200, Georg-Johann Lay wrote:
Yes, that's the straight forward approach which works so far. Bit tedious,
but well...
In one case expmed generated different code, though: divmodhi instead of
mulhi_highpart for
On 10/27/14 13:33, Georg-Johann Lay wrote:
Am 10/24/2014 08:29 PM, schrieb Jakub Jelinek:
On Fri, Oct 24, 2014 at 08:19:57PM +0200, Georg-Johann Lay wrote:
Yes, that's the straight forward approach which works so far. Bit
tedious,
but well...
In one case expmed generated different code,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Dear GCC Mirror Admin,
I have rearranged our mirror setup which means we offer additional
mirror servers mirroring GCC. Could you please make the following changes:
- - Remove the current 'mirror.bbln.org' entry as mirror
- - Please add the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
Igor Zamyatin izamyatin at gmail dot com changed:
What|Removed |Added
CC||izamyatin at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #6 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Igor Zamyatin from comment #5)
Confirmed. This will affect all SSE targets.
Have you managed to reproduce the issue on i686?
No, only with a crosscompiler to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #7 from Uroš Bizjak ubizjak at gmail dot com ---
The difference si that the call to f128_p3 does not expand with use (reg:SI
bx) tag in the Darwin case. Probably ix86_expand_call should be fixed for
TARGET_MACHO.
However, even if
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63652
Bug ID: 63652
Summary: [AArch64_be] vzip/vuzp tests fail
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63641
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63653
Bug ID: 63653
Summary: [AArch64_be] vldX/vldX_lane tests fail
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63654
Bug ID: 63654
Summary: An explicit copy constructor should be used in the
second step of a class copy-initialization.
Product: gcc
Version: 5.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63205
Paul Thomas pault at gcc dot gnu.org changed:
What|Removed |Added
CC||pault at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54521
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC||kariya_mitsuru
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63654
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #48 from Dominique d'Humieres dominiq at lps dot ens.fr ---
--- Comment #44 from Iain Sandoe iains at gcc dot gnu.org ---
(In reply to Stupachenko Evgeny from comment #43)
[...]
there were at one point this week 4 concurrent
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #8 from Stupachenko Evgeny evstupac at gmail dot com ---
(In reply to Uroš Bizjak from comment #7)
The difference si that the call to f128_p3 does not expand with use (reg:SI
bx) tag in the Darwin case. Probably ix86_expand_call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #9 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Stupachenko Evgeny from comment #8)
(In reply to Uroš Bizjak from comment #7)
The difference si that the call to f128_p3 does not expand with use (reg:SI
bx) tag in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63650
--- Comment #7 from Richard PALO richard at netbsd dot org ---
Further testing indicates that 'cdecl' is okay and that keeping 'regparm(0)'
causes the error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63655
Bug ID: 63655
Summary: ice using -O2 -floop-parallelize-all
Product: gcc
Version: 4.8.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63646
Yury Gribov y.gribov at samsung dot com changed:
What|Removed |Added
CC||y.gribov at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63656
Bug ID: 63656
Summary: a-tags.adb:82:04: warning: types for unchecked
conversion have different sizes
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63638
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #14 from M Welinder terra at gnome dot org ---
1) Your malloc is too small. It has to be sizeof (biggest member).
So you're invoking undefined behavior.
Can you produce a specific authoritative reference for that statement?
I.e., a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #10 from Stupachenko Evgeny evstupac at gmail dot com ---
(In reply to Uroš Bizjak from comment #9)
(In reply to Stupachenko Evgeny from comment #8)
(In reply to Uroš Bizjak from comment #7)
The difference si that the call to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #15 from M Welinder terra at gnome dot org ---
FYI, I filed a related bug for valgrind covering the problem with the
conditional jump being detected as undefined:
https://bugs.kde.org/show_bug.cgi?id=340392
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610
howarth at bromo dot med.uc.edu changed:
What|Removed |Added
CC||howarth at bromo dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610
--- Comment #7 from howarth at bromo dot med.uc.edu ---
I can confirm that there are many regressions (particularly in the fortran test
suite) on Yosemite due to the libtool bug which causes shared libraries to be
linked as if the target was
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610
--- Comment #8 from Volker Braun vbraun.name at gmail dot com ---
Another workaround is to set MACOSX_DEPLOYMENT_TARGET=10.9
Libtool-2.4.3 will have the fix, gcc (and everybody else) should just
reconfigure when its out.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #11 from Uroš Bizjak ubizjak at gmail dot com ---
(In reply to Stupachenko Evgeny from comment #10)
Anyway, if call is not EBX dependent (say local call in Linux) the issue is
not reproduced (like in example from PR63618).
So the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58644
Paul Thomas pault at gcc dot gnu.org changed:
What|Removed |Added
CC||pault at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63657
Bug ID: 63657
Summary: [4.9 regression] -Wunused-variable: warning supressed
by virtual dtor fn
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63610
--- Comment #9 from howarth at bromo dot med.uc.edu ---
Alternatively, you can just make sure you don't set MACOSX_DEPLOYMENT_TARGET in
your shell.
Also mote that gmp, mpfr and mpc also suffer from this bug and, if built on
10.10, should either
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62279
Kai Tietz ktietz at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
--- Comment #9 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Mon Oct 27 14:04:43 2014
New Revision: 216736
URL: https://gcc.gnu.org/viewcvs?rev=216736root=gccview=rev
Log:
[Vectorizer] Make REDUC_xxx_EXPR tree codes produce a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61114
--- Comment #10 from alalaw01 at gcc dot gnu.org ---
Author: alalaw01
Date: Mon Oct 27 14:20:52 2014
New Revision: 216737
URL: https://gcc.gnu.org/viewcvs?rev=216737root=gccview=rev
Log:
Add new optabs for reducing vectors to scalars
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #16 from Markus Trippelsdorf trippels at gcc dot gnu.org ---
(In reply to M Welinder from comment #14)
2) In the if statement, where you probe the different members, you
also invoke undefined behavior.
Absolutely not! I went
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=23055
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63648
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63658
Bug ID: 63658
Summary: [4.8/4.9 Regression] Using class reference as template
parameter causes compilation to fail
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61915
--- Comment #18 from Wilco wdijkstr at arm dot com ---
(In reply to Andrew Pinski from comment #17)
(In reply to Wilco from comment #16)
(In reply to Andrew Pinski from comment #13)
(In reply to Wilco from comment #9)
I committed a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59799
Ramana Radhakrishnan ramana at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63658
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Severity|major |normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #17 from M Welinder terra at gnome dot org ---
You keep saying undefined behaviour, but you keep avoiding
substantiating that claim.
Where, in the C99 standard, is the clause that makes things undefined?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63658
Jonathan Wakely redi at gcc dot gnu.org changed:
What|Removed |Added
Keywords||rejects-valid
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #18 from M Welinder terra at gnome dot org ---
The example at strict-aliasing in the gcc man page covers a different
situation: you don't get to access a double via an int.
I get it.
But the standard says that in certain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #19 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
Given
GnmExprBinary res;
GnmExpr const *expr = (GnmExpr *)res;
the C standard does not define where the result of the conversion points;
all that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63576
Ilya Palachev i.palachev at samsung dot com changed:
What|Removed |Added
CC||i.palachev
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org ---
(In reply to jos...@codesourcery.com from comment #19)
Given
GnmExprBinary res;
GnmExpr const *expr = (GnmExpr *)res;
Let's consider if in #c11 you change:
GnmExprBinary
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63659
Bug ID: 63659
Summary: wrong code at -O2 and -O3 on x86_64-linux-gnu
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63659
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #21 from Andreas Schwab sch...@linux-m68k.org ---
This is only valid if the object is of the union type (union _GnmExpr)
(§6.5.2.3#6: if the union object currently contains one of these structures).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63659
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #22 from M Welinder terra at gnome dot org ---
Given
GnmExprBinary res;
GnmExpr const *expr = (GnmExpr *)res;
the C standard does not define where the result of the conversion points;
How do you read C99's Section 6.5 #7,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63659
--- Comment #3 from Jakub Jelinek jakub at gcc dot gnu.org ---
Seems this is a REE bug. Before REE pass, we have:
(insn 4 27 76 6 (set (reg/v:QI 0 ax [orig:59 k ] [59])
(const_int -1 [0x])) pr63659.c:18 66
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62194
--- Comment #1 from Josh Triplett josh at joshtriplett dot org ---
An additional corner case: a deadfield, even one that has a default value to
allow reads of it to work rather than erroring out, must be an rvalue, so that
attempts to take the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62194
--- Comment #2 from Josh Triplett josh at joshtriplett dot org ---
One alternative implementation: if GCC supported a property attribute,
specifying (optional) functions to get or set the property (with compile-time
errors if attempting to
This is bug 41698. Please send a patch to gcc-patches, including the
addition of a testcase to the testsuite.
--
Joseph S. Myers
jos...@codesourcery.com
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #15 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Sun, 26 Oct 2014, Keith.S.Thompson at gmail dot com wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61502
--- Comment #14 from Keith Thompson
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #23 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Mon, 27 Oct 2014, jakub at gcc dot gnu.org wrote:
Let's consider if in #c11 you change:
GnmExprBinary *res = malloc (sizeof (GnmExprBinary));
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63660
Bug ID: 63660
Summary: [4.8-4.9+] -Wmaybe-uninitialized false positive with
-O1 and more
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63620
--- Comment #12 from Jeffrey A. Law law at redhat dot com ---
The more I watch the %ebx PIC problems, the more this reminds me of secondary
reloads and I wonder if we defined those properly if the right things would
happen.
This kind of thing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63659
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #24 from joseph at codesourcery dot com joseph at codesourcery dot
com ---
On Mon, 27 Oct 2014, terra at gnome dot org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63645
--- Comment #22 from M Welinder terra at gnome dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=62194
--- Comment #3 from Josh Triplett josh at joshtriplett dot org ---
(In reply to Josh Triplett from comment #2)
One alternative implementation: if GCC supported a property attribute,
specifying (optional) functions to get or set the property
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661
Bug ID: 63661
Summary: -O2 miscompiles on OSX 10.10 Yosemite
Product: gcc
Version: 4.9.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661
--- Comment #1 from Volker Braun vbraun.name at gmail dot com ---
Created attachment 33822
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33822action=edit
Output of gcc -v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63582
DJ Delorie dj at redhat dot com changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63661
--- Comment #2 from Volker Braun vbraun.name at gmail dot com ---
Created attachment 33823
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33823action=edit
Preprocessed source
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
Jeremy Huddleston Sequoia jeremyhu at macports dot org changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61407
--- Comment #43 from Jeremy Huddleston Sequoia jeremyhu at macports dot org
---
Created attachment 33824
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33824action=edit
gcc 4.2 based patch which handles tiny version numbers properly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59799
--- Comment #11 from Michael Hudson-Doyle michael.hudson at linaro dot org ---
Er yes, this was fixed before 4.9.0.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63658
Daniel Krügler daniel.kruegler at googlemail dot com changed:
What|Removed |Added
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63534
--- Comment #49 from Igor Zamyatin izamyatin at gmail dot com ---
Testing a patch to fix asan failures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63442
--- Comment #5 from Jiong Wang jiwang at gcc dot gnu.org ---
Author: jiwang
Date: Mon Oct 27 21:58:59 2014
New Revision: 216765
URL: https://gcc.gnu.org/viewcvs?rev=216765root=gccview=rev
Log:
PR63442 libgcc_cmp_return_mode not always return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63442
Jiong Wang jiwang at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662
Bug ID: 63662
Summary: __has_include defined but not implemented
Product: gcc
Version: 4.9.2
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662
Andrew Pinski pinskia at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63530
--- Comment #5 from carrot at gcc dot gnu.org ---
Author: carrot
Date: Tue Oct 28 00:20:13 2014
New Revision: 216770
URL: https://gcc.gnu.org/viewcvs?rev=216770root=gccview=rev
Log:
PR tree-optimization/63530
tree-vect-data-refs.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63663
Bug ID: 63663
Summary: [NEON] wrong value when computing the leading zero
of int16x4_t type at O2
Product: gcc
Version: 5.0
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63662
andre.mccurdy at linaro dot org changed:
What|Removed |Added
Summary|__has_include defined but |__has_include is not
On October 27, 2014 1:49:54 AM CET, David Edelsohn dje@gmail.com wrote:
Richi,
Does genmatch rely on static constructors or implicitly rely on the
order of static constructors? Sometimes those cause problems on AIX.
No, it doesn't.
Bootstrap on AIX succeeds prior to r216631, e.g., r216624.
Thanks for the comments. All comments are accepted and the updated patch is
attached.
-Zhenqiang
-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: Saturday, October 11, 2014 11:00 PM
To: Zhenqiang Chen; gcc-patches@gcc.gnu.org
Subject: Re: [Ping] [PATCH,
Thanks for the comments. All comments are accepted and the updated patch is
attached.
-Zhenqiang
-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: Saturday, October 11, 2014 11:22 PM
To: Zhenqiang Chen; gcc-patches@gcc.gnu.org
Subject: Re: [Ping] [PATCH,
Thanks for the comments. Patch is updated.
-Zhenqiang
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Richard Henderson
Sent: Saturday, October 11, 2014 11:03 PM
To: Zhenqiang Chen; gcc-patches@gcc.gnu.org
Subject: Re:
-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: Saturday, October 11, 2014 11:32 PM
To: Zhenqiang Chen; gcc-patches@gcc.gnu.org
Subject: Re: [Ping] [PATCH, 6/10] aarch64: add ccmp CC mode
On 09/22/2014 11:44 PM, Zhenqiang Chen wrote:
+case
-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: Sunday, October 12, 2014 12:52 PM
To: Zhenqiang Chen; gcc-patches@gcc.gnu.org
Subject: Re: [Ping] [PATCH, 7/10] aarch64: add function to output ccmp
insn
On 10/11/2014 09:11 AM, Richard Henderson wrote:
-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: Sunday, October 12, 2014 4:12 AM
To: Zhenqiang Chen; gcc-patches@gcc.gnu.org
Subject: Re: [Ping] [PATCH, 8/10] aarch64: ccmp insn patterns
On 09/22/2014 11:45 PM, Zhenqiang Chen wrote:
+(define_expand
-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: Sunday, October 12, 2014 4:46 AM
To: Zhenqiang Chen; gcc-patches@gcc.gnu.org
Subject: Re: [Ping] [PATCH, 9/10] aarch64: generate conditional compare
instructions
On 09/22/2014 11:46 PM, Zhenqiang Chen
-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: Sunday, October 12, 2014 5:40 AM
To: Zhenqiang Chen; gcc-patches@gcc.gnu.org
Subject: Re: [Ping] [PATCH, 10/10] aarch64: Handle ccmp in ifcvt to make
it
work with cmov
On 09/22/2014 11:46 PM, Zhenqiang
The results are the same for Silvermont.
There are no significant changes on Haswell.
So I agree with Richard, let's enable this x86 wide.
Bootstrap/ passed.
Make check in progress.
Is it ok?
2014-10-25 Evgeny Stupachenko evstu...@gmail.com
* config/i386/i386.c
Ping again...
Thanks.
From: bernd.edlin...@hotmail.de
To: hubi...@ucw.cz
CC: gcc-patches@gcc.gnu.org; richard.guent...@gmail.com
Subject: [PING] [PATCH] Fix PR ipa/61190, 2nd edition
Date: Tue, 14 Oct 2014 11:40:56 +0200
Ping...
see:
On 10/25/2014 12:10 PM, Richard Sandiford wrote:
This is part of a series to remove uses of for_each_rtx from the ports.
I think we only want to consider MEMs in patterns here, not MEMs in notes etc.
(Not sure why I fixed it for s390 but not for x86...)
Tested by making sure there were no
do you have any other (system) version of GCC, configured without
--disable-libsanitizer?
Nope.
2) Make check_effective_target_fsanitize_address not only link dummy
executable, but also run it and verify that exit code equals zero.
Yes, probably something along these lines, or restore the
+/* Handle pragmas for compatibility with Intel's compilers. */
+#define REGISTER_TARGET_PRAGMAS() do {
\
+ c_register_pragma (0, long_calls, aarch64_pr_long_calls);
\
+ c_register_pragma (0, no_long_calls, aarch64_pr_no_long_calls);
When assigning symbols to sections in ipa-comdats.c we currently
segfault when val is NULL. Fix by guarding against this case.
Tested on powerpc64-unknown-linux-gnu.
OK for trunk?
2014-10-27 Markus Trippelsdorf mar...@trippelsdorf.de
PR ipa/63649
* ipa-comdats.c
1 - 100 of 273 matches
Mail list logo
