On 06/05/2020 18:40, Richard Biener wrote:
On Wed, May 6, 2020 at 3:04 PM Erick Ochoa
wrote:
On 06/05/2020 14:25, Richard Biener wrote:
On Wed, May 6, 2020 at 12:26 PM Erick Ochoa
wrote:
Hi,
I am trying to find out how to use the alias and/or points-to analysis
in GCC. Ideally, I
Hello!
I wonder, if the build process really needs to build all multilibs in
stage-1 bootstrap build. IIRC, stage-1 uses system compiler to build
stage-1 gcc, so there is no need for multilibs, apart from library
that will be used by stage-1 gcc during compilation of stage-2
compiler.
Uros.
On 5/6/20 6:44 AM, Tetsuji Rai via Gcc wrote:
I wonder how Fedora project built its own kernel. I can't build custom
kernel with it.
What's wrong with 10.1-RC or how can I report my problem?
Hi.
Is it possible that you reached
https://lore.kernel.org/lkml/20200417190607.GY2424@tucnak/T/ ?
On 04/05/2020 20:28, H.J. Lu via Gcc wrote:
On Mon, May 4, 2020 at 12:24 PM Tobias Burnus wrote:
On 5/4/20 9:05 PM, Jakub Jelinek via Gcc wrote:
On Mon, May 04, 2020 at 08:56:16PM +0200, Martin Liška wrote:
What's missing right now is how will we declare a Backport format.
Can we just use
Hi,
I am trying to find out how to use the alias and/or points-to analysis
in GCC. Ideally, I would like to find a function that given an
allocation site, the return value is a set of pointers which may point
to memory allocated from that allocation site.
For example:
int
main(int argc,
Hi Martin,
Thank you for your reply!
Spot on!
It was my kernel config problem associated with stronger stack
protection of gcc-10, not a gcc problem. But I can't find this in
kernel.org bugzilla or bugzilla.redhat.com (searched with "gcc 10" and
"gcc-10".)
It happens not in qemu or any VM,
On 5/6/20 2:01 PM, Tetsuji Rai wrote:
Hi Martin,
Thank you for your reply!
Spot on!
It was my kernel config problem associated with stronger stack
protection of gcc-10, not a gcc problem. But I can't find this in
kernel.org bugzilla or bugzilla.redhat.com (searched with "gcc 10" and
On 30/04/2020 18:12, Jakub Jelinek wrote:
> On Thu, Apr 30, 2020 at 05:37:26PM -0300, Adhemerval Zanella via Gcc wrote:
>> Hi all, I would like to check if someone could help me figure out
>> an issue I am chasing on a libgomp patch intended to partially
>> address the issue described at
On Wed, May 6, 2020 at 12:26 PM Erick Ochoa
wrote:
>
> Hi,
>
> I am trying to find out how to use the alias and/or points-to analysis
> in GCC. Ideally, I would like to find a function that given an
> allocation site, the return value is a set of pointers which may point
> to memory allocated
Hi -
> https://gcc.gnu.org/pipermail/gcc/2020-February/232205.html
> Looking around, the last two months of gcc now have very small
> numbers, but e.g. on gcc-patches the mails have very high numbers like
> 545238.html. Can pipermail provide stable URLs at all? We really
> need those, we
On 06/05/2020 14:25, Richard Biener wrote:
On Wed, May 6, 2020 at 12:26 PM Erick Ochoa
wrote:
Hi,
I am trying to find out how to use the alias and/or points-to analysis
in GCC. Ideally, I would like to find a function that given an
allocation site, the return value is a set of pointers
Hi!
Last week after sending status report mails to gcc mailing list,
I've opened the web archive and copied the URLs of those status reports
https://gcc.gnu.org/pipermail/gcc/2020-April/232267.html
https://gcc.gnu.org/pipermail/gcc/2020-April/232268.html
and checked them into gcc-wwwdocs git
Hi,
>> https://gcc.gnu.org/pipermail/gcc/2020-February/232205.html
>> Looking around, the last two months of gcc now have very small
>> numbers, but e.g. on gcc-patches the mails have very high numbers like
>> 545238.html. Can pipermail provide stable URLs at all? We really
>> need those, we
Hi,
>> https://gcc.gnu.org/pipermail/gcc/2020-February/232205.html
>> Looking around, the last two months of gcc now have very small
>> numbers, but e.g. on gcc-patches the mails have very high numbers like
>> 545238.html. Can pipermail provide stable URLs at all? We really
>> need those, we
Hi!
On Thu, Apr 30, 2020 at 02:48:18PM +0200, FRÉDÉRIC RECOULES wrote:
> I am looking for some clarification about how are working the memory
> operands, especially when the constraint allows memory only (eg. "m").
> Please note that in a lesser extent, I know (by looking the gcc sources) how
On Wed, May 06, 2020 at 04:11:39PM +0200, Jakub Jelinek wrote:
>Hi!
>
>Last week after sending status report mails to gcc mailing list,
>I've opened the web archive and copied the URLs of those status reports
>https://gcc.gnu.org/pipermail/gcc/2020-April/232267.html
On Wed, May 6, 2020 at 3:04 PM Erick Ochoa
wrote:
>
>
>
> On 06/05/2020 14:25, Richard Biener wrote:
> > On Wed, May 6, 2020 at 12:26 PM Erick Ochoa
> > wrote:
> >>
> >> Hi,
> >>
> >> I am trying to find out how to use the alias and/or points-to analysis
> >> in GCC. Ideally, I would like to
On Wed, May 06, 2020 at 09:54:06PM +0700, Arseny Solokha wrote:
>may I also chime in with a related (to some extent), even though a separate
>issue? It seems URL rewriting rules designed to replace old-style
>
> https://gcc.gnu.org/ml//current
>
>URLs pointing to monthly digests to current ones
>
Hi,
Another minor cleanup.
This just strips out references to the draft standard numbered n4849.
The implementation is now intended to be applicable to the expected
final version.
tested on x86_64-darwin16,
applied to master as obvious
thanks
Iain
gcc/cp/ChangeLog:
2020-05-05 Iain Sandoe
On 06/05/20 20:46 +0200, François Dumont via Libstdc++ wrote:
Hi
I am not clear about current stage so I am proposing this trivial
patch to find out if we are back in stage 1.
The current status is always shown on the front page of gcc.gnu.org
(although currently the link to the GCC 11
setnbc[r] is like setbc[r], but it writes -1 instead of 1 to the GPR.
2020-05-06 Segher Boessenkool
* config/rs6000/rs6000.md (*setnbc_signed_): New
define_insn.
(*setnbcr_signed_): New define_insn.
(*neg_eq_): Avoid for TARGET_FUTURE; add missing && 1.
2020-05-06 Segher Boessenkool
* gcc.target/powerpc/setbc.h: New.
* gcc.target/powerpc/setbceq.c: New.
* gcc.target/powerpc/setbcge.c: New.
* gcc.target/powerpc/setbcgt.c: New.
* gcc.target/powerpc/setbcle.c: New.
* gcc.target/powerpc/setbclt.c:
Since r10-6527 fold_for_warn calls maybe_constant_value, which means it
can fold more than it previously could. In this testcase it means that
cp_build_binary_op/RSHIFT_EXPR set short_shift because now we were able
to fold op1 to an INTEGER_CST. But then when actually performing the
shortening
New instructions setbc and setbcr. setbc sets a GPR to 1 if some
condition register bit is set, and 0 otherwise; setbcr does it the
other way around.
2020-05-06 Segher Boessenkool
* config/rs6000/rs6000.md (setbc_signed_): New
define_insn.
(*setbcr_signed_): Likewise.
On 5/5/20 6:28 PM, Jakub Jelinek wrote:
Hi!
The following testcase gets a bogus warning during build_base_path,
when cp_build_indirect_ref* calls strict_aliasing_warning with a dependent
expression. IMHO calling get_alias_set etc. on dependent types feels wrong
to me, we should just defer the
On 5/5/20 5:35 PM, Marek Polacek wrote:
On Mon, May 04, 2020 at 09:18:57PM -0400, Jason Merrill wrote:
On 5/4/20 7:32 PM, Marek Polacek wrote:
Here we ICE with -std=c++98 since the newly added call to uses_template_parms
(r10-6357): we hit
26530 gcc_assert (cxx_dialect >= cxx11
On Wed, 6 May 2020, Andreas Tobler wrote:
> +#ifndef __FreeBSD__
>unsigned long hwcap = __getauxval (AT_HWCAP);
> +#else
> + unsigned long hwcap;
Would it make sense to change the logic to
#ifdef __FreeBSD__
..
#else
..
#endif
? I believe that makes it easier to potentially
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94950
--- Comment #6 from Jakub Jelinek ---
(In reply to Jim Wilson from comment #5)
> I tested it with an rv64gc-linux cross compiler. The patch fixes these
Thanks.
> I think it should be backported to the gcc-10 release branch.
Sure, but at this
Hi,
This patch removes all related helper functions around BIND_EXPR
generation in the D front-end, which were the cause of an ICE.
Both array concat and array new expressions wrapped any temporaries
created into a BIND_EXPR. This does not work if an expression used to
construct the result
Hi
I am not clear about current stage so I am proposing this trivial patch
to find out if we are back in stage 1.
This patch extend the overload so that it is used even when
_GLIBCXX_DEBUG mode is activated.
* include/bits/stl_algobase.h (struct _Bit_iterator): New
On Wed, May 06, 2020 at 09:54:47PM +0200, Andreas Tobler wrote:
> --- a/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
> +++ b/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
> @@ -1,5 +1,6 @@
> -#include
> -
> +#include
It needs to be:
> +#if __has_include()
+#include
> +#endif
__has_include
On 5/5/20 3:15 AM, Jakub Jelinek wrote:
Hi!
On the following testcase we ICE, because synthesize_method is called twice
on the same sfk_comparison method fndecl, the first time it works fine
because start_preparsed_function in that case sets both
current_function_decl and cfun, but second time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94950
--- Comment #5 from Jim Wilson ---
I tested it with an rv64gc-linux cross compiler. The patch fixes these
failures:
FAIL: gcc.dg/pr94780.c (internal compiler error)
FAIL: gcc.dg/pr94780.c (test for excess errors)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94970
--- Comment #5 from CVS Commits ---
The master branch has been updated by Iain Buclaw :
https://gcc.gnu.org/g:0af711e1914ab6d88538f1fcf0146757b5608b1d
commit r11-154-g0af711e1914ab6d88538f1fcf0146757b5608b1d
Author: Iain Buclaw
Date: Wed
For all of these, I forgot to mention that they have been bootstrapped
and tested on powerpc64le-unknown-linux-gnu with no regressions. Are
these okay for trunk, after GCC 10 is fully released?
Thanks,
Bill
On 5/6/20 3:31 PM, Bill Schmidt via Gcc-patches wrote:
*** BLURB HERE ***
Bill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94907
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:25ee2155ead87a5ea1c152a29341ee1e3275d706
commit r11-152-g25ee2155ead87a5ea1c152a29341ee1e3275d706
Author: Jakub Jelinek
Date:
Here we're failing to do SFINAE in build_op_call when looking up the
class's operator() via lookup_fnfields, which calls lookup_member always
with complain=tf_warning_or_error. And from there we complain about an
ambiguous lookup for operator().
This patch fixes this by adding a tsubst_flags_t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94230
qinzhao at gcc dot gnu.org changed:
What|Removed |Added
Version|10.0|11.0
Resolution|---
FYI.
> On Apr 23, 2020, at 5:13 PM, David Malcolm wrote:
>
> May need updating to match the hint message.
>
> [...]
>
> This is OK for stage 1 with those nits fixed.
I committed the updated patch with all the suggestions today to gcc11 stage1 as:
On 06/05/20 20:33 +0200, Rainer Orth wrote:
Hi Jonathan,
On 06/05/20 14:12 +0200, Rainer Orth wrote:
Hi Jonathan,
On 06/05/20 10:49 +0200, Rainer Orth wrote:
I just remembered that the libstdc++ ABI baselines haven't been updated
for the GCC 10 release yet. This patch corrects this for
On Wed, May 06, 2020 at 09:36:55AM +0200, Jakub Jelinek wrote:
> There were some discussions about whether REG_EQUAL notes are valid on insns
> with a single
> set which contains auto-inc-dec side-effects in the SET_SRC and the majority
> thinks that
> it should be valid. So, this patch fixes
On 06.05.20 22:27, Kamil Rytarowski wrote:
On 06.05.2020 22:25, Andreas Tobler wrote:
On 06.05.20 22:12, Jakub Jelinek wrote:
On Wed, May 06, 2020 at 09:54:47PM +0200, Andreas Tobler wrote:
--- a/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
+++ b/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
@@
*** BLURB HERE ***
Bill Schmidt (4):
Add insns for setbc and setbcr
Add tests for setbc and setbcr
Add insns for setnbc and setnbcr
Add tests for setnbc and setnbcr
gcc/config/rs6000/rs6000.md | 100 +---
gcc/testsuite/gcc.target/powerpc/setbc.h| 27
2020-05-06 Segher Boessenkool
* gcc.target/powerpc/setnbc.h: New.
* gcc.target/powerpc/setnbceq.c: New.
* gcc.target/powerpc/setnbcge.c: New.
* gcc.target/powerpc/setnbcgt.c: New.
* gcc.target/powerpc/setnbcle.c: New.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94946
Nathan Sidwell changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
On 06.05.2020 22:25, Andreas Tobler wrote:
> On 06.05.20 22:12, Jakub Jelinek wrote:
>> On Wed, May 06, 2020 at 09:54:47PM +0200, Andreas Tobler wrote:
>>> --- a/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
>>> +++ b/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
>>> @@ -1,5 +1,6 @@
>>> -#include
>>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94630
--- Comment #8 from Paul E. Murphy ---
The new libm/libc ABI for ieee128 long double on ppc64le is now committed to
glibc which will be available for the 2.32 release (commit
051be01f6b41a1466b07ae4bd7f5894a8ec5fe67).
TS-18661 does not specify
On 5/5/20 6:17 PM, Marek Polacek wrote:
An ICE arises here because we call cp_get_callee_fndecl_nofold in a
template, and we've got a CALL_EXPR whose CALL_EXPR_FN is a BASELINK.
This tickles the INDIRECT_TYPE_P assert in cp_get_fndecl_from_callee.
Jakub said in the PR that he'd hit a similar
Hi Jonathan,
> On 06/05/20 14:12 +0200, Rainer Orth wrote:
>>Hi Jonathan,
>>
>>> On 06/05/20 10:49 +0200, Rainer Orth wrote:
I just remembered that the libstdc++ ABI baselines haven't been updated
for the GCC 10 release yet. This patch corrects this for Solaris/SPARC
and x86.
>>>
>>>
On 04.05.20 12:10, Kamil Rytarowski wrote:
On 04.05.2020 12:04, Jakub Jelinek wrote:
On Mon, May 04, 2020 at 11:49:27AM +0200, Kamil Rytarowski wrote:
Please include in your patch "|| defined(__NetBSD__)".
is this ok for you?
This is one reason why I'd prefer #define alloca __builtin_alloca
Hi all,
Since FreeBSD 12, FreeBSD has a sys/auxv.h header too but it doesn't
provide the getauxval function. Instead it offers the elf_aux_info
function which provides a similar functionality.
This patch gets the hwcap for FreeBSD.
Is this ok for trunk?
TIA,
Andreas
+2020-05-05 Andreas
On 06.05.20 22:12, Jakub Jelinek wrote:
On Wed, May 06, 2020 at 09:54:47PM +0200, Andreas Tobler wrote:
--- a/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
+++ b/gcc/testsuite/gcc.dg/analyzer/alloca-leak.c
@@ -1,5 +1,6 @@
-#include
-
+#include
It needs to be:
+#if __has_include()
+#include
Introduce math_force_eval_div to use generic division to generate
INEXACT as well as INVALID and DIVZERO exceptions.
libgcc/ChangeLog:
2020-05-06 Uroš Bizjak
* config/i386/sfp-exceptions.c (__math_force_eval): Remove.
(__math_force_eval_div): New define.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=4210
--- Comment #41 from Niels Möller ---
(In reply to Manuel López-Ibáñez from comment #39)
> You can easily find which pass does something by dumping (-ftree-dump-*)
> all of them and comparing them.
It's -ftree-dump-all, and also -fdump-passes
Hi, Kees,
> On May 4, 2020, at 1:21 PM, Kees Cook wrote:
>
> On Mon, May 04, 2020 at 11:51:49AM -0500, Qing Zhao wrote:
>> Hi,
>>
>> This is a PING for this patch for gcc11 stage 1.
>>
>> https://gcc.gnu.org/pipermail/gcc-patches/2020-April/544058.html
>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94955
Marek Polacek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
On 4/29/20 6:50 AM, Iain Sandoe wrote:
Hi,
When we have completely missing key information (e.g. the
coroutine_traits) or a partially transformed function body, we
need to try and balance returning useful information about
failures with the possibility that some part of the diagnostics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94977
Bug ID: 94977
Summary: Some X86 inline assembly modifiers are not documented
in the web documentation
Product: gcc
Version: unknown
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94951
--- Comment #6 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:46fcef99f49cc2d9f28d98f8ecdbf8263e9e0a87
commit r11-153-g46fcef99f49cc2d9f28d98f8ecdbf8263e9e0a87
Author: Jakub Jelinek
Date:
Hi all,
I think the assumption in builtin_memref::set_base_and_offset
(gimple-ssa-warn-restrict.c) is not correct. It seems multiple levels of
indirection may confuse gcc. When it loses the reference to the original
buffer (e.g.the buffer is allocated by one of the parent class but it's
used by a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94938
--- Comment #4 from CVS Commits ---
The master branch has been updated by Marek Polacek :
https://gcc.gnu.org/g:1e89178889741c9c4d6a61e5a01c40a8a182fa68
commit r11-155-g1e89178889741c9c4d6a61e5a01c40a8a182fa68
Author: Marek Polacek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978
Bug ID: 94978
Summary: [8/9/10/11 Regression] Bogus warning "Array reference
at (1) out of bounds in loop beginning at (2)"
Product: gcc
Version: 8.4.1
Status:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978
--- Comment #1 from Fritz Reese ---
The regression is caused by r253156, which introduces the warning in the first
place. The relevant code is in frontend-passes.c (do_subscript). Apparently,
the FE is aware that when there is a conditional it
> Oops, here are the updates from Fedora packages built during the weekend.
The SPARC64/Linux bits are attached. OK for trunk and gcc-10?
2020-05-06 Eric Botcazou
* config/abi/post/sparc64-linux-gnu/baseline_symbols.txt: Update.
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94979
Bug ID: 94979
Summary: gcc-9 generates incorrect code causing segfault
Product: gcc
Version: 9.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94979
Andrew Pinski changed:
What|Removed |Added
Resolution|--- |DUPLICATE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91031
Andrew Pinski changed:
What|Removed |Added
CC||makhaloff at gmail dot com
--- Comment
On 5/6/20 6:48 PM, Segher Boessenkool wrote:
On Wed, May 06, 2020 at 03:41:35PM -0500, Bill Schmidt wrote:
For all of these, I forgot to mention that they have been bootstrapped
and tested on powerpc64le-unknown-linux-gnu with no regressions. Are
these okay for trunk, after GCC 10 is fully
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94938
Marek Polacek changed:
What|Removed |Added
Summary|[10/11 Regression] internal |[10 Regression] internal
On 5/6/20 4:35 PM, Joey Liu via Gcc-patches wrote:
Hi all,
I think the assumption in builtin_memref::set_base_and_offset
(gimple-ssa-warn-restrict.c) is not correct. It seems multiple levels of
indirection may confuse gcc. When it loses the reference to the original
buffer (e.g.the buffer is
On Wed, May 06, 2020 at 03:41:35PM -0500, Bill Schmidt wrote:
> For all of these, I forgot to mention that they have been bootstrapped
> and tested on powerpc64le-unknown-linux-gnu with no regressions. Are
> these okay for trunk, after GCC 10 is fully released?
These all look fine to me. But
Hi!
On Wed, May 06, 2020 at 03:31:08PM -0500, Bill Schmidt wrote:
> (ne3): Replace :P with :GPR; use setbc for TARGET_FUTURE;
> else for non-Pmode, use gen_eq and gen_xor.
Before this patch, there was only ne:P, which results in the same thing
(done by generic code). I should have
On Wed, May 6, 2020 at 5:11 AM Hongtao Liu wrote:
>
> On Mon, May 4, 2020 at 1:17 AM Uros Bizjak wrote:
> >
> > On Wed, Apr 1, 2020 at 9:23 AM Hongtao Liu wrote:
> > >
> > > Hi:
> > > This patch is about to enable GCC support for SERIALIZE which would
> > > be in GLC. There's only 1
On Tue, 5 May 2020, Jeff Law wrote:
> On Mon, 2020-05-04 at 14:11 +0200, Richard Biener wrote:
> > This patch sits in my trees for quite some years and I always forget
> > to push it - it usually gets triggered by weird targets (PSImode
> > pointers/sizetype) which run into GIMPLE IL checking
On Wed, May 6, 2020 at 4:48 AM Hongtao Liu wrote:
>
> On Mon, May 4, 2020 at 12:58 AM Uros Bizjak wrote:
> >
> > The part above is OK, but you are missing support for
> > __attribute__((__target__("..."))). Please see how for example -msgx
> > is handled in isa2_opts in i386-options.c and in
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94781
--- Comment #7 from ishikawa,chiaki ---
(In reply to Martin Liška from comment #6)
> (In reply to ishikawa,chiaki from comment #3)
> > https://send.firefox.com/download/bdf77223953903fa/#WMrJbMYdsL7AXf2vXYm82g
> >
> > I uploaded the file,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94963
Richard Biener changed:
What|Removed |Added
Last reconfirmed||2020-05-06
Hi!
According to my verification proglet, this transformation for signed types
with undefined overflow doesn't introduce nor remove any UB cases, so should
be valid even for signed integral types.
Not using a for because of the :c on plus which can't be there on minus.
Bootstrapped/regtested on
Thank you!
On Wed, May 6, 2020 at 12:43 AM Jakub Jelinek wrote:
>
> Hi!
>
> Similarly to the fixes on many other targets, riscv needs to use TARGET_EXPR
> to avoid having the create_tmp_var_raw temporaries without proper DECL_CONTEXT
> and not mentioned in local decls.
>
> Committed as obvious
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94965
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94965
--- Comment #2 from Richard Biener ---
@@ -9319,7 +9364,8 @@ vectorizable_load (stmt_vec_info stmt_info,
gimple_stmt_it
erator *gsi,
initialized yet, use first_stmt_info_for_drptr DR by bumping the
distance from first_stmt_info
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94960
Richard Biener changed:
What|Removed |Added
CC||hubicka at gcc dot gnu.org,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94961
Richard Biener changed:
What|Removed |Added
Target||x86_64-*-*
Target Milestone|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94957
--- Comment #3 from Jakub Jelinek ---
Some of it changed recently, e.g. when the FEs use ARRAY_RANGE_REFs in the
initializer the gimplifier's gimplify_init_ctor_eval emits a loop.
But in this case I think we need the FE to emit the loop itself.
Hi!
There were some discussions about whether REG_EQUAL notes are valid on insns
with a single
set which contains auto-inc-dec side-effects in the SET_SRC and the majority
thinks that
it should be valid. So, this patch fixes the combiner to punt in that case,
because otherwise
the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94963
--- Comment #2 from Richard Biener ---
Created attachment 48459
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48459=edit
patch in testing
Testing the attached.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89394
Trupti Pardeshi changed:
What|Removed |Added
CC||trupti_pardeshi@persistent.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94966
Bug ID: 94966
Summary: [10 regression] internal compiler error: tree check:
expected function_type or method_type, have
integer_type in gimplify_call_expr, at gimplify.c:3433
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94953
Richard Biener changed:
What|Removed |Added
Blocks||24639
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94957
--- Comment #2 from Richard Biener ---
Plenty of dups for this in bugzilla - but FE folks never get that idea of using
a loop ...
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94956
Richard Biener changed:
What|Removed |Added
Ever confirmed|0 |1
Keywords|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94781
--- Comment #8 from ishikawa,chiaki ---
(In reply to ishikawa,chiaki from comment #7)
> (In reply to Martin Liška from comment #6)
> > (In reply to ishikawa,chiaki from comment #3)
> > >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94873
--- Comment #20 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:f14848aea70066777faf201c0b6eb3c5520bfab9
commit r11-127-gf14848aea70066777faf201c0b6eb3c5520bfab9
Author: Jakub Jelinek
Date:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94950
--- Comment #3 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:b4ace720e004f736f1ee46b374c12f9826aad630
commit r11-128-gb4ace720e004f736f1ee46b374c12f9826aad630
Author: Jakub Jelinek
Date:
Hi!
Similarly to the fixes on many other targets, riscv needs to use TARGET_EXPR
to avoid having the create_tmp_var_raw temporaries without proper DECL_CONTEXT
and not mentioned in local decls.
Committed as obvious to trunk.
2020-05-06 Jakub Jelinek
PR target/94950
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94964
Bug ID: 94964
Summary: [8/9/10/11 Regression] ICE in add_phi_arg, at
tree-phinodes.c:359 since r8-2993-ga7976089dba5e227
Product: gcc
Version: 10.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94964
Martin Liška changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Known to work|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94961
Martin Liška changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94442
--- Comment #4 from xiezhiheng at huawei dot com ---
(In reply to Richard Biener from comment #3)
> So I wonder why
>
> a$vect_s8$0_4 = MEM[(const struct __m256i &)output_5(D) + 32].vect_s8[0];
>
> necessarily emits two RTL insns. It's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94964
Richard Biener changed:
What|Removed |Added
Status|NEW |ASSIGNED
Target Milestone|---
1 - 100 of 268 matches
Mail list logo
