https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102619
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99798
Mikael Morin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114922
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
--- Comment #4 from Mikael Morin ---
For what's worth adding -fno-tree-vrp "fixes" this and enables removal of the
call to 'foo' with trunk.
Here is a minimal revert of the regressing revision, but it may just make the
problem latent.
diff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111293
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
Mikael Morin changed:
What|Removed |Added
Assignee|mikael at gcc dot gnu.org |unassigned at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114475
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426
Mikael Morin changed:
What|Removed |Added
Status|NEW |ASSIGNED
--- Comment #10 from Mikael
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114475
Mikael Morin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103472
Mikael Morin changed:
What|Removed |Added
Known to work||14.0
Known to fail|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547
Mikael Morin changed:
What|Removed |Added
Status|UNCONFIRMED |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547
--- Comment #2 from Mikael Morin ---
Created attachment 57739
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57739=edit
Patch fixing the problem
This small patch fixes the problem.
Unfortunately allowing more errors seems
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #9 from Mikael Morin ---
(In reply to anlauf from comment #8)
> (In reply to Mikael Morin from comment #7)
> > FAIL: gfortran.dg/pr98016.f90 -O (test for excess errors)
> > Excess errors:
> >
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #7 from Mikael Morin ---
(In reply to Mikael Morin from comment #6)
> I need to reevaluate it; there were other regressions if I remember
> correctly.
The changes are these:
PASS->FAIL: gfortran.dg/graphite/pr107865.f90 -O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #6 from Mikael Morin ---
Created attachment 57571
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57571=edit
Tentative patch
(In reply to anlauf from comment #5)
> (In reply to anlauf from comment #4)
> > Thus I suggest to fix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
--- Comment #6 from Mikael Morin ---
(In reply to kargl from comment #5)
> (In reply to Mikael Morin from comment #4)
>
> > (In reply to kargl from comment #3)
> > > Yep, agreed. I went back an re-read the section about ASSOCIATE.
> > > Not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799
Mikael Morin changed:
What|Removed |Added
Known to fail||10.5.0, 11.4.0, 12.3.0,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113799
Mikael Morin changed:
What|Removed |Added
Ever confirmed|0 |1
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656
Bug 86656 depends on bug 111291, which changed state.
Bug 111291 Summary: ASAN error: heap-use-after-free gcc/fortran/parse.cc:359 in
decode_statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111291
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111291
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113377
--- Comment #6 from Mikael Morin ---
(In reply to anlauf from comment #4)
>
> Note that the following scalar example also fails:
>
"Fortunately", it is invalid. :-)
>From 15.5.2.12 (Argument presence and restrictions on arguments not
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113377
--- Comment #5 from Mikael Morin ---
(In reply to anlauf from comment #2)
> Note that adding a scalar call in function one:
>
> r(1) = two (i(1), j)
>
> generates sane code:
>
> *((integer(kind=4) *) __result.0 + (sizetype) ((offset.1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=46244
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|NEW
Assignee|mikael at gcc dot
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113377
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111291
Mikael Morin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113152
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
Mikael Morin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112412
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112412
Mikael Morin changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
Mikael Morin changed:
What|Removed |Added
Status|UNCONFIRMED |ASSIGNED
Ever confirmed|0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112412
Bug ID: 112412
Summary: Masked reduction functions return an unallocated array
when the result is empty
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
--- Comment #3 from Mikael Morin ---
Possible culprit:
ifunction.m4 has this code:
retarray->base_addr = xmallocarray (alloc_size, sizeof (rtype_name));
if (alloc_size == 0)
{
/* Make sure we have a zero-sized
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
--- Comment #2 from Mikael Morin ---
If dim == 3, the ubound and shape are (/ 9, 3, 7 /) as expected.
That is, the problem only arises if the resulting array is empty.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
--- Comment #1 from Mikael Morin ---
(In reply to Mikael Morin from comment #0)
> i = 1
> (...)
> r = sum(a, dim=i)
If i is inlined, that is
r = sum(a, dim=1)
the shape and ubound are (/ 3, 0, 7 /) as expected.
The difference is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112371
Bug ID: 112371
Summary: Wrong upper bound for the result of reduction
intrinsics if the array is empty
Product: gcc
Version: 14.0
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
Mikael Morin changed:
What|Removed |Added
Attachment #56094|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
--- Comment #3 from Mikael Morin ---
I'm trying to remove the formal_arg_flag global variables, which seem to just
disable all the checks on dummy arguments.
Unfortunately, it regresses a bit, say pr101026.f for example can be simplified
to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
Mikael Morin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #13 from Mikael Morin ---
(In reply to Tamar Christina from comment #12)
> (In reply to Mikael Morin from comment #11)
> > Created attachment 56094 [details]
> > Improved patch
> >
> > This improved patch (still single argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
Mikael Morin changed:
What|Removed |Added
Attachment #56091|0 |1
is obsolete|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111781
Mikael Morin changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #10 from Mikael Morin ---
(In reply to Mikael Morin from comment #8)
> (...) that is it was using too loops in a row in some cases.
>
... *two* loops in a row ...
(In reply to Tamar Christina from comment #9)
>
> Thanks Mikael!
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90608
--- Comment #8 from Mikael Morin ---
Created attachment 56091
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56091=edit
Rough patch
Here is a rough patch to make the scalarizer support minloc calls.
It regresses on minloc_1.f90 at least,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107716
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996
Mikael Morin changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957
Mikael Morin changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106050
Mikael Morin changed:
What|Removed |Added
Target Milestone|--- |14.0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106050
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111339
Bug ID: 111339
Summary: bounds-check does not detect nonconforming functions
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Severity: enhancement
Priority: P3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957
Mikael Morin changed:
What|Removed |Added
Last reconfirmed||2023-09-08
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89891
Bug 89891 depends on bug 48776, which changed state.
Bug 48776 Summary: ICE(segfault) after -std=f95 diagnostic error involving
PROCEDURE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
What|Removed |Added
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
Mikael Morin changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107923
Mikael Morin changed:
What|Removed |Added
Resolution|--- |DUPLICATE
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
Mikael Morin changed:
What|Removed |Added
CC||gs...@t-online.de
--- Comment #10 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996
Mikael Morin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
Mikael Morin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
--- Comment #7 from Mikael Morin ---
(In reply to Mikael Morin from comment #6)
> Can't reproduce with a recent master (14.0.0 20230814).
Sorry, missed the -std=f95 flag.
Confirmed on recent master.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48776
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86657
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68152
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996
--- Comment #8 from Mikael Morin ---
(In reply to JuzheZhong from comment #7)
> Do you have a solution that we can fix RISC-V backend?
No, this is not RISC-V specific.
> Or you will fix it in Fortran front-end?
Yes, the fix will have to be
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996
--- Comment #6 from Mikael Morin ---
(In reply to Mikael Morin from comment #5)
> Here sym->formal_ns is NULL because the symbol C has not been completely
> setup.
This makes the following an "obvious" fix:
diff --git a/gcc/fortran/decl.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110996
Mikael Morin changed:
What|Removed |Added
Ever confirmed|0 |1
Status|UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #42 from Mikael Morin ---
(In reply to anlauf from comment #41)
> (In reply to Mikael Morin from comment #40)
> > Harald, I have just closed the followup PR110419.
> > I think this PR can be closed as well, or is there something
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #40 from Mikael Morin ---
Harald, I have just closed the followup PR110419.
I think this PR can be closed as well, or is there something left to be done?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
Mikael Morin changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #18 from Mikael Morin ---
Created attachment 55662
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55662=edit
Updated tentative patch
This fixes comment #4 as well, but the failure on value_9 remains on 32 bit
powerpc.
It is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #17 from Mikael Morin ---
Created attachment 55660
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55660=edit
Update function type patch
This patch changes the dummy argument declaration type.
It changes the dump as follows.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87142
Bug 87142 depends on bug 110618, which changed state.
Bug 110618 Summary: Dependency between arguments when one is allocatable array
whose dummy is intent(out)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618
What|Removed
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618
Mikael Morin changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #15 from Mikael Morin ---
rs6000_pass_by_reference returns true with -m32, and false with -m64.
So the second argument is passed by reference with -m32, and by value with
-m64.
So the code in val looks right, it is the code in p
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92178
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618
Mikael Morin changed:
What|Removed |Added
Last reconfirmed||2023-07-13
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99798
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106050
Mikael Morin changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618
--- Comment #1 from Mikael Morin ---
Created attachment 55517
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55517=edit
Draft patch
This seems to work for this case, but I'm not sure how reliable it is.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618
Bug ID: 110618
Summary: Dependency between arguments when one is allocatable
array whose dummy is intent(out)
Product: gcc
Version: 11.4.1
Status: UNCONFIRMED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106050
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #14 from Mikael Morin ---
The tree optimized dumps are almost the same for 32 and 64 bits.
The expand dumps show more significant differences.
The 64 bits dump shows the register r4 is saved to memory with:
(insn 3 2 4 2 (set
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #13 from Mikael Morin ---
Created attachment 55488
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55488=edit
-m64 rtl final dump at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #12 from Mikael Morin ---
Created attachment 55487
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55487=edit
-m64 rtl expand dump at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #11 from Mikael Morin ---
Created attachment 55486
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55486=edit
-m64tree optimized (at -O0) dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #10 from Mikael Morin ---
The three previous dumps are generated with the example in comment #4.
The problem seems to turn around the val function needing to take the address
of the c argument, which is passed by value.
On powerpc,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #9 from Mikael Morin ---
Created attachment 55480
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55480=edit
-m32 final rtl dump at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #8 from Mikael Morin ---
Created attachment 55479
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55479=edit
-m32 rtl exand dump at -O0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #7 from Mikael Morin ---
Created attachment 55478
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55478=edit
-m32 tree optimized (at -O0) dump
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #6 from Mikael Morin ---
I finally got my access on gcc110 working.
(gdb) r
Starting program: /home/mmorin/gcc-pr110360/pr110360/pr110419_comment4
Program received signal SIGSEGV, Segmentation fault.
0x1684 in val (x=...,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
--- Comment #2 from Mikael Morin ---
(In reply to Mikael Morin from comment #1)
> Harald committed an additional fix to the PR:
>
Unfortunately, the failure on big endian power remains.
Is the execution output the same as before?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110419
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #23 from Mikael Morin ---
(In reply to anlauf from comment #22)
> Created attachment 55418 [details]
> Slighty revised version of 3rd patch
>
> I've looked at gfc_conv_string_parameter, which I was not aware of.
> This can be used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #21 from Mikael Morin ---
(In reply to anlauf from comment #20)
> Created attachment 55407 [details]
> Third patch set
>
> Here's a lightly tested 3rd patch that tries to handle the chaos I created...
>
> Can you have a look?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #19 from Mikael Morin ---
(In reply to Mikael Morin from comment #18)
> There is the "obvious" problem that gfc_build_wide_string_const creates a
> bare array, whereas gfc_string_to_single_character expects a pointer
> wrapping
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110360
--- Comment #18 from Mikael Morin ---
(In reply to Mikael Morin from comment #15)
> I have asked for an account on the compile farm (see
> https://gcc.gnu.org/wiki/CompileFarm) to have access to a powerpc machine.
It was pretty fast to get the
1 - 100 of 225 matches
Mail list logo
