Hi Tobias and Harald,
I sincerely apologize for the breakage! I did test both preprocessor branches,
but I tested against the same MPFR version (4.2.2, which is the latest on Arch
Linux). Going forward, I will test against versions both above and below 4.2.0
to ensure this type of breakage doesn't
Hi Harald,
Harald Anlauf wrote:
This breaks bootstrap here on openSUSE Leap 15.6 with mpfr-4.0.2:
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_expr*
gfc_simplify_cospi(gfc_expr*)':
../../gcc-trunk/gcc/fortran/simplify.cc:2305:3: error: 'mpfr_fmod_ui'
was not declared in this scop
On 5/28/25 19:51, Tobias Burnus wrote:
Hi Yuao,
Yuao Ma wrote:
[…]
Done.
LGTM :-) I have now applied it as r16-938-ge8fdd55ec90749.
Thanks for the patch!
Tobias
This breaks bootstrap here on openSUSE Leap 15.6 with mpfr-4.0.2:
../../gcc-trunk/gcc/fortran/simplify.cc: In function 'gfc_e
Hi Yuao,
Yuao Ma wrote:
[…]
Done.
LGTM :-) I have now applied it as r16-938-ge8fdd55ec90749.
Thanks for the patch!
Tobias
Hi Tobias,
> you will notice that the PR is not recognized. The format as mentioned before
> is "PR component/number". Namely:
Thanks for the reminder! I'll use `-p` to double-check PR numbers going
forward.
> The second part is not what you are doing, you are actually changing the
> call from
Yuao Ma wrote:
PR113152
If you run your patch through
./contrib/gcc-changelog/git_email.py
0001-fortran-add-constant-input-support-for-trig-function.patch
you will notice that the PR is not recognized. The format as mentioned before is "PR
component/number". Namely:
"PR fortran/113
On Tue, May 27, 2025 at 02:17:46PM +, Yuao Ma wrote:
>
> I've reverted the recent format changes, as three reviewers indicated they
> caused more harm than good.
>
Thank you.
> Are there any functional problems I need to address?
I did not see any additional functional issues. Patch is
OK
Hi all,
I've reverted the recent format changes, as three reviewers indicated they
caused more harm than good.
Are there any functional problems I need to address?
Thanks,
Yuao
0001-fortran-add-constant-input-support-for-trig-function.patch
Description: 0001-fortran-add-constant-input-support
Am 26.05.25 um 18:36 schrieb Steve Kargl:
On Mon, May 26, 2025 at 09:30:59AM +, Yuao Ma wrote:
Hi Steve,
I looked at the patch in a bit more detail, and
I am not thrilled with large-scale whitespace
changes mingled with functional changes. It makes
the patch harder to read and review.
I'
On Mon, May 26, 2025 at 09:30:59AM +, Yuao Ma wrote:
> Hi Steve,
>
> > I looked at the patch in a bit more detail, and
> > I am not thrilled with large-scale whitespace
> > changes mingled with functional changes. It makes
> > the patch harder to read and review.
>
> I'm not sure which file y
Hi Steve,
> I looked at the patch in a bit more detail, and
> I am not thrilled with large-scale whitespace
> changes mingled with functional changes. It makes
> the patch harder to read and review.
I'm not sure which file you're referring to.
If it's mathbuiltins.def, I'll need to add extra spa
On Sun, May 25, 2025 at 04:56:48AM +, Yuao Ma wrote:
>
> Thanks for your review! I've updated the patch.
>
> > this range_check() is unneeded.
>
> Done.
>
> > As a side note, the error message is slightly misleading
> > (although it will not be issued). Technically, x = -1 or 1
> > are all
Hi Steve,
Thanks for your review! I've updated the patch.
> this range_check() is unneeded.
Done.
> As a side note, the error message is slightly misleading
> (although it will not be issued). Technically, x = -1 or 1
> are allowed values, and neither is **between** -1 and 1.
You're right, th
Apologies for late a late reply. A quick skim of the code
suggests that you can eliminate some of the range_check()
calls in the simplifications. For example, you have
+gfc_expr *
+gfc_simplify_acospi (gfc_expr *x)
+{
+ gfc_expr *result;
+
+ if (x->expr_type != EXPR_CONSTANT)
+return NULL;
Hi Tobias,
The patch has been updated. Could you please take a look when you have a
chance?
> Can you add the PR number to the commit log ("PR fortran/113152")?
Done.
> Can you also update the documentation – as you already did for ATAND?
I think that's quite a lot of wording... Hoping to tack
Hi,
Yuao Ma wrote:
I'm pretty swamped for the next couple of days
Same issue here - hence, I haven't completed the review ...
You're absolutely right that the best way to keep changes minimal is to just
rename the `*resolve*` function.
I missed the
-gfc_resolve_trigd,
+gfc_resolve_trig,
c
Hi Tobias,
Thanks for the thorough code review! I'm pretty swamped for the next couple of
days, and I'll get the patch updated as you requested this weekend.
> I don't understand this change. First, I don't see any reason why this
> should get modified. And by modifying it, a simple "git blame" w
Hi Yuao,
first comments, I still need to look again at some changes, especially
at simplify.cc.
Yuao Ma wrote:
This patch introduces constant input support for trigonometric functions,
including those involving half-revolutions. Both valid and invalid
inputs have
been thoroughly tested, as
] fortran: add constant input support for trig functions with
half-revolutions
Hi all,
This patch introduces constant input support for trigonometric functions,
including those involving half-revolutions. Both valid and invalid inputs have
been thoroughly tested, as have mpfr versions greater than or
Hi all,
This patch introduces constant input support for trigonometric functions,
including those involving half-revolutions. Both valid and invalid inputs have
been thoroughly tested, as have mpfr versions greater than or equal to 4.2 and
less than 4.2.
Inspired by Steve's previous work, this pa
20 matches
Mail list logo
