https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
--- Comment #25 from CVS Commits ---
The releases/gcc-10 branch has been updated by Jason Merrill
:
https://gcc.gnu.org/g:031e97207463710797625382baff112b6c3ade51
commit r10-9362-g031e97207463710797625382baff112b6c3ade51
Author: Jason Merrill
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
--- Comment #24 from CVS Commits ---
The master branch has been updated by Jason Merrill :
https://gcc.gnu.org/g:bdbca69e0720fa9062fe71782235141f629ae006
commit r11-7142-gbdbca69e0720fa9062fe71782235141f629ae006
Author: Jason Merrill
Date: M
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
Jason Merrill changed:
What|Removed |Added
Target Milestone|--- |10.0
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
--- Comment #22 from Jason Merrill ---
Author: jason
Date: Wed May 22 21:39:08 2019
New Revision: 271523
URL: https://gcc.gnu.org/viewcvs?rev=271523&root=gcc&view=rev
Log:
PR c++/20408 - unnecessary code for empty struct.
Here initializ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
Jason Merrill changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned a
--- Comment #20 from rguenth at gcc dot gnu dot org 2007-11-27 09:40
---
For the testcase in comment #13 we now generate two(!) temporaries:
void barc() ()
{
struct Foo D.2027;
struct Foo D.2028;
D.2027 = {};
D.2028 = {};
bar (D.2028);
}
via gimplification of
;; Function v
--- Comment #19 from steven at gcc dot gnu dot org 2007-11-26 14:17 ---
The recent improvements to the dataflow module and ra-conflicts may have fixed
this. Richi, you were the last to look at this bug report. Can you check if
there still is an issue to fix here?
--
steven at gcc d
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-05
12:38 ---
Life analysis should figure out, that for
(insn 10 9 11 1 (set (mem/s:QI (pre_modify:SI (reg/f:SI 7 sp)
(plus:SI (reg/f:SI 7 sp)
(const_int -2 [0xfffe]))) [0 S1 A8])
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-05
10:48 ---
Unfortunately we start with D.1755 allocated to a register. This may be solved
at the tree level if we fix PR23372. Or we need to be smarter at allocating
space for D.1755.
--
http://gcc.gnu.org/bugzil
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-05
10:36 ---
Pinskias patch fixes one part of the problem. For x86 there remains the
issue that we are passing X on the stack and generate
_Z8call_foov:
.LFB2:
subl$26, %esp
.LCFI4:
pushw %ax
.LCF
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-04
17:12 ---
I will look at this. Is this by any chance a regression?
--
What|Removed |Added
Ass
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-04
16:37 ---
pinskia posted a patch for the =0 "bug"
http://gcc.gnu.org/ml/gcc-patches/2005-03/msg01054.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
--- Additional Comments From rguenth at gcc dot gnu dot org 2005-09-04
16:25 ---
For
struct Foo {};
void foo(const Foo&);
void bar(Foo);
void fooc(void)
{
foo(Foo());
}
void barc(void)
{
bar(Foo());
}
we get different initializers for the Foo& and the Foo case:
void f
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
17:35 ---
The change to cp-gimplifier.c should still happen as it makes not create a
INTEGER_CST for an
aggregate.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20408
--- Additional Comments From pinskia at gcc dot gnu dot org 2005-03-10
17:30 ---
(In reply to comment #10)
> I think we should produce an empty CONSTRUCTOR (which I am testing right now).
That did not fix it, we still get code generated for the "empty" struct:
;; D.1594 = {}
(nil)
;; fo
15 matches
Mail list logo