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
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
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?
++
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
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 lookin
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:
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 Bugzi
: 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
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&action=edit
Minimal repro
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.
: 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&action=edit
Minimum repro
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=60144
--- Comment #2 from Sergio Losilla ---
(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.) then
> j = 42
>end if
RMED
Severity: minor
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
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
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55960
--- Comment #6 from Sergio Losilla ---
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 => Foo_n2
procedure
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59398
--- Comment #8 from Sergio Losilla ---
> 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 it is up to the experts
>
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59398
--- Comment #5 from Sergio Losilla ---
(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 is UBOUND-LBOUND+1.
Hm,
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59398
--- Comment #2 from Sergio Losilla ---
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".
For the second, the obtai
: 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.
This
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
21 matches
Mail list logo
