https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90277
François Dumont changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90356
--- Comment #3 from ead ---
I guess -0.0+0.0=0.0 is the reason we have to add it once. I think there is no
need to add 0.0 twice.
Btw. compiled with -fno-signed-zeros, the code gets optimized to
doit:
ret
as expected.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
Andrew Pinski changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90356
Andrew Pinski changed:
What|Removed |Added
Keywords||missed-optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90356
--- Comment #1 from Andrew Pinski ---
So the optimization asked for in this case is:
a+0.0+0.0 to just a+0.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90356
Bug ID: 90356
Summary: Missed optimization for variables initialized to 0.0
Product: gcc
Version: 9.1.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90355
Bug ID: 90355
Summary: Uninitialized read in
gfortran.dg/ISO_Fortran_binding_4.f90 test
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Keywords: wrong-code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #9 from Toon Moene ---
> So with this suggestion, this procedure would be generated without the hidden
> length argument. The brokenness comes from
> call foo("ab")
> which would generate a call to a procedure WITH the hidden
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90352
--- Comment #6 from Paul Thomas ---
(In reply to Thomas Koenig from comment #5)
> Hi Paul,
>
> > I am sure that the array part is OK. Otherwise, why have a type code for
> > strings?
>
> It
>
> 18.5 The source file ISO_Fortran_binding.h
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90265
--- Comment #3 from Marek Polacek ---
This fixes it:
--- a/gcc/cp/pt.c
+++ b/gcc/cp/pt.c
@@ -18881,7 +18881,8 @@ tsubst_copy_and_build (tree t,
if (thisarg)
{
/* Shift the other args over to make room. */
-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90344
Thomas Koenig changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90344
--- Comment #3 from Thomas Koenig ---
Author: tkoenig
Date: Sun May 5 14:01:51 2019
New Revision: 270883
URL: https://gcc.gnu.org/viewcvs?rev=270883=gcc=rev
Log:
2019-05-05 Thomas Koenig
PR fortran/90344
* frontend-passes.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90344
--- Comment #2 from Thomas Koenig ---
Author: tkoenig
Date: Sun May 5 13:53:24 2019
New Revision: 270882
URL: https://gcc.gnu.org/viewcvs?rev=270882=gcc=rev
Log:
2019-05-05 Thomas Koenig
PR fortran/90344
*
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90352
--- Comment #5 from Thomas Koenig ---
Hi Paul,
> I am sure that the array part is OK. Otherwise, why have a type code for
> strings?
It
18.5 The source file ISO_Fortran_binding.h
18.5.1 Summary of contents
The source file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #8 from Janne Blomqvist ---
(In reply to Janne Blomqvist from comment #3)
> 1) When compiling an external procedure, for character(len=1) arguments we
> don't generate the hidden string length argument. And similarly when calling
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90344
Thomas Koenig changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90352
--- Comment #4 from Paul Thomas ---
Hi Thomas,
> if the type is character, interoperability also requires that the length
> type parameter be omitted or be specified by an initialization
> expression whose value is one.
>
> F2008, 15.3.2 has
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90354
vfdff changed:
What|Removed |Added
CC||zhongyunde at huawei dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90352
--- Comment #3 from Thomas Koenig ---
(In reply to Paul Thomas from comment #2)
> This is already fixed on my working branch.
>
> This used to be the error message:
>
> Character argument ‘c’ at (1) must be length 1 because procedure ‘bar’ is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90344
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90328
--- Comment #1 from Marc Glisse ---
dr_may_alias_p says a and b cannot alias because:
(gdb) p addr_a->base.u.dependence_info
$13 = {clique = 2, base = 0}
(gdb) p addr_b->base.u.dependence_info
$14 = {clique = 2, base = 1}
which comes from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90348
MCCCS changed:
What|Removed |Added
CC||mcccs at gmx dot com
--- Comment #2 from MCCCS
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90352
Paul Thomas changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |pault at gcc dot gnu.org
---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90354
Bug ID: 90354
Summary: [7.3 regression] Skip the not first insn when
traversing the insn node
Product: gcc
Version: 7.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340
--- Comment #2 from Fredrik Hederstierna
---
Created attachment 46297
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46297=edit
Stripped down testcase, gives +35% code size increase
Stripped down testcase, gives +35% code size increase.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90340
--- Comment #1 from Fredrik Hederstierna
---
Stripped down the testcase some, this version gives +35% code size increase.
With gcc-8.2.0 it was 536 bytes, when gcc-9.1.0 gives 724 bytes (+188 bytes).
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90353
--- Comment #2 from Marc Glisse ---
(from https://stackoverflow.com/q/55977431/1918193)
Thanks.
except.c (initialize_handler_parm) says:
/* Make sure we mark the catch param as used, otherwise we'll get a
warning about an unused
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90168
--- Comment #5 from Eric Botcazou ---
> How about adjusting REG_FREQ_MAX to be same as BB_FREQ_MAX? Now
> REG_FREQ_MAX/BB_FREQ_MAX is 1/10.
The way out is probably to use a 64-bit fixed-point type like profiling.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90352
Dominique d'Humieres changed:
What|Removed |Added
Priority|P3 |P4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90329
--- Comment #7 from Paul Thomas ---
(In reply to Thomas Koenig from comment #6)
> (In reply to Janne Blomqvist from comment #5)
> > (In reply to Thomas Koenig from comment #4)
> > > Currently, I am leaning towards using an option with a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90353
--- Comment #1 from Mark Harrison ---
Created attachment 46296
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46296=edit
Preprocessed file created with -save-temps
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90353
Bug ID: 90353
Summary: No warning on unused exception parameter with -Wall
-Wextra
Product: gcc
Version: 8.3.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90352
Bug ID: 90352
Summary: [9/10 Regression] ICE on BIND(C) subroutine with
characters with len /= 1
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90352
Thomas Koenig changed:
What|Removed |Added
Target Milestone|--- |9.2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90351
Bug ID: 90351
Summary: -fc-prototypes does not dump prototypes for external
procedures
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: enhancement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90174
--- Comment #9 from Feng Xue ---
(In reply to Feng Xue from comment #5)
> > I would say that top-down algorithm behaves better than bottom-up one. I
> > implemented Callahan-Koblentz (bottom-up algorithm) in GCC about 10 years
> > ago and it
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90168
--- Comment #4 from Feng Xue ---
(In reply to Andrew Pinski from comment #3)
> >or to use float type to hold frequency?
>
> This won't work correctly as floating point is different between hosts.
> There has been some usage of floating point
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90174
--- Comment #8 from Feng Xue ---
Created attachment 46294
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46294=edit
asm file 2 generated by llvm
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90174
--- Comment #7 from Feng Xue ---
Created attachment 46293
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46293=edit
asm file 2 generated by gcc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90174
--- Comment #6 from Feng Xue ---
Created attachment 46292
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46292=edit
test case with less live ranges
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90174
--- Comment #5 from Feng Xue ---
> I would say that top-down algorithm behaves better than bottom-up one. I
> implemented Callahan-Koblentz (bottom-up algorithm) in GCC about 10 years
> ago and it behaved worse than the current one. I think
41 matches
Mail list logo
