https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92646
--- Comment #5 from Andrew Pinski ---
Looks like multi-arch is not being auto-detected correctly.
Try adding --enable-multiarch .
We are pleased to announce the release of GNU Mes 0.21, representing
54 commits over 10 weeks.
Mes has now brought the Reduced Binary Seed bootstrap to Guix (bootstrap
a GNU/Linux system without binary GNU toolchain or equivalent). See
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264
Jakub Jelinek changed:
What|Removed |Added
Status|REOPENED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86172
Bug 86172 depends on bug 90264, which changed state.
Bug 90264 Summary: [9/10 Regression] -Wnull-dereference QoI issue
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90264
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
--- Comment #11 from David Brown ---
Reliance on -fcommon has not been correct or compatible with any C standard (I
don't think it was even right for K C). If the code is written correctly
(with at most one definition of all externally linked
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-10/msg01015.html
It feels to me like it's getting a little late for this but it
would still be helpful to get some feedback. Jeff, you were
very interested in this work when we discussed it offline. Do
you have any comments?
On 10/24/19 8:42 AM,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92533
--- Comment #4 from Tobias Burnus ---
Created attachment 47354
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47354=edit
Parsing-only patch – TODO: resolve PUBLIC/PRIVATE + handle example of comment 1
First patch. Need to resolve
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00812.html
On 11/18/19 11:23 AM, Martin Sebor wrote:
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00812.html
On 11/11/19 6:27 PM, Martin Sebor wrote:
The attached patch extends the strlen pass to detect out-of-bounds
accesses to
Ping: https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00652.html
This change is independent of either of the two patches below:
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00429.html
https://gcc.gnu.org/ml/gcc-patches/2019-11/msg00652.html
On 11/18/19 11:22 AM, Martin Sebor wrote:
Ping:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92651
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92586
epagone changed:
What|Removed |Added
Blocks||19276
--- Comment #3 from epagone ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92648
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
--- Comment #10 from David Binderman ---
(In reply to Jonathan Wakely from comment #9)
> C89 6.7p4 looks equivalent to C99 6.9p5, so I don't see why -std=c89 should
> imply -fcommon.
To reduce costs in upgrading to post-revision 278509
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
--- Comment #4 from joseph at codesourcery dot com ---
The design in the target-independent compiler is that the functions that
get called when processing builtins.def notice that the type involved is
error_mark_node (which in turn gets set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
--- Comment #9 from Jonathan Wakely ---
C89 6.7p4 looks equivalent to C99 6.9p5, so I don't see why -std=c89 should
imply -fcommon. It's just as bad in C89 as in later standards.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92641
--- Comment #3 from joseph at codesourcery dot com ---
The C front end explicitly tracks VLA size expressions in type names in
casts and ensures they are evaluated at an appropriate point using a
C_MAYBE_CONST_EXPR (which later turns into a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
--- Comment #8 from Wilco ---
(In reply to David Binderman from comment #7)
> (In reply to David Brown from comment #0)
> > Surely it is time to make "-fno-common" the default, at least when a modern
> > C standard is specified indicating that
> >
> > i wonder if gcc can auto-vectorize scalar sincos
> > calls, the vectorizer seems to want the calls to
> > have no side-effect, but attribute pure or const
> > is not appropriate for sincos (which has no return
> > value but takes writable pointer args)
>
> We have __builtin_cexpi for that
On Mon, Nov 25, 2019 at 03:34:25PM +0100, Tobias Burnus wrote:
>
> well, the question is what counts as regression. In any case, I have now
> committed that patch as r278689.
>
Regression is fairly easy to define. Standard conforming code
that compiled and executed correctly (for some
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85678
David Binderman changed:
What|Removed |Added
CC||dcb314 at hotmail dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92664
Bug ID: 92664
Summary: Wrong .debug_line section information when compiling
stdin input with -g3
Product: gcc
Version: 7.2.1
Status: UNCONFIRMED
Severity:
Am 06.11.19 um 23:32 schrieb Jeff Law:
On 10/31/19 3:55 PM, Georg-Johann Lay wrote:
Hi, this adds the possibility to enable IEEE compatible double
and long double support in avr-gcc.
It supports 2 configure options
--with-double={32|64|32,64|64,32}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
--- Comment #3 from David Edelsohn ---
An alternate work-around is
Index: tree.c
===
--- tree.c (revision 278691)
+++ tree.c (working copy)
@@ -10334,7 +10334,7 @@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #22 from Iain Sandoe ---
(In reply to Jürgen Reuter from comment #21)
> (In reply to Iain Sandoe from comment #20)
> > As of XCode 11.3beta, the contained SDK works OK:
> >
> >
I'm looking at the sets of branches and tags resulting from a GCC
repository conversion with reposurgeon.
1. I see 227 branches (and one tag) with names like
cxx0x-concepts-branch-deleted-r131428-1 (this is out of 780 branches in
total in a conversion of GCC history as of a few days ago). Can
I'm testing a gcc-conversion patch to implement the branchpoint fixes I
identified for GCC branches where cvs2svn chose a bad parent for the
branch-creation commit.
With that patch, I see:
# /branches/gcc-3_4-rhl-branch
<80870>|<81014> reparent --use-order
reposurgeon: couldn't match a name at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
--- Comment #2 from David Edelsohn ---
A crude work-around to allow GCC to bootstrap and show the extent of the
problem, I need the following patches to comment out all decimal builtins.
Index: rs6000-call.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61414
Jakub Jelinek changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #21 from Jürgen Reuter ---
(In reply to Iain Sandoe from comment #20)
> As of XCode 11.3beta, the contained SDK works OK:
>
> https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01439.html
>
> We still have the underlying problems -
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92663
Bug ID: 92663
Summary: Add __gcc_has_bug or __gcc_bug_fixed
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
On Mon, Nov 25, 2019 at 03:58:44PM +0100, Jakub Jelinek wrote:
> On Mon, Nov 25, 2019 at 09:42:41AM -0500, Marek Polacek wrote:
> > On Mon, Nov 25, 2019 at 09:39:25AM -0500, Jason Merrill wrote:
> > > On Fri, Nov 22, 2019 at 4:51 PM Marek Polacek wrote:
> > >
> > > > Committed to git. Should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662
--- Comment #2 from Jonathan Wakely ---
I'm pretty sure GCC 9 is correct. It started to be rejected with r269602:
PR c++/86521 - wrong overload resolution with ref-qualifiers.
Here we were wrongly treating binding a const
On Mon, Nov 25, 2019 at 09:42:41AM -0500, Marek Polacek wrote:
> On Mon, Nov 25, 2019 at 09:39:25AM -0500, Jason Merrill wrote:
> > On Fri, Nov 22, 2019 at 4:51 PM Marek Polacek wrote:
> >
> > > Committed to git. Should s/http/https/ the wg21 links.
> > >
> > > Jason, do we support P1907R1?
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662
--- Comment #1 from Michael Matz ---
I _think_ a reduced program would be this:
-
template struct remove_ref { typedef _Tp type; };
template struct remove_ref<_Tp&> { typedef _Tp type; };
template struct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92662
Bug ID: 92662
Summary: change in gcc 8 vs 9: call of overloaded
‘basic_string()’ is
ambiguous
Product: gcc
Version: 9.2.1
Status: UNCONFIRMED
On 11/15/19 12:02 PM, Stam Markianos-Wright wrote:
> Hi all,
>
> This patch adds support for a new real_format for ARM Brain Floating
> Point numbers to the middle end. This is to be used exclusively in the
> ARM back-end.
>
> The encode_arm_bfloat_half and decode_arm_bfloat_half functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69089
Tom de Geus changed:
What|Removed |Added
CC||tom at geus dot me
--- Comment #7 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
David Edelsohn changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92661
Bug ID: 92661
Summary: [10 Regression] AIX bootstrap failure with
builtin-types.def change
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: blocker
On Mon, Nov 25, 2019 at 03:39:32PM +0100, Jakub Jelinek wrote:
> I guess the question is, shall we store the minimum precision needed
> somewhere by finish_enum_value_list (perhaps only bother if the precision
> of the underlying type is not the same) or compute it each time again
> (which would
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
--- Comment #9 from Richard Biener ---
Thanks a lot. So besides the following mismatch for SLP
_24 = MEM[base: src_22(D), index: ivtmp.20_267, offset: 0B];
_97 = (unsigned char) _24;
_98 = (short unsigned int) _97;
_99 = BIT_FIELD_REF
On 11/25/19 3:40 PM, Segher Boessenkool wrote:
> On Mon, Nov 25, 2019 at 01:38:53PM +0100, Tobias Burnus wrote:
>> Thanks for the m68k work! Can you also update
>> https://gcc.gnu.org/backends.html ?
>
>> PS: I wonder whether some other archs also should be updated on that web
>> page.
>
>
On Mon, Nov 25, 2019 at 09:39:25AM -0500, Jason Merrill wrote:
> On Fri, Nov 22, 2019 at 4:51 PM Marek Polacek wrote:
>
> > Committed to git. Should s/http/https/ the wg21 links.
> >
> > Jason, do we support P1907R1?
> >
>
> Pretty close, just need to add a bit more checking.
Thanks, won't
On Fri, Oct 20, 2017 at 11:59:39AM -0400, Jason Merrill wrote:
> > Still, warning when a bit-field can't hold all enumerators instead of
> > all values may be a good idea. I've looked into it, and it does require
> > recalculating the maximum and minimum enumerator value, since the bounds
> > of
On Fri, Nov 22, 2019 at 4:51 PM Marek Polacek wrote:
> Committed to git. Should s/http/https/ the wg21 links.
>
> Jason, do we support P1907R1?
>
Pretty close, just need to add a bit more checking.
> commit d59a823fb4ad2daa535d26f592274ec68b9cb4a1
> Author: Marek Polacek
> Date: Fri Nov
Hi!
On Mon, Nov 25, 2019 at 01:38:53PM +0100, Tobias Burnus wrote:
> Thanks for the m68k work! Can you also update
> https://gcc.gnu.org/backends.html ?
> PS: I wonder whether some other archs also should be updated on that web
> page.
Possibly. Probably?
But, do you have any particular
Hi Steve,
well, the question is what counts as regression. In any case, I have now
committed that patch as r278689.
Cheers,
Tobias
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92050
--- Comment #7 from Tobias Burnus ---
Author: burnus
Date: Mon Nov 25 14:33:32 2019
New Revision: 278689
URL: https://gcc.gnu.org/viewcvs?rev=278689=gcc=rev
Log:
Fortran] PR 92050 - fix ICE with -fcheck=all
Backport from mainline
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657
--- Comment #3 from Adhemerval Zanella
---
(In reply to Adhemerval Zanella from comment #2)
> (In reply to Andrew Pinski from comment #1)
> > Again, this is not due to tree-ch at all. This is due to the code motion
> > passes move invariant
On 25/11/2019 14:17, Tobias Burnus wrote:
The compiler warns that funcs_tail and vars_tails are unused – they,
funcs_ids/var_ids and struct id_map seem to be a copy-n-paste leftovers
from gcc/config/nvptx/mkoffload.c.
Additionally, COMMENT_PREFIX does not seem to be used anywhere. (In the
The compiler warns that funcs_tail and vars_tails are unused – they,
funcs_ids/var_ids and struct id_map seem to be a copy-n-paste leftovers
from gcc/config/nvptx/mkoffload.c.
Additionally, COMMENT_PREFIX does not seem to be used anywhere. (In the
whole of GCC, it appears twice – in this file
Martin,
Thanks for your review. I updated the patch with your comments.
Feng
---
2019-11-15 Feng Xue
PR ipa/92133
* doc/invoke.texi (ipa-cp-max-recursive-depth): Document new option.
(ipa-cp-min-recursive-probability): Likewise.
* params.opt
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657
--- Comment #2 from Adhemerval Zanella
---
(In reply to Andrew Pinski from comment #1)
> Again, this is not due to tree-ch at all. This is due to the code motion
> passes move invariant load/stores out of the loop. Tree-ch pass just allows
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657
--- Comment #1 from Andrew Pinski ---
Again, this is not due to tree-ch at all. This is due to the code motion
passes move invariant load/stores out of the loop. Tree-ch pass just allows
those passes to work.
All three (gcse, tree pre and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
--- Comment #1 from Richard Biener ---
It looks like there are already some avx512 patterns matching this but they
are not visible to the RTL expanders.
(define_insn "zero_extendv8qiv8hi2"
[(set (match_operand:V8HI 0 "register_operand"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92642
--- Comment #3 from Jonathan Wakely ---
No, not necessarily.
extern const int n; // defined in another file
auto i = 1 << n;
void f(const int n)
{
auto i = 1 << n;
}
Not all const variables are compile-time constants.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
Jonathan Wakely changed:
What|Removed |Added
Keywords||diagnostic
Severity|normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92660
Bug ID: 92660
Summary: overflow warning message enhancement
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Hi Thomas,
sorry for the belated reply.
Some comments – and a patch modifying two test cases (see below).
Regarding the patch: OK for the trunk?
On 11/11/19 10:39 AM, Thomas Schwinge wrote:
By the way, do you know what's the status is for Fortran common blocks in
OpenMP: supported vs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92659
Bug ID: 92659
Summary: Suggestions for bitshift
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee:
Hi.
The patch cleans up typos in a dump message in IPA ICF pass.
I'm going to install the patch.
Thanks,
Martin
gcc/ChangeLog:
2019-11-25 Martin Liska
* ipa-icf.c (sem_item_optimizer::dump_cong_classes): Clean
up used dump message.
---
gcc/ipa-icf.c | 3 +--
1 file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92653
--- Comment #1 from Martin Liška ---
Author: marxin
Date: Mon Nov 25 13:57:00 2019
New Revision: 278686
URL: https://gcc.gnu.org/viewcvs?rev=278686=gcc=rev
Log:
Comment too strict checking assert.
2019-11-25 Martin Liska
PR
Hi.
Based on the discussion with Honza, I'm going to install the following patch.
It comments out a checking assert that is too strict. Honza promised that he
will take a look later.
Martin
gcc/ChangeLog:
2019-11-25 Martin Liska
PR bootstrap/92653
* ipa-fnsummary.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92642
--- Comment #2 from Jonny Grant ---
(In reply to Jonathan Wakely from comment #1)
> (A) seems pointless in this case, it's right there in the caret diagnostic.
>
> The type size_t is irrelevant.
>
> IMO a better testcase would be:
>
> const
Hello.
I'm sending v2 of the patch set based on the discussion I had with Honza.
Changes from previous version:
- I changed type of edge count from uint32_t to uint64_t.
- The algorithm traverses recursively inline clones.
- TDF_DUMP_DETAILS is supported and provides more information.
- I added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92645
Alexander Monakov changed:
What|Removed |Added
CC||amonakov at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91985
Joseph S. Myers changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91985
--- Comment #2 from Joseph S. Myers ---
Author: jsm28
Date: Mon Nov 25 13:45:42 2019
New Revision: 278684
URL: https://gcc.gnu.org/viewcvs?rev=278684=gcc=rev
Log:
Prevent all uses of DFP when unsupported (PR c/91985).
Code that directly uses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92658
Bug ID: 92658
Summary: x86 lacks vector extend / truncate
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
--- Comment #5 from fiesh at zefix dot tv ---
Thank you for your offer. The original translation unit is a whopping 20MB and
took about 3 days to reduce ;-)
I changed the file and the interestingness test to make sure clang compiles it.
It's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
--- Comment #20 from Iain Sandoe ---
As of XCode 11.3beta, the contained SDK works OK:
https://gcc.gnu.org/ml/gcc-testresults/2019-11/msg01439.html
We still have the underlying problems - which need to be addressed (so please
don't close this
On Nov 25 2019, Bernd Schmidt wrote:
> On 11/25/19 12:26 PM, Andreas Schwab wrote:
>> On Nov 24 2019, Bernd Schmidt wrote:
>>
>>> Whew, I think I have it. One tst instruction eliminated when it
>>> shouldn't have been:
>>>
>>> move.w %a4,%d0
>>> - tst.b %d0
>>> - jeq .L352
The following tries to improve PR92645 in a minimal invasive way.
Currently as heuristic the BB vectorizer throws away vector stmts
when all of the vector stmts need to be built via a vector CTOR.
That makes sense unless the stmt only needs a single such vector CTOR
which would still mean
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92445
Eric Gallager changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90835
Eric Gallager changed:
What|Removed |Added
CC||juergen.reuter at desy dot de
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
--- Comment #15 from Jakub Jelinek ---
I think other fn spec attributes in trans-decl.c should be checked.
E.g. for internal_pack, I see ".r", when the function sometimes returns a
pointer to a field pointed by the first argument. The address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92657
Bug ID: 92657
Summary: High stack usage due ftree-ch
Product: gcc
Version: 10.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: rtl-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60228
steffen.seckler at tum dot de changed:
What|Removed |Added
CC||steffen.seckler at tum
On 11/25/19 1:38 PM, Tobias Burnus wrote:
> Thanks for the m68k work! Can you also update
> https://gcc.gnu.org/backends.html ?
Committed as obvious.
Bernd
commit f42834ad5e77c05cb6bc0908b8fc9282fec7fc19
Author: Bernd Schmidt
Date: Mon Nov 25 13:48:08 2019 +0100
Change backends table
Hi Richard,
Many thanks for the suggestion of an alternative implementation. I tried
implementing the suggestion, and I had a couple of observations:
1. As well as applying the bias in compute_fn_summary, it seemed to also
be necessary to apply it in ip_update_overall_fn_summary to avoid an ICE
On 11/25/19 1:38 PM, Bernd Schmidt wrote:
> On 11/25/19 1:34 PM, John Paul Adrian Glaubitz wrote:
>> Are all 4 + 2 patches in now? Thus, can we close the bug?
>
> We're missing one piece for better autoinc generation, but that's a
> small optimization issue. The cc0 conversion is complete.
On 11/25/19 1:34 PM, John Paul Adrian Glaubitz wrote:
> Are all 4 + 2 patches in now? Thus, can we close the bug?
We're missing one piece for better autoinc generation, but that's a
small optimization issue. The cc0 conversion is complete.
Bernd
Hi Bernd,
Thanks for the m68k work! Can you also update
https://gcc.gnu.org/backends.html ?
(Webseite repo ist now in git, cf. https://gcc.gnu.org/about.html#git )
Cheers,
Tobias
PS: I wonder whether some other archs also should be updated on that web
page.
On 11/25/19 1:33 PM, Bernd
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92649
--- Comment #4 from Richard Biener ---
(In reply to Jiangning Liu from comment #3)
> It is a stupid test, but it is simplified from a real application.
>
> To solve even more complicated scenario, this simple case needs to be
> addressed first.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48188
--- Comment #4 from Zdenek Sojka ---
Doesn't seem to crash since at least gcc-7
Hi Bernd!
On 11/25/19 1:33 PM, Bernd Schmidt wrote:
> On 11/23/19 6:36 PM, Jeff Law wrote:
>
>> Not really. I've already indicated to Bernd that he should go ahead and
>> commit the changes and we can iterate on any problems that arise.
>
> After the last fix, I did some more testing and since
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851
Bernd Schmidt changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
On 11/23/19 6:36 PM, Jeff Law wrote:
> Not really. I've already indicated to Bernd that he should go ahead and
> commit the changes and we can iterate on any problems that arise.
After the last fix, I did some more testing and since I feel confident
that it really is in good shape now, I
On 11/25/19 12:26 PM, Andreas Schwab wrote:
> On Nov 24 2019, Bernd Schmidt wrote:
>
>> Whew, I think I have it. One tst instruction eliminated when it
>> shouldn't have been:
>>
>> move.w %a4,%d0
>> - tst.b %d0
>> - jeq .L352
>> + jeq .L353
>>
>> And the reason - that's
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91851
--- Comment #8 from Bernd Schmidt ---
Author: bernds
Date: Mon Nov 25 12:31:16 2019
New Revision: 278681
URL: https://gcc.gnu.org/viewcvs?rev=278681=gcc=rev
Log:
Convert m68k to not use cc0
* config/m68k/m68k.c (output_move_himode,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
--- Comment #4 from Martin Liška ---
(In reply to fiesh from comment #2)
> It's been made invalid by creduce, but the original code was valid.
>
> If necessary, we can try to produce valid code that leads to the same issue.
> But I'd only do so
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
--- Comment #14 from Richard Biener ---
Well, lying means that for non-escaped desctiptors A and B doing
A.data = malloc();
gfc_desc_to_cfi_desc (, )
B.data and A.data are not considered aliasing.
So I'd recommend to not lie here. Yes,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
--- Comment #3 from fiesh at zefix dot tv ---
(Or is there some other trick to make it valid apart from extending the
interestingness test of creduce to include a clang compilation step?)
Hi,
I forgot to ping this,
is the updated patch OK?
On 9/6/19 1:27 PM, Bernd Edlinger wrote:
> On 9/6/19 12:47 PM, Richard Earnshaw (lists) wrote:
>> On 06/09/2019 11:28, Bernd Edlinger wrote:
>>> Hi!
>>>
>>> It was pointed out in the PR that the test case fails on big endian
>>> targets.
>>>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
--- Comment #2 from fiesh at zefix dot tv ---
It's been made invalid by creduce, but the original code was valid.
If necessary, we can try to produce valid code that leads to the same issue.
But I'd only do so if necessary since it's somewhat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92654
Martin Liška changed:
What|Removed |Added
Keywords||ice-on-invalid-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92123
Jakub Jelinek changed:
What|Removed |Added
CC||rguenth at gcc dot gnu.org
--- Comment
On 11/21/19 3:59 PM, Matthew Malcomson wrote:
On 21/11/2019 13:10, Martin Liška wrote:
On 11/20/19 6:40 PM, Matthew Malcomson wrote:
On 20/11/2019 14:29, Martin Liška wrote:
On 11/7/19 7:37 PM, Matthew Malcomson wrote:
I have rebased this series onto Martin Liska's patches that take the
most
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92649
--- Comment #3 from Jiangning Liu ---
It is a stupid test, but it is simplified from a real application.
To solve even more complicated scenario, this simple case needs to be addressed
first.
If we change the case to be as below,
int f(void)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92484
--- Comment #5 from franz ---
OK, I've now digged a little further in to this issue.
According to the GCC docs for a native build a 3-stage-build is performed
automatically. So with "--disable-bootstrap" the build should behave the same
as the
101 - 200 of 261 matches
Mail list logo
