--- Comment #5 from lukew at radterm dot com dot au 2006-10-26 06:45
---
(In reply to comment #3)
> Subject: Re: hex and oct constants are converted to
> wrong type
> The resulting tokens compose the controlling constant expression which
> is evaluated according to the rules of
--- Comment #12 from P dot Schaffnit at access dot rwth-aachen dot de
2006-10-26 06:42 ---
Isn't this also 'Bug#: 27133'?
--
P dot Schaffnit at access dot rwth-aachen dot de changed:
What|Removed |Added
--- Comment #2 from bangerth at dealii dot org 2006-10-26 06:39 ---
To be more concrete: (int)(expression) rounds down. So if your quotient
of logarithms happens to be computed to 5.999, then you
will get a result of 5 after casting to int. You should round results,
not just
--- Comment #4 from P dot Schaffnit at access dot rwth-aachen dot de
2006-10-26 06:37 ---
I am experiecing the same thing under Irix with freshly checked out sources.
The system: SGI, IRIX64 blue1 6.5 04100802 IP27. All the tools are quite out of
date...
PS: is this related to 'Bug#:
--- Comment #9 from bangerth at dealii dot org 2006-10-26 06:35 ---
*** Bug 29593 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
---
--- Comment #4 from bangerth at dealii dot org 2006-10-26 06:35 ---
I meant PR 986 :(
*** This bug has been marked as a duplicate of 986 ***
--
bangerth at dealii dot org changed:
What|Removed |Added
---
--- Comment #3 from bangerth at dealii dot org 2006-10-26 06:34 ---
Ah shoot...
--
bangerth at dealii dot org changed:
What|Removed |Added
Status|RESOLVED
--- Comment #2 from bangerth at dealii dot org 2006-10-26 06:34 ---
This is in fact a duplicate of PR 968.
*** This bug has been marked as a duplicate of 968 ***
--
bangerth at dealii dot org changed:
What|Removed |Added
--
--- Comment #6 from bangerth at dealii dot org 2006-10-26 06:34 ---
*** Bug 29593 has been marked as a duplicate of this bug. ***
--
bangerth at dealii dot org changed:
What|Removed |Added
---
hello friends
I am new to this forum and i am having some doubt related to the GNU
compiler.
I am working with ARM core GNU compiler and i WANT TO PORT MY PROJECT THAT
HAS BEEN TESTED IN TURBO C ENVIRONMENT TO THE GNU SUPPORTED EMBESTide FOR
ARM PROCESSORS.
iS THERE ANY PROBLEM IN THAT. i AM FACIN
hello friends
I am new to this forum and i am having some doubt related to the GNU
compiler.
I am working with ARM core GNU compiler and i WANT TO PORT MY PROJECT THAT
HAS BEEN TESTED IN TURBO C ENVIRONMENT TO THE GNU SUPPORTED EMBESTide FOR
ARM PROCESSORS.
iS THERE ANY PROBLEM IN THAT. i AM FACIN
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mueller at gcc dot gnu dot
|dot org
--- Comment #5 from jvdelisle at gcc dot gnu dot org 2006-10-26 04:42
---
Subject: Bug 29563
Author: jvdelisle
Date: Thu Oct 26 04:41:55 2006
New Revision: 118060
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118060
Log:
2006-10-26 Jerry DeLisle <[EMAIL PROTECTED]>
--- Comment #4 from jvdelisle at gcc dot gnu dot org 2006-10-26 04:35
---
Subject: Bug 29563
Author: jvdelisle
Date: Thu Oct 26 04:35:45 2006
New Revision: 118059
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118059
Log:
2006-10-25 Jerry DeLisle <[EMAIL PROTECTED]>
--
mueller at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |mueller at gcc dot gnu dot
|dot org
--- Comment #3 from pcarlini at suse dot de 2006-10-26 04:22 ---
(In reply to comment #2)
> I just tried valgrind. I'm not really familiar with valgrind, but as far
> as I can tell it reports no problems. So, either purify is wrong, valgrind
> is wrong, or they're both wrong in different
--- Comment #11 from sgk at troutmask dot apl dot washington dot edu
2006-10-26 04:03 ---
Subject: Re: Intrinsic MOD incorrect for large arg1/arg2 and slow.
On Wed, Oct 25, 2006 at 08:19:21AM -, fxcoudert at gcc dot gnu dot org
wrote:
>
> I'm adding Steve Kargl to the CC list, si
--- Comment #37 from ghazi at gcc dot gnu dot org 2006-10-26 00:59 ---
A request for this optimization made by Bruce in Sept 2000. :-)
http://gcc.gnu.org/ml/gcc-patches/2000-09/msg00877.html
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21982
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-25 23:04 ---
This is mentioned in:
http://gcc.gnu.org/ml/gcc-patches/2006-10/msg01003.html
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
Executing on host: /home/dave/gnu/gcc-4.2/objdir/gcc/xgcc
-B/home/dave/gnu/gcc-4
.2/objdir/gcc/
/home/dave/gnu/gcc-4.2/gcc/gcc/testsuite/gcc.dg/tree-ssa/loadpre1
.c -O2 -fdump-tree-pre-stats -fno-show-column -S -o loadpre1.s(timeout =
300)
PASS: gcc.dg/tree-ssa/loadpre1.c (test for excess er
--- Comment #2 from mstaley at lanl dot gov 2006-10-25 22:38 ---
(In reply to comment #1)
> This is most likely a purify problem. Have you tried using valgrind instead?
>
I just tried valgrind. I'm not really familiar with valgrind, but as far
as I can tell it reports no problems. So,
--- Comment #11 from daney at gcc dot gnu dot org 2006-10-25 22:34 ---
With the (now committed) patches, my testing shows the problem as fixed.
--
daney at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #10 from daney at gcc dot gnu dot org 2006-10-25 22:29 ---
Subject: Bug 29519
Author: daney
Date: Wed Oct 25 22:29:10 2006
New Revision: 118044
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118044
Log:
PR middle-end/29519
* rtlanal.c (nonzero_address
--- Comment #84 from pinskia at gcc dot gnu dot org 2006-10-25 22:05
---
*** Bug 29597 has been marked as a duplicate of this bug. ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-25 22:05 ---
This comes from precission of the floating point.
*** This bug has been marked as a duplicate of 323 ***
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
---
The following code should return the base2 logarithm of 64 (ie 6)
double d = log(64.0) / log(2.0);
int i = (int)d;
cout << i;
And indeed it does output "6". However, if you attempt to cast it on the same
line, then it returns 5.
int i2 = (int)( log(64.0) / log(2.0) );
int i3 = static_cast( log(6
--- Comment #6 from again at gmx dot de 2006-10-25 21:57 ---
Remark to test.cpp:23:
std::cout << boost::lambda::_1 << '\n'
This should find the overloaded operator<< defined in boost/tuple_io.hpp.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
--- Comment #5 from again at gmx dot de 2006-10-25 21:53 ---
test.ii produced by `g++ -v -save-temps test.cpp -o test' is to bug for
bugzilla -- you can find it here:
http://schlotter.org/pub/test.ii (1.2MB)
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
--- Comment #4 from again at gmx dot de 2006-10-25 21:51 ---
Created an attachment (id=12495)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12495&action=view)
output of Visual C++ .NET 2003 plus output of compiled program
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
--- Comment #3 from again at gmx dot de 2006-10-25 21:50 ---
Created an attachment (id=12494)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12494&action=view)
output of g++ test.cpp -o test
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
--- Comment #2 from pinskia at gcc dot gnu dot org 2006-10-25 21:48 ---
Can you provide the preprocessed source which you can get via -save-temps and
it will be called something .ii.
Also you can provide the error message you get?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29596
--- Comment #1 from again at gmx dot de 2006-10-25 21:45 ---
Created an attachment (id=12493)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12493&action=view)
test.cpp (sample program that does not compile)
This program does not compile (commandline g++ test.cpp -o test)
--
h
Please find attached a sample program, which does not compile.
Unfortunately this program depends on boost. I use the current boost version
1.33.1. The include files "algorithm" and "iostream" are the ones belonging to
gcc-4.1.1.
--
Summary: overloaded function not found
--- Comment #4 from nigelenki at comcast dot net 2006-10-25 21:42 ---
Issue was passing an unsigned long int to a %i instead of %li format specifier
in printf(). I didn't know my C library altered anything if %n wasn't
specified... oh well, my bug.
--
http://gcc.gnu.org/bugzilla/sh
--- Comment #3 from rguenth at gcc dot gnu dot org 2006-10-25 20:51 ---
Eh, we're not going to debug your code for you. It looks too buggy and
segfaults on me.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-25 20:45 ---
How did you build it? It says
t.c: In function a_hash:
t.c:95: warning: right shift count >= width of type
also it seems to need proper input...
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29595
--- Comment #15 from ghazi at gcc dot gnu dot org 2006-10-25 20:44 ---
Subject: Bug 29335
Author: ghazi
Date: Wed Oct 25 20:44:09 2006
New Revision: 118042
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118042
Log:
PR middle-end/29335
* builtins.c (fold_builtin_c
--- Comment #1 from nigelenki at comcast dot net 2006-10-25 20:41 ---
Created an attachment (id=12492)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12492&action=view)
decrypt_1.2.c
C source file, there's a big block that says "GCC MISCOMPILATION" above the
printf triggering this.
--- Comment #1 from tkoenig at gcc dot gnu dot org 2006-10-25 20:39 ---
This is not a maxloc bug per se. Look at this:
$ cat a9.f90
INTEGER :: K(3)=1
INTEGER, PARAMETER :: J(3)=2
write (6,*) J<1
END
$ gfortran -fdump-tree-original a9.f90
$ ./a.out
F
Output should be
F F F
instead.
I noticed this while developing/debugging the source file, the code is in a
very rough and buggy state but the behavior I'm getting seems to be tied to a
properly formed printf().
$ gcc -v
Using built-in specs.
Target: i486-linux-gnu
Configured with: ../src/configure -v
--enable-languages=c,c++,f
--- Comment #2 from tkoenig at gcc dot gnu dot org 2006-10-25 20:11 ---
(In reply to comment #1)
> Thomas,
>
> Have you written Adrain about his plans concerning his patch?
Not yet (I tried CC'ing him with this, but apparently this doesn't work).
IIRC (and Adrian, please correct me) h
--- Comment #1 from pinskia at gcc dot gnu dot org 2006-10-25 18:56 ---
This warning is hard to get right as there are many many pieces of code that
depends on binding an rvalue to an constant reference.
This bug is related to PR 986.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
If I run jv-convert with no arguments I see an NPE:
opsy. jv-convert
Exception in thread "main" java.lang.NullPointerException
at gnu.gcj.convert.IOConverter.canonicalize(libgcj.so.7)
at gnu.gcj.convert.BytesToUnicode.getDecoder(libgcj.so.7)
at java.io.InputStreamReader.(libgcj.so.7)
a
--- Comment #7 from darkjames at darkjames dot ath dot cx 2006-10-25 17:24
---
Ok, one more question, is it possible to gcc print some warnings about code
like that? Cause even with -Wall it doesn't ;(
gcc4 is quite more verbose than gcc3 so I think
It'll be better to print warning ab
--- Comment #6 from pinskia at gcc dot gnu dot org 2006-10-25 17:18 ---
(In reply to comment #5)
> Yeah, I know, but why gcc generate good code if we add that printf to test1.c
> (test2.c) ? It's still wchar * -> char * still aliasing violation.
Yes but there is a barrier which cause op
--- Comment #5 from darkjames at darkjames dot ath dot cx 2006-10-25 17:11
---
Yeah, I know, but why gcc generate good code if we add that printf to test1.c
(test2.c) ? It's still wchar * -> char * still aliasing violation.
or if we replace:
__SN(&str, 1); with
str = (CHAR_T *) (((char
The following code has a subtle bug:
#include
class Blah
{
public:
const unsigned int &myfoo;
Blah(const unsigned int &p):
myfoo(p) {}
const unsigned int getfoo()
{
return myfoo;
}
};
int main()
{
int foo(42);
Blah baz(foo);
++foo;
assert(foo == baz.getfoo());
ret
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-25 16:45 ---
In the both case, you are accessing "wchar *" via "char *" which causes an
alias violation.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
-
--- Comment #4 from rick at hartmantech dot com 2006-10-25 16:23 ---
The problem is not only confined to "sufficiently modern machines". Some of us
have a conservationist sort of outlook, and are happy to find a use for an
older machine as a router, firewall, Kerberos server or whatever.
--- Comment #3 from darkjames at darkjames dot ath dot cx 2006-10-25 16:20
---
By the way, it's possible to fix the code in other way than using unions?
It just need to work both for wchar_t strings and normal strings...
If you have some ideas how, it'll be nice if you give me some hint
--- Comment #4 from billt at tutsys dot com 2006-10-25 16:13 ---
No luck using gcc 4.1.1 as the bootstrap compiler: I used the existing compiler
to build and install just the C compiler, which worked fine. "make bootstrap"
failed to build gcj using 4.1.1 as the C compiler. I then built a
--- Comment #2 from darkjames at darkjames dot ath dot cx 2006-10-25 16:13
---
Created an attachment (id=12491)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12491&action=view)
Second testcase
test1.c + added printf() to loop, not loops with -O2
--
http://gcc.gnu.org/bugzil
--- Comment #1 from darkjames at darkjames dot ath dot cx 2006-10-25 16:12
---
Created an attachment (id=12490)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12490&action=view)
First testcase
First testcase loops unending with -O2, not loops with -O2 -fno-strict-aliasing
||
-fst
After compilation test1.c with -O2 program loops unending.. Yeah I know is
possible cause -fstrict-aliasing and program works compilated with -O2 &&
-fno-strict-aliasing
It works too if it was compilated just only with -fstrict-aliasing so it loops
when some other optimization was turned on.
It w
--- Comment #11 from bonzini at gnu dot org 2006-10-25 14:55 ---
committed to all branches
--
bonzini at gnu dot org changed:
What|Removed |Added
Status|ASSIG
--- Comment #10 from bonzini at gnu dot org 2006-10-25 14:55 ---
Subject: Bug 29092
Author: bonzini
Date: Wed Oct 25 14:55:09 2006
New Revision: 118034
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118034
Log:
2006-10-26 Paolo Bonzini <[EMAIL PROTECTED]>
PR c/29092
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-25 14:39 ---
*** This bug has been marked as a duplicate of 29567 ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
--
--- Comment #5 from rguenth at gcc dot gnu dot org 2006-10-25 14:39 ---
*** Bug 29590 has been marked as a duplicate of this bug. ***
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
---
--- Comment #1 from dcb314 at hotmail dot com 2006-10-25 14:29 ---
Created an attachment (id=12489)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12489&action=view)
C++ source code
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29590
I just tried to compile Suse Linux 10.1 package abiword-2.4.5-6 with the new
GNU C compiler version 4.3 snapshot 20061023 on a x86_64 machine.
The compiler said
ap_Menu_Functions.cpp: In function 'EV_Menu_ItemState
ap_GetState_SetPosImage(AV_View*, XAP_Menu_Id)':
ap_Menu_Functions.cpp:1588: inter
--- Comment #10 from uros at kss-loka dot si 2006-10-25 14:16 ---
(In reply to comment #9)
> > In the later case, expansion will fall-back to normal library call.
>
> OK. So on system where the math library doesn't have remainderl, for example,
> we shouldn't use BUILT_IN_REMAINDERL or
--- Comment #2 from vincent at vinc17 dot org 2006-10-25 14:00 ---
(In reply to comment #1)
> So this sounds like a bug in your installation.
This cannot be with my installation in particular as the bug occurred on
various Linux machines (only one is mine). However it could be due to ba
--- Comment #9 from fxcoudert at gcc dot gnu dot org 2006-10-25 13:53
---
(In reply to comment #8)
> In the later case, expansion will fall-back to normal library call.
OK. So on system where the math library doesn't have remainderl, for example,
we shouldn't use BUILT_IN_REMAINDERL or
--- Comment #15 from kreckel at ginac dot de 2006-10-25 13:22 ---
(In reply to comment #14)
Maybe scheduling would have the same issue. The fact that the result of the
division is not used is a red herring, though. Of course, the assumption is
that it's actually used.
--
http://gcc.
--- Comment #2 from rguenth at gcc dot gnu dot org 2006-10-25 13:09 ---
Fixed.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #3 from JoeGTN1 at NetZero dot net 2006-10-25 12:44 ---
I think the pertinent part of this "bug" is:
> Is it possible to split this file?
It took 6-8 hours to compile this file alone on my xbox, which only has 64m
of memory but should be considered a sufficiently modern ma
--- Comment #7 from uros at kss-loka dot si 2006-10-25 12:18 ---
(In reply to comment #6)
> On Xeon 3.6, SSE is now faster:
... but for -ffast-math:
SSE: user0m0.756s
x87: user0m0.612s
Yes, x87 is faster for -ffast-math by some 20%.
--
http://gcc.gnu.org/bugzilla/show_bu
--- Comment #5 from dberlin at gcc dot gnu dot org 2006-10-25 12:12 ---
Subject: Re: [4.2/4.3 Regression] tree check: expected ssa_name, have var_decl
in is_old_name, at tree-into-ssa.c:558
On 25 Oct 2006 05:23:00 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> -
On 25 Oct 2006 05:23:00 -, pinskia at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
--- Comment #4 from pinskia at gcc dot gnu dot org 2006-10-25 05:22 ---
_ZTCN33_GLOBAL__N_t.cc__2292CFAC11NullostreamE0_13basic_ostream
# _ZTI13basic_ostream = V_MAY_DEF <_ZTI13basic_ost
--- Comment #6 from uros at kss-loka dot si 2006-10-25 12:04 ---
(In reply to comment #5)
> With more registers (x86_64) the stack moves are gone, but: (!)
> (testing done on AMD Athlon fam 15 model 35 stepping 2)
On Xeon 3.6, SSE is now faster:
gcc -O2 -march=pentium4 -mfpmath=387 pr
--- Comment #8 from uros at kss-loka dot si 2006-10-25 11:48 ---
(In reply to comment #7)
> Just to be sure I understand: we are garanteed that BUILT_IN_REMAINDER{F,,L}
> and BUILT_IN_FMOD{F,,L} are always available, right?
Yes. The expansion does not depend on -ffast-math anymore. How
--- Comment #4 from uros at gcc dot gnu dot org 2006-10-25 10:14 ---
Subject: Bug 28909
Author: uros
Date: Wed Oct 25 10:14:41 2006
New Revision: 118028
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118028
Log:
PR target/28909
* config/i386/sync.md ("sync_add",
--- Comment #3 from vladimir at codesourcery dot com 2006-10-25 08:54
---
I've confirmed that the patch does adds the exe extension for
$target-gcc-$version, when building arm-none-eabi.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28400
--- Comment #7 from fxcoudert at gcc dot gnu dot org 2006-10-25 08:19
---
I'm adding Steve Kargl to the CC list, since he's our arithmetics expert :)
(In reply to comment #6)
> Revision 118024 clears the way for MOD and MODULO implementation:
> http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg
--- Comment #9 from bonzini at gnu dot org 2006-10-25 08:11 ---
Subject: Bug 29092
Author: bonzini
Date: Wed Oct 25 08:11:26 2006
New Revision: 118025
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118025
Log:
2006-10-25 Paolo Bonzini <[EMAIL PROTECTED]>
PR c/29092
--- Comment #14 from pinskia at gcc dot gnu dot org 2006-10-25 07:57
---
So what is happening is there explict barrier for the divide so we assume we
can move it. I don't know what the correct thing is really, scheduling will
have the same issue and so will being able to delete the div
--- Comment #13 from kreckel at ginac dot de 2006-10-25 07:54 ---
(In reply to comment #12)
> It doesn't disappear with -fno-tree-ter, as I would assume if it were a TER
> bug.
I just discovered that it does disappear with -fno-tree-sink, though.
--
http://gcc.gnu.org/bugzilla/show
--- Comment #3 from keinstein_junior at gmx dot net 2006-10-25 07:41
---
Created an attachment (id=12488)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12488&action=view)
one failing and one working set of .mod files
In the tar archive there are two subtrees:
src-ICE has all load
--- Comment #6 from uros at kss-loka dot si 2006-10-25 07:33 ---
Revision 118024 clears the way for MOD and MODULO implementation:
http://gcc.gnu.org/ml/gcc-cvs/2006-10/msg00703.html
BTW: I don't know fortran requirements, but built-in functions produce faster
code if errno is not neede
--- Comment #5 from pault at gcc dot gnu dot org 2006-10-25 07:18 ---
This fixes it but has not been regtested. I was hoping to have found a
slightly cleaner way to fix this but did not alight on anything that would not
be a big performance. It's OK for rank 1 arrays but for rank 2 or
--- Comment #5 from kloedej at knmi dot nl 2006-10-25 07:16 ---
Thanks for your additional explanation, and the link to the original mail in
the mailing list.
A last remark on my side is then about the actual text of this error message.
People not familiar with the choice made in the fo
81 matches
Mail list logo
