On Thu, Dec 19, 2019 at 11:25 PM Jeff Law wrote:
>
> On Fri, 2019-12-20 at 08:09 +0100, Richard Biener wrote:
> > On December 20, 2019 3:20:40 AM GMT+01:00, Jeff Law wrote:
> > > I need a sanity check here.
> > >
> > > Given this code:
> > >
> > > > typedef union { long double value; unsigned
On Fri, Dec 20, 2019 at 12:29 AM Jakub Jelinek wrote:
>
> Hi!
>
> The following patch optimizes
> decl %eax; cmpl $-1, %eax; jne .Lxx;
> into shorter and even possible to be fused:
> subl $1, %eax; jnc .Lxx;
>
> Bootstrapped/regtested on x86_64-linux and i686-linux, during which
> this peephole2
On Fri, Dec 20, 2019 at 12:26 AM Jakub Jelinek wrote:
>
> On Thu, Dec 19, 2019 at 06:23:59PM +0100, Jakub Jelinek wrote:
> > On Thu, Dec 19, 2019 at 04:50:40PM +0100, Jan Hubicka wrote:
> > > Outputting the move as RIP relative movq would work.
> > > LC12 is string "s" and has nothing to do with
On Fri, 2019-12-20 at 08:09 +0100, Richard Biener wrote:
> On December 20, 2019 3:20:40 AM GMT+01:00, Jeff Law wrote:
> > I need a sanity check here.
> >
> > Given this code:
> >
> > > typedef union { long double value; unsigned int word[4]; }
> > memory_long_double;
> > > static unsigned int
On December 20, 2019 2:13:47 AM GMT+01:00, "Bin.Cheng"
wrote:
>On Fri, Dec 13, 2019 at 11:26 AM bin.cheng
> wrote:
>>
>> Hi,
>>
>> As reported in PR92926, constant ctor is shared translation unit wide
>because of constexpr_call_table,
>> however, during gimplify, the shared ctor could be
On December 20, 2019 3:20:40 AM GMT+01:00, Jeff Law wrote:
>I need a sanity check here.
>
>Given this code:
>
>> typedef union { long double value; unsigned int word[4]; }
>memory_long_double;
>> static unsigned int ored_words[4];
>> static void add_to_ored_words (long double x)
>> {
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92996
Tobias Burnus changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment
Hi,
Previously, limited unrolling was enabled at O2 for powerpc in r278034. At that
time, -fweb and -frename-registers were not enabled together with -funroll-loops
even for -O3. After that, we notice there are some performance degradation on
SPEC2006fp which caused by without web and rnreg.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93022
Bug ID: 93022
Summary: [ARM, AArch32, NEON] Missing 'vld1_s16_x3' intrinsic
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
I need a sanity check here.
Given this code:
> typedef union { long double value; unsigned int word[4]; } memory_long_double;
> static unsigned int ored_words[4];
> static void add_to_ored_words (long double x)
> {
> memory_long_double m;
> size_t i;
> memset (, 0, sizeof (m));
> m.value
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92980
--- Comment #8 from Hongtao.liu ---
(In reply to Andrew Pinski from comment #4)
> But that is not true any more. So I think this optimization can be removed
> as it is too early. Just double check the above testcase and the C++
> testcase
Trying to plan memory consumption ahead-of-work contradicts with the nature
of the graph traversal. Estimation may work very well for something simple
like linear or log-linear behavior. But many compiler algorithms are known
to be polynomial or exponential (or even worse in case of bugs). So,
On Thu, Dec 19, 2019 at 7:41 PM Jeff Law wrote:
>
> On Thu, 2019-12-19 at 17:06 -0600, Qing Zhao wrote:
> > Hi, Dmitry,
> >
> > Thanks for the responds.
> >
> > Yes, routine size only cannot determine the complexity of the routine.
> > Different compiler analysis might have different formula
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58237
--- Comment #4 from David Malcolm ---
Patch committed to dmalcolm/analyzer branch:
https://gcc.gnu.org/ml/gcc-patches/2019-12/msg01425.html
Ought to be live on godbolt.org within the next 24 hours.
gcc/analyzer/ChangeLog:
* analyzer.opt (Wanalyzer-use-of-closed-file): New option.
* sm-file.cc (class use_of_closed_file): New file_diagnostic subclass.
(find_file_param): New function.
(fileptr_state_machine::on_stmt): Complain about operations on
closed
This patch adds a simple mechanism for tracking sets of functions
for which a particular property holds, as a pragmatic way to build
knowledge about important APIs into the analyzer without requiring
markup of the user's libc.
gcc/ChangeLog:
* Makefile.in (ANALYZER_OBJS): Add
The analyzer ought to report various file leaks for the reproducer in
PR analyzer/58237, such as:
void f1(const char *str)
{
FILE * fp = fopen(str, "r");
char buf[10];
while (fgets(buf, 10, fp) != NULL)
{
/* Do something with buf */
}
/* Missing call to fclose.
On Wed, 2019-12-11 at 14:48 -0500, David Malcolm wrote:
> On Sat, 2019-12-07 at 08:01 -0700, Jeff Law wrote:
> > On Fri, 2019-11-15 at 20:23 -0500, David Malcolm wrote:
> [...]
> > > diff --git a/gcc/analyzer/analyzer.cc b/gcc/analyzer/analyzer.cc
> > > new file mode 100644
> > > index
This patch uses the class function_set from the previous patch to
generalize the test for an fprintf inside a signal handler to
check for a set of known async-signal-unsafe functions.
gcc/analyzer/ChangeLog:
* analyzer-selftests.cc (selftest::run_analyzer_selftests): Call
On Wed, 18 Dec 2019 18:44:04 +0100
Thomas Schwinge wrote:
> Hi!
>
> On 2019-12-17T22:02:25-0800, Julian Brown
> wrote:
> > This patch series provides support for OpenACC 2.6's manual deep
> > copy (attach/detach) feature.
>
> Thanks.
>
>
> There is high pressure to get this functionality
On Fri, Dec 13, 2019 at 11:26 AM bin.cheng wrote:
>
> Hi,
>
> As reported in PR92926, constant ctor is shared translation unit wide because
> of constexpr_call_table,
> however, during gimplify, the shared ctor could be modified. This patch
> fixes the issue by unsharing
> it before
On Thu, 2019-12-19 at 17:06 -0600, Qing Zhao wrote:
> Hi, Dmitry,
>
> Thanks for the responds.
>
> Yes, routine size only cannot determine the complexity of the routine.
> Different compiler analysis might have different formula with multiple
> parameters to compute its complexity.
>
>
On Thu, Dec 19, 2019 at 04:08:39PM -0800, Ian Lance Taylor wrote:
> On Wed, Dec 18, 2019 at 7:58 AM Segher Boessenkool
> wrote:
> >
> > On Sun, Dec 15, 2019 at 09:43:20AM -0800, Ian Lance Taylor wrote:
> > > On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool
> > > wrote:
> > > >
> > > > On Sat,
On Thu, Dec 19, 2019 at 09:30:49PM +0100, Tobias Burnus wrote:
>
> The latter could be "solved" by using %C instead of %L after
> gfc_simplify_expr in gfc_match_stopcode.
> [The "ref" has its own address (e->ref->u.ar->where); hence,
> the a(1,1) error would be still fine.]
> (Though, this
On Wed, Dec 18, 2019 at 7:58 AM Segher Boessenkool
wrote:
>
> On Sun, Dec 15, 2019 at 09:43:20AM -0800, Ian Lance Taylor wrote:
> > On Sat, Dec 14, 2019 at 11:25 PM Segher Boessenkool
> > wrote:
> > >
> > > On Sat, Dec 14, 2019 at 10:51:50AM -0800, Ian Lance Taylor via gcc wrote:
> > > > I'm
Eric,
On Wed, 18 Dec 2019, Maciej W. Rozycki wrote:
> On Wed, 18 Dec 2019, Eric Botcazou wrote:
>
> > > gcc/ada/
> > > * gcc-interface/Makefile.in (ADA_RTL_DSO_DIR): New variable.
> > > (install-gnatlib): Use it in place of ADA_RTL_OBJ_DIR for shared
> > > library installation.
> > >
>
Hi!
The following patch optimizes
decl %eax; cmpl $-1, %eax; jne .Lxx;
into shorter and even possible to be fused:
subl $1, %eax; jnc .Lxx;
Bootstrapped/regtested on x86_64-linux and i686-linux, during which
this peephole2 triggered 7825 times, ok for trunk?
2019-12-19 Jakub Jelinek
On Thu, Dec 19, 2019 at 06:23:59PM +0100, Jakub Jelinek wrote:
> On Thu, Dec 19, 2019 at 04:50:40PM +0100, Jan Hubicka wrote:
> > Outputting the move as RIP relative movq would work.
> > LC12 is string "s" and has nothing to do with stack protecting.
>
> This should fix it by doing more carefully
Hi, Dmitry,
Thanks for the responds.
Yes, routine size only cannot determine the complexity of the routine.
Different compiler analysis might have different formula with multiple
parameters to compute its complexity.
However, the common issue is: when the complexity of a specific routine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92905
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
build_min_non_dep wasn't setting any location so when we were emitting the
warning in the following test while instantiating a template, it's location
was UNKNOWN_LOCATION. Rather than adding a location_t parameter, let's use
the location from the original expression.
Bootstrapped/regtested on
This issue is well-known in research/scientific software. The problem of
compiler hang or RAM overconsumption is actually not about the routine
size, but about too complicated control flow. When optimizing, the compiler
traverses the control flow graph, which may have the misfortune to explode
in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93013
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On 12/19/19 6:29 AM, Eric Botcazou wrote:
Simple LRA algorithms switch off hard register splitting, so there might
a slightly bigger chance for occurring "can find reload register" error
(e.g. when -O0 -fschedule-insns is used). But this error is still not
solved in general case and in my
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92974
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92990
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P5
On Thu, 2019-12-19 at 16:47 -0500, Erick Ochoa wrote:
> Hello,
>
> I am working on testing an optimization. I am starting to write
> tests in the GCC testing suite. However, I want to develop some
> fine grain testing for my own sake.
>
> This optimization I am working on, is a variant of struct
On 2019-12-19 5:01 p.m., Jozef Lawrynowicz wrote:
> On Thu, 19 Dec 2019 16:47:42 -0500
> Erick Ochoa wrote:
>
>> Hello,
>>
>> I am working on testing an optimization. I am starting to write
>> tests in the GCC testing suite. However, I want to develop some
>> fine grain testing for my own
The following patch fixes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92905
The patch was successfully bootstrapped on x86-64 and ppc64 and
benchmarked on SPEC2000 on x86-64.
Committed as r279596
Index: ChangeLog
===
---
On Thu, 19 Dec 2019 16:47:42 -0500
Erick Ochoa wrote:
> Hello,
>
> I am working on testing an optimization. I am starting to write
> tests in the GCC testing suite. However, I want to develop some
> fine grain testing for my own sake.
>
> This optimization I am working on, is a variant of
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92905
--- Comment #6 from Vladimir Makarov ---
Author: vmakarov
Date: Thu Dec 19 21:59:47 2019
New Revision: 279596
URL: https://gcc.gnu.org/viewcvs?rev=279596=gcc=rev
Log:
2019-12-19 Vladimir Makarov
PR target/92905
*
Hello,
I am working on testing an optimization. I am starting to write
tests in the GCC testing suite. However, I want to develop some
fine grain testing for my own sake.
This optimization I am working on, is a variant of struct reordering.
One way I would like to test my pass is for example,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92974
--- Comment #2 from Marek Polacek ---
We have a good location when processing the template:
(gdb) p loc
$4 = (const op_location_t &) @0x7fffc3d0: {m_operator_loc = 0,
m_combined_loc = 2147483648}
(gdb) p loc.m_combined_loc
$5 = 2147483648
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92974
Marek Polacek changed:
What|Removed |Added
Keywords||diagnostic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93021
--- Comment #4 from Andrew Pinski ---
>When a bootloader transfers control to an application, there is no context to
>be saved
Yes that is correct but the way it is currently implemented in Adafruit Metro
M4 Express is incorrect. It changes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93021
--- Comment #3 from Ron Sutton ---
When a bootloader transfers control to an application, there is no context to
be saved; a new context is being created and the old one discarded.
Incidentally, this bug also impacts compilation of Adafruit's
x-post from here: https://marc.info/?t=15767864485=1=2
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 6341216d1bc..e6d690b75c0 100644
--- a/gcc/config/mips/mips.c
diff --git a/gcc/config/mips/mips.c b/gcc/config/mips/mips.c
index 6341216d1bc..e6d690b75c0 100644
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89062
S. Davis Herring changed:
What|Removed |Added
CC||herring at lanl dot gov
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93021
--- Comment #2 from Andrew Pinski ---
I looked into uf2-samdx1 and when it sets the SP, it is really really bad idea
because it does not copy the current stack frames and would mess up GCC
knownledge of the current stack.
So YES the error is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58237
David Malcolm changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93021
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93009
--- Comment #3 from Jakub Jelinek ---
(In reply to Andrew Pinski from comment #2)
> It is called fma but it does not have to do the fused multiple add.
> For scalar types, you should use std::fma . BUT NOTE on targets where FMA
> does not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93021
Bug ID: 93021
Summary: SP Clobber change prevents compilation of some
bootloaders and operating systems
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
On 2019-12-19 3:50 p.m., Andrew Pinski wrote:
> On Thu, Dec 19, 2019 at 12:48 PM Erick Ochoa
> wrote:
>>
>> Hi,
>>
>> I'm looking to create new tests for an LTO pass that I'm working on.
>> So, I started by trying to run the tests under the folder:
>> $gcc/gcc/testsuite/gcc.dg/lto
>>
>>
On Thu, Dec 19, 2019 at 12:48 PM Erick Ochoa
wrote:
>
> Hi,
>
> I'm looking to create new tests for an LTO pass that I'm working on.
> So, I started by trying to run the tests under the folder:
> $gcc/gcc/testsuite/gcc.dg/lto
>
> Looking at the documentation available here:
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93009
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
Hi,
I'm looking to create new tests for an LTO pass that I'm working on.
So, I started by trying to run the tests under the folder:
$gcc/gcc/testsuite/gcc.dg/lto
Looking at the documentation available here:
https://gcc.gnu.org/install/test.html
It says the following
In order to run sets of
On Thu, Dec 19, 2019 at 03:24:19PM -0500, David Malcolm wrote:
> Currently -fdiagnostics-urls defaults to "auto" and this works
> (e.g. for recent gnome-terminal, and is gracefully discarded by
> konsole5), but there have been reports of incompatibilities of the
> feature with various other
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92392
Marek Polacek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
On Thu, Dec 19, 2019 at 12:40:12AM +0100, Jakub Jelinek wrote:
> Hi!
>
> While looking at PR92666, I've spotted a wrong-code issue where we ignore
> any side-effects on arguments passed to ellipsis if they have
> decltype(nullptr) type.
>
> Fixed thusly, bootstrapped/regtested on x86_64-linux
Hi all,
expressions initially have "expr->rank = 0" (cf. gfc_match_rvalue,
called by match_expr). This is later fixed during the resolution in
"expression_rank", which is called by (gfc_)resolve_ref, which in turn
is called by gfc_resolve_expr. Additionally, the resolve_array_ref
ensures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93013
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
On Mon, 2019-12-16 at 10:39 +0800, 王昊然 wrote:
> > Which revision of gcc is this?
> Using built-in specs.
> COLLECT_GCC=/opt/gcc-10.0-20191208/bin/gcc-10.0-20191208
> COLLECT_LTO_WRAPPER=/opt/gcc-10.0-20191208/bin/../lib/gcc/x86_64-pc-
> linux-gnu/10.0.0/lto-wrapper
> Target: x86_64-pc-linux-gnu
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91620
François Dumont changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91856
François Dumont changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93020
Bug ID: 93020
Summary: Final patches to build gcc-10 on GNU/Hurd
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: go
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93013
--- Comment #4 from Andrew Pinski ---
>For input x=-2^31 y=-1, the result is expected to be 0.
NO. The result is undefined as I mentioned in comment #2 and #3.
If you want it defined, then check y == -1 && y != 0 before doing the %
operations.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93015
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93013
Andrew Pinski changed:
What|Removed |Added
Status|NEW |UNCONFIRMED
Ever confirmed|1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93019
Bug ID: 93019
Summary: memory leak in gcc -O2 reported by Valgrind
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93013
Andrew Pinski changed:
What|Removed |Added
Component|target |tree-optimization
Target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93018
--- Comment #1 from John Drouhard ---
I forgot to mention that changing the optimization level to -O3 appears to
"fix" baz2, and it correctly zero-initializes the empty struct in the union.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92964
--- Comment #1 from John Drouhard ---
I opened a separate bug report for the second issue I discussed in this one.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93018
Bug ID: 93018
Summary: Zero initialization not occurring for empty struct in
member union when converting constructor is used with
-O2
Product: gcc
Version:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93013
Bill Schmidt changed:
What|Removed |Added
Target|powerpc-ibm-aix7.1.0.0 |powerpc-*-*-*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93013
--- Comment #2 from Andrew Pinski ---
I thought we declared INT_MIN /-1 as undefined and also INT_MIN % -1 undefined?
There is another PR about that. I think even a defect report against the C
standard too.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93013
Bill Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93017
Bug ID: 93017
Summary: FAIL: gcc.dg/graphite/interchange-1.c scan-tree-dump
graphite "tiled"
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Because of this change printers.py has to be updated too.
François
On 11/17/19 10:15 PM, François Dumont wrote:
H1 used to be a reference to the user Hash, now _Hashtable and
unordered types agree on the same Hash type which is more intuitive.
I also chose to not support anymore a stateful
After further work on pretty printers I prefer to stay closer to what is
done currently. It works better with another patch I'll submit one day.
The drawback is that I needed to consider versioned namespace in
template parameters passed to lookup_templ_spec.
François
On 12/9/19 10:15 PM,
On Thu, Dec 19, 2019 at 11:52 AM Richard Sandiford <
richard.sandif...@arm.com> wrote:
> Jason Merrill writes:
> > On 12/12/19 10:16 AM, Richard Sandiford wrote:
> >> As Jason pointed out in the review of the C++ gnu_vector_type_p patch:
> >>
> >>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92995
Jakub Jelinek changed:
What|Removed |Added
CC||dmalcolm at gcc dot gnu.org,
Why not just add "-D__LINE__=LinkerError_LineMacroUsed_DoNotDoThat()" to
CFLAGS?
Best Regards,
Dmitry Grinberg
On Mon, Dec 16, 2019 at 3:51 AM Eric Curtin wrote:
> I want to add a compiler warning, if it will get accepted. It's a
> -Wlines warning. My employer bans the __LINE__ macro as
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92993
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P4
Status|UNCONFIRMED
Eric Curtin writes:
> I want to add a compiler warning, if it will get accepted. It's a
> -Wlines warning. My employer bans the __LINE__ macro as well as the
> ones warned by the -Wdate-time warning, because there is a consensus
> that the addition of whitespace or comments should not yield
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93016
Marek Polacek changed:
What|Removed |Added
Keywords||wrong-code
Hi Srinath,
On 11/14/19 7:13 PM, Srinath Parvathaneni wrote:
Hello,
This patch supports following MVE ACLE intrinsics with binary operand.
vsubq_n_f16, vsubq_n_f32, vbrsrq_n_f16, vbrsrq_n_f32, vcvtq_n_f16_s16,
vcvtq_n_f32_s32, vcvtq_n_f16_u16, vcvtq_n_f32_u32, vcreateq_f16,
vcreateq_f32.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93012
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92635
Segher Boessenkool changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92656
--- Comment #2 from Segher Boessenkool ---
Trying 104 -> 105:
104: r125:SI=zero_extend(r101:SI#0)
REG_DEAD r101:SI
105: r127:SI={(r100:SI!=0)?r125:SI:r79:SI}
REG_DEAD r125:SI
REG_DEAD r100:SI
REG_DEAD r79:SI
Failed to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93016
Bug ID: 93016
Summary: erroneous new (nothrow_t) still throws an exception
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Hi Srinath,
On 11/14/19 7:13 PM, Srinath Parvathaneni wrote:
Hello,
This patch supports following MVE ACLE intrinsics with unary operand.
vctp16q, vctp32q, vctp64q, vctp8q, vpnot.
Please refer to M-profile Vector Extension (MVE) intrinsics [1] for
more details.
[1]
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93002
--- Comment #7 from getchar_gnu at hotmail dot com ---
Actually for `while (i--) sink=i;` with knowledge that `i!=0` it's valid to
compile as
.L11:
subl$1, %edi
movl%edi, sink(%rip)
jne .L11
ret
Hi Srinath,
On 11/14/19 7:13 PM, Srinath Parvathaneni wrote:
Hello,
This patch supports following MVE ACLE intrinsics with unary operand.
vmvnq_n_s16, vmvnq_n_s32, vrev64q_s8, vrev64q_s16, vrev64q_s32,
vcvtq_s16_f16, vcvtq_s32_f32,
vrev64q_u8, vrev64q_u16, vrev64q_u32, vmvnq_n_u16,
Hi Srinath,
On 11/14/19 7:12 PM, Srinath Parvathaneni wrote:
Hello,
This patch supports MVE ACLE intrinsics vcvtq_f16_s16, vcvtq_f32_s32,
vcvtq_f16_u16, vcvtq_f32_u32n
vrndxq_f16, vrndxq_f32, vrndq_f16, vrndq_f32, vrndpq_f16, vrndpq_f32,
vrndnq_f16, vrndnq_f32,
vrndmq_f16, vrndmq_f32,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93009
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
Hi Srinath,
On 11/14/19 7:12 PM, Srinath Parvathaneni wrote:
Hello,
This patch is part of MVE ACLE intrinsics framework.
The patch supports the use of emulation for the double-precision
arithmetic
operations for MVE. This changes are to support the MVE ACLE
intrinsics which
operates on
Andrew Stubbs writes:
> This patch changes the operand predicates such that vector constants are
> permitted during compilation. This prevents ICEs caused by the compiler
> trying to emit such instructions without checking.
That sounds like a target-independent bug though. Why didn't we
On 11/14/19 7:12 PM, Srinath Parvathaneni wrote:
Hello,
This patch supports MVE ACLE intrinsics vst4q_s8, vst4q_s16,
vst4q_s32, vst4q_u8,
vst4q_u16, vst4q_u32, vst4q_f16 and vst4q_f32.
In this patch arm_mve_builtins.def file is added to the source code in
which the
builtins for MVE ACLE
Hello,
The attached patch is a standalone part of a slightly more
general change last discussed here:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg02626.html
Which I re-tested successfully on aarch64-linux (bootstrap
and regression test with --enable-languages=all + local tests
with Ada
1 - 100 of 238 matches
Mail list logo
