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: no
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: unknown
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: UNCONFIR
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54822
--- Comment #2 from Roger Ferrer Ibanez 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. I tried also with Intel F
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
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=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 2012-07-03
08:28:59 UTC ---
A similar problem happens when template-type parameters are involved.
// -- test2.cc
template
struct A { };
template
void g2()
{
const int M ( sizeof(Q) );
A a;
}
v
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
: 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
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65825
--- Comment #2 from Roger Ferrer Ibanez ---
> 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 by chance.
Kind regards,
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 a
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(:) >
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 this
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
: 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 "poly8x8_t
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
for
: 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 =
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 diagn
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&action=edit
Small reproducer
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
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 ---
Created attachment 34055
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34055&action=edit
Small testcase
: 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 gene
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64358
--- Comment #2 from Roger Ferrer Ibanez ---
(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
>
> https://gcc.gnu.org/ml/gcc-
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58734
--- Comment #2 from Roger Ferrer Ibanez ---
Hi,
g++ 4.9.1. does not fail anymore with this one.
I guess it was already been fixed.
Kind regards,
++
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
struct B { };
template
struct A
{
private:
template
static B bar();
public
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63378
--- Comment #1 from Roger Ferrer Ibanez ---
Created attachment 33578
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33578&action=edit
Testcase
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=36250&action=edit
Small testcase
Hi,
the following
31 matches
Mail list logo
