[Bug c/51883] New: Build warning unknown conversion type in gimplify.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51883 Bug #: 51883 Summary: Build warning unknown conversion type in gimplify.c Classification: Unclassified Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: c AssignedTo: unassig...@gcc.gnu.org ReportedBy: mdblac...@yahoo.com ../../gcc-4.6.2/gcc/gimplify.c: In function \u2018omp_notice_threadprivate_variable\u2019: ../../gcc-4.6.2/gcc/gimplify.c:5575: warning: unknown conversion type character \u2018E\u2019 in format ../../gcc-4.6.2/gcc/gimplify.c:5575: warning: too many arguments for format ../../gcc-4.6.2/gcc/gimplify.c: In function \u2018omp_notice_variable\u2019: ../../gcc-4.6.2/gcc/gimplify.c:5636: warning: unknown conversion type character \u2018E\u2019 in format ../../gcc-4.6.2/gcc/gimplify.c:5636: warning: too many arguments for format ../../gcc-4.6.2/gcc/gimplify.c: In function \u2018omp_is_private\u2019: ../../gcc-4.6.2/gcc/gimplify.c:5746: warning: unknown conversion type character \u2018E\u2019 in format ../../gcc-4.6.2/gcc/gimplify.c:5746: warning: too many arguments for format ../../gcc-4.6.2/gcc/gimplify.c:5760: warning: unknown conversion type character \u2018E\u2019 in format ../../gcc-4.6.2/gcc/gimplify.c:5760: warning: too many arguments for format ../../gcc-4.6.2/gcc/gimplify.c:5763: warning: unknown conversion type character \u2018E\u2019 in format ../../gcc-4.6.2/gcc/gimplify.c:5763: warning: too many arguments for format ../../gcc-4.6.2/gcc/gimplify.c: In function \u2018gimplify_scan_omp_clauses\u2019: ../../gcc-4.6.2/gcc/gimplify.c:5926: warning: unknown conversion type character \u2018E\u2019 in format ../../gcc-4.6.2/gcc/gimplify.c:5926: warning: too many arguments for format
[Bug c/51883] Build warning unknown conversion type in gimplify.c
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51883 --- Comment #2 from mdblack98 at yahoo dot com 2012-01-17 17:13:20 UTC --- I should have realized that. Indeed those warning don't show up in later stages. Sorry for the noise. -Original Message- From: manu at gcc dot gnu.org [mailto:gcc-bugzi...@gcc.gnu.org] Sent: Tuesday, January 17, 2012 10:13 AM To: mdblac...@yahoo.com Subject: [Bug c/51883] Build warning unknown conversion type in gimplify.c http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51883 Manuel López-Ibáñez changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED CC||manu at gcc dot gnu.org Resolution||INVALID --- Comment #1 from Manuel López-Ibáñez 2012-01-17 16:12:55 UTC --- GCC is built in stages. The first stage uses the system compiler, which may have bugs or not handle special conversion type characters handled by the GCC version being built (this particular warning). Therefore, warnings produced by the system compiler are often wrong. Please, do not report them. http://gcc.gnu.org/wiki/FAQ#stage1warnings It would be nice to NOT produce any warning during stage 1, but I guess people are happy enough just ignoring them to not bother sending a patch to fix the build scripts. The build system of GCC is a huge complex mess, so one needs a very good reason to play games with it.
[Bug c/89373] New: macro expansion not counting braces correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89373
Bug ID: 89373
Summary: macro expansion not counting braces correctly
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mdblack98 at yahoo dot com
Target Milestone: ---
include
#define MYMACRO1(m) MYLIST;
#define MYMACRO(r,m) \
MYMACRO##r(m)
#define MYLIST {1,2,3,4,5}
// too many args -- does not allow for braces such as used for array
initialization
int ii[32] = MYMACRO(1,{1,2,3,4,5});
// too many args -- does not allow for braces such as used for array
initialization
int jj[32] = MYMACRO(1,MYLIST);
// this works
int kk[32] = MYLIST;
int
main()
{
// all 3 of these should print 1,2,3,4,5
for(int i=0;i<5;++i) printf("ii %d,%d\n",i,ii[i]);
for(int i=0;i<5;++i) printf("jj %d,%d\n",i,jj[i]);
for(int i=0;i<5;++i) printf("kk %d,%d\n",i,kk[i]);
return 0;
}
[Bug preprocessor/89373] macro expansion not counting braces correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89373
mdblack98 at yahoo dot com changed:
What|Removed |Added
Status|RESOLVED|UNCONFIRMED
Resolution|INVALID |---
--- Comment #2 from mdblack98 at yahoo dot com ---
So how does one get this to compile then..Can't seem to find any combination of
parentheses that works. I'm converting an entry in the hamlib project to an
array and that's what is causing this problem with static initialization of the
array.
x3.c:10:26: error: braced-group within expression allowed only inside a
function
FRQ_RNG_160m_REGION##r((m), (lp), (hp), (v), (a))
^
x3.c:6:25: note: in definition of macro ‘FRQ_RNG_160m_REGION1’
{ 1810, 2, (md), (lp), (hp), (v), (a) }
^~
x3.c:21:20: note: in expansion of macro ‘FRQ_RNG_HF’
struct foo myfoo = FRQ_RNG_HF(1, MYLIST, 5,100,1,1);
^~
#include
#define MYLIST {1,2,3,4,5}
#define FRQ_RNG_160m_REGION1(md,lp,hp,v,a) \
{ 1810, 2, (md), (lp), (hp), (v), (a) }
#define FRQ_RNG_HF(r,m,lp,hp,v,a) \
FRQ_RNG_160m_REGION##r((m), (lp), (hp), (v), (a))
struct foo {
int i1;
int i2[64];
int i3;
int i4;
int i5;
int i6;
};
struct foo myfoo = FRQ_RNG_HF(1, MYLIST, 5,100,1,1);
int
main()
{
for(int i=0;i<5;++i) printf("kk %d,%d\n",i,myfoo.i2[i]);
return 0;
}
[Bug c/89380] New: Multiple items in brace not working on nested macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89380
Bug ID: 89380
Summary: Multiple items in brace not working on nested macro
Product: gcc
Version: 8.2.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: mdblack98 at yahoo dot com
Target Milestone: ---
Additional report from bug#89373
#include
// To see the bug
// gcc -DBUG -c x3.c
// Single item in braces is OK
// Multiple items in braces not OK
#ifdef BUG
#define MYLIST {1,2}
#else
#define MYLIST {1}
#endif
#define FRQ_RNG_160m_REGION1(md,lp,hp,v,a) \
{ 1810, 2, md, (lp), (hp), (v), (a) }
#define FRQ_RNG_HF(r,m,lp,hp,v,a) \
FRQ_RNG_160m_REGION##r(m, (lp), (hp), (v), (a))
struct foo {
int band;
int region;
int md[4];
int lp;
int hp;
int v;
int a;
};
struct foo myfoo = { 1,2, MYLIST,4,5,6,7 };
struct foo myfoo2 = FRQ_RNG_HF(1, MYLIST, 5,100,1,1);
int
main()
{
for(int i=0;i<4;++i) printf("kk %d,%d\n",i,myfoo.md[i]);
return 0;
}
[Bug preprocessor/89380] Multiple items in brace not working on nested macro
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89380 --- Comment #5 from mdblack98 at yahoo dot com --- Why can't it be fixed by not counting commas between braces? That seems to be the problem.
[Bug preprocessor/89373] macro expansion not counting braces correctly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89373 --- Comment #4 from mdblack98 at yahoo dot com --- FYI...the variadic macro __VA_ARGS__ did solve the braced items problem on array initialization in nested macros. Just have to move the argument to the end of the macro... Thanks Mike
[Bug fortran/84885] New: c_char bind length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84885 Bug ID: 84885 Summary: c_char bind length Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mdblack98 at yahoo dot com Target Milestone: --- subroutine foo(i,c) use, intrinsic :: iso_c_binding, only: c_char integer i type, bind(C) :: params_block character(kind=c_char,len=10) :: c end type params_block write(*,*) 'X',c,'Z' end This program fails to compile with gcc 8.0.1 20180304 -- but only if the character declaration is inside a type block Compiles fine with pre 8.0 compilers gfortran -fPIC -g -c foo.f90 foo.f90:6:42: character(kind=c_char,len=10) :: c 1 Error: Component 'c' of BIND(C) type at (1) must have length one Mike
[Bug fortran/84885] c_char bind length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84885 --- Comment #2 from mdblack98 at yahoo dot com --- I got what's below from Steve Lionel of the FORTRAN working groupWith what he said you flat should NOT be able to say anything other than LEN=1 for c_char. Whether it's in a type block or not.So the question becomes how to do this...since this is likely to break a bit of FORTRAN code out in the wild...like oursIt would appear you can't put a char array of any kind of type block which we use for shared memory. From Steve: However, I don't see that Fortran 2018 has anything to do with this. The code you show does not conform to Fortran 2003, which was the first revision to have C interoperability. The issue is that in an interoperable type (a type declared with BIND(C)), any entity of type CHARACTER must have length 1, because C doesn't have the concept of character lengths. Instead you would make c here a 10-element array of single characters. It's ok outside of the type because you're not declaring something interoperable then. Similarly, a dummy argument to an interoperable procedure can't have a character length other than 1 up through Fortran 2008. In Fortran 2018, you're allowed to use CHARACTER(*), but that requires that the corresponding C code pass or accept a "C descriptor". That earlier versions of gcc allowed this to compile would be a bug in those older versions. --- Michael D. Black On Thursday, March 15, 2018, 11:42:40 AM CDT, kargl at gcc dot gnu.org wrote: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84885 kargl at gcc dot gnu.org changed: What |Removed |Added Status|UNCONFIRMED |RESOLVED CC| |kargl at gcc dot gnu.org Resolution|--- |INVALID --- Comment #1 from kargl at gcc dot gnu.org --- (In reply to mdblack98 from comment #0) > subroutine foo(i,c) > use, intrinsic :: iso_c_binding, only: c_char > integer i > > type, bind(C) :: params_block > character(kind=c_char,len=10) :: c I see length of 10 here. > end type params_block > write(*,*) 'X',c,'Z' > end > > This program fails to compile with gcc 8.0.1 20180304 -- but only if the > character declaration is inside a type block > Compiles fine with pre 8.0 compilers > > gfortran -fPIC -g -c foo.f90 > foo.f90:6:42: > > character(kind=c_char,len=10) :: c > 1 > Error: Component 'c' of BIND(C) type at (1) must have length one From the F2018 standard, 18.3.2 Interoperability of intrinsic types Table 18.2 shows the interoperability between Fortran intrinsic types and C types. A Fortran intrinsic type with particular type parameter values is interoperable with a C type if the type and kind type parameter value are listed in the table on the same row as that C type. If the type is character, the length type parameter is interoperable if and only if its value is one. C1806 (R726) Each component of a derived type with the BIND attribute shall be a nonpointer, nonallocatable data component with interoperable type and type parameters. Your code is invalid, and the number constraint means that gfortran must tell you about it.
[Bug fortran/84885] c_char bind length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84885 --- Comment #3 from mdblack98 at yahoo dot com --- I'll correct my reply in that using len > 1 outside of an interoperability block is OK. So it is apparently now impossible to declare c_char len > 1 inside such a block? Mike
[Bug fortran/84885] c_char bind length
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84885
--- Comment #5 from mdblack98 at yahoo dot com ---
I've been using Fortran since 1980 so caps is natural to me :-)
My concern is that if gfortran has supported the len>1 convention for many
years than perhaps it should continue supporting it to prevent breaking code
like ours which will take some major effort to rewrite.Consider it an
"extension" to gfortran which apparently it was. Still fully 2018 compliant
with this one little extension. Enable it via a switch if you want to.
Making it a char array of 10 does not solve the problem as it doesn't behave
the same. Maybe it should behave the same?
Here's my test Both gcc-7 and gcc-8 work fine without the "type" block. So
comment out the type and end type lines and you get the correct output.But
including the type block causes both gcc-7 and gcc-8 to print out a floating
point number instead of the char string. So the data type when inside the type
block is different than when it's outside the type block? Or is there some
logical difference between len=1 c(10) and len=10 c?
#include
#include
void foo_(int *i,char *c,int);
int main()
{
int i=123;
char c[11];
sprintf(c,"%s","1234567890");
foo_(&i,c,strlen(c));
return 0;
}
subroutine foo(i,c)
use, intrinsic :: iso_c_binding, only: c_int,c_char,c_long
type, bind(C):: params_block
integer(c_int) :: i
character(kind=c_char,len=1) :: c(10)
end type params_block
write(*,*) 'Testing'
write(*,*) i
write(*,*) c
end
Mike
On Thursday, March 15, 2018, 5:58:21 PM CDT, sgk at troutmask dot
apl.washington.edu wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84885
--- Comment #4 from Steve Kargl ---
On Thu, Mar 15, 2018 at 09:57:08PM +0000, mdblack98 at yahoo dot com wrote:
>
> --- Comment #3 from mdblack98 at yahoo dot com ---
> I'll correct my reply in that using len > 1 outside of an interoperability
> block is OK.
>
> So it is apparently now impossible to declare c_char len > 1 inside such a
> block?
>
Steve Lionel is correct. If you have a BIND(C) entity
and it involves the character type, then the length
parameter must be 1. I quoted from a draft of the
upcoming F2018, because that is what I had at hand. The
Fortran 2003 standard has essentially the same language:
F2003, page 398
A Fortran derived type is interoperable with a C
struct type if the derived-type definition of the Fortran
type specifies BIND(C) (4.5.1), the Fortran derived type
and the C struct type have the same number of components,
and the components of the Fortran derived type have types
and type parameters that are interoperable with the types
of the corresponding components of the struct type.
Fortran 2003, page 396
...; if the type is character, interoperability also requires
that the length type parameter be omitted or be specified
by an initialization expression whose value is one.
You can specify an array of characters, e.g.,
type, bind(c) :: foo
character(kind=c_char, len=1) :: c(10)
end type foo
PS: The name of the language is Fortran. It hasn't been
written in all capital letters since 1990.
