https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #36 from Jan Hubicka hubicka at gcc dot gnu.org ---
This is probably too risky to fix for 5.1
(https://gcc.gnu.org/ml/gcc/2015-03/msg00241.html) though I am having WIP patch
now - we need to introduce transparent alias support and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #35 from Jan Hubicka hubicka at gcc dot gnu.org ---
Zack,
happy to hear from you again! Indeed the problem back was quite sloppy and we
kind of mixed up symbols, assembler names and declarations in not well defined
way.
I think the
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #34 from Zack Weinberg zackw at panix dot com ---
As I tried to explain, it is currently design decision to have one declaration
and one symtam node for one symbol. The one decl rule was introduced by
Codesourcery (Zack) in
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #30 from Richard Biener rguenth at gcc dot gnu.org ---
So, do we really want to go without this fixed again, for GCC 5? Honza? After
all this is an underlying wrong-code issue! (wrong function is picked as
prevailing)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
CC||zackw at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #31 from Jan Hubicka hubicka at ucw dot cz ---
So, do we really want to go without this fixed again, for GCC 5? Honza?
After
all this is an underlying wrong-code issue! (wrong function is picked as
prevailing)
Well, I have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #32 from rguenther at suse dot de rguenther at suse dot de ---
On Wed, 11 Feb 2015, hubicka at ucw dot cz wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #31 from Jan Hubicka hubicka at ucw dot cz ---
So,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #33 from rguenther at suse dot de rguenther at suse dot de ---
On Wed, 11 Feb 2015, Richard Biener wrote:
On Wed, 11 Feb 2015, hubicka at ucw dot cz wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #31
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #28 from Richard Biener rguenth at gcc dot gnu.org ---
Still broken :(
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
Target Milestone|4.8.4 |4.8.5
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #23 from rguenther at suse dot de rguenther at suse dot de ---
On Tue, 7 Oct 2014, hubicka at ucw dot cz wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #22 from Jan Hubicka hubicka at ucw dot cz ---
We can
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #24 from Jakub Jelinek jakub at gcc dot gnu.org ---
But is warning/error attribute the only thing on aliases that can hold extra
semantics info (now or in the future)? I'd say LTO symtab merging should merge
what is mergeable, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #25 from rguenther at suse dot de rguenther at suse dot de ---
On Wed, 8 Oct 2014, jakub at gcc dot gnu.org wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #24 from Jakub Jelinek jakub at gcc dot gnu.org ---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #26 from Jan Hubicka hubicka at ucw dot cz ---
But is warning/error attribute the only thing on aliases that can hold extra
semantics info (now or in the future)? I'd say LTO symtab merging should
merge
what is mergeable, and
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #19 from rguenther at suse dot de rguenther at suse dot de ---
On Mon, 6 Oct 2014, hubicka at ucw dot cz wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #11 from Jan Hubicka hubicka at ucw dot cz ---
Hi,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #20 from Jakub Jelinek jakub at gcc dot gnu.org ---
The builtin-types.def part is unnecessary, I don't see internal-fn.def part.
Also, we might need to tune optimizations across the two internal calls (from
aliasing POV at least), we
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #22 from Jan Hubicka hubicka at ucw dot cz ---
Concerning Richard's comment, it is true that we will produce more warings then
before in case function is optimized out. But we always did produce extra
warnings
when the function call
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #11 from Jan Hubicka hubicka at ucw dot cz ---
Hi,
this patch implements the lowring. Each call with warn attribute triggers code
in cgraphunit that inserts call to bulitin_warning/error that is output at
expansion time.
Do we have
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #12 from Jakub Jelinek jakub at redhat dot com ---
On Mon, Oct 06, 2014 at 10:22:21PM +0200, Jan Hubicka wrote:
this patch implements the lowring. Each call with warn attribute triggers
code
in cgraphunit that inserts call to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #13 from Jan Hubicka hubicka at ucw dot cz ---
Hi,
I am testing this variant of the patch.
For gcc-4.9 branch it may make sense to enable the new patch for LTO only.
Index: internal-fn.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #14 from Jakub Jelinek jakub at redhat dot com ---
On Mon, Oct 06, 2014 at 11:55:23PM +0200, Jan Hubicka wrote:
Hi,
I am testing this variant of the patch.
For gcc-4.9 branch it may make sense to enable the new patch for LTO only.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #15 from Jan Hubicka hubicka at ucw dot cz ---
On Mon, Oct 06, 2014 at 11:55:23PM +0200, Jan Hubicka wrote:
Hi,
I am testing this variant of the patch.
For gcc-4.9 branch it may make sense to enable the new patch for LTO only.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #16 from Jakub Jelinek jakub at redhat dot com ---
On Tue, Oct 07, 2014 at 12:18:24AM +0200, Jan Hubicka wrote:
On Mon, Oct 06, 2014 at 11:55:23PM +0200, Jan Hubicka wrote:
Hi,
I am testing this variant of the patch.
For
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #17 from Jan Hubicka hubicka at ucw dot cz ---
%K in the format string, assuming the call has locus with the right block,
should do that. At least with -g, without -g or with LTO it will be less
accurate.
Yep, for that I need a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #18 from Jan Hubicka hubicka at ucw dot cz ---
Hi,
actually I can just add the location to the first argument to avoid the need
to build extra tree...
Somewhat ugly, but seems to work.
Index: internal-fn.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #10 from rguenther at suse dot de rguenther at suse dot de ---
On Mon, 8 Sep 2014, hubicka at ucw dot cz wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #9 from Jan Hubicka hubicka at ucw dot cz ---
The
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #9 from Jan Hubicka hubicka at ucw dot cz ---
The issue is that we resolve aliases in a bogus way, not warning/error
stuff.
Those are not aliases, but duplicated declarations that are supposed to not
exist since one declaration
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #8 from rguenther at suse dot de rguenther at suse dot de ---
On Wed, 27 Aug 2014, hubicka at ucw dot cz wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #7 from Jan Hubicka hubicka at ucw dot cz ---
Honza,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Known to fail|4.10.0 |5.0
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61886
--- Comment #7 from Jan Hubicka hubicka at ucw dot cz ---
Honza, did you get anything working?
Sorry, I am at Mountain trip till 6th of September, so I do not have much
chance to hack. Will take it as priority afterwards. I think cleanest
32 matches
Mail list logo
