https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68370
--- Comment #3 from Roger Ferrer Ibanez ---
Created attachment 36729
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=36729=edit
Small reproducer
Priority: P3
Component: jit
Assignee: dmalcolm at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Target Milestone: ---
Hi,
maybe I'm doing something wrong, but libgccjit rejects an assignment of pointer
arithmetic where the types (according to the diagnostic
: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Target Milestone: ---
Hi,
GCC 6.0.0 20151025 and 5.2 crash with an ICE with the following code:
-- ice.cc
constexpr char c[] = "hello";
constexpr const char *p =
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67896
--- Comment #1 from Roger Ferrer Ibanez ---
Hi,
after some debugging I think I understand what happens but I'm not sure I can
provide an acceptable fix for that.
When comparing __Poly8x8_t and __Poly16x8_t types (these are the builtin types
: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Target Milestone: ---
Target: aarch64-linux-gnu
Hi,
aarch64-linux-gnu-gcc is able to distinguish Neon poly types "poly
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Target Milestone: ---
Hi,
this was discovered by accident.
g++ 5.2.0 accepts this
namespace N
{
int x;
}
void f(void)
{
_ZN1N1xE = 1; // somehow
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67746
--- Comment #2 from Roger Ferrer Ibanez ---
(In reply to Jonathan Wakely from comment #1)
> Your examples are undefined due to the use of reserved names, and the
> libstdc++ implementation actually relies on this in places, so I think
> changing
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Target Milestone: ---
Created attachment 36250
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=36250action=edit
Small testcase
Hi,
the following snippet
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65825
--- Comment #2 from Roger Ferrer Ibanez roger.ferrer at bsc dot es ---
Well, if so, why are you do you want to declare ubound as intrinsic besides
pushing gfortran to its limit?
I did not intend to push gfortran anywhere. It actually happened
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Hi,
a problem similar to PR57141 happens with the code below.
Fails both with gfortran 4.9.2 and 5.0.1 20150412 (prerelease).
Both Intel Fortran 14.0.2 and XL Fortran 15.01 accept this code (both print 3
: target
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Hi,
I'm observing a weird behaviour in PowerPC64 Little Endian that does not seem
to occur on other architectures supporting __int128. The following code, when
compiled with -O1 generates
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64358
--- Comment #2 from Roger Ferrer Ibanez roger.ferrer at bsc dot es ---
(In reply to Pat Haugen from comment #1)
This occurs on powerpc64 Big Endian too and is fixed by a patch I just
submitted yesterday. Talk about timing...
Fantastic
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Hi,
during an initialization of an array of unknown bound of
non-dependent type using a braced initializer which contains
type-dependent expressions, g++ does
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64002
--- Comment #1 from Roger Ferrer Ibanez roger.ferrer at bsc dot es ---
Created attachment 34055
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=34055action=edit
Small testcase
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Hi,
(I guess this is related to PR34657)
The following snippet is accepted by gfortran
-- test-ok.f90
MODULE MOO
INTEGER :: S
END MODULE MOO
SUBROUTINE S1
USE MOO, ONLY: X = S, X = S
X = 1
++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Hi,
the following testcase fails to compile with g++ 4.9.1 and 5.0.0 (20140925).
-- test.cc
template typename T1, typename S1
struct B { };
template typename T1
struct A
{
private:
template typename
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63378
--- Comment #1 from Roger Ferrer Ibanez roger.ferrer at bsc dot es ---
Created attachment 33578
-- https://gcc.gnu.org/bugzilla/attachment.cgi?id=33578action=edit
Testcase
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58734
--- Comment #2 from Roger Ferrer Ibanez roger.ferrer at bsc dot es ---
Hi,
g++ 4.9.1. does not fail anymore with this one.
I guess it was already been fixed.
Kind regards,
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Hi,
the snippet below causes an access error in g++ 4.9.1 if the
conversion-function-id is referenced in a class-member access.
Intel C++ 14.0.2 and clang
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Hi,
the following code
! -- test.f90
subroutine foo(a, b)
implicit none
integer, dimension(:), intent(inout) :: a
integer, dimension(:), intent(in) :: b
where (b(:) 0
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Hi,
a using-declarator the nested-name of which includes an enumerator-name fails,
as g++ seems to expect only namespace-names at this point.
This seems
: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
Hi,
g++ allows declarations to hide a template-parameter name in template member
functions defined inside the class
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: roger.ferrer at bsc dot es
In the snippet below, a weird interaction happens between two overloaded friend
declarations and a class member access using a qualified id-expression.
// -- test.cc
class A
{
protected
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57141
Bug #: 57141
Summary: Cannot change attributes of USE-associated intrinsic
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54822
Bug #: 54822
Summary: OpenMP - Firstprivate optional dummy arguments crash
if not present
Classification: Unclassified
Product: gcc
Version: unknown
Status:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54822
--- Comment #2 from Roger Ferrer Ibanez roger.ferrer at bsc dot es 2012-10-05
09:53:36 UTC ---
The OpenMP standard says that the firstprivate private copy of the var is
initialized (for non-pointers) using intrinsic assignment,
Oops
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54223
Bug #: 54223
Summary: Statement function statement with dummy arguments that
are also OPTIONAL may crash in wrong calls
Classification: Unclassified
Product: gcc
Version:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53836
Bug #: 53836
Summary: ICE: unexpected expression of kind template_parm_index
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53836
--- Comment #1 from Roger Ferrer Ibanez roger.ferrer at bsc dot es 2012-07-03
08:28:59 UTC ---
A similar problem happens when template-type parameters are involved.
// -- test2.cc
template int N
struct A { };
template typename Q
void g2
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52452
Bug #: 52452
Summary: INTRINSIC cannot be applied to gfortran's ETIME
Classification: Unclassified
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47359
Summary: Recursive functions of intrinsic names generates
invalid assembler
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
31 matches
Mail list logo
