https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105135
Bug ID: 105135
Summary: [11/12 Regression] Optimization regression for
handrolled branchless assignment
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105128
--- Comment #4 from CVS Commits ---
The master branch has been updated by Jakub Jelinek :
https://gcc.gnu.org/g:2a82301d409d3aa0e0b3b884e4c6daeaa0486d6b
commit r12-7968-g2a82301d409d3aa0e0b3b884e4c6daeaa0486d6b
Author: Jakub Jelinek
Date: S
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105128
Jakub Jelinek changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105136
Bug ID: 105136
Summary: [11/12] Missed optimization regression with 32-bit
adds and shifts
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104865
Maciej W. Rozycki changed:
What|Removed |Added
CC||macro at orcam dot me.uk
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105137
Bug ID: 105137
Summary: Missed optimization 64-bit adds and shifts
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: middl
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104865
--- Comment #4 from Jonathan Wakely ---
They can still have NaNs.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104865
--- Comment #5 from Maciej W. Rozycki ---
Wrong question then. Should `__builtin_nan' even compile on non-IEEE-754
FP targets that don't have a qNaN? And I'll reply to myself.
According to our manual:
"-- Built-in Function: double __builtin_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104865
--- Comment #6 from Jonathan Wakely ---
OK, maybe I should not have used __builtin_nan in the test. The bug is in the
rest of the code though, isn't it? Replace the __builtin_nan with a function
returning the same sNaN, does the test still fail?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138
Bug ID: 105138
Summary: [7,8,9,10,11,12,F95] Bogus error when function name
does not shadow an intrinsic when RESULT clause is
used
Product: gcc
Version: 12.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138
--- Comment #1 from Vladimir Fuka ---
For after naming LOG one gets
RECURSIVE FUNCTION LOG(Z) RESULT(RES)
COMPLEX,INTENT(IN) :: Z
COMPLEX :: RES
RES = LOG(Z);
END FUNCTION LOG
> gfortran-12 -c shadow.f90
/tmp/ccbpyhxl.s: Assembler mes
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104865
--- Comment #7 from Maciej W. Rozycki ---
Well, it's not clear to me whether the reserved operand as defined by the
VAX floating-point architecture ought be considered an sNaN given that
there is no qNaN.
Also a reserved operand causes a fault
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138
--- Comment #2 from Vladimir Fuka ---
As mentioned, the correct function is called in case everything is REAL
a = floor(5.0)
print *, a
contains
RECURSIVE FUNCTION FLOOR(Z) RESULT(RES)
REAL,INTENT(IN) :: Z
REAL :: RES
if (z>0) then
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138
kargl at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P4
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138
--- Comment #4 from kargl at gcc dot gnu.org ---
(In reply to Vladimir Fuka from comment #2)
> As mentioned, the correct function is called in case everything is REAL
>
Actually, the correct function isn't called. See the parse
tree that I pos
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138
--- Comment #5 from Vladimir Fuka ---
In that case some compiler or linker magic happens after that, because the
correct code is executed.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138
--- Comment #6 from anlauf at gcc dot gnu.org ---
Workaround:
module m
interface LOG_GAMMA
module procedure LOG_GAMMA_
end interface LOG_GAMMA
contains
RECURSIVE FUNCTION LOG_GAMMA_(Z) RESULT(RES)
COMPLEX,INTENT(IN) :: Z
COMPL
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105139
Bug ID: 105139
Summary: GCC produces vmovw instruction with an incorrect
argument for -O3 -march=sapphirerapids
Product: gcc
Version: 12.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138
--- Comment #7 from kargl at gcc dot gnu.org ---
It seems the problem is that gfortran does not know
that a function name is local to its own scoping unit
when a result-name is used.
First, if the function is contained in a module it seems
to wo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105101
Michael_S changed:
What|Removed |Added
CC||already5chosen at yahoo dot com
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105138
--- Comment #8 from kargl at gcc dot gnu.org ---
This patch fixes the error. The comment in the patch explains it.
diff --git a/gcc/fortran/intrinsic.cc b/gcc/fortran/intrinsic.cc
index 52e5f4ed39e..ec833667dbe 100644
--- a/gcc/fortran/intrinsi
21 matches
Mail list logo
