https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71539
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71539
--- Comment #2 from cubitect at gmail dot com ---
Thank you for the tip! I was unaware that signed integer overflow is undefined
in standard C. I was rewriting some java code in C when I ran into this
problem, so this makes sense now. (Though I
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71539
mednafen at sent dot com changed:
What|Removed |Added
CC||mednafen at sent dot com
---
The following patch adds support and native detection for C7, Eden
"Samuel2", Eden "Nehemiah", Eden "Esther", Eden x2, Eden x4, Nano 1xxx,
Nano 2xxx, Nano 3xxx, Nano x2 and Nano x4 VIA CPUs.
Sorry for the bogus character encoding of my previous mail.
Please CC me to any comment / review / change
The following patch adds support and native detection for C7, Eden
"Samuel2", Eden "Nehemiah", Eden "Esther", Eden x2, Eden x4, Nano 1xxx,
Nano 2xxx, Nano 3xxx, Nano x2 and Nano x4 VIA CPUs.
Please CC me to any comment / review / change request.
---
diff --git a/gcc/config/i386/driver-i386.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69523
--- Comment #7 from Eric Fiselier ---
> The warning should be controlled by *some* flag, but I'm not sure whether or
> not linking it with -Wliteral-suffix makes sense. I'll prepare a patch and
> see what people think.
Any update? I would be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71539
Bug ID: 71539
Summary: incomplete execution of a nested loop for -O2 and -O3
Product: gcc
Version: 5.3.1
Status: UNCONFIRMED
Severity: normal
Priority: P3
On Tue, Jun 14, 2016 at 09:26:19AM -0700, H.J. Lu wrote:
> On Thu, May 26, 2016 at 4:02 AM, Alan Modra wrote:
> > This fixes lack of bb_loop_depth info in some of the early parts of
> > ira, which has been the case for quite some time. All active branches
> > return 0 from
On Tue, Jun 14, 2016 at 6:12 PM, Paolo Carlini wrote:
> constexpr-specialization.C:7:26: error: redeclaration ‘constexpr int foo(T)
> [with T = int]’ differs in ‘constexpr’
>
> constexpr-specialization.C:6:16: error: from previous declaration ‘constexpr
> int foo(T)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71537
--- Comment #2 from Eric Fiselier ---
Hi Martin,
The 'xx' case is only accepted if it occurs at a global scope. If it appears
in a function body it is still rejected.
Resolve some test failures introduced for little endian arc as a result
of the recent arc/nps400 additions.
There's a new peephole2 optimisation to merge together two zero_extracts
in order that the movb instruction can be used.
Source operand mode filled in for a peephole2 optimisation, to
Joern,
Thanks for taking the time to review the previous patch.
I've revised the original fix-up patch to remove the addition of the
MODE in the zn_compare_operator case as you suggest, this is patch #1.
Patch #2 is an attempt to address you comment:
A generator program complaining about a
In md.texi it says:
Predicates written with @code{define_special_predicate} do not get any
automatic mode checks, and are treated as having special mode handling
by @command{genrecog}.
However, in genrecog, when validating a SET pattern, if either the
source or destination is missing a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71537
Martin Sebor changed:
What|Removed |Added
Keywords||rejects-valid
Hi,
I discovered some duplicate #define's in config/rs6000/rs6000-builtin.def.
This patch removes those, and corrects a commentary typo that I noticed
while I was in there. Bootstrapped and tested on powerpc64le-unknown-linux-gnu
with no regressions. Preapproved, committed.
Thanks,
Bill
On Mon, Jun 13, 2016 at 02:29:41PM -0400, Michael Meissner wrote:
> It would help if I included the patch.
:-)
> > Are these changes ok to install in the trunk? Assuming they go in the
> > trunk,
> > can I install them in the 6.2 branch if they cause no regression?
Okay for trunk. Okay for 6
Snapshot gcc-5-20160614 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/5-20160614/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-5
Hi,
today I noticed the below while I was putting together another batch of
minor diagnostic fixes. The error + error to error + inform change seems
rather straightforward to me and as usual adds clarity to the diagnostic
outputs (all the front-ends I have at hand either do something similar
On Fri, Jun 10, 2016 at 11:16:03AM -0500, Bill Schmidt wrote:
> Verified on powerpc64le-unknown-linux-gnu with an updated binutils, and on
> powerpc64-unknown-linux-gnu with an out-of-date binutils. Is this ok for
> trunk?
Okay. "powerpc_p9vector_ok" is a confusing name, but it seems to be
Uros Bizjak writes:
> testsuite/ChangeLog:
>
> 2016-06-12 Uros Bizjak
>
> PR target/71241
> * testsuite/gcc.dg/torture/float128-nan.c: New test.
>
> Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
The test FAILs on 64-bit
ENOPATCH ;-)
(I highly recommend https://gcc.gnu.org/wiki/CompileFarm )
--
Marc Glisse
On Wed, Jun 08, 2016 at 06:43:23PM +0200, Bernd Schmidt wrote:
> On 06/08/2016 05:16 PM, Segher Boessenkool wrote:
> >There is no standard naming for this as far as I know. I'll gladly
> >use a better name anyone comes up with.
>
> Maybe just subpart?
How about "factor"?
Segher
This is an implementation of the Standard is_swappable traits according to
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2016/p0185r1.html
During that work it has been found that std::array's member swap's exception
specification for zero-size arrays was incorrectly depending on the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71435
Eric Botcazou changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71538
--- Comment #1 from sasho648 at gmail dot com ---
The exact command used to compile this code was "gcc -O3 test.c" (as test.c
containing the snippet above).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71538
Bug ID: 71538
Summary: Obvious optimization related to arrays aren't
performed.
Product: gcc
Version: 6.1.1
Status: UNCONFIRMED
Severity: normal
On 06/14/2016 09:15 AM, David Malcolm wrote:
There's a lot of repetition between find_closest_string and
find_closest_identifier, and the next patch adds more, so this
patch moves the logic into a new template class "best_match"
for locating the closest string from a sequence of candidates.
The
On 06/14/2016 09:15 AM, David Malcolm wrote:
The next patch in the kit reimplements find_closest_string and
find_closest_identifier, so it seems prudent to add some more
test coverage for these. This patch also adds some more test
coverage for levenshtein_distance itself.
Successfully
On 06/14/2016 09:15 AM, David Malcolm wrote:
There's a fair amount of repetition in the code to emit
fixits for misspelled identifiers, and I plan to add more
such fixits, so this patch moves it to a helper method.
Successfully bootstrapped in combination with the rest of
the kit on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70572
Paolo Carlini changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70572
--- Comment #5 from paolo at gcc dot gnu.org ---
Author: paolo
Date: Tue Jun 14 20:55:08 2016
New Revision: 237460
URL: https://gcc.gnu.org/viewcvs?rev=237460=gcc=rev
Log:
/cp
2016-06-14 Paolo Carlini
PR
On 06/14/2016 09:54 AM, Kyrill Tkachov wrote:
Hi all,
The noce_convert_multiple_sets transformation in ifcvt is supposed to
handle things like:
if (x > y)
{ i = a; j = b; }
transforming them into conditional moves.
However it currently is rather conservative in that it allows only
On 06/14/2016 12:09 PM, Ilya Verbin wrote:
On Fri, Apr 29, 2016 at 11:19:47 -0700, Mike Stump wrote:
On Apr 29, 2016, at 5:41 AM, Rainer Orth wrote:
diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
--- a/gcc/config/darwin.h
+++ b/gcc/config/darwin.h
@@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71509
--- Comment #2 from Segher Boessenkool ---
(In reply to Richard Biener from comment #1)
> It looks like we didn't adjust the bitfield read paths for the mem model
> because in practice it doesn't matter and it may generate larger/slower code
>
On 14/06/2016 13:22, Jonathan Wakely wrote:
On 13/06/16 21:49 +0200, François Dumont wrote:
Hi
I eventually would like to propose the attached patch.
In tr1 I made sure we use a special past-the-end iterator that
makes usage of lower_bound result without check safe.
I'm confused ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71537
Bug ID: 71537
Summary: GCC rejects consetxpr boolean conversions and
comparisons on the result of pointer arithmetic.
Product: gcc
Version: 7.0
Status: UNCONFIRMED
On Tue, Jun 14, 2016 at 03:53:59PM +0100, Jiong Wang wrote:
> "bl to pop" into "pop" which is "jump to return" into "return", so a better
> place to fix this issue is at try_optimize_cfg where we are doing these
> jump/return optimization already:
>
> /* Try to change a branch to a return to
As discussed in bug 71104, the C++ P0145 proposal specifies the
evaluation order of certain operations:
1. a.b
2. a->b
3. a->*b
4. a(b1, b2, b3)
5. b @= a
6. a[b]
7. a << b
8. a >> b
The second patch introduces a flag -fargs-in-order to control whether
these orders are enforced on calls.
Hi
Here is the patch to limit burden on compiler in finding out what
is the right method to call eventually when we already know it.
This patch doesn't show all indentation fixes I will also commit.
* include/bits/stl_deque.h
(std::deque<>::operator=): Call _M_assign_aux.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71528
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Tue Jun 14 19:55:08 2016
New Revision: 237458
URL: https://gcc.gnu.org/viewcvs?rev=237458=gcc=rev
Log:
PR c++/71528
* decl.c (duplicate_decls): For DECL_INITIALIZED_P
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70703
Bernhard Reutner-Fischer changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70703
Bernhard Reutner-Fischer changed:
What|Removed |Added
Last reconfirmed||2016-6-14
On Wed, Jun 8, 2016 at 4:21 AM, Paolo Carlini wrote:
> .. shall we fix this in gcc-6-branch too or not? It's just an ICE on invalid
> but we don't emit any diagnostic before the crash.
Sure, it should be safe enough.
Jason
On Tue, Jun 14, 2016 at 3:21 PM, Jakub Jelinek wrote:
> Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk (and
> after some time for 6.x)?
Yes.
Jason
OK.
Jason
Hi!
The following testcase is miscompiled, because during cp_finish_decl when
handling the initializer of the reference we clear TREE_READONLY, because
it needs to be initialized at runtime, but the (useless) later extern
decl has TREE_READONLY set and when we are merging the two decls, we set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71536
Bug ID: 71536
Summary: lto1 ICE: func-static constant in openmp offloaded
function
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71535
Bug ID: 71535
Summary: ICE in LTO1 with -fopenmp offloading
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: lto
Hello,
I'm changing e-mails.
I've just updated the gcc redirection address with the new value.
Mikael
Index: ChangeLog
===
--- ChangeLog (révision 237453)
+++ ChangeLog (révision 237454)
@@ -1,3 +1,7 @@
+2016-06-14 Mikael
On 03/05/16 11:56, Andrew Burgess wrote:
* Claudiu Zissulescu [2016-05-02 09:02:16
+]:
Please also consider to address also the following warnings introduced:
mainline/gcc/gcc/config/arc/arc.md:888: warning: source missing a mode?
On 02/05/16 14:50, Claudiu Zissulescu wrote:
This patch makes the pc-relative access to be more safe by using @pcl
syntax. This new syntax generates a pc-relative relocation which will
be handled by assembler.
OK to apply?
OK.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51242
Tom Honermann changed:
What|Removed |Added
CC||tom at honermann dot net
--- Comment
On Fri, Apr 29, 2016 at 11:19:47 -0700, Mike Stump wrote:
> On Apr 29, 2016, at 5:41 AM, Rainer Orth
> wrote:
> > diff --git a/gcc/config/darwin.h b/gcc/config/darwin.h
> > --- a/gcc/config/darwin.h
> > +++ b/gcc/config/darwin.h
> > @@ -179,6 +179,7 @@ extern
HI,
On 14/06/2016 15:06, Jason Merrill wrote:
On 06/11/2016 12:06 PM, Paolo Carlini wrote:
The remaining issue to be discussed is what to do about that old bug,
c++/27952, a crash in decay_conversion during error recovery, when vtt
is found null. I propose to simply check for it in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71534
Bug ID: 71534
Summary: Initializing a static constexpr data member of a base
class by using a static constexpr data member of a
derived class should be an error
Product:
"%Lf\n", d);
}
--
gcc version: gcc (GCC) 7.0.0 20160614 (experimental)
This patch by Chris Manghane implements the escape analysis flood
phase, in which the compiler propagates escape information across
assignments and function calls. Escape analysis is still not turned
on. Bootstrapped and ran Go testsuite on x86_64-pc-linux-gnu.
Committed to mainline.
Ian
Index:
Here is an untested patch for that. Except that the middle-end considers
conversions between BOOLEAN_TYPE and single bit unsigned type as useless,
so in theory this can't work well, and in practice only if we are lucky
enough (plus it generates terrible code right now), so we'd probably need
to
On Mon, May 2, 2016 at 9:24 AM, Jakub Jelinek wrote:
> On Fri, Apr 01, 2016 at 08:29:17PM +0200, Uros Bizjak wrote:
>> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for stage1
>> > (while the previous patch looks simple enough that I'd like to see it in
>> > 6.x,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71532
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71532
Bug ID: 71532
Summary: [7 Regression] FAIL: gfortran.dg/select_char_1.f90
-O2 execution test
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71531
H.J. Lu changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
On Thu, May 26, 2016 at 4:02 AM, Alan Modra wrote:
> This fixes lack of bb_loop_depth info in some of the early parts of
> ira, which has been the case for quite some time. All active branches
> return 0 from bb_loop_depth() in update_equiv_regs, but whether that
> actually
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71531
Bug ID: 71531
Summary: [7 Regression] FAIL: gfortran.dg/select_char_1.f90
-O2 execution test
Product: gcc
Version: 7.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71435
--- Comment #7 from Eric Botcazou ---
> Maybe we need an arg for that function to say whether to look at individual
> insn chains?
That, or just fiddle with the existing one, its only purpose in the function is
to guard the problematic global
2016-06-14 Uros Bizjak
* config/i386/i386.md (signbittf2): Emit sse_movmskps for TARGET_SSE.
Bootstrapped and regression tested on x86_64-linux-gnu {,-m32}.
Committed to mainline SVN.
Uros.
diff --git a/gcc/config/i386/i386.md b/gcc/config/i386/i386.md
index
On 14/06/16 10:32, Florian Weimer wrote:
A long time ago, GCC decided that warn_unused_result warnings should *not* be
silenced by casting to void, as in:
(void) write (STDOUT_FILENO, message, strlen (message));
Apparently, programmers have figured out to use this idiom as a replacement:
On 06/14/16 03:28, Christophe Lyon wrote:
On 13 June 2016 at 21:06, Evandro Menezes wrote:
On 06/13/16 05:15, James Greenhalgh wrote:
Thanks for your patience on this patch series.
Just checked the series in.
If I'm not mistaken, it looks like you forgot to update
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71104
Jason Merrill changed:
What|Removed |Added
CC||jason at gcc dot gnu.org
--- Comment
On Fri, Jun 10, 2016 at 11:31:33 +0200, Jakub Jelinek wrote:
> On Fri, Jun 10, 2016 at 09:39:02AM +0200, Thomas Schwinge wrote:
> > But I'm actually confused as to seeing libgomp.so in that list -- given
> > the conflict of which compiler installations' libgomp.so "wins", I wonder
> > how it can
Hi all,
The noce_convert_multiple_sets transformation in ifcvt is supposed to handle
things like:
if (x > y)
{ i = a; j = b; }
transforming them into conditional moves.
However it currently is rather conservative in that it allows only simple
reg-to-reg moves.
In the testcase in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71435
--- Comment #6 from Bernd Schmidt ---
Not calling finish_spills however could miss cases where pseudos got spilled by
update_eliminables_and_spill->spill_hard_reg.
Maybe we need an arg for that function to say whether to look at individual
insn
Hi Richard,
As nobody else has replied, let me take a stab at this one.
> On Jun 10, 2016, at 2:06 AM, Richard Biener wrote:
>
> On Thu, 9 Jun 2016, Michael Meissner wrote:
>
>> I'm including the global reviewers on the list. I just want to be sure that
>> there is no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71435
--- Comment #5 from Eric Botcazou ---
I think that calling finish_spills before select_reload_regs is incorrect:
static void
select_reload_regs (void)
{
struct insn_chain *chain;
/* Try to satisfy the needs for each insn. */
for (chain
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71516
Jakub Jelinek changed:
What|Removed |Added
Summary|[5/6/7 Regression] ICE on |[5 Regression] ICE on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68657
Jakub Jelinek changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71405
Jakub Jelinek changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
On Wed, Jun 08, 2016 at 03:57:42PM +0100, Bin Cheng wrote:
> > From: James Greenhalgh
> > Sent: 31 May 2016 16:24
> > To: Bin Cheng
> > Cc: gcc-patches@gcc.gnu.org; nd
> > Subject: Re: [PATCH AArch64]Support missing vcond pattern by adding/using
> > vec_cmp/vcond_mask
On 11/05/16 12:52, Jiong Wang wrote:
On 09/05/16 16:08, Segher Boessenkool wrote:
Hi Christophe,
On Mon, May 09, 2016 at 03:54:26PM +0200, Christophe Lyon wrote:
After this patch, I've noticed that
gcc.target/arm/pr43920-2.c
now fails at:
/* { dg-final { scan-assembler-times "pop" 2 } } */
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71494
Jakub Jelinek changed:
What|Removed |Added
Summary|[4.9/5/6/7 Regression] |[4.9/5 Regression] label as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68657
--- Comment #13 from Jakub Jelinek ---
Author: jakub
Date: Tue Jun 14 14:44:28 2016
New Revision: 237448
URL: https://gcc.gnu.org/viewcvs?rev=237448=gcc=rev
Log:
Backported from mainline
2016-06-10 Jakub Jelinek
There's a lot of repetition between find_closest_string and
find_closest_identifier, and the next patch adds more, so this
patch moves the logic into a new template class "best_match"
for locating the closest string from a sequence of candidates.
The patch also introduces a pair of early-reject
This patch introduces a new lookup_name_fuzzy function to the
C frontend and uses it to provides suggestions for various error
messages that may be due to misspellings, and also for the
warnings in implicit_decl_warning.
This latter part may be controversial. So far, we've only provided
spelling
There's a fair amount of repetition in the code to emit
fixits for misspelled identifiers, and I plan to add more
such fixits, so this patch moves it to a helper method.
Successfully bootstrapped in combination with the rest of
the kit on x86_64-pc-linux-gnu
Successful -fself-test of stage1 on
The next patch in the kit reimplements find_closest_string and
find_closest_identifier, so it seems prudent to add some more
test coverage for these. This patch also adds some more test
coverage for levenshtein_distance itself.
Successfully bootstrapped in combination with the rest of
the kit on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71516
--- Comment #5 from Jakub Jelinek ---
Author: jakub
Date: Tue Jun 14 14:47:17 2016
New Revision: 237450
URL: https://gcc.gnu.org/viewcvs?rev=237450=gcc=rev
Log:
PR c++/71516
* decl.c (complete_vars): Handle gracefully type ==
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71530
ktkachov at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Hi!
I've backported following patches to 6.x branch and committed
after bootstrapping/regtesting them on x86_64-linux and i686-linux.
Jakub
2016-06-14 Jakub Jelinek
Backported from mainline
2016-06-04 Jakub Jelinek
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71494
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Tue Jun 14 14:45:23 2016
New Revision: 237449
URL: https://gcc.gnu.org/viewcvs?rev=237449=gcc=rev
Log:
Backported from mainline
2016-06-10 Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71448
--- Comment #9 from Jakub Jelinek ---
Author: jakub
Date: Tue Jun 14 14:43:42 2016
New Revision: 237447
URL: https://gcc.gnu.org/viewcvs?rev=237447=gcc=rev
Log:
Backported from mainline
2016-06-08 Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71405
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Tue Jun 14 14:42:46 2016
New Revision: 237446
URL: https://gcc.gnu.org/viewcvs?rev=237446=gcc=rev
Log:
Backported from mainline
2016-06-04 Jakub Jelinek
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71530
Bug ID: 71530
Summary: the caching does not work
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: debug
David Malcolm wrote:
> On Mon, 2016-06-13 at 13:36 +0200, Ulrich Weigand wrote:
> > Gerald Pfeifer wrote:
> >
> > > The source code of need_finalization_p in ggc.h reads
> > >
> > >template
> > >static inline bool
> > >need_finalization_p ()
> > >{
> > >#if GCC_VERSION >=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71516
--- Comment #4 from Jakub Jelinek ---
Author: jakub
Date: Tue Jun 14 14:33:11 2016
New Revision: 237445
URL: https://gcc.gnu.org/viewcvs?rev=237445=gcc=rev
Log:
PR c++/71516
* decl.c (complete_vars): Handle gracefully type ==
In the given testcase, g++ splits a live operation into two scalar
statements
and four vector statements.
_5 = _4 >> 2;
_7 = (short int) _5;
Is turned into:
vect__5.32_80 = vect__4.31_76 >> 2;
vect__5.32_81 = vect__4.31_77 >> 2;
vect__5.32_82 = vect__4.31_78 >> 2;
vect__5.32_83 =
Hi James,
On 13/06/16 17:31, James Greenhalgh wrote:
Hi,
Inspired by Jiong's recent work, here are some more missing intrinsics,
and a smoke test for each of them.
This patch covers:
vcvt_n_f64_s64
vcvt_n_f64_u64
vcvt_n_s64_f64
vcvt_n_u64_f64
vcvt_f64_s64
vrecpe_f64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71488
--- Comment #6 from Ilya Enkovich ---
I think we should disable vectorization of boolean comparison (except '==' and
'!=') and handle them applying patterns. E.g. a > b ==> a & !b, a >= b ==> a |
!b etc. Bitwise operations are better because
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71528
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71488
--- Comment #5 from Ilya Enkovich ---
What seems suspicious to me is how we vectorize boolean comparison. Before
vectorization we have (_3, _5, _6 are bool):
_3 = var_9.0_2 == 0;
_6 = _3 > _5;
vectorized code:
mask__3.59_62 =
On Tue, Jun 14, 2016 at 02:05:12PM +, Joseph Myers wrote:
> On Tue, 14 Jun 2016, Jakub Jelinek wrote:
>
> > But, unlike normal signed or unsigned integral types or char, cast to
> > bool/_Bool is special, it is actually a comparison != 0.
> > So, I'd say if we want to support arith overflow
1 - 100 of 168 matches
Mail list logo