Sorry for my mistake. I'll send the message to the appropriate mailing list.
Americo
On Fri, Apr 24, 2009 at 12:31 AM, Ian Lance Taylor wrote:
> Americo Barbosa da Cunha Junior writes:
>
>> I'm calling a FORTRAN subroutine in a ANSI C program. The subroutine
>> has the following prototype:
>
Americo Barbosa da Cunha Junior writes:
> I'm calling a FORTRAN subroutine in a ANSI C program. The subroutine
> has the following prototype:
This message is not appropriate for the mailing list gcc@gcc.gnu.org,
which is for gcc developers. This question would have been appropriate
on gcc-h...
gcc-4.4.0.tar.gz.sig was generated with an expired key:
gpg: Signature made Tue 21 Apr 2009 07:35:29 AM PDT using DSA key ID C3C45C06
gpg: Good signature from "Jakub Jelinek "
gpg: Note: This key has expired!
Primary key fingerprint: 33C2 35A3 4C46 AA3F FB29 3709 A328 C3A2 C3C4 5C06
I'm using ft
Joe Buck writes:
> The compiler is not supposed to be pedantic by default. A standards
> document saying that a diagnostic is required should not be the end
> of the story, especially when we're talking about important, widely
> used code bases.
Sure, but at least your example code seems pretty
I'm working on porting a plug-in designed for the old
branches/plugin branch to the (recently merged) shiny new
branches/plugins branch. One thing that's turning out to be tricky is
placing the plug-in transform in exactly the same place. In the old
branch, plug-ins hook in just before the pa
> On Thu, 23 Apr 2009, DJ Delorie wrote:
> > +# Return 1 if the target supports double larger than float,
> > +# 0 otherwise.
> > +
> > +proc check_effective_target_large_double { } {
> > +return [check_no_compiler_messages large_double object {
> > + int dummy[sizeof(double) < sizeof(float)
On Thu, 23 Apr 2009, DJ Delorie wrote:
> +# Return 1 if the target supports double larger than float,
> +# 0 otherwise.
> +
> +proc check_effective_target_large_double { } {
> +return [check_no_compiler_messages large_double object {
> + int dummy[sizeof(double) < sizeof(float) ? 1 : -1];
On Thu, Apr 23, 2009 at 5:39 PM, Joe Buck wrote:
>
> On Thu, Apr 23, 2009 at 1:38 PM, Denis Onischenko
>> wrote:
>> > The minimal code example is following:
>> >
>> >
>> > extern unsigned int __invalid_size_argument;
>> > #define TYPECHECK(t) ( sizeof(t) == sizeof(t[1]) ? sizeof(t) :
>> > __i
On Thu, Apr 23, 2009 at 1:38 PM, Denis Onischenko
> wrote:
> > The minimal code example is following:
> >
> >
> > extern unsigned int __invalid_size_argument;
> > #define TYPECHECK(t)( sizeof(t) == sizeof(t[1]) ? sizeof(t) :
> > __invalid_size_argument )
> >
> > static int arr[] = {
> >
SH (and I'm sure others) has some multilibs (like -m2a-single-only)
where sizeof(double) is 4, which breaks some testcases. Here's a
patch which adds checks for small doubles (and small long doubles),
and adjusts some of the tests which depend on large doubles.
Comments? Ok to apply?
*
Michael Hope writes:
> (define_expand "movqi"
> [(set (match_operand:QI 0 "nonimmediate_operand")
> (match_operand:QI 1 "general_operand" ""))]
> ""
> {
> if (can_create_pseudo_p () && MEM_P (operands[1]))
> {
> rtx reg = copy_to_reg (XEXP (operands[1], 0));
> em
On Thu, Apr 23, 2009 at 1:38 PM, Denis Onischenko
wrote:
> The minimal code example is following:
>
>
> extern unsigned int __invalid_size_argument;
> #define TYPECHECK(t) ( sizeof(t) == sizeof(t[1]) ? sizeof(t) :
> __invalid_size_argument )
>
> static int arr[] = {
> [TYPECHECK(int)] =
Hello there,
I'm calling a FORTRAN subroutine in a ANSI C program. The subroutine
has the following prototype:
C:
void CKINIT_(int *LENICK,int *LENRCK,int *LENCCK,int *LINC,int *LOUT,
int *ICKWRK,double *RCKWRK,char *CCKWRK,int *IFLAG);
FORTRAN:
SUBROUTINE CKINIT
Snapshot gcc-4.5-20090423 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.5-20090423/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.5 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/trunk
Thanks for the response Ian. Doing the define_expand inserts the post
increment but GCC doesn't seem to notice the change in X.
I added this code:
(define_expand "movqi"
[(set (match_operand:QI 0 "nonimmediate_operand")
(match_operand:QI 1 "general_operand" ""))]
""
{
if (
In gcc.dg/Wconversion-real.c we see this:
vdouble = 3.1L; /* { dg-warning "conversion" "" { target large_long_double }
} */
It turns out check_effective_target_large_long_double is NEVER called.
You can change it to some bogus string:
fdouble (3.1L); /* { dg-warning "conversion" "" { targe
Manuel López-Ibáñez writes:
> I authored the patch, HJ just committed it. I cannot think any trivial
> way to fix this and I don't have much time to investigate. The PR is
> already reopened, so I think the patch should be reverted. Probably we
> warn too early now but the above testcase seems sp
The minimal code example is following:
extern unsigned int __invalid_size_argument;
#define TYPECHECK(t)( sizeof(t) == sizeof(t[1]) ? sizeof(t) :
__invalid_size_argument )
static int arr[] = {
[TYPECHECK(int)] = 0,
};
int main()
{
return 0;
}
command line is: gcc test.c
GCC 4.
Hi.
The gnu.org webmaster team are going to be updating all the pages in the
gnu.org/software subdirectory, which includes -
http://www.gnu.org/software/fortran
This will involve changing the design of the page to match the new style
of gnu.org, and updating the information about the GNU Fortran
On Thu, Apr 23, 2009 at 12:11 PM, Kate Minola wrote:
> Ok, I am confused. You imply that PPL and CLooG are NOT required to
> build GCC, yet
>
> http://gcc.gnu.org/install/prerequisites.html
>
> lists them as prerequisites to a build.
>
> Who is correct?
Both, the website says:
Necessary to b
On Thu, 23 Apr 2009, Joseph S. Myers wrote:
> Because the behavior of -O3 must not depend on whether optional libraries
> are linked into GCC, and we did not decide to make PPL and CLooG required
> to build GCC, so -O3 cannot enable any optimizations using optional
> libraries.
Ok, I am confused.
On Thu, 23 Apr 2009, Denis Onischenko wrote:
> Thanks for reply!
>
> DRM_IOCTL_NR is defined as
>
> #define _IOC_NRBITS 8
>
> #define _IOC_NRSHIFT 0
> #define _IOC_NRMASK ((1 << _IOC_NRBITS)-1)
>
> #define _IOC_NR(nr)(((nr) >> _IOC_NRSHIFT) & _IOC_NRMASK)
>
> #define DRV_IOCTL_NR(n)
Jean Christophe Beyler writes:
> For the moment, no change, the expansion code is actually not used in
> this case because GCC only presents me with the load from a global
> during or after reload. Therefore, it's already done and he doesn't
> seem to want to change his ways. I haven't played wit
Thanks for reply!
DRM_IOCTL_NR is defined as
#define _IOC_NRBITS 8
#define _IOC_NRSHIFT 0
#define _IOC_NRMASK ((1 << _IOC_NRBITS)-1)
#define _IOC_NR(nr)(((nr) >> _IOC_NRSHIFT) & _IOC_NRMASK)
#define DRV_IOCTL_NR(n)_IOC_NR(n)
i.e. expands to an integer constant expressi
> We can test for the 'this cannot possibly work' cases, i.e. where there is
> no suitable register at all. That would address the problems you have
> originally identified for the m32c.
Sounds good to me ;-)
Hi,
i just built GCC 4.4.0 on AIX 6.1 using the following commands:
setenv LDR_CNTRL MAXDATA=0x5000
../gcc-4.4.0/configure --disable-multilib --with-gmp=/usr/local
make bootstrap-lean
make install
$ config.guess
powerpc-ibm-aix6.1.0.0
$ gcc -v
Using built-i
Quoting DJ Delorie :
> m32c has no problem loading a 24-bit register from a 32-bit memory
> location.
The only truncsipsi2* alternative part that seems to match is Raa / Sd* .
Does that mean that Sd* is as good as m?
m32c doesn't use any of the single-character constraints, as they're
too g
> > m32c has no problem loading a 24-bit register from a 32-bit memory
> > location.
>
> The only truncsipsi2* alternative part that seems to match is Raa / Sd* .
> Does that mean that Sd* is as good as m?
m32c doesn't use any of the single-character constraints, as they're
too general to pretty
On Thu, 23 Apr 2009, David Ronis wrote:
> Thanks for the reply. On the other hand, it seems that PPL and Cloog
> are auto-detected by configure; shouldn't that be enough to dynamically
> modify what -O3 does (or perhaps enable -O4)? On a related point,
> having used my old build script to buil
Thanks for the reply. On the other hand, it seems that PPL and Cloog
are auto-detected by configure; shouldn't that be enough to dynamically
modify what -O3 does (or perhaps enable -O4)? On a related point,
having used my old build script to build gcc I, of course, didn't read
the prerequisites
On Thu, 23 Apr 2009, David Ronis wrote:
> >From the info pages it seems that the new optimizations,
> -floop-interchange, -floop-strip-mine, and -floop-block, are NOT turned
> on when -O3 is specified. Is this correct and if so, why aren't they?
Because the behavior of -O3 must not depend on whe
>From the info pages it seems that the new optimizations,
-floop-interchange, -floop-strip-mine, and -floop-block, are NOT turned
on when -O3 is specified. Is this correct and if so, why aren't they?
David
On Thu, 23 Apr 2009, Denis Onischenko wrote:
> The following errors appears when I tried to compile linux kernel
> 2.6.30-rc2 with GCC 4.5:
>
>
> linux-2.6/drivers/gpu/drm/drm_drv.c:59: error: nonconstant array index
> in initializer
> linux-2.6/drivers/gpu/drm/drm_drv.c:59: error: (near initial
2009/4/23 Vincent Lefevre :
> There seems to be an error on
>
> http://gcc.gnu.org/gcc-4.4/changes.html
>
> It says:
>
> -Wsequence-points now warns within if, while,do while and for
> conditions, and within for begin/end expressions.
>
> However the -Wsequence-points option doesn't seem to exis
There seems to be an error on
http://gcc.gnu.org/gcc-4.4/changes.html
It says:
-Wsequence-points now warns within if, while,do while and for
conditions, and within for begin/end expressions.
However the -Wsequence-points option doesn't seem to exist.
Shouldn't it be -Wsequence-point (with
I've actually done that. I defined the expansion like this:
/* If we can create pseudos, the first operand is a register but the
second is memory */
if (
(
can_create_pseudo_p () &&
register_operand (operands[0], DImode)
&& memory_operand (operands[1], DImode)))
2009/4/23 Ben Elliston :
> Hi HJ
>
> According to svn annotate, it was you who authored the new 'offset
> outside bounds of constant string warning' warning in GCC (well, I think
> so, anyway). The compiler now complains about some code in the C++
> demangler:
>
> /home/bje/source/gcc-trunk/libibe
The following errors appears when I tried to compile linux kernel
2.6.30-rc2 with GCC 4.5:
linux-2.6/drivers/gpu/drm/drm_drv.c:59: error: nonconstant array index
in initializer
linux-2.6/drivers/gpu/drm/drm_drv.c:59: error: (near initialization
for 'drm_ioctls')
...
compiled code looks like this
The GNU Compiler Collection version 4.4.0 has been released.
GCC 4.4.0 is a major release, containing substantial new functionality
not available in GCC 4.3.x or previous GCC releases.
See:
http://gcc.gnu.org/gcc-4.4/changes.html
for more information about changes in GCC 4.4.0.
This release
Hi Alex,
On Wed, 2009-04-22 at 08:19 -0700, Alex Turjan wrote:
> Are there any plans to move the partial unrolling phase from
> RTL to Tree-SSA?
> The move would benefit from better (or easier to implement) Tree-SSA alias
> analysis.
We thought about loop unrolling in graphite.
It seems to be a
40 matches
Mail list logo
