https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94603
--- Comment #5 from Jakub Jelinek ---
(In reply to Uroš Bizjak from comment #4)
> (In reply to Jakub Jelinek from comment #3)
> > The testcase will need -msse -mno-sse2.
>
> Yes, but the testcase is invalid, because __builtin_ia32_movq128 should
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93053
Jakub Jelinek changed:
What|Removed |Added
Summary|[9/10 Regression] libgcc|[9 Regression] libgcc build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94516
--- Comment #13 from Jakub Jelinek ---
I've gathered statistics across x86_64-linux and i686-linux bootstraps/regtests
in postreload.c (reload_cse_simplify_set) when sp = sp + const_int is replaced
with sp = reg, once with the recent cselib.c/var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93974
--- Comment #20 from Jakub Jelinek ---
Have you managed to make some progress? This is one of the last 10 P1 blockers
of the release.
|1
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #11 from Jakub Jelinek ---
Created attachment 48280
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48280&acti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #20 from Jakub Jelinek ---
So, we are running into PR33916 here, not very much reduced test:
class function_arg_info
{
public:
function_arg_info ()
: type (0), mode (0), named (false), pass_by_reference (false)
{}
function_a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91153
--- Comment #2 from Jakub Jelinek ---
Only bugs that are marked as [... Regression] and have corresponding Target
Milestone are classified that way.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94607
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89494
--- Comment #23 from Jakub Jelinek ---
Eventually yes, but I'd like to test & submit the above patch too and let it be
tested on the trunk for a while before backporting.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
--- Comment #8 from Jakub Jelinek ---
I'd like to ping this, it would be nice to at least decide if this should be
handled for GCC10 or postponed to GCC11 only.
,
||jakub at gcc dot gnu.org,
||uros at gcc dot gnu.org
--- Comment #9 from Jakub Jelinek ---
(In reply to Richard Biener from comment #6)
> There's also
>
>&& i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #10 from Jakub Jelinek ---
So something like:
--- gcc/config/i386/i386.md.jj 2020-03-16 22:56:55.556043275 +0100
+++ gcc/config/i386/i386.md 2020-04-15 19:07:04.405933639 +0200
@@ -8732,8 +8732,20 @@
&& ix86_match_ccmode (ins
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #12 from Jakub Jelinek ---
(In reply to Jeffrey A. Law from comment #11)
> Rather than extending that hack, I think just widening the mode when the
> sign bit is being tested (c#5) is simpler and easier to understand. The
> bits you'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008
--- Comment #16 from Jakub Jelinek ---
bison 1.35 doesn't, and that is what has been used last time.
Is even %define api.pure full (vs. %pure_parser) supported in much older bison
versions? Maybe 1.875 is the oldest people do use in real-world,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008
--- Comment #19 from Jakub Jelinek ---
Created attachment 48287
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48287&action=edit
gcc10-pr92008.patch
Or maybe just do require bison 3 (7 years old) if intl/plural.y needs to be
regenerated?
D
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92008
--- Comment #20 from Jakub Jelinek ---
Forgot an important part:
--- config/gettext.m4.jj2020-01-12 11:54:35.753423366 +0100
+++ config/gettext.m4 2020-04-16 12:34:51.466081569 +0200
@@ -1,5 +1,5 @@
# gettext.m4 serial 20 (gettext-0.12
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94616
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
--- Comment #14 from Jakub Jelinek ---
Created attachment 48288
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48288&action=edit
gcc10-pr94567.patch
So perhaps this? In the condition exclude cases where we can't widen the
problematic case
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94617
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94612
Jakub Jelinek changed:
What|Removed |Added
CC||marxin at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94612
--- Comment #7 from Jakub Jelinek ---
(In reply to Matthias Klose from comment #5)
> > Perhaps Ubuntu has the offloading and non-offloading compiler configured
> > differently, one with zstd compression support and the other without?
>
> how wou
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
--- Comment #10 from Jakub Jelinek ---
Thanks.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94618
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94618
--- Comment #4 from Jakub Jelinek ---
I think the difference is much earlier, in cse_local dump there is (with
additional --param=min-nondebug-insn-uid=1):
deferring deletion of insn with uid = 10060.
-deferring deletion of insn with uid = 1
||jakub at gcc dot gnu.org
Status|UNCONFIRMED |RESOLVED
--- Comment #2 from Jakub Jelinek ---
.
*** This bug has been marked as a duplicate of bug 94621 ***
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94621
--- Comment #2 from Jakub Jelinek ---
*** Bug 94620 has been marked as a duplicate of this bug. ***
at gcc dot gnu.org |jakub at gcc dot gnu.org
--- Comment #5 from Jakub Jelinek ---
Created attachment 48293
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48293&action=edit
gcc10-pr94618.patch
Untested fix.
segfaults when|[9/10 Regression] GCC 9.2.1
|compiling file with -O3 |segfaults when compiling
||file with -O3 since r9-5354
CC||jakub at gcc dot gnu.org
Assignee|unassigned at
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94621
--- Comment #4 from Jakub Jelinek ---
Created attachment 48294
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48294&action=edit
gcc10-pr94621.patch
Untested fix.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94626
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94618
--- Comment #7 from Jakub Jelinek ---
Perhaps if we checked DEBUG_INSN_P on BB_END, we could then use
prev_nondebug_insn, so like:
if (INSN_P (insn) && BLOCK_FOR_INSN (insn))
{
basic_block bb = BLOCK_FOR_INSN (insn);
if (BB_END
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94618
--- Comment #8 from Jakub Jelinek ---
Though, a slight advantage of the patch as is is that it will do any insn walk
only if two conditions are met, BB_END is a DEBUG_INSN and insn is followed by
a DEBUG_INSN. My thoughs were that there could be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94621
Jakub Jelinek changed:
What|Removed |Added
Summary|[9/10 Regression] GCC 9.2.1 |[9 Regression] GCC 9.2.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94618
Jakub Jelinek changed:
What|Removed |Added
Summary|[8/9/10 Regression] |[8/9 Regression]
|'-fc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629
--- Comment #7 from Jakub Jelinek ---
(In reply to David Binderman from comment #6)
> (In reply to Jakub Jelinek from comment #5)
> > We should for GCC11 discuss if we want to implement some of these checks,
> > either in -fanalyzer, or as normal
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629
--- Comment #9 from Jakub Jelinek ---
Comment on attachment 48299
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48299
sorted list of redundant assignments
/* If there were any declarations or structure tags in that level,
or if thi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629
Jakub Jelinek changed:
What|Removed |Added
CC||ams at gcc dot gnu.org
--- Comment #10 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #18 from Jakub Jelinek ---
Comment on attachment 48302
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48302
Untested fix
+ /* IPA-SRA does not analyze other types of statements. */
+ gcc_unreachable ();
Won
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #20 from Jakub Jelinek ---
Looking at tree-ssa-dce.c, it uses remove_phi_node rather than gsi_remove for
PHIs. And for non-PHIs, it calls release_defs after gsi_remove.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94629
--- Comment #12 from Jakub Jelinek ---
(In reply to Andrew Stubbs from comment #11)
> (In reply to Jakub Jelinek from comment #10)
> > or if instead we should drop the "status = " for the cases where nothing
> > checks it. Andrew?
>
> I think ch
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94597
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
||jakub at gcc dot gnu.org,
||jason at gcc dot gnu.org
Ever confirmed|0 |1
Last reconfirmed||2020-04-17
Priority|P3 |P1
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #23 from Jakub Jelinek ---
Instead of #c11 I meant:
- else if ((is_gimple_assign (stmt) && !gimple_has_volatile_ops (stmt))
-|| gimple_code (stmt) == GIMPLE_PHI)
+ else if (flag_tree_dce
+&&
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #26 from Jakub Jelinek ---
For debug stmts, it would be best if we could use those
DEBUG D#Y s=> parm
DEBUG var => D#Y
added in if (param_body_adjs && MAY_HAVE_DEBUG_BIND_STMTS).
Though, if we remove already
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #27 from Jakub Jelinek ---
Now, perhaps the analysis code could also detect which lhs are directly or
indirectly needed by debug stmts and when doing this return NULL in
remap_gimple_stmt, we could do something like (much simplified)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94567
Jakub Jelinek changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94637
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #5
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94637
Jakub Jelinek changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
||jakub at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94641
--- Comment #2 from Jakub Jelinek ---
Created attachment 48310
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48310&action=edit
gcc10-pr94641.patch
Untested fix.
|1
Keywords||ra
Last reconfirmed||2020-04-20
CC||jakub at gcc dot gnu.org,
||vmakarov at gcc dot gnu.org
--- Comment #1 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #29 from Jakub Jelinek ---
(In reply to rguent...@suse.de from comment #28)
> On Fri, 17 Apr 2020, jakub at gcc dot gnu.org wrote:
>
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
> >
> > --- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94667
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94516
--- Comment #14 from Jakub Jelinek ---
Created attachment 48312
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48312&action=edit
gcc10-pr94516.patch
Untested patch for the missed-optimization part, with this we get the same
assembly like g
|--- |FIXED
CC||jakub at gcc dot gnu.org
--- Comment #2 from Jakub Jelinek ---
Fixed with r10-7770-ga64468a3034dd8e2d0794a5be84b8da544ffe2c3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89863
Bug 89863 depends on bug 80051, which changed state.
Bug 80051 Summary: gcc/dwarf2out.c: PVS-Studio: V501
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80051
What|Removed |Added
--
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94671
--- Comment #6 from Jakub Jelinek ---
Well, the compiler shouldn't optimize away the allocation and not the
deallocation or vice versa, it needs to either optimize away allocation and all
corresponding deallocations, or none of that.
There were s
|--- |FIXED
CC||jakub at gcc dot gnu.org
--- Comment #3 from Jakub Jelinek ---
Assuming fixed.
||burnus at gcc dot gnu.org,
||jakub at gcc dot gnu.org
Last reconfirmed||2020-04-20
--- Comment #1 from Jakub Jelinek ---
Started with r10-3735-gcb57504a550158913258e5be8ddb991376475efb
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94672
--- Comment #2 from Jakub Jelinek ---
>From quick look, seems the Fortran FE for the dummy optional argument uses
array.0, i.e. a local automatic array descriptor that is assigned if
if (array != 0B && (real(kind=4)[0:] * restrict) array->data !=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94672
--- Comment #3 from Jakub Jelinek ---
Note, just making (some or all) optional PARM_DECLs predetermined shared (or
firstprivate) by the langhook isn't correct, because
subroutine foo (array)
real, optional :: array(:)
!$omp parallel default(n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94655
--- Comment #4 from Jakub Jelinek ---
I don't see how it makes a difference between whether it is a store created by
the vectorizer or some original user store.
What matters is what ADDR_EXPR picks up SCCVN for the base, and it will pick up
the f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94383
--- Comment #11 from Jakub Jelinek ---
Created attachment 48317
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48317&action=edit
gcc10-pr94383.patch
Testsuite coverage. This passes make -j32 -k check-c++-all
RUNTESTFLAGS=struct-layout-1.e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94676
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94675
--- Comment #5 from Jakub Jelinek ---
(In reply to Martin Sebor from comment #1)
> unsigned char c, n;
>
> int f (void)
> {
> if (n <= 7) return 0;
>
> unsigned char *p = &c, *q = p + n;
This testcase has UB whenever n > 7 and due to that
]
|-Warray-bounds false|-Warray-bounds false
|positive with -O2 |positive with -O2 since
||r9-1948
CC||jakub at gcc dot gnu.org
--- Comment #6 from Jakub Jelinek ---
Started
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #18 from Jakub Jelinek ---
Note, we could do movq %xmm0, %xmm0; movq %xmm1, %xmm1; addpd %xmm1, %xmm0 for
the #c4 first function.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
Jakub Jelinek changed:
What|Removed |Added
CC||hjl.tools at gmail dot com,
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
Target Milestone: ---
typedef float V __attribute__((vector_size(16)));
typedef int VI __attribute__((vector_size(16)));
V
foo (V x)
{
return __builtin_shuffle (x
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94680
Jakub Jelinek changed:
What|Removed |Added
CC||uros at gcc dot gnu.org
Targ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #21 from Jakub Jelinek ---
(In reply to Joel Yliluoma from comment #20)
> Which exceptions would be generated by data in an unused portion of a
> register?
addps adds 4 float elements, there is no "unused" portion.
If some of the ele
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31485
--- Comment #24 from Jakub Jelinek ---
Bugzilla is not the right place to educate users. Of course the C FE_*
exceptions map to real hardware exceptions, on x86 read e.g. about MXCSR
register and in the description of each instruction on which E
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93786
--- Comment #9 from Jakub Jelinek ---
Tried now also:
--- gcc/gimplify.c.jj 2020-04-19 12:10:35.700627184 +0200
+++ gcc/gimplify.c 2020-04-21 12:24:41.444307978 +0200
@@ -886,7 +886,11 @@ mostly_copy_tree_r (tree *tp, int *walk_
/* Cop
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71311
Jakub Jelinek changed:
What|Removed |Added
CC||haoxintu at gmail dot com
--- Comment #1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94686
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94672
--- Comment #4 from Jakub Jelinek ---
Sorry for the wrong revision, started really with
r10-3563-g73a28634098cb1aba4a1773e62b6387af120dd9e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94672
--- Comment #5 from Jakub Jelinek ---
Further examples, one for which should be rejected:
subroutine s1 (array)
real, optional :: array(:)
!$omp parallel default(none) ! { dg-error "" }
if (.not.present (array)) stop 1 ! { dg-
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94689
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94689
--- Comment #3 from Jakub Jelinek ---
Guess get_or_create_mem_ref should punt or do something else for pointers to
functions, trying to create an ARRAY_TYPE of FUNCTION_TYPE (or METHOD_TYPE) is
rejected by build_array_type.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93385
--- Comment #32 from Jakub Jelinek ---
For debug stmts when DCE isn't involved, we already seem to do the right thing,
consider -O2 -g:
__attribute__((noinline)) static void
foo (int a)
{
int b = 2 * a;
int c = 3 * a;
a = a + 4;
asm volat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94641
--- Comment #4 from Jakub Jelinek ---
Fixed on the trunk so far.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
Jakub Jelinek changed:
What|Removed |Added
CC||burnus at gcc dot gnu.org
--- Comment #4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93871
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
--- Comment #7 from Jakub Jelinek ---
So, I meant something like:
--- libgfortran/configure.ac.jj 2020-01-24 22:34:36.340641225 +0100
+++ libgfortran/configure.ac2020-04-21 18:03:02.494598615 +0200
@@ -392,6 +392,9 @@ GCC_CHECK_MATH_FUNC([cab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
--- Comment #9 from Jakub Jelinek ---
Created attachment 48326
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48326&action=edit
gcc10-pr94694.patch
Completely untested full patch. Will try to test it on x86_64-linux where it
hopefully sho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
--- Comment #11 from Jakub Jelinek ---
(In reply to Fritz Reese from comment #8)
> I like this solution in principle but we would need to add fabsl, fmal, and
> copysignl, right? And then we are still left with the question: what do we
> do if HA
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94586
Jakub Jelinek changed:
What|Removed |Added
CC||jakub at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
--- Comment #13 from Jakub Jelinek ---
I've missed that. I'm afraid there is no way around missing sinl/cosl/tanl
etc.,
those aren't likely implemented inline by the compiler. The only exception
would be for targets where long double and double
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
--- Comment #14 from Jakub Jelinek ---
(In reply to Jakub Jelinek from comment #13)
> I've missed that. I'm afraid there is no way around missing sinl/cosl/tanl
> etc.,
> those aren't likely implemented inline by the compiler. The only exceptio
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
--- Comment #15 from Jakub Jelinek ---
Thus, I think we can extend the patch I've attached (and fix the two fmaf to
fmal spots), plus do the HAVE_INLINE_BUILTIN_* in configure.ac either through a
config/math.m4 macro, or through a loop over the f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
--- Comment #17 from Jakub Jelinek ---
(In reply to rguent...@suse.de from comment #16)
> Maybe they can be implemented like
>
> long double _gfortran_xyz (long double x)
> {
> __sorry_fortran_intrinsic_xyz_is_not_available_because_cosl_is_not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
--- Comment #19 from Jakub Jelinek ---
Working on it now.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
Jakub Jelinek changed:
What|Removed |Added
Attachment #48326|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94694
--- Comment #22 from Jakub Jelinek ---
I have now bootstrapped/regtested #c20 + #c21 on x86_64-linux and i686-linux
but I see
+FAIL: gfortran.dg/dec_math.f90 -O0 execution test
+FAIL: gfortran.dg/dec_math.f90 -O1 execution test
+FAIL: gfort
Keywords: ABI, wrong-code
Severity: blocker
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: jakub at gcc dot gnu.org
CC: jakub at gcc dot gnu.org, ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94704
Jakub Jelinek changed:
What|Removed |Added
Target Milestone|--- |10.0
CC|
701 - 800 of 42688 matches
Mail list logo
