https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
Bernd Edlinger changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #36 from Bernd Edlinger ---
Author: edlinger
Date: Wed Feb 27 20:14:55 2019
New Revision: 269264
URL: https://gcc.gnu.org/viewcvs?rev=269264=gcc=rev
Log:
2019-02-27 Bernd Edlinger
PR rtl-optimization/89490
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #35 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #34)
> Passed bootstrap/regtest on powerpc64le-linux, on powerpc64-linux passed
> bootstrap, regtest still ongoing.
Successfully regtested (-m32/-m64) on
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #34 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #33)
> I've started bootstrap/regtest of this on powerpc64{,le}-linux (on
> CompileFarm).
Passed bootstrap/regtest on powerpc64le-linux, on powerpc64-linux passed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #33 from Jakub Jelinek ---
I've started bootstrap/regtest of this on powerpc64{,le}-linux (on
CompileFarm).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
Bernd Edlinger changed:
What|Removed |Added
Attachment #45833|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #31 from Jakub Jelinek ---
(In reply to Bernd Edlinger from comment #30)
> (In reply to Jakub Jelinek from comment #29)
> > Either the
> >/* Don't use anchors for mergeable sections. The linker might move
> > the objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #30 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #29)
> Either the
>/* Don't use anchors for mergeable sections. The linker might move
> the objects around. */
> comment should be dropped, or the two
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #29 from Jakub Jelinek ---
Either the
/* Don't use anchors for mergeable sections. The linker might move
the objects around. */
comment should be dropped, or the two comments in
default_use_anchors_for_symbol_p should be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
Bernd Edlinger changed:
What|Removed |Added
Attachment #45832|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #27 from Bernd Edlinger ---
(In reply to rsand...@gcc.gnu.org from comment #24)
>
> I think we should also remove the test in default_use_anchors_for_symbol_p,
> since:
>
> sect = SYMBOL_REF_BLOCK (symbol)->sect;
>
> will surely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
Bernd Edlinger changed:
What|Removed |Added
Attachment #45830|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #25 from Jakub Jelinek ---
(In reply to rsand...@gcc.gnu.org from comment #24)
> I think we should also remove the test in default_use_anchors_for_symbol_p,
> since:
>
> sect = SYMBOL_REF_BLOCK (symbol)->sect;
>
> will surely
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #24 from rsandifo at gcc dot gnu.org
---
(In reply to Jakub Jelinek from comment #23)
> Comment on attachment 45830 [details]
> proposed patch
>
> Please update the get_block_for_section function comment accordingly:
>
> /* Return
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #23 from Jakub Jelinek ---
Comment on attachment 45830
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45830
proposed patch
Please update the get_block_for_section function comment accordingly:
/* Return the object_block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #22 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #20)
> I don't think users would appreciate the change in behavior where constant
> and string merging would stop to work completely.
>
> I've successfully
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #21 from Bernd Edlinger ---
Created attachment 45830
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45830=edit
proposed patch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #20 from Jakub Jelinek ---
I don't think users would appreciate the change in behavior where constant and
string merging would stop to work completely.
I've successfully bootstrapped/regtested the #c15 patch on powerpc64{,le}-linux
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #19 from Alan Modra ---
Created attachment 45829
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45829=edit
Prevent use of merge sections when -fsection-anchors
This isn't particularly elegant, but survives bootstrap and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #18 from Alan Modra ---
The assertion triggered in multiple places when compiling various libgcc2.c
pieces, and dfp-bit.c.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #17 from Alan Modra ---
The correct place for comment #15 patch is get_block_for_decl, I think. I'm
bootstrapping such a patch along with an assert in output_object_block that we
don't have a merge section.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
Jakub Jelinek changed:
What|Removed |Added
CC||rsandifo at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #15 from Bernd Edlinger ---
I wonder if this would also work?
At least for simple test cases that seems to be fine.
--- varasm.c.orig 2019-01-25 17:57:32.0 +0100
+++ varasm.c2019-02-26 22:03:39.753325517 +0100
@@
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #14 from Bernd Edlinger ---
(In reply to Jakub Jelinek from comment #13)
>
> Well, it matches what output_constant does:
> case STRING_CST:
> thissize = (unsigned HOST_WIDE_INT)TREE_STRING_LENGTH (exp);
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #13 from Jakub Jelinek ---
(In reply to Bernd Edlinger from comment #11)
> Instead of:
>
> if (thissize == 0
> || TREE_STRING_POINTER (str) [thissize - 1] != '\0')
> size = MAX (size,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #12 from Bernd Edlinger ---
> These should not go into mergeable sections.
I mean: These do not go into mergeable sections.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #11 from Bernd Edlinger ---
I agree, that it would be better to not put any
mergeable things in a block object. If section anchors
are ever used on a string constant, it is going to fail.
A constant with size = 0 is possible, for
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #10 from Jakub Jelinek ---
I think there is a serious flaw that the section anchor infrastructure is used
at all for the SECTION_MERGE sections, one really must not use any kind of
section anchors for those sections, there is no
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #9 from Bernd Edlinger ---
> And, what do you find wrong on the alignment?
In the case of the artificially zero terminated strings,
the .zero is now wrong, and they can actually screw up the
necessary alignment.
Maybe the easiest
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #8 from Jakub Jelinek ---
(In reply to Bernd Edlinger from comment #5)
> Adding zero bytes after each string constant makes no sense IMHO,
> since the linker will merge the constants, and so aligning the
> constants with .zero does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #7 from Bernd Edlinger ---
(In reply to Alan Modra from comment #6)
> The zero bytes are added by the -fsection-anchors code. They used to align
> the next object. Now, the number of zero bytes is wrong (in cases where we
> used to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
Alan Modra changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
Alan Modra changed:
What|Removed |Added
Priority|P1 |P3
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #5 from Bernd Edlinger ---
The patch should probably work, and a powerpc cross fixes the test case.
At least bootstrap and reg-test on x86_64-pc-linux-gnu is fine,
but that proves not too much.
When I look at the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
--- Comment #4 from Bernd Edlinger ---
funny, how I managed to overlook this...
--- varasm.c.orig 2019-01-25 17:57:32.0 +0100
+++ varasm.c2019-02-25 13:13:55.652051780 +0100
@@ -7634,6 +7634,8 @@
/* Output the objects
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
Jakub Jelinek changed:
What|Removed |Added
Priority|P3 |P1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89490
Alan Modra changed:
What|Removed |Added
CC||bernd.edlinger at hotmail dot
de
37 matches
Mail list logo
