: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: loximann at gmail dot com
The lower bounds of the result of an allocatable array-valued function are
always set to 1.
Also, I discovered that if LHS is allocated and has the same size as RHS, the
bounds are not changed
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59398
--- Comment #2 from Sergio Losilla loximann at gmail dot com ---
There should be no need to deallocate. From the excerpt you copied: If the
variable is an allocated allocatable variable, it is deallocated if expr is an
array of different shape
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59398
--- Comment #5 from Sergio Losilla loximann at gmail dot com ---
(In reply to Harald Anlauf from comment #3)
OK, so we seem to agree that gfortran is not assigning the correct bounds,
right?
shape(-3:3) == shape (-2:4) == shape(1:7)
Shape
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57145
Bug #: 57145
Summary: [OOP] Faulty Actual argument must be polymorphic
error
Classification: Unclassified
Product: gcc
Version: 4.7.2
Status: UNCONFIRMED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59398
--- Comment #8 from Sergio Losilla loximann at gmail dot com ---
Steve argues that it does not say whether its actual bounds are a
characteristic. If you assume that only the shape matters, then
the gfortran behavior is not a bug. I think
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55960
--- Comment #6 from Sergio Losilla loximann at gmail dot com ---
Well, a very similar case, with a non-abstract type throws an ICE with gfortran
4.8.1:
module Foo_class
type :: Foo
integer :: n
contains
procedure :: n2
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: loximann at gmail dot com
Compiler version: 4.9.0 20130917 (experimental) [trunk revision 202647]
Test program:
program test
real, target :: a(9)=1.
real, pointer :: p
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: loximann at gmail dot com
Compiler version:
GNU Fortran (Ubuntu 20130917-1ubuntu1) 4.9.0 20130917 (experimental) [trunk
revision 202647]
Test program:
program ifelif
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60144
--- Comment #2 from Sergio Losilla loximann at gmail dot com ---
(In reply to kargl from comment #1)
How is the compiler suppose to know that the programmer may have
meant
program ifelif
if (.TRUE.) i = 42
if (.FALSE
: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: loximann at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Created attachment 45012
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45012=edit
Minimum reproducible example
g
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88045
--- Comment #3 from Sergio Losilla ---
I see, thanks. Well then, I guess I'll stick to the workaround. Good to know it
is already fixed in version 9.
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: loximann at gmail dot com
Target Milestone: ---
Created attachment 47833
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47833=edit
Minimal reproducible exam
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96010
--- Comment #2 from Sergio Losilla ---
On a side note: are these bug reports I am sending useful in their current
form? Anything else that I can do to help? (Other than actually fixing them,
because I feel awfully unqualified to even start
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95994
--- Comment #5 from Sergio Losilla ---
Oh my, my apologies about the duplicates. There was an issue with the website,
I was just getting an error back:
--
Software error:
Invalid Content-Type 'subtype' parameter at
ty: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: loximann at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
I hope that the gcov file is self-explanatory:
: normal
Priority: P3
Component: gcov-profile
Assignee: unassigned at gcc dot gnu.org
Reporter: loximann at gmail dot com
CC: marxin at gcc dot gnu.org
Target Milestone: ---
Source code:
#include
#include
#include
int main(int argc, char
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102084
--- Comment #6 from Sergio Losilla ---
Thank you for taking the time in explaining it, appreciated :-)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102084
--- Comment #4 from Sergio Losilla ---
I see, thanks! The second version (constant_ref) which returns the reference to
the captured does not trigger the sanitizer, so returning a reference to that
is valid?
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: loximann at gmail dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org, marxin
++
Assignee: unassigned at gcc dot gnu.org
Reporter: loximann at gmail dot com
Target Milestone: ---
The following program crashes:
--
#include
#include
#include
template
std::function constant(const T&am
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: loximann at gmail dot com
Target Milestone: ---
The following program crashes when built with -static on Fedora 35:
#include
int main(int argc, char *argv[])
{
std::thread foo
21 matches
Mail list logo
