Eric Christopher <[EMAIL PROTECTED]> writes:
| >
| > -Wconversion is a good idea. I don't think -Wtraditional is relevant.
|
| Here's the patch to implement it. Avoids the warning in this testcase
| when -Wconversion is not passed on the command line:
|
| int func1(int i)
| {
|return i;
| }
DJ Delorie <[EMAIL PROTECTED]> writes:
> reg_overlap_mentioned_for_reload_p() assumes that all SUBREGs
> have REGs as their operand. However, register_operand() has
> this comment:
>
>(Ideally, (SUBREG (MEM)...) should not exist after reload,
>but currently it does result from (S
> I figured out what the root cause of this is. The SHL.L opcode (32
> bit shift) has a maximum shift count of 16:
This patch (committed) should fix it. I haven't addressed the "large
variable shift count" part of the problem; this addresses the "large
constant shift count" part which is needed
Hello,
When I run the test suite for my port of gcc, there are some failures
caused by the optimization flag such as -O2/-O3, and the messages are
like,
930120-1.c: In function `f':
930120-1.c:138: internal compiler error: in verify_local_live_at_start, at flow.
c:546
It seems that because of th
reg_overlap_mentioned_for_reload_p() assumes that all SUBREGs
have REGs as their operand. However, register_operand() has
this comment:
(Ideally, (SUBREG (MEM)...) should not exist after reload,
but currently it does result from (SUBREG (REG)...) where the
reg went on
> I apologize if this question has already been answered but I would
> like to know if there is a way to reuse the same config.cache file
> for all the builds of all the subdirectories of a bootstrap ?
It should be possible, but the configure scripts do not update the
config.cache file in a concur
I apologize if this question has already been answered but I would like to
know if there is a way to reuse the same config.cache file for all the
builds of all the subdirectories of a bootstrap ?
In my case, it would speed up a lot the whole process.
CJ
-Wconversion is a good idea. I don't think -Wtraditional is relevant.
Here's the patch to implement it. Avoids the warning in this testcase
when -Wconversion is not passed on the command line:
int func1(int i)
{
return i;
}
int main()
{
float f;
long l;
unsigned long ul;
f = 1.
Snapshot gcc-4.0-20060112 is now available on
ftp://gcc.gnu.org/pub/gcc/snapshots/4.0-20060112/
and on various mirrors, see http://gcc.gnu.org/mirrors.html for details.
This snapshot has been generated from the GCC 4.0 SVN branch
with the following options: svn://gcc.gnu.org/svn/gcc/branches
Hello.
I am the member of the project 'avr-libc' (AVR C Runtime Library). As a
result of this work there were patches with additions of support of new
Atmel devices in gcc the toolchain. I have a desire to add them in official
GCC sources, unfortunately at avr target at the moment would be not
Andrew J. Hutton wrote:
>The GCC & GNU Toolchain Developers' Summit was started in 2004
>
2003, actually ;)
Paolo.
We are pleased to announce the Call for Papers for the 2006 GCC & GNU
Toolchain Developers' Summit. The full text is available on our website
located at http://www.gccsummit.org/2006/cfp.php
The GCC & GNU Toolchain Developers' Summit was started in 2004 as a
venue for those directly involved with
On Thursday 12 January 2006 15:01, Richard Henderson wrote:
> On Thu, Jan 12, 2006 at 02:57:51PM -0500, Diego Novillo wrote:
> > Sounds good to me, but maybe the Fortran FE is relying on the
> > recursive nature of fold() to handle things like 'A = 1 + 1'?
>
> Huh? Fold isn't recursive in that way
On Thu, 2006-01-12 at 11:24 -0800, Joe Buck wrote:
> On Thu, Jan 12, 2006 at 12:13:06PM -0500, Daniel Berlin wrote:
> > I hate to bring this up, because it's a "half-troll", but the halting
> > problem is *not* undecidable on the machines we use everyday, because they
> > have finite memory.
>
>
On Thu, Jan 12, 2006 at 02:57:51PM -0500, Diego Novillo wrote:
> Sounds good to me, but maybe the Fortran FE is relying on the recursive
> nature of fold() to handle things like 'A = 1 + 1'?
Huh? Fold isn't recursive in that way. By design.
r~
On Thursday 12 January 2006 14:50, Richard Henderson wrote:
> On Thu, Jan 12, 2006 at 02:46:35PM -0500, Diego Novillo wrote:
> > #4 0x080a3b9d in gfc_add_expr_to_block (block=0xbfffe898,
> > expr=0xb7ee4bac) at /home/dnovillo/gomp/src/gcc/fortran/trans.c:365
> > 360
> > 361 if (expr == NULL_
On Thu, Jan 12, 2006 at 02:46:35PM -0500, Diego Novillo wrote:
> #4 0x080a3b9d in gfc_add_expr_to_block (block=0xbfffe898, expr=0xb7ee4bac)
> at /home/dnovillo/gomp/src/gcc/fortran/trans.c:365
> 360
> 361 if (expr == NULL_TREE || IS_EMPTY_STMT (expr))
> 362 return;
> 363
> 364
On Thursday 12 January 2006 14:38, Richard Henderson wrote:
> Why would we be trying to fold OMP_SINGLE?
>
The Fortran FE is doing that when building the IL:
#4 0x080a3b9d in gfc_add_expr_to_block (block=0xbfffe898, expr=0xb7ee4bac)
at /home/dnovillo/gomp/src/gcc/fortran/trans.c:365
360
361
On Thu, Jan 12, 2006 at 01:23:47PM -0500, Diego Novillo wrote:
> gcc_assert (IS_EXPR_CODE_CLASS (kind)
> && TREE_CODE_LENGTH (code) == 2
> && op0 != NULL_TREE
> && op1 != NULL_TREE);
>
> I am having problems with this because it's causing failures for pe
On Thursday 12 January 2006 13:39, Roger Sayle wrote:
> If tcc_statement is the best tree_code_class for OMP_SINGLE, then I
> think its reasonable for fold_binary to be more forgiving.
>
Yes, the OMP_* codes are statements that happen to have optional operands
(the clauses).
> Anyone feel stron
On Thu, Jan 12, 2006 at 11:13:59AM -0500, Diego Novillo wrote:
> On Thursday 12 January 2006 11:01, [EMAIL PROTECTED] wrote:
>
> > Yes, there is one more instruction to set the variable to 0...
> >
> Oh, please... Fine. You win. I don't care enough.
Use "unsigned".
On Thu, Jan 12, 2006 at 12:13:06PM -0500, Daniel Berlin wrote:
> I hate to bring this up, because it's a "half-troll", but the halting
> problem is *not* undecidable on the machines we use everyday, because they
> have finite memory.
Fine. Now you just have to come up with a solution before the
Hi Diego,
On Thu, 12 Jan 2006, Diego Novillo wrote:
> In fold_binary() we are asserting:
>
> gcc_assert (IS_EXPR_CODE_CLASS (kind)
> && TREE_CODE_LENGTH (code) == 2
> && op0 != NULL_TREE
> && op1 != NULL_TREE);
...
> DEFTREECODE (OMP_SINGLE, "omp_single
On Jan 12, 2006, at 1:40 PM, Jon BLOOMFIELD wrote:
Can somebody tell me whether there is a known bug in g++ 4.0.1 wrt
scoping
of members of a template base class. The following contrived test case
generates a compiler error on 4.0.1, complaining that 'a' is not in the
scope scope of D::f()
.
Robert Dewar wrote:
> Daniel Berlin wrote:
>
>>> The chain of inferences that the compiler would need to do to properly
>>> diagnose this case is beyond the scope of the mechanical
>>> transformations. The reasoning you need to implement to catch these
>>> cases could even be reduced to the haltin
Hi,
Can somebody tell me whether there is a known bug in g++ 4.0.1 wrt scoping
of members of a template base class. The following contrived test case
generates a compiler error on 4.0.1, complaining that 'a' is not in the
scope scope of D::f()
template class T
{
protected:
bool
Daniel Berlin wrote:
The chain of inferences that the compiler would need to do to properly
diagnose this case is beyond the scope of the mechanical transformations.
The reasoning you need to implement to catch these cases could even be
reduced to the halting problem.
I hate to bring this
In fold_binary() we are asserting:
gcc_assert (IS_EXPR_CODE_CLASS (kind)
&& TREE_CODE_LENGTH (code) == 2
&& op0 != NULL_TREE
&& op1 != NULL_TREE);
I am having problems with this because it's causing failures for perfectly
valid IL. With the new OpenM
On Jan 12, 2006, at 11:10 AM, Gabriel Dos Reis wrote:
Perry Smith <[EMAIL PROTECTED]> writes:
| Thanks Gaby...
|
| To recap, my current quest is to resolve references to symbols like
| __floatdidf. This is in a library for ppc64/soft-float.
|
| Ian pointed me to ppc64-fp.c. When I try to comp
On Thursday 12 January 2006 12:13, Daniel Berlin wrote:
> > The chain of inferences that the compiler would need to do to properly
> > diagnose this case is beyond the scope of the mechanical
> > transformations. The reasoning you need to implement to catch these
> > cases could even be reduced to
The chain of inferences that the compiler would need to do to properly
diagnose this case is beyond the scope of the mechanical transformations.
The reasoning you need to implement to catch these cases could even be
reduced to the halting problem.
I hate to bring this up, because it's a "half-tr
Perry Smith <[EMAIL PROTECTED]> writes:
| Thanks Gaby...
|
| To recap, my current quest is to resolve references to symbols like
| __floatdidf. This is in a library for ppc64/soft-float.
|
| Ian pointed me to ppc64-fp.c. When I try to compile it, TFtype is
| undefined. It is suppose to get de
Thanks Gaby...
To recap, my current quest is to resolve references to symbols like
__floatdidf. This is in a library for ppc64/soft-float.
Ian pointed me to ppc64-fp.c. When I try to compile it, TFtype is
undefined. It is suppose to get defined in fp-bit.h but only if
__LDBL_MANT_DIG__
On Thursday 12 January 2006 11:03, Michael Veksler wrote:
> You are most likely right about the "realistically" part.
>
Yes. The heavy analysis would probably be worth doing in a lint-like
checker. Or be part of the compiler with special static optimization
switches. It's probably too heavy-d
On Thursday 12 January 2006 11:01, [EMAIL PROTECTED] wrote:
> Yes, there is one more instruction to set the variable to 0...
>
Oh, please... Fine. You win. I don't care enough.
Quoting Diego Novillo <[EMAIL PROTECTED]>:
[...]
>
> The compiler cannot statically short-circuit that predicate because it
> doesn't know whether best.score will be positive or not.
>
> The chain of inferences that the compiler would need to do to properly
> diagnose this case is beyond the sc
Perry Smith <[EMAIL PROTECTED]> writes:
| Sorry for such a lame question:
|
| Where does __LDBL_MANT_DIG__ get defined? (gcc 4.0.2)
a built-in macro. See gcc/c-cppbuiltin.c
-- Gaby
[EMAIL PROTECTED] said:
> Sub-optimal?
Yes, there is one more instruction to set the variable to 0...
--- testit_1.s 2006-01-12 16:38:06.13376 +0100
+++ testit.s2006-01-12 16:57:04.844986000 +0100
@@ -16,6 +16,7 @@
testl %ebx, %ebx
je .L9
movl$0, %edx
On Thursday 12 January 2006 10:47, [EMAIL PROTECTED] wrote:
> But... it used to be the case that the compiler didn't try to warn about
> uninitialized variables embedded in structs (or so I seem to
> remember...) So I was wondering if this was some kind of regression...
>
Progression, of sorts. Y
[EMAIL PROTECTED] wrote:
> But... it used to be the case that the compiler didn't try to warn about
> uninitialized variables embedded in structs (or so I seem to remember...)
> So I was wondering if this was some kind of regression...
I would consider that to be a bug, not a feature. Just be
Ok, a slightly simpler testcase still shows the warning:
--- testit.c ---
#include
static void
testit(unsigned int *a, unsigned int cnt)
{
struct {unsigned int score; unsigned int d;} best;
unsigned int i;
best.score = 0;
for (i = 0; i < cnt; i++)
if (a[i] > best.score) {
best.
Sorry for such a lame question:
Where does __LDBL_MANT_DIG__ get defined? (gcc 4.0.2)
Thanks,
Perry
Problem is solved. It was a problem in my configuration of
GCC.
Leif Ekblad
On Thursday 12 January 2006 10:14, Perry Smith wrote:
> But... getting a compiler to figure that out is expecting too much.
> Did you try up'ing the optimization level (just out of curiosity)?
>
Right. He will have the same problem at any level.
The compiler cannot statically short-circuit that
Because best.score is set to 0 up front, he is expecting the || (or)
to short circuit and never test best.d.
But... getting a compiler to figure that out is expecting too much.
Did you try up'ing the optimization level (just out of curiosity)?
On Jan 12, 2006, at 9:01 AM, Diego Novillo wr
On Thursday 12 January 2006 09:53, [EMAIL PROTECTED] wrote:
> On my FC4 box with gcc version 4.0.2 20051125 (Red Hat 4.0.2-8) it says:
> testit.c: In function 'testit':
> testit.c:6: warning: 'best.d' may be used uninitialized in this function
>
The warning is valid. You are not guaranteeing that
>I am somewhat confused about the status of the
>"may be used uninitialized" warning...
This list is more for discussing the internals of the GCC compiler,
not how to use it.
As for your question, if cnt is less than or equal to zero, or if a[i]
is always less than zero, then the assignment to
> Dmytro writes:
- stwu r1,-24(r1)
+ stwu r1,-32(r1)
...
- addi r1,r1,24
+ addi r1,r1,32
This difference allocates and releases two more stack slots. It probably
means there is an incorrect assumption in the boot loader assembly code
causing its stack usage to conflict with the compiler sa
Hi all,
I am somewhat confused about the status of the
"may be used uninitialized" warning...
Consider:
--- testit.c ---
#include
static void
testit(int *a, int cnt)
{
struct {int score; int d;} best;
int i;
best.score = 0;
for (i = 0; i < cnt; i++)
if (a[i] > best.score) {
b
Well, shoot.
I added that and reconfigured and recompiled over night but it looks
like I need to define __powerpc64__ and currently it is not defined.
On Jan 11, 2006, at 10:17 PM, Ian Lance Taylor wrote:
Perry Smith <[EMAIL PROTECTED]> writes:
The problem: In the particular build I am tr
Jakub Jelinek wrote:
Yes. I think they are useful for all branches if you backport a patch for
a particular fix or e.g. fix something that is not yet fixed on the trunk
and will be only when a particular devel branch with that fix is merged
into trunk. But in all cases that should be a sing
> This is to update you that we have tested "float" and "double" data
> type computations on m32c hardware (3DKM32C/85U) and found that it
> is working successfully.
Ok, thanks. The m32c allows -32..+32 shifts so it wouldn't have this
particular problem. I'll probably end up splitting the m16c
On Thu, Jan 12, 2006 at 11:12:36AM +0100, Giovanni Bajo wrote:
> Bernd Schmidt <[EMAIL PROTECTED]> wrote:
>
> >> mysql> delete from longdescs where length(thetext) > 100;
> >> Query OK, 251 rows affected (2 min 12.11 sec)
> >
> > Thank you.
> >
> >> I may just set up a pre-commit hook to che
Here is the output from the same compile in the
/usr/src/toolchain/gcc-4.1-20051008/host-i686-pc-linux-gnu/gcc/ directory:
./xgcc -B/usr/src/toolchain/gcc-4.1-20051008/host-i686-pc-linux-gnu/gcc/ -B/
usr/local/rdos/bin/ -B/usr/local/rdos/lib/ -isystem
/usr/local/rdos/include -isystem /usr/local/rd
I rerun the compiler with -v option. This is the output:
./xgcc -B/usr/src/toolchain/gcc-4.2-20060107/host-i686-pc-linux-gnu/gcc/ -B/
usr/local/rdos/bin/ -B/usr/local/rdos/lib/ -isystem
/usr/local/rdos/include -isystem /usr/local/rdos/sys-include -o conftest
conftest.c -v
Reading specs from
/usr/s
Bernd Schmidt <[EMAIL PROTECTED]> wrote:
>> mysql> delete from longdescs where length(thetext) > 100;
>> Query OK, 251 rows affected (2 min 12.11 sec)
>
> Thank you.
>
>> I may just set up a pre-commit hook to check the log message length and
>> hav eit not let you commit if it's ridiculousl
Daniel Berlin wrote:
mysql> delete from longdescs where length(thetext) > 100;
Query OK, 251 rows affected (2 min 12.11 sec)
Thank you.
I may just set up a pre-commit hook to check the log message length and
hav eit not let you commit if it's ridiculously large.
Maybe checkins on a bran
Hi,
This is to update you that we have tested "float" and "double" data type
computations on m32c hardware (3DKM32C/85U) and found that it is working
successfully.
Regards,
Ina Pandit
KPIT Cummins InfoSystems Ltd.
Pune, India
We have a boot loader (u-boot) that runs on powerpc platform (MPC8272)
If we cross-compile it using gcc 3.4.4 it works fine and it generates the
following start and end of the functions
powerpc-linux-uclibc-gcc 3.4.4:
stwu r1,-24(r1)
li r0,128
...
addi r1,r1,24
blr
That works fine. But if we
59 matches
Mail list logo
