Hi all,
Could someone give me a pointer to doc or code about building a
function decl and function call expr that take a variable number of
arguments (like printf)?
Thanks,
FX
François-Xavier Coudert [EMAIL PROTECTED] writes:
Could someone give me a pointer to doc or code about building a
function decl and function call expr that take a variable number of
arguments (like printf)?
See c-common.c:def_fn_type for the decl.
Andreas.
--
Andreas Schwab, SuSE Labs,
Hi Zack, hi all,
A bootstrap of GCC mainline, rev. 123324, fails because of:
gcc -c -g -fkeep-inline-functions -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes -pedantic
-Wno-long-long -Wno-variadic-macros -Wno-overlength-strings
-Wold-style-definition
I'm CCing Zack
Away on vacation until March 31st, said the automated reply.
PS: I've launched a cross build to see if I can reproduce it there,
which would of course make it easier for tracking down.
Works OK on the cross. So, it's probably a host problem in gengtype.
It appears to exist on
In http://gcc.gnu.org/ml/gcc/2007-03/msg01007.html, Steven Bosscher wrote:
All of this feels (to me anyway) like adding a lot of code to the
middle end to support MEP specific arch features. I understand it is
in the mission statement that more ports is a goal for GCC, but I
wonder if this
On 3/29/07, François-Xavier Coudert [EMAIL PROTECTED] wrote:
Works OK on the cross. So, it's probably a host problem in gengtype.
It appears to exist on HPUX as well, as Steve noted.
Yeah, it appears I was overly optimistic in hoping vsnprintf() would
do what C99 says it does. I do not have
Yeah, it appears I was overly optimistic in hoping vsnprintf() would
do what C99 says it does. I do not have access to any system that
shows the problem, but I've attached a patch that should fix it (it
just reverts the oprintf() changes, which were not really necessary, I
was just trying to be
[resend]
On 3/29/07, François-Xavier Coudert [EMAIL PROTECTED] wrote:
I've attached a patch that should fix it (it
just reverts the oprintf() changes, which were not really necessary, I
was just trying to be more efficient).
Thanks, that fixes it for me on i386-pc-mingw32.
committed.
zw
Mark Mitchell wrote on 03/22/07 22:10:
Diego, Roger, Jason, would you please let me know if you can work on the
issues above? I'm going to try to test Jim's patch for PR 31273 tonight.
I'm looking at 29585 today.
Ian Lance Taylor wrote:
It's really a lot easier to do this as a source code modification than
as a compiler change. Unless you already have a lot of experience
with the compiler, I think you'd be lucky or very good to get it done
in two weeks.
I have already done it as source code modification,
Brian Makin writes:
Brian I had sent in the paperwork in october 2005.
Brian [EMAIL PROTECTED]
Brian Brian N. Makin
Brian I can certainly send another if necessary.
Did you send in a request for an assignment or did you fill out an
assignment yourself? Did you receive an
Hi Gcc gang,
Are my eyes playing tricks on me? While compiling this code:
/tmp/warn $ cat leaf.c
extern void external_func (void);
void __attribute__ ((__isr__)) foo4 (void)
{
external_func ();
return ;
}
the compiler sets current_function_is_leaf. Huh? It doesn't
This logic works fine - except when gcc tells me that this sibcall
function is a leaf, despite the fact that it calls out to another function
that probably clobbers the call_used regs.
A leaf function is one that doesn't make any function calls. Technically
speaking, a sibcall isn't really
Hi guys!
I've been having sporadic conversations with both Diego and Rth regarding
tuples, and I wanted to sum up, and get others' opinions.
After doing the GIMPLE_MODIFY_STMT work, I've come to the conlusion that
to continue overloading trees will be more work in the long run than doing the
On Thu, Mar 29, 2007 at 04:16:35PM -0400, Aldy Hernandez wrote:
* By extension, we will also need:
typedef struct gimple_expression_d { ... } * gimple_expr;
For example, PLUS_EXPR, etc. These will have location, btw.
Something like:
gimple_stmt
What application/tool can show inheritance tree of C++ classes, or
list all classes from a source code, which g++ can compile without
errors or warnings ?
This question is not relevant on this mailing list. This list is used
for discussions about GCC development. Next time, please try the
Aldy Hernandez [EMAIL PROTECTED] writes:
After doing the GIMPLE_MODIFY_STMT work, I've come to the conlusion that
to continue overloading trees will be more work in the long run than doing the
actual separation between tuples and trees. This business of this is
a tree, but not really,
On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Why will expressions have location? It seems to me preferable to save
the memory. After a few optimization passes many of the expressions
have no location anyhow.
And I know from past experiences, that this is really a
On Thu, Mar 29, 2007 at 06:40:30PM -0700, Andrew Pinski wrote:
On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Why will expressions have location? It seems to me preferable to save
the memory. After a few optimization passes many of the expressions
have no location
Andrew Pinski [EMAIL PROTECTED] writes:
On 29 Mar 2007 18:24:56 -0700, Ian Lance Taylor [EMAIL PROTECTED] wrote:
Why will expressions have location? It seems to me preferable to save
the memory. After a few optimization passes many of the expressions
have no location anyhow.
And I
Hi Eric, Hi Richard,
We recently ran across an ICE building a target libiberty for one of
the multilibs of the mips64vrel-elf toolchain:
.../libiberty/regex.c: In function 'byte_re_match_2_internal':
.../libiberty/regex.c:7481: error: insn does not satisfy its constraints:
I recently ran across an ICE building a target libiberty for one of
the multilibs of the mips64vrel-elf toolchain:
.../libiberty/regex.c: In function 'byte_re_match_2_internal':
.../libiberty/regex.c:7481: error: insn does not satisfy its constraints:
(insn 5211 1697 1699 173
Hi Richard,
But I am pretty sure that this is the wrong solution. Since I am
not a MIPS expert however I am punting this problem to you guys. :-)
Yeah, I'm afraid it's the wrong solution. ;)
Thought so :-)
I gather from the insn above that a use of the GP pseudo
register has been
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot
|dot org
--- Comment #1 from rsandifo at gcc dot gnu dot org 2007-03-29 11:02
---
Sigh. Wrong bug #, sorry.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31338
--- Comment #2 from rsandifo at gcc dot gnu dot org 2007-03-29 11:03
---
Sigh. Wrong bug #, sorry.
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
--
rsandifo at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |rsandifo at gcc dot gnu dot
|dot org
--- Comment #4 from nickc at redhat dot com 2007-03-29 11:05 ---
Brooks' patch is better than mine, so I would recommend that it be adopted.
Cheers
Nick
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31353
--- Comment #4 from nickc at redhat dot com 2007-03-29 11:08 ---
Subject: Re: --help=language option isn't documented.
Hi Brooks,
The patch tracker missed the patch I'd already posted for this one as well:
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01655.html
I think our fixes
--- Comment #2 from nickc at redhat dot com 2007-03-29 11:11 ---
Hi Brooks,
One difference that I see between our patches -- you have:
+ if (* descrip_extra == '\0')
+descrip_extra = lang_names [i];
whereas mine just unconditionally assigns descrip_extra to
--- Comment #1 from pault at gcc dot gnu dot org 2007-03-29 11:44 ---
Yes, indeed; a dummy argument of an elemental procedure cannot appear in a
specification expression.
12.7.1
Constraint: A dummy argument, or a subobject thereof, shall not appear in a
specification-expr except as the
Is the following buggy core or a bug in 4.3? I don't see why it should fail.
The problem is that when I compile an inline function with -std=gnu99, it will
not be found during linking.
Example:
gcc -c t.c
gcc -c -std=gnu99 timer.c
gcc -o t t.o timer.o
This results in:
t.c:(.text+0x1c):
--- Comment #1 from tbm at cyrius dot com 2007-03-29 11:51 ---
I forgot to mention that it works fine with 4.1.
--
tbm at cyrius dot com changed:
What|Removed |Added
--- Comment #64 from marc dot glisse at normalesup dot org 2007-03-29
12:29 ---
(In reply to comment #63)
However, I'm working on speculative fixes for newlib and linux, which are
predicated on the correct __cplusplus values. I may get to solaris too, if my
sanity stretches that
--- Comment #4 from steven at gcc dot gnu dot org 2007-03-29 13:00 ---
No dependent bugs left.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from steven at gcc dot gnu dot org 2007-03-29 13:01 ---
Lack of activity alone is reason enough to close this.
On top of that, this meta-bug has no dependent bugs left. In fact it appears
to never have had any.
--
steven at gcc dot gnu dot org changed:
--- Comment #26 from steven at gcc dot gnu dot org 2007-03-29 13:18 ---
I have looked at the various test cases in this PR, and all of them work for
me.
--
steven at gcc dot gnu dot org changed:
What|Removed |Added
I receive the following ICE:
transferbug.f90: In function bucketindexofkey:
transferbug.f90:14: internal compiler error: in gfc_get_element_type, at
fortran/trans-types.c:741
when compiling this test code:
module InternalCompilerError
type Byte
private
character(len=1)
--- Comment #8 from steven at gcc dot gnu dot org 2007-03-29 13:29 ---
For the original test case, our current output before expand (i.e. the
final_cleanup dump) on hosts where sizeof(long)==sizeof(int) is this:
;; Function convertToMinutes (convertToMinutes)
convertToMinutes
I get the following link error with 4.3 and -O -g:
$ gcc -c -g -O test.c -o test.o
$ gcc -o m m.c test.o
test.o:(.debug_info+0x539): undefined reference to `.L4'
collect2: ld returned 1 exit status
test.c:
#include netdb.h
#include stdio.h
#include malloc.h
typedef struct _hostEntry {
--- Comment #1 from tbm at cyrius dot com 2007-03-29 13:56 ---
This problem was introduced between 20070303 and 20070326.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31391
--- Comment #2 from rguenth at gcc dot gnu dot org 2007-03-29 14:24 ---
Inline behavior is now C99 compatible by default, you need to use extern inline
in this case.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #10 from patchapp at dberlin dot org 2007-03-29 14:25 ---
Subject: Bug number PR 30666
A patch for this bug has been added to the patch tracker.
The mailing list url for the patch is
http://gcc.gnu.org/ml/gcc-patches/2007-03/msg01939.html
--
--- Comment #2 from rakdver at gcc dot gnu dot org 2007-03-29 14:29 ---
Mine.
--
rakdver at gcc dot gnu dot org changed:
What|Removed |Added
This bug is meant to collect issues related to initializations and type
declarations.
--
Summary: [meta-bug] gfortran problems with initialization
Product: gcc
Version: 4.3.0
Status: UNCONFIRMED
Keywords: meta-bug
Severity: normal
This bug is meant to collext bugs WRT intrinsics that happen at compile-time,
i.e. no implementation issues, but issues where an intrinsic can be called
where it shouldn't and the like.
--
Summary: [meta-bug] gfortran compile-time problems with
intrinsics
--- Comment #11 from dgregor at gcc dot gnu dot org 2007-03-29 15:11
---
Subject: Bug 30666
Author: dgregor
Date: Thu Mar 29 15:11:28 2007
New Revision: 123330
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123330
Log:
2007-03-29 Douglas Gregor [EMAIL PROTECTED]
PR
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #12 from dgregor at gcc dot gnu dot org 2007-03-29 15:14
---
Fix committed to mainline
--
dgregor at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #3 from pinskia at gcc dot gnu dot org 2007-03-29 15:15 ---
Plain inline without any thing which says static or extern in C99 is the same
as what GNU-C90 considers as their extern inline and not what C99 considers
as extern inline. If you add a prototype that says extern,
--- Comment #11 from bangerth at dealii dot org 2007-03-29 16:13 ---
Still happens with 4.1.2
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #10 from bangerth at dealii dot org 2007-03-29 16:20 ---
This appears fixed with current mainline (at the very least, I don't know
how far back this reaches, but 3.3.5 is still broken).
--
bangerth at dealii dot org changed:
What|Removed
--- Comment #11 from bangerth at dealii dot org 2007-03-29 16:25 ---
Still happens with a recent mainline snapshot.
--
bangerth at dealii dot org changed:
What|Removed |Added
--- Comment #11 from tromey at gcc dot gnu dot org 2007-03-29 16:27 ---
This still happens with -fmessage-length=80, per comment #9.
Perhaps we don't care, though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=712
--- Comment #14 from bangerth at dealii dot org 2007-03-29 16:28 ---
Still happens with a recent mainline snapshot.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=99
bangerth at dealii dot org [EMAIL PROTECTED] writes:
| Still happens with a recent mainline snapshot.
This one is tricky. I once had a patch for it, but then the patch
broke some other diagnostic. :-(
I'll try to revive it.
-- Gaby
--- Comment #15 from gdr at cs dot tamu dot edu 2007-03-29 16:43 ---
Subject: Re: Bug in template type in error message.
bangerth at dealii dot org [EMAIL PROTECTED] writes:
| Still happens with a recent mainline snapshot.
This one is tricky. I once had a patch for it, but then the
--- Comment #12 from bangerth at dealii dot org 2007-03-29 17:05 ---
(In reply to comment #11)
This still happens with -fmessage-length=80, per comment #9.
Uh, but that's exactly what I tried and it wrapped just fine, with
the tick on the second line...
W.
--
bangerth at dealii
--- Comment #1 from fxcoudert at gcc dot gnu dot org 2007-03-29 17:10
---
I'd say it's a duplicate of PR31193, which was fixed on 2007-03-22. At least,
your testcase doesn't trigger the bug on i386-linux nor on x86_64-linux.
Closing as duplicate: could you try it with an updated
--- Comment #6 from fxcoudert at gcc dot gnu dot org 2007-03-29 17:10
---
*** Bug 31390 has been marked as a duplicate of this bug. ***
--
fxcoudert at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #13 from tromey at gcc dot gnu dot org 2007-03-29 17:18 ---
Right you are. Sorry about that :(
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=712
--- Comment #33 from rth at gcc dot gnu dot org 2007-03-29 17:30 ---
I've been trying to track down this same failure on Alpha. I can reproduce
that
reverting the third hunk allows the bootstrap to complete. Finding what has
got
miscompiled has been very difficult. Only two files
--- Comment #4 from tromey at gcc dot gnu dot org 2007-03-29 17:48 ---
I suspect we're trying to initialize the logging manager too early.
In particular in libgcj we use 'null' as the loader parameter to
Class.forName during startup -- this will bypass the system class loader.
Second,
I have some code that involves computing a cosine via cos(), specifically b =
cos(v). Depending on the context of the cos call, I get correct and incorrect
answers. In the example code's main program, I get a correct result regardless
of the compilation flags. In the MATHNEW_funceval routine,
--- Comment #1 from sdirkse at gams dot com 2007-03-29 17:55 ---
Created an attachment (id=13297)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13297action=view)
test case for the bug
Building with
gcc -m64 -O1 -o xxx cosbug.i -lm
shows the bug bug
gcc -m64 -o xxx cosbug.i -lm
is
--- Comment #5 from marcus at better dot se 2007-03-29 18:11 ---
(In reply to comment #4)
Third, what's up with the class name 1catalina.org.apache.juli.FileHandler,?
Perhaps we are not parsing something correctly?
It comes from a configuration file for the logging mechanism,
--- Comment #34 from rth at gcc dot gnu dot org 2007-03-29 18:13 ---
Actually, on second thought, I don't think the sign_bit_p change is legit:
Value ranges after VRP:
-mask_lo_1: [0, +INF] EQUIVALENCES: { } (0 elements)
+mask_lo_1: [0x0, +INF] EQUIVALENCES: { } (0
--- Comment #35 from rth at gcc dot gnu dot org 2007-03-29 18:21 ---
With some sed help, one can see that fold_binary is completely ruined:
- mhi = 0x0 128 - width;
- if ((~(hi2 | hi1) mhi) == 0) goto L; else goto L;
-
-L:;
- mlo = 0x0;
+ mhi = 0;
--- Comment #6 from tromey at gcc dot gnu dot org 2007-03-29 18:43 ---
Thanks.
This is a little bit screwy since Java 5 claims that 'handlers' is
whitespace-separated -- but I see that in Java 6 they updated the
docs to reflect the actual implementation.
Also tomcat seems to rely on
--- Comment #2 from dominiq at lps dot ens dot fr 2007-03-29 18:50 ---
This bug reminds me PR30980 and PR31161, though they were reported only for g++
and gfortran (they were fixed on 2007-03-16). Could you look at them to see if
the bug you have reported is not a duplicate? If yes, you
When run the following program:
PROGRAM test
INTEGER :: i = 1
WRITE(*, 10) i
10 FORMAT('i =',I2:,' this should not print')
END PROGRAM test
It prints:
i = 1 this should not print
If I insert a comma or a slash between I2 and : it will work correctly.
--
Summary: Colon edit
--- Comment #13 from dnovillo at gcc dot gnu dot org 2007-03-29 19:55
---
I can't reproduce this on mainline anymore. It does fail on the 4.2 branch.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29585
A simple function that just sums over a vector is much slower if inlined than
out of line. The o-o-l version keeps the sum in a xmm register, the inline
version keeps reading and storing the stack variable on each iteration (guessed
looking at the assembler).
Timings on a 2.4 P4 Xeon:
out-of
--- Comment #1 from jamagallon at ono dot com 2007-03-29 23:17 ---
Created an attachment (id=13298)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13298action=view)
testcase
Simple test case with a loop in main() and a call to a function.
Both just calculate the sum of all elements
--- Comment #2 from jamagallon at ono dot com 2007-03-29 23:18 ---
Created an attachment (id=13299)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13299action=view)
Makefile for testcase
Makefile to build tst.c.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31396
--- Comment #7 from law at redhat dot com 2007-03-29 23:18 ---
Subject: Re: Missed jump threading/bypassing
optimization with loop and % (or ands)
IMHO, this PR should simply be closed.
This is a case where aggressive threading is going to explode codesize
with marginal
--- Comment #3 from jamagallon at ono dot com 2007-03-29 23:22 ---
Sample assembler for the loops.
For the funcion, out of line:
#APP
#FBGN
#NO_APP
movldata, %edx
fldz
movl$1, %eax
.L2:
fadds -4(%edx,%eax,4)
addl$1, %eax
cmpl$268435457,
--- Comment #4 from jamagallon at ono dot com 2007-03-29 23:47 ---
Assembler for the opteron.
out-of-line:
.L2:
cvtss2sd(%rdx,%rax,4), %xmm0
incq%rax
cmpq$268435456, %rax
addsd %xmm0, %xmm1
jne .L2
inline:
.L11:
cvtss2sd(%rdx,%rax,4), %xmm0
--- Comment #4 from sje at cup dot hp dot com 2007-03-30 00:22 ---
This has been fixed for me with this patch:
2007-03-29 Zack Weinberg [EMAIL PROTECTED]
* gengtype.c (oprintf): Mostly revert changes from 2007-03-26;
add comment explaining why vsnprintf cannot be
--- Comment #5 from dave at hiauly1 dot hia dot nrc dot ca 2007-03-30
00:32 ---
Subject: Re: make[3]: *** [s-gtype] Segmentation fault (core dumped)
This has been fixed for me with this patch:
2007-03-29 Zack Weinberg [EMAIL PROTECTED]
* gengtype.c (oprintf): Mostly
--- Comment #3 from pault at gcc dot gnu dot org 2007-03-30 00:34 ---
This fixes it and regtests OK
Paul
Index: gcc/fortran/check.c
===
*** gcc/fortran/check.c (revision 123183)
--- gcc/fortran/check.c (working copy)
--- Comment #5 from dave dot korn at artimi dot com 2007-03-30 01:50
---
I have just checked in a fix for this in newlib. See the thread at:
http://sourceware.org/ml/newlib/2007/msg00292.html
and the references therein:
http://cygwin.com/ml/cygwin/2007-03/msg00705.html
--- Comment #7 from tromey at gcc dot gnu dot org 2007-03-30 05:09 ---
Subject: Bug 29869
Author: tromey
Date: Fri Mar 30 05:09:35 2007
New Revision: 123356
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123356
Log:
libjava
PR libgcj/29869:
*
--- Comment #8 from tromey at gcc dot gnu dot org 2007-03-30 05:12 ---
Fix checked in.
--
tromey at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #9 from cvs-commit at developer dot classpath dot org
2007-03-30 05:14 ---
Subject: Bug 29869
CVSROOT:/cvsroot/classpath
Module name:classpath
Changes by: Tom Tromey tromey 07/03/30 04:13:43
Modified files:
. : ChangeLog
--- Comment #10 from tromey at gcc dot gnu dot org 2007-03-30 05:35 ---
Subject: Bug 29869
Author: tromey
Date: Fri Mar 30 05:34:58 2007
New Revision: 123357
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=123357
Log:
libjava
PR libgcj/29869:
*
86 matches
Mail list logo
